Waterfall projects are undertakings that must, by some law or regulation, be delivered in full by a particular date. Legal, Regulatory and Mandatory (or ‘LRM’) projects are like that. They differ from agile or product-based projects in that delivery date and content are known at the project outset, and typically set by an external body. Failure to produce mandated content or missing due dates in these projects can make customers cross, incur financial penalties, damage company reputation, or compromise market position.

A recent review of this type of project shows that on average 50% of all waterfall projects in fact fail to deliver as promised. Research in large companies has found this to be a very generous number. We know of one £20 million piece of work, for a digital product, that was delayed 4 times. The project has ended up shelved for good – an expensive loss.

Why does this happen?

It’s usually because planning takes too long.

Or it’s because planning was half-baked – project deliverables are completely missed, or they’re completed in the wrong order. Often as well, there is no system for making decisions quickly. And finally, when it does look like the project will overrun – usually discovered when it’s too late – companies tend to revert to even more planning, even tighter due dates, and cumbersome new governance requirements.

It reduces to basically flawed methodology. All along the way, a continuous review progress, for example, can lead to projects incorrectly reported as on time; problems that are identified are rarely logged, or rarely escalated. Projects are also very often resourced incorrectly for number of people and correct levels of expertise.

We disapprove of problematic techniques like these, and other ones, like due date setting, RAG statuses, and hyper-focus on productivity. In this two-part series, we lay out our methodology for you to try out instead, which recently delivered an LRM project 8 months early, on your waterfall or LRM project. Our job in the following article, and subsequent articles, is to set out the assumptions and methods you’ll need for on-time, in-full, and on-budget delivery. One-by-one, we’ll take you through the steps, and the sub-steps, so you can get your project done.

The Steps

Step 1 – Designing the work

a) Defining ‘done’, ‘content’, and ‘dependencies’

b) Collaborative planning

c) Obstacle-based planning

d) Sufficiency logic

e) Deliverables and necessity planning

f) Resource bottlenecks and capacity planning

Step 2 – Estimating for the work

Step 3 – Managing project delivery, governance, and reporting

Step 4 – Day-to day-running and project ceremonies

Step 5 – Task management

Step 6 – Project measurement and reporting 

Step 1 – Designing the Work

Correct planning mitigates five potential problems in project delivery. The first is missing content. The second are points of contention regarding the order of deliverables. The third are points of contention regarding resourcing. The fourth is timeline-overruns. And the fifth is general lack of clarity on the process and objectives. The core assumption is that if we get the right people, with the right levels of skills and knowledge together at the outset of the project we are less likely to have missing content, and more likely to identify dependencies and points of contention, and have a timeline that is reasonable.

Typically, this is not the way projects are planned in large organisations. Normally, project planning is the domain of the business analyst (BA). But it’s done by the BA interviewing team, who build a project Gantt chart.  It works out that members are generally focused on their individual piece of the pie, so to speak, instead of the whole.  It’s not real collaboration.

Let’s talk about planning collaboratively.

a) Defining ‘Done’, ‘Content’, and ‘Dependencies’

The role of a Project Manager is to define the end result of a project. The challenge is to do it in such a way that there is a shared understanding of the project. A good, communicative manager might speak in the present tense, and describe their vision of the completed project.

E.g. ‘When we complete this project we’ll see a web page with a single sign-on, and nothing else on the page, and when the customer enters their details, they’ll go straight to their accounts.’

Having done this much, the Project Manager should define the first cut cross functional roles that they believe are necessary for delivery, and then pull those people together into an initial group meeting. Note that all roles, irrespective of seniority, should be at the meeting. This will reduce the likelihood of missing content or dependencies.

The role of the Project Manager, combining with that of the senior leader, is to discuss and refine these definitions of ‘done’ with the whole project group; the group then summarises back their definition of ‘done’ such that all in the project have a shared understanding of the end result.

b) Collaborative Planning

A clear and collective definition of ‘done’ allows for easier planning.  Given the nature of some projects, it is likely there will arise some anxiety over failure to deliver.  But, often, members of project teams do not always voice concerns in the planning stage. It is important that everyone be encouraged to speak up now about delivery.

c) Obstacle-Based Planning

To drive out fear of raising delivery concerns, and to help ensure that all content requirements are captured, it is recommended at this stage that the Project Manager use what we call ‘obstacle-based’ planning. This starts with the goal in mind, and works backwards, to capture all the deliverables required to meet the goal. It’s really asking a simple question:

‘If we were to attempt to deliver this project tomorrow, what obstacles would there be?’

Note that obstacles are different from negative reservations. A negative reservation might be, ‘Oh, what’s the point? Even if we do deliver this, the regulator won’t like it.’ Recast as an obstacle, something to be surmounted, this may become, ‘Well, we don’t know the required format for the regulator, so we’ll need to find that out.’

One of these is a gut-reaction. The other forms part of the basis for a plan.

If teams are encouraged to think of their anticipated problems like this, planning becomes much easier.

d) Sufficiency Logic

Each obstacle, once captured, forms the basis of the deliverables, in other words.

So how do we know when we’ve captured all the obstacles?

We have a method for that, called ‘sufficiency logic.’ As Project Managers keep capturing obstacles, they give the group time to reflect on the project needs, and they ask another question:

‘If we have removed obstacles x, and y and z, is there any reason to think we could not then deliver all the content? 

This step is repeated as often as required.

e) Deliverables and Necessity Planning

Not every obstacle is turned into a deliverable. Each one is checked for the same language as the overall deliverable: it is spoken of in the present tense, and it is described as part of what the team will see physically at the end.

The next element of the planning cycle, again, done with the whole team, is to get the sequence of deliverables right, and then check for resource contention. This is called ‘necessity logic.’ Simply put, we check whether it’s necessary to do one thing before another, or whether they can be done in parallel. The Project Manager will pick up two deliverables and simply ask, ‘Does one of these need to come first?’ Doing this with each deliverable makes it possible to build a network diagram which shows the sequence, and dependencies, for all the deliverables before the project starts. Note that at this stage we have not specified the actions required for each deliverable. As we move through the project, deliverables may change. Over-planning at this stage is likely to result in delays and rework later in the project. We’ll talk about the more granular actions later in the cycle.

Finally, we now check for resource contention. This is to make sure that we are planning our capacity correctly and not overloading a resource or causing multi-tasking by trying to share resources across the same deliverable. Here is where the Project Manager watches for early warnings about resource bottlenecks or other staffing problems.

f) Resource Bottlenecks and Capacity Planning

Theoretically, keeping everyone busy all the time maximizes the rate of project delivery. But in all systems flow is determined by the slowest moving piece of the system. This is true of traffic on a motorway, molecules in a test tube, or workflow in a project environment. Thus, a critical feature of the network diagram is its ability to show up pace-setting capacity restraints.

For example, in a recent project of ours, the leaders were concerned that if a developer stopped working to remove a project blocker, then the timeline would slip. But the project had four developers and one tester. All work was lined up in the front of the tester, not the developers. That meant that developer productivity didn’t matter much. What mattered was how the tester worked. The leaders were surprised to learn this, and pleased to be able to make better decisions from then on about where to add resource to improve flow.

Principle & Practice Summary

Better work design is really a matter of better work culture, that encourages visibility of purpose and direction, illuminating priorities and where alignment is needed.

Goldratt UK works with clients in both project and production environments to increase output, shorten lead-times and improve delivery performance. If you would like to view a case study of these ideas implemented within a project management environment, request one at [email protected].

© 2021, Goldratt UK