On project failure.

Nasty stuff

Resignations, budget blowouts, endless hours, delayed releases. And worst of all, seeing the nastier sides of everyone. Blame, gossip, overreaction… or what I simply call ‘noise’.

Often this does not add any value and is entirely self inflicted. 10 meetings about the size of a button. 32 emails about why a story didn’t make a sprint.

Given enough time, every project I’ve ever been on at times slips into noise. Some moments are noisier than others, as are some people. It’s not productive and the cost is real, both financially, physically and mentally.

On one hand, it’s no surprise. There’s lots of money and reputations at stake, and you’re mixing in a client and about 3 other companies in delivering a very public outcome. Each stakeholder has a different way they work, measure and communicate. You blend all of this together and it gets tough.

Waterfall projects succeed. Agile projects fail. Waterfall projects fail. Agile project succeeds. Product A is terrible, Product B would’ve been better. Project B is terrible, Product A would’ve been better. Just like a diet, the best one is the one you stick to. Blame gets thrown around to different methodologies, people and technology. But it’s never the case, it’s the way it’s done.

Why projects get noisy

In no particular order, here are what causes project noise. None of this is productive to a project, yet can occupy most of it.

Culture

This one is hard to summarise as it’s without describable shape or form, but very real. Does your project culture promote quality? Does it accept mistakes? Does it realise we are a collection of human beings and that it will never be a perfect machine.

Lack of focus

• This is the #1 culprit. What you’re doing a month from now should be unclear, what you’re doing next week should be somewhat clear, you’re doing this week should be clear, what you’re doing today should be set in concrete.
• If you’re in a project that says we are doing 5 things this week in order 1–5, but by the end of the week you didn’t do 1–5 but instead we’re redirected to number 7, 18, 6 and 22, and this is what happens every week. You are in a bad cycle and someone needs to break it.

Behaviour and methodology not the same

• Talking agile, reporting agile, using agile tools, but behaving waterfall. (And vice versa)

Continuous improvement and quality

• How your project quality is right now is irrelevant. How it is today compared to last week is very relevant. Quality is on every level of a project. How attentive are people at meetings? How well written are user stories? Are important workshops well run? Do leaders have clear direction and communicate it well? All of this is quality and arguably even more important than code quality. I haven’t seen projects hurt by poor code nearly as much as poor decision making.

Misusing a project plan

• A project plan is not a perfect forecast of the future. That is completely impossible. The plan is a best guess at a point in time and to be used to map dependencies and reforecast a new guess when changes happen.
• A project plan should be recut every week. If you have set your project plan in concrete, you have doomed your people. Unexpected things will happen, and also priorities will change.
• If you are behind on your plan and you have decided to ‘catch up’ instead of redo the plan, you’ve made a mistake.

Overreacting

• Surprises will happen. In fact, they shouldn’t even be called that as they are expected. Every time this happens, and it will happen daily, walk through collaboratively and pragmatically, make a decision and move on.

Individual accountability

• How predictable is behavior on the project? Do people do what they say they will? Are team members punctual? Do people own their work and follow through. This is a culture that can go either way.

Too many meetings

• Every member of your team needs at least 3 hours of interrupted time per day to only work on delivery. No meetings, no emails, no noise. 3 hours sounds little, but despite all we know about productivity, the calendar still gets filled up.
• The culture should support declining meetings when you don’t see value.

Not correcting skills mix

• You will likely never get the perfect team, but you may very well have people that are simply not the right fit, because of their technical, communication or productivity ability. Fix this. If coaching does not work, swap them out. Most projects never fix this or leave it too late.

Some ideas

For each one of the items I’ve listed you could come up with hundreds of solutions, but here I’ll suggest a universal few that work for me.

1. Know the why. This will make decisions pragmatic
2. Be sustainable. A pace that allows people to spend rich time with their families, get sleep and avoid burnout is the signs of a successful project. If that’s not the norm, then something is wrong
3. Prioritise ruthlessly, focus entirely
4. Culture of individual ownership to collective outcome. Plan with the whole team
5. Plan, and redo the plan, often. Know the critical path and the impacts of changes
6. Protect ‘doing’ time (eliminate meetings and distractions)
7. Take it seriously, but keep it chilled, have fun
8. Don’t say ‘yes’ to everything. See point #1
9. Get your skills mix right. You need the right people
10. Avoid ‘catching up’. Things happen, change your project plan, see how you can estimate better next time or else you’ll always be catching up

Projects are hard, but we do this to ourselves

As a leader you should be working to make your project successful, sustainable, using the best skills of your team, developing them and drive continuous to your clients.