This article is a follow up to the introduction to Earned Value Management (EVM) that I posted earlier this month.
One of the problems with Earned Value Management is that it needs some adjustment to make it useful for smaller teams. These teams are facing a different sort of challenge than large companies, and need to adapt their project management tools to match.
The first tweak to EVM I recommend is to switching to using elapsed time to measure schedule variance. Schedule Variance is the difference between the time taken so far and the planned time for the output you have achieved. This is contrary to the advice generally given for EVM, which states that time should be measured in man hours (hours spent working).
Assuming your systems are sophisticated measuring man hours spent is a good idea because it allows for granular reporting of time spent, detailed cost allocation between projects, calculation of labour efficiency variances and enumeration of slack time and utilization rates.
However all of the above is overkill in a small team environment and not required for a simple application of EVM. In this case we are only interested in two things:
- Are we delivering benefits as fast as the plan says we should. (Because running out of cash is bad.)
- Can we predict when we will deliver.
Measuring elapsed time (the number of days between milestones) rather than hours spent working rolls up all the factors such as 'did we actually do any work this week' into our single schedule variance measure. In a small team that kind of problem tends to already be visible without any help from a spreadsheet, so it's best to concentrate the effort one level higher.
This method is particularly applicable to teams where the members are salaried. The number of hours worked is irrelevant to the cost of the results, so we shouldn't waste time measuring it (for this purpose).
We can go back to our example from the introduction to EVM and make this adjustment:
Our schedule variance is 20 hours (40-20) per bike shed. It's taking 2 times as long as we thought.
However because we were working longer hours than we expected we completed all of those 40 hours in 8 working days instead of the planned 5. Our revised schedule variance is 3 days (8-5). It's taking 1.6 times as long as we thought.
You can clearly see that some information has been lost here (how hard we are working). However we make the calculation rely on data that is much easier to obtain and retain the predictive power of calculating the schedule variance. By plotting this number periodically we will get a feel for how well the team can deliver on it's time estimates.
The second tweak is related to cost variance. Cost Variance is the difference between what you have spent and the planned expenditure for the output you have achieved.
For bigger teams this is useful to track because it allows for checking your efficiency levels and digging down into the reasons for not being as profitable as you think you could or should be.
However in smaller teams the more important factor is how the work that is being done is being turned into cash. A lack of cash flow in a large company means arranging a new loan, in a small company a liquidity crisis often means the end of the business.
How do we modify cost variance to illustrate our cash position on a project?
Instead of crediting ourselves with the value of the completed product, we can perform our comparisons against the cash received for the output. To illustrate this we can look once more at or example from the introduction to EVM:
Our cost variance is $240 ($440-$200) per bike shed. It's costing 2.4 times as much as we thought.
However completing the bike shed entitled us to a payment of $240. Our cash variance (impact on cash) is -$200, or 55% (0.55) of our requirement to break even.
Again we have lost information. We can no longer look at the useful efficiency figures normally embedded in cost variance. However what we have gained is a direct and graph-able insight into how cash in is being translated into cash out.
In my opinion EVM is as valuable for small teams as it is for large ones. A small scale, low overhead implementation will gradually give you a historical store of data that you can use for estimation and control. By cutting out the parts you don't need you can work on getting the most value for the smallest input, which should be the goal of any endeavor.