Anatomy of an Analysis Session: Reloaded

Originally posted on May 10 2011

My friend Mark Stacey wrote an interesting post on how to run an analysis session. Actually I try to work in the same way and I totally agree with his points. He correctly describes a number of best practices to adhere to when a BI project takes off.
Why I say “I try to work in the same way”? Because, sometimes, projects start with such constraints that  applying a correct methodology is a challenge itself. I just try to lay down few cases I encountered in my career and I suggest a way out.

The project was sold upon a new, exciting technology

Modern BI tools, as I said many times, are truly spectacular. An inexperienced audience can be easily mislead toward the playful side and do not award the contract upon a balanced analysis.
In this case the expectation bar will be set very high on interactivity and there’s going to be little patience for things like data quality, data matching or hardware requirements.In this case the project is doomed to underdeliver and there’s little that can be done. I’d try to set up, as quickly as possible, a small environment where the decision maker can amuse themselves. Than start the real project.

The project was sold upon a wrong C-level assumption

Sometimes the C-level segment of the company awards a project to fix a non existing issue. In other words, they expect to get some results but the project outcome is different. They expect to get some figures but the actual result is totally different. This is not a terrible situation, though you have to earn the users’ confidence for the system. Bringing in sound data and analysis can make the brass slowly change her mind. This case can still be turned into a good project.

The project was started with a hidden agenda

Some projects are born just to backstab someone. They exist in order to provide figures that will doom someone to the flames of hell. This is not openly stated, of course, but somehow you soon become aware that “that group is the enemy”. If you do not comply, you risk to be fired and not paid for your work. So, probably the best thing to do is to place under scrutiny the “enemy”, in order to provide the sponsor with plenty of data to play with. At the same time, try to make friends as much as possible with the “enemy”. In this way, it will be easier to stay neutral at the final facedown. It is a sad final, but the happy ending is guaranteed only in movies. Of course, if you’re requested to openly falsify data, just quit the project.

The project was sold after something non-existent

Little to do here. If you can build it, than dive nose deep in it. If you can’t build it, and there’s no viable alternative, you will fail.

 

Just to be clear. After reading all these cases, you might have the impression that I just consider all these “original sins” as rather normal, like the rain, something that requires just boots and an umbrella. This is absolutely, positively not the case. These are commercially originated banes, that make everyone else's life much worse.

The only reason to sell a BI project is to fix a problem or to improve efficiency. It must be sold like a project, with realistic expectations attached and in a politically neutral environment. It must be sold like a good project.
If you can’t sell within these boundaries, it is better not to sell at all, because it will backfire somehow.

Selling is too a serious matter to be left in the hands of the sales department!