Continuing our series on Change Management with the change management process flow.
So far, we have presented defining what a change is, establishing the cost limits, and enforcing the Change Management plan. This article will focus on an undocumented Change Management Process Flow and the process to ensure it does not happen again. We should also recognize that scope may and will indeed likely change.
Project success is intricately connected to the management of the project scope.
Table of content :
- How do we know a Change has occurred?
- Fixing the undocumented Change
How do we know a Change has occurred?
One of the priorities early in the project is to uncover the scope of the project. We want to uncover or discover, the objective of the project in sufficient detail to identify the actions and suitably plan the project. To control something, we need to know what that thing is. How do we know there is a change? Compare what is asked with that which was previously asked. Is there a difference? This formally documented scope is analogous to a road map to the desired project and business objectives. It is this discovery and documentation that will lead to the starting point of the scope, referred to as scope baseline.
Scope baseline is a fancy way of referring to the scope at any given time in the project. The initial scope baseline is the approved, signed scope at the beginning of the project. This is the anchoring point for the comparison to future inputs. The scope baseline can and often will change throughout the project based upon change requests. As we perform the work to meet the project objective, we learn, and so too does the customer. This requires us to be prepared to handle this eventuality. Each updated to the scope baseline should be approved and signed.
Another way to find that something has changed, is through Cost Variance and Schedule Variance. Each time a project manager creates a Status update, Budget and Schedule are reviewed. If cost is trending faster than planned, it could be an undocumented change has occurred and resources are being committed. It could also be our estimates were off and this warrants some exploration, but not in this article. The same is true with Schedule. If key deliverables are tracking behind schedule but hours aren’t, the team maybe working on an undocumented change. Any time the variances are trending behind or ahead the project manager should investigate.
Fixing the undocumented Change
Okay, our team, in their haste to please the customer, have taken actions to meet an undocumented change. It is not good for us to ignore this. We will need to take some time to refresh our team and the customer in our agreed upon change management process. Next, we will investigate and document the Change, from beginning to end. We will research the consequences of these changes and then communicate the findings with the project team and all stakeholders. Be prepared for questions. Some of the questions maybe about how this happened and how to keep it from happening again. This is the reason for the review our project change management processes with the team and the customer.
Be prepared with your plan to move forward, actions and associated costs and time impacts. Don’t wait too long before sharing with the stakeholders, perceived bad news travels fast. Using the term ‘bad news’ as an assumption because very few undocumented changes improve project execution. There will be pressure to resolve quickly, from experience 24 clock hours should be a good time frame to inform everyone. In-person an acceptable method and with the nature of global projects, a phone call is acceptable. Emailing and/or texting bad news should be the last option.
Make sure that the revision to the Change Management plan goes through the same approval process that the Project plan when through at the start of the project. Do not side-step the necessary signoffs are required both from the customer and likely from the management structure of the organization. This will especially be valid if there are cost and contractual implications in the change.
Depending on the Change that occurred a tough talk may be required. A PM took over a $275K buildout project and found out a $50K verbal Change had occurred. Two tough talks had to take place. First, a Vice President of the company had been walking the site with a contractor and mentioned that ‘it would be nice’ to have this done here and there. The PM had to explain that this ‘direction’ should go through the PM first. The vice president said it wasn’t not direction, he assumed the contractor would notify the PM. After some discussion, the VP and the PM came to an agreement that the project budget was the PM’s and any further ‘would be nice’ would first go to the PM for discussion.
The contractor’s position was that this is a VP giving him direction and the work had to be done. Again, after a tough talk, in the future if approached by the VP about ‘would be nice’ the contractor would notify the PM.
This $50K Change was negotiated down to paying for the materials only since the materials were already installed. The project would not pay labor or any profit or markups. The project budget was altered to include the materials and approved only after a robust Change Management plan was written.
Re-enforcing the Change Management plan
As mentioned in the last article, the Change Management plan is a living document. A robust process may not have been in the original plan and now that an undocumented change has happened, the plan needs to be revised.
If our team has already undertaken a change, we should not just allow that uncontrolled, undocumented change to continue thusly.
- Investigate the change and activity to date.
- Verify the change is not part of the scope baseline.
- Develop a plan to resolve the situation.
- If necessary, review and update the scope baseline and budget documents.
- Review the Change Management plan updates with the Sponsor and team.
It is important that our team members and customer know we have a change management process and enough of a working knowledge of that process to know where to start the change request.
The best time to control the project scope, is at the very beginning of the project. A prudent action is to create a scope baseline when we have scope agreement with the customer. This will be the point from which all other comparisons of scope happen. As change of scope proposals are made, and accepted, the baseline will be updated in a controlled way. This provides traceability of the scope over the project life.
Even in the event a change of scope has been undertaken without requisite approvals, we should catch the documentation up to the change undertaken. Specifically, update the scope baseline and review the change to articulate the cost, time and any risks that may be included in this change. No need for a mistake to continue.
According to PMI, part of the project closure activities, will include comparing our contractual obligations, particularly scope, against what has been delivered. Not having a scope baseline that reflects the agreed upon scope during the closing phase of the project, will make an accurate comparison nearly impossible.