The Biggest BI Blunder

Instead, many people with failed projects saw BI as a business initiative or as a financial exercise and ignored decades of best practices of software development life cycle.

 

Jim Collins talked about how great companies put the right people on the right bus going in the right direction.

If you try to run a BI project as something other than a software application development effort, then you are immediately starting off on a bad trip with the wrong people on the wrong vehicle.

 

If you do not understand that your BI initiative is an SDLC project, then you will not follow well-established practices that would improve your chance of success.

You might not even follow basic project management concepts such as the “Magic Triangle” to define the “scope” of what you promise to deliver by what time and at what cost. Experienced SDLC developers understand that in a project you are stuck with three variables that are all interrelated. Changing one impacts the others. 

 

These are: 

For a project, you are stuck within an elastic constraint of these three limits. Individuals who do not understand or ignore these variables will have a failed project.

 

If you need your BI project to be done quickly, then you must add resources (increase cost) and/or reduce what will be delivered (reduce functionality).

 

If you want lots of functionality, then you must push back the deadline and/or add resources (increase your costs).

 

If you need to lower costs, then you have to be willing to eliminate functionality and/or push back the deadline and work with fewer resources. 

 

Experienced SDLC developers also know the difference between the “Big Bang” approach and a phased, iterative roll-out. Failed BI initiatives are those where an influential person gives vague marching orders such as, “I want an enterprise dashboard where everybody in the company can access all data in any way they need to see it and I need to demo it at the annual conference in three months. Oh, and make sure it works on my iPad, Bob’s Android phone, and Sally’s iPhone, and Greg’s BlackBerry.”

Successful SDLC projects understand a phased staffing approach. Not everybody needed the project has to start on Day One. Yet that is a common mistake on failed BI projects.

 

Imagine building a house. On Day One, you have an empty lot and must first dig a hole and pour the foundation. If your custom home builder told the electricians, plumbers, dry-wallers, and painters to come on Day One and just have a seat in lawn chairs to watch and wait for their work to start, you would immediate recognize this was wasting time and money.

 

Yet bringing in GUI developers to sit and wait for the database developers to finish a repository is common on a failed BI project. It just is not as obvious since IT people look more productive sitting in a Herman Miller chair in a cubicle rather than out front on a lawn chair. 

 

Experienced software developers know they will not be successful unless they first have a clear definition of the application they are to build. Successful individuals are able to take a fuzzy idea from the business and work jointly with others to properly define and formally document the specifics of what will be done.

 

The worst BI projects are those where the ideas for the dashboard are in one person’s head. This Person is always frustrated that nobody else on the project is smart enough to understand what she is thinking. Without formally dumping ideas from that person’s head into a well-articulated requirements document, the BI project is doomed. Yet it often happens.

 

Note: read the “Tappers and Listeners” section in the Heath Brothers’ book “Made to Stick” for more on this topic.

 

The first problem of not knowing what you are building is that you will create the wrong thing; your project will fail.

 

There is another problem of not clearly defining what you are building: you will never be done. At some point, the executive paying for the BI project will start to scream about the time and cost. “Why is this BI project taking so long?”

Well, it was never designed with an end goal in mind and as aresult the BI developers are continuously running a marathon on a circular track.

 

If you do not understand that you are running a SDLC project, then you will not employ the right people.

 

If you view this as a business initiative, you will naturally pick people who understand your business. It just seems to make sense to have the guy in Finance who calculates your business metrics to run the BI project. But without a formal SDLC understanding, Bob in Finance is not going to be able to run a successful software project.  

 

Repeatedly, I have a certain type of organizations fail in their BI initiative. These have been those where their IT groups have traditionally done operational support; they do not do SDLC projects. They are great at running the networks and keeping e-mail and packaged applications running, but they are not software developers. 

 

This is not a fault; their IT organization is intentionally designed to provide operational support.

 

When these types of  IT groups get complex BI projects thrust upon them, they typically fail. This is not what they know how to do. They are inexperienced in software development. Yet it does not occur to the executive that he or she is asking for the impossible from these employees. Instead, the project fails and the executive asks, “Why can’t my IT development implement a dashboard?”

 

Business Intelligence is a software application development endeavor;  without that basic worldview in place, your BI project will fail. Instead, you will jump into a BI project with the wrong approach, the wrong expectations, and the wrong people. 

 

A “Just Do It” command from an executive will not make an enterprise dashboard magically appear. To be successful, you will need experienced people following the right methodologies and best-practices to create your clearly-defined BI application.