Good Project Management controls cost and waterfall techniques give the best cost control – or that’s accepted wisdom.
Is that really true? – does a linear development process as opposed to an iterative one#1 really give you better cost control?
My experience is that it can cost you dearly.
The project can come in on time and on budget but the big question that every business lives or dies by is “are my customers happy with the outcome?”.
Here is where I think the right first time waterfall starts to creak.
Let’s take an example that I know well – a software development project.#2
1stly – Suppose your analyst perfectly transcribes the client’s wishes.
Just set aside the enormity of that statement and what it implies for a moment and lets consider the client. It’s not their field so they are employing you because you are the experts in this endeavour.
2ndly – So let’s also assume that the client understands their requirements perfectly.
So the perfect analyst takes the perfectly articulated requirements and produces a specification.
The client then reviews the specification and corrects any errors because the specification has been written so that they understand every nuance of the analyst and how that will translate into code.
3rdly – So now let’s assume we have a perfect specification.
The analyst hands the now perfect specification to a programmer who perfectly translates the specification into code.
4thly – so now let’s assume we have a perfectly coded solution to the problem.
We then hand over the finished code to our customer along with the invoice.
Now everyone is happy right – err – what do you mean you can’t use it and aren’t going to pay?
So the account manager sits down with the client and starts the discussion.
“Can we agree that the analyst performed his role perfectly?” – “Yep”
“The specification was perfect wasn’t it?” – “at that time – yep”
“The product matched the specification perfectly didn’t it?” – “yep”
“So what’s wrong?” –
“Life moved on, by looking at the processes we realised we were making an error that was costing us money. We’re glad you helped us to see it but surprised you didn’t spot it yourself and recode accordingly! It was obvious from the spec after all.”
It’s about this time that you realise that you need to change the code and the discussion of who pays is weighing on everyone’s minds.
Even in this perfect scenario time moves on and business doesn’t stand still.
As in Alfred Bester’s thought-provoking short story Time is the Traitor and there is no turning back the clock.
Of course there is no such thing as a perfect spec – ever. (Ok I did think I wrote one once but then I woke up because the alarm was going).
If the client is expecting a development cycle where they view an Alpha version, test a beta( and perhaps gamma version) before moving to a production version and understands the cost of each part of the cycle this would be picked up and they would be more willing to compromise on unwanted features, bells and whistles to keep costs down.
After all an iterative development system is a series of linear projects where the output of the last development feeds the input of the next.
Looking at a software development as a learning process for both the customer and supplier might be contentious but most software projects are often undertaken with the idea of improving systems and generating cost efficiencies.
Failing to realise that analysis of a system often exposes faults or causes change in the system is a rookie mistake. After all Physicists have known this for some time.
So my experience is that Whatever I’m doing for a customer – be it a few lines of code to a complete website or a custom deployment, assume at least an Alpha->, Beta -> production cycle – cost accordingly and give the customer the MAXIMUM they will pay together with a likely cost.
Generally people are happy if a project comes in under cost (although not always the case – for example in places where an underspend is considered bad budget forecasting and penalised).
With programmers taught linear analysis techniques because coding is a linear exercise it’s understandable that people cling to the waterfall method – however I hope everyone reading this at least seriously considers Agile or another cyclic method.
#1 It’s contentious wether Agile software development and project management are separate or if one is merely a specialised instance of the other. I’ll leave you to make up your own mind.
#2 It could be argued that sometimes this approach isn’t feasible – for example brain surgery. I agree entirely. One might say that’s why I choose not to work in those areas, however I would like to think that any technique had been thoroughly practised somehow before it’s tried on a patient.