Bezpłatny fragment - CRITICAL EFFORT METHOD™ (CEM)

Introduction — When the Plan Is Right, but the Project Is Not

There is a moment that almost everyone involved in projects recognises, even if it is rarely described explicitly.

The schedule is on the screen. Activities are logically connected. Durations appear reasonable. The sequence makes sense. From a planning perspective, everything looks correct.

And yet, something feels uncertain.

That uncertainty is rarely about time. It is about execution.

Nothing in the schedule itself has changed. No rule has been broken. No obvious error is visible.

But confidence in execution is not there.

This moment is rarely documented. It does not appear in reports and it is not captured in metrics, yet it represents one of the most important signals in project delivery.

In many projects, this signal is understood informally.

Experienced planners recognise it. Project managers sense it. Engineers and construction teams often describe it in practical terms, pointing to sequences that will be difficult to coordinate, activities that depend on too many conditions, or phases where everything seems to happen at once.

These observations are real and grounded in experience.

But they are rarely structured.

As a result, they are difficult to communicate, difficult to compare, and even more difficult to use as a basis for decision-making.

Traditional scheduling methods are designed to answer a specific and essential question.

When will the project finish?

This question remains fundamental, and the methods used to answer it are both well-established and widely understood.

However, there is another question that is just as important, and far less frequently addressed in a structured way.

How difficult will the project be to execute?

In practice, these two questions do not always lead to the same conclusions.

A project may be logically sound, correctly sequenced, and aligned with established planning principles, and still be difficult to deliver.

A schedule may represent time accurately, while failing to reflect the conditions under which work must actually be performed.

This creates a gap between the model and the reality.

It is often within this gap that problems begin to emerge.

Not as immediate failures, but as increasing pressure.

Coordination becomes more demanding. Decisions take longer. Dependencies become harder to manage. Small misalignments begin to accumulate.

The project continues to move forward, but with growing difficulty, and by the time this difficulty becomes visible in terms of delay, the underlying conditions have often been present for some time.

The purpose of this book is to explore that gap.

Not by replacing existing planning approaches, but by extending them in a way that makes execution easier to understand and manage.

The perspective introduced here is based on a simple observation.

Projects are not delivered only through time.

They are delivered through execution.

And execution does not behave uniformly.

Some parts of a project are relatively straightforward to deliver, while others require significantly more coordination, attention, and control.

These differences are well known in practice.

What has been missing is a structured way to describe them and use them consistently.

This book introduces that structure.

It presents a way of thinking about projects that complements existing planning methods by focusing on execution conditions and how they evolve over time.

The intention is not to add complexity, but to make existing complexity more visible.

The approach taken throughout the book reflects this intention.

Concepts are introduced gradually, each building on the previous one, and examples are used to illustrate how the ideas apply in real project environments.

The focus is not on calculation for its own sake, but on understanding what drives behaviour in execution.

The method does not require perfect data, complex tools, or a fundamental change in how projects are planned.

It requires a different way of looking at the same information.

For planners, it provides a way to describe what is often understood intuitively.

For project managers, it offers a clearer view of where attention is required.

For decision-makers, it creates a way to recognise when the project is approaching conditions that will be difficult to manage.

Ultimately, the value of this perspective lies in timing.

The earlier a condition is understood, the more options are available to respond.

By making execution more visible, understanding can be moved earlier in the project lifecycle.

And it is this shift that allows projects to be managed with greater awareness and control.

This book is not about replacing what already works.

It is about making something visible that has always been there.

And once it is visible, it can be managed.

That is where its contribution begins.

Chapter 1: The Moment Every Project Leader Recognises

In most project environments, there comes a point when the plan is considered complete, not only in a technical sense, but also in the way it is communicated to stakeholders who expect clarity, predictability, and control.

The schedule has been developed, reviewed, and validated across disciplines. Activities are defined, logic is consistent, and durations have been discussed with the relevant teams, often challenged and refined until they are considered realistic within the constraints of the project. Engineering confirms scope, construction evaluates sequencing and access, and planning ensures alignment with key milestones and contractual expectations. The network behaves as expected, float is visible, and the critical path is clearly understood.

From a formal perspective, the project is ready.

At this stage, senior stakeholders receive a familiar message, one that is both structured and reassuring. The schedule is in place, the critical path has been identified, and the completion date is defined. The project has a timeline, and that timeline is supported by logic that appears coherent and defensible.

It is a moment that creates confidence.

A project with a plan should, in principle, be a project that can be delivered.

However, those who have carried responsibility for delivery understand that this moment often creates a false sense of security, not because the schedule is incorrect, but because it does not fully represent what execution will demand from the organisation.

There is a difference between a plan that works as a model and a plan that can withstand the realities of execution.

That difference is rarely visible in reports. It does not appear in dashboards, and it is not reflected in the critical path. Yet it is often recognised immediately by those who have experienced projects under pressure and understand how quickly stability can change once execution begins.

It reveals itself in a more subtle way.

During a review meeting, attention shifts to a specific sequence of activities, often without a formal trigger. It may be a commissioning phase, a shutdown window, or a tightly constrained integration scope where multiple disciplines must operate within limited time, limited space, and limited flexibility.

The logic remains correct. The durations remain reasonable. The dependencies are still valid.

Nothing appears wrong.

And yet, someone in the room will say, often without elaboration, that this part of the project will be difficult.

There is no formula behind the statement. No indicator in the schedule produces it. No standard analysis highlights it. It is not supported by a visible metric.

Still, it is not questioned.

Because everyone understands what it means.

It means that coordination will intensify beyond what is explicitly planned. It means that decisions will need to be made quickly, often with incomplete information and under competing priorities. It means that resources will not only be limited, but also contested. It means that the margin for error will shrink, and that even small disruptions may propagate across multiple teams.

Most importantly, it means that this is where leadership attention will be required, not occasionally, but continuously.

This is not a planning observation.

It is a delivery warning.

For a project leader, this is the point where control becomes conditional, because what follows is no longer driven solely by the structure of the schedule, but by the organisation’s ability to manage effort, coordination, and decision-making under pressure.

In many organisations, this understanding remains informal. It is acknowledged through experience, discussed in meetings, and reflected in behaviour, but it is not embedded in the analytical structure of the schedule itself.

Projects are planned in terms of time.

They are delivered through effort.

These are not the same thing.

Traditional scheduling methods, particularly the Critical Path Method (CPM), developed in the 1950s by DuPont and Remington Rand, are one of the fundamental techniques used in project scheduling, answer a fundamental question with precision. They identify the sequence of activities that determines the completion date, quantify float, and describe how delays propagate through the network. This provides a structured understanding of time and supports forecasting, reporting, and contractual alignment.

For planning, this is essential.

For delivery, it is not sufficient.

Another question becomes equally important, particularly for those accountable for outcomes rather than plans.

Where will this project become difficult to execute?

This question is rarely answered explicitly within the schedule. It is recognised informally, often through experience, and expressed through language that reflects caution rather than analysis. It appears in phrases such as “this will be tight,” “this will require close coordination,” or “this is where we need to pay attention.”

These statements influence behaviour.

They influence how teams prepare, how resources are allocated, and where management attention is directed.

But they are not formalised.

As a result, two activities that appear identical within the schedule may behave very differently in execution.

They may share the same duration, occupy a similar position in the network, and have comparable float. From a time-based perspective, they are indistinguishable.

In practice, they are not.

One may follow a stable, repeatable process with limited dependencies and predictable execution conditions, requiring minimal coordination and limited management intervention.

The other may depend on multiple interfaces, tightly synchronised inputs, scarce or specialised resources, and approvals that must be obtained at precisely the right moment.

One can be delivered with routine management.

The other requires continuous attention.

The schedule treats them as equal.

Execution does not.

This difference becomes particularly visible in phases where complexity concentrates, such as commissioning or shutdown execution.

From a scheduling perspective, commissioning activities are often short, clearly defined, and logically structured according to technical requirements. The sequence is well understood, and on paper, the phase may appear controlled and manageable.

In reality, commissioning represents one of the most demanding stages of a project.

Multiple disciplines converge simultaneously. Electrical systems, instrumentation, automation, mechanical completion, and operations must align within a limited timeframe. Vendors may be required on site with restricted availability, systems must be tested in a precise sequence, and work must often be performed under operational or safety constraints that reduce flexibility.

A delay in one activity does not simply affect its successor.

It disrupts people, priorities, and availability across multiple teams. It creates waiting time, forces re-sequencing, and increases the number of decisions that must be made within a short period.

The schedule captures the order of work.

It does not capture the effort required to maintain that order.

A similar pattern can be observed during shutdown execution.

Shutdowns are planned with precision. Activities are compressed into a limited window, and logic is optimised to ensure that all required work fits within the available duration. From a Critical Path perspective, such a plan may be entirely correct.

However, the execution environment is constrained in ways that the schedule does not fully represent.

Time is limited. Access is tightly controlled. Multiple contractors operate in parallel. Work fronts overlap, resources are shared, and safety requirements introduce dependencies that go beyond logical relationships.

Under these conditions, even a small deviation can have disproportionate consequences.

A delay of a few hours may affect multiple downstream tasks, not only because of the logical sequence, but because of the operational constraints that define how work can be performed.

Again, the schedule shows sequence.

It does not show pressure.

This distinction matters at a management level.

Because management attention is not allocated based on theoretical importance, but on practical difficulty.

In many projects, attention is directed toward the critical path, where progress is monitored and mitigation actions are taken to protect key milestones. This is necessary.

But it is not always sufficient.

Areas of high execution difficulty may not sit on the critical path. They may contain float and appear stable in analysis, yet they are where the project is most likely to struggle.

The schedule did not fail.

It simply did not describe reality.

Chapter 2: The Schedule That Should Work… But Doesn’t

In many projects, the schedule performs exactly as intended, providing a structured and logically consistent representation of the work, defining the sequence of activities, and establishing a clear timeline for delivery. Activities are connected, durations are justified, and the critical path identifies what controls the completion date, creating a model that appears both reliable and complete.

From a planning perspective, the structure works.

For a period of time, it appears to work in execution as well. Activities start as expected, progress is reported, and milestones remain within reach, giving the impression that the project is stable and under control.

From a management perspective, this is a reassuring phase, because the plan appears to be functioning as intended.

However, this stability is rarely permanent.

Not because the logic is incorrect, and not because the schedule was poorly constructed, but because the conditions required to execute the plan begin to diverge from what was implicitly assumed during planning.

This divergence is rarely sudden.

It develops gradually, often without a clear point of origin.

At first, the signals are subtle. A dependency takes slightly longer than expected, a resource is not available at the planned moment, or a decision requires additional discussion before it can be confirmed. Each of these situations appears manageable and does not immediately threaten the project.

The system absorbs them.

Teams adjust. Additional coordination takes place. Minor inefficiencies are accepted. The project continues to move forward, and the schedule still appears valid.

But the effort required to maintain that alignment begins to increase.

This is the point where the nature of the project starts to change, even if that change is not yet visible in formal metrics.

A useful way to understand this transition is to examine the difference between how work is represented in the schedule and how it is actually executed in practice.

In the schedule, activities are discrete, clearly defined, and logically connected units, each with a start, a finish, and a duration. The structure is clean and predictable.

In reality, work is dynamic.

Activities overlap, compete for the same resources, and depend on information that is not always available when needed. Decisions rely on individuals who are involved in multiple parallel issues, and priorities shift as new constraints emerge.

This is not an exception.

It is the normal condition of complex projects.

Consider a situation where several activities are planned within the same time window. From a scheduling perspective, this is acceptable, as the logic supports it and resource allocation appears feasible.

In execution, however, those activities may compete for the same specialists, depend on the same approvals, or require access to the same physical area.

Individually, each activity remains achievable.

Collectively, they begin to create friction.

That friction is not visible in the schedule, but it becomes visible in behaviour, in the way work progresses, and in the increasing effort required to maintain alignment.

Over time, this begins to affect performance.

Teams start to wait, sequencing changes in the field, and decisions take longer because more elements must be aligned before action can be taken.

Each issue remains manageable on its own.

Together, they begin to redefine the project.

The project becomes harder to manage.

From a leadership perspective, this is where risk truly begins to materialise, even if the schedule still appears stable.

The system is under pressure.

The difference between a stable project and a fragile one is not reflected in dates, but in the effort required to sustain progress.

As pressure builds, small issues begin to have wider consequences. A delayed input affects multiple teams, a resource conflict forces reprioritisation, and a late decision creates a chain of adjustments that propagates through the project.

The project does not fail suddenly.

It loses stability over time.

This loss of stability has direct business consequences.

Costs increase as coordination effort expands. Productivity decreases as teams wait, rework, or adjust execution. Management attention shifts toward reactive problem-solving, and margin begins to erode long before delays are formally recognised.

By the time the issue becomes visible in reports, the project is already reacting rather than managing.

Recovery is possible, but it is significantly more expensive than prevention.

This pattern is common in complex projects, yet it is often misunderstood.

From a reporting perspective, it appears as a loss of performance.

From an execution perspective, something else has happened.

The project has entered a phase where the effort required to coordinate and deliver the work exceeds what was anticipated during planning.

This is not a failure of the schedule. It is a mismatch between the model and the conditions of execution.

When this occurs, the natural response is to return to the schedule, review logic, challenge durations, and attempt to regain control through adjustments.

These actions are necessary.

But they focus on time.

They do not address effort.

As a result, the same pattern continues.

More coordination is required, more pressure builds, and the system becomes increasingly reactive.

Management attention increases, but it is directed toward symptoms rather than underlying causes, because the schedule does not reveal where the real difficulty lies.

It shows where delay matters.

It does not show where delivery becomes complex.

Projects are rarely lost because the sequence of activities is incorrect.

They are lost because the effort required to execute that sequence exceeds the organisation’s capacity to manage it effectively.

The problem is not poor planning. The problem is planning without visibility of execution difficulty.

This is the point where a purely time-based view reaches its limit.

Time explains when things should happen.

It does not explain how difficult it will be to make them happen.

For those responsible for delivery, this difference directly influences decisions, resource allocation, risk exposure, and ultimately the financial outcome of the project.

A plan that ignores execution difficulty may still be logically correct.

But it will not be operationally reliable.

This is why some projects appear well planned and still struggle.

It is not because the schedule was wrong.

It is because it was incomplete.

Which leads to a fundamental question.

Can execution difficulty be made visible before it becomes a problem?

Chapter 3: The Missing Dimension

By this point, a pattern begins to emerge, not as a single observation, but as a recurring experience across different projects, teams, and industries.

Plans are developed with precision. Schedules are constructed using established methods, logic is carefully validated, and timelines are defined in a way that gives confidence not only to planners, but also to stakeholders responsible for delivery. The structure is clear, the dependencies are understood, and the critical path provides a coherent explanation of how the project is expected to unfold.

And yet, as execution progresses, that clarity begins to fade.

The schedule continues to describe the project.

But it no longer fully explains it.

This distinction is easy to overlook, because the model itself does not change. The logic remains intact, the dates remain visible, and the structure continues to behave as designed.

What changes is the relationship between the model and reality.

The schedule explains how the project should progress.

It does not fully explain how the project will behave under real conditions.

This difference becomes most visible when the project is under pressure.

In such moments, the limitations of a purely time-based perspective begin to surface, not because time is irrelevant, but because it is incomplete.

When projects begin to struggle, the instinctive response is to return to the schedule and attempt to regain control through analysis.

Logic is reviewed in detail. Durations are challenged and adjusted. The critical path is recalculated. Alternative sequences are explored, and mitigation plans are introduced in an effort to restore alignment between the plan and execution.

This response is rational and necessary.

However, it is also constrained by a fundamental assumption.

It assumes that the problem exists within the same dimension that the schedule describes.

Time.

Time is structured, measurable, and well understood. It allows planners and managers to analyse dependencies, evaluate delays, and forecast outcomes. It provides a common language for communication and a framework for decision-making.

But it does not capture everything that influences delivery.

It does not describe how much coordination is required between activities, how sensitive a sequence is to disruption, or how difficult it will be to maintain alignment between teams operating under different constraints and priorities.

It does not describe effort.

And yet, effort is what defines execution.

Effort determines how much attention is required from management, how much coordination is needed between teams, and how quickly decisions must be made in order to maintain progress. It influences how resilient the project is to disruption and how quickly small issues can escalate into larger problems.

It is effort that transforms a theoretically correct plan into a practically challenging one.

This creates a fundamental imbalance in how projects are understood.

Projects are analysed in terms of time.

They are delivered through effort.

In practice, experienced professionals attempt to bridge this gap through judgement. They recognise patterns, anticipate where complexity will emerge, and adjust their behaviour accordingly. They know where to focus attention, even when the schedule does not explicitly indicate a problem.

They recognise that not all parts of the project carry the same execution burden, even when they appear similar in the plan.

However, this approach has inherent limitations.

It depends on experience, which varies between individuals. It is difficult to formalise and even more difficult to scale across teams and organisations. It cannot be consistently embedded into processes, and it does not provide a structured basis for decision-making at a management level.

As projects become larger, more complex, and more interconnected, relying on intuition alone becomes increasingly insufficient.

For project leaders, this creates a structural challenge.

Decisions are made based on what is visible.

If execution difficulty is not visible, it cannot be managed proactively.

It can only be managed reactively, once its effects begin to appear in performance, cost, or schedule.

This is why many projects appear to be under control until they are not.

The indicators used to assess the project reflect time, progress, and cost, but they do not fully capture the conditions under which the work is being delivered.

As a result, early warning signals are often missed, not because they do not exist, but because they are not formally represented.

The project continues to move forward, while the underlying complexity increases.

By the time the impact becomes measurable, the project is already responding to consequences rather than managing causes.

This is not a failure of scheduling.

It is a limitation of perspective.

The question, therefore, is not whether schedules are useful.

They are.

The question is whether they are complete.

If time represents one dimension of the project, then what represents the other?

What is the dimension that explains why certain parts of the project require disproportionate attention, why coordination becomes increasingly difficult, and why pressure builds even when the schedule appears stable?

This dimension has always been present.

It is recognised in conversations, reflected in behaviour, and understood through experience.

But it has rarely been formalised.

It has not been systematically integrated into the structure of the schedule, nor has it been consistently used as a basis for planning or decision-making.

As a result, it remains implicit.

And what remains implicit cannot be managed effectively at scale.

If this dimension could be made visible, it would fundamentally change how projects are understood.

It would allow teams to identify where effort will concentrate before execution begins. It would enable management to allocate attention more effectively, anticipate coordination challenges, and reduce the likelihood of reactive decision-making under pressure.

It would shift the focus from responding to problems toward preparing for them.

This does not replace time-based analysis.

It complements it.

Time explains when work should happen.

Effort explains how difficult it will be to make it happen.

Together, they provide a more complete picture of the project.

This leads to a fundamental shift in perspective.

From asking only when the project will be delivered, to also understanding where it will be most difficult to deliver.

For those responsible for outcomes, this distinction is critical.

Because projects do not fail simply because they are late.

They fail because they become too difficult to manage within the constraints of time, resources, and organisational capacity.

Understanding when something will happen is important.

Understanding how difficult it will be to make it happen is what enables control.

This raises a fundamental question.

Can execution difficulty be made visible before it becomes a problem?

The answer to that question defines the next step.

It is the point at which planning moves beyond describing time and begins to describe execution.

This is where a new perspective becomes necessary.

And this is where the Critical Effort Method™ (CEM) begins.

Chapter 4: Introducing a Different Way to See the Project

By this point, a pattern becomes difficult to ignore, not because it is new, but because it appears consistently across different projects, teams, and environments.

Schedules are developed with care and discipline. They describe sequence, define dependencies, and provide a structured timeline that allows teams to align around a common plan. They are reviewed, challenged, and refined until they are considered reliable enough to support execution and decision-making.

This structure is not the problem.

It is necessary.

What becomes visible during execution, however, is that this structure does not fully capture what it takes to deliver the project under real conditions.

Certain parts of the project repeatedly demand more attention, more coordination, and more effort than others, even when they appear comparable in the schedule. These are not isolated anomalies, nor are they random occurrences. They follow patterns that experienced professionals recognise, often immediately, even if those patterns are not explicitly represented in the planning model.

This creates a gap that is not immediately obvious, but becomes increasingly significant as the project progresses.

A gap between what is visible in the schedule and what is experienced in execution.

A gap between what is planned and what must be managed.

For those responsible for delivery, this gap has practical consequences.