Lesson 8: The bigger picture

A short history of project management

Project management has a long history of tools: the Gantt chart (1917), the critical path method and PERT (late 1950s), the founding of the Project Management Institute (1969). Theory of Constraints appeared in the mid-1980s, and Critical Chain in the late 1990s, alongside Scrum and PRINCE, the PMBOK guide’s first edition (1996) and the Agile Manifesto (2001).

The PMBOK framework organises project management into process groups, what you need to do (initiating, planning, executing, monitoring and controlling, closing), and knowledge areas, what you need to know (integration, scope, schedule, cost, quality, resources, communications, risk, procurement and stakeholders).

More processes, same results

Large surveys of project professionals tell a consistent story: a large share of projects miss their original goals, budgets or schedules, and scope creep is common. Over the same years, the body of knowledge kept growing, especially in planning and in monitoring and control. New processes were added to the guide, but project performance did not improve much.

Pause and think: if the body of knowledge keeps adding planning and monitoring processes, what assumptions must sit behind that?

That projects fail because of bad luck
That projects fail mainly through inadequate planning, and execution problems come from inadequate monitoring and control
That people work too hard
That there are too few projects

Those two assumptions lead to one direction of solution: do more, better. Plan in more detail, account for every past reason for failure, measure and control more. If they were right, decades of added process would have shown better results.

The core conflict of project management

Every project organisation, and every PMO, wants to manage the business well. That means two things:

Arrest delays on existing projects, which demands focus on executing running projects.
Protect the commitments of future projects, which demands focus on planning future projects in detail.

Project managers and shared resources have limited bandwidth, so they switch between the two. Planning time is taken from execution; execution fires take time from planning. The result is a vicious loop: compromises in planning and execution (inputs assumed, change requests left for later), rework and scope creep, delays, pressure to start more projects, shifting priorities, projects dropped, and low annual output from the whole system.

The usual way out is an “acceptable compromise”: a little more planning, a little more control. TOC asks whether the assumptions behind the conflict hold. Must commitments be protected by defining everything accurately in planning? Is that even possible in an uncertain environment?

How the TOC solution grew

Solution 1.0: Critical Chain. Is the real problem uncertainty, or the way projects are managed? Touch time is about 30% of lead time; the rest is internal wastage plus external delays. Buffers already exist in projects, but they are wasted inside each task, and resources are limited and shared. Critical Chain removed task-level buffers, put the safety at the project level, and moved from the critical path to the critical chain, which accounts for resource contention.

Solution 2.0: flow. Even so, projects could still be late, because bad multitasking is the major cause of wastage wherever resources are shared. So the method added WIP control to reduce bad multitasking, full kit, planning, execution, ways to absorb the client’s disruptions, and continuous improvement.

Solution 3.0: management. Two questions remained. Can WIP rules co-exist with task priorities coming from schedules? No: time-based planning conflicts directly with WIP. And do WIP and full kit address every controllable wastage? No: the escalation and collaboration conflicts remain. So the solution added high-frequency management and project visibility through ETA, which you studied in this course.

Resolving the conflict

Time, budget and scope are linked, and most compromises of budget and scope happen under pressure of time. So the TOC answer starts with time:

Plug the internal wastages, interruptions, slow-downs and rework, through WIP control, full kit and high-frequency management.
That frees enough time to deal with external uncertainty, risk and Murphy, protected by buffers instead of padding.
When time is managed well, scope, cost and quality fall into place.

The conflict between executing today’s projects and planning tomorrow’s dissolves, because execution stops consuming the bandwidth it used to, and planning no longer has to pretend it can foresee everything.

Check your understanding

Answer all five. Get four right to complete the lesson.

1. Over recent years, the project management body of knowledge has mostly grown in…

Team building
Procurement only
Planning, and monitoring and control
Sales

Reflecting the assumption that failures come from inadequate planning and control.

2. The core conflict of project management is between…

Executing running projects and planning future ones
Sales and finance
Quality and cost
Clients and suppliers

Limited bandwidth makes PMs switch between the two.

3. Critical Chain (solution 1.0) moved safety…

Into every task
To the customer
Out of the project entirely
From individual tasks to the project level

And from the critical path to the critical chain.

4. Why was high-frequency management added (solution 3.0)?

To create more reports
Because time-based planning conflicts with WIP, and the escalation and collaboration conflicts remained
To replace full kit
To increase task deadlines

Daily management and ETA visibility address what WIP and full kit don’t.

5. The TOC answer to the time-cost-scope dilemma starts with…

Cutting scope
Increasing budget
Plugging internal wastages of time, which frees time to absorb external uncertainty
More detailed planning

Manage time well, and the rest falls into place.