"An extraordinary thinker and strategist" "Great knowledge and a wealth of experience" "Informative and entertaining as always" "Captivating!" "Very relevant information" "10 out of 7 actually!" "In my over 20 years in the Analytics and Information Management space I believe Alan is the best and most complete practitioner I have worked with" "Surprisingly entertaining..." "Extremely eloquent, knowledgeable and great at joining the topics and themes between presentations" "Informative, dynamic and engaging" "I'd work with Alan even if I didn't enjoy it so much." "The quintessential information and data management practitioner – passionate, evangelistic, experienced, intelligent, and knowledgeable" "The best knowledgeable, enthusiastic and committed problem solver I have ever worked with" "His passion and depth of knowledge in Information Management Strategy and Governance is infectious" "Feed him your most critical strategic challenges. They are his breakfast." "A rare gem - a pleasure to work with."

Thursday, 29 May 2014

The one question that you must never ask!

Information Requirements gathering – without asking about information requirements

Over the years, I’ve tended to find that asking any individual or group the question “What data/information do you want?” gets one of two responses:

“I don’t know.” Or;

“What do you mean by that?”

End of discussion, meeting over, pack up go home, nobody is any the wiser. Result? IT makes up the requirements based on what they think the business should want, the business gets all huffy because IT doesn’t understand what they need, and general disappointment and resentment ensues.

Clearly for Information Management, Business Intelligence and Analytics solutions, this is not a good thing.

So I’ve stopped asking the question. Instead, when doing requirements gathering for an information project, I go through a workshop process that follows the following outline agenda:

Context setting: Why information management / Business Intelligence / Analytics / Data Governance* is generally perceived to be a “good thing”. This is essentially a very quick prĂ©cis of the BI project mandate, and should aim at putting people at ease by answering the question “What exactly are we all doing here?”

(*Delete as appropriate).

Business Function & Process discovery: What do people do in their jobs – functions & tasks? If you can get them to explain why they do those things  - i.e. to what end purpose or outcome - so much the better (though this can be a stretch for many.)

Challenges: what problems or issues do they currently face in their endeavours? What prevents them from succeeding in their jobs? What would they do differently if they had the opportunity to do so?

Opportunities: What is currently good? Existing capabilities (systems, processes, resources) are in place that could be developed further or re-used/re-purposed to help achieve the desired outcomes?

Desired Actions: What should happen next?

As a consultant, I see it as part of my role to inject ideas into the workshop dialogue too, using a couple of question forms specifically designed to provoke a response:

“What would happen if…X”

“Have you thought about…Y”

“Why do you do/want…Z”.

Notice that as the workshop discussion proceeds, the participants will naturally start to explore aspects that relate to later parts of the agenda – this is entirely ok. The agenda is there to provide a framework for the discussion, not a constraint. We want people to open up and spill their guts, not clam up. (Although beware of the “rambler” who just won’t shut up but never gets to the point…)

Notice also that not once have we actively explored the “D” or “I” words. That’s because as you explore the agenda, any information requirements will either naturally fall out of the discussion as it proceed, or else you can infer the information requirements arising based on the other aspects of the discussion.

As the workshop attendees explore the different aspects of the session, you will find that the discussion will touch upon a number of different themes, which you can categorise and capture on-the-fly (I tend to do this on sheets of butchers paper tacked to the walls, so that the findings are shared and visible to all participants.). Comments will typically fall into the following broad categories:
  • Functions: Things that people do as part of doing business.
  • Stakeholders: people who are involved (including helpful people elsewhere in the organisation – follow up with them!)
  • Inhibitors: Things that currently prevent progress (these either become immediate scope-change items if they are show-stoppers for the current initiative, or else they form additional future project opportunities to raise with management)
  • Enablers: Resources to make use of (e.g. data sets that another team hold, which aren’t currently shared)
  • Constraints: non-negotiable” aspects that must be taken into account. (Note: I tend to find that all constraints are actually negotiable and can be overcome if there is enough desire, money and political will.)
  • Considerations: Things to be aware of that may have an influence somewhere along the line.
  • Source systems: places where data comes from
  • Information requirements: The outputs that people really want.
Here’s a (semi) fictitious example:

e.g. ADD: “What does your team do?”

Workshop Victim Participant #1: “Well, we’re trying to reconcile the customer account balances with the individual transactions.”

ADD: And why do you wan to do that?

Workshop Victim Participant #2: “We think there’s a discrepancy in the warehouse stock balances, compared with what’s been shipped to customers. The sales guys keep their own database of customer contracts and orders and Jim’s already given us dump of the data, while finance run the accounts receivables process. But Sally the Accounts Clerk doesn’t let the numbers out under any circumstances, so basically we’re screwed."

  • Functions: Sales Processing, Contract Management, Order Fulfilment, Stock Management, Accounts Receivable.
  • Stakeholders: Warehouse team, Sales team (Jim), Finance team.
  • Inhibitors: Finance don’t collaborate.
  • Enablers: Jim is helpful.
  • Source Systems: Stock System, Customer Database, Order Management, Finance System.
  • Information Requirements: Orders (Quantity & Price by Customer, by Salesman, by Stock Item), Dispatches (Quantity & Price by Customer, by Salesman, by Warehouse Clerk, by Stock Item), Financial Transactions (Value by Customer, by Order Ref)

You will also probably end up with the attendees identifying a number of immediate self-assigned actions arising from the discussion – good ideas that either haven’t occurred to them before or have sat on the “To-Do” list. (Note that all actions should have an agreed Due Date). That’s your workshop “value add” right there….

e.g. Workshop Victim Participant #1: “I could go and speak to the Financial Controller about getting access to the finance data. He’s more amenable to working together than Sally, who just does what she’s told.”
  • ACTION: WP#1: Discuss data access with Fin. Controller by end of week.

Happy information requirements gathering!


In response to a number of recent enquiries including this exchange on LinkedIn, I have prepared an example Data Specification and Information Requirements Framework, including a number of supporting templates. 

The links to download the Framework can be found on my Resources and Downloads page.


  1. Great summary Alan. To add to that. Data profiling can uncover data issues or patterns that become very clear requirements when presented to business. They very quickly agree whether something is a rule or an issue when they can see it in context.

    1. Thanks Gary - totally agree. The same goes, that the DQ Profiling results need to be presented in business terms - sometimes almost without referring to the data...!

  2. Information Week suggests "what should we do with our data" is another bad question:

  3. I've been asked whether I think this approach was suitable for 1-to-1 interviews as well as workshops.

    I think you have to gauge it based on who you're interviewing. In general terms, I've found my suggested agenda to be a pretty good framework for both workshop-style sessions and 1-to-1 interviews. Clearly, if you've got an executive who is familiar with Business Intelligence as a concept, you can rein in on the "what's this all about" bit.

    But in all honesty, I tend to find that many (most?) aren't actually that up-to-speed, and that the level of digital literacy and evidence-based decision-making is generally pretty low. (This point of view borne out by a recent McKinsey analysis: http://blogs.hbr.org/2014/07/boards-still-dont-see-the-value-of-digital/ ).

    We need to be operating on the basis of the *audience's* level of understanding and familiarity, not your own. Plus, attention spans are short, and getting shorter. That means ensuring that we bring everyone with you and assume nothing. It's constant reinforcement, revision and re-education of what BI/Analytics is all about - "sell", not "tell". (Even if that can get pretty wearing at times!) Also, I find that it's sometimes worthwhile covering less ground in one session but ensuring that everyone stays on the same page, rather than racing ahead too quickly and losing people because they're not getting it.

    It's worth noting too that what I'm proposing is a *framework*, not an an agenda - it's an overall set of inter-connected areas to explore during the discussion, rather than a linear step-by-step approach.