Heuristics for better project delivery leadership

Heuristics are rules of thumb, a pithy summary that simplifies a larger, complex idea. Most importantly, a heuristic is something that can be put to practical use.

There's lots of complex ideas and difficult things to understand when delivering projects and services, and plenty of places that things can go wrong. This is exactly where fast rules of thumb can help:

Heuristics can help improve project leadership.

Below is a set of heuristics taken from 20+ years of experience, reading and researching in service delivery.

Delivery leadership heuristics #

Discover stuff first #

Find things out first of all, before you even start thinking about a plan let alone getting to work.

Save time and pain later on by discovering as much as you can up front.

Find out why #

Ask the customer why they are doing this thing. Understand the problem that needs to be solved.

Ask what #

Ask service users what they want to achieve, and what makes it hard to do that.

Focus on user needs #

If people don't use (or don't know how to) then thing you're building, it'll be useless.

Prioritise user needs over everyone else’s, including those of your senior stakeholders.

Fail fast and learn quickly #

Do experiments, especially early on, and don't be afraid to fail. That way you can spot problems early and resolve them quickly.

Be happy with doing things that fail, and create a culture that learns from failure.

Deep Dive: Fail fast, learn quickly

Try out the risky, difficult and important stuff first #

Before you commit to a project, especially a large one, identify:

• the biggest risks to success
• the hardest things that you'll have to do
• the most important elements to achieve or deliver

Create experiments and spikes of activity on these so you know in depth how you're going to deal with them. As above: fail fast, learn quickly.

Stop to reflect and decide what next #

Bake in moments when you stop what you're doing and see how you've done.

Use those as decision points — times to understand what you've achieved, what you've learnt, and how you should proceed.

Be agile, keep planning #

• Reflect on what you've done.
• Check if and how things have changed.
• Decide what are the next priorities.
• Adapt the plan.

Slice things into phases #

Projects should be approached in phases:

• Discovery — understand the problem that needs to be solved, learn as much as you can
• Alpha — experiment to try out the risky, difficult and important stuff, fail fast and learn quickly
• Beta — build the thing, do it iteratively, do it fast
• Live — open the doors for people to use the thing, learn from what they actually do and make improvements
• Retirement — when conditions change, you may need to retire your service

Share what you've learnt at the end of each phase. THEN decide whether it's right to progress onto the next.

Deliver iteratively, in milestones if possible #

Deliver in increments the things that meet the needs that are most important to your users.

If possible, don't wait until the very end before people use the thing you're making. Set milestones for delivering service or product features.

Share what you learn #

You and your team will learn things at every step of your projects. Share that knowledge whenever you can.

Keep demonstrating #

When you reach a point where you have built something that meets the need that’s most important to your users, demonstrate it. Listen to their feedback, then make improvements.

Documentation is important #

While the working thing is the primary aim, do no neglect documentation. When the next person comes to use what you've built, they'll need to know how to use it or how to follow the process.

Flyvbjerg's ten heuristics for getting things done #

This set of project leadership rules is taken from Bent Flyvbjerg's book, How Big Things Get Done.

1. Hire a master builder #

Someone with deep experience and a proven record in what you're doing.

2. Get your team right #

A team that will get the job done. By preference, hire the team of the master builder.

3. Ask why #

Focus on what matters and the ultimate purpose of the project.

4. Build with Lego #

Modularise things, do stuff iteratively, learn, and scale up.

5. Think slow, act fast #

It's much cheaper and quicker to find problems and fail at the planning stage. So, reduce uncertainty with low-cost planning.

Then, deliver rapidly on the thoroughgoing plans you have made.

6. Take the outside view #

Plan using Reference Class Forecasting.

Always try to think that 'this' is 'one of those'.

7. Watch your downside #

Spot risks and eliminate the things that can kill the project.

If the downsides get too big, see Rule 8.

8. Say no, and walk away #

Focus only on what’s required to succeed.

9. Make friends, keep them friendly #

Build bridges with stakeholders, suppliers, previous colleagues and collaborators.

Maintain those relationships — some day, no doubt, they'll be vital.

10. Know your biggest risk is you #

Avoid the ‘inside view’ — that the thing you're doing is completely unique.

And remember, we are highly susceptible to behavioural biases.