The waterfall model for software development has gone the way of the dodo (and did so at about the same time). Yet this newly minted indie developer often gets requests for proposals that follow this model, fixed-time, fixed-process and fixed-price.
I instantly and politely decline these requests.
I don’t ever want to decline work, and when I set up this business, I planned to say yes to every potential client and service them as best as possible. Not only that, the only way to grow a consulting business is to actually bid and win business, not decline it. No engagements, no clients, no business, no money, obviously!
But I still decline requests for proposals on fixed-price, fixed-time, fixed-process based work. Several potential clients have been upset by the instant rejection and have asked why such a response.
Here’s why:
- At the time of proposal, neither the client nor I have a concept of the true scope of an engagement. How can one then present a proposal? (Actually, I used to do these back in 1993 as a pre-sales guy at a massive Systems Integration house.) Proposals at this stage usually mean setting the wrong expectations in client and developer, and lead to disagreements later when timing and costs blow out.
- Assuming there is sufficient information for me to scope out the job, experience has shown that estimation is hard and highly inaccurate. Rules of thumb regarding the doubling of time between each phase, or the use of function point analysis to measure scope, have all proven to be wrong. I do not want to set incorrect client expectations by responding with a project plan that I know is rubbish.
- At the request stage, neither party has an understanding of the language, tools, techniques and processes of the other. There are always communication breakdowns and misunderstandings that come when two people from different domains attempt to understand each other’s ideas and plans. Jargon, domain knowledge, assumptions and conventions differ between client and developer, and I prefer not to propose to do work until the language and true needs are understood by both of us.
- The waterfall model assumes no changes in scope and assumes no technical hitches and glitches along the way. In reality, as you drill on the scope and technology of a solution, and as your understanding of a problem domain grows, both the client’s needs and the amount of development work changes. Most fixed-price projects go off the rails because of disagreements over changes, both the work to be done and the cost to be paid. I will not go through that again, and will not put my clients through it either.
- A lot of these projects also involve a lot of design - graphic, thematic, flow and technical. Anyone who has done any of these knows its hard, iterative and variable. You may hit the design first time and just iterate on polishing it, or you may need to redesign several times before you find that which ‘just works’ for the client and the developer.
Instead
- Instead of writing requirements, I am happy and excited to spend time pro bono with a client to get to know them, their business and their needs. Through discussion, the client and I can come up with the scope of work, we can both understand the process to deliver and can come to an agreement on what needs to be done and paid.
- Part of my role is to also explain my process to them, why I use the process and the benefits of the process. When clients understand the hows and the whys of my delivery process, it makes it easier to come to agreements and launch engagements.
- Waterfall assumes vendor and customer relationship, an adversarial system. I work in collaboration with my client. Both of us are stakeholders, both of us want the same result (a great product at a fair price), both of us are learning as we go, and both of us understand and solve any issues as they come up.
- Instead of creating a fixed time project plan, the client and I agree on a series of small steps, deliverables and iterations. Sometimes a deliverable takes less time that we expect, sometimes longer, but progress can easily be measured as each part gets built and delivered.
- Since we work in collaboration, changes in scope can be implemented on the fly. We can add or change deliverables, iterations, even functionality as needed and still stay on track to deliver the final product.
- And when things do not go according to plan, like when the art is not right, or a function or feature just does not work, we can choose to refocus our energies to get the missing piece done, or replace it with something that does actually work. And do so quickly.
The only question that comes up, then, is how can the client be sure, given the iterative and open-ended nature of the engagement, that they will end up with the product they expect, in the timeframe they need, at a reasonable price (the implied goal of the waterfall model).
The answers, my friends, are these.
- The client will not get the product they expect, they will get a better one! As we both learn, our expectations will change and we will collaborate on and produce a much better product, more aligned to the client’s needs.
- The client will not get it in the timeframe they need, they will get in the timeframe its needed in! Experience and a history of successful projects has shown that the client will get the product sooner when collaborating well and following a flexible process. And client’s always adjust the timeframe as their understanding of the product changes.
- The client will not get it at a reasonable price, the will get it at a better price! A large part of the expense of waterfall is in all the documentation (a known cost), in changes (an unknown cost) and management overhead. Collaborating using a flexible process means we can start creating sooner, deliver sooner and manage the client’s project budget better.
I do not expect to stop receiving requests for fixed-price, fixed-process and fixed-time project proposals, nor do I expect to ever accept and respond to any.
I do hope to receive more interest from clients intent on collaborating to produce great software, software that we can both be proud of, and can enjoy working on creating and delivering it.