8 Ways BI Projects Are Different Than IT Projects

Unfortunately, many organizations still try to approach BI projects like they would approach a project to update their network hardware. They are unsuccessful because they don’t understand how BI projects are different!  The reality is BI and IT projects are very different. When you approach BI and analytics projects, there are different steps you must take to ensure success.​

Many organizations often still struggle with the basics when it comes to analyzing data.  For example, getting a report on “Last Month’s Sales by Region” to the appropriate staff in a timely manner with accurate data and data definitions that everyone understands is a challenge for many organizations. This hasn’t changed since I’ve been in the BI industry. But most now realize that they must do much more with data to outpace their competition and serve their customers better. 

Today we are using data in ways that would have been considered science fiction eight years ago, but the data isn’t always neat and tidy, the value of the data often deteriorates in literally minutes or hours, and there is so much more data! It is a real struggle for every organization to prioritize their analytics needs and execute without over-promising and repeated expensive false starts. 

Unfortunately, many organizations still try to approach BI projects like they would approach a project to update their network hardware. They are unsuccessful because they don’t understand how BI projects are different! 

The reality is BI and IT projects are very different. When you approach BI and analytics projects, there are different steps you must take to ensure success. 

About 8 years ago, we wrote the 8 Ways Business Intelligence Projects are Different Whitepaper. Since then, many of our customers and prospects have told us that they have found this whitepaper to be valuable when planning a BI project. 

Let’s see how each of the 8 ways BI projects are different from IT projects and if they do or do not apply today:

1.    BI projects are primarily business projects, not IT projects.

This is undoubtedly still true – and even more true today. Eight years ago we recommended that subject matter experts (SMEs) should be involved during the requirements and testing phases of a project. Today, the SMEs are among the primary members of the delivery team involved from day one. We do a lot more prototyping and even faster project iterations than we did eight years ago. Projects move so fast and requirements change so quickly today, that we recommend 100% involvement from business experts throughout the entire project, otherwise the project will drag waiting on their input. 

2.    Intensive IT business analyst support is required throughout the project.

This difference is still true today. We described the need for IT to be more accommodating to business analysts than typical IT projects. We find today, that IT has largely embraced this idea – and not only in BI projects, but in most projects. If anything, other types of IT projects are now done with a closer alignment to the business than they were 8 years ago. There are a lot fewer large-scale, force-it-down-their-throats IT projects now. Businesses will work around IT if that happens, and IT will get a reputation of being unhelpful. It is still a challenge for our very large clients and those in certain industries like healthcare and insurance (because they are more risk-adverse).

3.    Requirements for BI projects are impossible to define completely in advance.

This is the most fundamental difference between BI projects and IT projects, and it is as true now as 8 years ago. Our clients who understand this are the most successful in using data as a strategic asset. For an IT project, you can completely define your needs for a network upgrade project, and can almost completely define your needs for an accounting system or a CRM system up front. Of course a company’s needs will change, but if you involve the right people, they can tell you exactly what they need.

Not so for BI and analytics projects. This is because you don’t know what the data is going to tell you until you start asking and answering questions. Your data may tell you that what you thought was important is much less important than something else. And you may discover this fact at any stage of the project.

Today, we have much better tools to allow us to change requirements throughout a project. The data discovery tools from Qlik, Tableau, and others have revolutionized how we deliver these projects. And the big vendors have followed suit with their own tools that allow fast prototyping, data profiling, and put more power in business users’ hands.

4.    A different project management approach is needed.

This is also still true. An agile methodology is a requirement for a successful BI or analytics project. But today, we find this approach is embraced across business – not just in BI and not just in IT. We still focus on fast time-to-value – which means short iterations and confidence that a feature left out now will be incorporated into the next iteration a few weeks (or less) later.

5.    Building the BI solution is just the beginning - extensive testing is needed.

While this is still true, the testing we do is a lot more pervasive throughout a project. We actually have shorter testing phases because we’ve done testing throughout the project. The rapid prototyping we now do allows a better understanding of the data at earlier stages of our projects which allows us (and our clients) to fix things before any dedicated testing phase.

6.    Users are attached to their current toolset – change management is critical.

In the past 8 years, the BI & Analytics pendulum has swung away from neat and orderly “one-version-of-the-truth” data warehouses to a more chaotic world where business users have powerful tools and access to more data. As our clients embrace this business-centric, decentralized, post-data-warehouse model (even though almost all of our clients still have, and still need, a data warehouse or something that serves as the data warehouse function), the need for change management is as prevalent as ever.

8 years ago, change management was necessary because users liked the tools they frequently used and didn’t want to move to the new tool implemented with the data warehouses. Today, adoption rates of self-service BI tools are high because they are more intuitive and flexible to the business needs. But with powerful and decentralized analytic tools comes a need for centralized data stewardship so the company doesn’t lose the “one-version of the truth” trust in the data.

Rather than teaching new tools and managing adoption, change management today is more focused on standardizing and managing processes, master data, and access to data. Make sure that you continue to define requirements from the users themselves and then implement a similar change management strategy we talked about 8 years ago in the whitepaper.

7.    Tight integration with existing systems and business processes.

This is absolutely still true, but now companies are  less focused on the need to extract data from existing systems without affecting performance because modern operational systems and back-end databases are much better today. It’s something to pay attention to, but not a main concern.

I would, however, put a lot more emphasis on correcting the data in operational systems and even changing business processes as a result of findings during an analytics project – even during discovery or prototyping activities. We always (not almost always - always) find data quality issues and we often make recommendations to change source systems to help keep data cleaner. One simple example: changing a field from a free-form text field to a drop-down with defined options.

8.    BI is a program, not a project.

This is as true 8 years ago as it is today. It is still what we tell our clients. It gets our clients’ attention when they ask how long it takes to finish a BI effort and we say, “you will never finish . . .” and then go on to describe that they can certainly finish a well-scoped project in as little time as a week, but for an organization to really use data as a strategic asset, they will need to put a long-term program in place. There are many more companies that realize this today than there were eight years ago. Companies even take the concept a bit further and employ a Chief Data Officer whose full-time job is to make sure that the organization is making the most of their data.

This whitepaper has helped our clients manage and execute their BI projects and set them up for success – so much so, that we still recommend it today. Even though 8 years has passed and the BI & Analytics Industry has had an explosion of software options, data nerds, and amounts of data, the fundamentals of BI listed in the whitepaper are still the same.

Use the whitepaper and these 2016 applications to approach your BI projects so you can champion a data-driven culture in your organization and see success in your analytics efforts. 

David Fussichen's photo
President
In 2005, David founded Analytics8’s in the United States. His focus is on leading and building Analytics8’s business in the Americas as well as our worldwide products business. His favorite way to spend a weekend is by building something or doing an activity with his family. You’ll never find him being idle. “Relaxing” on a beach sounds like torture to him.

 

Contact Us

National Office Telephone | Mon-Fri 8:30am-5:30pm CT