You know that nice neat project schedule you created? The one that you’ve saved in a fancy graphical format and turned into a PDF for your stakeholders? I’ve got news for you: tomorrow it will be in the recycling bin because it will be out of date.
Project plans change daily as work gets done and you adjust what’s happening to meet the challenges of the tasks but sometimes we’re also hit with bigger changes.
Here are 7 causes of change on projects – things that will make you review that schedule again (and again).
1. Stakeholder Changes Their Mind
A stakeholder could change their mind at any point in the project. And they frequently do! If their new opinion relates to the format or quality of the output of the project then you’ll be making a change to incorporate their new ideas. Essentially, this is a change to requirements.
The earlier you can get these out of your stakeholders the less impact they will have on the project overall. While you are still at the requirements elicitation phase they can pretty much change their minds as often as they like. When you are into build, that’s when it is going to incur rework and an associated increase in cost and time to make any changes.
2. Regulatory Change
When new regulations or legislation is introduced this can result in a change to project scope or requirements. You need to make sure that your business remains compliant and legally allowed to trade. This could happen at any point in the project life cycle so the earlier you can be aware of upcoming changes the better, as generally you will get some notice before new rules come into effect.
A legislative or regulatory change might even make your project redundant so you could be faced with closing it down.
I’m sure your projects never have poorly defined requirements, do they? Well, over here in the real world we face that challenge all the time.
If your requirements are poorly set out during the definition phase of your project then it’s going to impact you later when you move into the development and build stages.
As the uncertainty around requirements is probed by the team doing the work, assumptions will be challenges and this is likely to result in a change to scope as you define what your key users actually want.
4. Change in Sponsorship
A new sponsor brings new ideas. Whether your project is changed voluntarily because it’s of benefit to the project or replaced through resignation or redundancy, whoever is now in charge will have their own approaches for doing things.
A different leader isn’t always going to mean project changes, but it is something you should watch out for. And you’ll have to put your managing up skills to the test as you bring them up to speed with what’s happening on the project.
5. Business Strategy Change
A change in direction could result in changes to the scope or requirements on your project. this could happen at any point in the project: business strategies are often under constant review for competitive threats, even if in principle the organisation has published a three- or five-year strategic plan.
Ultimately, a change to the strategy could result in a major change: your project being closed down prematurely. This could happen if the project no longer supports the strategic direction and objectives of the company but more often you’ll be expected to pivot the work to align with a change in direction.
6. Updated Technology
We all know that technology moves on. During a long project, or a programme of work, you may find that the tech solutions you put in place at the beginning are out of date by the planned end. I’ve worked on a project like this: cutting edge tech was welcomed by the teams who got it at the beginning of the roll out but 18 months later when we were still installing it in other places those first teams were clambering for the upgrades and new features.
Technical updates can introduce changes to your project. in the case of my project, we shifted our approach to deploy the latest version of the software for the teams who came later in the deployment schedule and then went back and upgraded the ones who had it first. This resulted in a change to scope and it made the overall project longer as there was effectively rework to do. But we all agreed it was a sensible approach and one that we had seen coming.
7. Not Enough Resources
If you don’t have enough people (or money, or equipment) to do everything you want to then you might be forced to change the project to get by. For example, if you’re building an estate of new houses and you run out of time or money towards the end, you might finish off the last few to a lower spec than the first ones. Top of the range taps? No thanks, just the basic ones will do fine.
Of course, if you end up compromising on quality then you’ll have to adjust the end price accordingly. In this example, you couldn’t sell the last house for the same price as the first one as the finish would be different. This is where a change can have potentially far-reaching effects: you should be looking forward and factoring in all of the impacts so that you can make the right decision about whether to go ahead with the change.
Bonus: Bugs and Defects
A defect is where a particular deliverable has failed to meet the specification set out. In software projects they are often called bugs; in building this could be your snagging list. If you’ve delivered something, or are on your way to delivering something that won’t meet your quality targets, you might have to change something somewhere along the line so that the next deliverables you do are of the right quality.
These causes of change may well cause you to go back to that schedule and wish you hadn’t spent so much time making a beautiful summary in a graphics package, because now you are going to have to do it again…
Watch out for them, anticipate where you can and work through a change management process so that you can control and monitor changes to the project as you move through the life cycle.