Managing Change on an IT Project: Part 3 – 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.

Implementation

No matter when the changes are made (either pre-deployment or post-deployment), following a successful UAT, the changes can be moved to production.  The change has been formally documented in the change order and signed off by the customer.  The change has been tested as part of the overall UAT or a separate UAT depending on when the change was identified.  As previously mentioned, always ensure that the customer signs off on a successful UAT and system go-live so that the line has been drawn in the sand for any future scope issues and change order work.

Related posts:

1. Managing Change on an IT Project: Part 2 – Negotiating Change
2. Managing Change on an IT Project: Part 1 – Identifying Change
3. The Art of Negotiation – Part 1
4. The Responsibility of Defining Requirements
5. When the Client Just Can’t Do UAT