Your BI Project Shouldn’t Be a Lag Activity

There's a school of thought which advocates that Business Intelligence work should lag behind the other pieces of a larger project and that one should never attempt to undertake business intelligence (BI) activities in parallel with the other "core" activities of the project. The line goes something like this: you can't undertake a major project, say the implementation of a new ERP system, and design and implement BI over that system at the same time; the BI components have to happen 6 months or so later, they can't be designed and built as part of the main project because they are dependent on the main project items being in place first. Those espousing this popular line would have us believe that one can't build BI until the system is up and running, there's a good volume of data available and the business users have worked out what reports they really want and need. Anyway, there's no rush - reports and other BI items are only an output after all!

I disagree. Business intelligence items are as much an input as an output. Yes, they draw upon data in the system, but, compliance reports aside, the information they present should be used as part of a decision making process which then causes some course of action to be taken in a larger process. If this isn't the case then I'd argue that the report in question adds no value. It may just as well not be there!

Look at the idea of doing the BI components at a lag behind the main project through another lens. What this is really saying is one of a few things: 

• We don't need the information we'd get from the reports to base decisions upon;

•  We’re happy coming up with and using a range of time consuming workarounds;

• We’ve got a good gut feel for the business. We can get by making guesses for a while; or

•  We can get by not doing some of the things that we used to do before we put this new system in place. This could be anything from something as simple as not providing team managers with trend reports of absenteeism through to things with much more potential for a financial sting in the tail such as not re-forecasting project budgets after the initial baseline as been set.

Also take some time to think about the resultant behaviors that may arise from not having reporting and analytic capability available early in the life of your new system. People in your business need to make choices and they need information to do so. If they can’t get it from BI, from the right channels, then they’ll find and develop a myriad of workarounds in attempts to continue to do their jobs. Wait too long to bring BI to the party and chances are a good number of those workarounds will persist in various pockets throughout your business. 

So I’d suggest a pause for reflection before rushing to adopt the common [BI] scheduling wisdom. Put it in the above terms, mull over it, have the leaders in your business consider it too and then see if there’s still the same appetite to defer that BI work for six months. Yes, bringing the BI work in to the main project isn’t easy, challenges abound, at times it feels like you’re building on shifting sands but the pain of not doing it may be much worse.

Data Governance and the Not So Thirsty Horse

What's that old joke? The one about the deeply religious man caught in his house as flood waters rise around him.  Early in the piece as the waters are only a few feet deep a dingy arrives to take him to safety and he refuses, saying "I'll be fine, the Lord will look after me". Later, as the water rises and forces him to the house's upper story, a bigger boat arrives and those on board implore him to leave his house and come with them. Once again he answers "I'll be fine the Lord will look after me". Some hours later as he is perched dangerously on his roof with water lapping at his feet a helicopter descends and those on board urge him to leave before it is too late. But the man is insistent - "The Lord will look after me, I don't need you to save me". Not long later the waters rise again and the man is swept away to his death. Arriving in Heaven he is confused and, on being granted an audience with God, asks Him "Lord, I put my faith in you. I trusted you. Why didn't you save me?". God looks at him somewhat incredulously and asks "what more did you want? I sent you a dingy, a boat and a helicopter!"

On more than one occasion in my career I've marvelled at how much that joke paralleled what was going on around me. You may have even experienced this yourself at some time - demands coming from all sides, requests for clarity around data meanings, master data rulings, demanding to know why you don't know the ins and outs and business rules of obscure pieces of data that is about to be touched by some project or rather, and complaining because there's not enough documentation and other collateral in place - forcing them to have to spend more effort and dollars inside their project.  If this was indeed all missing then I could understand the consternation, but when a data governance framework exists and the business users understand and acknowledge that they (and not the IT group) steward the data and are the ones with the true knowledge of that data, then I start to bristle a bit. Maybe not the first time, or even the second or third time you walk people through what's available and how to make best use of, and leverage it, but sometime thereafter it's sure to come. I've noticed similar behaviour in other industries across my career, but it does seem to be remarkably pronounced amongst those working in IT.

Often I've put this down to some form of Not Invented Here Syndrome and accepted that some individuals will just not use what is put before them, be it through lack of acceptance, understanding or whatever. I'm sure that the phrase "you can lead a horse to water, but you can't make him drink" has passed my lips on numerous occasions. But lately I've started to think that perhaps this is not the answer. The horse really needs a drink, he just doesn't know the water is good yet! I've written before  about the need for persistence and tenacity when implementing data governance programs. Perhaps this situation offers an opportunity to create greater acceptance of data governance, data stewardship and the like. Meeting those IT folks placing demands on you half way may well work - give them a little of what they are asking for, do a bit of "their" work for them.  Sure, it's re-inventing the wheel to some degree, but nudge them toward what's already in place, shepherd them into the data governance framework and show them (via a few small wins) how they can leverage the data stewards working within it. My initial findings suggest that where those people begin to see that it can make their jobs easier they start to be more accepting of it and begin to use it to augment their other activity and in some cases make it first port of call. Given enough time I'm convinced we can make data governance advocates and champions of at least  some of these people.

I'm keen to hear from you if you've experienced (and leveraged) similar issues as I'm sure I'll encounter many stables full of horses who don't know they're thirsty across the rest of my working life!

Data Governance and the Self Licking Ice Cream

A friend and colleague regularly uses the self licking ice cream phrase to illustrate to the project management team he mentors that projects need to provide value to the enterprise and not just operate in a vacuum. No matter how well those in the project build a system, or how well that project is managed, it's unlikely to be perceived as a useful and successful exercise unless the various stakeholder groups agree that the work was needed and worthwhile. From their point of view all that the project will have achieved is keeping those on the project busy and employed for its duration.

But that can't be said for data governance, can it? Every organization has at least some data quality problems, conflicts around data ownership, data silos preventing leveraging the data asset across the business, so therefore every organization could benefit from a data governance program.

That may be true, but I'd still like to bet that many, if not most, data governance programs are seen by many in the organization as self licking ice creams. Ask an exec or senior manager from one of those firms and chances are they'll not see the value of the data governance initiative. If you're heading a data governance program and your execs don't recognise the need for it then, even if you think what you're doing is worthwhile, I've got bad news for you - to others you're licking your own ice cream! It won't matter if you've been making great advances in improving data quality, finally getting the data stewards to work together to understand master data issues, or building understanding across your data landscape and producing mountains of documentation along the way. From the outside you'll just be seen as doing little more than using scarce funds and making a call on their peoples' time for no other reason than to keep yourself in a job.

Of course securing an executive sponsor for the program and working to win wider executive awareness and buy-in will help avoid this scenario. However, this will be difficult to achieve and retain unless you continue to find ways to make your data governance work relevant and demonstrate value that can be seen by key stakeholders in the organization. For me, to do this it's critical to have demand placed on a data governance program. If people in the enterprise don't recognise they have data problems and aren't coming to you to help solve them, then you need to find something tangible for your program to tackle. If you're lucky enough to be facing upcoming system changes with associated data migration then that may be a great driver. If not, then try and find the areas where non trivial amounts of money can be saved due to data problems or look for the issues that keep your execs awake at night because they lack confidence in the data. If you believe that those situations can be helped through data governance then start to work on them, if not keep looking - trying to force them to be data governance issues won't do you much good.

If there's nothing in your organization that you can apply data governance to (and be seen to create value) right now then don't be afraid to let things lie for a while. Pushing ahead on things others don't perceive as valuable may actually torpedo the longer term success of a data governance program. Better to lie low and bide your time rather than have others shut the program (and perhaps your career prospects) down. But, keep your ear to the ground because there will come a time when there will be a big problem facing the organization which data governance could help solve. Be ready to seize the opportunity. If you don't and one of your execs later reads about data governance then being a self licking ice cream will be the least of your worries - you may fall victim to airline magazine syndrome!

Your Data Migration Project is Not a Data Quality Exercise

If I look back across all of the data migration exercises I’ve been involved with one aspect has come up during every single one of them – at some point someone involved with the project will try and seize the opportunity to use the migration as the means by which all past data quality sins will be dealt with and solved.  There was a time when I’d have embraced this idea and tried to incorporate it in to the project plan, on more than one occasion I may have even been the person advancing the idea.

But not any more. That was then, this is now. Looking back over some of the projects which struck problems, one recurring theme seems to have been a push for wide ranging data quality improvements as one of the key deliverables, either as a mid stream addition to, or change of, focus or a key aim from day one.  I’ve reached a conclusion – looking at it now it seems stupidly obvious, self evident if you like, but I suspect it may seen a tad controversial to more than a few people out there:

Data migration exercises are about migrating data. This should be the first and only aim. If you don’t get your data from the old to the new system then you have failed – it’s a simple as that. All of those forecast business benefits that rely upon having data migrated will be reduced, deferred or missed entirely. Don’t even think about using the migration to do anything else, data migration is hard enough without making a conscious choice to try and increase the complexity, cost, timeframe and risk. Don’t do it to yourself!!

I’d suggest only entertaining the concept of improving data quality when it can be shown that the new system can’t and won’t operate successfully with the level of quality of data currently available in the incumbent system. Then, and only then, look to incorporate data quality improvements, but keep them as light as possible. Only improve the data as much as is required to allow the new system to operate. This may seem counterintuitive, even perhaps bordering on delinquency of our duty as data professionals, but step back and look at the bigger picture, the interconnectivity of the data in (and across) systems. The changes you may make to improve a particular aspect of the data in one area may have unforeseen and impacts elsewhere. Sure, data profiling can go some way to help understand the impacts here, but do you really want to be following convoluted lineage trails just to be sure that no nasty surprise side effects crop up? Worse still, much improved data quality in one area of the system will soon be forgotten if whole other areas can’t even get the base data they need to operate due to migration woes.

Now, before all of you data quality folks delete my blog address from your favourites folder, let me reassure you that I’m not saying that we shouldn’t improve data quality. In fact I think that the arrival of a new system and the data migration project that comes with it is a great opportunity to push for funding to improve data quality. We just need to play the long game and look a little further ahead - designing projects to make specific data quality improvements before the data migration even begins. Start selling the benefits of improved data quality well ahead of the migration (months, if not a year or more) and angle the pitch in such a way as to show how these projects will reduce the risk of your company becoming the next data migration horror story headline with huge cost overruns, customer churn and brand damage.

We Don't All Need World's Best Practice

In anything but the smallest of IT departments chances are that at sometime you will need to rely on the efforts of others to design and deliver some project or other, be they internal staff, contract resources brought in-house or a full blown systems integration firm. There’s also a reasonable chance that you may not have managerial authority over those undertaking the work, or perhaps at best a dotted line report to you.  When faced with this scenario most of us will want to exert some degree of control or influence over how the work gets done or, at the very least, we’ll have an approach we’d prefer those charged with performing the work to follow.

One common element I’ve noted amongst many of the people I’ve managed or mentored over my career is an hesitation, or even unwillingness, to commit to paper a set of rules or guidelines which will govern the way in which others conduct their design, development and implementation activities. Often these folks have claimed that this sort of guiding documentation isn’t required, citing reasons including direct supervisory authority over the project team, the ability to exert technical influence in a one on one scenario with key project team members, or that the project team is experienced and skilled enough that such governance is not required. To my way of thinking none of these reasons really holds water. Even if you are able to direct or influence the behavior of the project team, to tackle this in an ad-hoc fashion is ineffective, not fair on the project team (it’s hard to work within given constraints when those constraints are only trickle fed to you and often only arrive at a review stage) and often this direction falls by the wayside as project pressures heat up (if it ever actually occurs at all). Leaving things ungoverned is also a risky proposition – there are many ways to skin a cat – and there is no guarantee that the approach taken by the project team (no matter how good or effective it may be) will result activities or outputs which mesh well with your existing team, processes, procedures or landscape. Failure to govern, guide and set some ground rules can, and usually will, result in project outcomes which are not as good as they could otherwise have been.

I have another theory as to why people are reluctant to commit such ground rules to paper – fear! It’s a natural reaction when you’re dealing with the unknown. Other than a paper CV and perhaps a few preliminary meetings you have little real idea of the depth of experience and skills of the “outsiders” you will be working with. Concern creeps in: “will they know so much more than me” and “will I look stupid alongside them or in their eyes” are just two of the things those little voices in your head might start to whisper to you. I can recall these feelings in the past even the project lay squarely in an area in which I had deep expertise. Imagine how uncomfortable a person already a little uncertain of his or her skill and experience in an area might feel! Alongside the fear comes overwhelm: the feeling that there are just too many things to think about, that it would not be possible to get them all documented without missing at least one or two items. This thought process leads right back to feeding the fear with concerns that omissions from the document will only make the author look even worse in the eyes of his or her management or the new people arriving for the project.

Let me put an idea out there. You don’t need to know more than the people coming into your company, you don’t even need to know the best way to tackle a certain technology problem or the ins and outs of the latest development techniques or what domain thought leaders are debating amongst themselves. There is no need to commit to documenting world’s best practice, nor to hold your project resources to that standard. Good practice will be fine for the vast majority of situations. But how do you even know what good practice is? And how do you make sure that you cover all of the big-ticket items? Knowing everything that is important to think about can be daunting.

I favour tackling this with something I call the Bad Outcomes approach. Rather than trying to think of everything that needs to be done in a certain way or toward a certain approach, simply make a list of the bad outcomes that could result from the upcoming project. Start with the really big ones; the things that might cost your company at the high end of the scale, whether it be financially or in other less direct ways such as reputation or brand damage, or even worse could cost you your job. Once you have those down move on to the layer below, those bad outcomes which may not be as catastrophic but are still likely to cause a prolonger period of discomfort. Mull on these items for a few days; discuss them with colleagues, both from within the IT function and from the business, adding any new items that might come up. Revisit your list and drop any items which would only cause minimal impact or short term pain and with luck you’ll have a relatively short list of the outcomes that you need to govern against. As an example, the last time I went though this exercise I ended up with only eleven items for a project likely to be worth multiple tens of millions of dollars. Now you’ll have focus – you’ll know what to work on that’s really important. It won’t matter if you don’t use the World’s Best Practice approach to govern and guide each item, so long as you find a way which is likely to avoid the outcome then you’ll have what you need and you’ll likely have saved your company a pretty penny in avoided costs and perhaps even your job along the way.

The next time you’re faced with the need to craft a strategy or pen a set of standards or guidelines don’t worry about what you don’t know. Remember, no-one will know all there is to know about a subject, so accept that you won’t always know the best way to solve a problem or everything there is to think about, but I’m pretty sure you, like me, have your scars and war stories so you’ll know what you want to avoid, so start there. Good luck!

Technology Leadership - A Misnomer?

If you've had a career of any reasonable length in the IT industry and have a track record of success behind you then chances are you're now in, or at some future point will be offered, a role which is considered a Technology Leadership role. In the data and information space these types of roles include Architects, Business Intelligence Managers, Competency Centre Leaders, Data Quality Managers and the like.

I've worked in many of these roles at various times and the one thing that they all have in common is that often this so called technology leadership is actually dealing with issues that have little to directly do with the technology at all. Rather the Technology Leader spends his days strategy setting, looking for ways to deliver business value through future change or the current actions of his people, engaged in stakeholder management, selling concepts to senior management, and so on. Most of these issues are actually more closely aligned with managing functions, people, shaping programs of work, etc and require some ability to control and direct and have access to, and authority over, budget and resourcing decisions. Without this the leadership may become divorced from the ability to deliver which can have serious ramifications on credibility, influence and ability to show effect and value from the leadership role. Perhaps it could even be argued that people in such roles are shouldering, and in some cases having to own, some of the concerns traditionally associated with line management without having enough say in solving those problems - i.e. their plans could be quashed, derailed or rerouted by others who do have control over budget, resourcing or strategy.

In order to allow our technology leaders to add the most value we need to realise and acknowledge their leadership is in fact only in part technology based. Our technology leaders need a seat at the management table to be truly effective. Taking this step delivers another benefit. Technology Leaders are in the decision loop early, ensuring better alignment with other initiatives and allowing others in the management structure better visibility of, consideration of, and therefore use of the area from which the "technology" leader comes.

The alternative to this arrangement is the introduction of Thought Leadership roles. These may well be ideal positions for the person formerly known as Technology Leader if the organization can stretch to that. However most can't due to lack of size, true need, commoditisation of many facets of the IT function, or shrinking budgets. The unkind (or is that better phrased as jealous?) spin on these roles might well be lots of thinking, musing and sprouting of opinion without the need for implementation efforts hampered by real world constraints and politics. Hey Gartner - if you're ever looking, I'm over here :)

Data Ownership and Data Responsibility Should Go Hand in Hand

Chances are that all of us who have tried to advance a Data Governance initiative will have had the data ownership discussion and socialized the idea that IT shouldn't own the data. In the earlier years of my data governance efforts getting acceptance of this concept was most often the first stumbling block. Common remarks from both the business and IT fronts reflected long established culture and practices in which data was seen as an IT focus - they managed it, wrangled it, invested and got to the root cause of data problems, and they held the responsibility of fixing data problems. This resistance, although frustrating, at least had a common theme which allowed me (and I suspect others like me) to build up a toolkit of arguments, presentations, stories and case studies to help move stakeholders toward an understanding that data is best owned by the business and not the IT function.

I've written about the need to keep working away toward implementing data governance before in my post on Thinking Like a Vogon. Having a bag of tricks built up and finessed over time is, in my opinion, key to successfully importing data governance at an organization. It allows those of us charged with championing data governance to keep working toward advancing stakeholder understanding and buy-in over weeks, months and years. Recently I've noticed a trend which has the potential to poke a hole in this bag of tricks, reducing its effectiveness and necessitating a rethink of how I engage with stakeholders. These days I encounter less push back when I propose the idea that IT doesn't own the data. The concept that the business owns the data now often seems to be easily accepted, with some business users going as far as saying "of course we own the data!"

Acceptance! It's all easy from here, right? Maybe not. While there seems to be a lot more widespread agreement that business users own the data this doesn't always translate into the best outcomes for data governance and improved data quality. Statements from stakeholders along the lines of "we own the data, but IT let us down because they can't get the data quality right and they don't understand our data" ring alarm bells for me. That one step forward may just have been followed by two quick steps back. What's missing here is responsibility. Ownership without responsibility is hollow and reflects an understanding which still has quite some way to go to reach maturity. I liken this sort of statement to a father boasting about the achievements of his children before reaching for the phone to arrange a nanny to look after them whilst they are home from boarding school. Just like we can't expect school teachers and others to take sole responsibility for shaping our childrens' lives and helping them through their problem times, business users can not claim to be data owners and then take a passive role only getting involved in data issues long enough to point the finger of blame at IT.

So how can we this new phenomenon be dealt with? Sure, a part of what needs to be done is updating the message and tailoring the tools and communication methods we use to address this new position. But, it's more than that, as data governance professionals we need to look for ways of showing those in the business with this view "what's in it for them". We should look to find success stories - show where there was demonstrable benefit gained when another business user started to take an active interest in the health and well being of their data. Even better, we should spend time with those business users who have already embraced not just data ownership but data responsibility as well, helping to make them into champions for the cause and assisting them to sell the benefits to their colleagues. The broader IT function also has a role to play here. We need to ensure that IT doesn't reinforce the existing culture, and as such there needs to be a little gentle push back when the business shows signs of pushing all data responsibility to IT. This need not mean a flat out "no", nor an abdication of any and all responsibility, but rather taking these opportunities to engage with business users, working with them as enablers rather just than in isolation as technical troubleshooters blindly trying to solve problems often without enough context or knowledge. By working together - making changes on both sides - IT will boost data context familiarity and those on the business side will get involved more often and earlier. From a management perspective, look to change IT policies if they talk about IT owning and managing the data, and think about establishing data reference groups.

No matter what approaches we take, there is one very important thing that can not be forgotten. We must help business people in their new roles as data stewards. We can not leave them to feel their way along. Build documentation and tools to help and guide them, recognise new responsibilities by modifying Position Descriptions and the way these people are measured and rewarded for performance. Not only will this signal that the organisation is serious about data governance and data quality, but it will also guide and encourage the stewards to perform better.

Data Migration: Don't Ask What Should I Take, Ask What Can I Leave Behind?

I've written before about the importance of Selling the Data Migration Strategy and getting senior management buy-in. Recently I've been engaged in that sales job within my own organisation and just the other day met some resistance. On past projects disagreements around my strategic intent often took the form of objecting to my position that migration is an activity that should be front and centre for the business with them, rather than the IT or IS function, having accountability for its success. However, that wasn't the case this time, instead the contentious issue was that the strategy I'd written didn't explicitly call out the we should only migrate the minimum amount of data.

From my point of view this isn't something that belongs in an Enterprise Data Migration Strategy. It's not that I don't think that keeping the volume of data to be migrated down has merit. I don't need convincing that involving more data increases the cost and heightens the risks of overruns or impacts outside of the organisation's walls but, even more importantly, I don't think it's my place to be mandating a minimum data approach in a blanket fashion. For me, each of our data migrations will have different needs, different profiles and different levels of data to be migrated. And let's not forget that it's the business, not the technical staff, who should be making the calls about how much data to migrate!

This discussion got me thinking. There is value in keeping migration data volumes low so how could I, through the strategy, encourage this behaviour without presupposing it was the right course of action for each migration project? After some thinking I've landed on updating the data migration strategy to include a new principle:

Migrate the appropriate level of data. 

Expanding this a little, I see two key points that should be considered in finding this appropriate level of data.

• Firstly, a default position of migrating all available data is not where we should start. 
• Secondly, and following on from this, don't just ask the question "how much data do we need to migrate", but instead try the question "how much data can we afford not to migrate - what data can we leave behind?" 

With this question as the starting point I think there is a way of ticking all the boxes: the appropriate amount of data is migrated, the data migration volume is kept as low as possible, and IT doesn't drive how much data is migrated - the business still gets to make this decision.

The unanswered question here is how does the business decide on the appropriate level of data? I've used various techniques to help in the past and I've some new ideas as well, but that's a discussion I'll leave for another blog post.

Big Data: Are We Really Ready for the Final Frontier?

I've just read an excellent post from Rich Murdane entitled "Big Data" and the Failure to Communicate. I'm glad Rich penned this piece as I was beginning to think I was either alone with my position and thoughts or, worse still, just missing the point! Rich has managed to nicely put into words a feeling that has been gradually building with me. For a few months now I've had a growing sense of disquiet that "big data" was becoming a buzz word - a phrase that was on everybody's lips but often with little substance behind it. That is, folks are talking about it because they feel they should be talking about it, but in reality they (and we as the broader industry) have not yet taken the time (or perhaps more kindly, had the time) to really think through what big data is and more importantly what it means to each of us and what  value it might deliver to our organisations.

I fear there is a real chance that much money will be spent too early as folks jump on the big data bandwagon before they they really have a good handle on which part of big data they should be focusing on. If we look at what "Big Data" is then a number of things spring to mind. For me the the obvious one is condition monitoring data - generally structured time series data. It's not just the size of this data that makes it big, it's how fast it arrives - what's beginning to be more commonly talked about as the velocity of data.

For me, and the big data problems I'm likely to face in my industry, I think this may well be the key issue at least in the short term. Operational technology is prevalent and in some cases this could mean thousands of data points arriving per second - huge waves of data washing in. One of the questions that I think needs to be considered is how high velocity big data should be used, or perhaps how the best value can be derived. Quite a bit of the discussion I'm hearing and reading suggests that this question is not being asked, but rather there's a leap of faith being taken resulting in a default position that this data needs to be stored and analyzed. I agree that over time this might well be the case, but for many right now I wonder if this value proposition is understood well enough to be effective. Perhaps it might be wiser to wait and look at other ways to gain value from this style of big data, one of which might be a form of complex event processing to monitor the stream of data and pluck out those events or short term trends which allow an action to be taken to materially impact operations. Those of us without a compelling business case to store, and later interpret across, huge data volumes might be best to wait and watch, taking action not because we feel that we should be, but because we understand what the value is and how we will unlock it.

This watch, monitor and wait brief should be wide enough to make sure that all forms of big data that might deliver value are considered. This means that it's not just the structured data area that is important, unstructured data is perhaps even bigger. For many of us with long pedigrees in the data space this may be somewhat of a new and unfamiliar area. I think we have no choice but to step outside of our comfort zones and become more familiar with this space. Much of the short to medium term value to be derived from big data, in my opinion, will come from this area for many industries. Sentiment analysis and mining of data from social networks is a great example of this which is already becoming important for many organizations. It's also an example where a stream of data can be monitored for data if interest as well as gaining value from analysis across larger pieces of historical data.

Big data is here to stay. It's not a matter of if it will impact your company, but now only a matter of when. You'll have to jump in and ride the wave at some time, just be sure you don't jump into too soon. Make sure you haven't worn out your funding and senior management support, will and trust before there is a real opportunity for you to harvest value from big data. Big Data may or may not be the final frontier. I could borrow from Star Trek, but I'd rather borrow from 1980s one hit wonder Star Trekkin'. It's Data Jim, but not as we know it. Good luck in your explorations, but be careful. There may not be Klingons on your starboard bow, but there is almost certain to be an executive or two asking the hard questions if his money disappears into a black hole with no value return.

Rethinking Your EIM Program

I've not looked at a Gartner Hype Cycle in a while, but I'm pretty sure if I did I'd find Enterprise Information Management (EIM) Programs heading into the Trough of Disillusionment. From what I'm hearing these programs are doing it tough and its not surprising.  EIM aims and value can be hard to articulate, I know I've struggled at times with ours . If you have an EIM program what's your elevator pitch? Phrases like improved decision making, better data management, and leveraging the data asset abound but chances are that many decision makers are coming to see those as little more than motherhood statements, particularly if there's been an EIM program in place for a while with few real benefits yet realised.  Although there may have been initial agreement around the problems to be solved and excitement around the promise of the program your sponsors may no longer really be signed up for the journey and are probably now struggling to see the way there.  


Perhaps it's time to rethink the strategy we take toward reaching our EIM goals. Rather than one big program maybe the use of strategic themes might work better. Use themes to chunk your nebulous program down to smaller quick projects which deliver toward and enable a common theme and focus the efforts and imaginations of people around a few key areas and projects at a time. It's easier for people to see value along the way yet (if you keep your eye on the longer tern prize and larger goals) still possible to get to the bigger picture by drawing synergies from projects along the way. Some of the themes I'm promoting right now include making information findable and believable, and the use of templates to tie information and process together and allow nimble reuse when new business initiatives arise. 


Using strategic themes also means it's much easier for people to "get it" and you, as the architect of the broader EIM initiative, will have better control over how they perceive what's important to do next. Equally importantly you'll have a better chance that they won't "get the wrong end of the stick" and become focused on the wrong things and put their energy into work that really delivers little to advance your true EIM aims.  Another plus is that it's more likely that you'll have people wanting to get involved (and hence get better people) if they can see what is going to be delivered in the smaller projects within the theme. 


If your team structure allows it then look to embed account managers in to the various business areas to get early signals and information about what needs are out there and weave these into the strategic theme sets where appropriate. Doing so will get people on the train.  Let the inertia build and then use that inertia to drive through those pieces of work which are less tangible - whether they be advancing data stewardship, building out the enterprise data model, or something else.


I believe this chunking and strategic themes approach will become more important across the coming 12 -24 months,  particularly if your company places more stock in initiatives with strong business cases and has an over representation of business improvement projects among the successfully funded initiatives and pushes those with less obvious or quantifiable benefits to the back of the queue. This approach will also give you the flexibility to be nimble and stay aligned with business strategies and priorities as they change rather than locking you in to a full year's budget cycle many months before the first work even begins. 


With this approach there are bound to be trade offs but, hey, at least you're moving forward and making (some) progress toward your EIM goals. And that's got to be better than the program being killed entirely.