Badly Handled Changes

No matter how well the project is planned and how well the requirements are defined, there will always be requests to change something about the project, usually the product being delivered. There are good reasons for this; business doesn’t stand still while your project is going on so we expect that ongoing business will trigger the need for changes to the system being built to support that business. These changes are mission critical to the project in many cases. If the system isn’t changed to reflect business needs as they will be when the system is implemented, your project will succeed in building a system to support business as it was done 6 months ago! These changes are why project managers need a good Change Management Plan and process.

Failing to properly plan the project’s work or sloppyrequirements gathering will certainly lead to requests for change and will probably overwhelm the project’s resources with change requests to analyze and implement, no matter how solid your Change Management Plan and process is. Failure to define a change management process that meets your project’s needs and plan process activities will lead to: the wrong changes being implemented, budget wasted on the wrong changes, failure to reserve sufficient time for analysis of change requests, refusing changes that would add value to the project, exceeding the budget, and late delivery.

Project length is another source of change requests. The longer the project goes on, the more the business changes, the more the business changes, the more the system must change to support the business. The insulation of the development cycle from the impact of change is one objective of iterative development methods. With iterations, fewer changes are likely to be requested. Software development projects with long delivery time lines can expect to experience a flood of change requests towards their end.

All changes are not created equal. Another common error in the area of changes is the tendency to treat all changes in the same way. The administrative effort required to process a request to change the color of a button on a web site screen from red to maroon should not be the same as a request to double the number of pages on the web site. Attempts to force requested changes through a laborious process designed to support major changes to project baselines will meet with resistance. There are two possible outcomes here. Either the team will prevail and will start making the minor changes behind your back or you will prevail and stifle minor changes that ought to be made because they add value to the product.

Yet another common mistake is to have the wrong people make decisions about changes. This mistake is related to the failure to provide different processes for different changes but it is possible to provide the right process for each magnitude of change and still identify the wrong people as decision makers. The decision makers for a change should be those people, or that person, who has the best grasp of the pros and cons of the change. The decision maker should also be someone who has the authority to approve any budget changes. The decision on whether to approve the change in the color of the web screen button should be made by someone who is knowledgeable enough about web design to predict its affect on users. The decision on whether to double the number of screens, and probably double the cost of the project, should be made by someone who has the authority to double the budget. This may be a customer, a sponsor, or an executive steering committee.

Project managers often make the mistake of assuming that because they have asked the project team and stakeholders to read a document (e.g. their Change Management Plan) that they will read and understand it. You should make the document available for reading by posting it to a site where everyone you expect to read it has read access, but too often project managers will stop there. The result is usually that changes are made without project approval, and/or the team attempts to follow the process but fail to follow it properly creating more work for the project manager.

Avoidance Strategies

Start your project with a good change management plan. A good change management plan should accommodate any change likely to occur on your project. The plan should support all the best practices described in the PMBOK®, but be tailored for the size, complexity, and industry of the project. You can learn more about these best practices by taking a good PMP® course, or other PMP® Exam preparation training, You should define at least 2 processes, what I’ll call "Change Management Lite” and "Change Management Full”. Change Management Full should be suitable for large scale changes, up to and including those that must be decided upon by your customer, sponsor, or executive steering committee. Change Management Lite should accommodate the smallest change. Make sure that the administrative overhead entailed in each process is proportional to the size of the change.

A good plan identifies the actions and tasks that must be performed to follow the process, assigns people to those tasks, and identifies any deadlines that must be met. Allow sufficient time in your schedule for the tasks to be performed. Since you can’t predict the number of change requests you will receive, or how complex those requests will be, over the course of the project phase you will need to set buffers. Set your buffer for each iteration, if you are using an iterative development method. One way of dealing with the uncertainty surrounding number and complexity of change requests is to raise an alert when a buffer is approaching total depletion (say 90%). You have 2 choices when you reach that point: you can shut the change process down (OK if you are almost at the end of the project), or you can request a change to provide more time to deal with change requests. This change will require either more resources (increase the budget) or reducing the scope.

Identify the proper decision makers in your plan. The customer, or client, or sponsors, or executive steering committee should be responsible for making decisions that will change the baseline. These individuals must understand what is expected of them, when they must render decisions, and how they will receive the information they need to make the decision. For changes that don’t change the schedule, budget, scope, or quality baselines, identify one of the project team as the decision maker. You should be the first in line after the executives, but you should not be required to render decisions on issues which do not require a change in the project plans. Take our web page button as an example. It will cost no more to create a maroon color button than it will to create the red version and you are not in a position to know if maroon is the right color. Delegate this decision to the web design expert. The web design expert must follow the change management process. The change will not affect your plans but will affect the design, coding, and testing of the web site. Team members responsible for those tasks must be made aware of the change and the appropriate documents updated.

Educate your project team and stakeholders on the change management processes in your plan. Education for requesting a change should include where the change request form resides, how to complete it, who to send it to, when to expect an initial response, when to expect a decision, and how that decision will be made. They should also be educated in their support responsibilities (i.e. answering any questions SMEs who analyze their requests may have). Education for the team should include their responsibilities when they receive a change request for analysis, the deadlines for those tasks, and how the analysis information is to be captured. Education should be in the form of a ½ hour – 1 hour formal training session. Do not throw a process document or presentation over the wall and expect your stakeholders and team members to absorb its contents.

The tips and tricks described in this article implement some of the best practices promoted by the PMI (Project Management Institute). These are taught in most PMP^® courses and other PMP^® exam preparation training products. If you haven't been certified as a PMP^® (Project Management Professional) by the PMI and would like to learn more about certification, visit the three O Project Solutions website at: http://threeo.ca/pmpcertifications29.php. three O Project Solutions also offers a downloadable software based training tool that has prepared project managers around the world to pass their certification exams. For more information about this product, AceIt, visit the three O website at: http://threeo.ca/aceit-features-c1288.php.