Many organizations still try to approach BI projects like they would approach a project to update their network hardware. The reality is that BI and IT projects are very different - here's how.
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 once would have been considered science fiction, 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.
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 of our customers and prospects have told us that they find the 8 Ways Business Intelligence Projects are Different 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:
This is undoubtedly still true – and even more true today. 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 back then. 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.
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 in the past. 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).
This is the most fundamental difference between BI projects and IT projects, and it is still true. 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.
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.
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.
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.
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 years ago in the whitepaper.
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.
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. Many more companies are realizing this today. 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 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.
To thrive with your data, your people, processes, and technology must all be data-focused. This may sound daunting, but we can help you get there. Sign up to meet with one of our analytics experts who will review your data struggles and help map out steps to achieve data-driven decision making.