• Functional – People report to particular departments like marketing or engineering. As a PM, if you need someone to do some work on your project, you typically have to go to the department head to ask for that person’s time.
  • Projectized – People get seconded to projects, and while on the project, they report to the project manager.
  • Matrix – This is somewhere between Functional and Projectized where people report into a functional area but also to a project manager. We can have a Weak Matrix that is closer to Functional structure and the PM’s authority with team members is limited. Or a Balanced Matrix where authority is split, all the way to a Strong Matrix that is closer to a Projectized environment and the PM’s authority is High.


The table below summarizes other project characteristics, including who typically controls budgets and common part-time and full-time roles.

Beyond Functional, Matrix and Projectized, there is a fourth type called a Composite Organization. This is an organization that uses a mixture of the functional, matrix, and projectized approaches either consistently or on a project-by-project basis.

Composite organizations may change their project structure (just from a staffing, reporting, project authority and budgeting perspective) to suit a particular project. For instance, they may deliver one project using a Matrix approach, while another is undertaken using a Projectized approach. They may also have a third project being handled more in a Functional way.

Project Management Offices (PMOs)

A Project Management Office (PMO) is a group in an organization that provides or ensures compliance to project governance. The PMO may oversee or assist with the execution of projects. Similar to organization structures, there are several types of PMO, each with varying authority levels.

Types of PMOs include:


Supportive PMOs – Exercise a low level of control over a project and instead provide tools, templates, methodology guidance, policy guidelines and support.


Controlling PMOs – Exercise a moderate level of control over a project and provide guidance on how to manage projects. They may also provide training and ensure project management approach compliance.


Directive PMOs – Have a high level of control over projects. They may provide the project managers for projects and be responsible for the project’s success.

Types of PMO
Agile icon

Increasingly, organizations are creating or converting PMOs to Value Delivery Offices (VDO) or Value Management Offices (VMO) that focus on value. The deliberate name change to reference “Value” emphasizes the shift to concentrating on value and assisting with its delivery.

3.4.2 Evaluate Impact of Organizational Change

Evaluate the impact of the organizational change and determine the required actions.

Understand how change is viewed and handled
(Understand how change is viewed and handled)

PMOs are often custodians of the processes, procedures and document templates we use to execute projects along with lessons learned repositories. These procedures and knowledge stores form part of what traditional project management calls OPAs.

Organizational Process Assets (OPAs)

Organizational Process Assets or OPAs is the collective name for all the procedures, processes, policies, documentation, and knowledge bases used by an organization. Project managers and teams may recommend changes to OPAs to improve how projects operate, but they are usually owned and updated by the Project Management Office (PMO).

OPA examples include:

  • Standard templates for project work
  • Specific organizational standards
  • Guidelines and criteria for aligning project work
  • Organizational communications requirements
  • Standardized guidelines, work instructions, proposal evaluation criteria, and performance measurement criteria
  • Procedures for officially opening and closing a project
  • Corporate knowledge bases – repositories for storing project information, including:
    • Project files
    • Policies, procedures, and guidelines
    • Human resources documentation
    • Lessons-learned and retrospective findings


Since EEFs are factors that a project manager or team would likely struggle to change, they represent things that are considered a given, and we have to be aware of them when planning.

OPAs and EEFs describe the environment our projects operate in. Some settings are formal, strict and slow to change. Others are more adaptive, constantly evolving and easier to make changes within. These organizational and environmental realities influence how change is viewed and handled in projects. They influence our change management processes and how project outcomes will be rolled out.


Sometimes our project delivers change to an organization. Sometimes changes impact our project. When this occurs, we need to handle the change and, if necessary, update our plans.

Change Management Plan

Organizational culture directly influences how an organization manages changes to a project.


An organization in a highly regulated environment tends to have a cautious, formal, and rigid culture. This leads to rigorous change management procedures, perhaps with multiple levels of approval. Organizations operating in new or rapidly evolving environments tend to have a lighter-touch approach to change. 

The change management plan describes how changes will be managed and may include:

  • Approval levels for changes
  • The structure of the Change Control Board, if one is used
  • The change control process
  • The tools used to track and communicate change decisions
  • The emergency change process

Project Management Plan Updates

Based on the scope of changes, the project management plan may need minor to substantial updates.

These updates might include:

  • Scope
  • Timelines/Release plans
  • Work packages / Backlog items
  • Team member assignments
Agile icon

In agile projects, it might be necessary to move lower-value deliverables out of scope to make room for the adopted change. See 3.3 Evaluate and address changes for an explanation of reprioritizing the backlog and what happens to items at the bottom of the backlog.

3.4.3 Evaluate Impact of Project to the Organization

Evaluate the impact of the project to the organization and determine the required actions.

Check to see if the desired project changes have been achieved

Once we know what we want to change, we need a plan to communicate the approach and coordinate the necessary steps. What we need is a roll out plan!

Roll Out Plan

Roll out plans explain how the project’s new product or service will be implemented after it is approved. Roll out plans enable the project manager to define the preparation, training, and knowledge transfer activities required to implement the change.

Delivering a new solution and expecting customers or clients to accept and welcome it is unrealistic. During a project’s development, the project manager and team become deeply invested in the endeavor and the perceived benefits.

It is understandable to expect the product or service consumers to feel the same way too, but this is rarely the case. Often customers do not care much or consider it an inconvenience to change how they currently work. Project managers need to “grease the tracks” ahead of the change to ensure it goes smoothly.

Depending on the size, scope, and nature of the change, the roll out plan details might include:

  • Information about the affected customer and user stakeholders
  • Prerequisite work
  • Training plans
  • Support activities
  • Transition support
  • Troubleshooting and escalation procedures
  • Post-implementation review

Training Plan

The training plan can be a section of the Roll Out Plan or its own document. Training plans outline the following information:

  • Who will be trained – by name and role for future new hires
  • What training they will receive
  • When the training will occur
  • How the training will be conducted and evaluated

If our project is impacted by change or makes significant adjustments to its planned deliverables, we will need to change the training plan or some training artifacts.

Training Artifacts

Training artifacts are simply components of the training program. They can be learning objectives, courseware, labs, or assessments. Changes to our project plan and deliverable set sometimes require changes to the training artifacts, including:

  • Changes to the training courseware modules
  • Changes to lab configurations and exercises
  • Changes to knowledge requirements and credentials if certification of skills is expected
  • Training updates for the trainers to learn the changes to the topics in the updated training


Changes to procedures or software solutions often benefit from demonstrating the changed processes, workflows, and roles and responsibilities. Demonstrations should be provided to the key customer and user stakeholders for feedback to ensure the changed elements work as intended and do not otherwise impact the solution’s workflow.

Gaining early feedback allows for adaptation while the feedback is immediately relevant. Timely feedback also reduces the overall cost and risk of making any required changes. This is because there is less to rework and fewer elements built on the components that need to change.

Guidelines to Recommend, Plan, and Facilitate Change

When dealing with change, whether it is happening to our project or we are introducing it to others, the following guidelines are helpful:

  • For handling changes to traditional, plan-driven projects, establish a single way changes are requested. Ensure it captures the proposed change, the business value of the change, any risk and risk mitigation recommendations, and the likely cost of the change.
  • Ensure that a Change Control Board (CCB) can assess the change cost, risk, value, other potential impacts on the project and make recommendations.
  • Use the magnitude of the change and the project’s tolerances to determine if the project manager can approve the change. If the change is very large or outside of the project tolerances, it should be escalated for review and approval to the project’s governing board or steering committee.
  • Follow your organizational change management best practices. This includes building a compelling case for the change and getting buy-in and commitment from key stakeholders. Then communicate the change vision and benefits to encourage other stakeholders to engage and support the change.
  • Ensure changes are appropriately aligned and updates to other project artifacts, such as the project plan, training plans, training artifacts, and software configurations or demonstrations.

Deliverables and Tools

  • Change Management Plan
  • Roll Out Plan
  • Training Plan
  • Training Artifacts
  • Project Management Plan updates
  • EEFs
  • OPAs
  • Demos
  • PM / PMO Org Structure

Related Topics