Solution Requirements Mismatch

Impedance Mismatch is an issue occuring in mismatching database types of different paradigms (e.g. object-oriented vs. relational). They may conceptually contain the same information, but their way of representing the data (model) does not relate well between the different database types . 

A similar effect can be observed in business settings, during requirements management for business intelligence solutions.

1. Let's say a business customer communicates some functional requirements to a B.I. solution provider. Whether that's an internal developer, or an external vendor doesn't matter in this context.
2. And let's say the B.I. solution provider can confirm the requirements and make a proposal about the planned solution.
3. Both parties agree to move forward with a project, purchase, or consulting engagement.

When all is implemented and ready for use, the business customer realized that the provided solution doesn't do what it should. 

What happened?   Most likely...

• the business customer expressed their wants, and not the business' actual needs, or should have
• the solution provider confirmed what he can or wants to deliver, not what should be delivered.

Cynics will encounter this conclusion, which strangely is often very apparent, with "hindsight is always 20/20", or "shoulda-woulda-coulda".

But wait a minute, wasn't learning one of the key aspects of intelligence? If these patterns are apparent, why not learn from them, apply them with each initiative moving forward?

So let's examine the above scenarios a bit closer:

Why do business customers often ask for requirements about what they want, instead of what the business needs?

• "If everything you have is a hammer, every problem will become a nail" 
• Over-simplification of the actual challenge to be addressed with a requested solution.
• Lack of understanding of the constraints of tools, existing solutions ("silver bullet" syndrome) 
• Rush, no time to think, so decisions are made impulsively, or by instinct, instead of rational analysis

Why do solution providers commit to delivering requirements that the customer actually needs, but instead of go by what the provider is able to deliver, or is interested in delivering?

• Sales-driven: eagerness to please customer (catering to broad desire for instant gratification)
• Competitive pressures: no time to explore details of the requirements, the competition might snatch up the contract instead
• Focus on Profits: lack of selectivity whether provider actually is able to delivery solution, since they don't want to miss out on the opportunity of doing business. Unfortunately the lack of capability/willingness to grow into a promised deliver is often not honestly communicated to the customer (which often results in the over-promised/under-delivered effect, when providers confused their capability with their motivation of "we can do it!")
• Cultural factors, professional image/pride: the right thing to do would often be to advise a customer that what they require is not what they really need. But in our business culture it is rarely appreciated to push back on customers, and say no to setups that have low chance of success. The customer/provider relationship is often one subliminally serving social validation, more so than pragmatic business conducting. This dynamic affects the compatibility of agreedupon requirements vs. actual solution need. 

In summary, the above phenomena can be expressed in four scenarios:

• lacks willingness & lacks understanding
 (willingness might have potential if understanding is addressed; see scenario 3)
• lacks willingness, but understands (abandon all ye hope, a.k.a. "politics")
• is willing, but not understanding (needs consulting)
• is willing, and understanding (perfect setup for success!)

More on requirements analysis here.