What is change?
Change in a project is the transition from one requirement to a different, superseding requirement, the addition of a new requirement, or removal of a requirement that is no longer relevant. There are changes driven by deliberate choices, by new information, and from challenged assumptions. There are changes from the tweaks to insignificant project minutiae to wholesale rewriting of an entire project specification. Motivations for change can be a desire for improvement, a realisation that things are going awry, or an ego-driven “project stamp”. The truth behind any change to a project is that, if the change is managed properly, it doesn’t have to result in challenge. Change can be a good thing.
Managing your changes
It’s important in any project that, when changes arise, they’re managed and communicated properly so that everyone involved is aware of the new project parameters. In particular there are seven key factors in change management;
The project manager should be aware of how much a change affects their project.
How a change affects a project obviously depends on what the change is. A large scale change has a much greater impact on a project than a small change. That isn’t the whole story though. A small change can have an significant impact on the project’s effectiveness if it comes at a time when there’s already a large amount of change in the project; “The straw that broke the camel’s back” is a fitting cliche to describe something small that might have a catastrophic effect. It’s fitting here. A project change that tips the balance by demotivating the team as their workload increases beyond capacity, or adds too much to one team member that they can’t cope, can cause a project to fail. Awareness of the total scale of change in a project is critical.
People are affected by a project change.
A change in a project doesn’t only affect the outcomes of the project – it affects the team implementing the project, the project sponsors, and the end user of the project’s goal if there is one. When a project changes it’s important that everyone affected by the change is aware that it has happened and that they’re onboard with the change. If there are people who haven’t negotiated their position on the change then they will be resistant to it. Such resistance can be a reason behind project lateness.
Some teams are better at change than others.
If the team has worked on projects together before you’ll have a good idea of how well, or otherwise, they work together to manage changes in a project. Most importantly, how long have changes in previous projects have taken to be accepted. If a team is very slow to react to changes then that factor should be considered in estimating how much addition time a change will add to the project estimate. Teams that are comfortable with change are more likely to be successful in implementing a project that’s very dynamic and unknown at the beginning.
Project sponsors need to be onboard with changes.
Another factor that can slow a project considerably is having a project sponsor (client, lead, project manager, etc) that resists change. When each of the stakeholders needs to sign off on a change to the requirements a project can slip when one delays the sign off process for any reason. Developing a strategy that mitigates resistance from known awkward parties is a valuable asset if an unexpected change occurs.
Every change carries a risk to the project.
Identifying the specific risks that a change adds to a project is a key strategy for deciding whether or not a change is important enough to include in the requirements. Moreover, understanding how the change affects the overall risk facing the project is important too. Changes rarely happen in isolation – a change to a requirement affects the requirements that it depends on, and the requirements that depend on it. It’s critical that the project manager understands how the requirement “network” changes with updates.
Different changes require different approaches.
Perhaps most important of all, a key factor in project success is dealing with each change in an appropriate way. There isn’t a “magic bullet” that will work for everything. Some changes will require a great deal of management, some will slot in to the updated project requirements very easily. The specific tactics that are used to manage changes in the project need close monitoring and constant evaluation; tactics change with the territory. As more information is made available the tactics we use to implement project requirements will also change.
Usable Requirements is a project tool that gives project managers a set of features that can help with changes to project requirements. Project Snapshots freeze the requirements to be viewed again later, and snapshots can be compared against both one another and the current project requirements to analyse what has changed in the project since a given date. Requirements also features powerful reporting, cost change analysis, and a project dashboard that gives the project manager an easy overview of the state of the project.