We’ve talked about how hard it is to estimate a software project on this blog before and – no doubt – we’ll talk about it again. Estimation is, after all, the fire in which all agencies are forged. In this post I want to talk about the other side of estimation: tracking the progress of the project against estimates. And not burndown charts; they’re only good if you’ve got good data. This is about generating good data. Then you can draw all the burndown charts you like.
All too often we find ourselves helping people who start our conversations with things like “It’s been ‘another two weeks’ for the last two months” or “I was sure we were on track until a fortnight before we were supposed to go live” or just simply “I don’t know when it’s going to end”
All of these are signs that progress tracking might not be up to snuff. And bad progress tracking is more than merely a frustration. More often than not it does serious damage to your relationship with the client, and over the long run it ruins the profitability of the agency. If a project is going wrong good progress tracking means you get early warning and hopefully it’ll give you the time to fix it.
So how do you get good tracking? We have a few pointers that have helped us out.
On ticket estimates: a third pass at estimation
Good estimates are hard, and hard is expensive.
Generally people we meet have a process that involves two goes at estimating. The first pass is done as part of the sales process, while the second happens during “Discovery” (or “Specification” or “Pre-sales” or whatever you call the process of nailing down the requirements). Up to this point it’s likely the customer’s not fully committed to the project and you’d struggle to get anyone to pay for three devs, a pm and a tester to sit in a room for two or three days to put together the estimates. Even though that’s what it actually takes.
Our advice? Instead of starting coding on day one, sit down with the entire team and break down your specification (whatever form it’s in) into tasks and subtasks in your ticketing system of choice and put a time estimate on each ticket. Also, mark these estimates with a confidence level. It’ll take a long time, but it’ll save you an age later, and crucially it’ll give you concrete numbers to track progress against as the project progresses. And those confidence scores will remind you when you’ve still got some hairy unknowns left to do.
“Done means done”
One of the tenets of Agile is done means done. But, a bit like Brexit means Brexit, what does that actually mean? If those tickets I described above are too big, or cover too many moving parts, then it becomes very hard to tell when they’re actually complete. And if it’s hard to tell when they’re complete, it’s going to be nigh on impossible to give an accurate idea of how much of the ticket is actually done. Make sure your tasks are small. Make sure they’re atomic. Make sure the acceptance criteria are concise and achievable. And encourage a culture of ticket completion.
A culture of openness and honesty
Talking about culture, let’s talk about openness and honesty.
Firstly, I know Hacker News and the like keep talking about “10x devs” and “ninjas” and “rockstars” and all that macho bullshit, but if your team has a culture where people can’t admit to being stuck then you’re never going to get an honest assessment of progress.
Secondly, make sure people are honest in their time recording (you do have a time recording system, don’t you?). Time sheets are boring and onerous and everyone hates them, but if you don’t have accurate time sheets then you literally have no clue what is going on. Put a time sheet system in place, make sure everyone uses it, and that they’re using it accurately. How you go about this is a challenge, but it’s one you’re going to have to overcome.
Take pleasure in mastery
Everyone wants to try the new shiny. But if every project is using a new CMS, a new framework or even a new language then estimates are going to be wrong, and people are going to genuinely struggle to know how close to completion they are. Specialise, get experience. Don’t reach for something new each time, however amazing that series of video tutorials made the thing look.
And I don’t mean this just for the developers, either. Project managers are just as susceptible to the new shiny. Decide on a process and tools. Master them. Take pleasure in it.
The MVP is not a myth
It’s your responsibility to get the shape of the project right. Make sure you tackle the biggest business benefits first. That way if the project goes adrift or the budget runs out there is a good chance that there’s some useful software.
And make sure you’ve got a plan B. If there are some genuinely scary parts to the project be honest with the customer about them and make sure that everyone’s signed up to a plan B if things don’t come off. Not every project deserves a formal risk register, but make sure you’ve got something in the back of your mind ready for if things don’t go as planned.
No silver bullets
Even if you do everything I outlined above there are still a million ways to lose track of a project. But… Each of them is incredibly valuable, and your projects will improve immeasurably if you can implement them.
