How to manage a project in two simple questions

How to manage a project in two simple questions

I’ve read a few articles recently, that criticise - or at least question - agile delivery approaches. It's not like they're suggesting agile is a terrible idea. More that agile has become trapped in its own processes and smothered by orthodoxy. The very things that the Agile Manifesto set out to avoid.

In The Failure of Agility, Andy Hunt talks about 'the joy of rules’. How, when you first start learning something, rules are brilliant. They help you master the basics. But agile is all about questioning and evolving rules within your team. If you aren't careful, the scaffolding that got you started strangles your growth.

Rules are like a comfort blanket. They reassure you that you’re doing it right. If you stick to the rules and your project still goes wrong, it can’t be your fault. Can it?

Comfort blankets are easy to sell

If you’ve got a certification to prove that you’re doing it right, even better. It proves to potential employers - and to yourself - that you're a safe pair of hands. Which is why certificates, and the courses that lead to them, are so easy to sell.

In A Criticism of Scrum, Aaron Grey transcribes a video where Robert C. Martin, one of the original authors of the Agile Manifesto, describes how agile got certificates:

Ken came to me… telling me he was going to make a class called Certified Scrum Master Class. I thought it was a dumb idea. But a dumb idea that works is not a dumb idea. People came and liked it. The more he charged, the more people came. He started giving out certificates, and he made a little organization off to the side – the Scrum Alliance... __This had the effect of legitimizing Agile. Without that Certified Scrum Master course, Agile would be nothing. That caused Agile to cross the chasm and go mainstream.

And to make something certifiable, you need to give it some rules. Processes. Things you can teach people in a week.

Scrum joins the methods police

I've been told Scrum isn't a method. But it sure as hell feels like one.

I arrived in my first Scrum team full of excitement. I’d read the Agile Manifesto. I’d seen the Instagram feed from our colleagues in the New York studio, with their sticky notes and their sketching and their freewheeling creativity. I thought I knew what to expect.

It wasn’t how I expected. There was a huge amount of focus on rituals over results. Tremendous anxiety about whether we were doing it right, and almost no anxiety about the fact that we were delivering total crap to our stakeholders at the end of each sprint. And no questioning of whether Scrum was the right way for this team to deliver this particular product.

We’d been told to do Scrum, so we did Scrum. End of discussion.

You can’t fix a broken project with a method

I’ve had similar experiences with project management. The consultancy I worked for was helping an organisation adopt PRINCE2. At the time, this was the preferred project management method in the UK public sector, and the organisation had decided it was the answer to all their problems.

Their problems weren’t particularly unusual. Projects that were consistently late, over budget, and short of the initial specification.

As usual, we investigated the situation at the start of our engagement with this client. As usual, we discovered that the budgets were too small, the deadlines were too short, and the specifications were too big and complicated for any human to estimate with any confidence.

The client had already decided that the answer was to train everyone in PRINCE2. Projects were still late, over budget, and short on features. So they hired us to help them do PRINCE2 'properly'.

But that wasn't the issue. Their people were word-perfect in PRINCE2. It was just that all the filling in of templates and maintaining of logs was having zero impact on the real problems on each project. They were too busy being PRINCE2 project managers to actually manage their projects.

Managing projects isn’t about templates, it’s about questions.

Too much 'project management' can obscure all the stuff you actually need to deal with. Which basically comes down to this:

  • Has anything gone wrong yet?
  • Is anything about to go wrong?

The point of these questions isn’t to pile up information or fill in status reports. If something has gone wrong, what can we do about it? How can we make up the time, fix the deliverable, or get the result in a different way? If something is about to go wrong, what can we do to avoid it, or minimise the impact?

This is project management: constantly watching for opportunities to fix little problems before they become big ones. Tackling small risks before they turn into big issues.

It’s not that I don’t use any templates or documents to help me answer these questions. But I keep the volume and complexity of the documentation at the lowest possible level for each project.

Minimum viable project management?

If you’re asking ‘have we gone wrong?’ you need some definition of ‘right’. So I always have some kind of plan that represents my current best forecast of what remains to be done, when it will happen and who will do it. It might be a to-do list, or a Gantt chart, or a kanban board, or some combination. But there will be a plan.

Though ‘right’ is a moving target. If we realise we aren’t going to hit our planned launch date, that might mean we’ve screwed up. Or it might mean our estimated launch date was wrong in the first place. Either way, the knowledge that our forecast is deviating from our original plan is useful information that we can act on.

There may also be a contract, stating what ‘right’ looks like as far as the client is concerned. What the product needs to do, when they expect to get it and what the budget is. This is also a useful reference when thinking about ‘have we gone wrong yet?'

For ‘is anything about to go wrong?’, you also need a different kind of list.

If you’ve done any kind of project management training, you’ll have encountered a risk log. A massive spreadsheet that you fill out at the start of the project with a list of all the things that might go wrong. Then you stash it in a drawer and get on with your status reporting...

I don’t. I look at it every week and think about whether each risk is more or less likely to explode than it was last week. I decide what actions to take to get each risk back under control, and then I add the actions to the plan and make sure they happen.

That’s pretty much it. A plan that lists what I expect to happen, and a risk log that lists what I’d prefer not to happen. Updated weekly. And maybe a really simple status report if your client insists on it.

Sounds almost like a method, doesn’t it? Maybe I should start selling certificates.

I have not received any compensation for writing this post. I have no material connection to the brands, products, or services that I have mentioned.

How to design an effective training session

How to design an effective training session

How the good/fast/cheap tradeoff really works

How the good/fast/cheap tradeoff really works

0