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 .

Techniques for Project Control

In the previous post We emphasized the value and importance of planning your control system. In this post, we highlight some of powerful project control techniques that you want to consider during your planning efforts and then implement during the execution of your project.

Small work packages—This was a point of emphasis during our discussion on building a WBS. If you recall, there were two primary reasons for advocating small work packages: more accurate estimates and better control. From a control perspective, if your work packages are scheduled to complete within one (or at the most, two) reporting periods, it is much easier to detect a delayed or troubled task. With earlier notice, you are more likely to resolve the variance and protect the project’s critical success factors.

Baselines—A fundamental control principle is to manage to baseline.

First, establish a baseline. This is generally applied to the critical success factors of schedule and budget, but you can apply it equally as well to product-oriented aspects of the project, especially requirements. Second, measure and report performance against the baseline. Third, maintain the baseline unless there is a formal agreement to reset the baseline.

Status meetings—The simplest, and most widely known, technique is the status meeting. Consistent and regular status meetings help to keep everyone honest, accountable, and on their toes—especially if work assignments are small and have clear completion criteria. In addition, status meetings are powerful tools for improving project communications and managing expectations.

Completion criteria—This starts during project definition with defining the acceptance criteria for the project, and it continues for each deliverable and work assignment. Answer this question in advance for each deliverable and work assignment: “How will we know when it is done?”. Understanding the completion criteria upfront increases productivity and avoids many of the issues associated with status reporting on work tasks, especially the infamous “I’m 90% done” syndrome.

Reviews—Reviews are a key technique for ensuring quality and managing expectations on project deliverables, and they can take many forms. The principle here is to plan for the review-feedback-correction cycle on most, if not all, of your key deliverables. Common examples of reviews are process reviews, design reviews, audits, walkthroughs, and testing. In addition, reviews can be combined with predefined milestones and checkpoints.

Milestones and checkpoints—A key feature of most proven project methodologies is the use of predefined milestones and checkpoints. These markers are important points to stop, report progress, review key issues, confirm that everyone is still on board, and verify that the project should proceed with its mission. Besides being a powerful expectations management tool, these predefined points allow project sponsors and senior management to evaluate their project investments along the way, and, if warranted, redirect valuable resources from a troubled project to more promising pursuits.

Track requirements—A simple, yet often neglected, technique to help control both scope and expectations is the use of a requirements traceability matrix. The traceability matrix provides a documented link between the original set of approved requirements, any interim deliverable, and the final work product. This technique helps maintain the visibility of each original requirement and provides a natural barrier for introducing any “new” feature along the way (or at least provides a natural trigger to your change control system). In addition, the trace matrix can link the specific test scenarios that are needed to verify that each requirement is met.

Formal signoffs—Formal signoffs 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. Most importantly, the use of a formal signoff acts as an extra incentive to make sure the appropriate stakeholders are actively engaged in the work of the project.

Independent QA auditor—The use of an independent quality assurance auditor is another specific example of the “review” technique mentioned earlier, and it’s often a component of project quality assurance plans. In addition, the quality audit can be focused on product deliverables, work processes, or project management activities. The power of this technique is in establishing the quality criteria in advance and in making the project accountable to an outside entity.

V method—The V method is a term used for a common validation and verification approach that ensures that there is validation and verification step for every deliverable and interim deliverable created. The left side of “V” notes each targeted deliverable and the right side of the “V” lists the verification method to be used for each deliverable directly across. The diagram shown below helps illustrate this method.

 

Escalation thresholds—Escalation thresholds sound much more ominous than what they actually are. The purpose of escalation thresholds is to determine in advance what issues and variances the project team can handle and what issues or variances demand attention by senior management. Often, these thresholds are defined as percent variances around the critical success factors. For example, if the cost variance is greater than 10% or schedule variance is greater than 15%, engage senior management immediately for corrective action steps. The key value of this technique is that it helps define tolerance levels, set expectations, and clarifies when senior management should get involved in corrective action procedures.

Performance Reporting

Another key aspect of project control is measuring and reporting project performance. if you keep these following principles in mind, you can adapt your performance reporting process to best meet the needs of your project environment:

Answer the big three questions—As a rule, key stakeholders want to know the answers to the following three questions when reviewing project performance:

1.     Where do we stand (in regard to the critical success factors)?

2.     What variances exist, what caused them, and what are we doing about them?

3.     Has the forecast changed?

Measure from current baseline—If you are going to report project performance with a variance focus, you must establish and maintain your performance baselines. Any change to the performance baselines is controlled via your change control procedures.

Think “visual”—Another key concept in reporting is to think visually. Most people are visual and spatial learners and will grasp the important project performance metrics more quickly if they are presented in a visual format. The use of bar charts, graphical schedule summaries, and stoplight indicators (red, yellow, and green) for key metrics are good examples of this technique.

Think “summary page”—Along this same theme, you generally want to provide your key status information in no more than one to two pages. If it is appropriate to have details that will take more than one or two pages, it is recommended that you provide a one summary page upfront.

Highlight accomplishments—A part of the status report’s function is to serve as a public relations tool for the project, so make sure key accomplishments are highlighted prominently.

Show forecasts—In addition to reporting how the project has performed to date, remember to show the forecasted schedule and cost metrics. Often, this information is shown as Estimated At Completion (EAC) and Estimated To Complete (ETC) figures. Specifically, highlight any changes to these figures from the last reporting period.

Highlight key issues, risks, and change requests—A natural category when assessing project performance. Make sure any key issues, risks, and change requests are included on status reports.

Avoid surprises—An important point about consistent, performance based

status reporting is that stakeholders are aware and knowledgeable regarding overall project status and are not caught off guard with project developments. To this extent, depending on the audience for any status report, you might want to communicate with specific stakeholders in advance of any official report distribution. Always remember, don’t surprise anyone—especially your sponsors and accountable senior management stakeholders.

Adapt to meet stakeholder needs—This is an example of the customer service orientation and servant leadership qualities of effective project managers. Be prepared to offer examples of performance reports that have worked well for you in the past, but most importantly, go into any project looking to understand the information needs for this given environment. Show enthusiasm and willingness to adapt to the customer’s standards or to develop custom formats to best meet the stakeholders’ needs.

Appropriate frequency—Consistent with a management fundamental mentioned earlier, the frequency of performance reporting needs to be appropriate for the project. The process of gathering information and reporting performance needs to be quick enough and occur often enough to be useful and relevant.

Variance Responses

As we have mentioned, the first goal of our project control system is to prevent any variance. However, we also realize variances and changes will occur—this is the nature of the project beast. Thus, the remaining goals of project control are centred on early detection and appropriate response. Let’s review the general response options that are available to us (the project) when a variance occurs.

Take corrective actions—The preferred option, whenever possible, is to understand the root cause of the variance and then implement action steps to get the variance corrected. When performance measurement is frequent, it is more likely that action can be taken that will make a difference. Examples of corrective actions include adding resources, changing the process, coaching individual performance, compressing the schedule (fast tracking or crashing), or reducing scope (this would be documented as a change request, too).

Ignore it—In cases where the variance is small (and falls within an acceptable threshold range), you might choose to take no action to resolve the deviation. Even in these cases, it would be advisable to log the variance as a risk factor.

Cancel project—There might be times when the appropriate response is to cancel the project altogether. This response is more likely on projects where one or more key assumptions have not held or when one or more of the critical success factors has a very low tolerance for any deviations.

Reset baselines—While taking corrective action is the preferred option for performance variances, there are times when the variance cannot be eliminated. This is common on knowledge-based projects and common on projects where the estimating assumptions have not held. In these cases, a decision to reset the performance baselines is made and approved. Then from this point on, performance is measured from this revised baseline.