Structured Problem-Solving Maximizes IT Effectiveness

Guest blog by David X. Bonnar, Manager, Web & Application Development and ERP Systems, Community Medical Centers, Fresno, CA.

One of the duties of a leader is to grow his people so that they can help improve the organization.  Providing smart people with good tools and techniques makes them better professionals, and that should also help the organization improve while it helps the leader fulfill his mission.

Providing my leaders with structured approaches to different situations and problem sets is key to their effectiveness. Teaching them roadmaps through situations adds value to their career.

Providing tools and techniques to your people requires various degrees and styles of training, and as a leader, you should be ready to teach them (or at least make sure someone is teaching). Helping your team adopt and use tools that are new takes time and repeated exposure.

A Common Language for Problem Resolution

There is one tool set that I’ve found to be equally useful to my technical systems/network staff, as well as my project managers and analysts. This tool is not a product—it is a way of thinking: the Structured Problem Solving Roadmap (SPSR). It also creates a common approach that I can manage to. This means it’s useful to both leaders and followers and is worthy of mastery.

I learned some parts of SPSR in the 1980’s as part of the formal training provided by Novell for their Netware Certified Engineers program (CNE). They wanted to teach an orderly method for troubleshooting complex networks (ok, in 1980 we only had SPX/IPX and networks weren’t as complicated as they are today - -- but I appreciated the tools).  The approach taught was to “cut the problem in two” repeatedly until you thoroughly understood it (Define) and then work to Resolve it.  I fell in love with it as a way to work with my IT staff on problem resolution.  I’m not sure where else it’s been taught, but I am documenting my version of it here for the benefit of the reader.

The SPSR provides a common language and a structured approach for problem resolution. It is a lifelong skill that I have gotten better and better at using over the years. I teach it to others by repeatedly emphasizing the five steps, and asking them to explain where they are in the structured problem solving cycle. 

People at all levels can use a structured approach to problem solving. When they do so, my experience has been that people simply perform their jobs better.

Right when things go wrong, always remember:  Discuss and determine with the team what activity/phase of the SPSR you are operating in at the moment. Start documenting immediately.  You’ll want to review assumptions, activities and results all throughout the problem resolution process.

The Structured Problem Solving Roadmap Process

The five steps of the Structured Problem Solving Roadmap (SPSR) are:

1)     Detect

a)     Detection has to happen before a problem can be tackled.  Most activities around improving the Detect phase happen after the fire is out, but you start thinking about improving Detect immediately upon learning of a problem.  Did you get that?  Even before the problem is solved, be thinking about improvements your team should make to their Detect competence.  This is the leader’s job – get through the crisis, but ponder how to improve at every stage.

b)     Later, during the Prevent phase, perhaps during an RCA (root cause analysis), ask questions like: “How well did we do at detecting?” Once everyone is done assuring you that the detect Detect is flawless, ask “Were we the 1^st to know of this problem or did someone else know before we did?”  Here’s the deal: If someone knew before your team knew, then there is room for improvement in the Detect phase. Your team should know before anyone else that something is wrong in their area of responsibility.  In other words, if someone on another team (or a customer) alerts you to a problem, you have two problems! One is the problem, the other is your team’s competence at the detection of problems. Your Detect skills should be so good that they are confused with prevention.

c)     Communicate: Be sure to share the alert around an issue with other responders so that they are aware of who is working to solve the detected issue.  Avoid too many cooks at a critical time.

2)     Define

a)     Don’t try to contain or solve a problem until it is defined and understood. It’s fun to whack moles, but that doesn’t define what the future should look like. People sometimes want to resolve so quickly that they try to skip the definition of the issue.  However, I’ve learned that a formal written definition of the problem is the seed for my later root cause analysis, and for good documentation about how to diagnose similar issues in the future. In other words, a good definition is how we will know in the future if the problem reoccurs, so Define it even if your team wants to rush to solution.

b)     Communicate: Be sure to share your definition of the issue with all involved so that everyone is working to solve the right thing. I’ve had my team send a problem definition out to stakeholders before, and seen it blown to bits because my team only had visibility into a small part of the problem. Communicating out our Define helped us contain, and then solve the actual full scope of the problem, not just our small vision of it.

3)     Contain

a)     Stop the bleeding – quickly, even if temporarily.  In fact, temporarily and rapidly is sometimes best as it stops the panic, and lets people engage their creative side for long term thinking.

b)     Normally, Contain involves workarounds—quick, temporary changes that can involve lots of trade-offs and negotiations about the immediate and longer term impacts of the containment steps. You have to negotiate any tradeoffs rapidly in this phase.

c)     Communicate, let all involved know what the workaround (Contain) actions are, and that the issue is not completely resolved.  The feedback you receive from communication about your containment plan or steps may protect you from missing the mark.

4)     Resolve

a)     The fourth step is to solve the problem for the longer term.  Resolution = Long Term.

b)     Communicate the resolution, and that you are moving on to the Prevent phase of problem solving. Let people know that you know that you need to prevent, even while you take some deserved credit for resolution. Maybe even share the improvements your team discovered about the Detect phase in this announcement. Earn some credit!

5)     Prevent

a)     Leaders don’t back off here.  Respect is earned here.

b)     How do we prevent?  Seems easy but takes focus and commitment.  Most people want to move on, they hate prevention if it requires introspection. Stay with it – there is gold here. In my experience, people are initially annoyed, but they quickly realize that you’re right to focus here and expect written plans and procedural changes. 

c)     While we’re here – go back to phase 1 and ask how can we improve our Detect capabilities/processes for the future? Can we improve our ability to communicate detection (more timely, more clear, the right people, etc.)?  Improving Detect now is almost like free money. It’s all good.

d)     Communicate your Prevent plan. You will be amazed by both the positive comments, as well as the challenges to your Prevent plan that you will receive. Those challenges will refine your Prevent plan, then you can communicate it out again. Continuous improvement!  Trust me – people will know exactly what you are doing that it is the right thing. 

Structure Engenders Support and Respect

I’ve found that people who love excellence expect and support my use of a very structured process for problem resolution/solving. This goes for my own team, as well as for leadership who can see what we are doing.

I continually remind staff to consciously identify which phase(s) of the SPSR they are actually in at the moment. Did you notice that Resolve is the most briefly described step here? It is the most important for the moment, but for the long term, I’d rather focus on asking my people for improvements in detection and prevention any day. I Resolve because I am paid to.  I make improvements in my team’s ability to use the roadmap and to find opportunities for improvement in each and every phase because I care about them, the company and the customer. 

As you use the SPSR, you’ll learn that people can still be in the Define phase, while ideas for Contain and Resolve are being generated. That’s OK.  Just make sure folks agree on the phase we are “mostly” in so they can bring their attention to bear on that phase primarily. 

After the dust settles, lead an “after action” analysis, step-by-step asking “What did we do well, and what could we do better?” in each phase, one at a time, look for improvement ideas.