In an interesting meeting recently I was asked an interesting question: ‘how do you solve problems in a programme environment?’
Like many people who make a living from getting stuff done, problems are an everyday thing: they’re just part of the rich tapestry of projects, and indeed – life. I wrote about problem solving a while ago here and here, but the question made me think more deeply about the different ways to approach problems, and I was pretty happy with what I came up with as an answer, so I thought I’d share a slightly fuller version of it here.
As we work through projects, delivering the building blocks that contribute to a successful programme (as per the figure below), the rate of progress varies, depending on resourcing, focus, constraints, problems and so on. Sometimes problems don’t impact progress for longer than it takes to have a conversation, but others can have a more disruptive impact – taking longer to return progress to the critical path.
In a project team (and even more so in a programme team), there is a variable threshold for uncertainty: one person’s major issue is a line on another’s To Do list. Treating everything that happens unexpectedly as a problem spreads doubt through an organisation, so the first step is to establish whether it merits attention as a problem in its own right (i.e. whether it has the potential to impact key parts of the project), or whether it’s just something that needs to be added to a To Do list.
If the problem is a simple one, then a little thought and a few conversations are often enough. If it’s more involved then I’ll get a few people (3 or 4 seems to be the sweet spot) together and whiteboard potential solutions until we’ve agreed on a solution that;
- will work, and;
- we can explain to the rest of the team, and more importantly the client.
If we can’t come up with a viable solution, or if constraints (usually time and the associated resource costs) mean that there’s no time to implement a thought-through solution, then we go to the next step – working around the problem.
On well-run projects we can batch most of these together for post-go live resolution. On other projects, they may be ignored and forgotten in time; contributing to a belief amongst people that have to use the systems / processes that a project leaves behind that the term ‘Phase 2’ is a project management joke.
Successful (or more accurately: ‘successfully perceived’) project management often comes down to deciding when to buffer (if you pass on every problem without resolution, a client can legitimately ask ‘what am I paying you for?’) and when to escalate. These are my tips for escalation:
a) Provide the background to a problem, to ensure the client is well-briefed. Few project managers will survive the fallout from a client appearing ill-informed about a major issue on their watch;
b) Articulate the steps you and the team have been through to solve the problem;
c) Recommend a course of action – ideally the thinking you’ve done will mean that this fits in the context of the project and the wider organisation;
d) Be prepared for the client rejecting your plan – it pays to have a fall-back position. This is usually when your earlier whiteboarding session proves its value.
Some problems are not resolvable. In these cases it pays to figure out the root cause and make sure that you learn the lessons the project is teaching you.