The traditional way to track a project budget (which is to say, the way I learnt to do it first) is to track the time people spend on the project each day and add it up. I call this bottom-up budget tracking. Agile forces an alternative approach, which I call top-down. I was involved in a very happy example of this last week. Let’s talk first about how it works, then my experience this week, and finally a bit of a discussion.

The top-down approach simply requires you to cost your unit of measurement (ideal days, points, notional units of time, whatever) and then allows you to cost any any arbitrary grouping of functionality. Specifically, if your whole project costs C, and you’re on track to deliver W units of work, then one unit of work costs C/W. And if your sub-project totals P units of work then it will have cost you P * C/W.

The happy example I was involved in occurred when someone in our company unexpectedly decided we should know the cost of a particular subsection of our on-going redesign. It was 10 minutes’ work to find the stories which related to that work and convert story units into money. It was 20 minutes to explain to the visiting man-with-a-notebook how the numbers were derived, and the caveats.

In this particular case there were two caveats. One was that some planning and production work had taken place out of the scope of our project, so I couldn’t cost it. My man-with-a-notebook was fine with that because he already knew it was a cross-business piece of work and was already due to meet people in the other areas. The other caveat was that we were building on top of a large CMS, which clearly contributed to the value of the subsection he was interested in, but from which no cost could be reasonably apportioned. Again, he was fine with this because it was quite clear that the core CMS was built specifically for the main project while the additions we were discussing were very clearly for the subsection he was looking at. In the end he was just happy to have a clear financial figure.

The whole top-down approach is entirely dependent on the fact that your project is constantly delivering tangible features. This works on an Agile project because within each story you’ve bound up the analysis, architecture, development, QA and release. So the cost of each unit really does include everything. This doesn’t work for a waterfall-style project because although you may have only spent five days coding a particular feature, that also builds on some of your three weeks’ database schema design and implementation, some of your six weeks’ analysis time, some of your eight weeks’ testing time, and you almost certainly don’t have enough time tracking data to apportion the time correctly. But unlike the CMS in the example above you cannot reconcile the cost of the schema, analysis, etc to anything else because those things have no value or function without the delivery of the particular feature.

Naturally, though, there are pros and cons to the top-down approach.

The pros include the fact that it’s relatively easy to calculate. You may want to keep a running tally of how much a story unit costs — there will be good weeks and bad weeks — but overall it’s fairly straightforward, and you can do away with an awful lot of low-level accounting headaches.

Another benefit is that you can pull out any arbitrary group of stories and find their cost, as we’ve just seen.

A third benefit is that you know your numbers will add up: 100% of features delivered in the time will add up to 100% of your budget.

One of the major negatives I’ve found is in comparing it to the bottom-up approach. I remember a particular meeting with one project manager who was accounting bottom-up. His project intersected with an Agile one and he had been tasked with reporting on a particular cost, part of which was in the Agile project. As ever the bottom-up project manager had been asked for this report out of the blue. He met with the top-down, Agile project manager and me to get his data.

The top-down project manager wrote out a very simple calculation: the relevant work was, let us say, 3% of his overall project and the cost was therefore £24,500. However, the bottom-up project manager wasn’t comfortable with that: he wanted details. How much of that was PCs? How much software licences? How much time from developers? Consultants? Analysts…? There was some discussion, but there was no more detail to be had: the total project was £815,000, this was 3%, so the cost was £24,500. The top-down project manager explained his decision to keep administration to a minimum, explained again the cost structure of his project, and that’s all there was to it.

You can imagine the frustration felt there. The bottom-up project manager wanted to see the detail behind the cost, and he wasn’t comfortable with what he got. The detail he got was, “We delivered feature A for this much, feature B for this much, and feature C for this much.” The detail he wanted was names, hours, and asset numbers. The bottom-up project manager went away with concrete numbers but was dissatisfied, and I do wonder if he suspected his top-down colleague of financial recklessness. There were no repercussions from this, by the way. The financial report was submitted, accepted, and no more was heard. Nevertheless I would have liked a happier conversation.

Meanwhile the top-down project manager continued to report regularly to his project stakeholders, and that report naturally included budget status. The stakeholders were busy, senior people, who didn’t have the time or the desire to drill down into names, hours and asset numbers. For them a report saying that 42% of the functionality has been delivered with 45% of the budget was meaningful. They would query the big things, and the project manager needed to have detailed answers. A lightweight top-down approach allowed him to focus on those issues, and not get too distracted.

The names, hours and asset numbers are only enabling details, they are not ends in themselves. If they can possibly be avoided to focus on the more meaningful features then that’s a very good thing.