How to Manage Project Changes and Stay Ahead of the Curve

Change is a good thing, right? Well, sometimes, but not always. If you're in a rut, yes. If you're managing a project that is cruising along smoothly at 100mph with the windows rolled down, then no. Definitely not. And managing that project change – no matter where you are in the project, no matter how competent or how experienced or how certified you are as a project manager, and no matter how good your organization’s change process is, can be a challenge. 

Project changes are really about changing what you're creating with the project – from implementing a new hiring process to developing and implementing a new high tech accounting solution. Both start with requirements and the need to guard those requirements. I don't think I've managed a project to date that hasn't experienced some change in requirements, and therefore some work that needed to go through a formal change control process. Given that, let's discuss what managing and adapting to project changes are all about and the essential elements of that effort.

This is the fifth article in our six-part How to be a Successful Project Manager series. Want more? Download the full ebook below.

Lay out the project change control process at kickoff

The best project change processes start with a common understanding at project kickoff time. Explain to the project client how project change control will happen. Usually following some format of these basic steps:

1. A new request or requirement comes about
2. The project manager and team estimate the effort
3. The project change request is formally documented in the form of a change order with resources, effort, and dollars noted along with any assumptions, changes to the project schedule, etc.
4. The project schedule is modified to include the change order work and becomes part of the change order
5. The change order is presented to the customer for approval/sign off
6. The change order is ready to begin immediately or when documented on the change order

Beyond this – on the delivery team side – the project manager must revise the financial forecast and analysis tool that is being used and any separate resource planning document that may be affected.

Understand client business processes and the real project need 

Jumping into the process of capturing detailed project requirements is a reasonable aspiration, but do you really know the client's business processes yet? Do you know the “as is” and the “to be” environments in detail? And in enough detail to bridge that gap with documented, detailed requirements? And do you really know the project need – the real project? 

Often what the customer thinks is the real project may only be a symptom of the actual need. The project may be much smaller or much larger than the perceived need. Document the real need and that customer will be your friend for life as long as you don't scare them too much with a new project budget that might be twice what they were initially planning.

Capture detailed requirements

Next, go through the planning process of capturing detailed requirements. This usually cannot be done in just a couple of hours. It may take many sessions, followed by documenting and reviewing with the client to ensure formal understanding and agreement. Official sign off is also critical as this becomes the scope of all the project work to come as well as the benchmark that user acceptance testing (UAT) will use to thoroughly test the solution and sign off on the final full project as a deliverable. 

Excellent, detailed, complex, thorough, complete requirements are indeed the lifeblood of the successful project and must be managed as such. Any potential changes to those requirements can affect the project and the final solution profoundly. Therefore, those proposed project changes must be tracked and must be documented. Every change order means the requirements have changed. Make sure the differences are duly noted.

Frequent team contact to avoid gold plating

Gold plating on the project is basically the team going a bit overboard – often without realizing it or its effect on the project – to fulfill a requirement on the project. They may be working with the project customer's team closely on developing a report and suddenly the “nice to haves” become “must haves” without any project requirements changing and without any project change order being initiated. This instance of gold plating might add 15 hours of effort to the project, and suddenly the project is $50,000 over budget, and the project manager can't figure out why.

To avoid this happening, maintain close contact with the team and discuss current tasks during internal team meetings. It's ok to take on these additional client “needs,” but they need to be performed as part of a formal change order, so the project doesn't become a runaway financial disaster.

Don't be afraid to initiate a change request

Project managers often hate to initiate project change requests because they're afraid of how the project customer will react. Of course, that's not the case if the appeal is obvious. But many times it isn't apparent. It's a new need, an updated requirement, and tweak of a deliverable date that affects the resources available to the project. This results in higher costs or more hours, and often the customer doesn't realize that even a few of those needs or requests can affect the project budget and timeline profoundly. A change in requirements needs to be followed by an approved change order.

Summary

Scope management isn't easy or fun. But it must happen, and the project manager is usually the overseer of that process. It may make you the bad guy, but it must be handled.

Readers – how do you feel about change management? What steps would you change or add to what I've documented here? And what stories can you share about your own project change management efforts?

Want to improve your project management skills? Learn how to execute effective team meetings and more with the Project Management for Business Professionals course.