I have never, in my entire life, worked in an IT department where there was less work than time. There is always more that you can do. Always more to improve, more to fix, more to deploy. Which runs up against the first big question that always gets asked:

What should we do first?

(Okay, technically the first question we get asked is: can you just do this all at once? And unfortunately we can’t, because we’re temporal beings, subject to the capricious edicts of the arrow of time and unable to handle 9 number one priorities simultaneously.)

So how do you decide what to do first?

The obvious answer is that you create some kind of list or ledger or whatever of all your requests and then you prioritize them. Duh!

Except writing everything down doesn’t always make it much easier to prioritize them. In fact, it can be a little disheartening to see a list of work that needs to be done that’s way bigger than you can realistically tackle. So how do we create this list in a way that helps us gather information necessary to prioritize, and also keeps us … heartened? I guess.

Enter the “Symptom Statement”

My last post talked about what many different problem solving methodologies have in common. The first step is usually something like “Identify the problem” — but how they are identified can vary pretty widely. Some use a “problem statement.” Some involve comparing the “current situation” to a “target situation” and then finding gaps.

As we built out our own “lean” operations based around Toyota Kata we wanted to make defining problems as quick and intuitive as we could. We also needed it to be simple to teach. So we took some of the initial steps of the Toyota Kata problem solving method and combined them into a problem statement that follows this pattern (we owe a debt to “user stories” from agile methodologies as well):

[group or person] suffers [affliction] because [reason]

What makes a symptom statement powerful is when you make it as specific as possible. Often this takes multiple revisions, each one bringing you closer to understanding the current state. Let’s say you have a dozen retail locations that sell … sunglasses. The helpdesk has noticed several calls for stores not being able to sell because the internet goes down. They may create a symptom statement that looks like this:

• Stores suffer lost revenue because the internet keeps going down.

That’s a good start, but you would ask them to be more specific. Go back and find out which stores, and how often exactly?

At this stage what we’ve found is that you can quickly weed out problems that aren’t really problems. You may have an impression that something is a serious concern, but when you dig in it’s not actually a big problem (maybe every store is having one outage every six months or so, which feels like a lot as a group, but is pretty normal individually).

So after a little research the symptom statement is revised:

• Our two locations in Salem are suffering lost revenue because the internet has been going down once a week for roughly an hour at a time.

This tells us a lot more. Maybe we have a few more questions. How much revenue are they losing? And why just those two stores? And why is the internet going down?

• Our two Salem locations that use “Salem Broadband” are losing roughly $300 in revenue per week (each) because the internet has been going down weekly for an hour at a time due to “unscheduled maintenance” from the ISP.

Now we have a very specific and actionable symptom statement. We’re ready to start looking for solutions. Maybe we could go to a different provider, or add a backup provider, or a cellular backup, or try and set up a store-and-forward system for internet outages.

The great thing about the symptom statement like this is that it also provides a way to gauge the ROI of any possible solution. Maybe a second provider would cost $100 a month, plus we’d have to buy a new router at $1500. At those prices it would take less than two months for the solution to pay for itself.

The other interesting thing I’ve found working with symptom statements is that often it takes a while to reach the actual symptom. Multiple times we would look at a symptom and say “is this really the group that is suffering?” only to find it was actually IT that was suffering, or developers, or only some specific person.

A symptom statement starts general, and over time becomes very specific and objective. If you look at the first example above all the vague statements become super obvious in retrospect. “Stores” – which stores? “Suffer lost revenue” – how much revenue? “Internet keeps going down” – which provider? And why? And how often? What time of day? Etc.

Eventually it will become second nature to look at a vague statement and know exactly where you need to start to make it concrete and objective.

Give Symptom Statements a Try

Alright, so try it out with this activity — maybe plan 30-60 minutes.

1. Get all your team leaders together with post it notes and pens for everyone
   (get nice pens! I’m partial to Muji’s myself)
2. Explain the symptom statement as we’ve done above
3. Ask everyone to take 5-10 minutes to write down any symptom that springs to mind — one symptom per post it.
4. Remind them that these could be issues your users feel, customers feel, the IT department feels, some other department feels or things that the business suffers in general
   (cybersecurity people will have a lot of “The business suffers increased risk because ….” notes)
5. Have everyone put them on the wall
6. Go through every post it note, reviewing what is written and revising it — since this will be most people’s first time there will probably be a good amount of revising, but it’s a really helpful exercise
   (I don’t mean revising like above, where we’re gathering more detail, I mean just making sure the syntax is accurate and the symptom actually is what it says and affects who it says)
7. As you revise them, cluster them together based on similarities that spring to mind. You’ll likely find there are some that are based around processes, maybe even specific processes. Some may be based around specific tools or products. However you do it, cluster them together

When you’ve reviewed all of them, ask everyone what the most important symptoms to treat are. What you’ll likely find is that some projects that people have been working on for months will lose their importance when you stop to think about the problem you’re actually trying to solve. You’ll probably also find that the most impactful things to look into will be the basics — processes, building expertise, communicating with the business, etc.

What we have also found is that shiny new tools all of a sudden become less shiny when you realize that you’re deploying a huge product to solve a problem that …. isn’t actually a real problem. And that by doing so you’ll probably introduce new symptoms that you can’t even predict. All of a sudden deploying a new system becomes something that only happens if there is a concrete, definite, quantifiable need — instead of a knee jerk reaction because people don’t like something about the current solution.

Once you know the symptoms to tackle, use one of the problem solving methods mentioned in the last post to solve it! I highly recommend Toyota Kata.

Let me know how it went!