Year: 2022

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

Advertisement

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 Management Plan – Project Close

Professor of Project Management Project Planning
Planning

When you are managing a long-running project, your sponsoring business partners may start to feel you are a permanent part of their team. Since many projects have enhancements to make after the initial project is done, it is easy to get endlessly drawn into managing these enhancements as if they were part of the original project.

Your defense against this is to define the conditions of project close in your Project Management Plan. Here is a sample list of typical conditions:

  • The Project Objectives from the Project Charter have all been met
  • Contracts have been fulfilled and closed.
  • Lessons Learned have been documented and reviewed
  • Project Documents have all been stored in the project document repository
  • There are no critical open issues (there will always be some issues left over; as long as they are not critical, these can be handled by your post-implementation Support Model)

Be sure to include this section in your Project Management Plan and that your Project Sponsor is aware of and agrees to these conditions in advance.

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

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

The Project Management Plan – Procurement Management

Professor of Project Management Project Planning ,
Planning

In many projects you will need to procure or purchase something. It might be software, hardware, professional services, office space, furniture, resources, licenses, permits, etc. It is up to the Project Manager to determine what needs to be procured, who is providing the funding, who will sign the purchase orders or contracts, and the timing of when it is needed for the project. These actions need to be tracked and managed in order to stay on schedule and budget.

Many organizations have policies and procedures on procurement to ensure they are getting the best deal and there are no suspicious or illegal activities. Be sure to understand the relevant policies and procedures for your organization

The Procurement Management Plan addresses at least the following:

  •   Lists what to purchase or acquire and when and how
  •   Documents all products, services, and results requirements
  •   Identifies potential sellers
  •   Describes how sellers will be selected
  •   Describes how contracts will be negotiated, administered and closed. You can   reference the Contract Management policies of your organization

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

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

The Project Management Plan – Risk Management

Professor of Project Management Project Planning , ,
Planning

Managing risk stands along with having a well-defined Project Charter as the two most important disciplines of Project Management. Having a documented plan for how you will manage risk will help enforce the practice.

In a future post I will describe the metrics that are used to measure the health of a project. One of these measures is Risk Management. The health of managing risk is “green” (which is good) if you have a sponsor-approved plan for managing risk and are adhering to it.

The Risk Management Plan addresses the following:

• Identify the template to be used as the Risk Register.  Include column definitions and an example. In a future post, when I elaborate on Risk Management, I will identify the key components of a Risk Register

• Include the procedures you will use to identify, monitor and escalate risks. This includes identifying who will participate in Risk Management sessions.

• Identify standard checklists or historical risk information you can use for Risk identification

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

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

The Project Management Plan – Communications Management

Professor of Project Management Project Planning
Planning

Managing communications on a project is one of the top real-world challenges, right up there with the battle for resources. Project crises are frequently created by miscommunication or lack of communication.

Communications must be managed on many levels:

  • Communicating up to Executives and the Project Steering Committee
  • Communicating sideways to your management peers
  • Communicating down to the project team members (note the “up”, “sideways” and “down” designations refer to the typical project hierarchy chart and are not meant to be derogatory)
  • Managing the lines of communication. There are potentially n(n-1)/2 lines where n = the number of people involved in the project. For example, a project with 10 people has 45 potential lines of communication!

Knowing how to tailor your communications to each audience is an important skill. Executive communication is typically brief and bottom-line (are we on schedule and budget? Do we have critical issues? How are high-exposure risks being managed?). Communication to management peers usually will include important project metrics (schedule, budget, scope, resources, issues, risks, task plans). Communications to project team members is focused on near-term task planning and upcoming milestones.

The Communications Management Plan specifically addresses the following:

  • Identifies all of the stakeholders and determines their information and communications needs
  • Identifies how and when the information will be distributed, including status reporting, progress measurement, and forecasting
  • Identifies how stakeholders will be managed to satisfy their requirements and resolve issues. This includes defining the lines of communication and the mechanism for issue logging and visibility
  • Identifies the project document repository and the folder names

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

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

The Project Management Plan – Staff Management

Professor of Project Management Project Planning
Planning

Staff management planning is important to prevent or minimize the battle for resources, which is the number one problem for most Project Managers. The Staff Management section of the Project Management Plan addresses the following:

• Identifies project roles, responsibilities, and reporting relationships

• Describes how the project team will be formed, developed, and managed. This includes procedures on releasing and adding team members

Identification of roles can occur even before you know the specific names that will fill those roles. It is based on the parameters and demands of the project. Examples of roles are “Executive Sponsor”, “Project Manager”, “Business Analyst”, “Tester”, “Contract Reviewer”, etc.

Defining the responsibilities of each role is important to minimize the chance of two unwanted outcomes: (1) two or more people are duplicating effort because they all think they own it; (2) key responsibilities are not taken on by anyone because they think it is owned by someone else.

Defining the reporting relationships is important as you will need to know who to go to for permissions and escalations.

Understanding how the project team will be formed is important to make sure you will have the roles filled on time, for the time needed, and with the skill sets required to meet the schedule.

The Project Manager also has a responsibility to develop the project team members soft and hard skills so they become more valuable to the organization and increase their personal job satisfaction. This development can take many forms. It can be formal training, coaching or show by example. You can discuss who will be targeted for development with the managers of the project team members and define what form it will take.

My Kindle book (now also available in paperback!), “Project Management For The Real World”, is available at

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