Explain me your problem, I’ll find a solution.

A recurrent question that I received after a conferences or during a course sounds really simple but is rather complex to answer: How do you write specifications for Business Intelligence solutions? That will be the starting point of this series of four blog posts about specifications, requirements, work-items and test-cases.

A key point is what do you mean by specifications? I tend to agree with this definition from Business Dictionary:

Exact statement of the particular needs to be satisfied, or essential characteristics that a customer requires (in a good, material, method, process, service, system, or work) and which a vendor must deliver. Specifications are written usually in a manner that enables both parties (and/or an independent certifier) to measure the degree of conformance. They are, however, not the same as control limits (which allow fluctuations within a range), and conformance to them does not necessarily mean quality (which is a predictable degree of dependability and uniformity). […]

In a few words, specifications let you measure conformance not quality.

IMHO, they are pointless. Do you really want to open a debate with your customer or stakeholder by the following sentence: “Yes, we’re delivering bullshit but it’s 100% conform to the specifications!”. Personnaly, not. And it’s independent about who is writing the specifications or if they have been validated or not. Who cares? Seriously, will you accept specifications from your plumber? Are you sure to understand 10% of his technical wording? You don’t care about all the documents, you want a good solution. A better way to collaborate: you explain your problem to him and he’ll find and implement a good solution.

You’ve two kind of issues with specifications:

  • They don’t describe the problem but a potential solution. These requirements don’t let some latitude to the business intelligence specialists to design the best models and visualizations. Generally the resulting development is not performant and sub-optimal and overly complex, leading to a solution not accepted by end-users.
  • They do not provide enough specificity to guide development of the BI databases and applications that deliver the BI or to guide the business process changes that deliver the bang for the buck to the business.

For the second kind of specifications, it’s usually easy to explain to your stakeholders that you can’t come to a good solution with generic sentences. But it’s more tricky with the first kind of specifications explained above. They will tell you that the solution is already explained and you just have to implement. From my experience, don’t accept this kind of mission. Explain them that we’re BI professionals, it’s up to us to understand the needs of our customers and to deliver solutions with a high quality. It’s not their responsibility to explain how they would like to solve their own issue.

So if I don’t like specifications, what am I recommending to write? Requirements, Work items and test-cases. But that’s for a few other blog posts starting by this one.

Advertisements

2 comments

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s