One of the terms you will hear when learning about Earned Value Management is the need for an Earned Value System Description. Have you ever wondered what the Earned Value Management System Description (EVMSD) is and why you need one? Maybe more importantly, what does it have to have in it?
The EVMSD is something you hear a lot when you first start investigating implementing Earned Value at an organization. It tends to be listed as one of the must haves when you start looking at what you need to put in place to be compliant with the earned value requirements you typically see on government contracts.
What A Earned Value System Description Is Not
First, it helps to understand what the System Description is not.
It is not just a training resource for staff to reference, for example, what is the definition of a Cost Performance Index (CPI). That type of information is useful to have in the System Description, or at least a reference for where someone can find that, but it is not the reason for having a System Description.
It is also not a listing of specific contract requirements, like reporting levels or reporting thresholds. That kind of information belongs in the Project Management Plan (PMP). The PMP will typically reference the System Description, but a PMP is not a System Description.
Finally, a System Description is not simply an acknowledgment of the requirements identified in EAI-748 documentation and a commitment to be compliant with those. In other words, a System Description should not just say Criteria 23 states that you need to report against variances and that you will do that on your project.
What A Earned Value System Description Is
A System Description should be executable processes and procedures that your organization (note I did not say project) follows when managing a project.
That means it needs to detail how you will track whether you have tripped a variance threshold (which may vary from project to project) and, when tripped, what actions will be taken. This also includes the actions required by the organization’s management to review and sign off on variances.
That means the same processes and procedures detailed in the System Description are used consistently across an organization to manage projects. One of the worst things an auditor can find is that simple processes are different from project to project. That kind of inconsistency drives overhead and inefficiencies that ultimately lead to doubts about the validity an organization is delivering. At a minimum, it can spawn multiple audits because each project will have to have its processes reviewed.
This means that the System Description is more than a generic reference/training guide but instead is the Standard Operating Procedures (SOP) for managing projects. The System Description needs to be the first thing your project team “reaches” for when they have to ask how to deal with something when it comes to managing a project.
Ideally, an Earned Value Management System Description is a regularly referenced document/wiki/tool that your staff uses, actually uses, to manage a project…no matter what project they are working on. A well-built System Description should be built around the typical process flows your team will face. For example, have a section that addresses how to handle a contract change, monthly reporting, establishing a baseline.
While this structure means you address the individual EIA criteria in multiple sections, and multiple criteria within sections, it also organizes the information in a relevant way for your staff to reference.
People do not tend to think in terms of Criteria 1 or Criteria 10, but implementing a change or delivering a variance report. For auditing purposes, you should also build a cross matrix that maps where in the document the specific EIA criteria is addressed.
The other best practice when looking to develop a System Description is to think in terms of levels of documents. We typically recommend doing two levels:
- A process level that is high enough that it addresses the organization level workflows.
- A procedure level that, for example, addresses the unique aspects of a division within an organization or drills down into specific steps within tools.
The reason for this division is that this gives you a process level that will be more static for an organization that you can have approved by your customer or cognizant organization. It also provides the flexibility to have procedures (or desktop instructions) that can be changed more frequently as software tools are updated or replaced. Without this separation, you end up revising your System Description version each time you make a change, which technically has to be approved by your customer.
A final thought on the System Description (at least for this blog) – if you are thinking, “isn’t this the same thing as my project management Standard Operating Procedure’s with an Earned Value tint? The answer is yes! In fact, if your organization has existing project management SOP’s, your Earned Value Management System should not be a standalone silo document. That would be the worst-case scenario because it creates configuration headaches down the line. Instead, you should update your project management SOPs to ensure they are addressing the EIA criteria and that becomes your System Description.
Earned Value is not a separate Project Management philosophy; it is a Project Management best practice that is part of a mature project management approach within an organization. The good news here is, if you have any processes defined, you are already ahead of the game when it comes to implementing Earned Value, because odds are you’re already doing at least 50% of the things you need to be doing to be compliant.
An EVMSD is something that at first blush sounds like added overhead only applied to specific contracts that have an Earned Value requirement. In reality, it is a output of an organization moving up the Project Management maturity scale, whether you have an Earned Value requirement or not. If you take the latter approach to building your System Description you’ll find that you are not only being compliant, your are adding value to your organization’s goal of better project management.