Defining the Need for Revision

The English writer Arnold Bennett said, “Any change, even a change for the better, is always accompanied by drawbacks and discomforts.” How true that is!

In the world of IT project management, change is not, and generally should not be, an easy process to incorporate. Every project, as you know, needs a scope statement. The scope statement defines what will and will not be delivered as part of the project. The scope is a point of reference for all future project decisions. Recall that the project scope is all of the required work—and only the required work—to complete the project. Once the scope has been created and agreed upon by the stakeholders, it must be protected from superfluous changes.

IT projects, however, are particularly subject to change due to the nature of the industry. Patches, service packs, new releases of software, bugs, threats, security issues, and new wishes from stakeholders can all task an IT project on a daily basis. Each change request must be documented, and be evaluated for cost, time, risk, and repercussions. In addition, each change request must be documented, tracked, and implemented in the plan or denied.

But what happens in many projects? Change is forced into the project scope, even if it’s a complete redesign on the deliverables, and then a project manager tries to shoehorn the project plan into the new and improved requirements. This rarely works. Instead what happens is that team morale declines, frustration ensures the deliverables aren’t met, and the project manager loses control. To prevent this, you must have a process to control change and implement change when it is needed