What Exactly Is a Project Change and What’s the Big Deal, Anyway?

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. We review the key elements of this system later in this chapter.

Now, if you find yourself managing an agile project, you might be tempted to think “I don’t need to worry about this change stuff, since change is encouraged and part of the innate process.” Not so fast, my friend. We will talk more about this in Chapter 25, but while agile approaches do have built-in processes to identify, prioritize, and manage scope changes, that does not mean the changes won’t impact the budget, alter the schedule, or require additional resources. All of this requires proper management. And this is especially true for contractual projects.

Relation to Configuration Management and Organizational Change Management

To further clarify what is meant by a project change, let’s review two other change-related components of project management: configuration management and organizational change. This is a common area of confusion because change control management, configuration management, and organizational change management are somewhat interrelated, they all deal with change, and they all are a part of project management. As illustrated in Figure 11.1, we are focused on change control management in this chapter. Table 11.1 summarizes the key differences between the three.

	Change Control Management	Configuration Management	Organizational Change Management
Target	Project critical success factors	Project deliverables and product	Organizational impact of the project results
Primary Concern	Project performance; stakeholder expectations	Integrity of project deliverables; tracking changes in project deliverables	Preparing individuals, organizational units, and customers for the changes
Related Terms	Change control; scope management	Document management, versions, and builds	Change management
Discussed In	This chapter	Chapter 12	Chapters 18 and 20
Notes	Focus on scope can overlap with configuration management	Can be part of project’s overall Change Control Plan	Not regarded as a project control activity

Fundamentals for Managing Project Change

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

• 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 (to be discussed next). For projects with an innovation focus or a volatile set of requirements, an iterative or agile development-type approach that expects deliberate scope expansion or scope clarification should be utilized.

• 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. We discuss the details later in this chapter. The key benefits for establishing a formal change control system include the following:

  • Helps protect the integrity of the project performance baselines

  • Ensures that the right people are involved in the decision-making process

  • Helps manage stakeholder expectations

  • Enhances the credibility and professionalism of the project manager

  • Prevents issues and confrontations when changes do occur

• 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.

• 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.

• 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 must 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).

• Overcommunicate—For effective stakeholder management, make sure that all project changes are clearly communicated and understood by all key project stakeholders.

• Be a watchdog—As a project manager, you must be continuously alert and mindful about 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.

What Causes Unplanned Scope Changes?

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.

• 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

• Shift in project acceptance criteria—This one addresses changes in any one of the following: the targeted completion date, financial return on investments, client satisfaction ratings, quality levels, other expected benefits, or the stakeholders who need to approve.

• 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.

• 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. Of course, this would happen only on projects that you inherited and would never happen on projects that you helped define. Right?

• Poor requirements definition—There are entire training courses on requirements definition and requirements management due to the importance they play in project success. Suffice to say, the more gaps that you have in your requirements, the more scope changes you are likely to have. For your awareness, 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 not aligned with project scope

  • Requirements not addressing complete process workflow

  • Documented requirements not meaningful to targeted audience

  • Requirements not reviewed for inconsistencies

  • Requirements not verified for correctness and completeness

  • Missing stakeholders

  • User sign-off without a real understanding of what the documented requirements mean

Essential Elements of a Project Change Control System

At the heart of managing project changes well is a project change control system. The specifics of project change control systems can vary depending on industry, organization, and project importance, but every change control system should possess certain essential principles, guidelines, and components.

Powerful Techniques for Minimizing Project Changes

Although we want to be prepared for project changes when they occur, we want to spend most of our energy preventing the need for changes in the first place. The following techniques are powerful change prevention actions we can take:

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

• Solid requirements definition—As mentioned before, the more complete requirements are defined and understood, the likelihood of scope changes are reduced.

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

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

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

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

  • Emphasis on project definition and planning

  • Shorter timeframes (1 year or less is preferred)

  • Pilot tests

  • Phased implementations

  • Go/no-go decisions at phase ends

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

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

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

Common Project Change Control Challenges

Before we end this chapter on managing project changes, let’s look at the challenges faced by many project managers. Here’s a list of things to either avoid or be on the lookout for:

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

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

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

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

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

• Is it really a change?—Not that this ever happens, but sometimes stakeholders do not agree on what really is an official change. I know—it’s hard to believe. Especially in contractual arrangements, the issue isn’t always “Is it a change?” but rather “Do I have to pay for it?”—a slightly different matter. There are no silver bullets here. Most of the disagreements occur because of ambiguity or inconsistencies in the specifications. Just do the other things previously mentioned, and you should have a solid foundation to deal with this, if it ever happens.

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

• Inadequate impact analysis—You are exercising your change control system. The change request is being assessed. You are in good shape—right? Probably. Just make sure the analysis performed on the impact is complete. At the minimum, verify the following on any change request assessment:

  • Has the total work effort been accounted for? All supporting processes? All impacted deliverables?

  • Have the implications of the request been completely considered?

  • Have all impacted stakeholders been considered?

• Beware of the little guys—On most projects, there will always be one or more of those small, minor scope changes. Sometimes they are clear changes; other times, they fall into a gray area. In an effort to build relationships and please the customer, many project managers do not document these if they feel the change requires minimal effort to implement. Be very careful here. Before you know it, you can easily have a series of these little changes that, when added up, can affect your project. In addition, you must manage the expectations you are setting if you overuse this technique. As a rule, I would encourage you to at least document every change—no matter how small. For small ones, you might choose to group them into a single change request.

The map in Figure 11.2 summarizes the main points reviewed in this chapter.