The Project Plan Part 3a – The Organizational Change Management Plan: Roles & Responsibilities

Planning

Organizational Change Management is a structured approach to transitioning individuals, teams, and organizations from current state to a desired future state. The outcome of “People Change Management” is the number one reason why projects will either succeed or fail.

The Organizational Change Management Plan provides a framework to effectively lead your affected stakeholders through the changes that occur within a project. I will address this topic in four posts starting with this one (defining the roles and responsibilities). The topics for the remaining posts are :

  • Preparing for Change
  • Managing Change
  • Reinforcing Change

Roles and Responsibilities

Defining the roles within the team and organization ensures that the team members understand their role in effecting the change within the organization. Use the table below to define the roles, describe the responsibilities and define the names of who will fill the role.

Role

Description/Responsibility

Name(s)

Executive Sponsor/ Change Champion

“Face” of the project communicating directly with employees and management

Participate actively and visibly throughout the project

Build a coalition of sponsorship and manage resistance – identify other Executives who will Champion the change

 

Change Management Resource/Team

Formulate change management strategy – evaluate how big the change is and who will be impacted

Develop change management plan – determine what actions will be taken to enable moving people forward including a communication plan, sponsor roadmap, a coaching plan, training plan and resistance management plan

Execute plan with the other “doers” on the project

 

Change Agents (Middle managers and supervisors)

These are people that have influence in the organization that  can be an advocate for change

Communicator of the change – become well versed in the changes that are occurring and why so they can communicate the message to the employees

Coach – trained in how to help the employees through the change

Liaison between the employees and the change management/project team taking direction and providing feedback on the “buzz” in the organization

 

The Project Plan Part 2 – The Operations Plan

Planning

The Operations Plan describes how day-to-day operations will occur when the solution is in place and the project is over. The planning principle is to “begin with the end in mind”. This definition of the end state will help you complete the identification of the Stakeholders and verify that you have the complete list of Project Objectives in the Project Charter. It provides guidance to the organization on how to successfully maintain the solution over time.

Here is a list of some things to consider (this is not necessarily the complete list of considerations; your project may have more):

• Operations Infrastructure – a comprehensive description of the environment into which the solution will be deployed and supported (including incident management).

• Service Level Agreement (SLA) – addresses up-time, performance, redundancy and disaster recovery

• Reporting Model – describes generally who will receive reports, what information they will get and on what schedule, and what source data will be used to generate the reports.

• Organization Skill and Time Requirements – identifies the job roles, associated skill requirements and work time necessary to operate the solution. This information could be placed in a matrix that identifies 1) types of operational functions, 2) the job roles that work within each function, 3) the skill requirements for each job role, and 4) the frequency and time required (i.e. “3 hours per month”). This information can be used to identify organizational impact for your Organizational Change Management Plan (more on that in future posts). Make sure you identify the Administrators and their functions.

• Software and Data Updates and Refreshes from External Sources; how often and how it will be tested and verified.

• Backup/Recovery; how often backups will occur and the process to order a restore.

• Scheduled Maintenance Times; when and how often will the system be unavailable for maintenance

• Monitoring; who is responsible for monitoring system performance; what tools will be used.

• Security – requests to add access, remove access or change roles

The Project Plan Part 1 – The Development Plan

Planning

The Development Plan describes the solution development process used for the project in order to achieve the Project Objectives as defined in the Project Charter. This plan complements the Requirements specifications that details what will be built and provides consistent guidelines and processes to the teams creating the solution.

Here is a list of some things to consider when creating the Development Plan (this is not necessarily the complete list of considerations; your project may have more):

  • Intermediate deliverables needed to achieve the Project Objectives. For software, this list includes documents for Requirements, Design, Configuration, Build, Test and Deploy.
  • Delivery Strategy (e.g. phased implementations, high-priority/high-risk items first, “depth-first”, “breadth first”, “features, then performance tuning”)
  • Design Goals (e.g. create reusable components, use existing components, ease of maintenance vs. speed of delivery, security, etc)
  • Development and Build Environment – this has the potential to be a high-work, high-risk area. Include source code control, software and tools needed, test data, connectivity to other environments, security, tool and run-time licensing etc
  • Naming Conventions
  • The Build Process (how will versions be created for system, user and quality testing)
  • List Components and who will build them –  Also state if you have to buy components and how you will acquire them.
  • Development tools – also identify licensing needed.
  • Team Training and Support – identify training for the development team and what support they will need

You need to break down the activities listed above into pieces of work small enough to assign to one or more resources and estimate the effort and duration of the activity. The level in which you break this down is usually at the Project Manager’s discretion and will vary by project.

In addition to assigning resources and effort, you should describe how the activity will be accomplished. For example, if your major activity was ” Create System Design Document”, you could break this down into lower level activities such as “Data Design”, “Interface Design”, “Transaction Process Design”, etc. For “Interface Design” you could refer to company standards (if they exist), what languages and technologies will be used and what reviews and approvals are needed.

As we go thru each part of the Project Plan in subsequent posts, you will be collecting a list of activities that will ultimately be used to build the Project Schedule.