Fred, the real Fred 01 Apr 05

Jason…..your dead on with this one.

And that’s no April Fools joke.

Malcolm O'Keeffe 01 Apr 05

It’s an interesting hypothesis, but I don’t think it’s neccessarily applicable to all web-based projects.

I think it applies more clearly to new, “custom” applications where there are many potential discoveries along the project’s path. For example, a client who needs you to build an extranet for B2B commerce - I have seen projects like this change significantly along the way, and need to have one or more adjustments to time/scope/cost.

The way we always try to handle engagements like this is by emphasizing a stong discovery/strategy phase, and adjusting expectations at the end of this phase. We can usually catch between 75-90% of the likely changes to the client’s original expectations prior to building anything. We then work with the client to review the differences (the dreaded “gap analysis”) between how they originally described the scope to us, and what they really need/want. It seems to be the best possible situation for both us and the client, as they’re not hit with change order after change order, and they can then prioritize things based on their ability to adjust cost/time expectations on their end.

For a more straightforward project - say a typical “corporate Web site”, I think there’s no reason that an agency or freelance developer/designer can’t deliver a tightly scoped estimate, and complete the project based upon that estimate. If you clearly describe exactly what you’re doing for XX cost, then any significant (client-generated) changes will have an effect. If you can stay on top of the changes from the client, and let them know when they step over the lines, they can then make the choice to pay more/take longer, or stay within the bounds of the current agreement.

It’s very difficult for clients to accept the concept that the project doesn’t have fixed limitations from a cost/time perspective (both of which are dependent upon scope, of course). Clients have both limits on their budgets, as well as deadlines they have to meet. In order to make the client successful, it’s important for the agency to deliver a well-scoped, thorough project plan that CAN be completed in time and within budget. If the client wants to change things after this point, then it’s their call.

Jason and crew are in a great position now, in that the bulk of their work and revenue comes from the products they are developing. I would imagine that it’s easier to be more careful about which clients you work with in these circumstances. I’m pretty sure that if I were to have presented most of our clients with an open-ended proposal (from a time/cost perspective), I’d have had a hard time convincing them that we were their best choice.

One of several Steves 01 Apr 05

This is one area in which I get envious of you. I don’t really have the luxury of choosing my clients. The company I work for chooses them for me.

The scope/time/budget battle is an unending one. And if you’re able to find clients who truly accept that only two are possible, you’re insanely fortunate. In my experience, even though most clients do accept it begrudgingly, it’s often a struggle to bring it home and get them to accept it in reality and not just concept. It’s tough to tell which is the more persistent struggle: that or getting clients to stop requesting substantial changes or new items late in the development - or, worse, testing - process.

JF 01 Apr 05

Yup, it’s definitely tough. No doubt about it. And we’re not always successful at it, but we aim for it. If Plan A doesn’t work then you go to Plan B, but always work for Plan A first.

Jameson 01 Apr 05

Sure, the client will always be happy at the onset if you let them pick three and promise them everything they want. But most clients (the right clients) will be more satisfied in the long run if you present them with something which meets their needs and is realistic.

Any project I’ve ever seen that starts with promising the client everything eventually degrades into bickering over specifics. Something has to give, and without any flexibility you start arguing scope semantics just to get done on time. Projects with realistic expectations go more smoothly - maybe the client has to compromise along the way, but in the end they get the best result.

After all, that’s why you hire professionals to do the project: they’ve got the experience to know how to do it best.

JF 01 Apr 05

BTW, Merlin posted some thoughts on this at 43folders.

Steve, via Den, Fla and now RDU 01 Apr 05

I think it applies more clearly to new, �custom� applications where there are many potential discoveries along the project�s path

True and like Jason/PaulGraham/Guy Kawasaki has said, get Version 1.0 out the door ASAP.

“Version 1.0 means never having to say your sorry.” - Guy Kawasaki

Malcolm OKeeffe 01 Apr 05

It’s an interesting hypothesis, but I don’t think it’s neccessarily applicable to all web-based projects.

I think it applies more clearly to new, “custom” applications where there are many potential discoveries along the project’s path. For example, a client who needs you to build an extranet for B2B commerce - I have seen projects like this change significantly along the way, and need to have one or more adjustments to time/scope/cost.

The way we always try to handle engagements like this is by emphasizing a stong discovery/strategy phase, and adjusting expectations at the end of this phase. We can usually catch between 75-90% of the likely changes to the client’s original expectations prior to building anything. We then work with the client to review the differences (the dreaded “gap analysis”) between how they originally described the scope to us, and what they really need/want. It seems to be the best possible situation for both us and the client, as they’re not hit with change order after change order, and they can then prioritize things based on their ability to adjust cost/time expectations on their end.

For a more straightforward project - say a typical “corporate Web site”, I think there’s no reason that an agency or freelance developer/designer can’t deliver a tightly scoped estimate, and complete the project based upon that estimate. If you clearly describe exactly what you’re doing for XX cost, then any significant (client-generated) changes will have an effect. If you can stay on top of the changes from the client, and let them know when they step over the lines, they can then make the choice to pay more/take longer, or stay within the bounds of the current agreement.

It’s very difficult for clients to accept the concept that the project doesn’t have fixed limitations from a cost/time perspective (both of which are dependent upon scope, of course). Clients have both limits on their budgets, as well as deadlines they have to meet. In order to make the client successful, it’s important for the agency to deliver a well-scoped, thorough project plan that CAN be completed in time and within budget. If the client wants to change things after this point, then it’s their call.

Jason and crew are in a great position now, in that the bulk of their work and revenue comes from the products they are developing. I would imagine that it’s easier to be more careful about which clients you work with in these circumstances. I’m pretty sure that if I were to have presented most of our clients with an open-ended proposal (from a time/cost perspective), I’d have had a hard time convincing them that we were their best choice.

Malcolm OKeeffe 01 Apr 05

Sorry for the double post! (Got an error on the first submission, assumed it didn’t get posted. )

Jon Blake 01 Apr 05

What you say is insightfully simple, but perhaps too simple.

For example, saying that you have fixed scope and timeframe but flexible budget implies that if a project is falling behind, more money will fix the problem. As anyone who has been introduced to Mythical Man-Month by Frederick Brooks is aware, more money and more manpower doesn’t make software projects deliverable on time.

Still this triangular metaphor is a good place to start and a good way to frame discussions with a client. And it still probably holds up for work that isn’t similar to software.

pb 01 Apr 05

It seems that people invariably have a time and budget in mind so it usually comes down to scope and virtually every project could afford to be scoped down.

graham 01 Apr 05

Why are the archives for this blog no longer available (as far as I can tell)?

JF 01 Apr 05

virtually every project could afford to be scoped down.

You nailed it, pb. As we say, make half a product, not a half-assed product.

Don Schenck 01 Apr 05

This is timely, as I’m about to start on a new project for a client. It’s interesting because they have a “Statement Of Work” and want a time estimate — which means a cost estimate. In effect, they want to fix all three.

I, of course, am pushing back. Should be “interesting”.

Anonymous 01 Apr 05

Where is the sent to Printer button on this blog?

Some of this stuff is worth keeping in print!
Or better yet another 37Signals book on process improvement.

Don Schenck 01 Apr 05

I can’t believe that in this day and age, with all the information and training available, that developers don’t prioritize Requirements. Mindboggling.

JF 01 Apr 05

As anyone who has been introduced to Mythical Man-Month by Frederick Brooks is aware, more money and more manpower doesn�t make software projects deliverable on time.

I completely agree with this, but sometimes more money can shift priorities. If a client pays X, maybe I can spend 65% of my time on their project. But if they pay Y, maybe I can spend 85% of my time.

Allan White 01 Apr 05

I see approaches like Get Real and “pick two” as high-level principles that are helpful for setting expectations (both on our side and the client side). Absolutes and rigid philosophies (i.e. legalistic or overly rule-bound approaches) are destined for trouble (wait - I just wrote an absolute statement…).

I like guiding principles like these - very helpful.

Steve 01 Apr 05

Why not have quality be variable as well? I’d never much liked the
triangle vs the square (cost, time, scope, quality) because nobody
seems to be willing to talk openly about quality expectations.

If you want NASA-style near-perfection with mathematically proven
algorithms, that’s obviously going to cost more if you get your high
schooler nephew to write it. But even less obviously, an intranet
probably can stand a few more bugs than a busy e-commerce site.

So maybe it’s okay to have less QA time on a project to contain costs,
if the lowered quality is acceptable. Why not discuss that option out
in the open?

Adam Michela 01 Apr 05

Where is the sent to Printer button on this blog?

Anonymous: Select the text of the post and go to Print > Selection (FF or IE). It will print great. :)

kira 01 Apr 05

From a client’s point of view — these principles sound like a straightforward but rigid technique to keep a client focused on what’s truly important.

I can’t see this model replacing the client 1) being clear on goals and priorities, and 2) having the discipline to make trade-offs based on new information.

A client with those two things straight should be able to manage trade-offs efficiently without eliminating one axis of flexibility before the project even starts.

To make that more concrete, I can say at the beginning that I think launch date is the most flexible constraint. But that doesn’t mean that in *every* case, I would trade time in order to get higher quality, lower price, or more features.

And I agree with Malcolm that clear expectations and building scope/time/cost checkpoints into the process is key.

Adam Michela 01 Apr 05

This is timely, as I�m about to start on a new project for a client. It�s interesting because they have a �Statement Of Work� and want a time estimate � which means a cost estimate. In effect, they want to fix all three.

Don: Your client isn’t in the wrong. The Statement of Work is a long standing, standardized, business form:

Project Request
Background
Scope of Effort
Approach
— Technical Approach
— Quality Approach
— Management Approach
Deliverable Products
Roles and Responsibilities
Time and Cost Estimates
Change Process
Acceptance Process
Appendices

You define the project, determine the deliverables, then you estimate how long it will take you, then you estimate how much that time costs.

These are not supposed to be exact estimates. All assumptions are supposed to be defined, and you should not estimate for anything that hasn’t already been defined.

The Change Process is where you establish a procedure for dealing with the unexpected. This is also where you establish a Change Budget.

You define QA in both the Management Approach and the Acceptance Criteria.

The Project Triangle COMES from the philosophy on which the SOW is based. If you are ever instructed on writing a standardized SOW you will be taught about the triangle mentioned here.

Adam Michela 01 Apr 05

As anyone who has been introduced to Mythical Man-Month by Frederick Brooks is aware, more money and more manpower doesn�t make software projects deliverable on time.

No doubt. There are formulas for estimating how much man-power should be allocated to a project. For every 15% above or below you lose 15% productivity on the project.

Estimate the total effort hours a project will take with 1 person, multiply that by a productivity factor of 1.25, divide that by 173 (the average work hours per month), and you get the total months the project will take.

The square root of that result is the exact amount of people that should be on the project.

* Keep in mind I didn’t invent this shit, I’m not vouching for it’s reliability and it probably doesn’t apply so well to small teams. Although, this is one of the few formulas of project management I’ve always found to be relatively reliable (in big teams)

Adam Michela 01 Apr 05

Damn! Would someone mind closing my tags for me? ;o

We need a post preview :(

Matt 01 Apr 05

Hmm… Is that right. “fixed scope, fixed timeframe, or fixed budget”… I bet my client would pick fixed timeframe & fixed Budget… They will let the scope remain unfixed.

:)

Matt Henderson 02 Apr 05

I’m just curious, how do you contractually capture the non-fixed element when you sign engagement documents with your customers? In all of the projects we’ve been involved in, we’ve been required to capture (in a contract) all three areas: scope (requirements), budget and schedule.

Christopher Fahey 02 Apr 05

The “pick two” theory is useful only when a project’s scope is excessively vague. It’s not a myth — it’s more like a crutch.

If you have enough experience in your professional field, it’s really not so hard to write a Statement of Work in which all three (price, time, scope) are fixed. If you (a) provide sufficient detail about the features, tasks, and deliverables of the project (using detailed descriptions, specs, examples, etc), (b) specifically identify those areas of the scope that are risk factors for scope creep (for example, stipulating that the client must deliver assets on time and in the right format or else the project timeline & price will be affected), (c) identify key assumptions about the project that, if violated, will constitute scope change (for example, that a content management system can do something that later proves to be impossible), and (d) maintain a good and open client service relationship with your client throughout the project… then promising a fixed time, price, and scope should not be a problem.

In other words, identify what is in scope and identify what is NOT in the scope before the project begins. Visualize the project as it will unfold over the weeks and months ahead, and try to anticipate all the various ways in which scope creep will occur. And write it all down in the SOW. When scope creep starts to rear its ugly head, as it inevitably will, your SOW will give you the contractual basis on which to ask the client to either scale back the original scope or to pay for the additional features via a contract change order or addendum.

In other words, the “flexibility” Jason describes can be specifically written into the contract. This it the “Change Management” process that several others have mentioned above.

I attribute the old “pick two” choice as only useful when an inexperienced client is so eager to begin work that they’re willing to sign vague, unspecific contracts… or when the client is looking to “entrap” an inexperienced vendor into promising the impossible and setting themselves on fire in order to deliver… or when a vendor is so eager to land new business that they are willing to take the risk of not practicing good healthy CYA.

But if you and your client can be even a little bit patient and honest with each other, it’s not uncommon for the scope/pricing segment of a project to take many weeks of close communication and negotiation in order to ensure that both sides are “on the same page” about what is in scope and what is not. Writing an SOW is hard work, and can sometimes take up a noticable chunk of the project’s total timeframe - time well spent when you consider the impact of scope creep when it invariably occurs. If your client’s project is large enough, this segment of the project development should be billable to the client as well.

-Cf

Adam Michela 02 Apr 05

Great post Chris. I pretty much agree on all points.

On “Writing an SOW … can sometimes take up a noticable chunk of the project�s total timeframe”: Yep. 10% is the accepted average.

Vanja Bertalan 03 Apr 05

Yes, Chris summed it up really well. Great post.

Patrick Dodd 12 Apr 05

I have to disagree to a certain extent with your “pick two” argument for development. By using an agile development methodology you start by listing all of the desired functionality and then have the client prioritize the list. Once the list has been prioritized you inform the client that you will break the project into 30 day iterations and focus exclusively on the first iteration. Your client has some flexibility in determining how much they would like to accomplish in the first iteration by determining the number of programmers that will be working on the project with the stipulation that there is a maximum number of programmers that can productively work on the project whereby adding more programmers will not increase the productivity. Once you have locked in the resources and the scope for the 30 day iteration, the budget, by default, is also determined. The key is to focus only on the tasks of the present iteration to avoid scope creep. We have been using this methodology and have found it to work very well.

MonkeyT 21 Apr 05

Why not have quality be variable as well? I�d never much liked the triangle vs the square (cost, time, scope, quality) because nobody seems to be willing to talk openly about quality expectations.

It’s no good to anyone if it doesn’t work. Quality isn’t job one. Quality is the bottom line. Being absolutely f@#!$ing amazing is job one. (Not mine, came from GapingVoid.com, but good words.)

Ritz 27 Apr 05

I have a problem with working for a client for weeks, if not months, before actual working progress is made for the client. This “Pick Two” scenario gives you the ability to start working, not next month or next week, but now and still maintain some sort of contractual agreement.

I also like the idea of having mock-ups or prototypes for the client to see and use before really signing your lives away on paper. Picking two lets you quickly and effectively show the client what you’re envisioning and see if it’s matching their vision. Lending flexibility to one of the three parts lets you skip over so many formalities and actually work.

I know we all love explaining things to the millionth degree, get to work, and when the client sees final product… wait… that’s not what I was thinking… Let the good times roll!

Wayne Arthurton 01 Jul 05

I just re-read this post. I used to tell my clients something very similar. “Sure we can do that, we can do anything. But there is a matter of time and money.”

vruz 29 Aug 05

I partially agree with Steve, who mentioned Quality should be taken into account when making estimates.
I believe Quality can be taken account of as part of Scope, which records customer’s expectations.

As I see it Scope can be fragmented in three variables in fact, that together describe the quality of a project:

A) Comprehensiveness, feature-completeness
B) Extendability, can the project/product grow ? can it be “easily” adapted to new situations that may occur ?
C) Maturity, “built-in intelligence”

(A) Comprehensiveness Is the easiest, the set of tasks the application/system is expected to perform to be useful. It may not be the most efficient system, but it lets you do everything you need to get the work done. This is in my book an “objective” list of requirements. It can be measured, tracked and projected, tried and true methods are always good for it.

(B) Growth, can be broken down in two (at least)… Scalability and Extensibility. Can we add notes to this form as a reminder ? Can we scan photos and attach them to mails inline ? Oh, by the way, we expect growth in the second quarter, we will need to migrate the database from MySQL to Postgres or Oracle and cluster them somehow. Didn’t we tell you we would like our partners to develop their own plugins to retrieve data from our warehouse management system ? We now need our statistics to track 1 million visitors to the website but the system only allows for the top-20…… yeah, don’t smile, it happens to all of us.

C) Maturity, “built-in” intelligence. This is the hardest of all, because it’s mainly a subjective matter.
You can make a feature-complete application according to the requirements, but it will never be mature enough unless one of the following things happen:
1) You -the developer- are the person with domain knowledge of the problem at hand. (the ideal)
2) You have immediate/recurring/frequent access to the person who has domain knowledge and this key person is an expert and totally supports the project. (there’s nothing worse than boycotts and false commitment)
3) You work your ass off and try to learn a new domain, and how to be efficient at it, but this will take a lot more time and it may not be what you want to do after all.

Extreme programming advocates try to tack all of these at different levels more or less simultaneously.
Whilst it’s good to attack the problems in parallel it’s also important to be able to identify them separately proactively when you prepare your strategy.

Finally, how do you measure Quality ?
HCI have a lot to do with it, how the end-user interacts with the inner engine of the system to make her work more efficient.
A user will tell the difference from a mature application from another one that’s only feature-complete when she uses them, not before. Mock-ups of a running application at different stages are always good for this. Usability studies are conducted in big projects, how does usability impact productiveness ?
How can you guarantee Quality ?
I think they will just have to give you credit for having been successful at creating Quality before, just like Gaudi or Le Corbusier, and being able to consistently deliver this across your previous works.

Quality is also about density, about how much intelligence you build in the engine. Not stuff you thought might be useful, (ie: not “more features”) but actual intelligence that is useful at work. (ie: useful features)
I may be biased on this, however contradictory it may sound, I’m a big minimalist :-)

One final question:
Is it a cost-effective decision to build-in more intelligence into the system ?
Is it a cost-effective decision to make it more extensible ?