So you’ve got a problem. It’s on the issue log. You’ve pulled together the key subject matter experts who can help get the project over this hurdle.
But how do you come up with the answer?
Sometimes, the answer to a problem is staring you in the face. There is only one sensible solution to fixing an issue. You are confident that using that approach is going to get you where you need to be. And the project can carry on.
However, that isn’t always the case.
In this article, I’ll share a secret weapon for improving problem solving in project management. And you don’t have to do anything different to use it.
I’ve been involved on many projects where seemingly simple problems turned out to be vast caverns of knotty issues, and unpicking one led to something else unraveling. Can you relate?
I find that this is particularly the case with complex processes or projects with lots of moving parts and many stakeholders. In those situations, it’s hard for the subject matter expert in the ‘problem’ area to see exactly what the impact of their solution might be on other departments or downstream processes.
The fact is that many knowledge workers don’t have a perfect working knowledge of the entire business, and why would they? That’s not their job. However, not having that bigger picture view can make it harder to sort out tricky issues.
2 ways to resolve tricky project issues
So how do you get over these hurdles? As I see it, there are two options for unpicking those large, knotty problems that you face on a project — the ones that touch multiple business areas. Actually, these approaches work even for small problems.
Option 1: Work with a skilled business analyst to help you dig into the operational processes and uncover a solution that works the whole length and breadth of the problem.
Option 2: Do problem solving the best you can, calling in subject matter experts as required and checking and testing before you take any action.
Unfortunately, in many businesses, the BA skill set is sadly lacking. Experienced BAs are hard to come by and very valuable (so if you have the opportunity to have a business analysis expert on your team, grab it!).
You are left with the alternative of facilitating the problem solving yourself, as the project manager.
Lessons learned: your secret weapon for problem solving
So here’s the secret: in this article I’m going to show you how to expand your problem solving toolkit by using your lessons learned log to uncover potential solutions.
There is so much rich information available in your lessons learned log. It already exists, so you don’t have to create anything new. And it’s packed with tips and tricks that will help you resolve issues.
Here’s how to use the project management lessons learned information to improve your project, specifically coming up with ideas for tackling issues when you can’t easily see what route might be the best option.
1. Review the lessons learned log
When you first identify a problem, quickly scan through the lessons learned log or minutes from lessons learned meetings and see if you’ve come across this issue before.
While you are checking project documentation, you may as well review the risk and issue logs too, just in case something similar has come up in the past.
This step should be the first thing you do when someone asks you something or flags a potential problem. It may just be that you or someone else on the team already had this on their radar and there is a plan to deal with it.
2. Look for relevant information
As you review your project management documentation, look for relevant information, contacts, facts, data sources and more. If you find something relevant, see what you can draw from that.
Your current problem might be caused by:
- A lesson that was uncovered earlier in the project or on a different project, but the underlying process was never updated with the suggested improvement
- A process that was changed as the result of a lesson learned, and your current problem is the result of that poorly-thought-through change
- Something you thought the team had already learned and improved on but is still happening.
Or, of course, anything else. Problems have roots that go deep! See if you can find anything that links to or informs the issue you are currently having.
3. Use the lessons learned information
If your lessons learned log gives you a nugget of information you can use to fix this problem, then go ahead and discuss what you’ve found with the team.
I find that often this solves the problem straightaway. I can’t speak for all businesses, obviously, but I do talk to and mentor many project managers and there are common threads across many teams – one of which is that we aren’t good at managing organizational knowledge.
The better we get at accessing and using what we know, the easier it will be to resolve problems in the future.
Use other sources of information too
Let’s be realistic: your lessons learned database isn’t going to magically solve all your problems. You’ll be coming across new and unique problems specific to the stage of the project you are in.
There will be situations where you can derive something useful from the lessons learned log, but that it doesn’t quite solve the problem, and situations where there’s nothing helpful in there at all.
In those cases, you need to move on to other problem solving techniques to fully resolve the issue you are having. Techniques like data analysis, root cause analysis, reviewing risks and issues, digging into processes, spotting where results are outside of control limits and more will help you better understand the problem and therefore have more chance of coming up with a reasonable and successful solution.
Capturing lessons learned
This technique of using lessons learned for problem solving ideas is great. But there is one catch. It only works if you have a lessons learned log to refer to! Let’s look briefly at getting started capturing lessons learned so you have an archive of rich ideas to return to as and when you look to improve processes or learn from issues.
You know how to run a brainstorming session to help with problem solving; brainstorming for lessons learned is exactly the same process.
Most lessons learned capture is, in my experience, carried out after a piece of work. You might do this as part of a retrospective, or in a more linear project methodology, at the end of the stage or project.
Create an agenda for lessons learned discussions. I find it helps keep the conversation on track and focused on lessons, and it helps remove any blame because the agenda makes the meeting feel more formal and structured. Structuring your meeting will help you get something useful out of it.
Talk about what worked, what didn’t go so well and what you have learned from that as individuals and as a team. Document the lessons.
Moving beyond lessons learned
Documenting the lessons learned is one thing – you’ve now got them in your log so you can refer back to it if necessary. However, you haven’t actually solved anything or prevented problems from happening in the future. Lessons captured are not the same as lessons learned!
If you want to truly benefit from what you’ve covered in the lessons learned session, please take action as a result of what you uncovered!
Using lessons learned proactively this way will also help you cut down on future problems because you are picking off and improving things as you go.
A version of this article first appeared on Project Bliss.