Last week's article on doing agile development with clients provoked a comment from a reader who claimed that “Fixed-price contracts require specific deliverables.” This is an assumption that we also debated last year. We'll listen to the reader's concern – lack of accountability - and then move on to the big issue, which is whether you need a specification at all.
I wrote, “You can set minimum deliverables, and then run your team with weekly releases and deliverables that get changed when you discuss the next week. I know this works because we do this in all of our customer jobs. And, I insist on it. When I have worked on teams that delivered to fixed specifications, the end product and customer satisfaction were not as good.”
Micheal Motta writes “In this case, all of the project risk shifts also to the customer. But what the customer typically buys is functionality. They also want their partner to adopt some of the project risk. Fixed-price contracts require specific deliverables. Most often, these are the basis for progress payments. It is not a viable business model for all project risk (both technical and business) to swing entirely in favor of the client. So, incremental payments are essential. Where there are fixed deliverables tied to payments there are acceptance tests to ensure the goals have been met. Where there are acceptance tests there is a specification somewhere. Operating in the absence of a specification is a disaster under the fixed-price engagement model.”
I would argue that the risks just get moved around. The customer removes some of the risk of not getting what they pay for. However, they assume the risk of getting a bad product, if the original specification was not great, which is the assumption that drives these weekly deliverable engagements. They also run the risk of never getting anything, or getting it much delayed. Capers Jones notes that more than 50% of big projects are never finished. If the customer wants to shift risk onto the service provider, then just hold back some of the money until it gets a viable release.
What really happens is that product management and budgeting work moves from the up-front specification, to the weekly planning. Moving work around can be important if you care about time to delivery, which we will get to later.
Actually, I tried taking Motta's position, in the 90's. I took over a small company that specialized in working to specification, because they weren't doing well. I loved the concept anyway. They would make wireframes of every screen in the proposed customer system, and print them out in a big book. Then, they asked the customer to initial every page in the book. They would work for a few months, and come back with the requested system. About a month after I got involved, we brought one of these projects to the customer for delivery, and I learned why they weren't doing well. The customer hated the app.
Motta goes even further: “I agree with Joel Spolsky's prescription that a spec up front is in all cases necessary.”
No, a specification is not always necessary. Did Spolsky really make such an absolute claim? I do not agree that an up front spec is always required, nor do I agree that there should always be an orderly process to modify the spec. All of these things are very useful. However, they all cause delays. The specification is sort of like pants. It's nice to have pants. But, some days are kilt days. The absence of a spec doesn't mean that we don't have to think about our product. Far from it. It just means that we need to think about where and when we fit our design to our requirements.
I can think of at least two ways to avoid doing a spec up front. First, you could use a Kanban-style process where design is one of the steps for each incremental change. The second option sounds more radical, but it is widely used in the open source world. Rather than making a spec up front, you could just accept applications and changes that you like AFTER they are implemented. Big companies do this all the time in packages ranging from a logo contest, to buying startups and competitors.
These options become important if you care about time to delivery. My neighbor used to say when I started out on a run “if you had started earlier, you wouldn't have to run as fast.” Writing a specification is a huge source of delays, because it prevents you from getting started. Much of the delay in delivering software actually comes at the beginning, the “fuzzy front end” before you even start.
I recommend that if you care about time to delivery, you should never buy anything fixed price. What I am really saying is that you should never stop and argue over a fixed-price specification, because that costs a lot of time. It's a tradeoff.
Scalability is another issue. I find that product management is not a very scalable process. It often comes back to one person considering all of the alternatives. You might not be helping yourself in a big project by increasing your reliance on a non-scalable process. Now, software development is also famously not scalable, so maybe it doesn't help to put development in before product management, but at least it is an option.