As a Technical Solutions provider to an organization at my company I deal with multiple clients at any given time on a wide range of projects. When your team is servicing multiple clients within the same company it can be tricky to pick, prioritize, and produce for each client on each request in a timely and professional manner. These steps to follow are a culmination of methodologies I’ve experienced with over the last decade. Here is what I think is worth taking away. (There are no revolutionary insights here. Just a re-iteration of what most good methodologies strive to achieve.)
1. Be respectful and listen to their concerns. It’s important to try and place your feet in their shoes to attempt at “feeling” their pains. Be compassionate and understanding.
2. Translate their stories, feedback, data, etc, into an understandable mind-map to see what’s “deadly towards being productive”, “a side effect of the root problem”, “a need-more-clarification before judging”, etc.
3. Identify, in that mind-map, what User (in)action cause the root problem.
4. Ask yourself: “Is software the best answer to solving the root problem?” If not, present why and move on to the next Client problem today. If Software is a good fit continue.
5. Design a client-friendly (read: mock-up) software sketch of how and why the software will solve this problem.
6. Ask How and Why the User thinks that software solution being presented will solve the problem. These questions should identify whether the User actually agrees/likes the solution.
7. Alternate between steps 5 and 6 a few times until everyone is on board with the sketched solution.
8. Build the sketched solution. Have one of your subject matter experts (SME) give it a whirl. Are they clicking and thinking about the solution the way you had envisioned? Ask them to talk about what they are trying to do while they try to do it within the solution. Pay attention to their concerns. The solution should solve the problem, not create another headache in the process.
9. Demo the sketch to a larger audience. You’ve already vetted the solution to the SME, so this step is more about letting other Users of the software see how an expert would use it.
10. Launch the Demo.
11. Run a newsletter or some notice that the tool is launched – this step is for awareness amongst non-solution Users.
12. Schedule a 2 week, 4 week follow-up right now. Aside from any subtleties or bugs discovered during use, you’re looking for long term feedback when they least expect it. You should catch some good stuff here. Maybe they’ll provide a testimonial to the solutions success. Other scenarios include finding out the user has never actually used the tool once launched. That’s OK. Just remember that the next time around when dealing with this client. I think this is one of the most important points… Software is not a build-and-forget process!
Mind-mapping out what scenario we face is a great way to categorize & contextualize what we’re dealing with. After a few dry runs using this process you should find yourself naturally limiting the scope of your projects by identifying the root problem, if their even exists one. You may save yourself from one or two less valuable problems-to-solve a year and that frees up time to work on problems-worth-solving.
Do you have a 12 step program, or other method for madness, that has worked well? Leave a comment!