According to a survey done by Geneca, a staggering 75% of business and IT executives anticipate their software projects will fail.
Launching a successful software project is not easy.
A business intelligence project is no exception.
So, why do so many expect failure?
Often, a project fails because of only a few factors not being considered properly.
Your BI project, however, doesn’t have to end in such failure.
Let’s look how to make sure you launch a successful business intelligence project.
There are 5 main stages to a successful BI Project: Requirements, Assessment, Planning, Implementation, and Post-care.
Each one has important considerations to understand in order to be successful.
Let’s go through each one.
When starting a BI project, right away you’ll need to know the right requirements for being successful.
What happens if you find out you have bad requirements late in the project?
Your project might be among the 39% of projects that fail due to bad requirements.
So how can you avoid having bad requirements?
Talk to your stakeholders.
And really talk to them.
Schedule time with stakeholders to get answers
Ask them lots of questions.
Often times, these stakeholders will have only a vague idea of what they want.
They know they need something, but haven’t thought of all the details.
Most are probably not too technical either.
One of the biggest dangers to avoid is not getting enough information initially.
It’s easy to think you’ve asked enough questions.
You might think you have a good grasp of what is needed by briefly talking to stakeholders.
However, sooner or later, you’ll wish you received more helpful information ahead of time.
Get enough information upfront.
This will limit the amount of times you’ll need to go back to them during later phases.
As a result, you won’t lose valuable time going back and forth on requirements with people.
So what can you do to avoid not getting enough helpful information?
Answer all the important questions you’ve carefully prepared.
If they can’t answer the question right away, have them circle back to it as soon as possible and follow up with them.
What are some examples of questions to ask?
Let’s go through a few.
What questions must the final reports or dashboards answer for you to consider them useful and a success?
This question will help you to see the end goal clearly.
Make sure goals are clear in sight
Throughout the project, there will be questions that arise.
If you can isolate key questions and answers that these reports must answer, you’ll be able to stay on track and continue to move forward.
For example, when developing a particular report for one of our clients, a key question to answer was:
Have the project issues that are opened in each month of the year been closing in a timely way, or lagging behind schedule?
Our path was clear when focusing on answering that question.
The visual needed functionality to count open issues for each month that were opened for that month, or have been rolled over from a previous month.
What visual would we use?
Another question can answer that:
What type of visual would be most helpful to answer your questions?
Now often times, a stakeholder or end user has a particular visual type that may be what they are used to.
It’s important to note, however, that it may not be best.
Find out why they prefer that one, and be ready to recommend others.
To do this, learn visuals that are commonly used.
Although the following common visuals are specific to Microsoft PowerBI, almost all BI software have the equivalent visual types:
Area charts: Basic (Layered) and Stacked
Bar and column charts
Cards: Multi row
Cards: Single number
In our example with our client, we ended up using a line chart.
It fit the needs best for the end users.
Keep in mind, you don’t have to be an expert in any of the above visual types by any means.
However, it’s good to familiarized yourself with the visuals available to assist your stakeholders in what they can expect.
If you’d like a more in-depth look at the different visuals offered, you can look at this visual reference found here.
Often times, stakeholders may not know that gathering information a certain way is possible.
So make sure to ask them:
What are your current pain points with business intelligence?
This can reveal what you’ll need to overcome.
Find out what they’ve always wanted to know or do with their data.
Based on this one question alone, chances are that you’ll learn how to proceed well.
Based on all the three questions above, you can get a great start on gathering requirements.
Other questions that you should ask are:
- What is the minimal viable product (MVP) needed?
- Why is this dashboard needed?
- Who will use the dashboard?
- When will the dashboard be used (How often?)
- How up-to-date does the information on the dashboard need to be? (Daily refresh? Weekly? Monthly?)
Asking enough questions can be like drawing up water from a deep well. It takes work, but in the end, it’s worth it.
And one more thing. Even as simple as it sounds, it’s important to stress:
Write down your requirements.
Not only does writing down goals make you 1.2 to 1.4 times likely to accomplish them, but you’ll also be able to remember all the details.
Too many requirements have gone forgotten.
Jot down all the important points
Lost opportunities and lost time that can’t be recovered.
Try not to make the same mistake as others have before you.
Now that we have gathered enough requirements, we’ll need to assess what we currently have.
If you don’t know already, find out what BI tools are available in your organization.
Remember when you asked your stakeholders what pain points they have experienced?
One might just be your current BI tool.
Assess your BI tools.
You might now find out the tools you currently have may not be good enough for your project.
If you don’t have one yet, look into what is offered.
What’s the top failure reason by buyers of BI Tools from vendors?
Not having enough features (47%).
The next highest reason for failure is the tool being too manual (19%).
Don’t fall into a trap by relying on old technology.
Keep up with today’s demands on visualizing your data.
If the visuals are clunky looking and hard to use, people will not use them.
It will be hard to get a good adoption rate.
Make sure the tool you have or choose is right for you.
How can you find out if it’s right?
If you have the ability to change or use a new BI tool: Research alternative BI tools online.
There are many comparisons online that can give you a good overview of top BI tools, like this one here.
Once you’ve identified your tools, you’ll be one step closer to a successful launch.
Next, you’ll need to identify your data..
Find out your data sources.
Gather where your data is located and what is included in it.
Does it have all the information to answer your requirements?
Is your BI tool able to retrieve information easily from it?
Most newer BI tools can gather information from a vast list of different types of systems. Make sure yours is included in this list.
Make sure you have good data.
Good data is consumable. Good data doesn’t need clean-up.
If data takes a lot of clean-up, it is considered bad.
What do I mean by clean-up?
Without going into too many specifics, if you have to alter values for them to make sense (i.e numbers with other characters at the end), it’s bad data.
Here is an example of information that shouldn’t be appended at the end of numerical values. They should instead be split off into separate columns, such as Currency.
Although this is more of a technical issue, it can weigh on your project schedule.
Bad data shouldn’t be used.
What should you do if you have bad data?
Ask for changes.
Get the person or OU responsible for the data to store the data in an improved format; one that would be considered good data.
Most modern systems are becoming more strict as integrations are more common than before. This can sometimes prevent bad data.
However, user input can also cause bad data in many ways no one could even predict.
How can you see if there is bad data in your data source?
Have your IT department give you a sample of the top 1000 records of data in the source in table format.
It could be in a CSV or Excel file.
Once you can see the data, you’ll have a better idea of what you’re working with.
Here’s an example:
One of the best ways to know if you have all the data you need and if you have good data is to see it with your own eyes.
Once you’ve identified your data, go on to planning the project.
You’ll want to start with a budget.
Set out a realistic budget.
Now that you know the scope of your project, you’ll be able to set a budget that matches it closely.
Often times, leveraging existing BI tools that the organization is already paying for may seem tempting.
However, you’ll want to make sure that the projects that are using that BI tool is actually being used and is effective.
Although saving costs can be an important factor, it shouldn’t be the only one.
A successful BI project needs tools that can do the job.
If you skimp because of the budget, you can find out your BI tools don’t have the features you need.
You could have already invested too much time into that specific tool to turn back.
What if you’re on a tight budget?
One of the top BI tools that is priced well below other tools is Microsoft’s offering: PowerBI.
Keep in mind, the most difficult budget to set is always the first.
If you don’t know where to start, see if there are others in your organization have set a budget for a similar BI project.
Use what you learn as a baseline for understanding the costs.
Launching a BI Project on the cheap is usually a recipe for failure.
Make sure you have enough resources to finish what gets started.
Make a schedule that is not too ambitious.
A schedule’s timeline can vary greatly.
Much will depend on how wide spread the dashboards will be for the company, and how many dashboards and metrics will be developed.
You’ll want to make sure that you give yourself enough time to make adjustments and work through any issues that come up in initial pilot testing (more on this testing later on).
Plan who will implement the project.
Will you use a BI Consultant? Do you have in-house developer?
There are pros and cons to each option.
List them out.
The best results usually come from making sure you keep a healthy pulse on the project and hit the requirements well.
If you do this, having outside help, doing everything in-house, or a mix of both will all lead to success.
Architect a solution
Finally, architect a viable solution.
This is a combination of the requirements that you’ve gathered, along with how it will be implemented using the BI tool you have chosen.
Make graphics that show visually what you will make. Create the graphics using a free tool like Canva.
A project management study found that more than half of all project budget risk is due to ineffective communications.
To avoid this, revisit your stakeholders once more.
See how the solution stacks up now to what they expect.
Show them the solution you have architected and go from there.
Doing this earlier than later will allow for a more agile approach to changes needed.
Once you’ve received all the feedback from stakeholders and any end users, you’re ready to implement your solution.
You’ll begin the implementation process by developing the dashboard in the BI tool you’ve chosen.
Develop the Dashboards
Although development could be it’s own phase, we’ll include it in the implementation phase since we are focusing more high level concepts.
Make sure the developer doing the work doesn’t stray too far from the minimal viable product. This is what is absolutely needed to the dashboard success.
This is to limit the amount of risks as well as get feedback as soon as possible from the stakeholders and pilot testers.
Get regular updates on how the dashboards are looking.
Keep a close eye and make sure you’re getting the necessary car, and not the fancy sports car.
Definitely high performance, but not needed…
You can fancy up the visuals or adjust the layout positioning as needed later on, once all the metrics are in place.
Conduct a Pilot
Create a list of questions that include the original questions in your requirements.
Include them in a survey that you give to pilot testers.
Choose pilot testers from end users and stakeholders to test the solution before going live.
Once you’ve received all the feedback, make the necessary changes.
To get more details on how to go about pilot testing, you could check out this article.
Make the dashboards available to all the end users.
Depending on how many users are going to see the new dashboards, you may want to use a phase approach where you release the dashboards to different groups one by one over time.
Just as if you have a toddler who is taking his first steps, watch closely as the dashboards are being used.
Help your project to walk on it’s own
Keep track of how people are reacting to the dashboards.
If any bugs or issues come up that need resolving right away, go ahead and make those changes.
Otherwise, wait for enough time to pass while building an lists of updates.
Bonus: Review Choices and Consequences
Finally, you should now reflect on any lessons learned.
You’ll want to improve your process based on what results you have received.
Write these down and keep for future reference.
If you are planning to launch another BI project in the future, you can take what you’ve learned an build on it.
Launching a BI project can be a bit overwhelming at first.
With so many IT Project failures, you’ll want to improve your chances as much as possible to have a successful project.
If you’ve followed the above steps, you’ll be able to launch a successful BI project that makes both your stakeholders and end users satisfied.
Have an good or bad experience with launching a BI project?
Are you planning a project soon?
Any tips that you’ve found helpful in your own experience?
Write in the comments below to share.