Defining a 'real' IT solution

Here's a day-to-day scenario to ponder: So, business wants a 'live health monitoring' of one of the products, and contacts IT for a solution. The product manager or someone from business side quickly drafts an email with "what they want" and shoots it off to the IT director. An architect or engineer is assigned to device a solution, and an email with a solution proposal goes back to business. A quick review is done if all requirements in the original email are met, funds are transferred, and the solution engineered and delivered.

Couple of months pass, and business wants the past couple of months' data from the live monitoring solution, but could not figure out how to get it from the system, and shoots off an email to IT on instructions. IT responds back informing that historic data isn't available in the 'live health monitoring' solution. Business is furious: "What!? The solution you provided does not capture historical data?" IT responds  with the original email requirement attached: "PFA original requirements form you - you never asked for historical data - you just wanted 'live' monitoring". Business is even furious: "You morons! Any 1st grader knows that captured data would be stored somewhere. Historical data storage is automatically implied in the monitoring requirements". IT is even more furious: "You ignoramus imbeciles ! Do you have any idea of the data storage requirements arising out of your 'automatic implication'?? You should have asked your 1st grader about it before you wrote your requirements. Your 'automatic implication' translates to a database server on its own for historical data capture, as against the transient live data requirements that you asked for"...

... and the email thread continued for miles... it paused for a day or two in-between, as someone who was supposed to respond was out-of-office, and someone else 'did not get time to look into it'. Anyways, you know how this ends, so I need not digress.

There are "solution providers", and then there are solution providers. What differentiates the latter from the former are a few simple things:

1. They never expect that the one who approaches them [the 'troubled'] with a problem can ever state it accurately.


2. They utilize their accumulated wisdom to assist the troubled, to accurately define their problem by asking them a lot of "what if.." and "have you thought about..." and "do you want to..."s.


3. They study the ecosystem of the troubled to device a seamless and immersive solution - one that blends into their landscape, cheaper to engineer and easier to maintain.


4. And, when they send in their solution proposal, they clearly mention what the solution provides, and what it doesn't. They don't skip the 'what it doesn't' so that the troubled knows exactly what they can expect, and throw as many assumptions out of the window.

Sometimes the troubled may even find that what they really need is far far from what they wanted originally - and unless a solution provider aspires to be the latter, they are eagerly planting the seeds to long and ugly email threads - quite unproductive and full of "I'm covering my a**!"