The Now Platform® Washington DC release is live. Watch now!

Help
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Chuck Tomasi
ServiceNow Employee
ServiceNow Employee

find_real_file.pngIt'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.

48 Comments