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.

[Surbhi Rani]

Thanks Chuck , Interesting blog !! :), what can be more good than understanding by your personal example with the customer.

I also face this while serving customer with there requirement. Understood that there is no bad in asking "Why" what if the solution is just a click and  save .

[JerryJ071847183]

Thanks Chuck ... you are fantastic I admire you . It was really  nice and  meaningful post. But, my concern  here is that in most of the service based companies BA's from our company take requirements from Customers and they give it to us directly and tell us to implement , so we just get the precise view of what to do , due to that lot of time we end up creating one field and removing that same field when business feels it is irrelevant. 

But from now onwards I will ask them one simple question  ""Help me to understand…" before implementing anything .

[Tamizh Selvan B]

thanks for the article!! 🙂

[Dave Smith1]

"in most of the service based companies BA's from our company take requirements from Customers and they give it to us directly and tell us to implement"... has anyone asked them exactly what part of "Business Analyst" they're doing here, if they're simply channeling requirements directly from customer to design?

Your concern is valid, but ultimately amounts to "I know many BAs that don't do this" - consequently the wrong thing will be built because the requirements were not properly validated.

Yes, I've seen it happen before - with companies that blamed the devs for building the wrong thing, not the BAs for defining the wrong solution because they never bothered to understand the problem.

[Chuck Tomasi]

Hi Dave,

It comes down to the same thing. Don't be a automaton developer. If you don't understand a requirement or have questions "Why are we doing this? What's the underlying requirement? - ASK!" If it means the BA has to go back to the customer, that's their fault for not gathering the proper information. If it costs more, use that in the project retrospective to understand how to avoid it in the future. If the person is just ineffective, that's going to fall back on them (eventually.) 

One solution might be to get the developers in the BA meetings earlier when requirements are being gathered. I've seen this done a number of times very effectively when I worked for an engineering company for over 20 years. You may need to give the developers some guidance to NOT solve the problem right at the table. I'm guilty of this. I start writing code/build solutions in my head before I have all the requirements. Thinking about the requirements is good, but don't make assumptions about the solution. You may not see how the pieces fit together until you have all the pieces! Get all requirements, then ask questions to clarify.

[Carl Fransen1]

Right-on point as per usual Chuck - the trick is convincing the 'customer' to also do this, and let them think it was their idea in the first place - regardless of whether you're an implementation partner or it's for an internal customer.  

Hope you can make it out to NZ in the near future, if the murmurings are to be believed 🙂

Cheers

Carl.

[Cathy Wang]

Like your articles. I just subscribed! Thanks!

[EricMiller]

Nice article Chuck!

I am here as this article is referenced as part of the Scripting in ServiceNow course.  I might have heard you say this on Community LiveStreams a few times.

Keep up the great work!

[Cheryl H_]

Understanding "why" is at the heart of great UX. Thank you for sharing this.

[Ganpat Patel]

Excellent post.