You may snicker to think that Microsoft Project can serve as a tool for producing earned value metrics. After all, there are highly complex, dedicated products that perform this job. In this article I won’t attempt to cover all the necessary aspects and nuances of using Project as an EV tool; but I will discuss what project managers need to understand to achieve meaningful metrics.

The True Nature of Project

One of the beauties of 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 makes them difficult to work with but ends up also making them better systems for reporting EV metrics. This process discipline is paramount to ensuring the EV metrics are sound, consistent and meaningful.

What does this mean for the Project user willing to take on the challenge of using the tool as part of an earned value management (EVM) system? Above all, a regimented and consistent schedule development and tracking process needs to be developed into and around the tool. A tight process along with a few other key elements in Project ensure that metrics will be properly reported for your project. The overarching theme in using Project as an EV tool is to ensure that a sound process is in place for planning, developing, tracking and communicating the project schedule.

Planning

For a successful EVM system, it all begins with the planning process. Where the planning is typically not p05erformed within Project, the outcome of the process will affect 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 dictionary). The process 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 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 identifying required task inputs and outputs. This will help with task logic and sequencing when you develop the schedule. Another consideration worth exploring: how credit (EV) will be taken for each task.

Developing

When you’ve completed the planning processes, it’s time to develop a schedule. Here is where planning meets Project. While schedule development philosophies may differ, there are few essential elements Project needs to produce EV metrics.

Let’s 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 EVM schedule. There are many ways to apply rates for resources. Adopt a methodology appropriate for your organization and apply it consistently to obtain meaningful data. One word of caution: Avoid using the Cost resource type in Project, as it won’t contribute to EVM calculations.

When you develop schedule tasks, make sure 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. In addition, task durations should be based on the resource work effort and not strict duration-based estimates. While you may find it tempting to “fix” the end date of a project by restricting task durations, doing so could result in an over-utilization of associated resources, producing a plan that’s impractical or unsustainable.

When you’ve finished adding all tasks and assignments to the schedule, I suggest you take steps to ensure you don’t overuse resources and that you do address underuse where practical. The goal 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, neither activity will get done as expected, and the project will suffer as a result. While it’s sometimes difficult to achieve exactly 100-percent resource use for resources over daily, weekly or monthly periods using leveling tools or other methods within Project, I recommend focusing at the very least on the large peaks within the resource usage. While a few excursions above 100 percent may be deemed acceptable, consistent overuse isn’t. At the same time, recognize that since things generally don’t go as planned, spending hours trying to achieve exactly 100 percent isn’t time well spent.

Finally, once you’ve entered all tasks and leveled them, the key stakeholders will need to weigh in and form a consensus schedule approval. The schedule must be baselined (one of those pesky Project requirements); a project schedule snapshot must be taken to provide the measuring stick of project progress. This is necessary for the calculation of EV metrics since 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 schedule.

The schedule reporting frequency should be consistent with the EV reporting frequency, whether internal, external or both. There’s no choice if the reporting period is weekly. In this case each reporting period must be supported. I strongly advise the use of a periodic cadence, whether weekly or bi-weekly. After all, a lot can happen in a month. You can lose details and generally find it harder to react to changes after a month has gone by. I also discourage issuing status reports more frequently than weekly since this could quickly become overwhelming.

What constitutes the best practice for schedule status when calculating EV? First, the status date must be set to calculate the metrics (another Project requirement). Typically, the status date is set to the date that the status gathered is valid. Task 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. I’m no fan of this since 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 information detailing how you derived estimates. During schedule development and tracking, it’s important to keep team members informed of progress and schedule changes. Having 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 Project.

Build EV Metric Creation into Project

Clearly, Project doesn’t have its own EV metric-creation process. As the project manager, you must build this process into the tool, making it consistent to your organizational practices. However, the secret is to ensure discipline and rigor in how the tool is to be used to provide sound and consistent EV metrics.

A version of this article originally appeared on the Edwards Performance Solutions blog here.

Have your own observations regarding EV with Project? Share them with the MPUG community in comments below.