Guest blog by Jon Pugh, DataBank IMX
“A Problem Well-Defined is Half-Solved”
Consider this scene:
A patient walks into his doctor’s office and says, “I just saw a commercial for Amazilor and I’d like to try it. It may be right for me.”
The doctor answers back, “Let’s talk about that. Why do you think you need Amazilor?”
“Well, first off, ‘amaze’ is right there in the name! And sometimes, I get nervous on airplanes.”
The two continue this way for a short while before the doctor hands over a prescription for Superynol. Superynol shows a higher success rate than Amazilor without such annoying side effects as Dancing Frenchman Syndrome or sudden total weight loss. Besides, Amazilor is for patients of considerably smaller size and only works if you’re left-handed.
Let’s imagine a world where doctors didn’t dig any deeper than the patient’s initial request. Patients, untrained in the medical field and unfamiliar with the specifics of a particular product or the product landscape as a whole, could self-diagnose and self-prescribe. Irresponsibly applied, the treatment could present a number of possible outcomes:
- The treatment has no effect
- The treatment intensifies the original problem
- The treatment solves the original problem but creates another one (and the treatment for THAT problem creates yet another)
- The treatment works (the patient lucked out)
What if, instead of the scene described above, it’s a company executive who just walked into your office and told you that he or she needs a new business application that’s going to manage millions in invoices or handle every piece of sensitive client data in your customer base? Again – we have a need and a lead on a solution, except this one comes with added constraints: thousands of stakeholders, a due date and a budget. And, it must account for all of your stakeholders’ needs within that date and that budget. But, who are the real stakeholders and what are their needs? And what if they have unclear objectives and competing priorities? What if no one can agree on what the real issue is?
The investigation that allowed the aforementioned doctor to find the right medication is akin to the discovery process that any good information technology vendor follows in order to design the correct business application for its customers. Discovery is a critical first step in solution delivery because it protects everyone from the unnecessary costs associated with redoing a solution that didn’t solve the business problem or simply started an unending string of new and different issues throughout testing.
Before starting any large project, it’s crucial to understand the importance of a thorough discovery to mitigate your risk and ensure that the project is successful. In this series, we’ll be covering the most common and (in many cases) the most contentious issues clients bring to us when wrestling with the discovery and design phase.
To start, let me know if you or someone you know has ever said any of the following:
| On the relationship between sales and services… | Didn’t we just go through all of this with the last guy? |
| On preparing for discovery… | No, no – we’ve already covered the requirements ourselves. Look, here’s our flowchart. |
| On budgeting for discovery… | It’s going to take HOW long? That’s like one-third of the project! |
| On designing at the table… | We just need a [button/script/scheduler] that… |
| On discovery logistics… | Ok, so your guys will just like, follow us around for a day and see what we do? That sort of thing? |
If you’ve ever had difficulty understanding some of the finer points in any of these topics, I look forward to addressing them in future articles as you join me on [insert bold music and backdrop of the Milky Way] THE ROAD TO DISCOVERY!
