Agile, Risk Reversal and Software Engineering
In programming though, what is the right way to handle development risk?
At one extreme is Agile development. The basic premise of Agile is "we're smart and hard working - ask us for no estimates and we'll tell you no lies"! In Agile, ALL of the risk is on the client. They pay for hours, you do what you can within the best of your professional abilities and they get whatever they get and still have to pay you for your time. Because both the client and the developer can focus completely on getting the best application within the time available, instead of wasting time developing detailed written specifications and quotations, you can just build and then iterate. The first round often raises issues that would have been hidden in a printed spec and you usually end up with a much more usable app (although you may well end up with less feature points or a bigger cost - most people underestimate the complexity of what they're trying to do). I think Agile is ideal from a production standpoint, but from a sales standpoint, I don't think it is very good at all. The basic principle of "give me money for being here and breathing, and you may get something eventually" isn't a terribly easy sell.
At the other extreme is a fixed bid, fixed scope, fixed timeframe project where you gather requirements (ideally properly in a paid discovery phase, but often for smaller clients in a couple of informal meetings as part of working up a free quotation). You then guestimate a price point that'll hit the function points within the clients likely budget and then try to figure out how to do the least work to deliver something that meets the original quote irrespective of whether it meets the clients needs. When you describe it this way, it doesn't sound terribly appealing, but it's actually a much easier sale as the client says I want a, b, and c and you guarantee to give them what they asked for for a fixed price in a fixed timeframe - it's like all their Christmases came at once.
"But how can you give me a fixed price for a project when the other developer was only able to provide me with an estimate?" asks the (all too rare) suspicious client. "Ahhh" you reply. "When I started, I was also unable to give a fixed bid because I didn't have enough experience, but now that I've developed hundreds of web applications I know what it will take to deliver the system you need." It's a lie, but a simple and seductive one, and what has the client got to lose - you're supposed to be the one taking all the risk. So, another deal is concluded, a downpayment made, and by the time the client finds out the potential pitfalls of a fixed bid project, they're too emotionally invested both financially and in terms of their reputation (they can't admit to the rest of the team that they made a bad vendor selection) so they work with you to get something up and to move onto something else.
Of course, fixed bid projects don't ALWAYS go wrong. The smaller they are and the better the client is at expressing their actual needs (or the more flexible they are in terms of the deliverables), the more likely they are to work out well. We do a fair number of fixed bid projects and the vast majority of the time we give clients what they want and need and do so within budget and timeframe. We have also created many tools for generating code and facilitating reuse of functionality which allow us to make more changes than most while still not breaking the budget.
Of course, the dark side of fixed bid/fixed scope/fixed timeframe budgets comes some times and then it becomes a real issue. How do you handle dark matter (things that weren't mentioned in the spec at all)? What do you do with the client who wants to ask lots of questions about every detail? How many revisions do you allow? Is ANY implementation within spec acceptable, or did you agree to keep changing the implementation until they love it?
The challenge is that the approaches that allow for mitigation of development risk (a thorough, hourly, paid discovery phase, prototyping, wireframing, and an agile approach) don't make sense to clients who haven't figured out that they didn't have a problem last time because they used a bad developer, but they had a problem because either they used a bad process or perhaps (shock horror) because they're a bad client!
How do you help your clients to mitigate their risks when developing software?
Agile processes have all the same activities as waterfall processes (requirements gathering, design, coding, testing) but they are organized in different way. Rather than doing all the requirements gathering up front and doing the testing last, we go through repeated cycles of all these tasks.
Estimation plays an important role in agile processes: clients generate a list of requirements (stories, etc.) -- estimates are worked up for the requirements, and are used to decide which requirements are going to be addressed in the next (and future) iterations. Even though the focus is on the current iteration, it's always possible to project to later iteration to get an idea of where the project is going. Real experience in earlier iterations helps produce better estimates for later iterations: estimations can be more accurate in an agile process than in many traditional processes.
Agile can reduce risk for a client: clients have better visibility -- they are aware of what's going wrong or right -- they can make the decision to pull the plug or change direction. This will be appreciated more by clients with a lot of technical sophistication (who can complete development or move it to another shop) and less by people who are intimidated by computers.
It seems to me that we need some model that's in between fixed price and time and materials. As you point out, fixed price projects don't give clients the incentive to control the budget -- some clients will really take advantage of this.
Some great points - thanks for the comment. I certainly agree that Agile can provide a client better visibility than a BDUF where you don't know how much trouble you are in until one week before launch when the tech team come calling. That said, if I go to you and say "I will complete these stories for $15k" and someone else says "I think it'll take about $15k to implement these stories as per your description", someone not familiar with programming is going to perceive a lower risk in a fixed bid than in an estimate. If I tell you dinner WILL be $200 or dinner should be around $200, it would be reasonable to expect the first statement to be less risky. In fact, in the first statement, I am simply saying that providing you have three friends, all take the tasting menu and all drink a single bottle of house wine between you, it'll run $200. However, the simplified perception used to make the decision by the naive decision maker is that the first has less risk, when in fact it simply has more assumptions.