Project ManagementRisk Management

7 Causes of Project Change

Change is just another component of a project, the same way time is just another dimension coinciding with height, width, and depth. The fact that it is not as easily managed should not be cause for concern. In a post for the PM Perspectives Blog, Elizabeth Harrin pinpoints seven common reasons that projects change, so you can be proactive about it:

  1. Stakeholders changing their minds
  2. Regulatory change
  3. Poorly defined requirements
  4. Change in sponsorship
  5. Business strategy change
  6. Updated technology
  7. Not enough resources

Change Is Not a Threat

Everyone is entitled to change their mind; the difference when stakeholders do it is that project requirements change with them. Try to help stakeholders see the full picture early on so that these changes happen sooner rather than later. Similarly, a change in sponsorship brings a whole new perspective on the project. This may or may not demand project changes, but stay vigilant all the same. A regulatory or legislative change can also put a damper on affairs, but keeping all aspects of the project compliant and legal is not optional.

The biggest changes are changes in company strategy. These are the sorts of things that can outright cancel a project halfway into it. There is nothing you can do about it, so hey, why worry about it? Dealing with advancing technology warrants a similar attitude. A technology rollout could take long enough that some updates and upgrades are already available by the time it is done. If this is foreseen but the business climate does not offer leeway, you may decide to bite the bullet and do some rework to ensure everyone gets the upgrades.

Lastly, if not enough resources are available to actually achieve the intended scope of the project, then the project has to change. Two hamburgers and a clown costume is not enough to launch a fast food franchise, for instance. Harrin concludes by reminding us of one more thing that forces changes—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.

Live and let change. You can view the original post here:

Show More

Leave a Reply

Back to top button

We use cookies on our website

We use cookies to give you the best user experience. Please confirm, if you accept our tracking cookies. You can also decline the tracking, so you can continue to visit our website without any data sent to third party services.