Managing Project Change Requests

Datamation content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

In a 2006 study the Standish Group found that only 35% of IT projects could be deemed successful. Of the balance, 19% failed outright and 46% were considered “challenged” due to missed dates, blown budgets, etc. While this is an improvement over the original 1994 study, there is still dramatic room for improvement. In a sense, this means that 65% of projects will fail to meet management’s expectations.

One of the challenges with projects is that even if requirements are carefully defined, the needs of the business may change. In other cases, the requirements are not adequately defined. A common theme is that many project teams allow changes to stream in and try to accommodate the changes in an ad hoc manner without properly scrutinizing them. This is akin to trying to change the tires on a moving car. The resulting work all too frequently causes projects to go awry and fail to meet management’s expectations.

One of the more infamous comments a project manager often hears is, “Oh, it’s just a small change”. The problem is that the small changes add up and are akin to death by a thousand paper cuts. Each small change not only carries its own resource requirements and costs but it may combine with other changes and cause modifications to other requirements or come at their expense. The net effect of any given change on an existing project may be greater than the work estimated due to dependencies and the costs associated with switching from task to task.

Regardless of the vector and reason, change requests need to be managed in order to create a reasonable assurance that projects will be completed on time, within budget and with the expected feature set. Moreover, in today’s world with concerns over security and regulatory compliance, project changes need to be managed now more than ever. With these thoughts in mind, the question then becomes how to manage project change requests?

Managing Change

First, there must be a process definition that elaborates on how projects are to be managed at the organization. This includes policies, procedures, templates, roles, responsibilities, etc. Project management must be formalized because project teams need to follow the same set of policies and procedures to manage risks as well as to reduce variation and improve quality. The more consistently projects are managed; the more opportunities will exist for process improvement, cross training, automation, effective generation of management information, etc.

Second, all change requests must be formally submitted. Organizations should invest in software to support the project management process and change management is crucial. For smaller organizations or situations where the budget does not exist, at least move to an electronic template in Word, Excel, or something similar, wherein a requestor can identify what is needed, by when, and expected benefits. The important thing is to move away from the ad-hoc, verbal agreements to proper decision making and tracking.

Third, the process needs to identify how changes will be reviewed. There may be several workflow models that define for a given set of criteria how the change request is to be scrutinized. For example, there should be one workflow model for low-risk low-impact changes that the project manager can decide on and then one or more models for more significant changes that require additional scrutiny.

The models should be designed to accommodate the need for change while also safeguarding projects from failing to deliver as expected. The objective isn’t to stop changes but rather to appropriately manage risks and thus better ensure that projects deliver on time, within budget and with the expected features that have evolved over time.

During the review, the impact of changes needs to be assessed and I’ve provide the following sample questions for consideration:

What is the business value of the change?

What is the expected cost of the change itself?

Who needs to review this request to properly assess the potential impacts and benefits?

What existing requirements will be impacted by the change?

Are there other dependencies that must be addressed?

What risks are associated with the change?

How does this change affect the risk profile of the project?

What is the total impact to costs, schedule, feature set, security and regulatory compliance?

Fourth, the status about changes should be reported. The requestor and project stakeholders need to understand what changes have been received, which are being reviewed, approved and rejected. For rejected changes, a rationale should be given so the requestor understands why a particular decision was made. In addition, management needs to understand what is being requested and decisions that are made.

In summary, changes can disrupt projects to the point that schedules, budgets, and features are compromised. In some cases, unplanned and unmanaged changes can lead to outright project failure. To guard against the risk of failure, organizations need to define a project change management process that enables proper decision making.

Like most things in life, it is a balancing act. On one hand, changes are needed to meet the needs of the business. On the other, risks to the project and the organization as a whole must be properly controlled.

George Spafford is a principal consultant with Pepperweed Consulting and a long-time IT professional. George’s professional focus is on compliance, security, management and overall process improvement.