When working on any project, expect change. While change can have a significant impact on a project, it’s change requests that aren’t appropriately approved, incorporated, and communicated that cause significant issues and have negative impacts that often spiral out across the organization. In this article, we look at how to manage change requests so that an informed decision can be made about whether or not to approve them, and how change can be incorporated into a project with as little disruption as possible.
Step 1 – Determine the Scope of the Change
The first question to consider is what exactly the scope of the change request is. A change request could be related to the business, stakeholder, or functional requirements. This step looks a lot like discovering new requirements for the project in the first place. You’ll want to involve all impacted stakeholders in eliciting the requirements of the change, analyze those requirements, and then validate them.
Along with identifying what the change is, you’ll want to identify the benefit of making change or the business need driving the change as well. This will help your change approval team determine whether or not the proposed change is worth the effort. But we’re getting a step or two ahead of ourselves. Before the change request form can be submitted for approval, you’ll need to understand what it will take to implement the change. That’s covered in Step 2.
Step 2 – Determine the Scope of Incorporating the Change
Once you understand what the proposed change is and why it’s important, your project team will need to formulate a response to the proposed change. This typically means identifying the impact of the change on the technical design and project schedule, putting together a high-level implementation plan, and determining the level of effort to make the change. With this information in hand, often documented in a Change Request Form, you’ll be able to articulate whether the change impacts the project budget, schedule, or scope.
(By the way, my go-to Change Request Form is included in the Business Analyst Template Toolkit.)
Sometimes there are multiple options for incorporating the change. For example, one approach could be to trade-off the change for a lower-priority requirement and not impact the schedule or scope. Another approach could involve delays to the the schedule and an increased budget, but keep the original scope intact. Often during this step, one or more business stakeholders are involved to evaluate trade-offs and solution approaches. The goal in this step is to present the information your change approval team needs to make an informed decision about whether or not to approve the change. Let’s look at that step next.
Step 3 – Gain Approval or Rejection of the Change
With the scope of the change, benefits of the change, and information about what it will take to implement the change in hand, the change request form is ready to be presented to the change approval team. One thing to keep in mind is that most organizations have various levels of approvals.
- A change requiring an hour of work might be approved within the project team by the primary business sponsor.
- A change requiring a week of work might be approved by a mid-level management team who can authorize changes that have minor impacts to other projects on the roadmap.
- A change to a primary business requirement requiring a month or more of work might be approved at the executive level because it impacts high-level organizational initiatives.
While realistic, these are hypothetical examples. More mature organizations will have specific criteria in place outlining what stakeholder group can approve what kinds of changes. More informal organizations will figure this out as they go along. Provided the change is approved, it’s time to act on the implementation plan and communicate the change throughout the project team.
Step 4 – Communicate and Implement an Approved Change Request
Once a change request is approved, the project team needs to be notified and project deliverables need to be updated. Consider the following potential updates, depending on the degree of the impact and the state of your project:
- Requirements Documentation
- Technical Design Documentation
- Software or Programming Code
- Project Plans and Schedules
- Test Plans or Test Cases
- Training Documentation
- Business Process Documentation
Often these updates are facilitated by a formal change notification process, where the project manager or business analyst notifies the project team of the change and each document owner incorporates the appropriate adjustments into their deliverables.
Manage Change or It Will Manage You!
While “change” is often thought of as a dirty word, the reality is that change happens for legitimate business reasons. In today’s fast-moving and competitive marketplace, it’s unrealistic to expect stakeholders to have perfect knowledge of what they want or need to achieve business objectives. Yes, we want to avoid drastic changes not tied to business objectives, but we don’t want to do so at the expense of ignoring real opportunities to deliver more value to the organization.
The most important thing is that an informed decision is made about if and how to incorporate the change. Steps 1 and 2 support the discovery of information for an informed decision to be made by the appropriate people in your organization. The second, and nearly equally important thing is that change is managed in such a way that everyone involved understands what the change is, why it’s important, and what impact it has. That’s covered in step 4.
>>Save Time Creating Your Change Management Form<<
For a starting point for approaching common business analyst work scenarios, such as managing change requests, check out the Business Analyst Template Toolkit. All of the requirements templates in the toolkit are fully annotated and editable by you, giving you a great starting point for starting your next business analyst project or formalizing your work samples.