Don’t Get Seduced by the BI Development Honeymoon Period
BI development

Written by: Jon Stafford

I have over 13 years experience in creating effective BI that turns data into insight and value. I’ve worked in many industries, combining my extensive business knowledge and background in solution development to deliver successful BI strategies, solutions, training and coaching.
Don’t Get Seduced by the BI Development Honeymoon Period

We all know about ‘honeymoon periods’ – those times when everything is going wonderfully and we don’t have a care or worry in the world. They happen at the start of something new, whilst the novelty is still there, and any negative aspects have yet to make themselves known.

Projects can have their honeymoon periods too, particularly if they’re based around a waterfall delivery. And, if they’re BI development and projects, particularly if they start with long delivery phases like ‘restructure all our data into a new enterprise data warehouse’ or ‘spend six months developing a new BI strategy’.

Worse still, these honeymoon periods are seductive. Who doesn’t want to feel safe, happy and secure in the knowledge that everything’s going just fine? What could be better than being halfway through a 12-month project, not too busy, with plenty of time still left to do everything and with the project reliably reporting green every week?

But there’s a problem with honeymoon periods – they come to an end.

In everyday life that’s OK (expected even) – people just move forward and get on with it. But when a BI project’s honeymoon period ends, it’s often not an expected, business-as-usual situation. Things change unexpectedly, and not for the better:

  • Projects go from green to red, remedial action starts, as do late nights and stress.
  • If the issue is to do with mistakenly believing that your testing was covering everything, then you have lots of unhappy users raising lots of support issues, losing trust and confidence in what you’ve delivered, and certainly not gaining any value from their new BI.
  • If it’s the BI development requirements you mistakenly thought were right, but that you then found out were wrong x months later when you first showed something to your users,  then it’s even worse – trying to cobble together some reporting and analysis that half satisfies people without too unreasonable a delay and without too much extra cost.

Worse still, the causes of why projects get seduced into honeymoon periods aren’t going to go away any time soon, because they’re rooted in human nature. It’s only natural to report a project is going well (despite those niggling doubts that everyone’s just reporting progress as a subjective percentage complete). It’s only natural to assume that a little bit of testing on a small amount of well-behaved data is going to be enough. It’s only natural to assume that requirements are captured accurately and that everyone knows perfectly well what the users want without ever needing to go back and ask them.

The Answer

Happily, there are a few ways you can stop your BI projects being seduced into that ultimately destructive honeymoon period.

Firstly, if you can, move to an agile delivery methodology. This avoids the lengthy delivery phases that are a prime cause of honeymoon periods. You’re only ever a few weeks away from delivery at the most, progress towards that delivery is measured on a daily basis, and the users are involved throughout both with shaping and with testing. You’re much more likely to deliver something that works and gives them what they need.

If you can’t move to agile, then recognise the causes of honeymoon periods and make sure they don’t happen:

  • Break tasks into smaller chunks, measure their progress objectively where you can, and report that progress honestly. There’s no shame in reporting a project as amber, or even red, as long as you know what to do to return it to green. This is certainly better than misplaced optimism (those ‘green, green, green, green, red, delivered late’ projects that we’re all familiar with).
  • Introduce checkpoints and regular review into long activities that you can’t break down. Regular peer reviews keep people focused and honest, and, when done right (a collaborative culture rather than a blame culture) create a way of working that results in better delivery from everyone.
  • Recognise that BI development requirements gathering and testing require specialist skills, just like development does. Keep in mind that you don’t find out whether your requirements were gathered properly, or whether your testing was adequate, until the users see what you’ve delivered. This can be months down the line, at the end of the project when it’s too late to do the right things to fix it. So make sure the people doing these activities are specialists that will do them properly, and make sure it’s not too long before you confirm that they have been done right (remember agile delivery and small chunks).

With awareness, forethought and planning, and by taking the right approach to your BI projects (and others) you’ll find you can avoid seductive honeymoon periods altogether, and instead go straight to the long-lasting satisfaction of successful delivery.

For more insights like this check out our blogs here!

Alternatively, if you would like to speak to one of our dedicated consultants about your BI development and projects book here for a free discussion with no obligation!

You may also like…

This Is Data-Driven Genius

This Is Data-Driven Genius

KPIs and why a fuel-gauge is data-driven genius. While driving you take a quick glance down to your dashboard and...

1 Comment

  1. zvodretiluret

    I like this weblog so much, saved to bookmarks. “Respect for the fragility and importance of an individual life is still the mark of an educated man.” by Norman Cousins.


Submit a Comment

Your email address will not be published. Required fields are marked *