Welcome back for part 1 of my series on SMACK, an approach I've developed over the years to push adoptions and usage of the systems that I've worked on.
Let me start with apologies, as many of you know I took a position as an application development manager at Microsoft back in September, and I've now hit the point where I'm supporting customers and it is keeping me MORE than busy. And on top of that we've had some exciting things going on with our other blog TotalALM. Including Brandon and I recently being invited as guests on the internet podcast DotNetRocks.
But I digress, back to what I was talking about.
Firstly, if you haven't already looked at it, there's a link to the previous post on the basics of the approach. This describes the underlying principles behind the SMACK method. But the short version is that we as software developers tend to focus on the technical details, the how's and what's of the conversation. Specifically speaking, the "How we solved the unsolvable problem?" and "What we did to solve it?" or "what we were able to deliver?"
The simple fact is though, that at the end of the day, there are two groups of people you need to convince if you want to drive people to actually use the solutions that you've built. And more than that, transform them into true believers in your abilities. Those two groups are Front Line Users, and Business Decision Makers.
These two groups of people are the most essential groups to focus on your efforts. Convincing IT people that its a solid solution does little to get it used. Its an essential part of getting it deployed, but that's only the first step. The first group being the Front Line Users, these are the people who will be using your system the most. They many times focus on the data entry, or people using the systems. IF these people don't want to use your solution they won't. They will complain to BDMs, and they will not put quality data into the solution. No quality data means no overall value.
Think about this logically, do you use tools you don't see the value in, do you use software packages that make coding easier or harder.
The other group is the business decision makers, and these people are the ones who will make the decision that your system is necessary, and if they don't believe in it, you will have no managerial mandate driving the usage of your solution.
So the whole point of this article is, how do you make these people pay attention? How do you make them true believers that will embrace your solution and see the value you intrinsically know is there?
Back in the day, we all had to take some form English class, or writing. And one of the things I remember is the journalism questions, that all news articles should answer the same questions. Who? What? Where? When? Why? and How?
Like I said, we as developers love to answer the What? and How? Specifically focused on the details of the technical solution. But at the end of the day, these two groups don't really care about either of those questions. So what do they care about? The most important question to them is "Why?"
Why should I use this? Why does it make my life easier? Why do I care? And there are a couple of things you can do to make sure that user's see the "why's" in the same light as you.
Step #1.) Always present the why's towards the beginning: Inevitably you are going to be presenting what you've built to end users, I usually start with a slide towards the beginning of the deck that says "Why do you care?" across the top. This draws their attention to the benefits and frames the conversation so that when you present it makes them focus on the positive and not the negative.
Step #2.) End with the same "Why you care?": Make sure you drive this point home by circling back to this in your presentation.
Step #3.) Keep the points in "Why" do you care focused on them. They don't want to hear this will make your life easier, they want to hear how it makes their life easier.
Step #4.) Keep the tech jargon out of the presentation. Other developers might be impressed with how you built this solution, but they aren't. Don't waste their time.
This is an essential part of succeeding in the IT field and not something to take lightly. And this is one that I intend to spend many of a blog post on.