In a previous post entitled ‘A Simple Why Can Lead to New and Improved Processes‘ I wrote about how the 5 whys methodology changed my world when it came to root cause analysis. I have since expanded my use of that simple three letter word to aid in requirements gathering and use case writing.
I was recently part of a fire drill project in which we had less than two weeks take an existing website and update and upgrade it to include a new line of business my company was looking to open. So, we had a meeting with some members of the leadership team and talked through what needed to go live for launch. The meeting quickly devolved into a checklist making party of “Let’s do this” and “Let’s do that” with one of the leaders prefacing the meeting with the statement: “I don’t know much about this technology stuff.”
I wish this project would’ve kicked off a week later because instead of a scathing internal dialogue keeping me sane I would have thought to apply my now go-to tool when it comes to evaluating the various processes across our business: “Why?”
For example, here is a chart that captures just a handful of the requests that were presented to me at this meeting and then runs them through the ‘Why?’ examination:
Everything in the first column seems fairly innocuous but asking why really shed a ton of light on two key things relating to the requests: 1) how well thought out they were and 2) how necessary they were in terms of the final product. Whitespace may not have been a favorite of the executive but it is one of the key tenets of clear web design so the ‘I don’t like it’ answer would have been easily countered.
Asking why is not just for root cause analysis. It’s a way to get people really thinking about the requests they’re making of their co-workers or agency partners. This post on CMSwire.com lays out eight tips to capture better requirements for software projects lists “Why?” as valuable tool, stating:
Ask “Why?” Ask it a lot. Never accept an answer in the requirements gathering phase without asking “why” at least five times. No matter the project, the technology, the company or the interviewee — “Why?” is the best question.
Why ask why? Because why is a pretty versatile question, that’s why. So next time you get what could be deemed an extraneous request just ask why a few times to determine if it’s a serious requirement or a nice-to-have. It gets people thinking about their requests and a well-reasoned, well thought out request is the best kind.