Change management is a critical project activity and one that needs to rest firmly on the shoulders of the Project Manager. There are basically three steps to the process:

  • Identifying change
  • Documenting and negotiating change
  • Implementing change

Let's start with covering the first part – Identifying Change.

Identifying change

The Origin of Change

As we all know, the Project Manager serves as the information and communication coordinator for the entire project. Since the PM is that point person and has access to all documents, requirements, issues/risks lists, budget info, etc. then it is reasonable to think that they are the point person for identifying change on the project. Certainly, the need for change – say a change in scope due to a need to modify requirements, add a report or integration point, etc. – will probably originate from discussions the Business Analyst is having with the customer. The BA may even discuss this scope issue at a high level with their primary POC on the customer side. However, the issue should always be formally initiated by the Project Manager.

To illustrate, I’ll use examples from a recent project of mine. The customer had been extremely happy with the phase 1 portion of a large-scale, enterprise-wide implementation that was overall going to last approximately one year. The delivery team was scattered all over the country and we would meet face-to-face with the customer to kickoff each project phase.

It became apparent early on that the BA was meeting the customer’s needs very well and that his product knowledge level was helping them feel very comfortable with the implementation. Basically, anything that he said needed to happen they just went along with it. Eventually, the customer project sponsor made a formal request to have him onsite full-time throughout the remainder of the engagement. Since he was not originally forecasted to be actually full-time on the engagement, I let them know that moving him from 30 hours per week to 40 hours per week as well as additional travel and hotel stays was a scope change and would result in a change order. They understood and requested the appropriate paperwork – which I was happy to provide.

Know the Scope

This is just one example and this same customer requested two other items related to the implementation (add-on software services) that resulted in approximately $80,000 in changes over the course of the final three months of the phase 1 portion of the implementation. The key is knowing very well what is and is not within the original scope of the Statement of Work. This is critical and can very positively affect the financial bottom line on the project. The entire team needs to know this because everyone on the delivery team is a potential identifier of scope changes. They all potentially interact with the customer and they all are definitely providing work to the customer.

Negotiating Change

As discussed previously, change management is a key activity for which the Project Manager is responsible. It goes hand-in-hand with Scope Management. Whenever issues arise that appear to be out of scope, they must immediately become part of the change management process on a project.

Above we discussed the concept of Identifying Change on a project. Now, I will discuss the next step the Project Manager must take – Negotiating Change.

"It’s Out of Scope"

You’re the Project Manager and you’ve reached the point where you, or someone on your team, have identified a potential out of scope issue. Customers cringe when they hear the words “It’s out of scope” uttered by a Project Manager. Or possibly even your customer has brought an out of scope issue to you and identified it as out of scope verbally. That would be the easy route. That’s how it was for me on one project I mentioned in another article when the customer requested the Business Analyst to be full-time on the project – and onsite – for the rest of the engagement. They knew that was out of scope and knew they would pay for it. It doesn’t always go like that. In fact it rarely does.

When an obvious out of scope issue arises, the best course of action – after you’ve discussed it with the delivery team members – is to take it to the customer. The earlier in the process they know about it the better. Give them as much information as possible and explain what likely effects it will have on cost/budget and schedule. This is when you put your PM negotiating cap on.

As the customer, they are worried about both cost and timeframe. One may be more important than the other on any given engagement, but the customer is definitely watching both closely. As quickly as possible, put together a proposal for the out of scope (OOS) issue detailing the cost estimate and timeframe changes (either or both depending on what affect the OOS issue has on the project). Deliver it to the customer and set up a meeting to go over it either in person or over the phone depending on logistics. Be careful to include all details on the benefits to the customer of the change and the work to be performed and any assumptions you have made to achieve the cost and timeframe estimates. The customer will appreciate the documentation and the justification and this will likely make the acceptance and signoff process – and thus the negotiation process – much smoother.

Dollars and Sense

As the PM and the keeper of schedule and budget and the leader of the delivery team, you are in a unique position to negotiate with the customer on this change order. It may be possible to provide the customer with a reduced hourly rate for the labor involved in the change. This is an especially good tactic to take if there was any grey-area surrounding the need for the change or the potential that there was some early-on failure on the part of Sales to properly educate the customer thus leading to this needed change order.

Another possible negotiating point may be in schedule. If the change will affect the timeliness of rolling out some critical functionality, then it may be possible – and necessary – to negotiate with the customer a possible phased approach to implementing the changes needed in the change order. Proceeding down the current may satisfy the customer and allow for the revised work covered in the change order to be performed in a later phase. If that is the case, then this later phase work can be estimated at either the regular hourly rate or at a revised, negotiated rate depending who or what actually caused the need for the change order.

Implementing Change

Change on a project is nearly inevitable. Sales closes a deal with expectations set at ‘x’. The delivery team goes onsite and starts to work through requirements and into design with a customer and there becomes a realization on either or both sides that there is a gap to some degree between expectations and reality.

So far we’ve discussed the process of Identifying Change and Negotiating Change. Now we’ll cover the process of Implementing Change.

It Really Was Out of Scope

As the Project Manager, to get to this point you or someone on either side of the fence has identified a potential scope issue and brought it to the attention of everyone involved. A draft change order identifying the scope change, budget impact, and schedule impact has been created, delivered to the customer, reviewed, discussed, and approved. Now, the delivery team must implement the change.

Really, the work to be performed happens as all other work on the project. The difference really is in the fact that the budget needs to be amended and tracked and the schedule likely needs to be amended and tracked. This new budget and schedule is what you’ll work from at this point and going forward. I will highlight the fact one more time that before any work on the change starts, be absolutely certain that the customer has formally approved the change order and given approval for the work to begin. Otherwise, it can be very costly for the project, the delivery organization, and damaging to the relationship with the customer. Nothing should proceed without the proper approval.

Document Updates

Requirements approval has already basically happened with signoff on the change order. However, the Business Requirements Document (BRD) should be updated (if applicable), the Functional Design Document (FDD) should be updated (if applicable), and the Technical Design Document (TDD) should also be updated, if applicable. Because the BRD and FDD are usually formal deliverables to the customer, the customer sponsor should review the changes and signoff on these documents again.

Testing/UAT

If the solution is already in production, then the remaining process is not much different from the regular tasks that go into any IT implementation. Following the revision of the BRD and FDD, development work can begin. Once that is completed, the developer and relevant individuals on the delivery team will perform a system test to ensure that everything is working properly and according to the revised FDD. Once the system test has been successfully completed, the customer should be engaged to perform User Acceptance Testing (UAT) on the modifications and a quick UAT on the system as a whole. It is very important that when pricing the change order, the Project Manager includes time and effort for these critical activities.

However, if the system is still in the Design, Development, or Testing phases when the change is identified, then the only thing that needs to be modified for UAT would be test scripts and test cases to ensure that the change is properly tested by the customer.