Cheap-Fast-Good for Doable Requirements

Cheap-fast-good. Pick two.

Probably every IT person collecting new project requirements has at least said this in their head. The three alternatives contain a basic truth about balancing resources. There is a way to use the relationship to set better requirements. The best kind of requirements: requirements that get you the resources you need to satisfy them.

Requirements Definition

To be clear: the requirements I’m talking about are not simple service requests. A simple request asks for something familiar. Usually it’s something that doesn’t take long to complete. It may be a standard and well-defined service offering. The balance of the cheap-fast-good is already well-known and accepted. Example: ‘to get you a new printer, it’ll cost $X and can be done by next Tuesday’. Standard stuff.

The requirements process improved here supports projects. A project is a series of steps to significantly extend current service offerings. It may create a new service. It implies that an unknown amount of time and resources may be needed to satisfy the requirements – or even to estimate the time and resources needed.

Let’s say that you have the requirements. Let’s call the person giving you the requirements ‘the customer’. You have identified that the current requirements is a project. Where should ‘cheap-fast-good’ enter the requirements gathering process?

Cheap-Fast-Good as Budget-Schedule-Features

‘Cheap-Fast-Good’ makes its appearance when:

you have determined that the request is a project, and
you are presenting an estimate of resources needed to satisfy the requirements.

Part of making ‘cheap-fast-good’ a useful tool in justifying requirements is changing the formulation to make it actionable. An alternative is ‘budget-schedule-features’.

Cheap is probably the easiest. It’s the cost. It may be the purchase cost for external resources. For internal resources, it is usually stated in labor time required. All of this is budget.

Fast is the when it will be available. In project planning this is the duration. Usually duration and time required are different amounts.

Good is the number of features that satisfy the requirements. Unlike the previous two elements, features are a bit more involved. This is where the real work of meeting requirements comes into play.

A feature is a deliverable item. If you have several features, you may or may not include a feature in satisfying the requirements. A feature may be dependent on other features. You have to have the dependent features as part of the project in order to have the feature depending on them.

Example: ‘that new printer you’re getting on Tuesday – do you want the high capacity paper tray?’ The paper tray is a dependent feature. If you don’t have the printer, you won’t have the high capacity paper tray. You can still have the printer without the tray. You have two features: the printer itself and the high capacity paper tray.

How do features define ‘Good’? The more features, the more the requirements are fulfilled.

So how does ‘cheap-fast-good’ become actionable in ‘budget-schedule-features’?

Budget implies the cost of resources more so than does cheap. The cost may be the time required, which usually is not associated with ‘cheap’.

Schedule implies fast. It also suggests working fulfillment of the requirements for this project into a production schedule that includes other projects.

Features brings clarity to what is meant by good. Good (or ‘quality’) is a fluid and vague concept. ‘Good’ is usually what the person giving the requirements says it is. That is hard to quantify and balance. The number of features, and their relative magnitude for their impact and time to create, is easier to balance.

Applying Budget-Schedule-Features

Putting ‘budget-schedule-features’ to work:

when creating options to satisfy the requirements, budget-schedule-features defined requirements in terms of budget-schedule-features provides a basis for comparison.
when gathering requirements, budget-schedule-features provides a checklist to cover before ending the requirements gathering. Do you have an idea of what the features are? Do you have an idea of the budget that would be accepted? Do you have an idea of an acceptable schedule?
when a project is in progress, it helps define changes resulting from underestimating schedule or cost, or feature scope creep.
when a project is completed, the budget-schedule-features list provides the benchmark for whether the requirements are fulfilled as agreed

Using the relationship in handling a project in progress can be especially valuable. The two most common reasons for exceeding the budget or schedule are:

budget and schedule was underestimated and/or
something changed

Underestimating, particularly for the time required, is probably the most frequent reason for missing the agreed marks. Using Agile feature estimation helps avoid this outcome. Limiting feature definitions to the smallest viable deliverable increases accuracy. Unlike budget and schedule, underestimating features takes the form of the original understanding of the features not matching what was intended. This is the discovery that there is a lot more to the features than was originally understood.

‘Something changed’ is generally something out of your control and thereby beyond the bounds of reasonable estimating. Maybe the person who was going to do the work had a long illness. That breaks the schedule. Maybe the price of the example printer had increased by the time you’re ready to buy it. That breaks the budget.

Maybe features were added. Yeah, that’s probably it.

Features Creep Resolution

Adding features doesn’t invalidate the original estimate. The original estimate was ‘this much budget and this schedule for these features’. Increasing / changing agreed features or adding features has an impact on budget and schedule.

When using Agile for projects, the iterative process fine-tunes the features. This is a good thing. The key to recognizing a project as successful is adjusting the budget and schedule in step with the feature adjustment.

What to do when the person who gave you the initial requirements wants to hold you to the original budget-schedule-features when there has been a lot of change (rather than a lot of underestimating)? If you’ve been communicating the changes along the way, this shouldn’t be a surprise. Despite this care, the dialogue goes something like this:

“You said it would be done by <fill-in the original date>”

You: ‘You changed the features. That changed the <budget/schedule – pick one or both>’.

‘But you said it would be done by <fill in the original date>’.

You: ‘That original date was for the original features. What you have now is different”

‘No, it does what I originally wanted.. So why wasn’t it done by <fill-in the original date>?”

And now you have it. The customer who supplied the requirements is talking about the goal, or ‘what he wanted’. You are talking about features, or ‘how we got you what you wanted’.

I prepare for the challenge of ‘why did this take so much longer?’ by:

Reviewing where I underestimated,
Reviewing where something happened outside of my control, and
How the features evolved to satisfy the requirement

If I’ve done well, I’ve communicated how the budget and schedule changed as the features evolved. You can hope for a customer understands the relationship and remembers the update communications.

You may have a customer that choses to not remember the updates. This is frequently accompanied with the phrase ‘I don’t want to hear excuses.’

Worse than disavowing the updates given along the way, your customer may deny that changes in budget, schedule or features has an impact on the other two elements. Sometimes you must provide an estimate to a customer who holds this delusion. You may be part of in-house IT and you can’t chose your customers. If you’re faced with a customer who holds that delusion, and you still must provide an estimate, you need to massively overestimate all the components.

The overestimation may be rejected, too, in favor of the number the customer feels is right. Depending on the customer role in the organization, they may be able to make it stick. That’s a losing situation. Changing the situation to find a new customer is usually the only ‘out’.

Budget-Schedule-Features in Creating Requirements

I use the budget-schedule-features relationship even in casual requirements gathering. After I clarify what the customer wants, I determine whether this is more like a project. I talk with them about possible solutions. In this instance, the solutions are high level features. If the customer indicates agreement, I’ll say about a solution, ‘and this might take this long and we’ll have to buy X’. I can gauge the customer value for the project based on their reactions. If they still want to proceed. I’ll let them know when I’ll get back with them for approval. When I return, I introduce them to not only my estimate, but the budget-schedule-features relationship.

Depending project life length, I log underestimates, things outside my control, and, most importantly, feature shift. When the changes are material, I communicate the variances. This keeps the budget-schedule-features balance and adjustments clearly in view.

The results:

I get what I need on the front end for successful completion
I enjoy acceptance on completion.

What I don’t get

projects for which the expectations are not adjusted to something practical
as much grumbling and complaining on the way to completion
the substantially less than five star rating for the work delivered