Identifying the opportunity for improvement is the first challenge of a design team, problems can come from many directions and usually are not as clear cut as they first seem; Often times symptoms masquerade as problems, for example I once worked with a client where it took 48 hours from the moment a user requested access to a system before it was either granted or the user was informed that they needed to take the appropriate training; after some investigation, the problem seemed to be a 48 hour service level agreement (SLA) with a 3rd party provider who was paid per ticket.
The provider was not willing to budge on the 48 hour SLA putting us at an impasse, but once we asked why is this handled by a service provider we started to gain some traction. We ended up cutting down a 48 hour turnaround time into a 10 second one by circumventing the service provider with a chatbot.
Now the above is a very simple example that nicely illustrates that the symptoms of a "slow" system was actually the result of of an underlying problem of not having a dedicated admin that could handle the request, and that in fact this "admin" wasn't even necessary.
When we are trying to define our problem we should pursue questions along the following lines:
- What is the actual problem underneath the symptom(s)?
- is there a resolution?
- what are the components of the resolution
- can the components be modified or reordered
- Who is affected by the problem,
- our staff
- our clients
- our management
- some of the above?
- all of the above?
- who has tried to solve this problem?
- Other teams?
- our competition?
- has anyone solved it
- has anyone moved towards a solution?
- When did the problem start being a problem?
- this year?
- this quarter?
- last week?
- why is it important now?
- has it always been there?
- has something changed that suddenly it's more serious? or just more visible?
- has management changed
- was someone managing the problem and no longer is
- if yes, how?
- if no, why?
- Has someone failed to solve this problem in the past
- what can we learn from their failures
- what did they do wrong
- did they understand what the root cause was
- where is this problem
- local?
- regional?
- national?
- global?
- is it a cultural specific challenge?
- Source of the problem
- Internal
- management
- union
- personnel
- Partner
- 3rd party provider
- strategic alliance
- Competitor
- Direct
- Indirect
- Disruptive tech
- Government
- Law
- Cultural change
- Why is it worth solving
- enough impact to dedicate time and resources
- will the solution be cheaper then the problem
- in the long run
- immediately
- does it matter (if it's legislation driven)
The most important thing is to dive deep, when investigation our problem, not to stop after the first level of questioning but to keep chipping away until we can get to the root cause, it's a very contextual approach, it's hard to say when you've gone deep enough. For my chat bot solution, the line of questioning that got us to our solution went something like this:
- Why does it take more than two days for new users to get anything done in this system?
Because it takes up to 48 hours to gain access - Why does it take 48 hours to gain access
because it's a 3rd party provider that handles it for us on a ticket basis - why do we use a 3rd party provider
because its a rarely accessed system and it doesn't make sense to have a dedicated admin - Is the system ours? or the 3rd parties?
it's our internal system - is there a rest API that we could use to access the system
Yes.
The above is a very neat and tidy representation of what we did, in reality there where many dead ends we investigated many points of contact, many frustrations and many experts we had to consult, which brings me to my next point, just because our team has a technical component it doesn't mean it's the right technical component, when solving problems as a team you have to move beyond yourselves and consider solutions that you may not be well versed in. in those case you need ask yourselves:
- What expertise do we need?
- Who has the expertise that we need?
- how much does it cost?
- do we need external help?
One of the biggest challenges that we have to overcome is getting a handle on what the root cause of our challenge is, to make matters worse often times the client doesn't truly understand what's wrong:
- The wrong problem being presented by the client
- The wrong solution being presented by the client
in both cases it's easy to follow the wrong path, if the client pays you to solve the wrong problem or even worse they give you the solution to implement you are left in the worst possible situation where even if you are successful you still fail. If you solve the wrong problem 100% effectively you are still 100% wrong.
