Tips for managing technical people: Beware large numbers
11 November 2014, by Zoe Cunningham
The following is an excerpt from my new book, “Galvanizing the Geeks – Tips for Managing Technical People”. You can buy the full book on my website, here.
Why people underestimate
The single most common cause of failure for software projects is misalignment between the time that the project is expected to take to develop and the amount of time that it actually takes. There’s a good reason why estimating is known as ‘the black art’. Assuming that you’re far enough down the line not to be estimating against tasks that bear little resemblance to those that you’ll eventually undertake, there are two main ways in which your estimates can be horribly, horribly out.
Firstly, single tasks may overrun by hundreds of percent. The coarser-grained your estimate is, the more likely this is to happen. I’ve found that tasks that are in the order of a day or two are easiest to estimate. It is too easy to underestimate the size of a ‘large’ task; there are very few tasks that don’t feel like they will fit inside a 20-day estimate – that is, until you break them down. Even a task of five days is likely to be concealing hidden gotchas, simply because, to get a five-day estimate, you don’t need to know exactly what you’ll be doing on each day. So Rule One of estimating is to break down large estimates into smaller ones.
The second most common cause of overrun is The Missing Task. You can have a whole spreadsheet of perfectly estimated line items, but, if there is just one task that isn’t on there, your project will slip by the amount of that task. To help avoid such omissions, it can be useful to have a standard set of tasks that you always estimate (or explicitly omit) for every project – and to make sure you think carefully about what exactly needs to be done. Estimating in small numbers, as described above, can help in dealing with omissions that may or may not have been included as part of a line item.
It’s hard for anyone to assume that there are tasks hidden within a single day estimate – but however thorough your process and however rigorous your analysis, you will still miss some tasks. It is inevitable. So you need to leave some contingency, preferably just by adding a big fat contingency task as a new line item. Without any contingency, you are guaranteed to fail.
Why scope changes
Even if you have estimated as well as you can, there remains a third common cause of overrun that you will need to deal with throughout the project: changing requirements. Projects can be perfectly estimated and brilliantly executed, but, if they are creating the wrong things, they will be at best late and at worst canned. It is common in today’s software environment to have an explicit, often non-technical, owner of the scope and output of the project. This person is called a product owner. A good product owner is worth their weight in gold. It is not an easy job. All but the most trivial of projects have several stakeholders, all with competing interests, and managing these into a single output system is an extremely difficult task.
As the technical team, you unfortunately cannot assume that there is a great product owner available to you. Having a busy or overworked product owner – or, worse, no product owner at all – is a gigantic risk to your project. And you don’t have the luxury of throwing up your hands and claiming that it was someone else’s problem: if the requirements are not looked after the software output will be poor, and the software output is your responsibility. If it’s not up to scratch, there’s no way for you to dodge the blame.
You will need a strategy for taking on the product owner role. If you have qualified (and brave) members of your team available, you can create a ‘shadow’ product owner. If not, you’ll need every developer to do their part in keeping the scope of the project under control.
Invest in estimation
A particularly sharp incentive for getting estimating right is to work on a fixed price basis. Then if you fail in your estimating, your developers go hungry (or least bonus-less). This doesn’t work so well if your client is part of the same organisation and it may be tempting to allow yourselves to get away with being poor at estimating; there are almost always excuses that can be invoked if a specific project fails. But each time you do this you are eroding trust with the business – which will only damage your ability to do your job in the long run. Investing in estimating will help you build the openness and trust you need to be able to get on with delivering to the best of your ability.