Skip to content

6 ways a change can impact your project

July 21, 2011 - Project Management

pile of rocks“Oh, this is a small change. We’ll just add it to the requirements.”

“It’s only $20,000.”

“A two-week delay isn’t that big of a deal.”

The most common mistake when it comes to project change control isn’t that we interpret a large change as a small one.  It’s that we don’t treat small changes with respect, and end up with a mountain of change over time, completely undocumented and grandfathered in.  Then we wonder why we completed the project 50% over budget and two months late.

Step two of easy project change control is analyzing the change impact.  We’ll cover three obvious impact areas, and three that aren’t so obvious.

The Obvious Ones

The three obvious project change impact areas are the members of the good ol’ Triple Constraint:

Scope

Did any business requirements change?  Probably.  Also, be sure to check if the new requirement(s) conflict with any existing requirements.  Was there a larger change in the strategic direction of the project?  That should require higher level approvals (which we’ll cover in the next post in the series).

Budget

Is there a budget increase or decrease due to this change?  When analyzing the budget impact in more detail, which project stages will see the budget increase / decrease?

Schedule

Is the project schedule impacted due to the change?  What specific milestones will shift?  Will the go-live date need to move?  Are any Development or QA system availabilities now at risk, due to potentially clashing with another project’s development schedule?

The Not-So-Obvious Ones

solution architectureSolution Architecture

Will the scope change require a solution redesign, and does that impact the overall architecture of the business solution?  The Enterprise Architecture group may require approval before an Architecture Review Board for the design changes.

Business Case

A change in any of the three major impact areas could also impact the project’s business case.  Budget changes impact the business case in obvious ways, but a schedule change could, for example, nullify year-one business benefits, or a requirements scope change could introduce additional benefits not originally included in the business case.

Partner Contract

If leveraging third-party resources to execute any part of the project, that partner’s contract may also require a change request, if the project change impacts any of the deliverables the partner was expected to produce.

The change’s impact on the project should be documented along with the other change details in the Project Change Request.  These impacts will also drive what level of approvals are required for the change, which we’ll discuss in the next blog post of this 5-post series.

Project Change Control blog series

  1. Introduction
  2. Document the change
  3. Analyze the impact
  4. Approve the change
  5. Re-baseline the project


Spread The Love, Share Our Article

  • Delicious
  • Digg
  • Newsvine
  • RSS
  • StumbleUpon
  • Technorati
  • Twitter

Related Posts

Comments

There are no comments on this entry.

Trackbacks

There are no trackbacks on this entry.

Add a Comment

Required

Required

Optional