Overview

IT uniquely approaches each support request in a consultative manner. We understand that if we provide solutions without asking “why”, we may not address the root problem of a request.

This document is meant to provide a high-level overview of how we work. While the process is sequential, it does not necessarily need to be followed in a prescriptive way. It is here to guide you through any challenges you may be faced with. Each situation is different, so work through as many or as few of these ideas as you need.

The Process

“What problem are you trying to solve?”

When someone makes a request outside of an everyday problem or ask, it’s important to always find out the “why” behind it. By asking clarifying questions (not justification) and determining the problem they are trying to solve, we can better determine the appropriate course of action.  

• Example of an everyday problem or request that is likely straight-forward:  
• “Can I get a new mouse?”
• “My Chrome app isn’t launching.”
• Example of a non-standard problem or request to ask “why?”:
• “Can I get a switch for my desk?”
• “We just started a new project and I need three MacBook Pros.”

Keep in mind that they could be coming to you with their own solution to a problem (“I need X to do Y”). This is normal and fine, and they could be completely right! However, we’re here to help shepherd them towards the right solution, which may or may not be the one they came to you with.

Remember to be kind, assume positive intent, and work as a partner.

Identify stakeholders

Stakeholders are the people and/or teams that will need to be involved in the decision-making process and would be affected by the outcome. They could be the person making the ask, your teammates, other teams entirely, or folks in varying departments.

Stakeholders may be any of those who:

• are involved in the project
• are invested in the outcome
• have right of refusal
• will support the team
• are key decision-makers
• the team should meet with to help get context

Understand scope and context

It’s important to understand the big picture before presenting a solution. We want to understand the goals, figure out what we can actually support or implement, and know who and what will be affected.  

You should try to learn:

• The problem or need they are trying to solve and what they hope to achieve
• How we would be helping  
• What concerns them and us
• Barriers to start (technical, timing, staffing, clarity or alignment on scope)
• Risks associated with the work/implementation
• What teams and individuals are involved?
• What platforms or apps would be affected?
• How many people are affected? Is this limited to a specific person, office, etc.
• When do they need a solution or resolution?  

Discovery and research to validate the problem space

It’s important to understand the problem and pain points from the perspective of those who are experiencing it or may have additional context. To get this information, we want to conduct user research. This will help us to define the problem, validate the business case, and determine next steps in finding a solution.  

User research could include:

• User interviews
• Surveys
• Focused retros
• Data analysis

After completing your research, visually organize the insights you’ve gained into like-minded clusters. Once organized, you can identify the overarching theme of those clusters to aid in prioritizing which to address first. This is called affinity mapping.

• We recommend using sticky notes on a whiteboard or in Miro, with one insight per card.
• What does a typical experience in this space look like?
• What are their shared pain points?
• Shared pain points should probably be prioritized.
• What are their wants and needs?
• Which wants and needs correlate to their actual pain points?

You may discover you have multiple problems to solve. Prioritize your top problems based on how valuable they would be and move forward on them. The others, deemed less important, can be worked on later down the line.

• Try using a 2x2, stack ranking, or simple voting to determine which should be worked on first.  

Develop/design a solution to fit the problem

After we have defined and validated the problem, we can then design a solution. Work with your pair or balanced team to generate several possible solutions and prioritize one to try out. You may even have several needs with multiple solutions for each part to solve. Prioritization becomes more important when the complexity increases. To narrow it down, consider using the following tools:

• Dump and sort
• Self-edit
• Solution prioritization using a 2x2

Test your solution in a controlled environment

You have a solution and you’re ready to roll it out. In order to minimize the risk - whether that is system downtime, breaking things in general, spending a lot of money, or realizing you attempted to solve a separate unrelated problem - we want to test it first in a controlled environment.

Determine what needs to happen (or not happen) for you to know your solution is successful. In a software platform, this is why we have development environments or sandboxes. You may want to ask:

• Does it solve the issue?  
• Does it cause unforeseen problems for others?  
• Is there no change to your current situation?

For a tangible solution - whether for a physical office, people, or a team - pick a small control group or location to test this.  

• For example, if you’re rolling out conference room changes, pick a conference room in one or two offices to be the test, and compare the results to the experience in other conference rooms.  
• Grabbing a control group of the same type of people you’re solving for anyway is better - having their input is far more valuable than people who wouldn’t normally use/touch/experience the problem space.

Gather feedback and iterate

You’ve tested and now you want to know if your solution works. The best way to find out is by gathering feedback from users. You can do this by:

• Talking to them directly
• Running another focused retro
• Sending out surveys
• Checking metrics that compared to the previously gathered metrics

If it works, and you’re ready to fully implement it, discuss with stakeholders before you go live. Be sure to communicate to everyone the changes that are happening and how users will be affected.

If it hasn’t resolved the problem, find out what needs to change and iterate on what you’ve done, adding this new information to what you’ve already gathered. Back to the solution development step.

• This process of iteration is normal and expected. This is not failure, this is progress. The knowledge you have from running the process once, if not enough to solve it outright, will continue to be valuable as you work on this and future problems.