What do project managers actually need to know to activate meaningful metrics?

Edwards project managers have worked on thousands of schedules and in multiple scheduling tools, and one thing we’ve discovered that clients can struggle to get right in Microsoft Project is Earned Value Management (EVM). When harnessing Microsoft Project for your earned value (EV) needs, there are a few key things to keep in mind. Ignoring any of these can lead to a lot of frustration, faulty reports, bad decisions . . . or even project failure.

True Nature of Microsoft Project

One of the beauties of Microsoft Project is that it provides an open architecture for your organization’s processes. 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, they’re better equipped to properly report EV metrics. Having a process discipline is paramount to ensuring your EV metrics are sound, consistent, and meaningful.

So, what does this mean for Microsoft Project users willing to take on the challenge of using the tool as part of an EVM system? It means that you’ll want to develop a regimented, consistent process for planning, developing, tracking, and communicating the project schedule. That process, along with a few necessary key elements in Microsoft Project, ensure reliable metrics for your project


Any successful EVM system begins with the planning process. 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 after the fact—no matter how comprehensive the Work Breakdown Structure (WBS) 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, you’ll want to be sure to develop a WBS and a set of detailed tasks with work assignments and cost estimates that support it. As you plan, consider task sequencing or at least identifying the required task inputs and outputs; this will help with task logic and sequencing during schedule development. One very important consideration is how credit (EV) will be taken for each task. Each task should be given some sort of objective progress measure or completion criteria. This could be something as simple as weighted binary (credit on start and credit on finish) or something more complex like milestone weightings.

Planning usually doesn’t happen within Microsoft Project itself, but the outcome of the process directly affects how you develop a project schedule.


While schedule development philosophies may differ, there are few things you need to include in Microsoft Project in order to achieve accurate EV metrics.

Resources and rates: 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 is generally one of the biggest challenges when developing a schedule with EVM. There are many ways to apply rates for resources, so 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 since “Cost” resources do not contribute to EVM calculations.

Tasks and estimates: When developing schedule tasks, ensure those tasks are traceable back to the Statement of Work (SOW) and are aligned with the WBS from the planning process. This will be increasingly important during the tracking and reporting processes once you finish developing the schedule. You’ll want to map to the WBS 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); these estimates should be based on strong technical judgment or historical performance if at all possible. 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, you may end up overutilizing the associated resources, which means your plan 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’re not overutilizing resources and that any underutilizations are addressed as much as possible. The goal is to arrive at a realistic plan. Assigning a resource to conduct two activities full time at the same time is a recipe for disaster. Chances are that quality and/or deadlines will suffer. While it’s sometimes difficult to achieve exactly 100% resource utilization over daily, weekly, or monthly periods using leveling tools or other methods within Microsoft Project, we recommend focusing on the large peaks within the resources utilization. A few excursions above 100% may be deemed acceptable as long as the overall utilization averages near 100%. Remember, things generally don’t go as planned, so spending hours trying to achieve exactly 100% is not time well spent.

Stakeholder approval and baselining: Once all tasks are entered and resource leveled, key stakeholders will need to weigh in. Once you get stakeholder consensus, don’t forget to baseline your schedule—one of those pesky Microsoft Project requirements. You need a project schedule snapshot to provide the measuring stick for evaluating project progress. This is imperative for the calculation of EV metrics since it forms the basis of the project Planned Value.


Now that all of that planning and development is complete, you’re done with this schedule, right? Not so fast! The fun has only just begun! Now you need to track progress against the schedule to calculate the EV. Two important tenets of schedule tracking are how often to make updates and what constitutes a properly updated schedule.

How often: 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; each reporting period must be supported. We strongly recommend a periodic cadence—weekly or at most every-other-week reporting cycles are best for reporting periods that span a month. A lot can happen in a month! Some details may be lost, and it’s generally harder to react to changes after a month has passed. We also discourage applying status more frequently than weekly—depending on the size of projects in your organization—since this could quickly become overwhelming.

What exactly 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, it’s valid to set the status date to the date that the status is actually gathered. 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 get a pass on this only if you happen to own a DeLorean containing a flux capacitor.) For complete or in-progress tasks, you must also properly apply EV. If you plan to use “% Complete” as the EV basis, then updates of “% Complete” will calculate EV. Some of our PMs are not fans of this idea since duration changes will influence the completion percentage and hence the EV. If you plan to use the “Physical % Complete” (recommended), then this field must be properly updated based on the EV credit methods assigned during the planning process.


Communication—one of the keys to project management—is critical when planning an EV project. During the process, be sure to 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’s important to keep team members informed of progress and any schedule changes. Regular conversations with team members can go a long way to gathering task status and updates. Ultimately, both internal and external EV reports will be sourced from the schedule at some point if not generated by Microsoft Project.


Clearly, Microsoft Project does not have a built-in process. As the project manager or scheduler, you must build this process into the tool, and this process must be consistent with your organization’s practices. To avoid failure, the key is to ensure that discipline and rigor govern how the tool is used in order to effectively provide sound and consistent EV metrics.


Mike is a former Senior Project Manager with focus on Microsoft Project and Project Server. He develops many Microsoft Project training courses, custom schedule management and reporting solutions, and Project Server implementations for clients in both federal and commercial markets.