Scope change control

Abstract

Let us start with a few questions to see if this topic is aligned with your needs:

1. Has every project you have ever been involved with delivered exactly what your business partners or users asked for during the initial phases of scope definition?
2. Have your customers always been completely satisfied with the deliverables at project completion because you delivered exactly what they wanted?
3. Does your team always have complete user involvement and fully understand the scope of what they are being asked to deliver before work begins?

If you are either laughing hysterically or squirming in your seat because of a rush of bad memories, then read on … you are not alone. This paper will introduce the concept of scope change control, with a focus on practical application. We will begin with a review of why projects fail and include a summary of well-documented research supplemented by practitioner experiences in the field. Topics will include not only the potential impact of poor scope change control on your project, but also how project challenges influence perceptions about the project manager, project team, and performing organization. Based on these factors, this paper will provide recommendations to develop a practical approach to this all-too-real factor that influences almost every project, program, and portfolio. A real-world application of the presented content will highlight the need for, and benefit of, standardized change control processes.

Introduction

Projects are about change, and strangely enough, lack of change control is one of the biggest barriers to project success. If project managers do not take advantage of the best practices for documenting and controlling the scope of work on their projects, they are doomed to be controlled by:

1. The whims of stakeholders and project team members
2. Stakeholders with bad memories about what was (or was not) in scope
3. Stakeholders with good memories that know exactly what was originally approved but choose not to remember
4. Great ideas that can have serious consequences to the project's schedule, cost, and final benefit

Just as the shortest distance between two points is a straight line, the best approach for controlling project scope is with a direct, simple method that project stakeholders understand and can follow. Of course, to draw a straight line, you have to know where to start and where to finish. Do you know your “points?”

Why Do Projects Fail?

A simple internet search on “Why Projects Fail” will produce thousands of results that include articles, papers, published research, and blogs that attempt to answer this question. According to the “The Chaos Report” published by The Standish Group (1994), incomplete requirements, changing requirements, and unclear objectives were three of the top 10 factors contributing to challenged projects. The AST Group (2001) lists incomplete project scope and a lack of formal project management methodologies as two of the top 10 reasons that projects fail. Eric Rosenfeld (n.d.), with Adaptive Consulting Partners, LLC, states that vague, unstable requirements will reduce any project's reasonable chance for success.

Of course, we do not need to rely on published research to get a list of leading causes for project failure. Discussions with students, peers, and practitioners have led to a similar list of causal factors for project failure. A Pareto analysis conducted on survey results from over 500 professionals from the Greater Louisville area from February 2005 through June 2008 led to the following list of the four top causes for project failure:

1. Poor or incomplete requirements
2. Scope creep
3. A lack of a structured project management methodology
4. Lack of change control

Either through published, professional research or through information solicited from local practitioners, whenever a list of reasons that projects fail is being developed, scope change control is certain to be on the list. Common causes, such as incomplete requirements, poorly defined requirements, no scope verification, and scope creep all point back to a lack of structured scope management and scope change control.

The Impact of Change on Projects and the Project Manager's Credibility

Scope change is inevitable. Scope change is natural. It is important to understand that our job is not to stop scope change, but to successfully manage that change.

What do all projects have in common? We only need go to the A Guide to the Project Management Body of Knowledge (PMBOK^® Guide)---Third edition to find the textbook definition of a project (Project Management Institute [PMI], 2004), but most will agree that all projects share some basic characteristics. First, there is a definable objective. More formally, projects are a temporary endeavor undertaken to provide some unique product or service (PMI, 2004). Second, projects have boundaries and constraints as related to costs, schedules, and resources. There is an additional commonality that is not a part of the formal definition of a project, but heavily influences project-related decision making. This unspoken common factor is based on Albrecht's Theory of Service Relativity. The Theory of Service Relativity states that your customer's perception of value is equal to the delivered reality less expectations (Albrecht, 1998). Like it or not, our stakeholders will develop a value perception of the project deliverable(s), the project management processes, and the project manager. Our ability to manage scope, and their expectations as related to scope, will directly influence this perception.

Our customers base their opinions about the quality of the project outcomes on their expectations as compared the actual delivered product or service, or V = R – E. Where V is value, R is reality, and E is expectations (Albrecht, 1998). If the delivered product or service does not meet their expectations, then the E value (expectations) is greater than the R value (reality), which leads to a negative value perception. If the delivered product or service exceeds their expectations, then the R value is greater than the E value, which leads to a positive value perception. This paper suggests that the best target perception value for project managers to strive for is zero or slightly positive. This indicates that the project has either perfectly met expectations or slightly exceeded expectations. One could argue that more would be considered gold plating if there was a cost associated with the delivery.

If we accept that project management is the discipline of organizing and managing resources in such a way that the project is completed within defined scope, quality, time and cost constraints (PMI, 2004), then it is not a stretch to accept that one of our primary roles as project manager is to manage that defined scope, while ensuring that we are meeting expectations. Here is another thought provoking question… Which of the elements of Albrecht's Theory of Service Relativity, as related to projects, is easiest to proactively manage? Consider these statements;

• Even the most talented, effective project managers cannot control a customer's perceptions. (Note: controlling perceptions and managing perceptions are not the same concept.)
• The final product or service, or the delivered reality, is a function of the many factors that influence what, when, and how we deliver and is frequently beyond a project manager's control.
• Statements (a) and (b) would lead one to conclude that influencing the customer's perception of value can most easily be achieved by managing expectations to ensure that those expectations match what will be delivered.
• Hmmm … this sounds like integrated change control!

Poorly managed change control has a negative influence on our customer's expectations and their opinions about our effectiveness as project managers. Of course, this is just scratching the surface of the cascading impacts of a lack of change control. Although many of the additional impacts, such as cost variance, schedule variance, team morale, resource management, and so on are inseparable from perceptions of a project's success and the project manager's effectiveness, these are outside the scope of this paper. (No pun intended.)

Build Your Home on a Strong Foundation: The Underpinnings of Scope Change Control

Do you think that the architect planned for the Torre pendente di Pisa, or the Leaning Tower of Pisa, to have a southeast lean while adding height and weight to the first floors? How many of us as children asked our parents or teachers, why is the tower leaning? The answer is simple. The foundation was weak. The loose rock and soil allowed the foundation to shift, or change, direction. The tower now leans to the southwest. So what is the monumental lesson learned? Build your house on a strong foundation to prevent unplanned changes, whether sudden and obvious changes or slow and undetectable changes. Notice that the emphasis here is on a strong foundation, not a complex foundation.

You cannot have accurate speed control without defining the speed limit. The same is true with scope. The true value of a structured approach to scope change control is realized when there is a process in place to define scope. The foundation for scope management is scope definition.

One of the primary benefits of defining scope is to ensure that everyone is on the same page. We generally do not just hop into our vehicles and start driving without knowing where we intend to go. We may not know the exact route we plan to take, but we know where we want to be when we have reached our destination. Scope definition is similar to determining where you want to go. By defining scope, you are clarifying objectives and setting the exit criteria for project completion. During the decomposition process, as you develop your work breakdown structure (WBS), you may change how you plan on meeting the objectives, but the objectives remain constant.

Uh-oh … what if we change our mind about our destination? Scope change management addresses this very issue. Remember, change is natural; change is expected. The best of the best project managers seek not to stop change, but to control change. Add a new destination or determine the new objective; complete an impact analysis to ensure that everyone understands what the change request does to the project; get approval for the change (there's no such thing as informal change control); and then update your plan to include the new objectives.

Can you get into your vehicle to drive somewhere and end up in a place that you want to be without determining ahead of time where you want to go? Absolutely …if you are lucky! However, is that the most effective way to plan your travel? How could you increase your odds of ending up where you want to be? Or, how would you increase your chance of being lucky? Determine your destination before leaving the driveway!

Now, absent of analogies, what does this mean? Simply stated, “Charter your projects.” Define the business problem that you are attempting to solve. Break the issue down into objectives that can be measured. The goal is not to develop a complex metric that requires statistical analysis to provide evidence of success. A simple “one” or “zero,” or “yes” or “no,” will do in some cases. The point is that a project objective should have an associated metric or measurement to determine completion. This is where we begin to manage expectations to ensure that the final deliverable's reality is considered to be of value. Remember, V = R – E. There are many more elements to a fully developed project charter, but the end-state goal is to have a documented, agreed upon preliminary scope to serve as the foundation on which to build.

Steps to Develop a Practical Approach to Scope Definition and Change Control

Step 1: Be Lean

Trying to introduce any type of structure or control in an organization or environment that has been absent of controls can present a significant challenge. Before a project management organization can address scope change control, they must implement a process to define scope. Getting organizational decision makers to accept the project management precepts is not overly difficult, but changing organizational behavior to leverage these principles is another matter altogether. The more change we attempt to introduce into an environment, the more difficulty that environment has in adapting to, accepting, and embracing that change. To avoid the natural resistance to excessive change, a logical approach is to limit the scope of change and focus on immediate needs. Focus on the foundation and basics. Why have a complex, highly mature process if you are not consistently performing the basics well?

Step 2: Define Preliminary Scope

What is immediately needed for an organization without processes for capturing the business objectives associated with project requests is to define a structured approach for documenting, evaluating, and approving the preliminary scope of work. Note that approving the scope of work involves more than shaking heads, shaking hands, or a casual agreement on broad, subjective criteria. Approvals, in project management, imply documented endorsements. More simply, these are signatures that provide evidence of agreement and a foundation on which to build. It is important to emphasize to stakeholders and sponsors unfamiliar with our profession's structured approach to managing projects that accepting a preliminary scope of work does not mean that you are locked in for the remainder of execution. Nothing could be farther from the truth. Instead, you are protecting their interests by beginning to set boundaries upon which effective planning can begin. In other words, you are increasing the probability (remember the research) that the project will be successful.

Step 3: Develop an Understanding of What Final Acceptance Means to the Project Sponsor or Sponsors

How do we know when we have arrived at a destination? When traveling, we know our trip is complete when we arrive at the place that we intended to reach. Likewise, we know that a project is complete when we have delivered on the business objectives identified in the project charter, right? Well, yes … and then some. The “and them some” is the focus of scope change control. How does your organization define final sponsor acceptance? The recommended approach is to define sponsor acceptance for stakeholders using plain language. Sponsor acceptance is therefore defined as the formal recognition that the objectives defined in the original agreed upon scope of work, plus the objectives agreed upon in all of the formally approved change requests, have been met. This plain definition helps to avoid the differing perceptions around what was wanted versus what was documented.

Step 4: Define, Document, and Communicate a Structured Approach to Requesting, Evaluating, and Approving Change Requests

What is a change request? Some schools of thought suggest that changes are limited to requests for additional features, deliverables, or work. Although this paper is focused on these types of change requests, or scope change requests, it is important to note that any change that has the potential to impact expectations should follow a formalized change request, approval, and communication process. Remember, aggressively managing expectations is our best opportunity to influence our stakeholder's perception of value. Scope, budget, schedules, and risks are typically interdependent and directly influence our stakeholder perceptions. Also, remember that the most effective change control processes include risk assessments that evaluate the potential risks of either approving or disapproving a change request.

Keep in mind that too much bureaucracy, too much analysis, or too much unnecessary paperwork will give stakeholders an incentive to circumvent your process. If you want your stakeholders to avoid, ignore, or completely bypass your process, include a great deal of “administrivia.” “Administrivia” is the new word for trivial administrative process. Remember, our profession's focus is on delivery and business results, not just adherence to a predefined process. Taking a lean approach to scope change request documentation can help influence acceptance of this sometimes painful but vital process for capturing change.

Process tip: Determine early (either as an enterprise standard or for your specific project) what the tripwires and associate levels of authority are for approving a requested change. What level of change can be approved internally? For example, a change with an impact of less than 1 week schedule delay or budget impact of under $10,000 may be approved by the project manager. What needs to be escalated to the project sponsor? What needs to be reviewed by a change control board or governance council? Determining these decision points in advance can remove a great deal of the mystique around how to manage change.

Ensure that everyone understands the difference between the natural decomposition process and identifying new work that must be accomplished to deliver on a previously agreed upon business objective and work associated with new or modified deliverables. Remember that omissions and errors in planning may lead to schedule and budget changes, but are usually not scope changes.

Step 5: Document and Validate the Full Scope of Work (Create the Work Breakdown Structure)

A great approach for defining all of the work required to complete a project is to start with the desired end state and associated expected benefits. What work is required to provide those benefits? What work is required to reach the approved end-state goals (or business objectives)? Plan to the level of detail necessary to manage the work effectively. Decomposing work packages beyond the level required for effective management is considered administrivia. Note that defining and communicating the processes for final sponsor acceptance and requesting changes both come before traditional decomposition. Why? Terrific question! The natural planning processes that we follow in breaking down business objectives into definable work packages can be a catalyst for change requests. We want to communicate up front that change is not free and that additional requests will need to be formally requested, documented, agreed upon, and approved before being included in the project scope of work.

Step 6: Manage Change

Your foundation is laid, you have documented the preliminary scope, you have defined processes for sponsor acceptance, you have defined and documented scope change request processes, and you have developed your WBS; now the only thing left for you to do is to manage according to your policies and plan. You also have to manage the change requests that are guaranteed to come too! Scope change control protects the project manager, and the performing organization, from scope creep and contributes to managing stakeholder expectations.

A question that frequently comes up among practitioners is “What do I do when my leadership does not allow me to define, document, and manage change?” This is a real, practical question that deserves a response. The instinctive tactic is to communicate the necessity for a structured approach to documenting and managing scope. However, as our peers will often admit, this is not always sufficient to get the support we need to set organizational policy. We can attempt to implement these processes without formalization, or we might just “do it anyway.” This can be an effective approach for demonstrating their value, but can also be perceived as a self-protective measure instead of a process used to increase the likelihood of project success. People can be leery of someone else documenting requests, justifications, and so on, for their needs. Ensure that you share the information and provide an explanation as to why this approach is designed to ensure that you are managing to their expectations. In general, people find it difficult not to accept altruistic approaches to meeting their needs.

Learn from Other's Lessons: A Real-World Application

Leveraging experience, best practices, and lessons learned, the Churchill Program Management Office began with the basics; they chartered their project management office (PMO). The three-fold mission of the newly founded PMO was to establish, facilitate, and manage the project portfolio selection and funding process; create a foundation for consistent project success throughout the organization through development of a strong and pervasive project management discipline; and to guide key projects to a successful conclusion by providing project management leadership, while improving the quality and repeatability of related processes. Sounds fairly standard, right? The mission was then broken down into specific objectives and successful completion of these objectives was tied to the PMO director's compensation.

PMO objectives included:

1. Develop and implement standard processes for project requests, evaluation, and funding to ensure hat approved projects were aligned with Churchill Downs Incorporated's business goals and objectives
2. Develop and implement a standardized project management methodology, to include policy, standards, guidelines, procedures, tools, and templates
3. Build project management professionalism by providing mentorship, training, and guidance to project teams as they learn and adopt project management processes and best practices
4. Manage the Churchill Downs Incorporated project portfolio by ensuring that required documentation is in place and that stakeholders are properly informed about the ongoing progress of the project portfolio through effective reporting of key performance indicators
5. Direct proj ect management for key strategic initiatives
6. Ensure benefit realization by define processes for clearly defining business cases and the associated metrics for measuring project success. Facilitate post-implementation benefit measurement and reporting.

As related to change control, we wanted to ensure that the process was lean, that our stakeholders understood the importance of the process, and finally (and arguably most importantly), we communicated in a way that our stakeholders understood and could follow the change request processes. Here is a thought-provoking question for our practitioners: “Why do we expect our stakeholders to learn and understand our vernacular?” To aid in understanding and training, we developed visual tools documenting our overall project management processes in a language that they understood. For example, the project “race track” (see Exhibit 1) demonstrated to our leadership and project team members what we, in our profession, take for granted as universally understood: that projects have a defined start, a defined finish, and require certain documentation throughout the planning and execution processes to ensure that everyone understands expectations and that we will realize the intended benefit from the investment.

Exhibit 1 – Project Race Track

For Churchill Downs Incorporated, scope change control begins with the foundation of a completed investment request worksheet (or business case) and an agreed-upon scope of work as outlined in a signed charter. The work is then decomposed to the level of detail required to control the effort and complete the work necessary to deliver on the requested and approved objectives as detailed in that charter and approved scope change requests. A scope change request consists of a simple-to-understand, fill-in-the-blank template, and the process is facilitated by the project manager. More important, the scope change request form is used to document the business objectives for a change request, the metrics needed to ensure that the change's benefits are realized, the impacts on schedule and costs, the funding source, and the necessary approvals required for including the request in the overall scope of work.

Some of the benefits that Churchill Downs Incorporated have realized to date from this structured approach to documenting and controlling scope include:

1. Retroactively documenting scope for legacy projects, which resulted in canceling projects that were plagued with uncontrolled change to the point that the final product would no longer deliver the benefits presented in the business case
2. Denying scope change requests based on factual return on investment and impact analysis
3. Ensuring that requested scope changes would contribute to the business objectives approved by the investment council
4. Empowering project team members to say “no” to informal change requests that may or may not provide a quantifiable benefit
5. Demonstrating that seemingly great ideas might not stand up to a structured impact analysis

Conclusion

Do not spend your valuable time seeking directions to an undetermined destination. Gain agreement on the business objectives of your projects, document the scope of work required to realize the benefits of the project, and control the scope of your projects so that your projects do not control you.