Whenever you are faced with a knowledge gap, education is the best chance you have. I have tried sending people case studies and examples to show why do so many software project fail and talk about the top 10 risks of software development. But this does not seem to change things.
In this article, I am going to present three techniques that I have used to help coach people out of this mindset. And when these three techniques are used together, you can usually convince people not to use waterfall. It is soooo important to manage expectations and get this right.
Trade off sliders
Trade off sliders are a great way to help prioritise what is the most important thing. They can be used for anything where you need to have hard discussions and trade offs between priorities. They are pretty simple to understand.
Simply draw a table with rows and columns. In the rows put the items that you need to prioritise and in the columns use some words that indicate importance. In the example below, the trade-offs are time, scope and quality. The importance range from fixed to flexible. Now ask the participants to put a mark in each row but you are not allowed to have two marks in any column.
When you do this activity, it is the difference between time and scope that you are interested in. It is good to have quality in the mix as it helps to talk about testing as often as possible when building software.
If time is a priority over scope (fixed time with flexible scope), it is much easier to estimate costs as the length of the project is known. But it is harder to say how much of the project will be completed because the scope is flexible.
If scope is a priority over time (flexible time with a fixed scope), it is harder to estimate costs as the length of the project is flexible. But it is easier to say how much of the project will be completed because the scope is fixed. In this arrangement, the costs are inevitably a lot higher than fixed time and any variations to the scope must be systematically recorded and approved as scope changes will have an impact on time. This is scenario is sounding very waterfall.
Hopefully at this point you can visualise the difference between the these two arrangements. If a participant chooses a fixed scope with flexible time (or is hell bent on a fixed time and fixed scope), you can move onto the cone of uncertainty.
Cone of uncertainty
The cone of uncertainty has been used widely over the years. All the way from weather forecasting to NASA’s software engineering lab. One of the great things about the cone of uncertainty is that it recognises something that we have all felt, the further into the future we try to predict, the worse at it we are. Basically, the unknown unknowns build up over time. Another great thing is that it is visual.
Take your time to discuss the cone of uncertainty with the person how are trying to convince not to use waterfall. Once they have a grip of the concept move the discussion back to the trade-off sliders.
For a fixed time (flexible scope) option, you can place a mark on the x-axis of the cone to show where time could land. Let’s say the project is 12 weeks long in this example. Now, for a fixed scope (flexible time) option, place a mark on the cone directly above the fixed time mark. This difference can be as much as +20%, +60%, and even more!
Finally, it’s time to show the numbers. For simplicity, let’s say the project costs are $10k per week. The 2 options are:
- 12 weeks @ $10k is $120k fixed time.
- 19 weeks @ $10k is $190k fixed scope (where the cone of uncertainty is plus 60%).
Then offer 2 scenarios:
Scenario 1: Would you like to use fixed time with a project cost of $120k and we build as much as e can from a backlog that you can prioritise. You will more than likely get all the must have’s and should have’s completed delivering value to your customers. In this arrangement you are free to change scope as you seek out user feedback to build a great product.
Scenario 2: Would you like to use fixed scope with a project cost of $190k and we stick to the scope of requirements without any variations. If a variation does come in, we will provide another quote for this extra work. In this arrangement you will be less likely to manoeuvre to user feedback and build a great product as you are locked into a waterfall approach.
At this point, people are usually coming around as a $70k difference can hit the back pocket and they ask themselves the hard question, do I really need that little extra bell and whistle that I don’t really know will move the needle on creating happy users.
Legal contracts
There is one last piece of advice that I would recommend that really drives this home. If you are putting together a business case, a contract, or anything where someone else is going to sign off the project, you should include an option where they can choose which of time and scope they want to fix.
Literally, put it on the front page of the contract with both prices you have calculated in the scenarios described above. They would then need to circle or select the option they are after.
I have found this to be an excellent approach for several reasons. Firstly, you are giving the person control to make a decision and they have influence over the project. Secondly, it sets the stage for how the project will be rolled out and whenever hard discussions come up, you can always refer back to the original signature. Thirdly, it ensures that the person has been educated and is making an informed decision. People won’t sign something until they know the implications and having the choice right next to the signature makes sure no one has buried their head in the sand.
Summary
No doubt, on your quest to build an amazing product, you will come across some people stuck in a waterfall mindset. They want to know exactly how long this is going to take and how much it will cost. Coaching people around this mindset is very important.
In this article, three tools were presented and when used in combination, can be a very handy approach to managing expectations.
Start our with the trade-off sliders to work out what is the most important to them. Follow this up with the cone of uncertainty to talk about the risks of software and trying to predict the future. Finally, give them the control and allow them to make a choice about the type of project they are comfortable with.
Finally, if after all this effort they are still chasing a fixed scope. The best thing to do (if you must proceed with the contract) is to make the project as small as possible and ensure that change requests are tightly managed.
Written by Eban Escott
Founder of Codebots
Dr Eban Escott received his Doctorate from UQ (2013) in Model-Driven Engineering and his Masters from QUT (2004) in Artificial Intelligence. He is an advocate of using models as first class artefacts in software engineering and creating not just technologies, but methodologies that enhance the quality of life for software engineers.
