Change requests can significantly impact the course of your project and make staying in balance with the triple constraints (time, budget, and scope) more challenging. And if you don’t address change requests the right way, you might find your project running late and over budget. (Nobody wants that!) Handling project change properly helps you stay in control of your project.
What is a project change in the context of project management?
Project change is an intentional modification of an original project plan. This type of change affects the scope of the project, including specifications, deliverables, timeline, resources, schedule, and budget. A project change can be small with little effect on the scope. But it can also be large enough to trigger a domino effect that radically expands the project scope. The bigger the change, the more difficult it is to accommodate or foresee potential consequences.
In project management, project tolerance tells you how far you can deviate from your original schedule and budget without having to ask key stakeholders (specifically a project sponsor) for approval. There may also be tolerance levels for quality, scope, and risk. You can set tolerances for a project, stage, or work package level, too. In other words, tolerances can get very detailed.
Say you’re running a six-month project and set a tolerance of ± one month. If you forecast your project to be one week late, you’re free to handle it without escalating to your sponsor, project board, or other relevant stakeholder(s). But if that forecast predicts a delay of two months instead of one week, then you’d need to escalate the issue.
Reasons for changes in a project
Some project changes are ad-hoc and come from the stakeholders with the intention of improving the final product (or the process of implementing it). Other changes are the result of external factors you have little to no control over.
A project change can arise from a variety of sources. Depending on the source or reason, the project change may fall into one of the following categories:
- Strategic changes are the consequence of shifts taking place on the management level within the organization (e.g., new project priorities or direction).
- Reactive changes are the direct response to some specific situation that happened or is happening (e.g., technical problems).
- Proactive changes are introduced to mitigate the potential consequences of events you anticipate will happen (e.g., dependencies and risks).
- Changes due to force majeure are things no one could predict or control (e.g., weather, new legal regulations, different vendors).
5 steps to project change management
The goal of project change management is not to accept every single change request and introduce it into your project. (In fact, not every change is necessary, and you have an obligation to reject some of the requests if you think it advisable.) A solid project management process tells your team members and other stakeholders when and how they can request a change in a way that keeps your project on track.
#1. Receive the change proposal
The first step is to receive a project change request. This can come from any stakeholder, including a project team member or a customer. The change they propose should justify the need for change and explain how it would benefit the project. (Unless it’s the reactive or force majeure type of change.)
#2. Analyze the impact, risks, and value of the proposed project change
Next, you’ll need to consider the impact and value of the potential change in the broader context of the project. Think about the domino effect, because changing one moving part in a project will affect others, potentially including resource availability or capacity, budget, schedule, and deadlines, or even other initiatives if your project is part of a program or portfolio.
The bigger the change, the higher the probability of risks (but also opportunities!). For instance, a proposed change to organizational policy could actually benefit your project in the long run. Therefore, along with the impact and value analysis, a thorough risk assessment will help you see a bigger picture of the change implementation consequences.
#3. Accept or reject the project change
Based on your analysis, a Project Manager or another person with the authority decides to whether accept or reject the project change. The decision might be to reject the project change permanently, but the decision maker might opt instead to defer the change until the later phases of the project, or until the project meets certain conditions.
#4. Implement the change
If the change is accepted (or it has already happened and you have no other choice but to act on it), you’ll need to make it part of your project. This might mean lifting some of your resources, altering your schedule, creating more dependencies, or adding risks to the risk matrix.
#5. Communicate and report the progress of the project change
Once you’ve made the proposed change part of your project, you’ll want to update your project plan, budget, schedule, and any other documentation you use to track your project. Later on, you’ll be communicating project changes and after-effects to your stakeholders, so keeping documentation up-to-date is crucial. Solid project management software can help you add, monitor, and report on any changes.
Tips for managing project changes with BigPicture software
Project management software like BigPicture can help you to simulate, analyze, implement, and report all the changes effectively. Most importantly, you’ll know how a given change will affect your project and whether it will exceed your project tolerance(s). And then, you’ll be able to report the project progress to your stakeholders at any point in the project lifecycle.
Simulate and analyze an impact of a project change
One of the most important questions to answer is how a proposed change will impact your project in the long run. Questions like “Will my resources have enough capacity to carry out this task or user story?” or “How will this change affect project milestones or other tasks?” will present themselves. And you’ll want to know the answer to these questions to successfully complete step #2 on your project change journey.
Test a project change with what-if scenarios
The what-if scenarios (Scenario Mode) feature in BigPicture enables you to conduct a series of simulations based on selected conditions. For example, you can find out whether certain ad-hoc tasks will exceed a specific person’s capacity during a specific period. Or how the dependent tasks in your schedule will behave when you change the parent task’s start/end dates.
Any change you introduce to your project while in Scenario Mode is safe from altering your project permanently. (Unless you deliberately decide to merge the scenario version with your original project.) So you can try out different approaches toward implementing project change without messing up your project. And afterward, you can easily compare solutions and choose the best one. The scenario will also help you see whether a specific change will exceed your project tolerance.
Tip: BigPicture Enterprise users can see every task assignment in their resource swim lane, even if it doesn’t belong to the scope of their project. The “Show overall assignment” feature helps you avoid overallocation and find the right resource with respect to the project change.
Identify conflicts with colored task dependencies
Project changes don’t happen in isolation and usually take some toll on other tasks you already had planned. Consequently, any new task you add to your project could affect task dependencies. The job gets even more tricky if there are multiple dependencies making the consequences of a change difficult to follow.
BigPicture can visualize all the dependencies in your project. It will count every dependency link connected to your tasks, indicate out-of-view/cross-project dependencies, and inform you about the health of individual dependencies by coloring them.
Assess and visualize risks
When considering a project change, you’ll need to take into account the risks and other uncertainties that could follow. This will help you minimize their impact or even mitigate some of those risks. When you’ve identified those risks, you can assess their impact and probability, and position them on the risk matrix. Such a visualization will help you prioritize and track the risks.
In BigPicture, you can create and display risks as either regular Jira issues or risk cards. You can approach risks in two ways. If you treat individual issues as risks and display them as issues, you’ll know exactly which tasks are at risk. But you won’t know the risks associated with them.
On the other hand, if you display project risks as cards, you’ll know what the risk is about. But you won’t know which tasks they relate to.
Tip: If you choose the risks-as-issues approach, you can create soft dependency links between the risks and the associated tasks. This will enable you to see what risk is connected to which task and easily track both.
Make the change part of your project
In step #4, we talked about the project change implementation. At this point, you want to add a change fast and easily. In BigPicture, depending on the nature of the change, you can go about this in several ways.
Adding a task
If the change results in additional work, you’ll need to add it to your project. Then, depending on the management methodology, you’ll position it on your work breakdown structure (WBS) or the Agile board (or product backlog if your team will commit to this task in later iterations/Sprints).
In BigPicture, you can create and add new tasks directly on the WBS and the Board, or in the Scope module.
Assign the resource
Resource allocation can be tricky due to each person’s maximum workload, remaining capacity, and (un)availability. Furthermore, individual tasks you need to assign vary in terms of length but also skills required. But by now you’ve analyzed the impact of the project change on your resources (e.g., with the Scenario Mode). So you know to whom you can assign a task and when.
Task assignment in BigPicture is simple and you can do it several different ways. For example, during in-line editing, you can use an Assignee column on your WBS and select a person from the drop-down menu.
Likewise, you can re-assign every task on the fly whenever you need to.
Adjust project schedule
A project change will affect the project or individual tasks’ schedule. This can be due to a new task entering your project, or delays in execution caused by external factors (like a crucial skilled professional leaving a project).
New or current tasks may require different period (scheduling) rules for your parent or children tasks. So based on the analysis you conducted earlier, you’ll need to alter individual tasks’ period mode, start/end dates, and estimates — whatever it takes to fit them into your project schedule.
You can approach task scheduling with BigPicture’s Gantt chart in two ways. First, you can manually alter taskbars by moving them and stretching or shrinking their length. Likewise, you can in-line edit task details directly on your WBS to change their estimates and start/end dates.
Tip: If there are strong dependencies between the tasks you want to move, the auto-schedule feature will reschedule dependent tasks for you. This way, whenever you alter the dates of one task, dependent tasks will automatically adjust.
Communicate and report project change
The last step in handling project change is to communicate the change and continue monitoring your initiative. When you pair BigPicture with the BigTemplate app, you’ll be able to export (and import) data about your project from the following modules: Scope, Gantt, Objectives, Board, Resources, Risks, and Calendar.
The export function is the way to go whenever you want to work with the data or combine it with other pieces. It’s also great for stakeholders who don’t have access to Jira.
For those who can access Jira, you can share a direct link to the project view you’d like them to take a look at. For example, you could share a link to your Gantt chart and talk live about it so everyone stays on the same page.
The “Share view” option works in every module except Reports. This brings us to the third method for communicating your project changes and progress — the project reports. You can generate reports to gain insight into different aspects of your project. For example, the Plan Delays report will tell you which tasks are delayed (and by how many days). The Velocity report will help you understand how the recent project changes have affected your Agile team’s velocity and compare it across several iterations (or Sprints).
Discover how to tackle all kinds of project changes with the help of the BigPicture PPM solution.
Not a BigPicture user yet? Start your free 30-day trial today. Or visit our demo page to play with the app straight in your browser — no registration or installation needed.