Ask Why

[Chuck Tomasi]

It's quite likely that if you're reading this, at some point you'll be approached to add a field to a form, create a report, or change the system's behavior. Before jumping in and making that 2 minute change, spend 15 minutes and always try to understand the underlying reason behind the request. Ask "Why is this needed?", or if you prefer to use a phrase like "Help me to understand…"


I get asked by customers to make changes to their system on a daily basis. They come to me with what they feel is the solution to the problem, when they haven't explained the problem yet. Don't fall in to the trap of doing what they say. Understand what the issue or requirement is before implementing a solution.

I had one case where the customer had deployed incident management with a dozen categories, and each category had 3-10 subcategories. For example: Category=Software, Subcategory=JD Edwards. I got a request from one of the JD Edwards analysts asking to create a sub-sub category so they could break out the JD Edwards subcategory. (Just the name sub-sub category was enough to make me wince.)

To make this more interesting, she was in Malaysia and I was in the U.S. so communication was typically done via email and replies often took days. Over the course of three weeks of going back and forth trying to understand what she was after, I decided to enlist my partner in the same office to voice my questions directly. He knew what I wanted and could easily act as an intermediary to get to the heart of the matter. On the very next weekly call I had with my partner, he said "She wants a list of JD Edwards functional groups to help understand where they have the most issues. For example, Finance, Accounting, User Training…" In short, she wanted to group the common JD Edwards incidents together and get a root cause so her group could take corrective action. You see where this is going don't you? OOOOHHH, She needs a problem management system! Unfortunately, at the time they had not yet deployed problem. Once we sorted that out she understood and agreed to wait until problem was online to do what she needed.

If I had simply agreed to create another dependent choice list, that would have taken a few minutes. Getting people to use the additional field properly so the managers and supervisors can draw meaningful information is another order of magnitude harder. By understanding the intent, I was able to avoid building a little more complexity in the form which ultimately leads to confusion with the other IT users.

• First, Seek to understand their needs. Don't take their solution at face value when you haven't understood the problem. Ask why.
• If necessary, consult the community for additional knowledge in the matter.
• Offer options.
• Finally, make your recommendation based on their needs.

In the end you'll save yourself, and others lots of time and frustration.

[Chuck Tomasi]

Thank you

[jjill]

This info is still relevant!  😄 

[Jonah Piascik]

This is so still relevant!  I was just speaking to a colleague about this same thought process, regarding another of our systems (our most critical - EHR).  The example your provide with category>sub-category is something we also lived through, and are now in the process of replacing it with the CSDM.

I can't believe this was originally posted 10 years ago!

Thanks Chuck!

[Chuck Tomasi]

This is one of those evergreen ideas that applies to more than just ServiceNow and more than just software development. Seek first to understand what the customer is looking for. What are the desired outcomes, then plan a way to best address them. Don't let the tail wag the dog. More specifically, don't listen to the customer's proposed solution. Once you know what they REALLY need (richer reporting information, faster turnaround, decreased costs, etc.) Then you can start to architect a solution to fit that. Anything else is too risky and potentially wasted time.

[Olu Oguns]

Thanks for sharing, the "why" is very critical before fulfilling requests.

[Felipe Vilela1]

Thank you very much!!! What you are saying is exactly what happens in real life!

[Paul A Ciocan]

Reading this article was really helpful, I pressed on the Thumbs-Up button, also I had to read this as a Lab Exercise. There are takeaways from this blog post.

[Susan31]

Oh how I would love to go into the details of what we just went through with my company implementing ServiceNow for the first time, so many lessons learned!

Suffice it to say your blog post hits WAY too close to home.  When we started the project I was not a ServiceNow developer, nor a software developer of any kind.  My most recent experience was as a process analyst, but my role was release manager, this is to say as a customer I had no idea what I wanted, or how to get there.  We hired a vendor partnered with ServiceNow to do the implementation.  As we started the project I reminded our internal team over and over to:
1) stick as closely to out of the box behavior for the initial implementation as possible

2) think about why we are doing something and don't just do it because that's how it was done in the prior ticketing system

3) listen to the experts (implementers) and give serious consideration to what they recommend as they have done this many times for many companies

Eventually, people fell into their normal behavioral ruts and pressures of time and budget constraints and ignored all the above advice and we are paying the price now. 

All this to say:

Chances are your customer does not know what they want, or how to get there, in ServiceNow and they shouldn't have to know. They really just know the problem they want to solve.  As a ServiceNow developer or implementer, keep in mind YOU are the design expert and it's up to you to guide your customers into doing what is best for their company while doing what's best for the ServiceNow platform, i.e. just because we CAN do something, does not always mean we SHOULD do it.  This is not always what they want to hear, so it's a good idea to develop your soft skills in asking the questions:
Why do they need it?
What are they trying to accomplish?
What is the problem they are trying to resolve?
What are their pain points?
Who is the target audience for the change or who benefits from the change? 

Then design a plan or solution that knocks their socks off while following best practices and keeping it as simple and clean as possible.  Also, I've found that often the customer does not care about the details of how their problem gets resolved they just want the end result.  So feel confident when you explain to them why you designed the solution the way you did, as the expert your confidence will ease your customer's mind.

[anjayani]

Hi Chuk, Can u plz help in designing a report on survey ??. . . . . . . . .

[Hunterod2]

Thank you, Chuck! Very insightful as usual!