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.

The Project Plan – Overview

Planning

There are many Project Managers and Stakeholders who refer to the Project Schedule (usually built in Microsoft Project or equivalent) as “The Project Plan”. This is not true. The schedule shows “who, what and when” but does not address “how”. A plan must address “how” or it is not a plan. I will address the Project Schedule in a separate series of posts.

The prerequisite to building a schedule is to identify all of the activities, and in order to do that you need a Project Plan. Activities will also be drawn from the Project Management Plan (refer to prior series of posts for more on this). This overview will list the main topics of the Project Plan and subsequent posts will do a deeper dive into each topic.

Here are the elements of the Project Plan:

  • The Development Plan
  • The Operations Plan
  • The Organizational Change Management Plan
  • The Test Plan
  • The Migration Plan
  • The Pilot Plan
  • The Deployment Plan
  • The Support Plan (post-implementation)
  • The Support Plan (during the project and stabilization)

Some of these topics will require multiple posts to give them the depth they deserve.

Requirements Elicitation Techniques Part 6 – Document Analysis

Planning

Document Analysis is simply gathering and reviewing all existing documentation related to the scope of the project. It can be very useful in identifying the “as is” state as well as help to uncover Business Events for your Event/Response analysis.

There are three stages to document analysis

  • Stage 1 – Identify the relevant materials
  • Stage 2 – Study the materials, take notes and list follow up questions
  • Stage 3 – Get answers, organize the information into your requirements format

One of the major cons of document analysis is that documentation is often not kept up to date. You will have to verify the validity of anything you plan to use.

Here is a list of documents which can be useful:

  • Business Process Documentation
  • Training / User Guides
  • Functional specs of existing system
  • Business Rules
  • Organization Charts
  • Emails
  • Contracts
  • Help Desk Incident Reports
  • Project Documentation for prior projects in the area under study
  • Existing user enhancement requests

 

The Project Schedule Part 7: Schedule Adjustments

Planning

After you have created your initial cut of the schedule, you will often find that this schedule will not meet the target date. Adjusting the schedule and adapting to changing circumstance is where a Project Manager earns their money.

Here are some of the actions you can take:

  • Focus on the tasks that are on the Critical Path
  • Revisit the estimates – do some of the estimates have more safety time built in than is needed? Where can you reduce estimates and not take on more risk?
  • Fast-Tracking – look at activities that you have scheduled in sequence due to assumed dependencies. Can you do some of these in parallel or at least have some overlap? For example, you might have “Solution Construction” following “Design” but in reality you can start building some of the solution after some (but not all) of the design is completed. Fast-tracking is a very common practice and you will use this on most large projects.
  • Crashing the schedule – this is where you throw additional resources at critical path tasks without regard to efficiency or budget. If meeting the target date is imperative, this is a useful tactic. It is best to plan for this contingency when you are doing your Risk Management Plan in order to have contingency funds in the budget that you can draw on in case the schedule risk is triggered.
  • Obtain stronger resources – you can examine the critical path task assignments and look for opportunities where more experienced and knowledgeable resources would allow you to substantially reduce the task estimates.
  • Reduce Scope – review the ranked requirements and obtain Sponsor approval to remove or delay requirements that are not essential for the initial go-live date.
  • Sacrifice Quality – you can ask the Sponsor for approval to reduce test time for functions that are used rarely or are not business critical.

You are likely to use some or all of the tactics listed above in any project of significant size. It is a critical skill for Project Managers.

The Project Schedule Part 6: The Critical Path

Planning

With tasks, resource assignments, durations/effort and dependencies defined, your project scheduling software will create a schedule. The path of dependent tasks that in aggregate take the longest amount of time is called “The Critical Path”. This is because if any one of these tasks is completed later than originally scheduled, your project end date will move.

When you are in the “Execution and Monitoring” Phase of your project, regular examination of the state of your critical path tasks is a top priority. It is important to routinely check in with the assigned resources to determine if the “days to completion” is still valid. If you wait until the task is late, it will be too late to do anything about it. Your only choice would be to examine the other tasks on the critical path to see if any task times can be reigned in to make up for the lost time. We will examine techniques you can use for this in the next post.

A technique you can use to make your critical path less volatile is to estimate your individual tasks more aggressively and aggregate the extra time you would have assigned to individual tasks into one “critical path buffer”. If critical path tasks come in early, you can add the time saved to the buffer. If critical path tasks come in late, you subtract time from the buffer. Using this technique, your schedule will not move with any one late task and it will encourage team members to work faster and ignore distractions. Also, the health of the buffer would be the key metric instead of the health of each individual task.

You can measure the health of the critical path buffer with two metrics:

  1. % or original buffer remaining
  2. Divide the “% of elapsed project time” into “% of buffer used”. If this is a number less than one you are tracking well. If it is greater than one it is an early warning sign to take action

For example: Your project has used 30% of it’s original buffer but you are only 10 weeks into a 50 week project (only 20% of the project schedule has elapsed), You divide 30%/20% and this equals 1.5 (greater than one) meaning you need to take remedial action.

If your project only used 15% of your original buffer, 15%/20% = 0.75, which is less than one indicating a healthy schedule.

When using this technique, it is very important to regularly update the “days to complete” for each critical path task so you can have confidence in the status of your buffer.

Whatever technique you use, constant monitoring of the health of the critical path is one of the most important tasks for the Project Manager.