6 ways a change can impact your project
“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:
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).
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?
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
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.
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.
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
There are no comments on this entry.
There are no trackbacks on this entry.