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.
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 unravelling.
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 expert in the ‘problem’ area to see exactly what the impact of their solution might be on other departments or downstream processes.
Unless they’ve got a perfect working knowledge of the entire business, which in my experience is rare.
So how do you get over these hurdles?
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 one on your team, grab it!).
So you are left with the alternative of facilitating the problem solving yourself, as the project manager.
Lessons Learned: Your Secret Weapon for Problem Solving
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. Let’s dive in.
Review 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.
Look for Relevant Information
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!
Use What’s There
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.
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.