Several years ago, Edwards presented a short presentation titled Earned Value with Microsoft Project the Myths, the Fears, and the Realities. We developed this presentation in conjunction with our training course that detailed a process with the necessary rigor for gaining meaningful Earned Value (EV) metrics from Microsoft Project. I will not attempt to cover all of the necessary aspects and nuances of using Microsoft Project as an EV tool in a blog. I will however discuss in some depth the nature of the true realities Project Managers need to know to achieve meaningful metrics.

True Nature of Microsoft Project

One of the beauties of Microsoft Project is that it is an open architecture into which an organizational process can be woven. However, when it comes to EV, an open architecture is not always the best answer. Many EV tools are built around a regimented process that may make them difficult to work with, but as a whole, are better equipped to properly report EV metrics. This process discipline is paramount to ensuring the EV metrics reported are sound, consistent, and meaningful. So what does this mean for the Microsoft Project user willing to take on the challenge of using the tool as part of an Earned Value Management (EVM) system? Well, it means that above all, a regimented and consistent schedule development and tracking process needs to be developed into and around the tool. A process along with a few necessary key elements in Microsoft Project ensure that metrics are properly reporting for the project. The overarching key to using Microsoft Project as an EV tool is to ensure a sound process is in place for planning, developing, tracking, and communicating the project schedule.

Key Microsoft Project Elements for Tracking Earned Value

Planning

For a successful EVM system, it all begins with the planning process. Where the planning is typically not performed within Microsoft Project, the outcome of the process does impact how a project schedule is constructed within the tool. A sound project planning process that involves key stakeholders early on is critical to obtaining the necessary level of plan buy-in and understanding. Given the choice, people would rather be a part of an evolving plan as opposed to reading about it later no matter how comprehensive the Work Breakdown Structure (WBS) dictionary. The process used should be rooted in strong project management principles such as those defined in the Project Management Institute (PMI) Project Management Body of Knowledge (PMBOK).

To support schedule development, outputs of the planning process should include a development of a WBS and a set of detailed tasks with work assignments and cost estimates that support it. You should consider task sequencing or at least identification of the required task inputs and outputs; this will help with task logic and sequencing during schedule development. One other consideration that should be explored is how credit (EV) will be taken for each task.

Developing

Upon completion of the planning processes, a schedule may be developed. Here is where the planning and Microsoft Project come together to form our project schedule. Where schedule development philosophies may differ, there are few key necessary requirements I will address that Microsoft Project will need to have for achieving Earned Value Metrics.

We will start with resources, the project should be resource loaded and each resource must be assigned a rate or cost. Earned value calculations are conveyed in units of currency and begin with rates applied to resources. Most organizations are very protective of resource rates and rightfully so. This generally poses one of the biggest challenge when developing an Earned Value management schedule. There are many ways to apply rates for resources, a methodology appropriate for the organization should be agreed upon, adopted and consistently applied in order to obtain meaningful data. One word of caution, avoid using the Cost resource type in Microsoft Project, as they do not contribute to EVM calculations.

When developing schedule tasks, ensure those tasks are traceable back to the Statement of Work (SOW) and are organized in accordance with the WBS from the planning process. This will be increasingly important during the tracking and reporting processes once schedule development is completed. Mapping to the WBS should be done to at least one level below the required level for reporting out.

Schedule tasks should have sound estimates applied to them (a product of the planning process) that are based on strong technical judgment or historical performance where practical. The tasks should be sequenced using task predecessors and successors. Generally, all work related tasks should have at least one predecessor and one successor. Tasks should have appropriate resources assigned to them based on the work estimates. Further task durations should be based on the resource work effort and not strict duration-based estimates. It is very tempting to “fix” the end date of a project by restricting task durations; however, by doing so, we may end up over utilizing the associated resources and have a plan that may not be practical or sustainable.

At the completion of adding all tasks and assignments to the schedule, you should take steps to ensure you don’t over utilize resources and any underutilizations should be addressed where practical. The goal here is to arrive at a much more “do-able” plan. Having a resource conduct two activities at full time in parallel is a recipe for disaster, chances are they both will not get done as expected and the project suffer in the form of delays until the work is accomplished. It is sometimes difficult to achieve exactly 100% resource utilization for resources over daily, weekly, or monthly periods using leveling tools or other methods within Microsoft Project. My recommendation is to focus on the large peaks within the resources utilization. A few excursions above 100% may be deemed acceptable so long as the utilization is not consistently more than 100%. Remember, things generally don’t go as planned, spending hours trying to achieve exactly 100% is not time well spent.

Finally, once all task are entered and resource leveled, the key stakeholders will need to weigh in and form a consensus schedule approval. Once this is achieved the schedule must be baselined (one of those pesky Microsoft Project requirements) or in other words, a project schedule snapshot must be taken to provide the measuring stick of project progress. This is absolutely necessary for the calculation of Earned Value metrics as it forms the basis of the project Planned Value.

Tracking

Now that all of that planning and development is complete, we are done with this schedule, right? Wrong, the fun has only just begun! Now we need to track progress against the schedule to calculate the EVM. Two important tenets of schedule tracking are how often and what constitutes a properly updated scheduled.

The schedule reporting frequency should be consistent with the EV reporting frequency whether internal, external, or both. There is no choice if the reporting period is weekly, in this case each reporting period must be supported. A periodic cadence is strongly recommended, weekly or at most bi-weekly reporting cycles are best for reporting periods that span a month. A lot can happen in a month, some details may be lost and generally it is harder to react to changes after a month has gone passed. I also discourage statusing more frequently than weekly, depending on the size of projects in your organization, as this could become overwhelming quickly.

So what constitutes the best practice for schedule status when calculating EV? First, the status date must be set to calculate the metrics (another Microsoft Project requirement). Typically, the status date is set to the date that the status gathered is valid. Tasks updates are made only up to the status date and planned work is then scheduled after this status date. There should be no work planned in the past nor any completed work in the future. (Note: You have a pass on this if you happen to own a DeLorean containing a flux capacitor in your possession). For complete or in progress tasks, you must also provide proper application of EV. If you plan to use %complete as the EV basis, then updates of percent complete will calculate EV. Personally, I am not a big fan of this as duration changes will influence the completion percentage and hence the EV. If you plan to use the Physical %complete (which I recommend) then this field must be properly updated based on the planned EV credit methods from the planning process.

Communicating

Communication, one of the keys to project management, is critical when planning an EV project. From the planning process, you should document details in the form of a WBS dictionary which will include many of the planning elements, descriptions, and completion criteria. Included with this dictionary should be the basis of estimate (BOE) information detailing how estimates were derived. During schedule development and tracking, it is important to keep team members informed of progress and any changes to the schedule. Regular conversations with team members can go a long way to gathering task status and updates. Ultimately, EV reports both internally and externally will be sourced from the schedule at some point if not generated by Microsoft Project.

Conclusion

Clearly, Microsoft Project does not have a built-in process. As the project manager, you must build this process into the tool and this process must be consistent to your organizational practices. However, the key is to ensure the discipline and rigor must govern how the tool is to be used to effectively provide sound and consistent EV metrics.

---

Categories:

Leave a Comment