I have had a few examples in the last 15 years where IT have decided that the Business should embark on a Data project or, that they should purchase a new toolset. These projects have been more difficult than normal and prompted me to consider what I had learnt from the experience.
Let’s start by asking “what motivates IT when they take this approach?”. In my experience it often comes from a desire to:
Make the business users more strategic in their thinking and less operational.
Deliver commercial advantages to the business through the provisioning of faster, cleaner, more complete analytics.
Satisfying ITs’ own appetite for new initiatives and the related technologies.
Providing an alternative perspective to expose hidden insights that business users may not have considered.
Future proof the infrastructure and data to cater for future objectives like ‘big data’, realtime data, advanced analytics, etc. The organisation don’t need these things now, but IT is sure they will in the future.
The drivers are of course complex and never as concise as the list above, the goal of this blog is not to question the motivation, instead discusses the nuances, risks and accompanying pitfalls when delivering such a project.
If we look at some of the delivery phases we see the following risks:
Requirements
The project team:
Spend a large amount of time tying to extract requirements from business users who start of being politely disinterested and ultimately become frustrated.
Neglect to speak to the ‘real’ drivers of the project (i.e. IT) as they assume that the business actually wants the project.
Given that IT are driving the project, and the business are being passive, the functionality delivered may miss the target.
Testing
At this point, the business has probably lost interest, after all they have their day jobs to do, so it is easy for them to find a reason not to test a solution that they didn’t really ask for.
If you have persuaded them to test, unless the quality is high, you will feed them opportunities to question the very existence of the project.
Adoption
Now if the project has managed to go live, issues can arise from it:
“We didn’t ask for it and don’t need it.”
“We like the idea, but we just want the data, not the dashboards, analytics, etc.”
“IT thought they knew what we wanted but they don’t.”
To work out if you are dealing with an IT Initiated project, try some of the following:
Ask who is sponsoring the project. It seems obvious but we usually don’t bother. Be aware that even if you are told that “it’s a sales lead project”, you need to read between the lines for the real truth.
If there is a business case, read it. Who authored it? What are the tangible and intangible returns on investment?
Look at the level of participation within the Steering Committee, if the business representatives tend to be missing or passive, alarm bells should be ringing.
Ok, so let’s assume that you’ve got a project that IT are pushing and the business are ambivalent to:
Don’t throw visual trinkets at the business and expect them to be interested beyond the first gasps.
Give them features that provide them a tangible saving in effort, even if it is just a well formed data dump to excel. You can then follow up with the “sexy” deliverables that the project is really offering.
Search for a “change evangelist” from the business who can help with the embedment of the solution and “gets’ what the project goals are.
Make sure you have an IT representative at the requirements work shops. They can:
Help with pregnant pauses when no-one wants to answer your questions about the business issues being solved.
Put there own spin on where they want the project to head.
I am not saying that an IT initiated BI project is a bad idea, it simply means that the project team needs to understands the real driver of the requirements!
