Project Issues

Issues are events that have occurred or situations that exist which will adversely affect the project outcome if not resolved. In a typical project life cycle, circumstances are going to change, misunderstandings occur, assumptions don’t hold, political agendas collide, problems arise, and risk events happen. These situations are categorized as project issues, and they all have the potential to adversely affect the project’s ability to accomplish its objectives.

To minimize the potential effect of these obstacles on our project objectives, we need to have a proactive plan for effectively managing project issues. Managing project issues is an example of proactive project management. Through solid planning, effective stakeholder management, and insightful risk management, we can reduce the number of issues our project will encounter, but we cannot eliminate them. The goal of project issue management is to detect issues as early as possible. The earlier an issue is identified, the greater the chance of resolving the issue before it can affect any of the project’s critical success factors.

The objective of project issue management is to identify, record, track, resolve, and communicate all issues that might adversely impact the project. To accomplish this objective, we need to review the associated principles. The principles of issue management fall into two main categories:
an administrative process and a project manager mindset.

• Administrative process principles: To properly manage project issues, there are a few  administrative fundamentals to adhere to:

1. Document the issues—We need to log the issues somewhere as they are identified.
2. Track until closure—Use the log to make sure issues remain visible until they are resolved.
3. Align with project needs—Ensure the overall process matches the communication and workflow needs of the project.
4. Cost-effective approach—Keep things in perspective. Don’t buy a BMW when a Chevrolet is all you need.

• Project manager mindset principles: More than anything, effective issue management is an attitude and an approach. The following terms describe the mindset principles that a project manager needs to have in this arena:

1. Ringmaster—As the project manager, you operate as the focal point for tackling project issues. You are the one who must get the right people involved at the right time to make sure issues are resolved. In addition, some issues require the input of several different parties to resolve. You need to facilitate this process.
2. Smiling bulldog—Your goal is to resolve issues as quickly as possible and to stay with them until they are resolved. Be persistent. This is the “bulldog” mentality. However, you need to do this with a smile. Leverage your interpersonal strengths to do this, while still building relationships.
3. Swivel-head—Just as with risks, you need to constantly be looking for trouble. That is, trouble for your project. Sometimes issues come disguised as questions or non-verbal communications. When in doubt, ask questions and verify. The effect of most issues can be mitigated if they are detected early and resolved quickly with the right buy-in.
4. Goaltender—Just as a good goaltender does not let anything get by him, a good project manager lets no issue go unnoticed or unresolved. In addition, the subtle intensity displayed by the project manager here helps to set expectations with the project team and signals to all stakeholders that they will be held accountable for getting issues resolved.
5. Disciplined—To be effective, you need a fair amount of discipline. You need the discipline to log the issues and follow the process. In the whirlwind of most project environments, it is easy to let this slip.

Features of Issue Management Systems

The actual details of the issue management system are not complicated, and in most situations they share many similarities with your change control system and risk tracking system. Although issue management systems vary in complexity and sophistication depending on your organization and the needs of your project, there are key features that all issue management systems should possess.

Clear process—Clearly define and communicate how issues are submitted, how they will be resolved, how and when outstanding issues will be reviewed, and what is needed to officially close an issue.

Escalation procedures—This is part of the overall issue resolution process, but not always thought about in advance. Define the types of issue that warrant escalation to higher levels of management. Generally, there is a single escalation process for a project that is leveraged for anything affecting the critical success factors (issues, changes, or risks).

Issue log—This is the mechanism used to document and track project issues. The most common mechanism is a spreadsheet, but there are limitations to this method. Other options include database systems and collaboration tools. There are pros and cons to each choice. The important thing is to use a tool that matches the needs of your project.

Issue Log Administrator—Someone needs to serve as the central control point for the Issue Log. Usually, this will be you, the project manager.

Issue Data Points—Although the specific mechanism used for the Issue Log and the exact  information needs vary across projects, there are a core set of data points that should be considered for any issue logged. The recommended data points are listed in the table shown below:

In the next post we shall look at the available tool options for your Issue Log and certain best practices that  help you avoid the common mistakes in this aspect of project control.

Configuration Management Plan

The configuration management plan (CM Plan) is first defined during the project planning process and is part of the overall project plan. Like all planning documents, the level of detail included in the CM Plan should be consistent with the risk levels, compliance requirements, and composition of the project team.

The following table lists the minimum topics/ recommended Sections that should be covered in a CM
Plan:

Even with a CM Plan, there are still some remaining pitfalls that you need to be on the lookout for:

1. Not following the plan—One of the first things to go when the realities of the project hit is execution of the CM Plan. There are two things you can do to help make sure the CM Plan is executed:

• Use an independent auditor (such as a QA Lead) and include the CM activities as part of the quality review process.
• Make sure to include the CM activities in the WBS and project schedule.

2. Tool difficulties—As stated before, configuration management tools should be leveraged whenever possible, and in some cases, they are absolutely mandatory. That being said, the proper use of these tools is not automatic. If you are going to use a tool, you need to make sure the right team members are trained on how to properly use the tool, and you to verify that the tool works correctly (not that this is ever an issue or anything).

The Principles of Managing Work Products

Managing project work products is a strong example of the preventative aspects of project control. If you have a solid process in place, and you are using it, everything rolls along as expected. It’s only when you have a “gap” in this area that it attracts attention from stakeholders—generally unwanted attention. The principles of managing project work products are simple and can be boiled down to three management fundamentals:

Identify—Define all the work products that need to be managed. Make sure all the work products are identified, not just the major ones and not just the product deliverables. For each deliverable type, you might need a different configuration management process. This is often true when dealing with both digital and tangible deliverables and when dealing with documents and software components. This can also be true when there are limitations with the configuration management tools that are available.

Protect—Protect the integrity of the work product. This means that you need to control who has access to the work product, what changes can be made by each person, and that you can recover the work product in the event of an unexpected accident or disaster. The access control can have several layers, but the most common aspects are facilities access and network access. In addition, this means protecting any contractually significant approvals or sign-offs.

Track—The ability to trace your steps and track the changes that are made to a work product. Common terms associated with this principle are “version control” and “revision history.” The other important aspect of this principle is the ability to provide status on the current state of all managed
work products.

Best Practices

Whether you utilize manual or automated processes, here is a list of techniques that should be considered for your configuration management process:

1. Establish central repository—First and foremost, define a central repository for the project where all project work documents will be stored. Make sure access to the repository can be controlled and that the appropriate stakeholders have access to it.

2. Define review/revision/approval process—Define which work products need to be reviewed and approved when any change is made, who can make those changes, who needs to approve those changes, and the associated workflow that needs to be followed.

3. Define a “gatekeeper”—Experience has shown tremendous value in establishing someone as the official librarian for the project repository. This person is responsible for controlling access to the repository, updating the repository, and ensuring that the configuration management procedures are being followed.

4. Implement access controls—Ensure that the project repository is only accessible to authorized stakeholders and the granted access level is aligned with their role on the project.

5. Establish common directory structure—To better organize work products and to make it easier to find them when you need them, it is recommended that a directory structure be defined that is aligned with the project phases and workflow process.

6. Establish file-naming conventions—Also in the spirit of better organization of work products, it is recommended that a common convention be defined for naming project work products. The conventions provide consistency and help improve project communications and stakeholder expectations as well.

7. Establish search keyword conventions—Given the growing popularity and use of Internet search engines, people are more accustomed to searching for what they need by the used of keywords. This can be especially helpful if the project repository directory structure is large or has multiple layers, and it can be a tremendous timesaver if it is “less than obvious” where a given work product would be found.

8. Establish version numbering scheme—If these guidelines do not exist for your organization already, determine the rules that will govern the versioning scheme for each category of work product. Common elements to consider include version number format, differences between major and minor versions, and conventions to be followed.

9. Establish baselines—A key best practice, especially before any milestone-type event on the project, such as phase-end, tollgate, start of a testing phase, or releasing work product to a client. To effectively deal with any quality issues and client expectations, you must be able to clearly define (and maintain) the configuration of a work product at a given point in time.

10. Use standard document sections—To help encourage effective configuration management practices, it is recommended that work product templates be developed that contain standard document sections. Recommended document sections include the following:

• Title page
• Revision history page
• Approval page
• Standard header and footer formats/data

11. Use a deliverable tracker—A powerful technique that can be utilized regardless of the sophistication of your process. Develop a mechanism to identify and track the status of your project work products. For lack of a better term, I will call this your deliverable tracker. This can be done with a simple spreadsheet program.

12. Back it up—Make sure that your project repositories have proper backup procedures in place and that they are actually working.

13. Address needs of different work product types—A single configuration management process might not be adequate for your project. You should develop specific configuration management procedures for each type of work product you are managing.

14. Leverage configuration management tools—Although effective configuration management procedures can be executed using clearly defined manual procedures—and a fair amount of discipline and a central control point—the process is much easier with configuration management tools. The tools enable you to control access to the repository, control the revision process (only one person can check out the work product for edit at a time), and provide an automatic audit trail.

15. Define product configuration build/release process—On any project that deals with a product that is composed of multiple components, a process is needed that properly integrates the components into a final product. This is especially true for any product that represents a system. This process enables you to establish a baseline configuration.

16. Develop configuration management plan—This is where you document all of the configuration management best practices you are going to utilize for your project. The configuration management plan enables you to communicate the procedures and rules that the project will follow and to gain agreement on the plan.

17. Leverage archive folders—A simple but powerful technique to help you manage (and not lose) project information is to always create an archive folder within a specific project directory to hold any previous versions. This is especially useful for digital work items that are not managed by a configuration management tool. This practice also has the added benefits of better organization and better visibility of the most current work items.

Managing Project Deliverables

An excellent indicator to the experience level, professionalism, and overall project management maturity of an individual is how much effort and thought he/she gives to the management of the actual project work products (deliverables). This area of project management is one of the most neglected, yet it is a foundational element of managing risk, quality, and stakeholder expectations on any project. Without it, you will inevitably incur additional work efforts, lower quality, and more costs—which generally leads to missed project objectives and disappointed stakeholders.

By managing project deliverables, we mean the process by which the project work products are controlled. The work products can include anything resulting from project activities, including any deliverable, document, or project management item. And by control, we mean managing the changes to the actual work products themselves. The most common term for this process is configuration management. The change control system manages changes to a critical success factor (time, cost,
scope, and quality) for the project. The exact nature and details of this process will vary by project and the types of deliverables involved. The project planning document that defines this process is
generally called the configuration management plan.

Configuration management is often neglected because it is a non-glamorous, mundane aspect of project management that requires a certain discipline to carry out. In addition, this area of project management tends to fall victim to many ill advised assumptions and to the notion that this is just common sense and it will just happen automatically. Real-world experience would say otherwise.
Especially in the digital age, if you do not think about where your project files will be stored, who has access to them, how they will be protected, how changes will be made, and how changes will be tracked, your project is carrying a significant risk—and in most cases, an unidentified risk.

In many organizations today, enterprise configuration management tools are being implemented to better protect and control all digital assets of the organization, especially documents. In a work environment where configuration management is an integral part of the project management approach there isn't any issue but otherwise it is often tempting. A question which might trigger your mind is Why should we plan out the details for how specific work products are going to be managed?

Here are a few reasons why:

Where is that file?—The ability to quickly locate project information for a key stakeholder or to help resolve an important issue.

Lost productivity—Avoid instances of lost productivity when the work of one team member is overwritten by another team member, or when the product configuration you are testing does not have the latest versions of all components—thus making the test run invalid.

Baseline? What baseline?—Avoid instances where you cannot “go back” or “restore” previous versions of work products.

Who made that change?—Avoid instances where you cannot clearly tell (or explain) when changes were made and who made them.

Who approved that change?—Avoid instances where changes are made to work products that are not properly reviewed and approved. To say the least, this can lead to quality and customer satisfaction issues.

That will never happen to us—A major or minor disaster occurs that wipes out one or more work products. Where is your backup copy? Can you recover?

We said we would do what?—On projects with numerous deliverables and work products, it is easy to lose sight of the minor or auxiliary work items. A basic deliverable tracking mechanism can go a long way to prevent this from occurring.

I’ve got your official sign-off right here...now where did that go?—Assuming you have official client acceptance of your key deliverables, make sure you have a way to protect this evidence going forward.

You have no choice—In many environments, there are legal, regulatory, or process compliance requirements that must be met. In each of these cases, having control over work product changes is an absolute must. Most of this activity is focused on protecting the integrity of the work product and providing associated audit trials (evidence).

The ultimate reason: negotiating power—There is tremendous political power in having tight control over project work products. If targeted work products are officially approved, you have a clear audit trail on any changes to those work products, and those official sign-offs are protected, you are well-positioned to deal with any scope or requirements dispute. In addition, a historical record of all project management work products, such as project schedules, issue logs, status reports, and meeting minutes can be very valuable in negotiating new issues.

Common Mistakes of Project Managers

A single mistake from the person in charge of a project can not only cause delays but at times might even result in the complete failure of a project. This is not only incredibly demotivating but can also create issues around reputation management not to mention a potential marketing nightmare for the organisation or the team ultimately responsible for the delivery of the project.

While no two projects are exactly the same, the issues that can affect — and potentially jeopardize — them are often quite similar. And even good project managers can make mistakes when wrangling a big, complex project — or when being bombarded with change requests. Understanding the most common project management mistakes helps focus our efforts and helps us to avoid the same mistakes on our projects.

The following are some of the most common mistakes made by project managers:

• Not clearly understanding how or ensuring that the project is aligned with organizational objectives.
• Not properly managing stakeholder expectations throughout the project.
• Not gaining agreement and buy-in on project goals and success criteria from key stakeholders.
• Not developing a realistic schedule that includes all work efforts, task dependencies, bottom-up estimates, and leveled assigned resources.
• Not getting buy-in and acceptance on the project schedule.
• Not clearly deciding and communicating who is responsible for what.
• Not utilizing change control procedures to manage the scope of the project.
• Not communicating consistently and effectively with all key stakeholders.
• Not executing the project plan.
• Not tackling key risks early in the project.
• Not proactively identifying risks and developing contingency plans (responses) for those risks.
• Not obtaining the right resources with the right skills at the right time.
• Not aggressively pursuing issue resolution.
• Inadequately defining and managing requirements.
• Insufficiently managing and leading project team.

You are a project manager who has to juggle multiple projects simultaneously without messing up any one of them. Despite that, the projects you oversee end up taking longer to complete and cost you much more than the original budget. This gives you sleepless nights and even when you sleep, you get nightmares. Does all this ring a bell? If yes, you need to think about the reasons why projects fail. When you analyze it, you will realize that you are making some  classical project management mistakes repeatedly that are hampering your project progress.

Qualities of Successful Project Managers

Given the many roles played by a project manager, the broad range of skills needed, and the inherent challenges in successfully delivering a project, we need to find ways to accelerate the learning process. Two key ways to accelerate our learning are understanding the qualities of successful project managers and understanding the common mistakes made by project managers. In this post we'll focus on the qualities of successful project managers.

Successful project managers do not share personality types, appearances, or sizes, but they do share three important features:

1. They excel in at least two of the five key skill categories (Project Management Fundamentals, Business Management Skills, Technical Knowledge, Communication Skills, Leadership Skills) and are either “good enough” in the other categories or staff their teams to compensate for their deficiencies.

2. They avoid the “common” mistakes described in the next section.

3. They bring a mindset and approach to project management that is best characterized by one or more of the following qualities:

• Takes ownership—Takes responsibility and accountability for the project; leads by example; brings energy and drive to the project; without this attitude, all the skills and techniques in the world will only get you so far.

• Savvy—Understands people and the dynamics of the organization; navigates tricky politics; has the ability to quickly read and diffuse emotionally charged situations; thinks fast on the feet; builds
relationships; leverages personal power for benefit of the project.

• Intensity with a smile—Balances an assertive, resilient, tenacious, results-oriented focus with a style that makes people want to help; consistently follows up on everything and their resolutions without
“annoying” everyone.

• Eye of the storm—Demonstrates ability to be the calm eye of the project hurricane; high tolerance for ambiguity; takes the heat from key stakeholders (CxOs, business managers, and project team);
exhibits a calm, confident aura when others are showing signs of issue or project stress.

• Strong customer-service orientation—Demonstrates ability to see each stakeholder’s perspective; able to provide voice of all key stakeholders (especially the sponsor) to the project team; has strong
facilitation and collaboration skills; and has excellent active listening skills.

• People-focused—Takes a team-oriented approach; understands that methodology, process, and tools are important, but without quality people it’s very difficult to complete a project successfully.

• Always keeps “eye on the ball”—Stays focused on the project goals and objectives. There are many ways to accomplish a given objective, which is especially important to remember when things don’t go as planned.

• “Controlled passion”—Balances passion for completing the project objectives with a healthy detached perspective, which enables him to make better decisions, to continue to see all points of view, to better anticipate risks, and to better respond to project issues.

• Healthy paranoia—Balances a confident, positive outlook with a realism that assumes nothing, constantly questions, and verifies everything.

• “Context” understanding—Understands the context of the project, the priority that your project has among the organization’s portfolio of projects and how it aligns with the overall goals of the organization.

• Looking for trouble—Constantly looking and listening for potential risks, issues, or obstacles; confronts doubt head-on; deals with disgruntled users right away; understands that most of these situations are opportunities and can be resolved upfront before they become full-scale crisis points.

In the next post we'll focus on the common mistakes made by project managers.

Project Change Control Challenges

In this post we'll look at the challenges faced by many project managers. Here’s a list of things to either avoid or be on the lookout for:

The obvious—Be sure to set up a change control system as part of your approved project plan—and then use it.

Can’t say “no”—Use your change control system and don’t automatically agree to accept a scope change request without running it through the process. This is a common issue with project managers who have a fear of confrontation. Use your system as an objective third party to minimize direct confrontations.

Can’t say “yes”—Some project managers take the other extreme. They are so paranoid about “scope creep” that they do not listen to consider legitimate scope changes, often overlooking changes that are needed to meet the project objective. Again, keep the focus on the “big picture” (the project objectives) and exercise your change control system.

Over-reliance on formal sign-offs—Formal sign-offs are important and valuable. However, they should represent genuine agreement and understanding. Verify that you have real understanding and buy-in before proceeding.

Not the “gold” you want—Be on the lookout for gold-plating. This is the term given to extras or features added to the work product by the project team but not requested by the customer. This is a common reason why schedule delays occur and why unnecessary risks occur on projects. Also, the same issue can manifest itself in a work process. A technician might want their work to be perfect rather than just meet the specifications for the project. This is another reason why a team approach to estimating and planning can be so valuable.

Is it really a change?—Sometimes stakeholders do not agree on what really is an official change. Especially in contractual arrangements, the issue isn’t always “is it a change?” but rather “do I have to pay for it?”—a slightly different matter. Most of the disagreements occur because of ambiguity or inconsistencies in the specifications. Just do the other things we mentioned, and you should have a solid foundation to deal with this, if it ever happens.

The “impact” of the impact—In most cases, the individuals who need to assess the impact of a proposed change, especially scope changes, are members of the existing project team—who have current work assignments. Be aware of the impact that this “unplanned” effort could have on the project and guide the CCB accordingly.

Inadequate impact analysis— Just make sure the analysis performed on the impact is complete. At the minimum, verify the following on any change request assessment:
• Has the total work effort been accounted for? All supporting processes? All impacted deliverables?
• Have the implications of the request been completely considered?
• Have all impacted stakeholders been considered?

Beware of the little guys—On most projects, there will always be one or more of those small, minor scope changes. Sometimes they are clear changes; other times, they fall into a gray area. In an effort to build relationships and please the customer, many project managers do not document these if they feel the change requires minimal effort to implement. Be very careful here. Before you know it, you can easily have a series of these little changes that, when added up, can affect your project.

In addition, you must manage the expectations you are setting if you overuse this technique. As a rule, I would encourage you to at least document every change—no matter how small. For small  ones, you might choose to group them into a single change request.

Powerful Techniques for Minimizing Project Changes

The following techniques are powerful change prevention actions we can take:

Clear project definition—The more effort spent upfront to get agreement on clear project objectives and success criteria from the appropriate stakeholders, the less likely we are to get change requests during the project.

Solid requirements definition—Discussed in previous posts when we looked at the common reasons for scope changes.

Trace requirements—There is nothing like linking any work specification to its original source to control project scope. By tracing and showing the relationship from the original business objectives down to the detail design specification, you can identify (and possibly eliminate) any scope expansion when it is first proposed. If the proposed feature does not link directly to a higher level specification, it is a potential scope change.

Formal acceptance sign-offs—Formal sign-offs are a key aspect of change control management, especially for client-vendor oriented projects. The formal record of review and acceptance of a given deliverable helps to keep expectations aligned and minimize potential disputes.

Engaged stakeholders—Although formal sign-offs do act as strong “stick” incentive to get stakeholders involved, there is nothing like having professional, knowledgeable, and engaged stakeholders who are committed to doing their best as the best weapon against unplanned scope
expansion. A team of people who want to work together and get the job done can accomplish the work at hand with a “less formal” level of project management.

Use the right project approach—This technique is more about risk management, but change control and risk management are very intertwined. As mentioned before, if you know there is likely to be a high degree of change, structure your project in a manner that allows for deliberate, planned scope expansion (prototyping, iterations, cycles, and so on). For all projects, the following approaches help reduce the number of project changes:

• Emphasis on project definition and planning
• Shorter timeframes (1 year or less is preferred)
• Pilot tests
• Phased implementations
• Go/no-go decisions at phase-ends

Use WBS to illustrate impact—This technique might not prevent change requests from being submitted, but it can help you classify something as a change (and not part of the intended scope), and it can help you communicate the effect of the proposed change. By reviewing your detailed WBS, you can show that the work for the proposed feature was never accounted for, and you can show what other work items will be affected by adding the proposed change.

Defer to post-implementation—Another technique that will not prevent change requests, and that might not be applicable to all project situations; however, if it does, it can reduce impact on the project success factors. If the change request is legitimate, but is not absolutely critical to the initial
release (there is not a workaround, it does not adversely affect the customer experience), you can guide the CCB to defer the request to a future project or a post-implementation phase.

Track assumptions and constraints—This is definitely part of your risk response plan, too, but part of your “watch dog” mindset is to keep a close eye on the project assumptions and constraints. If these change, your project will definitely be impacted.

Although we want to be prepared for project changes when they occur, we want to spend most of our energy preventing the need for changes in the first place. Hence using the above discussed techniques must be carefully used to minimize project changes.

Elements of a Project Change Control System

The specifics of project change control systems can vary depending on industry, organization, and project importance, but there are essential principles, guidelines, and components that every change control system should possess.

Principles

Effective project change control systems follow these key principles:

1. Any proposed scope change is documented, evaluated, and approved before it is implemented. 
2. The appropriate stakeholders are involved in the evaluation and approval process.
3. Any change request is thoroughly assessed for impact to other project critical success factors, especially project schedule and budget.
4. The appropriate management level approves any change request before it is implemented.
5. All project changes are documented and communicated to all stakeholders.
6. Any stakeholder is permitted to submit a project change request.
7. The rules are firm, the roles and responsibilities are clearly defined, and
   the workflow process meets the needs of all stakeholders.

Guidelines

In addition to the principles we reviewed, these guidelines should be considered for an effective project change control system:

Re-baseline—The project plan should be updated to reflect the acceptance of any change to the critical success factors. A new performance baseline should be established.

Multiple paths—The change control system should consider multiple process paths based on estimated impact of the change request and the thresholds negotiated with senior management. This allows the appropriate stakeholders and management levels to be involved when needed and at the right time.

Focus on “buy-in”—Especially on proposed scope changes, make sure the right stakeholders are involved, understand the need and impact of the proposed change, and agree to the action plans before proceeding.

Aligned with contract—If your project involves contractual arrangements, make sure the project’s change control process is aligned with the change control process used to manage the contract with the vendor(s).

Components

There are no requirements from a technology perspective when it comes to project change control systems. They can leverage manual processes or utilize enterprise software packages. The following components are present, understood, and utilized:

1. Change request form—This form is used to capture the pertinent details of the proposed change and the key information resulting from the impact assessment.

2. Unique identification number—When a change request is submitted for evaluation, a unique identification number should be assigned to facilitate better communications and tracking.

3. Change request tracking log—The tracking log communicates summary information on all project change requests. Minimal information includes identification, impact summary, and current status. Spreadsheets and databases are common tools for tracking logs.

4. Change control board (CCB)—The minimum set of project stakeholders who need to review and approve any change request impacting the project’s critical success factors.


At the heart of managing project changes well is a project change control system. The specifics of project change control systems can vary depending on industry, organization, and project importance. Ultimately, the determination of any change request is a consensus-based, cost-benefit decision made by the stakeholders accountable for the project.

Causes of Unplanned Scope Changes

The leading causes for unplanned scope changes on a project are:

1. Shift in business drivers - Due to the dynamic nature of the business world today, things can change quickly. These business changes can have an immediate impact on existing projects. Examples of business drivers that can alter a project’s scope include:

• Available budget/funding for the project
• New government regulations
• Changing target market for the product
• Time-to-market pressures
• New business opportunities
• Changing customer priorities
• Unexpected market or world events

2. Shift in project acceptance criteria - Addresses changes in either the targeted completion date, financial return on investments, client satisfaction ratings, quality levels, other expected benefits, or the stakeholders who need to approve.

3. Shift in technology - With the move to shorter duration and phased projects, this is not as much of an issue as it has been in the past. However, there are still times when new technology becomes available during a project that will significantly meet the needs of the customer much better than what is currently planned.

4. Poor scope statement - If the scope statement is incomplete, ambiguous, inconsistent with project assumptions, or does not address the complete business workflow process, you are much more likely to have project scope changes.

5. Poor requirements definition - There are entire training courses on requirements definition and requirements management due to the importance they play on project success. Suffice to say, the more gaps that you have in your requirements, the more scope changes you are likely to have. Here is a list of the leading reasons for poorly defined requirements:

• Ineffective or wrong techniques used to gather requirements
• Communication breakdowns between analysts and stakeholders
• Requirements are not aligned with project scope
• Requirements do not address complete process work flow
• Documented requirements are not meaningful to targeted audience
• Requirements not reviewed for inconsistencies
• Requirements not verified for correctness and completeness
• Missing stakeholders
• Users sign off without a “real” understanding of what the documented requirements mean

To better manage project changes and project risks, and to minimize the number of scope changes, it is important to understand the leading causes for unplanned scope changes on a project.

Seven key management principles for effective project change control

Following are seven key management principles for effective project change control:

1. Plan for changes—Change control does not mean preventing changes at all costs. Conversely, project changes should be expected, planned, and well managed. The two keys here are selecting the proper project approach (methodology) and setting up a project change control system. For projects with an innovation focus or a volatile set of requirements, an iterative development-type approach that expects deliberate scope expansion or scope clarification should be utilized.

2. Set up a change control system—If your organization does not already have a defined procedure for project change control, then you need to set up a change control system for your project. The key benefits for establishing a formal change control system include the following:

• Helps protect the integrity of the project performance baselines
• Ensures the right people are involved in the decision-making process
• Helps manage stakeholder expectations
• Enhances the credibility and professionalism of the project manager
• Avoids issues and confrontations when changes do occur

3. Educate stakeholders—Whether you adopt an existing change control system or develop your own, you need to step through the change control process with your stakeholders. Do not assume that because the procedure is documented that individuals understand it or their roles and
responsibilities within it.

4. Use the system—This might seem obvious, but it is a common pitfall. Make sure to utilize the change control system that you have defined. If the project manager does not consistently follow the process, no one else will either.

5. Minimize scope changes—This is the great balance of managing project changes. On the one hand, you plan for changes and set up a system to manage those changes when they do occur; on the other hand, you work diligently on influencing those factors that are responsible for project changes, especially scope changes, to minimize their occurrence. The keys here include the following:

• Keep the team focused on the project objectives, the big picture.
• Listen carefully. You need to understand immediately when a critical gap is identified.
• Limit, if not totally avoid, any unnecessary changes by either the customer or the team.
• Educate stakeholders on the impact of their change request.
• Encourage any scope change request that is not an absolute, must-have feature to be scheduled for a follow-up project (cycle, iteration, or phase).

6. Over-communicate—For effective stakeholder management, make sure that all project changes are clearly communicated and understood by all key project stakeholders.

7. Be a watchdog—As a project manager, you must be continuously alert and mindful to anything that could impact your critical success factors. In particular, you need to understand what can cause unplanned scope changes to occur—and then work to prevent their occurrence.

Project Change

A project change is a change in any of the critical success factors (scope, schedule, costs, quality, and project acceptance criteria). The “big deal” is not that there is a change. In fact, for many projects, changes—especially scope expansions—are expected and encouraged. The big deal is uncontrolled change.

Why?

Because a change in any of the critical success factors affects the other factors, which then impacts project performance and the project’s ability to achieve the success criteria, which then impacts stakeholder perceptions and satisfaction levels. For example, an expansion in project scope increases the work of the project. At a minimum, the increased work affects project schedule and project costs. In many cases, the increased work also impacts resource plans and adds new risks. On projects with contractual arrangements, the increased scope will likely have contract implications and needs to be formally managed to protect all parties involved.

Thus, any time a change occurs, the project needs a way to recognize the change, evaluate the impact of the change, communicate the change, and make planning adjustments if the change is accepted. This mechanism is commonly referred to as a project change control system.

For many people, project control equals “managing project changes,” and managing project changes equals preventing “scope creep.” Scope creep is a common term used to describe uncontrolled expansion of project scope. Scope creep is legendary for causing project delays and cost overruns.

Although this belief is not completely accurate, the perception cannot be ignored. The ability to manage and control the change elements on a project, particularly the project scope, is a key to project success and a key performance indicator for a project manager.

To manage project changes effectively, a project manager must utilize all of his skills and  demonstrate project leadership. In addition to being an insightful measure of individual project management maturity, it is not uncommon for organizations that are in the early stages of adopting project management business approaches to look at how well project changes are being managed to determine whether project management is making a difference. Although it sounds like there is a lot riding on this ability to manage project changes (and there is), the process is not difficult if you follow the key success principles and understand how to avoid the common errors.

Although scope changes are generally responsible for 80% or more of the project changes, it is important to recognize that any of the following would also constitute a project change (and should be controlled using the project change control system):

• An expansion or reduction of project scope
• An expansion or reduction of product features
• An expansion or reduction in performance requirements
• An expansion or reduction in quality requirements
• A significant change in the target milestone dates
• A shift in the implementation or deployment strategy
• An increase in resource costs
• An expansion or reduction in the project budget
• A change in any of the project objectives
• A change in any of the final acceptance criteria, including return on investment forecasts
• A change in any of the project assumptions, constraints, or dependencies, especially regarding resources and work effort estimates
• A shift in project roles or responsibilities, especially on projects with contractual arrangements
• A decision to reset the performance baselines due to an unrecoverable performance variance

What occurs during a typical project recovery?

A project recovery is an attempt to turn around a troubled project. If there is ever a case where project control is absolutely critical, it is when you are trying to heal a sick project. To really understand what is important for controlling a project, let’s review what occurs during a typical project recovery.

The first thing that senior management will do to recover a project is to make sure there is an  effective project manager in charge. This might mean anything from validating the current project manager, bringing in someone new, pulling someone up from the project team, or providing a mentor to the current project leadership. After the project leadership is solidified, most recovery missions
involve the following activities:

1. Review planning principles—The planning principles are revisited. A focus is placed on establishing priorities and objectives, clarifying acceptance criteria, gaining consensus, and reviewing roles and responsibilities.

2. Reset baseline—As a final step in the re-planning step, key milestones are set and new baselines are set for cost and schedule performance.

3. Frequent status checks—To facilitate better communications, prevent additional obstacles, reinforce the visibility of the recovery mission, and emphasize individual accountability, team status meetings are conducted daily. In some situations, these checkpoints are even more frequent. It depends on the nature of the project.

4. Aggressive issue resolution—One purpose of the frequent status checks is to gain visibility of any new or potential issue. The resolution of any new issue is aggressively pursued. These become top priorities for project leadership.

5. Ensure clarity—Another technique normally employed in successful project recoveries is an extra effort to ensure clear understanding of all communications, expectations, and work assignments. When focus and efficiency is of paramount importance, the criticality of clear communications and mutual understanding is obvious.

6. Increase visibility and accountability—This has been referenced indirectly already, but it is worth emphasizing again. A major reason that project recoveries often work is because people know they are more accountable for their efforts due to the increased visibility with senior management. For both the individual and the organization, the recovery mission helps to prioritize efforts and align resource allocations.

Ubiquitous Project Control Challenges

In the previous posts we’ve discussed on some of the challenges the project managers when  attempting to control their projects. Now let’s see the top reasons for difficulty in the project control arena.

1. Time and cost accounting logistics—The logistical and organizational culture issues relating to time reporting and project costs tracking can prove detrimental to timely and accurate performance reporting. During planning, you want to understand and clarify how project time and cost information is reported and how quickly you can get this data. You might need to establish project specific time reporting or approval procedures to ensure the integrity of your control system.

2. Project manager reluctance, multitasked—The project manager might be reluctant to request WBS level time reporting by project team members, especially if this is not part of the organizational culture. In addition, the project manager might be overallocated and might not be able to invest enough time to performing the project controlling duties. This is most common when the project manager has assigned other project roles to herself or when the project manager is assigned to multiple projects.

3. No change control—The most popular reason is the lack of change control procedures. This is most problematic when the project scope has increased without the proper reconciliation with the project schedule and budget.

4. No completion criteria—When clear completion criteria for work assignments is not established, you are more likely to have increased rework cycles, more difficulty in accurately reporting progress or status, and more likely to experience the 90% done phenomenon.

5. No baselines—This should be obvious by now, but if a schedule and budget baseline are not  established and controlled, then you will not be able to accurately measure for performance variances. Without this ability, you are less likely to detect problems early—when they are small and more manageable.

6. No requirements traceability—Definitely an issue for controlling scope and stakeholder expectations. The lack of a formal tracking procedure between original requirements and final products increases the odds of missed work and scope creep.

7. Not consistent—When control procedures are not consistently implemented, it is difficult to detect performance variances early, and it is more difficult to get project team members to follow the defined control procedures.

8. Measuring progress accurately—Accurately measuring progress is a natural challenge on work assignments with intangible final products, especially on any project where status is estimated. However, this challenge is further complicated when work definition is vague, completion criteria is not established or when work efforts are not reported on a daily basis.

9. Impact of hidden work—This hits at the heart of work definition and change control. Any effort spent on unidentified work, unplanned rework cycles, or out-of-scope work adversely affects the accuracy and effectiveness of project control procedures.

10. Virtual/distributed teams—When project team members are not physically located together, it can be more difficult to get information, detect potential issues, measure work progress and ensure understanding of work expectations.

Common EVMS Misconceptions

For companies exploring a potential contractual need or competitive desire to implement an Earned Value Management System (EVMS), there are a host of misconceptions that frequently surface about earned value management (EVM) and implementing an EVMS. For anyone new to EVM, there is a certain air of mystery about it - EVM can appear complicated and hard to do. There is no doubt that implementing an EVMS requires management commitment and concerted effort to succeed. The whole point of an EVMS is to provide reliable, timely, and actionable information that can be used to manage a project more effectively. The trick is not making it more difficult than necessary. What are some common misconceptions about EVM and EVM Systems? The following is a short list of some of the frequent misconceptions Humphreys & Associates consultants encounter along with some observations to help dispel them.

1. Install software, have EVMS.
   
   False. Implementing one or more software toolsets to assist in the EVM process always helps, but it is just one component. An EVM System is more about instilling a disciplined and repeatable process for managing projects. That process will need to integrate all of the project control subsystems such as work organization, planning and scheduling, budgeting, accounting, work performance and analysis cycles, estimating what it will take to complete the remaining work (in time and resources), and managing changes to ensure the process provides reliable information from project inception to completion.
   
   The people using the project control system are another critical component. The goal is to create an EVMS that all project stakeholders including upper level management, project managers, integrated product team (IPT) leads, control account managers (CAMs), and others actively use as a normal part of their day-to-day routines regardless of the toolsets the company uses.
   
   The right software tools can certainly make it easier to implement an EVMS. Merely implementing software without addressing the process does not address the issue. Implementing a disciplined process that people use does.
   
   Beware of those who suggest that implementing a software toolset equates to an EVMS. In some instances the incorrect application of software, or software that claims to do more than it does, hinders the EVM process and can create issues with a government customer EVMS review team. Classic examples include the inability to fully integrate the schedule and cost data or the software produces Contract Performance Reports (CPR) formats using an outdated Data Item Description (DID).
    
2. An EVMS prevents budget overruns or schedule delays.
   
   Unfortunately, this is a common misconception of both contractors and government program offices.
   
   Properly used, an EVMS is an early warning system. It provides the means to identify issues early and proactively address them before they impact the ability to meet contractual requirements whether technical, schedule, or cost. Knowing how to identify risks and opportunities is an integral part of an EVMS. It is essential that managers at all levels know how to use the information the EVMS provides to respond quickly to deviations from a baseline plan. An EVM System is a useful management by exception tool. Project managers can manage the work effort with less stress, because they can focus on critical or problematic work elements.
   
   When a baseline plan is unrealistic or does not take into account likely risks to the project, implementing an EVMS will not prevent an overrun or schedule delay. It will, however, highlight where the baseline planning was inadequate and which work elements require management attention to make the necessary adjustments for the remaining work effort.
    
3. Variances are a bad thing.
   
   This is another common misconception of both contractors and government project managers. The bad part of this misconception is that it causes people to unwisely hide schedule or cost variances or to produce rosy estimates at completion (EACs) until an unpleasant surprise surfaces (i.e., the bad news cannot be hidden any longer). Hiding variances negates the whole purpose for implementing an EVMS. This is one of the reasons EVM gets a bad name. The EVMS is used improperly and then becomes the culprit when management or the customer is blindsided.
   
   Variances are the early warning mechanism of an EVMS. While most projects endeavor to produce a reasonable and executable baseline plan, what actually occurs as the work is performed will deviate to some degree from the plan. Consequently, the performance variances provide the ability to quickly identify deviations from the plan and determine the impact to the project. That means management can take the appropriate action to minimize the impact. This analysis provides fact-based information that can be provided to the customer about issues that are surfacing, what the impact is to project, and the actions being taken to minimize the impact. This instills confidence in the system, because the contractor demonstrates it knows how to actively manage the work effort.
   
   Variances and performance indices also provide an indication of the quality of the baseline planning process or how realistic the baseline plan was from the onset. It may be that the proposal and/or baseline basis of estimate or scheduling process needs additional work to produce better baseline plans for future projects. It highlights an opportunity to improve that initial planning process.
   
   Conversely, a good estimating or baseline process can result in small deviations in variances and performance indices as project work effort is completed. At completion performance indices can be cited in future proposals as evidence of a company's ability to effectively plan and manage projects. These indices also validate the underlying basis of estimates when planning similar projects in the future.
    
4. An EVMS is too rigid, requires too much detail.
   
   This can be true in those situations where the EVMS implementation process was not thought out or tailored to the environment. An EVMS does not inherently require more detail. A common error made by companies new to EVM is to drive the data down into too much detail. This over complicates the planning and scheduling, budgeting, performance measurement, analysis, and change control processes.
   
   What EVM does require is a defined logical approach to produce technical, schedule, cost, and risk data that are fully integrated. This is necessary to summarize the source detail data to various levels or to drill down into the data to perform root cause analysis. That means more upfront planning is required to determine a reasonable level of detail to manage the work effort based on risk and other factors for management visibility. It also means defining a useful coding approach to organize and integrate the data. This upfront effort quickly pays for itself because it provides the means for the EVMS to highlight work effort that is deviating (positively or negatively) from the plan and for management to take appropriate action.
   
   EVMS most certainly adds a level of discipline to the project management process. This is necessary to implement a repeatable process that can be described and demonstrated - this is similar to goals of the Capability Maturity Model Integration (CMMI). An EVM System is a structured collection of effective project management practices as defined in a company's EVM System Description. Projects use the same effective practices (the System Description) along with needed project specific directives to match the project's needs or contractual requirements. Implementing and effectively using an EVMS demonstrates a higher project management maturity level.
   
   Whether or not someone translates a repeatable process as being too rigid is a subject for debate. In some instances, the "too rigid" label is a result of self-induced pain. The EVM System Description should provide a foundation of sound practices that all projects are expected to follow so that a common set of performance metrics can be captured for companywide project portfolio analysis. Project directives can be used to further define how those practices are applied to a project based on the scope of work, type of contract, duration, risk, and other factors. This provides the ability to tailor or scale the EVMS as needed and yet ensure sound, effective practices are being followed.
   
   What is easy to forget are the hazards and business risks related to ad hoc processes or project management by heroics. Typical results of ad hoc processes: regularly failing to meet objectives (overruns, late deliveries, last minute scrambles to the finish line), lack of management visibility into the real status of the project (which results in unpleasant surprises), quality issues that result in rework or unhappy customers, and high frustration levels (is anyone in charge?).
   
   The important point is that the principles of EVM can be used on any project to improve the management and control process.
    
5. High cost to implement and to use an EVMS.
   
   Or the corollary to this: EVM provides limited return on investment. This is a common argument about any new process that is introduced. An EVMS may be a new contractual requirement for a company. To win the business, an EVMS is required. That immediately determines management's commitment - either implement or decline to bid.
   
   There certainly is a price tag for implementing new processes. The difficult part is determining the delta between what a company is currently doing compared to those practices noted in the EIA-748 32 Guidelines. It may be a narrow or large gap. Having an experienced independent third party conduct a gap analysis is one means to capture fact-based information about the current state of a company's project control system and project personnel's EVM knowledge level. This can provide a basis to determine what it will take in time, resources, and cost to close the gap. This can also help to perform an internal cost/benefit analysis.
   
   What is sometimes missed is that EVM is really a set of proven project management principles that can be applied to any project. It can improve the ability of a company to meet commitments, increases management visibility which helps to prevent expensive surprises, and demonstrates a higher level of project management maturity that can be used to a competitive advantage. All of these factors can reduce the overall cost to execute projects and, in turn, increase the company's profit margin.
   
   Yes, there is a cost to implement a disciplined project management process. A company's management team must make the decision to fully embrace EVM (a cultural change) or not. There is a much higher hidden cost for ad hoc project management practices that is harder to capture and measure and thus easier to overlook as it is business as usual. There are also significant costs incurred should a government customer decide a company's project control system is not up to the task or is not being implemented properly. That typically means an emergency response team has to be brought in (whether internal or external) to resolve issues that could have been averted with proactive upfront planning, and avoid a loss in credibility and goodwill with the customer. Unfortunately, some companies learn that the hard way when senior management is not fully committed at the start.

Introduction to Implementing an EVMS

An earned value management system (EVMS) is a common contractual requirement on any US federal government agency project as well as some foreign government agency projects. Requiring the use of an EVMS is a sensible approach as a means to provide more visibility into project performance whether for a government customer or for internal management.

Implementing an EVMS does require dedication and significant effort as it inherently increases the maturity level of a contractor’s project control functions. It requires a higher level of project control discipline that can impact business functions as well as the corporate culture.

Based on more than three decades of helping hundreds of companies implement earned value management systems, Humphreys & Associates experience has shown that it typically requires approximately 12 months to fully implement an EVM System. Preparing for and obtaining a system validation from the designated government agency can easily add six months or more to the process.
As with any new concept or tool, everything is dependent on how the system is implemented. The upfront planning can mean the difference between success and failure. The seven steps described below can help to expedite and manage the implementation of a compliant EVM System. The goal is to create an earned value based project control system that is embraced and used throughout the company from the highest level managers to those performing the work. Successfully implementing an EVMS can prove to be a business enhancing endeavor.

Step 1 – Management Team Commitment

Commitment and support from the management team is essential to the success of the implementation. Without it, the process will fail. Establishing an implementation team responsible for developing the strategy plan and schedule is a critical initial step. The first task for the team is to create a charter that defines its specific roles and responsibilities. With that in place, the team can focus on developing an initial implementation plan that defines the goals and objectives, scope of the effort, overall time frame and key milestones, and resource requirements (people and budget). It is also useful to include a discussion on potential risks as well as how to document and resolve problems that may arise during the implementation process.

Step 2 – Pre-Implementation Assessment

Before implementing an EVMS, it always helps to have a clear understanding of the state of the current project control system. This is essential to be able to determine the full scope of the implementation effort. Comparing the current processes and procedures to the 32 guidelines in the EIA-748 Standard for Earned Value Management Systems (EIA-748) is part of the process. It also includes assessing the level of data quality and integration as well as how company personnel are using the current system. It is important to evaluate the level of project management and earned value knowledge.
Internal EVM experts or an independent third party can conduct this assessment, sometimes referred to as a requirements analysis or gap analysis. The intent is to produce fact-based information useful for creating a more realistic implementation plan. What are the processes, tools, and training that need to be enhanced or implemented? Based on this knowledge, a resource loaded schedule can be produced that defines the specific tasks and milestones to accomplish the end objectives. This implementation plan and frequent schedule status help to manage the process and maintain focus – what’s been done and what’s left to do.

Step 3 – System Structure and Integration

At the beginning of the system enhancement or design stage, it is useful to focus on each of the subsystems that support the nine EVMS process areas and how they integrate with each other. When the customer’s reviewing agency reviews the company’s EVMS, it will look at each of the following process areas:

• Work Organization
• Planning and Scheduling
• Work/Budget Authorization
• Accounting
• Indirect Management
• Management Reporting and Analysis
• Revisions and Data Maintenance
• Material Management
• Subcontract Management

Note that risk management may be treated as a separate and additional process area or incorporated into the other process areas where appropriate. An example is incorporating schedule risk assessment into the scheduling subsystem.
The EIA-748 32 guidelines are the foundation for determining if an EVMS meets the requirements for a compliant system. Developing flow diagrams and storyboards are useful tools at the beginning of the design phase to note what needs to be added or enhanced to create a fully integrated EVMS as well as to satisfy the EIA-748 guidelines.
An EVMS storyboard illustrates all of the EVMS process areas as cross functional flow diagrams on panels or a conference room wall. It depicts the integration of all the process areas and clearly shows who is responsible for what, the flow of functions, inputs, outputs or products, and actions using real company project artifacts. The storyboard illustrates the complete system as well as the various interactions between the different subsystems, functional organizations, and project artifacts. The contractor will also need it for demonstrating how its system works to the government reviewing agency’s team. It is also very useful as the basis for an EVMS training program.
Once this preliminary design is laid out and approved by the implementation team and management, a more comprehensive effort to design or modify forms, practices, and subsystems can begin.

Step 4 – The System Description Document

The primary document for describing the system and how it satisfies the EVMS guidelines is the EVM System Description. Internal formal procedures support this document. The system description and related procedures are meant to be the all-inclusive explanation of the EVMS characteristics and how the system is used to manage a project from inception to completion. The EVMS storyboard and system description are complementary work efforts. An excellent starting point for the system description is to develop an outline that describes the subsystems for each of the nine process areas. Include references to completed forms and reports. If a form or report exists, include it as an example. If it does not, then one should be created and incorporated into the system process. Some companies also find it useful to create desktop procedures to help ensure that the end users understand how to use a specific toolset to complete typical actions such as statusing a network schedule or completing a baseline change request (BCR).
It is also strongly recommended that a cross reference to the EIA-748 guidelines’ 162 management system characteristics (MSCs) is included as part of the EVM System Description. This is important to fully demonstrate that specific system description content, forms, or reports support the requirements.

Step 5 – Training

Training is an important part of the implementation process. This includes upper level management, project managers, functional managers, control account managers (CAMs), and analysts. The training should reflect the EVM System Description as the government reviewing agency’s team will assess whether or not a project is following the company’s EVM System Description. The development and execution of the training plan as part of the overall implementation plan helps to ensure the various end users complete the training they need. Training tailored for the various end user roles helps to engrain the new process more quickly. Training may be more in depth for analysts and CAMs or summarized for upper level management. Having a strong set of instructors in place makes it easier to continually train new and existing users. This also helps to increase the confidence level and knowledge base within the company and provides the foundation to keep improving the application and use of the EVM System.

Step 6 – System Implementation

System implementation on a pilot project requires dedicated teamwork and is the most time consuming of the seven steps. An easier approach is to implement the EVMS on a new project so that all project artifacts reflect the system description at the onset. An existing project can present extra challenges as it may be necessary to recode data or enhance the quality of the data, incorporate new forms, or undertake forensic accounting to create contract budget base (CBB), management reserve (MR), and undistributed budget (UB) logs.
Once a company becomes comfortable with its EVMS, each future project must be planned and managed using the EVM System. This is where the benefit from implementing the system becomes more apparent over time. Management gains confidence in the system to provide timely and reliable information that it can use to make informed decisions. An actively used EVMS can help project managers to manage their work effort with less stress because they can quickly respond to issues and problems. Projects that are run effectively and efficiency often translate into higher profit margins and result in more company business.

Step 7 – Operation and Use Verification

Once in place, periodic internal reviews, sometimes called self surveillance, can be done to ensure that the EVMS implementations on the various projects continue to comply with the company’s EVM System Description. This helps to prevent the system from atrophying over time. It also provides an opportunity to address additional training needs, resolve common implementation issues, and enhance the system. A common approach for companies with a long history of using EVMS on its projects is to form peer review teams. An example would be reviewers from a different project or another division performing a review on a given project. This provides a degree of independence that can help to identify problems or issues. These companies develop an annual schedule of the reviews they will conduct based on a number of factors such as risk, the number of change orders, type of contract, size of the contract, project phase, etc. This can also include EVM contractors and EVMS  subcontractors when the EVMS requirement has been flowed down to the subcontractor. Independent third parties can also assist with the self surveillance process. This provides an added benefit with using experienced outside consultants who regularly perform mock validation and other types of reviews. The outside consultant team can also update a company on the latest issues the government agency review teams are focusing on, provide a fresh look at how an EVMS is used on a project, or bring new ideas to the table that can improve the company’s EVM System. Similar to the implementation and use of the EVMS, it is important to establish a repeatable process for self surveillance, capture the results from the self surveillance, identify the problem areas, identify actions to address the root cause of the problems, and track them to closure.

Earned Value Management Concepts

EVM concept presented in these requirements is a sound management approach, that once incorporated on any type of program, whether research and development, construction, production, etc. provides all levels of management with early visibility into cost and schedule problems.  Earned value management is now used on programs world-wide.

The basic concept of EVM is more than a unique project management process or technique.  It is an umbrella term for 32 guidelines that define a set of requirements that a contractor’s management system must meet.  The objectives of an EVMS are to:

• Relate time phased budgets to specific contract tasks and/or statements of work.
• Provide the basis to capture work progress assessments against the baseline plan.
• Relate technical, schedule, and cost performance.
• Provide valid, timely, and auditable data/information for proactive project management analysis and action.
• Supply managers with a practical level of summarization for effective decision making.

Once the contractor’s EVM System is designed and implemented on a project, there are significant benefits to the contractor and to the customer. Contractor benefits include increased visibility and control to quickly and proactively respond to issues which makes it easier to meet project schedule, cost, analysis, and technical objectives. Customer benefits include confidence in the contractor’s ability to manage the project, identify problems early, and provide objective, rather than subjective, contract cost analysis and schedule status. Earned value management does introduce a few new terms.  Contractors’ internal systems must be able to provide:

• Budgeted cost for work scheduled (BCWS), sometimes called the planned value.
• Budgeted cost for work performed (BCWP) or earned value.
• Actual cost of work performed (ACWP).
• Budget at completion (BAC).
• Estimate at completion (EAC) which is comprised of the cumulative to date actual cost of work performed plus the estimate to complete the remaining work.
• Cost variance (CV) which is calculated as BCWP minus ACWP.  A result greater than 0 is favorable (an underrun), a result less than 0 is unfavorable (an overrun).
• Schedule variance (SV) which is calculated as BCWP minus BCWS.  A result greater than 0 is favorable (ahead of schedule), a result less than 0 is unfavorable (behind schedule).
• Variance at completion (VAC) which is calculated as BAC minus EAC.  A result greater than 0 is favorable, a result less than 0 is unfavorable.

The 32 guidelines in the EIA-748 Standard for EVMS are divided into five sections which are discussed below.

1. Organization
2. Planning, Scheduling and Budgeting
3. Accounting Considerations
4. EVMS Analysis and EVMS Management Reports
5. Revisions and Data Maintenance

Let's look into these in details:

Organization

This first section includes 5 guidelines that focus on organizing the work. One of the most fundamental is that the contractor must establish a work breakdown structure (WBS) extended down to a level that describes the tasks that will be performed as well as their relationship to product deliverables. Also critical is the organization breakdown structure (OBS) that identifies who is responsible for the work effort defined in the WBS. It is at this level where the WBS (what) and OBS (who) intersect that defines a control account, a key management control point. The person responsible for the work effort (scope, schedule, and budget) is the control account manager (CAM). This is the foundation for ensuring the contractor’s planning, scheduling, budgeting, work authorization, and cost accumulation processes are fully integrated -- for the EVMS contractor's compliance. Establishing the control accounts is illustrated below.

Intersection of the WBS and OBS establishes the control accounts

Planning, Scheduling, and Budgeting

The second section includes 10 guidelines that cover the basic requirements for planning, scheduling, and establishing the time phased budgets for the tasks. The integrated master schedule is the project’s road map to meet contract objectives.  This schedule must be resource loaded to determine the budget for the work as scheduled. The resource loaded schedule is the basis for the monthly budget, or BCWS, for each task and thus the project.  This time phased budget is the performance measurement baseline (PMB). The total budget for each task, control account, or the entire project is defined as the budget at complete (BAC). Because most projects are initiated with some level of uncertainty; i.e. risk, project managers typically set aside a portion of the total project value as a management reserve (MR).  MR added to the BAC equals the total project budgeted value, defined as the contract budget base (CBB). This is illustrated below.

Establishing the baseline – an Iterative, three step process | EVM Analysis

All of the budgets on any project should be logged for successful baseline control.  Occasionally contracted tasks may be temporarily held in abeyance, not yet authorized to a manager. When the project manager has yet to assign tasks and budgets to the CAMs, such as an authorized, not yet negotiated additional work, the task and its budget can be retained in undistributed budget (UB). These budget assignments, the WBS, and the functional organizational identity of the managers can be captured in a matrix as illustrated below.

EVM Budget summary matrix

A very important aspect of the planning and budgeting process is to determine how BCWP will be assessed. This determination begins with classifying work tasks as one of three types: discrete, apportioned effort, or level of effort (LOE). From this initial classification, for each discrete work effort work package, the CAM selects an earned value technique such as milestones, 50/50, 0/100, or percent complete. It must be stressed that work only begins when there is formal work authorization to proceed.  This requirement is a disciplined approach to clearly define work, schedule, and budget before work commences and actual costs begin to accrue. How can someone be expected to manage the work effort when it is unclear what is to be done? The ad-hoc approach to managing, “Give me a charge number and I’ll tell you when I’m done with whatever I think I am supposed to do” does not work. The principles of EVM are quite clear in this regard.

Accounting Considerations

This section is a very straightforward, long standing project management set of 6 guidelines for capturing actual costs (ACWP) expended for project work effort. Actual costs must be captured in a manner consistent with the way work is planned and budgeted. The section outlines the need to select the appropriate time to schedule an important project resource, material, and to accrue performance data correctly. The section also stipulates a common sense practice to accrue the costs for the material in the same month as the BCWP was taken (earned) to avoid a very misleading cost variance, also known as “booking lag.”

Analysis and Management Reports

The fourth section of 6 guidelines is very important, inasmuch as it requires human attention to cost and schedule variances, documenting cause, impact, and correction action, and determining a new estimate at complete (EAC), if warranted. The variance calculations during Earned Value Management analysis are typically done at the control account level which provides the ability to summarize the data up through the WBS and/or the OBS. This is illustrated below.

Summarizing EVM data by WBS or OBS

As needed, the CAM or others can drill down from the control account level into the detail data analysis to identify the root cause of a variance, determine the impact of the variance on future work effort, and identify correction actions. The use of the EVM data analysis indices is a common practice to help managers consider their past performance and their future performance to complete the work within the approved EAC and estimated completion date (ECD).  This is illustrated below.

Estimate based on combined cost and schedule performance

EVM Cost and schedule variance trends

The cost and schedule indices are featured in commercial off the shelf project management toolsets and should be carefully reviewed during each reporting cycle. They serve as a valuable validity test to the estimate at completion.

Revisions and Data Maintenance

The final section is a set of 5 baseline control guidelines that emphasizes disciplined and timely incorporation of customer directed changes, including stop work orders (SWO). The rules also apply to internal replanning and project analysis. Lack of baseline control can doom a project.  Establishing and maintaining a schedule and budget baseline is essential to be able to assess work accomplished for each reporting period.  The Revision and Data Maintenance section is a must for proactive, meaningful earned value management when there is a constantly changing baseline.

Contractor and Customer Benefits

An earned value management system is an aid to both the EVM contractor and EVM customer. The benefits of implementing an EVMS can be summarized as follows. An EVMS:

• Improves the planning process;
• Fosters a clear definition of the work scope;
• Establishes clear responsibility for work effort;
• Integrates technical, schedule, and cost performance;
• Provides early warning and analysis of potential Earned Value problems;
• Identifies problem areas for immediate and proactive management attention;
• Enables more accurate reporting of cost and schedule impacts of known problems;
• Enhances the ability to assess and integrate technical, schedule, cost, systems analysis, and risk factors;
• Provides consistent and clear communication of progress at all management levels; and
• Improves project visibility and accountability.

Earned Value Management Concepts

Earned Value Management (EVM) (also known as variance analysis) is the best project control technique for early detection of performance variances. It was initially developed for the United States government to better manage contract payments to vendors. Ever since, it has grown in popularity and acceptance across many industries, and now is regarded as the preferred project control technique by PMI. However, it has not been accepted as standard practice in all industries, and it is usually a technique found in organizations or industries that are relatively mature in their management processes.

The type of questions project managers usually are asked are:

What is the progress or status of the project? How is your project performing?

No one really is interested to know the details and the day to day activities. Customers/clients and sponsors will want to know the progress because this is what ties more to the money spent or earned on a project.

Conventional Project Performance technique

If you had a budget of $10,000 (Planned/budgeted) for a project, and you spent $5,000 (Actual) so far, knowing that you spent half of your budget does not tell you much about the performance of your project, as it lacks an adequate indicator of progress; how much work did you finish by spending 50% of your budget? Are you expecting to finish the work with the remaining budget? The conventional way of project management looking at only Budgeted vs Actual costs has not been able to address such questions and provide adequate indicator of project progress.

                    

Earned Value Management System

In order to overcome the shortcomings of the conventional technique of measuring project performance, a new system was developed; the Earned Value Management system, and is now considered a commonly used method in project management to help project managers to assess and measure project performance and progress.

Earned Value Management system measures project performance by introducing the earned value concept. Earned value is a value assigned to work which was accomplished during a particular time period. This value can be stated in any appropriate measurable unit such as hours or dollars. Going back to our example at the beginning of this post, in addition to the budgeted cost of $10,000 and actual cost of $5,000, if the amount of work accomplished was 40% of the total planned work, this gives it an earned value of $4,000. Thus, we have spent 50% of the budget to complete 40% of the work, which provides an indication that we are behind schedule, and that it is likely we will be over budget by the time we finish the project if we kept performing the same way on the project.

Earned Value thus provides progress information that can be compared to the planned budget and actual cost to provide additional insight into project status.

In this post we'll have a quick review of EVM so that an awareness of the fundamental concepts will help you in your project controlling and performance reporting endeavors.

Assess cost performance and schedule performance together—The main value of EVM is that it enables you to measure and track both schedule and cost performance together. Evaluating project performance on just one of these indicators does not always give you the true picture and does not allow you to detect variances as early.

Each work package has a planned value—The planned value of any work package is the budgeted cost of the work scheduled to complete the work package. The important point here: Estimate the cost of each work package in your schedule. Also, this means that the project as a whole has a baseline schedule and budget.

At any point, the project has an “earned” value—The earned value of a project is the budgeted cost of the work actually completed. In other words, how many work packages (or partial work packages) have been completed at this time? The value is expressed in budgeted cost terms, not actual costs. This enables you to perform cost analysis by comparing budgeted versus actual costs for the work completed. The important point to consider: Be aware of the costs you expected to incur for the work that has been completed.

Basic Elements of Earned Value Management (EVM)

EVM uses three basic elements to track project progress and measure performance:

1. Planned Value (PV)
2. Earned Value (EV)
3. Actual Cost (AC)

Planned Value (PV)

Planned Value (PV) is the total cost of work scheduled/planned at a point of time. It is also referred to as Budgeted Cost of Work Scheduled (BCWS). The PMBOK defines PV as being the authorized budget assigned to work accomplished for an activity or WBS component.
In other words, PV is the total cost of the work you are supposed to accomplish at a point of time as per the schedule.

Planned Value (PV) formula

BAC is the Budget at Completion.
Notice that the formula uses the Planned % Complete, and not the actual % Complete.

Example of Planned Value (PV)

You have a project to build a billing solution, the project is expected to last 10 months, and you have estimated the total cost to be $100,000. Using Microsoft Project, you have calculated that the % Complete of the project is supposed to be 50% after 4 months. What is the planned value (PV) after 4 months?

Budget at Completion (BAC): $100,000
Planned % Complete after 4 months: 40%

Applying the formula, Planned Value (PV) = 40% X $100,000 = $40,000
Thus the cost of the work planned to be accomplished after 4 months is expected to be $40,000, this is what you should have spent after 4 month/50% completion.
Let us move on now to Earned Value (EV).

Earned Value (EV)

Earned Value (EV) is the value of the work that has been accomplished to date. It is also referred to as Budgeted Cost of Work Performed (BCWP).
In other words, it is the total of planned/budgeted cost of the work accomplished at a point of time.

Earned Value (EV) Formula

Another formula that can be used sometimes is

Example of Earned Value (EV)

Using the same above example, using Microsoft Project, after 4 months you found out the Actual % Complete = 30%, and not 40% as planned. What is the Earned Value (EV) of the work you have accomplished after those 4 months?

Applying the formula, Earned Value (EV) = 30% X $100,000 = $30,000

Notice that although you were expecting a value of $40,000 after 4 months, but the value earned of the accomplished work is $30,000, which indicates you are behind of what you originally planned. This is still though not the actual cost, which I will talk about next.

Actual Cost (AC)

Actual Cost (AC) is the total actual cost incurred in accomplishing the work to date. It is also referred to as the Actual Cost of Work Performed (ACWP).
In other words, it is the amount of money you spent on the project to date.

Actual Cost (AC) Formula

Actual Cost (AC) has no formula; it is just what has been spent to date.

Example of Actual Cost (AC)

For the above example, after reviewing the costs incurred after 4 months, you found that you have recorded $35,000 of labor cost and $10,000 of different expenses for the project. What is the Actual Cost (AC)?

The Actual Cost (AC) = $35,000 + $10,000 = $45,000

Notice that after 4 months, you have actually spent $45,000 (AC) to perform work of the value of $30,000 (EV), where you should have spent and produced work of the value of $40,000 (PV). So you can tell that after 4 months, you are above budget by $5,000 so far (AC > PV), and that you are behind schedule from what you have planned (EV < PV).

Now let’s review the other key terms and concepts that comprise EVM. The table shown below summarizes these key elements:

As you may have noticed, EVM takes the planned value (PV), or what you planned to do at an estimated cost, and compares it against the estimated cost of the work performed (EV) and against the actual cost of work performed (AC), or what actually got done. These metrics provide a wealth of information about whether the project tasks are taking longer than they should (schedule variance, or SV), or whether they are actually requiring more work effort to complete (cost variance, or CV). In addition, the estimate-at-completion metric (EAC) helps you forecast final project performance and determine if any corrective action needs to take place.

Let's take another example to illustrate how EVM could be used for performance reporting. In this example, the report provides EVM data for the fourth reporting period. At this time, the Planned Value = $75K, the Actual Costs = $100K, and the Earned Value = $60K. On this project, we can tell the following by analyzing this report:

• There has been a cost variance from the start. It could be the actual resource costs have been higher.
• Also, for the first three weeks, the project was ahead of schedule. More work was completed than planned. This was a likely factor for the actual costs being higher too.
• During the past reporting period, something has occurred that delayed progress. The project is now behind schedule (and the cost variance has increased significantly).

Many of the project management software tools, such as Microsoft Project, include these EVM calculations. To be useful, the schedule must include all assigned resources, individual resource costs, and current progress measurements. The figure below depicts EVM metrics for the fourth time period on a sample project:

This was a brief overview of EVM. In the next post we shall continue with EVM .