Changes are an important part of any project. There are two factors at work that guarantee the generation of change requests: 1) changes that happen to the marketplace the project is aimed at, and 2) 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 project's product or service 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 project 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 Project 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 (SME) 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 project 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. In that case, there is no benefit.
