I'm currently training for taking the PMP certification exam, and managing a large software project in parallel.

When it comes to EVM, PMBoK guide seems quite clear about how EVM technique can help PM assessing project performance. However, when I try to apply this method to my project I face an issue that I think many practionner face : How do you know where you stand ?

EVM fully makes sense if you have an accurate EV calculation method, which is not so trivial.

 

Indeed, in the 4 brick wall example (http://leadinganswers.typepad.com/leading_answers/2009/04/the-simple-guide-to-earned-value.html), it's easy to assess how complete the wall is. When it comes to software implementation, or other brain creation activities, it's far more difficult to assess where you stand.

I've thought about the question, and found it was a hard one.

Method 1: Progress based on reviewed ETC

Let's say that progress on on-going activities is Actuals divided by Actuals + Bottom-up eestimated ETC. We have the following progress indicators multiplied by initial budget for each work package :

  1. 0% for not started work packages
  2. 100% for completed work packages
  3. Reviewed progress for ongoing work packages

BUT, from my recent experience, some ongoing activities on work packages can entail rework on other work packages, causing completed work packages to go back to ongoing status, and progress to decrease on ongoing deliverables, causing the process less likely to converge using this kind of progress.

Method 2: Gates for assessing progress

Another way to proceed would be to define "gates" for each deliverable. Progress associated with the gates could be defined in the Project Management Plan. The achievement of a gate would set the progress to the defined value.

As an example, for a GUI based deliverable, you could define:

  1. Design completed : 25% progress
  2. GUI completed : 35% progress
  3. Controller / Model completed : 55% progress
  4. Ready for System Testing : 65% progress
  5. Ready for Integration Testing : 85% progress
The main benefit of this approach is that progress is related to concrete, meaningful for stakeholders steps.
However, we can see in the given example that it either constrain the sequencing of tasks, or do not reflect the real progress if tasks are conducted in parallel.

Conclusion

I'm not comfortable with setting-up EVM tracking on my project. I chose to implement the Method #1 which seems more close to real progress tracking despite its disadvantage.

And you ? Which way to track progress as an input to EV calculation do you use ?

 

Comments  

#3 Maxime Macron 2013-01-16 18:54
Thanks for your comment Marc,

In fact, in my company, we use to implement the approach you describe, using a precise weekly estimate of the ETC (Estimate to Complete). % complete can therefore stall as actuals keep on increasing on the given task. That's why I was looking for something more accurate.

In between, I finally came to implement a system in which low level granularity tasks are grouped within what I called "Work items", which can be "Not started" (0%), "Started" (20%) or "Completed" (100%) : the very mechanism you describe. The benefit of this approach is to detect more easily if new "Work items" occur if these had been forgotten in the baseline, making easier to justify costs overrun if any.

I totally agree when you say that precision of the team estimates and status of tasks is key to proper PSR.

Thanks once again for sharing your experience here.

Wish you all the best
#2 Marc 2013-01-16 13:54
.../...
Second, you can set up your project schedule with no activity greater than 40h. When it comes to Project Status Reporting, an activity is either completed or late. This approach might be tricky to implement.
Earn Value Management is part of the project status reporting, but only a part. Accurate and timely inputs from the project team are critical to know where you stand.
I hope this helps.
Take care,
Marc.
#1 Marc 2013-01-16 13:53
Hi Maxime,

That's a good question. :-)

You should have the %complete indicator at the activity level. Having it at the work package level is not enough.
What I have learnt is 'Remaining Work' is more valuable than the %complete indicator.
Depending on you project environment and teams, you can use 2 approaches.
First a ‘pre-defined’ scale (at the activity level):
0% not started,
20% just started,
80% almost completed,
100% completed.
Each and every week, project team members are asked to provide an accurate Project Status Report, with an update of activity status and the remaining work for started activities. They should also provide their confidence level to achieve the activity on-time. They might list the activity as a new risk is they have limited confidence, or as an issue if they are facing an issue that impacts their work.

.../...

You have no rights to post comments