Or perhaps this article should be called: 5 pitfalls that can happen when EVM is not implemented the way it should be!
Here are 5 things that can go wrong when an organisation chooses to implement Earned Value Management as a way of working for project performance tracking.
1. There is low organisational support
Possibly: there is no organisational support outside of the PMO. EVM is very much an enterprise-type solution so everyone needs to be on board. The whole organisation needs to know what it means for them as individuals and as a team – and you should try to bust the myth that it’s all complicated maths.
In reality, most of the tools now do all the heavy lifting for you, so there’s no need to be hands on with the maths. However, the project delivery teams are going to need to understand the inputs and outputs to the formulas so they can interpret what the numbers are saying. That’s the secret: it’s making sure the wider team understands that the move to EVM is all about creating a set of essential measures to track performance and improve project control.
2. Thinking of EVM data as the answer
EVM data is simply a representation of current project performance. It’s not a decision in itself. It’s not a set-in-stone forecast that tells you what is definitely going to happen.
The team can still adapt and change, mixing up what they do to shape future performance, preferably in a positive way. The data should be seen as decision support information, helping the team make the right choices about what to do next in order to get the best results for the project.
3. There are poor or no decision-making processes
Pitfall #2 brings us on to this one: EVM implementations struggle when the organisation has poor (or no) decision-making processes. There should be some way of managing decisions as part of project control. Decisions and management responses to situations should be structured and repeatable, not knee-jerk. Proactive action taking is better than reactive ‘let’s just do something and cross our fingers’ type decisions.
EVM data is good, and helpful, and informative but if the project leadership team don’t have the power or ability to do anything with it, then the data is just a set of pretty reports no one ever looks at. Decision makers should be looking for patterns, documenting decisions made and their outcomes so that future decisions can be shaped by today’s lessons learned and building credibility by using the information to improve project performance in meaningful, predictable ways.
4. Limiting EVM to a small group
When EVM is implemented, we talk about it being a whole enterprise thing, and that everyone needs to understand what it is and the value it brings to the organisation (as discussed in Pitfall #1 above). But making it ‘a whole enterprise thing’ actually goes far wider than a communication campaign.
When EVM is implemented, it’s important that the whole team is able to see, input, act on and engage with EVM numbers. They should be responsible for their part of the system. In other words, it’s not a good idea to limit the people with hands on experience to a small sub-group of project practitioners in the organisation. It’s ineffective to ask project managers to provide time sheet information, for example, to the gatekeepers who then load it into the system and provide monthly reports in PDF format.
That leads to a couple of problems. Practitioners feels like they aren’t truly included in the EVM and will probably disengage from it. For them, it becomes one more set of data points to submit to someone else for reporting; something that happens outside of their sphere of influence (or interest). It also creates a culture of auditing, where individuals feel that their work is dissected by people who lack hands on experience. EVM shouldn’t turn out to be a ‘them’ and ‘us’ experience in practice. For best results, it really does need to be a whole team process with plenty of input from everyone. Basically, it needs to become ‘how we do business round here’.
5. Not creating a common vocabulary
Of all the various aspects of project management that require specialist jargon, is EVM the worst? I think it could be. There are all the acronyms (PV, EV, SPI, etc) and formulas. There are control accounts and control account managers (which must make control accounts very important if they have their own managers), plus the terminology that goes along with the WBS.
The benefit of all this jargon is that when it is understood by everyone, it provides a common and clear way of talking about the same things. You avoid the misunderstanding of schedule vs plan, for example, because there is a common language with terminology that means the same thing to everyone. That’s powerful. It’s also good for decision making because clarity of understanding helps execs make the right call.
Next month I’ll be looking at a few more pitfalls from EVM implementations that are not done in the best possible way, but meanwhile I’m interested in your views. What have you seen go wrong with EVM rollouts in the organisations where you have worked? Let us know in the comments!
