The Power of "Why"!

(For Non-Coders and Coders alike!)

Introduction

Often times we need to design solutions with incomplete information. It isn't intentionally incomplete; it's simply that way because either the customer doesn't know to bring it up, or the developer/BRM/other hasn't asked the right questions.  

This discussion will be targeted toward non-coders with an example, but will also include a coding discussion for you coders out there so that you can see it from that angle as well. Since we don't know what language you might code in, we'll simply talk at the 10,000 foot level because non-coders will understand this as well. The Geek example will be more of real world example to help drive the point home.

Let's get into the discussion of "The Power of Why!"

Non-Geek Discussion

There is a rather famous cartoon some attribute to 2005 posting which you can see here:

As you can see, it tries to show the difference between the different roles approaching a customer's needs/requirements. But, mightn't the differences have been made narrower with a simple question? WHY!?

Even the justice system uses why as a key question. Motivation is the "why" they search for because it brings clarity to the what and who.

Let's examine this with an example. You've been tasked by your VP to stage a symposium for your company, ABC Corporation, who specialize in electronic devices and they need you to stage it, market it, and organize it. They need your plans in one week, because the event is to occur in 3 months.

You do your (Scooby) due diligence, you study, you interview, you plan, and you come up with the event outline to present. You do so with the following highlights:

• You will highlight your most profitable products.
• You will have a speaker encouraging the purchase of these products by none other than Lebron James, NBA MVP!
• You recommend commercials leading up to the event.
• You recommend kiosks demo'ing the products for consumers to see.

Your VP is impressed with your work, but there's one major problem. You focused on the customer, when the purpose of the event was to inspire and galvanize your partners. And this is to be an annual event which should feature benefits to the partners for selling your products.

Granted, this example is a bit far-fetched and simplistic. You certainly would have been given more information (one would hope). But, let's assume it played out like this.

Your due diligence was missing one magic question. Why? Why would have revealed the TRUE "what". It would have revealed the PATH to "how". Why provides direction, clarity, and depth.

The "Geek Discussion" below will provide a more real world example that I think everyone can relate to and believe would occur.

Geek Discussion

OK, you coders have waited long enough. I know you're frothing just waiting for some scenario to begin designing a code solution to. I promised you a coding example of what you might encounter. But, this will work for you non-coders too. Try this requirement on for size.

Let's tackle this with yet another example. You have been asked to create a Web service that will create Cases for a customer (Microsoft) upon demand, and another one that will Get Case information for them. They want standard case assignment and they want this to be accessible from a third-party rather than directly against your service for a number of reasons.

Great! You have a good understanding of the requirements for a case. Agreements, Entitlements, the Organization ID for Microsoft, etc. You even know how an API publishing service such as APIGEE works. So you provide a level of effort of four weeks (there's coordination with the API publishing and details around case creation to deal with) and set to your task.

After 3 weeks, you feel pretty confident and you set a meeting to show them what you've developed below:

• Microsoft can call the service for their Organization ID without providing it.
• All field necessary are configured to be returned in the GET Case call.
• Likewise, all fields necessary to create a Case are included in the Create Case call.
• All fields are documented so that the customer knows what to send and receive.

Unfortunately, they state that this won't work at all.

• It only takes the corporate Organization ID for Microsoft into account. They need to allow all Microsoft locations that have an Asset be able to submit.
• This isn't just for Microsoft. Other Enterprise level customers will be brought in as time goes on.
• Each customer will have fields that are specific to them that will need to be supported when Getting a case.
• New fields for Cases are expected to be able to be supported through configuration rather than a new API each time so that customers don't need to regression test every time.

Ouch! How could you have been so far off the mark? Simple, you didn't ask "why". You needed to find out the ultimate vision for the service. What does Utopia look like? "Why" would help you get there.

Now, with your newfound clarity, you set upon a more generic service. After another four weeks, this is your new solution.

• Each corporation will get their own ID to call the service. However, you will configure the specific Organization ID's for them under a header ID so that all are eligible to be used.
• Each corporation will have fields as configuration data external to the service so that the service will read them and adjust the Create and Get Case accordingly.
• Required fields and supported fields for Create will likewise be configured so that they too can be supported with new fields in the future.
• You configure the service using Key/Value pairs rather than hard-code the fields in the request and response.

Ah! Much cleaner! It fills the needs of the service and more. It's generic, it's adapting, and best of all, it meets the needs of the future vision. Simply because of "why".

Closing

As you can see, a simple question of "why" can bring about some truly clarifying answers. Answers that not only allow you to bridge the gap between "How the Project Manager understood it" and "What the customer really needed", but also to avoid the dreaded Technical Debt and create some real synergy and dialog between the customer and those delivering the solutions.

In short, the "Why" helps provide depth and context to the "what" and the "how". It is the contact lens of problem-solving. When you know the "why", you can often infer the "what" and the "how".

I hope this creates some thought into the serious questions and ways you can begin to bridge that gap and become part of the solution instead of sometimes a barrier.