Controlling Change Requests

Changes are an important part of any project. There are 2 factors at work that guarantee the generation of change requests: changes that happen to the marketplace the project is aimed at and an unclear understanding of the goals and objectives of the project. The first factor is immutable, we can’t stop the world outside our door changing whether we like it or not. Successful projects are agile enough to respond to those stimuli and re-invent themselves so that when the product or service of the project hits the marketplace it’s the right thing delivered at the right time.

Change requests that are a result of a stakeholder’s unclear understanding of the goals and objectives of the project are easier to avoid. Clear communications about the project’s overall goals and objectives will place the project on a firm footing. Ensuring that the right stakeholders review project requirements and that the right decision makers approve them is also helpful in avoiding change requests that arise from an unclear understanding of project goals, objectives, and requirements. But no matter how diligent the project manager is in their communications and requirements gathering processes, they will still have to deal with change requests that have no value other than to clear up stakeholder misconceptions. Here are some tips on how to do that and still have time to deliver the project.

Spotting the Noise

How do you tell the difference between a change request that springs from a need to respond to a change in the marketplace, and the problem the project is meant to solve? You need to be able to make this distinction before you take the next step in the change management process. Change requests are like mini business cases and should contain the elements the business case contains. The element that concerns us here is the expected benefit of the change. A change request that articulates a benefit to be derived from making the change such as making the on-line purchase process easier, making the product more appealing to the target demographic, or changing a function to address a change in the work flow process is a change request that may add value to the project. This type of change request should flow to the next step in your Change Management process. Benefits can also accrue to the project itself. For example, a change that would reduce the amount of work necessary to build a deliverable or a change that would allow the team to deliver earlier than planned.

Change requests may not contain explicit descriptions of the benefits they bring. The Subject Matter Expert who spots the necessity to meet a new market place demand or spots the opportunity to save money or time may not be proficient at stating the business case. The implied benefit to the organization or project may be hidden in the technical description of the change requested. Your change management process should provide for requester contact information to be provided on the change request and for all requesters to be prepared to answer questions about their requests. Visit, telephone, or e-mail the requester and ask them to explain the business case in greater detail. Ask them leading questions such as "What new marketplace demand will this change meet?”, "How will this change save the project time?”, or "How much money will this change save the project?” Avoid asking questions such as "How will this change improve the system?”, or "How will this change improve quality?” These questions will open the door to discussions on why their solution is better than the one originally specified.

The description of the benefits of the change may have to be coaxed from the requester but if they cannot articulate the benefit of the requested change after several leading questions, or they insist on turning the conversation to why their solution is better than the one originally planned, end the conversation; you’ve got the information you were seeking – there is no benefit.

An Ounce of Prevention….

You have an obligation to avoid time wasted on drafting change requests that don’t benefit the organization or the project, here’s how you do that.

State the project goals and objectives clearly in theProject Charter, the Business Case, and the Statement of Work. Clarity of the project’s purpose is your first step in the avoidance of excess change requests. Be sure that the project’s goals and objectives are stated clearly and simply. The criteria for project success should also be stated simply and clearly, as well as any measures that will be used to verify success. Communicate your Charter, Scope Statement, or SOW to all project stakeholders. You can’t force everyone to read these documents but you can communicate your expectations and make the documents easily accessible to all the stakeholders.

Ensure you use the best practices that project management offers to gather and verify your project’s requirements. In my humble opinion, the best practices the discipline has to offer are described in the Project Management Body of Knowledge (PMBOK ®). You can study these practices and demonstrate your proficiency in project management by taking a PMP ® Course or other PMP ® exam preparation training product and passing PMI’s PMP ® certification exam. I’ve written a series of articles on gathering requirements for software development projects available on this web site and elsewhere. I’ll give you a thumb nail sketch of the key points in those articles, here.

You’re starting with a clear, concise set of project goals and objectives so you’ve met the first criterion for gathering requirements. The next is to engage the right stakeholders for input into the requirements set. The right stakeholders are those that will use the system, those who are customers or clients of the system, those who own the system, those who are responsible for the customer market, or those who own systems that must interface with the new/changed system. Each of these categories of stakeholders will have difference areas of influence over the project and their requirements should be restricted to those areas.

Requirements solicited from those sources must also beclear, concise, and unambiguous so that they can be interpreted into specifications governing what is built. The requirements should also be verifiable – what will the product look like when the requirement has been satisfied? How will the system respond? The next step in obtaining requirements is to have the right people sign off on the requirements. Simply put, the right people are those who own, or are responsible, for the business units the stakeholders belong to. They may delegate the decision to a subordinate but should only delegate to one subordinate, not a committee. The sign off process may be complex requiring every stakeholder in the business unit to review their requirements and provide input, but only the decision maker should sign off. It is possible that stakeholders within one business unit may have conflicting, or competing, requirements and you need the business owner to be the final arbiter in any disagreement.

The final step in the capture of project requirements is the communication of the approved, signed off, requirements to the project stakeholders. The requirements will be captured in some form of Business Requirements Document, or Commercial Specification. Ensure this is in a readable form, make the stakeholders aware of its location, communicate your expectations for reading it, and make certain it is accessible to all stakeholders.

…Is Worth a Pound of Cure

So you’ve followed my advice and you are still bombarded with change requests without valid business cases. You need to act as a screener so that valuable project resources are not wasted analyzing and estimating requests which have no hope of acceptance. The reason is simple: your project only has so much time allocated for evaluating change requests and time spent evaluating one that has no hope of approval takes away from the time available for evaluating those that do. All the stakeholders may not understand this fact, but your executive sponsor will.

Your change management plan should provide an avenue for rejecting change requests un-supported by a business case before the evaluation step. The person responsible for managing project change should be the first line of defense. That person could be the project manager, or someone on the project team assigned that role. One of my best experiences in managing project change came about when I identified a team member as the Project Manager responsible for managing project change. This lady had expressed an interest in gaining experience in managing projects and had the strength of character to take on the role and not be bullied by stakeholders. She had input into defining the process and did remarkably well at limiting the number of changes that had to be evaluated (thanks Melinda!)

Don’t hesitate to reject a change that you have assessed as having no business case to support it. Be sure to expand on your reason for rejection when you communicate the rejection to the author but stand behind your decision. You may find that you have to speak to your executive sponsor the first time or two you reject a change request for this reason, but the benefit will be the support your receive. Word will spread that you can’t be bullied and that will have a dampening effect on the creation of change requests. Even if you executive sponsor does not back you up, you’ll know where you stand and can justify your request for more resources to deal with the evaluation of bogus change requests.

The one exception to the above rule is where you are dealing with a change request supported by a valid business case that isn’t stated in the request and that you failed to elicit when questioning the requestor. Be prepared to be flexible in this case, after all your purpose is not to eliminate change requests, just to eliminate those without a business case.