There is a lot of project management you can learn from a book. And you should learn it.
Plans, risks, dependencies, RACIs, governance, status reporting, whatever flavour of delivery process your company happens to use. None of that is pointless.
If you’re starting out, learn the mechanics. Get good at them.
But after a while you realise that knowing the mechanics isn’t actually the difficult bit. The difficult bit is knowing what to do when the situation in front of you doesn’t quite fit them.
When do you push and when do you leave the team alone? When is a stakeholder saying “fine” actually fine? When does a risk need escalating and when are you just creating noise? When do you follow the process, and when has the process itself become part of the problem?
That’s what I think of as the art of project management.
Unfortunately, I don’t think you can learn most of it from a book.
You can learn from other people. A good manager or an experienced PM can save you a few scars by pointing things out before you walk into them. But mostly you learn by doing the job and getting some of it wrong.
I’ve made calls that worked really well. I’ve made others that definitely didn’t. The annoying thing is that sometimes you can make what looks like exactly the same call in two different situations and get two completely different outcomes.
The context was different.
That’s something I underestimated earlier in my career. The more context I have, the better my judgement tends to be.
And I don’t just mean the project plan.
What is actually important to the business? Who really cares about this? Who doesn’t? What else is happening in the organisation? Is the team struggling? Is there history between two stakeholders that nobody wrote down anywhere? Is the deadline genuinely immovable, or is it one of those deadlines that becomes surprisingly movable when somebody sufficiently senior asks why?
That stuff matters.
I’ve worked in situations where I had a really good view of what was going on around the project, and others where I had much less. The difference was huge.
Without the context, you can still run the process. You can update the plan, maintain the risks and organise the meetings.
But you’re making more decisions in the dark.
It’s also why copying another PM’s style only gets you so far. I’ve worked with very good PMs who operate completely differently from me. Some are more structured. Some are more forceful. Some talk constantly. Some hardly seem to say anything until they need to, and then everybody listens.
There isn’t one correct version.
What I find more useful is watching what good people actually do when things get awkward.
What do they do when nobody agrees? When a senior stakeholder is wrong? When the team says something can’t be done? When the deadline is going to move? When following the process isn’t actually helping?
That’s where a lot of the useful stuff is.
It’s also, really, what I wanted to write about when I started this blog.
There are plenty of places that can explain how to build a RACI.
I’m more interested in what happens when you put one in front of five people and two of them immediately disagree with their names being on it.
Learn the tools. Use them.
Just don’t confuse knowing the tools with knowing what to do.