Strategy Needs More Than Projects: Build the Corporate Support System Behind Execution
You can have a clear strategy.
You can have motivated project managers.
You can even have good individual project plans.
And still struggle to implement the strategy. π€
Why?
Because at some point, strategy implementation becomes bigger than the individual projects themselves.
When several strategic initiatives run in parallel, someone needs to look across them:
π Are we working on the right initiatives?
π Do we actually have the capacity to deliver them?
π Are projects competing for the same resources?
π Are business processes ready for the change?
π Is the technology landscape able to support it?
π Are people prepared to adopt what we are building?
This is where more mature organizations usually introduce several corporate support roles around strategy implementation.
Not to create bureaucracy.
But to prevent chaos.
π§ 1. The Strategic PMO: Connecting Strategy with the Project Portfolio
Many organizations have a PMO.
But not all PMOs play the same role.
Some mainly support project administration. Others act almost as an execution arm of the strategy.
A more strategic PMO can help establish some very important foundations.
A clear project portfolio
First: What initiatives are we actually running?
It sounds obvious.
Yet I have seen organizations where dozens of initiatives were started locally without a consolidated view of the total workload.
Everybody has priorities.
The problem is that everything is a priority. π
A portfolio should clarify:
- which initiatives exist,
- their relative priority,
- which ones are active,
- which ones are waiting,
- and potentially which ones should stop.
Without that discipline, employees constantly switch between initiatives and delivery slows down everywhere.
A portfolio roadmap
The portfolio list tells us what we want to do.
The roadmap tells us when.
At minimum, people should have a high-level view of what the organization expects to work on over the coming quarters.
Otherwise every department creates its own interpretation of the plan.
And sooner or later those plans collide.
Portfolio reporting and governance
Active projects also need to be monitored.
If an initiative starts drifting, management needs visibility early enough to intervene.
That may mean:
β οΈ creating a recovery plan,
π changing scope or sequencing,
π₯ reallocating resources,
π or, occasionally, stopping a project.
Stopping a project isn't necessarily failure.
Continuing to consume scarce resources on an initiative that no longer makes sense can be much worse.
Good governance should therefore clarify who decides what, when, and in which forum.
Standards, systems and capability building
The PMO can also help create consistency through:
- project lifecycles,
- Waterfall, Agile or Hybrid approaches,
- standard templates,
- project repositories and systems,
- training for project managers and team members.
Again, the objective isn't to force every project into the same box.
It is to create enough common language that people can work together effectively.
ποΈ Not every PMO is a Strategic PMO
This distinction matters.
PMOs can play very different roles.
A Support PMO may help project managers with administration, meetings, planning and documentation.
A Control Tower PMO consolidates project information so management can understand portfolio status and make decisions.
A PM Competence Center focuses on methodologies, tools and building long-term project management capability.
And a Strategic Portfolio Management function goes much further.
Its question becomes:
How do we turn the strategy into an executable portfolio of initiatives?
That requires more senior profiles and often experienced program and project managers.
The PMO is no longer simply supporting execution.
It is helping orchestrate execution.
π§© 2. Business & Enterprise Architects: Understanding What Must Change
Projects don't exist in isolation.
They change the organization.
This is why another important corporate capability is business or enterprise architecture.
Business architects can help management understand the organization through several complementary views.
Capability maps
What capabilities does the organization need to execute its strategy?
And more importantly:
Which capabilities are currently missing or insufficient?
Those gaps can then become candidates for strategic initiatives.
Process architecture
Capabilities tell us what the organization needs to be able to do.
Processes show how the organization actually operates.
An end-to-end process view often reveals bottlenecks that aren't visible when every department only looks at its own activities.
A problem that appears to belong to Sales may actually originate in Operations.
A Finance bottleneck may originate in missing master data.
A delivery problem may come from several poorly connected processes.
That enterprise view is extremely valuable when deciding where transformation effort should really go.
π» 3. IT Architects: Making Sure Technology Evolves as One System
Today, almost every major transformation includes a technology component.
This creates another challenge.
A business unit may see an obvious solution:
"Let's implement a new application."
But that application becomes part of an existing technology ecosystem.
IT architects help ensure those decisions work together.
They can maintain views such as:
- which systems support which processes,
- where key data originates and is maintained,
- which applications are becoming bottlenecks,
- where technology obsolescence creates risk,
- how applications and infrastructure interact.
Without that enterprise view, local technology decisions can solve today's problem while creating tomorrow's integration nightmare. π¬
π₯ 4. Change Managers: Making Sure People Actually Adopt the Change
And then there is perhaps the most underestimated dimension of transformation:
People.
A technically perfect solution that nobody adopts isn't much of a solution.
Change managers support program and project managers by focusing specifically on the people side of transformation.
They can help build:
Stakeholder maps
Who is impacted?
Who has influence?
Who supports the initiative?
Who is neutral?
Who is resisting it?
Impact assessments
What exactly changes for each group?
Their responsibilities?
Their processes?
Their tools?
Their organization?
Their daily habits?
Change plans
Communication and training are part of change management.
But they are not the whole story.
A good change plan considers the different actions required to move people from awareness to actual adoption.
Change networks
For large transformations, the project team cannot communicate personally with everybody.
A network of local change champions can therefore become extremely powerful.
These people become relays between the transformation and the organization.
π‘ "But We Can't Hire All Those People!"
Fair point.
Not every organization needs separate teams for PMO, enterprise architecture, IT architecture and change management.
Company size, industry complexity and the scale of transformation obviously matter.
But here is the important distinction:
Not having a dedicated position doesn't mean the role doesn't need to exist.
Someone still needs to think about:
- the project portfolio,
- dependencies,
- capabilities,
- processes,
- technology architecture,
- stakeholder impact,
- change adoption.
These responsibilities can be combined.
They can initially be assigned part-time.
Some can be outsourced.
But somebody needs to own them.
Otherwise they don't disappear.
They simply become invisible gaps in your strategy implementation system.
π¦ Don't Make the Opposite Mistake Either
There is another danger.
Once organizations discover the value of planning and architecture, they sometimes try to understand everything before starting anything.
That doesn't work either.
You need enough portfolio planning to decide which initiatives should be active.
You need enough architecture to understand the major dependencies and risks.
But some dependencies will only become visible as projects develop their detailed plans or design their solutions.
That is normal.
Which is why portfolio planning shouldn't be a one-off exercise.
It should become a continuous dialogue between portfolio and projects.
Projects provide new information.
The portfolio adapts.
The portfolio changes priorities.
Projects adapt.
π That's strategy implementation.
Not a perfectly linear master plan.
π’ So How Could You Start Building This Corporate Support?
You don't necessarily need a major reorganization.
Start small.
1οΈβ£ Define the roles
Decide which capabilities you genuinely need and clarify their scope.
2οΈβ£ Decide how staffing should evolve
Separate what is needed immediately from what may be required later.
3οΈβ£ Create a minimum viable corporate support team
For example, depending on your environment:
- one experienced Strategic PMO / Portfolio Management profile,
- one senior Change Manager,
- with architecture responsibilities initially covered internally or through specialist support.
4οΈβ£ Give them time to create the first enterprise-level views
Don't hire these people and immediately bury them in project firefighting.
Agree upfront on tangible deliverables.
5οΈβ£ Demonstrate value
Build the portfolio.
Clarify priorities.
Highlight capacity issues.
Expose dependencies.
Improve decision-making.
6οΈβ£ Expand when the value justifies it
Add further expertise as complexity and transformation activity increase.
The Key Point
As organizations grow, strategy implementation can no longer depend only on individual project managers doing their best.
You eventually need an organizational system around the projects.
A system that connects:
Strategy β Portfolio β Capabilities β Processes β Technology β Projects β People
The objective isn't more governance for the sake of governance.
It is:
π― more focus,
π§ better planning,
β‘ faster decisions,
π less rework,
π less frustration,
π€ and ultimately greater confidence that the strategy can actually be delivered.
And that confidence matters.
Because people are much more likely to take ownership of a strategy when they can see that the organization has created the conditions for them to succeed.
π¬ How mature is this support system in your organization?
Do you have strong Portfolio Management, Architecture and Change Management capabilities β or are project managers still expected to cover most of these gaps themselves?
I'd be interested to hear how it works in your organization.