Project Accounting and Development Methodologies

While reading one of Craig’s recent posts, I couldn’t help but think about how differently labor has been accounted for on the different projects I’ve been involved with over my career.  Line items such as license fees and server hardware are usually easily attributed to the project budget, but once you get down to the activities of the BA and the PM, things become a bit more fuzzy.

My very first project, all hours  were counted in the deferred pool. This project was a multi-year, global project with the goal of modernizing the processes and systems of the service division of a Fortune 300 company. At one point, we counted over 75 people working on the project full time and more than 100 more working part time. The daily burn rate for that project was staggering, especially when you consider this project went on for over 3 years before the first phase was implemented and almost 8 years before it was completed. Just over half of the full time resources were contract labor through some of the most expensive consulting firms in the business.

Even though this project was insanely expensive, because all the hours were accounted for as capital / deferred, the project looked to be incredibly worthwhile for the company as it was building a very large asset in a standardized process and system. The goal was for all customers on the planet to have the exact same experience regardless of where they happened to be on the globe.

But everything, and I do mean everything, was classified as a capital expenditure. It didn’t matter if we traveled to train other project members in a different country, if we purchased a new server or if we were paying consultants, it was capital. Regardless of the task, be it planning, executing, developing, testing, training or support, it all went to capital. My salary (and funny enough, my education reimbursement for my MBA) all ended up as project expenditures. I once joked that if a problem came up, the program managers wrote blank checks to fix it. Money was no object and cash flowed freely.

Contrast that with another project I was on a few years back, where the PMO, in concert with the Finance budgeting department, became extremely rigid regarding which project activities became capitalized and which did not. Support activities, rightly so, were not capitalized, nor were project status meetings. Design and development were capitalized, but not all analyst activities met the capitalization threshold. As I was acting as a pure BA at that time, any of my time that went into what would be considered ‘design’ activities were capitalizable, but 'analysis’ tasks were not.

This put me in a quandary when it came to reporting my hours. If I created a mockup early on in the requirements elicitation process, did that count as deferable or not? The mockups were created to help our business area to understand what was possible to do, not what we would do. Our PMO had stated that tasks to define 'what’ were not to be included in the capital budget, but the 'how’ tasks were to be included. These mockups would eventually become the backbone of the 'what’ but only months down the line. At the time when I was creating them I spent a couple days effort on them and I had no idea if they would ever be used again or not. Do I take a chance and defer the hours as I think they will be used or do I forgo those hours and just classify them as an expense?

Working months in advance, you can see I was working a traditional waterfall project. One of the things about a waterfall project is that most of the tasks can be easily classified as either expense or capital just by looking at the phase of the project and the job role of the resource. There are exceptions to this, as I found out with my mockups, but generally it is a very easy line to draw.

Generally, the finance department prefers easily drawn lines such as this. The less ambiguity in the task, then the easier it is for them to defend the classification if the company is audited.

What got me thinking about this subject is how much more difficult I believe it could be to do this type of task accounting in an agile environment. When the sprints go by so fast and the tasks are broken down into such small intervals, that spreads out the hours spent doing each phase across the whole of the project. Instead of nice, neat little buckets as are found in a more traditional waterfall project, you create a financial hodgepodge of time slices.

If the project is more like my first project example, then it really doesn’t matter to the finance group what tasks are performed when because its all like a big chicken pot pie, where all the ingredients are mixed together to form the project. But in project where resources routinely flip back and forth between deferred and non-deferred tasks, this accounting becomes significantly more difficult. It is easy for finance to log that all hours between February and June are allocated to capital expenditures for resources working on a specific project. Compare that with saying that from January to December, each resource spent between 5 and 40 hours per week on different capital tasks is a lot more work to move around in the general ledger.

All that said, finance is there to account for these expenditures, but when the finance team doesn’t have the staff to track and classify the expenditures, they will likely push back on any methodology that makes it more difficult on them to do their job (and rightly so). The best thing we can do for our finance friends is to have a system to properly track and categorize our planned tasks, so that each month they receive a nicely formatted report that lists hours into expense and capital buckets. By doing this, we free ourselves to ensure that our methodology is right for the project and not be limited by what can be supported by the finance team.