Project Smart ~ Exploring trends and developments in project management today

Calendar icon
Adobe PDF icon

Common Project Management Mistakes: Badly Handled Changes

~ By Dave Nielsen

Motorway gantry sign with a change concept

No matter how well a 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 six 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 sloppy requirements gathering will certainly lead to requests for change and will probably overwhelm the project's resources with change requests to analyse 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 colour of a button on a website screen from red to maroon should not be the same as a request to double the number of pages on the website. 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 colour 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 should define at least two 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 two 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 colour. 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 website. 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 analyse 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.


Dave Nielsen is a principal with three O Project Solutions, the vendors of AceIt. Dave was also the key architect responsible for the creation of the product. AceIt has prepared Project Managers from around the world to pass their PMP exams. You can find endorsements from some of his customers on three O's web site http://www.threeo.ca

The tips and tricks described in this article are intended to help the project manager using the best practices promoted by the PMI. Project managers who are certified have already implemented those best practices. 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.


Comments

Be the first to comment on this article.

Add a comment



(never displayed)



 
1500
What is the next number: 10, 12, 14, ..?
Notify me of new comments via email.
Remember my form inputs on this computer.

Project Risk: Is It All Bad?

Road warning sign - Risks Ahead

Risk Management is an essential part of any programme or project and can vastly contribute to successful delivery.

Managing The Project Time

Man pointing at an alarm clock

Project managers should know the iron triangle of project management, sometimes called the triple constraints of project management, because all projects are constrained by these elements.

How to Initiate a Six Sigma Project

Six Sigma diagram scheme concept

Although one cannot have a project-specific vision right from the very beginning of a Six Sigma initiative, you can develop a comprehensive viewpoint.

But What is Best for the Customer?

Four business people's hands holding puzzle pieces

Ideally our project management methodology in a box process works perfectly for everyone. But clients come in all types and sizes and one size doesn't fit all.

PROJECT SMART is the project management resource that helps managers at all levels improve their performance. We provide an important knowledge base for those involved in managing projects of all kinds. With weekly exclusive updates, we keep you in touch with the latest project management thinking.

WE ARE CONNECTED ~ Follow us on social media to get regular updates and opinion on what's happening in the world of project management.


Latest Comments

Duncan commented on…
10 Rules of Highly Successful Project Management
- Mon 26 September 7:50am

John Corbett commented on…
10 Rules of Highly Successful Project Management
- Mon 19 September 1:36pm

London Management Centre commented on…
Get Maximum Benefits of Merging Top-down and Bottom-up Project Management
- Mon 19 September 11:29am

Latest tweets

General Project Management • Best Certification For Me? https://t.co/KZdv5lIiKy #pm #projectsmart about 6 hours ago

General Project Management • Re: Course Recommendation! https://t.co/R001FDPE3A #pm #projectsmart about 16 hours ago

General Project Management • Re: Need help with technological terms https://t.co/JlHbxg6tks #pm #projectsmart about 16 hours ago