Managing Change on an IT Project: Part 1 – Identifying Change

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

For this article, I will cover Part 1 – 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.

Avoid the Danger of Scope Creep

Do not hesitate to raise a flag if something is being performed for the customer that may be out of scope.  If you feel it is, have a team discussion – led by the Project Manager.  If you still feel it’s out of scope, take it to the customer and let them know this possibility.  If you don’t identify the scope issues, then you’ll end up performing the work anyway and the potential price you’ll pay is a delay to the project schedule and an overrun of project hours and, therefore, budget. 

Related posts:

1. Managing Change on an IT Project: Part 3 – Implementing Change
2. Managing Change on an IT Project: Part 2 – Negotiating Change
3. Never Say No to the Customer
4. The Statement of Work
5. The Responsibility of Defining Requirements