
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
Here in the ServiceNow community, we’re all technologists at heart. When we’re approached by the business with a new feature request it’s tempting to jump straight into our comfort zone, to the fun part, to … the technical solution.
Danger! This approach brings a strong risk of missing the real requirements behind the request.
I’m really glad to see ServiceNow extending its learning programs to include a learning path for Business Analysts. Today I’d like to introduce a simple tool that I borrowed from the LEAN process improvement methodology that’s great way to uncover hidden business requirements. The “5-Why’s” encourages us dive deeper.
As traditionally used in problem solving, the 5-Why’s approach is straightforward: start with the initial problem and ask “why” it exists, continuing to ask “why” until you reach a root cause. For example:
- Why did the system crash? – because there was a bug in the software
- Why was there a bug in the software? - because it didn’t get found during testing
- Why didn’t it get found during testing? – because the testing didn’t cover that feature
- Why didn’t the testing cover that feature? - because the team was rushed
- Why was the team rushed during testing? - …
How does this apply to ServiceNow requirements? Often, a user’s initial feature request is based on their perception of what the solution should be but isn’t necessarily the best way to apply ServiceNow capabilities to the real underlying business need.
As a (simple) example:
- Why do you need a field added to the incident table? - Because we want to track the status of closed incidents?
- Why do you need to track the status of closed incidents? – Because we want to track process steps we have after the incident is closed?
- What steps are you tracking? – We need to track the root cause analysis and follow up actions…
In the simple example above you’d guide the requester toward using the problem management module instead of extending incident management, but it’s not always that obvious. For example, if a user requests a custom workflow, ask why they need it. Perhaps they’re experiencing a bottleneck in approval times. Asking “why” again might reveal that don’t understand the approval system, or that the delay stems from outdated routing rules or assignment group definitions. A custom workflow may not be needed.
It’s not always “5” questions, but asking “Why?” (repeatedly) helps us find simpler, more effective solutions aligned with the system’s capabilities. The goal is to have an open-ended discussion to understand the request’s background fully and determine the best solution.
The 5-Why’s is an easy-to-use (and free) tool that any ServiceNow analyst or developer can use, regardless of project scope. It fosters collaboration, encourages listening, and ultimately leads to better, more business relevant ServiceNow development.
- 529 Views
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.