Operational Excellence in Project Management

• governance;
• planning;
• monitoring;
• dependency management;
• performance tracking;
• decision support.

• more meetings;
• more controls;
• more indicators;
• more rituals;
• organizations may still experience:
• rework;
• misalignment;
• constant change;
• conflicting interpretations;
• difficulty sustaining decisions.

Not every problem requires the same response

• increase reporting;
• expand governance;
• create additional rituals;
• tighten accountability.

• When teams struggle to converge, the issue may not be execution alone. Different groups are often operating with different interpretations of context, priorities, or the meaning of the situation.
• When small changes create large effects, it is worth investigating dependencies that have not yet been identified or understood.
• When priorities shift continuously, the context itself may still be evolving and generating new information that changes direction.
• When decisions produce conflicting interpretations, there is usually some level of organizational ambiguity that has not yet been surfaced or addressed.

Decisions do not always arrive complete

• open assumptions;
• partially understood impacts;
• constraints still being validated;
• dependencies still emerging.
• The natural reaction is often to fill the gaps quickly.

What is defined

What remains under analysis

What happens next

Data does not replace understanding

• Now the task is to turn information into useful interpretation.
• One simple practice is to review the questions being asked in meetings.

• What has changed since the last decision?
• What assumptions are no longer valid?
• Where have different interpretations emerged?
• What are we assuming without evidence?
• What still needs to be understood before accelerating?

Alignment becomes a process rather than an event

• review assumptions regularly;
• document critical hypotheses;
• make open decisions visible;
• create short interpretation checkpoints;
• validate understanding with stakeholders.

Communication also changes

• rumors;
• parallel interpretations;
• misalignment.

What we know

What is still evolving

What we will do now

Five questions for PMOs to bring into the next meeting

1. Do we have a shared understanding of the context?
2. Are we treating assumptions as facts?
3. Is the system continuing to change while we execute?
4. Are we adding control or increasing understanding?
5. What still needs to be interpreted before accelerating?

Closing

Measurement does not start with impact. It starts with the structure that allows impact to be observed.

This implies three distinct layers that most PMOs tend to mix.

• Progress is not impact

The first mistake is using progress as evidence.

Common examples include:

• percentage of projects delivered
• schedule and cost adherence
• number of completed initiatives

These indicators demonstrate execution, not effect.

They answer:

“What was done?”

But they do not answer:

“What changed because of it?”

This distinction is fundamental.

Impact only exists when there is an observable change in the organizational system.

• Maturity is not impact

The second mistake is using maturity as a proxy for impact.

More structured PMOs often assume:

“We have capability, therefore we generate impact.”

The data suggests otherwise.

Organizations continue investing in delivery capability while still showing significant gaps in converting those investments into business outcomes.

Capability measures potential.

Impact measures realization.

Without evidence of realization, maturity is merely infrastructure.

• Impact requires direct linkage to services

The PMO-MI model is explicit:

Impact is not attributed to the PMO as an entity.

It is attributed to the services the PMO performs.

This entirely changes how measurement should be approached.

The question is not:

“PMO impact”

The question becomes:

“What is the impact of service X within domain Y?”

Without this linkage, there is no traceability.

And without traceability, there is no evidence.

• Evidence comes from integration, not isolated indicators

Another recurring mistake is treating indicators as proof.

Isolated indicators do not demonstrate impact.

They must be integrated into a coherent interpretation logic.

Within the AIPMO perspective, measurement maturity requires moving from data to decisions. This implies:

• integration between records (risks, decisions, changes)
• connection with executed services
• longitudinal interpretation over time

Without this, the PMO accumulates data but does not generate evidence.

• Impact is inferred, not declared

Impact does not appear directly.

It must be inferred through observable patterns.

For example:

Not:

“The PMO improved decision-making.”

But rather:

• reduction in decision-making time
• fewer rework cycles
• greater prioritization stability

And most importantly:

A clear connection with the service that generated the effect.

Without this structured inference, the PMO remains trapped in perception.

The central point

If impact cannot be traced, connected to services, and observed in organizational behavior, then it is not being measured.

It is being assumed.

• Replace structural thinking with service-oriented thinking

Influence is not a characteristic of the PMO. It is the result of the services the PMO delivers.

The PMO-MI Model model is direct:

Impact is not in the existence of the PMO, but in how its services operate and connect.

This changes the core question.

Instead of asking:

“What is the role of the PMO?”

The question becomes:

“Which services actually interfere with relevant decisions?”

Without this shift, the PMO continues trying to gain relevance through internal structure.

And that does not change outcomes.

• Reposition services into the correct domains

Not every service needs to influence decisions. However, critical services must be positioned where decisions are made.

The model establishes that impact occurs in the domains of control and influence, not within observation.

This requires a clear distinction:

• services that remain in the domain of concern continue to be informational
• services positioned in the domain of influence begin shaping decisions

Without this distinction, the PMO increases operational activity without increasing organizational relevance.

• 
  
• Integrate capabilities to generate organizational effect

Isolated capability does not create influence.

Impact is not the result of adding practices together.

It emerges from the integration between services and domains.

This is the most neglected point.

PMOs improve processes, tools, and controls.

But they fail to integrate capabilities in ways that alter how the organizational system operates.

The result is predictable:

• Consistent execution with no meaningful organizational change.
• Influence requires something different.

The capability to connect information, anticipate implications, and act before decisions become fixed.

Without this, the PMO reacts instead of directing.

Repositioning the PMO is not about evolving practices. It is about changing how the organization makes decisions.
When this happens, the evaluation criteria change.
The PMO stops being measured by what it controls and starts being recognized by what it changes.

Without this movement, any evolution tends to reinforce the current pattern:

• more internal capability with the same absence of influence.

• Risks continue to be absorbed too late
• Priorities continue to be redefined outside the PMO
• Decisions continue to happen without structured input

None of this shows up in internal assessments.

Because they measure consistency, not influence.

This is the breaking point.

A PMO can continuously evolve while simultaneously losing strategic relevance. When that happens, the nature of the discussion changes.
It is no longer about quality.
It becomes about necessity.

The PMO is not questioned for what it does. It is questioned for not making a difference.
From that point onward, any additional evolution tends to generate diminishing returns.
More process.
More control.
The same irrelevance.
The required shift is not technical.
It is structural.

As long as the PMO continues to operate as a mechanism for organizing execution, it will remain outside the decision core.
And outside the decision core, there is no perceived value.
In the next pieces, I will explore three points that are usually left out of this discussion:

• How to reposition the PMO to generate real influence,
• How to measure impact practically, and
• How to connect PMO services to executive decision-making.

Introduction

The Nature of Cyber Risk in Projects

• Interdependence: vulnerabilities in one system may propagate across integrated platforms
• Latency: risks often remain undetected until late phases of execution
• Impact asymmetry: relatively small vulnerabilities can generate disproportionate operational or financial consequences

• operational continuity
• regulatory compliance
• organizational reputation
• physical safety (particularly in OT environments)

Integrating Cybersecurity into Project Management

• Definition of security requirements aligned with business and regulatory expectations
• Identification of critical assets and threat vectors
• Integration of security criteria into scope and acceptance definitions

• Continuous validation of security controls
• Coordination between technical teams, vendors, and governance structures
• Monitoring of vulnerabilities introduced during implementation

• Use of specific cybersecurity KPIs, such as:
• percentage of implemented security requirements
• number of critical vulnerabilities resolved within SLA
• incident response time during testing phases
• Alignment with frameworks such as ISO/IEC 27001 and NIST CSF

• Validation of compliance and certification requirements
• Documentation of lessons learned related to security incidents and controls

The Role of the Project Manager

• facilitating alignment between business, technical, and regulatory stakeholders
• ensuring traceability between security requirements and implementation outcomes
• supporting decision-making under uncertainty, particularly in risk prioritization

Common Implementation Challenges

• Fragmentation of responsibilities between IT, security, and business units
• Late inclusion of security requirements, increasing rework and costs
• Limited visibility of cyber risks at the portfolio level
• Difficulty in measuring the real impact of security initiatives

Practical Application: What Should Change in Project Execution

• Embed security checkpoints in stage-gate or agile review cycles
• Define minimum security baselines for all project types
• Establish clear ownership of cybersecurity risks within the project structure
• Integrate security metrics into project dashboards and reporting routines
• Use risk-based prioritization to balance delivery speed and protection requirements

Conclusion