Home / Project Management / 7 Causes of Project Change

7 Causes of Project Change

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.

Change Management3. Poorly Defined Requirements

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.

If you enjoyed this post, make sure you subscribe to our RSS feed!

About Elizabeth Harrin

Elizabeth Harrin
Elizabeth Harrin is a career project and programme manager with over a decade of experience in healthcare and financial services. She's also a content strategist, award-winning blogger and author of several books about project management. Find her online at A Girl's Guide to Project Management

2 comments

  1. Avatar

    As a business analyst, point 3. Poorly Defined Requirements, is the one that I’m most concerned about and it happens often.

    In defense of my trade, it’s not always due to poor BAs :-) It can be a symptom of a more fundamental problem – early on in a project, when discussing high level requirements, it can be difficult to get quality involvement of important stakeholders and subject matter experts. It’s only when ‘the rubber hits the road’ and the project feels real that people then suddenly find themselves engaged and thinking up things that didn’t come to mind earlier in the project.

    Solution? I guess drive for better engagement earlier in the project.

    • Avatar

      Tom, in my experience projects with BAs tend to have the best requirements! Regardless of who is doing the elicitation, it’s exactly as you say: without the right people involved, giving it enough of their focus then you don’t get the clarity upfront. Driving for better engagement and trying to set the scene that if people really want whatever the benefits are of this project then they have to do their bit and get involved to the best of their ability is a great way to offset some of the challenge of changes later.

      Thanks for taking the time to comment.

Leave a Reply

Your email address will not be published. Required fields are marked *

*

Discover the new Adaptive Strategic Execution Programme

Get notified of new blog posts weekly. Guaranteed spam and advert free.

We publish two new articles by leading thought leaders every week. Subscribe to our weekly digest email and never miss another blog post.

%d bloggers like this: