Key Concepts
Projects happen inside organizations, and a project that ignores its surroundings can deliver a perfect product that nobody uses. Supporting organizational change means understanding the groups, culture, and willingness to adapt, anticipating how the change will land, and planning the work to give it a fair chance of sticking.
Projects do not occur in a vacuum. They happen in organizations with their own histories, structures, reward systems, and tolerance for upheaval. A project that ignores the organization around it can deliver a perfectly built product that nobody uses, or a process change that everybody quietly works around. Supporting organizational change is the discipline of paying attention to the culture we operate in, anticipating how our change will land, and planning the work needed to give it a fair chance of sticking.
Supporting organizational change requires an understanding of the groups, culture, and willingness to adapt. For each group in an organization, there are many factors to consider:
- Motivation and reward systems
- Regulations, policies, and procedures
- Risk tolerance
- Operating environment
- Shared vision, beliefs, and expectations
- Code of conduct
- Information sharing norms
- Promotion and disciplinary processes
3.7.1 Assess Organizational Culture
Before we can support change, we have to learn how the organization actually acts and behaves. Org charts tell us part of the story. The rest comes from watching how decisions get made, how disagreements get handled, who really has authority over resources, and how the organization treats both success and failure. That learning is a culture assessment: looking past the org chart at how decisions, disagreements, and authority work. It feeds our assessment of change readiness, so we know how much energy the organization can spare for this change now.
Organizational Structures
Project managers need to navigate various work cultures, norms, management practices, and organizational structures. Often, the structure of an organization affects access to people and how they interact with one another. This in turn affects how projects operate. The common organizational structures are:
- 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.
- Matrix – somewhere between Functional and Projectized, where people report into a functional area but also to a project manager. A Weak Matrix is closer to Functional structure and the PM’s authority with team members is limited. A Balanced Matrix splits authority. A Strong Matrix is closer to a Projectized environment with high PM authority.
- Projectized – people get seconded to projects, and while on the project, they report to the project manager.
- Composite – 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 to suit a particular project. They may run one project as a Matrix while another runs Projectized and a third runs Functional.
Project Management Offices (PMOs)
A Project Management Office is a group in an organization that provides or confirms compliance to project governance. The PMO may oversee or assist with the execution of projects. As with organizational structures, there are several types of PMO with varying authority levels:
- Supportive PMOs – exercise a low level of control over a project and 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 confirm project management approach compliance.
- Directive PMOs – have a high level of control over projects. They may provide the project managers and be responsible for the project’s success.
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 emphasizes the shift to concentrating on value and assisting with its delivery.
Exam Tip on PMOs
On the exam, assume there is a functioning PMO that provides the expected services and support described here. In practice this is often not the case, but if a question mentions a PMO, assume it is comprehensive and effective.
Organizational Process Assets (OPAs)
PMOs are often the custodians of the processes, procedures, and document templates we use to run projects, along with the lessons learned repositories. These procedures and knowledge stores form a large part of what we call OPAs. The OPAs themselves were introduced in 3.1; here the question is how they shape the cultural picture. Highly mature OPAs typically signal a culture comfortable with formal process. Sparse or unused OPAs usually signal a culture that prefers informality and direct decision-making. Neither is good or bad on its own, but the difference tells us how change is likely to be received and what artifacts will help that change land.
Enterprise Environmental Factors (EEFs)
EEFs are conditions outside the control of the team or project manager. They can be external or internal. External examples include government regulations, laws, industry standards, and market conditions. Internal examples include organizational culture, the type of organizational structure, internal political conditions, infrastructure, geographic locations, and available resources. Since EEFs are factors a project manager or team would likely struggle to change, they represent things considered a given, and we have to be aware of them when planning.
OPAs and EEFs together describe the environment our projects operate in. Some settings are formal, strict, and slow to change. Others are adaptive, constantly evolving, and easier to make changes within. These organizational and environmental realities influence how change is viewed and handled in projects. They also influence the change management approach we should adopt and how project outcomes will be rolled out.
Reading the Culture in Practice
Beyond the formal structures and assets, a few indicators can tell a project manager what we are walking into. How are mistakes treated? Are they investigated for learning, or pinned on individuals? How are decisions made? By the most senior person in the room, by consensus, or by the person closest to the work? How are rewards distributed? By individual contribution, team performance, or political alignment? The answers do not change the project, but they tell us which change tactics will work and which will be quietly ignored.
3.7.2 Evaluate the Impact of Organizational Change on the Project and Determine Required Actions
Most projects exist to create change. The product the project delivers is the visible part. The change in how people work, what they use, and what they are accountable for is the part that actually has to land. Evaluating impact means asking, for each group affected, what changes for them, how big the change is, and what they will need to make it work.
Sometimes our project delivers change to an organization. Sometimes changes elsewhere in the organization land on our project. Both directions need handling, and both may require updates to the project plan.
Change Management Plan
The Change Management Plan was covered in detail in 3.3. As a brief reminder, organizational culture directly influences how an organization manages changes. Highly regulated environments tend to have a cautious, formal, and rigid culture, which leads to rigorous change management procedures with multiple levels of approval. Organizations in new or rapidly evolving environments tend to take a lighter-touch approach. The same plan that governs internal project changes also governs how project-driven changes are released into the wider organization.
Roll Out Plan
Once we know what we want to change, we need a plan to communicate the approach and coordinate the necessary steps. Roll Out Plans explain how the project’s new product or service will be implemented after it is approved. The plan lets the project manager 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 development, the project manager and team become deeply invested in the work and the perceived benefits. It is understandable to expect product consumers to feel the same way, 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 give it the best chance of going 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:
- Who will be trained, by name and by 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 affected by change or makes significant adjustments to its planned deliverables, we will need to change the training plan or some training artifacts to match.
Demos
Changes to procedures or software solutions often benefit from demonstrating the changed processes, workflows, and roles. Demonstrations should be provided to the key customer and user stakeholders for feedback to confirm the changed elements work as intended and do not otherwise affect the solution’s workflow. Early feedback allows for adaptation while the feedback is still immediately relevant. Timely feedback also reduces the cost and risk of any required changes. There is less to rework, and fewer downstream elements built on top of the components that need to change.
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 or release plans, work packages or backlog items, and team member assignments. In agile projects, it might be necessary to move lower-value deliverables out of scope to make room for the adopted change. The water-line model from 3.3 still applies: accepting a change means displacing a similarly sized piece of lower-priority work.
Guidelines to Recommend, Plan, and Apply Change
When dealing with change, whether it is happening to our project or we are introducing it to others, a few guidelines are helpful:
- For handling changes to traditional, plan-driven projects, establish a single way changes are requested. Make sure the request captures the proposed change, the business value, any risk and risk mitigation recommendations, and the likely cost.
- Confirm a Change Control Board can assess the change cost, risk, value, and 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. If the change is very large or outside tolerances, escalate to the governing board or steering committee.
- Follow your organizational change management practices. Build a compelling case for the change and get buy-in from key stakeholders, then communicate the change vision and benefits to encourage other stakeholders to engage and support the change.
- Confirm changes are appropriately aligned, with updates to other project artifacts such as the project plan, training plans, training artifacts, and software configurations or demonstrations.
Predictive roll out is typically a defined phase near the end of the project, with training, transition, and go-live activities planned upfront and tracked against the Roll Out Plan.
Agile rollout is incremental. Each increment that ships includes its own slice of training, communication, and user support. This way, adoption builds alongside delivery rather than at the end.
Hybrid may combine an agile delivery of the product wrapped in a more structured rollout phase for regulated environments. This can help where training, documentation, and certification have to be in place before go-live.
Deliverables and Tools
- Organizational Structures – Functional, Projectized, Matrix (Weak, Balanced, Strong), and Composite. The structure determines access to people, authority levels, and how projects operate.
- Project Management Office (PMO) – A group providing or supporting project governance. Comes in Supportive, Controlling, and Directive forms with varying authority levels.
- Value Delivery Office (VDO) / Value Management Office (VMO) – Newer forms of PMO that focus on value delivery rather than process compliance.
- Organizational Process Assets (OPAs) – The organizational templates, processes, and knowledge bases whose maturity signals the cultural preference for formal versus informal working.
- Enterprise Environmental Factors (EEFs) – Conditions outside the team’s control, internal (culture, structure, infrastructure) or external (regulations, market conditions), that the project must work within.
- Change Management Plan – The plan governing how project-driven changes are released into the wider organization, including approval levels, the CCB structure, the change process, tracking tools, and emergency change handling.
- Roll Out Plan – The plan explaining how the project’s new product or service will be implemented, including preparation, training, knowledge transfer, support, and transition activities.
- Training Plan – A document or section of the Roll Out Plan describing who will be trained, what training they will receive, when, and how it will be conducted and evaluated.
- Training Artifacts – The components of the training program: learning objectives, courseware, lab configurations, exercises, and assessments.
- Demos – Demonstrations of changed processes, workflows, or roles to key stakeholders, used to get early feedback and adapt while it is still cheap to do so.
- Post-Implementation Review – A review held after rollout to confirm benefits, capture lessons, and identify any follow-on work.
- Project Management Plan Updates – Updates to scope, timelines or release plans, work packages or backlog items, and team member assignments that reflect approved organizational changes.
- Stakeholder Register and Communication Plan – Updated to reflect new audiences and communication needs created by the rollout.
Related Topics
- 1.4 Engage stakeholders
- 1.5 Align stakeholder expectations
- 1.6 Manage stakeholder expectations
- 1.7 Help ensure knowledge transfer
- 1.8 Plan and manage communication
- 2.1 Develop an integrated project management plan and plan delivery
- 2.10 Manage project closure
- 3.1 Define and establish project governance
- 3.3 Manage and control changes
- 3.6 Apply continuous improvement to processes
- 3.8 Evaluate external business environment changes
FAQ
Why do projects fail despite good delivery?
A project that ignores the organization around it can deliver a well-built product that nobody uses, or a change everyone quietly works around.
What does supporting organizational change involve?
Understanding the groups, culture, and willingness to adapt, then planning the work needed for the change to stick.
What should you assess about the organization?
Its histories, structures, reward systems, and tolerance for upheaval.
