"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."

Saturday, 19 July 2014

Information Management Quote of the Week 19/07/14

Do not quench your inspiration and your imagination; do not become the slave of your model.”

(Vincent Van Gogh)

See also:

Thursday, 17 July 2014

“Stupid is as stupid does...”

How to really learn the lessons of your mistakes, and turn them in to foundations for success

How often do you run a “lessons learned” session after the completion of a project? Good practice would have us carry out such an evaluation following any significant piece of work – and collective learning from previous experiences has got to be a good thing, right? 

Well done you.

Now ask yourself this – how often do you actually apply the learning that was so heart-wrenchingly drawn from the exercise in group suffering and torment that is a “Project”? Or do you put the “lessons learned” document in the project filing cabinet, never to be seen again (and where the lessons will quickly get forgotten)? Not feeling quite so self-satisfied now, hmmm?!

As Forrest Gump put it, “Stupid is as stupid does.” 

If you’re forever repeating the errors of prior experience, then go figure… So here’s my tip if you don’t want to repeat the failures of before.

Don’t do a “Lessons Learned” session at the end of a project.

(Pauses for a moment to allow the gasps of shock and indignation to pass...)

I suggest incorporating a “Long Hard Look” exercise at the start of a project phase as part of project initiation and planning.

These sessions should involve a focussed sub-group comprising of key stakeholders and the project team and will focus on answering three key questions:
  • NEW OPPORTUNITIES: What should we start doing that we currently don’t do?
  • INHIBITORS TO SUCCESS: What are we currently doing that should we stop doing?
  • SUSTAINED SUCCESS: What are we currently doing well that we should keep doing?

You then need to build the learning points from the “Long Hard Look” into your project principles and approach. This will help you to create the manifesto or statement of intent that will drive the overall project team towards as successful outcome. (See also Jim Harris’s excellent article, “Data Governance, Commander’s Intent and Semper Gumby,” for more on this).

Regular “Short Hard Look” health-checks during project progress are also a good way of ensuring that the project remains on track to meet its outcomes…

Sunday, 13 July 2014

"What you should know about" quickie

Not strictly "Information Management." But I thought this "quickie" was worth sharing in the wider context of information sharing and evidence-based decision-making:

Sourced from Facebook. With thanks to Alex MatthewsSciencegasm and IFLScience

The information about all these topics is freely available. Whether you choose to seek it out or not is your choice...


Friday, 11 July 2014

Monday, 7 July 2014

Dispelling the MDM Myth, Part 2

If you don’t want to confuse, be careful of the terminology you use!

Wow! When I posted my article “Dispelling the MDM Myth” last month, it seems like I really opened up a can of worms – mostly in a good way.

While it was easily the most popular blog post I wrote last month (getting nearly double the number of hits that the next most read post received), what became apparent through various group discussion threads on LinkedInis that the “MDM” acronym isn’t nearly as well understood or universally used as I had anticipated. (e.g. here, here, here and here) There were various comments to the effect of “what do you mean by that”, “please stop using unfamiliar terms” and “I don’t understands” going on. (Bear in mind that the groups that I had posted to are all focussed on the practitioners and professionals within the Information Management & Data Governance community, rather than being more general business user groups where I might have expected a higher level of unfamiliarity.)

Lesson for me? Make sure you always do a “Humpty Dumpty” and define your terms whenever you use a piece of jargon, even if you think your audience is totally familiar with the domain! If nothing else, it ensures that you’re all on common ground and discussing the same thing within that topic. e.g. one commenter identified that in certain circles, “MDM” can refer to “Mobile Device Management”.

(Aside: all this also made me wonder whether there is also still confusion when it comes to  terms such as "Business Intelligence" (BI), "Data Warehouse" (DWH), "Customer Relationship Management" (CRM), "Enterprise Architecture", "Cloud Computing", "Big Data" etc.?)

Anyway, with Humpty-Dumptyism in mind, I thought I should clarify my general overview of what I take Master Data Management (MDM) to mean - if nothing else for the sake of disambiguation within my own mind!

  • The term "Master Data Management" (MDM) is a well-documented and accepted phrase within the Information Management & Data Governance arena as a generic catch-all for a wide range of complex and inter-related disciplines affecting the processes, methods, architectures and tools of administering core categories of descriptive and categorising reference data. It is prevalent within the Information and Data Management sector and the acronym is in wide use in our industry. (Web sites such as those by IAIDQ, MIKE2.0 and DAMA are useful to gain a broader understanding). 
  • The originating "golden record" of ANY data record should ideally be managed according to principles of data mastery, and on that basis "Master Data Management" would refer to the disciplines of curating the originating source of all such data, with every other usage of that data becoming an integrated and dependent read-only copy. 
  • However, the term “Master Data Management” in its current common usage focuses on the disciplines of co-ordinating the data values and member records for key sets of "master" reference data (the Product list, the Customer list, the Locations list, etc). These lists of reference data records get re-used as look-up data sets in multiple transactional systems - they are what gives each transaction record it's context and meaning. (In data warehouses and Business Intelligence solutions, the Master Data sets become the member records within the "Dimension" tables, while the transactional records become "Fact" tables.)
  • Unfortunately, very often these "master" data sets don't get co-ordinated terribly well - each transactional system can end up maintaining a local copy of the data, and we end up with inconsistency of the data. This can happen even if the core "enterprise" data model which defines the expected structure of the data is well defined and the metadata structures for all the systems are properly maintained.
  • Coordinating and maintaining the Master Data sets requires specific process and organisational disciplines that are part of the business function, not IT.

I would make the point that the summary of "MDM" that I've offered above reflects how I perceive the term to be in general and pervasive use across the industry and in particular as appropriated by the software vendors. (i.e. the management of common reference & contextual data sets only.) Depending on your point of view, that may be unfortunate, or even "wrong", but it is how things are. 

In that respect, it's not really "my" definition - and anyone who thinks I've got enough influence within the Information Management sector to affect a change to this received usage is A) significantly flattering me and B) delusional!

As I implied in my original post, I think part of the challenge is that the technology vendors will always appropriate any fashionable term and mis-direct it to fit their own particular agenda - which means no standard understanding and we have an Information Management "Tower of Babel" on our hands. Once we go beyond a simplistic and generic understanding of the discipline as a whole, different software and services vendors tend to use such terms to mean subtly different things dependent upon their own purposes and tend to focus on the technology aspects of data management, rather than dealing with the human elements. 

We've seen this with "Business Intelligence", we've seen it with "Big Data", we're now also seeing it with "Data Governance" - which I've seen used to describe anything and everything from ETL mapping tools, metadata repositories, security management software and even just data storage.

In my view, purchasing a software product will (almost) never a panacea end to all your problems - it will be the starting point only. The "80/20" rule applies pretty well - 80% of the effort, cost and general heartache for any successful deployment will relate to "human" elements (organisational, educational, cultural, behavioural, process/procedural) and 20% will be about technology delivery.

In my 20-plus years of doing this schtick, I've encountered very, very few product vendors (and all-too-few services providers) who take this mindset into a project. In the MDM space, the French business Semarchy are one such business, while in the Data Governance area, Collibra seem to be saying many of the right things (which is reflected in Forrester's latest Data Governance market analysis). IBM's Information Management division are now getting there, but it's still patchy. After that, it seems to be tools and features all the way...

If I was to be REALLY cynical (surely not...), then I'd offer that from a project management perspective, it's the human elements that bring almost all the risk, so as someone bidding to implement a solution for a client, the very first thing that you'll want to do is manage your risk by excluding any human factors from your contracted scope. It also means that the "core cost" of a project will appear much lower - which is great if you're trying to get a Business Case past an unsuspecting Executive group, but hopeless when it comes to the reality of getting anything done. Result - project failure.

(See my recent discussion paper on Distributed Data Quality for some alarming statistics on how many information management projects fail to meet expectations):

As an industry, we've collectively bought into this "Emperor's New Clothes" delusion. Clients need to be less naive, vendors need to be more ethical.

So in summary - if you ever come across anyone who does take a "humans first" approach, treasure them and don't let them go!

Key message #1: beware the vendors!

Key message #2: All of us within our industry have a responsibility to contribute to the ongoing education and change process. We do what we can, and we all benefit if we help each other.

I really hope that’s now cleared everything up!

Thursday, 3 July 2014

Information Management Quote of the Week 04/07/14

“Waste is worse than loss… The scope of thrift is limitless.” 

(Thomas Edison)

See also: 

Saturday, 28 June 2014