When Project Management Requires Change Management – Part II

Marianne Hang, Senior Project Manager

December 5, 2018

In Part I of this article When Project Management Requires Change Management – Part I , I introduced the fact that projects are increasingly being viewed as OCM focused. This means that the need for organizational change management skills on the part of the Project Manager, as well as their trusted IT Architect and Business Manager, have become more relevant in today’s project management space. While recognition of the importance of OCM to project success has been long awaited, it is still rare that a project will have a dedicated OCM Lead on the project team. It therefore frequently falls to the Project Manager, with the assistance and support of their IT Architect and Business Manager, to fulfill OCM project requirements. Since both the Project Manager and OCM Lead roles are full time, the Project Manager must be selective in determining what OCM artifacts and deliverables are reasonable to add to their already full to-do list. As well, it is important to understand that while the skill sets of the Project Manager and OCM Lead have similarities, they are not identical. With this in mind, the PM must focus on OCM artifacts and deliverables that draw upon their existing skill set – yet also choose the ones that will provide the most value to the project. The objective is to customize the OCM artifacts and deliverables for the client throughout the project lifecycle in order to ensure surprises are limited and effectively managed.  Furthermore, potential challenges are put forward in the initial stages of the project for early awareness and with a recommended plan of action in the event of occurrence.

The Communication and Change Management Plan – A Key Deliverable for Managing OCM

There are a variety of OCM artifacts and deliverables that a PM can provide, in collaboration with their IT Architect and Business Lead of course, which build upon the project management skill set and do not require specialized OCM skills. However, the one artifact that addresses the need to limit and manage surprises, in addition to providing a recommended plan to manage challenges, is the Communication and Change Management Plan. This Plan should be developed and presented in the first stage of a project, and as such, provides the project’s OCM framework. It is upon this framework that all subsequent OCM deliverables will be built. As a PM, work closely with your governance, sponsor, and SMEs to collect the information needed to complete the Plan, remembering that it is a living document and you will fine tune it over time as you get to know more about the project. The goal is to get an initial and high level OCM framework in place – not to provide a level of detail that is impossible to achieve in the early stages of the project. Depending on the level of complexity of the project, there are two versions of the Communication and Change Management Plan: one less detailed and one more detailed. We start by describing the less detailed of the two versions:

  • Communication and Change Management Plan – Lite: build this high level Plan using the information you have in the early stages of the project. By starting with the “Lite” version, you avoid being overwhelmed at a time in the project where not much information may be available. You can evolve this document as you gather more information, using the more detailed version noted later in this article. Information to be captured in this document includes the following:
    • Project Identification Details:
      • Project Name
      • Project Number
    • Project Key Resources: include resource departments where possible.
      • Project Manager
      • IT Architect
      • Business Lead
      • Project Sponsor
      • Technical Lead
      • PMO Lead
      • Etc.
    • Current Stage of the Project: use the relevant terminology from the client’s PMO methodology and update the document for each stage.
      • Planning
      • Design
      • Execution
      • Go Live
      • Close
    • Project Business Drivers: identify the business case behind the project; use the approved Business Case if there is one. Note that project deliverables are not business drivers. Business drivers define why there is need for change, while project deliverables facilitate that change. In some cases, project deliverables are not clarified early on, and choosing a solution may be part of project scope. With this in mind, it is vital to understand and document the rationale for the project’s existence by clearly stating the business drivers.
    • Project Change Impact: identify what will change for the business as a result of project deliverables. Maintain focus on a description of the change impact to the business, rather than a description of what the project is to deliver. For example, if the project will implement new software, the change impact is the impact of that new software on the business. Think about the impact to business resources and their day to day roles, as well as to business processes. Engage the Business Lead because the PM should not determine change impact to the business – the business must determine that impact. The IT Architect will also help because they understand how new technology impacts the business in terms of the end-to-end solution build, business data inputs and outputs, and business processes that support the new technology, as well as business processes that will change or be eliminated due to the new technology.
    • Project Communication Process: this process doesn’t need to be fancy or complicated. Start by identifying the four key groups that are in place for most projects and align project communication objectives for them:
      • Steering Committee / Governance: objectives = decision making and support.
      • Stakeholders: objectives = requirements, inclusion, transparency, and support.
      • Project Team: objectives = resourcing, deliverables, and issue resolution.
      • Vendors: objectives = resourcing, alignment to the project, SOWs, issue resolution, and technical support.

Then determine how each key group will be engaged in the project, i.e. what are the appropriate vehicles of communication. Examples include meetings (identify the meeting cadence for each group), status reports (identify the status reporting cadence for each group), change requests, decision records, SOWs, reporting, etc.

Next, identify the communication mediums for each vehicle of communication. For example, verbal communication, presentations, hard copies, emails, meetings, etc. This section of the document will likely be similar for each key group.

Finally, identify resource leads who are accountable for the communication process for each key group. For example, the lead resource accountable for communication to the Steering Committee is typically the Program Manager, not the Project Manager. However, the lead resource accountable for communication to the Project Team is typically the Project Manager, not the Program Manager.  

  • Project Organization Chart: develop a simple and high level organization chart that includes each resource noted in the Project Key Resources section referenced above, within the reporting structure that the project will follow.
  • Project Change Management Process: most projects must follow the established Change Management process of the client they are delivering to. Note that this is not the technical MOC (Management of Change) process, rather what most PMOs term the Change Request (CR) process. The CR process is typically implemented for any change to project scope, schedule, or budget that will have an overall material impact of plus or minus 10%. There is also usually a CR template to be completed.

In addition, most projects must follow an established Decision Record (DR) process for any significant decisions that impact project scope, schedule, or budget at a milestone level. Reference both the existing CR and DR processes at a high level, and state that the project will follow these established processes.

If there is a technical Management of Change (MOC) process in place that the project must abide by, reference this process as well and state that the project will adhere to it.

    • Document Approvals: end the Communication and Change Management Plan Lite with a section to capture sign off by project governance such as the IT Architect, Business Lead, Project Sponsor, and PMO Lead. You may also wish to add a version control section following the approvals section in order to manage updates to the Plan as you fine tune it.
    • Communication and Change Management Plan: if the project is complex, it may warrant adding more sections, in which case simply drop the word “Lite” from the title and consider any or all of the following components, in addition to those components noted above for the Lite Plan:
    • Areas / Resources Impacted by the Change: specific resources, business departments, locations, etc.
    • Areas / Resources Involved in Delivering the Change: specific resources, business departments, locations, etc. These areas and resources are often referred to as Change Agents or Change Champions in OCM, and their role is to support the project’s OCM on a wider basis.
    • Change Prerequisites: conditions that must be in place in order for the change to be realized. For example, successful testing and end user training.
    • Business Benefits of the Change: obtain this information from the approved Business Case. Note that new technology is not a valid business benefit on its own so refer to how the new technology will support / improve the business, its resources, its processes, and its outputs.
    • Change Schedule: identify when change will occur and what groups will be impacted. For example, if the project implements a Pilot, Pilot users will be impacted by the change before the end users, who will not see the change until production.
    • Voluntary or Mandatory Change: understanding whether the business asked for the change vs. was told that the change is coming is vital to determining effective OCM, and will help identify challenges to expect and plan accordingly for.
    • Change Levers Required to Enable the Change: change levers help support change to move forward effectively, for example, a Project Sponsor who understands and supports the need for OCM in the project, or a Steering Committee that assigns an OCM Lead to the project.
    • Change Success Measurement: identify how the project and its stakeholders will define change success and what tools will be used to measure this success, for example, end user surveys.
    • Key Stakeholders Impacted by the Change: primary stakeholders who are on the front lines of the change impact.
    • Change Management WBS (Work Breakdown Structure): includes change tasks / activities, due dates, accountable resources, and status.
    • Change Sustainment Plan: identify what will be done, when, and by whom to maintain change adoption, for example, power users, transition to operations, and ongoing training.
    • Tools to Confirm Readiness for Change: for example, Go Live Plan, Go Live Stage Gate Review, testing, and sign off by all required stakeholders including the Operations Team.
    • Tools to Establish Change Accountability: for example, RACI, Decision Log, Change Requests, and Transition to Operations Checklist, and sign off.
    • Tools to Confirm Learning and Sustainment of Change: for example, documentation for solution design / build / implementation, testing, training, and transition to Operations.
    • Tools to Confirm Change Acceptance: for example, testing, stakeholder communications, governance, stage gates and health checks, user / stakeholder sign off, training, and warranty periods.
    • Tools to Confirm Change Feedback: for example, end user surveys and tracking service tickets.
    • Project Issue Escalation: using the project organization chart, identify how project issues will be escalated and resolved.
    • Project Meetings: identify the meetings that will take place during the project lifecycle, for example, Status Meetings, Steering Committee Meetings, Working Meetings, Internal Stakeholder Meetings, External Stakeholder Meetings, and Project Team Meetings.
    • Training Requirements: at a high level, identify anticipated training required, as well as whether different types of training are required for different groups, e.g. Business vs. Operational. Remember to note that a Training Plan will be developed if required.

Having either the Lite or more detailed Communication and Change Management Plan in place at the beginning of a project provides the early on OCM focus that sets the stage for the importance of this component throughout the project lifecycle. It demonstrates to project governance and stakeholders that the project leadership team is aware of OCM and how it supports project success, and has the capability required in the organizational change management space. Even if there is no requirement to provide any other OCM artifact, development of the Communication and Change Management Plan, and updating it throughout the project lifecycle as needed, will provide the guiding framework that parallels and supports the other workstreams within the project to enable a holistic and comprehensive approach that keeps the primary purpose of any project in mind – that being a satisfactory experience for the client.

Ms. Marianne Hang is a Senior Project Manager affiliated with IT Architects in Calgary, Alberta. IT Architects (www.itarchitects.ca) is an information consulting firm specializing in business process optimization, system evolution planning, and the deployment of leading-edge technologies. If you require further information, Marianne can be reached at info@itarchitects.ca or 403-815-7505.

Leave a Reply

Your email address will not be published.