One of my favorite aspects of a presentation by Guy Kawasaki I saw a few months ago was the serial entrepreneur's illustration of the generic nature of most mission statements.
His example, from Wendy's:
"Our guiding mission is to deliver superior quality products and services for our customers and communities through leadership, innovation and partnerships."
All too typical of mission statements, it leaves the reader clueless as to what the company actually sells.
While generic can be good in the case of prescription drugs, it just doesn't work for mission statements. Or for business requirements, as Steve Williams of DecisionPath Consulting points out in a B Eye Network article.
Generic business requirements can cripple business intelligence initiatives, says Williams. Squishy statements about "providing a single version of the truth" or "managing data as an organizational asset" aren't likely to win the backing of senior executives or business users.
And BI won't be successful if people don't recognize its value. A lack of buy-in is one of nine "dumb ideas" associated with BI failures mentioned in this CIOUpdate article.
(Business executives) see no reason to get excited about business intelligence absent a more compelling business case and more concrete BI requirements that relate to the things they do, like conduct marketing campaigns, manufacture and ship products, buy raw materials, provide services to customers, and so forth. As a result, they underfund business intelligence, which limits its business impact and thereby justifies their skepticism.
Some companies get hung up on functional requirements or specifications. While it's good to be aware of such desired features as "the system shall enable integration of data from multiple disparate sources" or "the system shall provide the ability to specify organizational hierarchies," Williams says these are now standard capabilities of most commercially available BI tools.
They offer little help in creating BI applications that actually meet users' needs, he says, because they don't address the specific types of business information, analytical techniques or decision support that will be used or even the core business processes that the company hopes to improve.
Some companies list data elements in lieu of business requirements, says Williams. This is even more vague than the aforementioned generic statements or functional requirements. How will the information actually be used, and will it need to be integrated with other data? Who knows?
Not only that, writes Williams, but:
BI capabilities built on top of large stores of unintegrated subject data elements run the risk of spawning inconsistent business intelligence depending on how development teams and/or power users choose to integrate data for their specific purposes.
Just when the article starts to seem a bit discouraging, Williams provides a seven-step list for establishing BI requirements that are driven by the business. He offers a couple of helpful graphics to further illustrate some of the most important parts of the process. For example, when defining what he calls BIOs (business improvement opportunities), you should specify:
Williams' suggestions could certainly help companies gain more from their BI investments in the five areas mentioned as needing improvement by respondents to a recent CIO Insight survey:
His advice seems particularly helpful for items 1, 3 and 4 on the list.