Project Plan

The Project Plan Part 3c – The Organizational Change Management Plan: Managing Change

Professor of Project Management Project Planning ,
Planning

Managing Change includes the design of Organizational Change Management Plans and individual change management activities. This is the “what you are going to do” to manage the change. Here are the components of the plan to manage change:

Communication Plan – Communication is a key component of explaining what is changing and why to the organization. Be sure to include the “WIFM” (What’s in it for me?) message. These communications should promote awareness of the project, the timeline, and how the changes will impact each affected group.

Training Plan – This plan will not only focus on training for a new system but also new processes. It will provide the specifics of what is changing for each user group. Also, included in the training is reiteration of why we are embarking on the change initiative.

Coaching Plan – Your coaching plan defines how you will support managers and supervisors during the change and how they will interact with front-line employees. The objective is to fully enable these managers and supervisors to:

• Sponsor the change

• Support their employees during the change

• Support their employees in the new, changed environment

The steps to developing a coaching plan:

1. Enable supervisors and managers to be effective change management coaches

Prepare a change management program and deliver this program to supervisors. Several key areas should be addressed with supervisors:

• Why is supervisor involvement important in change management?

• How do I talk with my employees about change?

• How do I coach my group through a change?

• Identifying different ways that people deal with change and how to coach them through it.

• How do I coach individual employees through change?

• What are the expectations for coaching in this project (frequency, timelines, agendas, etc.)?

2. Develop group coaching activities and timeline

Supervisors should prepare for and meet with their groups to discuss the change. Key messages should be provided by the change management team.

Group coaching during a change is an effective medium for distributing information and gathering feedback. It can help to build support for change and ease concern and resistance.

3. Develop individual coaching activities and timeline

Individual coaching sessions are one-on-one opportunities for supervisors and managers to work on change with specific employees. The face-to-face messages received are important as employees work through the change and try to perform in the changed environment. You should develop a matrix with the following components: Coaching Activity, Purpose, Timing, and Audience.

Workforce Transition Plan – A Workforce Transition Plan is a detailed plan to address changes in roles, responsibilities and organization structure. You need to plan how individuals will transition as a result of change and ensure they are transitioned according to organizational values and policies. You should develop a matrix with the following components: Individual or Group, Supervisor, Describe the transition, New Skills Required, Resolution, Communication Needs, Comments.

Resistance Management Plan – A resistance management plan is a proactive approach to managing resistance. During the assessment you identified potential resistance points. As your project implementation progresses, additional areas of resistance may surface. Below are action steps to creating your resistance management plan and the template:

1. Review areas of resistance from the assessment and define what resistance may look like for your change and how it may be identified.

o Brainstorm with the change management team and project team

o Brainstorm with the stakeholders and sponsors

2. For each level with the impacted organization, define a strategy for managing resistance to the change.

o Brainstorm strategies to address the key areas of resistance. This may be changes in functionality, new skills required or certain departments that may be resistant to the change. Some examples of possible strategies include:

• Communication about why we are making the change, benefits to the organization, and WIFM (What’s in it for me?)

• Training or job aids to assist in the transition

• Pairing up certain areas of the organization that will be the most affected by the change with positive change agents or project team members

• Engage with managers, supervisors and coaches to help these individuals along in the change

My book, “Project Management For The Real World”, is available in paperback and Kindle formats at

http://www.amazon.com/dp/b089krddvn

The Project Plan Part 3b – The Organizational Change Management Plan: Preparing For Change

Professor of Project Management Project Planning ,
Planning

Plan preparation includes activities to prepare yourself and the team for managing the change and the creation of the change management strategy. This allows the team to understand the magnitude of the change and potential resistance from the organization.

Defining the Scope of the Change

Defining the scope of the project for change management purposes means answering the following questions:

  • What are the changes that will occur as a result of this project?
  • Who will be affected?
  • What will be the magnitude of the change?
  • How might the affected groups react when notified of this change? What will be their concerns?
  • How can their concerns be addressed?

Putting the answers in a spreadsheet will help the planning process.

Conduct an Organizational Assessment

You can assess the organizational readiness for change by finding the answers to the following questions:

  • How resistant is the organization to the change associated with this project?
  • What is the capacity for change within the organization? Is the organization already being required to make changes elsewhere? How much more change can the organization absorb?
  • What is the history of similar projects/change within the organization? Did past projects/changes leave a residual effect that could either work in your favor or make the management more challenging?
  • What is middle management’s predisposition to change? Is the management team behind the change effort? Are there any that are opposed?
  • Anticipated Resistance – are particular departments, regions, etc. impacted differently than others? Were certain groups advocating a different solution? Are certain groups heavily invested with how things are done today?

In the next post I will address the components of “Managing Change” and the ADKAR change methodology.

My book, “Project Management For The Real WOrld”, is available in paperback and Kindle formats at

http://www.amazon.com/dp/b089krddvn

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

Professor of Project Management Project Planning ,
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.

RoleDescription/ResponsibilityName(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/TeamFormulate 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 

Get these commitments well in advance. Don’t assume you can ask people to fill these roles “on the fly”. Change management tasks take a lot of effort and need to be well planned.

My book, “Project Management For The Real World”, is available in paperback and Kindle formats at

http://www.amazon.com/dp/b089krddvn

The Project Plan Part 2 – The Operations Plan

Professor of Project Management Project Planning
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, the technology to be used for report delivery, 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

My book, “Project Management For The Real World”, is available in paperback and Kindle formats at

http://www.amazon.com/dp/b089krddvn

The Project Plan Part 1 – The Development Plan

Professor of Project Management Project Planning
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.

My book, “Project Management For The Real World”, is available in paperback and Kindle formats at

http://www.amazon.com/dp/b089krddvn

The Project Plan – Overview

Professor of Project Management Project Planning
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)

You will not necessarily need all of these plans for a given project. It is good practice to review each one for every project to see if they apply. Some of these topics will require multiple posts to give them the depth they deserve.

My book, “Project Management For The Real World”, is available in paperback and Kindle format at

http://www.amazon.com/dp/b089krddvn

The Project Plan Part 9 – The In-Project Support Plan

Professor of Project Management Project Planning ,

Planning

The In-project Support Plan is needed if all or part of the solution is to be supported by a vendor or 3rd party. It addresses support needed during the project which includes the post-implementation stabilization period.

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

  • Scope – describe the conditions in which this support is triggered.
  • Contact information – phone #’s, email, website, customer access id
  • Service Level Agreements (listed in order of severity, commits to how fast you can expect a response to a reported issue)
  • Problem and Status Reporting – what tools will be used, roles, responsibilities
  • Escalation Procedure if issues are not addressed in a timely or effective manner
  • Change Requests – for changes that are not bugs, define the request procedure & labor rate

This topic concludes the series on “The Project Plan”. In the next series of blog posts, I will address development of the Project Schedule.

The Project Plan Part 8 – The Post-Live Support Plan

Professor of Project Management Project Planning ,

Planning

The Support Plan describes how the solution will be supported once operational. This includes a description of the support personnel and their roles as well as the processes to resolve problems arising within the solution boundaries.

Implementing a Support Plan is an important piece of Project close-out. The operational Stakeholders must be self-sufficient once the solution is live and no longer dependent on the Project Manager. Lack of a Support Plan is the primary cause of Project Managers being attached to projects for a long period of time after go-live.

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

  • Support Resources, Roles, Responsibilities
  • Support model – define who will function as level 1, 2 & 3 support, how they will be contacted, and their staffing needs
  • Service Level Agreements (e.g. system availability, up-time, response time, etc)
  • Help Desk support
  • Vendor Support (support that will be purchased from the vendor) including naming the Stakeholders that will be the vendor support point of contact
  • Specialists (describe circumstances in which in-depth knowledge of the solution requires engaging specialists)
  • Product Updates – Who is responsible? Software vendors typically release updates multiple times a year. How often do we plan to apply them? How will it be tested? What is the roll-back plan? Who will monitor changes in platform support?
  • Include both one-time and ongoing costs for the items listed above

The Project Plan Part 7 – The Deployment Plan

Professor of Project Management Project Planning ,

Planning

The Deployment Plan describes the factors necessary for a smooth deployment and transition to ongoing operations. It encompasses the processes of preparing, installing, training, stabilizing, and transferring the solution to operations. For some projects, deployment can be very complex. For these types of projects it pays to start deployment planning as early as possible to manage the risk of delays due to deployment difficulties.

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

  • Scope
    • Stakeholders (those affected by the solution)
    • New and changed Business Processes
    • Licensing considerations
    • Approx. # components per platform
  • Deployment strategy & schedule (e.g. phased, site-by-site, push vs. pull, dept. by dept, etc)
  • Organizational Change Management
  • Implications of new and old system and processes in production at the same time
  • Deployment Resources
  • Help Desk Preparation
  • Desktops/Servers Affected
  • End User Training (High level business process and detail usage)
  • Installation Process
  • Installation Validation
  • Support during Stabilization
  • Hand-off to Support and Operations
  • Activation of Monitoring (for computer systems and business processes)

The Project Plan Part 6 – The Pilot Plan

Professor of Project Management Project Planning ,

Planning

Some organizations define a solution “pilot” as a “limited deployment” for the purpose of managing risk. That can be covered in a Risk Management Plan in lieu of a Pilot Plan. The definition we will use in this post is to use a Pilot to gather information about the solution that can only be discovered by “going live”. The intent of the Pilot is to obtain the information and then pull the solution out of the live environment for additional work.

The Pilot Plan describes what aspect of the solution will be delivered as a pilot and provides the details necessary to conduct the pilot successfully. This includes details on how to evaluate the pilot, the results of which will facilitate a decision whether or not to move the solution to production. Projects often create one or more “pilot” solutions for the purpose of proving the feasibility of solution approaches, experimenting with different solutions, and obtaining user feedback and acceptance on proposed solutions. Pilot solutions usually implement only those subsets or segments of requirements or functional specifications necessary to validate a solution.

The Pilot Plan provides the means to validate business requirements and technical specifications prior to deploying the solution into production. Planning the details of the pilot ensures that the participating project teams identify their roles and responsibilities and resource requirements specific to pilot development, testing, and deployment activities.

A pilot can provide key information on development processes, end-user validation, and production environment usage. It also provides feedback to stakeholders regarding the success of the solution once it is formally released.

Note that Pilot Plans are not just for IT projects. For example, fast food chains will often test new menu items for a limited time in a small number of locations to gauge consumer interest and test the store’s ability to deliver the product successfully.

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

  • Overview – Scope (what part of the solution will be demonstrated as part of the pilot, and the target user profile used to select which users will participate)
  • Success Criteria and Metrics – The success criteria may fall into the following categories:
    • System performance
    • Operations cost
    • Stability –down time
    • User performance
    • User satisfaction
    • Business goals
  • User Preparation and training
  • Marketing Plan – how users will become aware of the pilot and the value to them
  • Conditions for adding additional users
  • Rollback – conditions for rolling back the pilot to pre-deployment state
  • Pilot Evaluation – describes how the pilot results will be evaluated