As a project manager, I rank a C+ at best. That’s why I work in sales where the damage I can do is more limited. However, where I differ from a lot of not-very-good project managers is that I know exactly how bad I am and am happy to share my hard won experience with you all. Lucky old you, eh?
The topic for today is the most-asked question in agencies up and down the land: Why is my project over-running and what can I do about it? (It’s kind of a companion piece to Andy’s previous post “How do I know my developers are on track?”)
One of the reasons why this question is so often asked is that it is a defining feature of so many digital projects. Managing overrun is often one of the key tasks of any senior management team within an agency. This blog post is an not an attempt to exhaustively catalogue all the reasons why it happens. Instead I thought it’d be useful to discuss some of the less discussed reasons.
Let’s start with an easy one:
The estimate wasn’t an estimate
There are as many ways to generate an estimate as there are uses for that estimate. All bodies will develop their own idiosyncratic approach and – fun! – multiple approaches to estimation can also exist within an organisation at one time.
This tendency often leads to confusion or amnesia about what the estimate was for in the first place. Two extreme examples here are an internal estimate of developer effort and an estimate of price meant for an external, customer audience. The developers might estimate, say, a 6 week build for a given feature At the same time, for reasons of political expediency, you might only want to charge for 4 of those.
There’s nothing necessarily wrong or even surprising about a calculation like that, but it’s vitally important that you have the organisational memory to remember that the devs need 6 weeks in the resource planning and reporting areas of your business. In a month’s time when you’re looking back on the project and reporting its profit/loss, what tools are available for you to track this information beyond your fallible, over-worked brain?
How much are you losing to churn?
There are countless posts on the damaging effect that context-switching can have on a development team. If you’re delivering work into a team of generalist developers who are having to switch from one project to another over the course of a day, then you’re going to be having an impact on productivity from the get go. I can think of countless examples from my day to day life where an hour of timesheeted development somehow managed to cost a whole day of my precious budget.
So we all instinctively know this – but what I see agencies do again and again is both fail to develop tools and processes to compensate for this tendency *or* build any of this into planning. Spending time and resource developing ways to automate the build/deploy process, for example, can save a ton of tooth-grinding right at the most stressful moment of the ‘task-switching’ process.
The only other solution is to plan projects sensitively enough that the plans take into account the workload of other projects and/or assign an amount of ‘dead time’ to a developer on the assumption that they’re going to be doing nothing profitable for a proportion of the project.
From a commercial point of view, this is a more or less indefensible position. From a practical point of view it borders on the hilariously implausible. (Show me an agency with a resource planning horizon of more than 4 weeks and I will show you the authors of the greatest work of fiction the world has ever seen.)
And speaking of which…
Your developers have an outside-context problem?
This is really common across the industry but is particularly true where you’ve got a team of middle-weight generalists – which is where dev teams in marcoms agencies naturally tend to gravitate.
The problem goes like this: The client asks for something new. You’ve never built it before but you’ve built something like it. The team diligently estimate the project based on the thing you’ve built before and everything is going fine until, suddenly, horribly, it isn’t. The differences that seemed so small from a distance are, up close, suddenly yawning and irreconcilable. This thing isn’t like the other thing at all. This thing is like nothing the team have seen before. It’s an outside context problem; outside the context of the team to estimate, deliver or support.
And now, not only are your estimates wrong, but you’re two thirds of the way through the budget and three quarters of the way through the allotted time.
There are a number of related issues here – and they really need to be unpicked in a longer post – but briefly it can be incredibly difficult to spot these things before you’re in their grip.
The short-term obvious preventative here is to review progress against budgets religiously and provide your teams with enough space and time to estimate properly in the first place, however there is a more long term and harder to spot solution too.
You need to foster an internal atmosphere where teams can feel both empowered enough to speak up when things are going wrong and can be sensitive enough to human weakness to know when “I don’t know how to estimate this” is the only correct answer.
In my experience, even senior devs can have a tendency to nail themselves to the crosses they manufacture in the project initiation stages. (I’ve seen management help make these crosses too.) In a healthy company there should be no need for this.
Get help
Watch now, reader, as I pivot effortlessly into an advert for my company’s services here: Mid-sized, mid-weight dev teams are, by their nature, prone to making the kinds of mistakes outlined above; it’s the downside of fast-moving, flexible team.
As a software agency rapidly approaching 20 years age, we have seen pretty much all the ways that a digital project can go wrong and we’re happy to use this knowledge to help make sure that yours don’t. Our team of developers and project managers is experienced and mature enough to be able to give accurate, actionable advice that will be good for the duration of the project.
If you want to give us pop along to our contact page.
