In Part 1 of this article I talked about two ways to measure discrete effort: percent complete and fixed formula. Today I’m going to share the other two options: weighted milestone and physical measurement.
As a recap, discrete effort is the name given to the work required for an activity that can be planned, measured and ends up with something specific as the output. If you are doing work that directly leads to the completion of a deliverable, that’s discrete effort.
There are different ways to measure this type of work in a project using earned value management, or even in projects that don’t apply EV measures but still need to track progress (like: all of them). I wouldn’t use discrete effort measurement techniques for every single task on every single project, but they are available to you if it makes sense to use them. This is the benefit of tailoring 😊
The first one to look at today is weighted milestone. This is similar to fixed formula in that the value is apportioned to the work as the activity progresses, but it’s based on milestones.
Divide the work package into measurable chunks that are attached to and end with milestones. For example, a work package might include a couple of weeks of design work before a document is created. There could be a milestone at the end of the last of a series of design workshops.
When those milestones are reached, the activity earns the progress based on whatever breakdown you have assigned to each milestone.
So how is this different to fixed formula? It’s different in that it suits longer term work packages. Fixed formula is best for short activities, those that don’t stretch over more than two reporting periods. Weighted milestone progress tracking is an option for when your work package runs longer than that.
Ideally, each milestone should be a tangible ‘thing’ as well: some kind of interim result.
Reporting works best when there is at least one milestone within each reporting period, otherwise you aren’t able to tell if work is on track as it won’t have moved since the last report. You don’t get credit for any deliverables leading up to milestones where the work isn’t completely finished. In other words, it’s the achievement of the milestone that triggers the tick in the box, not the progress against the tasks leading up to it.
You don’t have to equally split the work across the different milestones. The ‘weighted’ part of this way of measuring progress allows you to apportion value across all the milestones. Allocate the appropriate amount per milestone, but don’t worry about limiting yourself to a regular split if that doesn't work for you.
Physical measurement is a way of tracking progress for things that can be counted. If you are working on something that has a specific, tangible way of measuring in a physical way, then this is the option for you.
If you can measure it specifically in a real world way, then that becomes your measure. You should agree it in advance so everyone knows how the effort spent will be tracked and reported on.
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!
How to you predict what’s going to happen on your project, from the perspective of performance? The infographic below shows a few different metrics and performance measures that you can use to forecast future performance – helpful if you want to know what your project’s results might look like before the end of the project, so you can make better decisions about what to do and how to use your time and budget effectively.
For more information about estimate to complete, estimate at completion, variance at completion and to-complete performance index, you can have a look at the PMI guidance on EVM and the ANSI Standard. Regression analysis and throughput analysis are other methods you could use.
Infographics can only give a very headline view, so there’s a lot more to say about each of these! Which of these forecasting calculations do you use? Or do you forecast using something different?
How do you actually go about mitigating risk? We talk about the need to mitigate all the time, but what kinds of things can you do to ensure that risks really are managed appropriately and mitigated to avoid the impact you think might be on the horizon? In this video, I talk about 5 different things you can try to mitigate risks. They are simple and practical, and you can easily turn them into solid actions for your risk log.
If you want a couple of extra suggestions, and some more detail (or you just prefer to read rather than watch), then the original article that prompted this video is available here: 7 Ways to Mitigate Risk.
The UK Government’s Infrastructure and Projects Authority’s Cost Estimating guidance talks about 8 principles for best practice estimating when it comes to working out how much your project will cost. I’ve already written about front-end loading, and today I wanted to look at another one that is really helpful – even if you don’t do huge scale infrastructure projects (which admittedly, the guidance is aimed at).
Estimates should be ‘reviewed and assured’. This is something you can implement regardless of the size of project – as long as you have more than one person in the team who has an opinion about the estimate.
The guidance says:
“Cost estimates that are reviewed and assured appropriately will be improved and become more reliable, further driving project discipline.”
You might already be doing this informally: a quick check in a team meeting, for example: “Is everyone OK with that if I put it into the figures at £5k?” But making a review a formal part of your estimating will elevate your practice and hopefully create more robust budgets.
Here’s how to do it.
1. Make it clear you will be reviewing cost estimates
As a team, explicitly call out that there will be a review and assurance process in place. Make sure you know what that is, and when it will be used. For example, as you prepare documentation to get sign off to move the project into another phase, or during backlog grooming etc. The whole process needs to be designed to remove ambiguity, so consider outlining what the inputs and outputs of the process will be and what triggers need to be reached to kick off a review.
The IPA guidance doesn’t mandate a review process but does say people in the review and assurance roles should be independent and make sure the process is robust and followed. Document the process so everyone knows what is coming. Ideally, the review team should stay the same throughout the project to provide some continuity, and now is the perfect time to plan to make that happen, allocating resources who can follow the project through its lifecycle.
If there will be different types of reviews (or reviewers) for different things, make that clear.
2. Find standard methodologies to compare against
So you don’t have any data in house to act as your benchmark? You will, with time, if you start collecting it now. Alternatively, check in with your colleagues or see if there is any available industry benchmark data that will help you assure your in-house estimates.
3. Schedule reviews
The easiest way to review cost estimates is a simple peer review process. Get colleagues to review each other’s schedule estimates (as these translate into financial amounts if you are charging clients by the hour) and budget estimates where these are not based on formal supplier quotes.
Where your project warrants it, block out the time for formal reviews. Independent assurance is particularly useful when it’s timed to coincide with ‘big’ events on the project like the approval of a business case for the next phase, for example.
Make sure people know when the review is coming so they can prepare for it and resources can be available to run it. Plus, the actual process takes time and you’ll want to factor that in to your schedule so executives aren’t expecting work to continue during that time, prior to the review being signed off.
4. Act on the data
The thing with getting other experts to weigh in on how much things are going to cost is that often experts disagree. That gives you, as the project manager, a role to play in making sure that any potential conflict is addressed and dealt with professionally, without it causing fireworks in the team.
Another time to act on the data is before the project moves into the next stage, whatever that might be in your process. If the estimates have changed or need to be refreshed, this is the time to do it. It’s fine that the figures are updated: what’s important is that they accurately reflect the costs as you see them at the moment.
Benefits of reviewing and assuring cost estimates
As you can imagine, there are plenty of good things about reviewing estimates as a team, not least that you should end up with better quality data. Here are some other benefits: