« February 2010 | Main | April 2010 »
March 21, 2010
Delivering Data Is Not Enough
The history and often conflicting definitions of Business Intelligence are such that many organizations still hold on to one or more dangerous fallacies concerning everything from who should run BI initiatives to what real value BI can actually offer and how.
BI has largely emerged from IT-driven work of extracting data from source systems and building data warehouses. There are still many organizations in which BI is run by IT. IT's goal is to get the data out to the business but their focus is on the technical solution development and the software. This focus often leads to general unhappiness: business feels that the data is irrelevant or difficult to understand; IT feels frustrated that business is unsatisfied. This scenarios tends to produce a lot of confusion and results in significant adoption problems with managers wondering why people aren't using their expensive BI or reporting solutions.
It was a huge step forward when organizations began to understand the importance of involving business in the initial goal-setting, requirements collection and data presentation design. This approach helps to involve business users and sometimes creates a better solution design (better in its ability to get the right info to the right people to support decisions). However, the "BI solution" is still a set of reports, usually emailed to users with little additional context or guidance.
The problem is that seeing the goal of BI as simply delivering data to people (the laziest version of "decision support") ignores the human and process factors that will move BI past an initial project success into a program that guarantees ongoing and business-driven expansion, adoption, support, evolution and value. Real success and value in BI will be realized through:
- strategic planning and goal alignment
- common data definitions
- data quality optimization
- actionable data presentation design (to drive behaviour)
- data integrated into processes
- training, change management and communications
- ongoing value optimization through collection, prioritization and management of requirements.
Only recently is this point becoming clear to even very experienced BI professionals and industry analysts such as Gartner: see article here.
In order to speak intelligently about immediate and ongoing Business Intelligence (BI) value, BI must be seen and spoken of in a holistic manner rather than as a set of technical and end-user solutions. A holistic view is like saying that Customer Service is not just the CRM technology, which is clearly obvious and universally accepted. By understanding BI in a holistic manner as a set of ongoing strategies, systems and processes designed to optimize the value of your critical data in pursuit of business goals, we can gain clarity around how to organize, plan and run successful initiatives as well as how to assure and measure success over time.
Posted by Kelly Lautt and John E West at 2:30 PM | Comments (0)
March 10, 2010
Iterate, Prototype, Deliver Value
The standard "Rigid" model
Business Intelligence projects are complex endeavours with far-reaching goals. BI projects include myriad themes from corporate strategy down to intricate technical details and include users from different business areas with unique needs from data of inconsistent quality. With this level of complication many organizations choose to approach BI projects with an enterprise-wide focus and long planning cycles to avoid mistakes, missteps and costly diversions.
Unfortunately, many BI projects with extensive scope and long cycles of planning deliver limited value, take longer than expected, cost more than budgeted and are less likely to be adopted by users. A better alternative is to adopt an agile approach to delivering BI value.
Rapid iterations
Agility in BI delivery (for which the actual "Agile" project type is only one valid approach) means dividing efforts into manageable chunks that deliver material value on a regular and iterative basis (i.e. every 3-5 weeks). This iterative approach helps to address:
Value realization begins after each incremental release usually in less time than standard planning cycles would have been completed. Within a month, users can access data and prototypes to provide feedback and more detailed requirements, increasing adoption, fostering a feeling of ownership and increasing usability. Short cycles with visible value also help sponsors manage budgets and get users to "good enough" quickly.
Project Momentum
Enterprise-wide BI plans are usually conducted to reduce the risk of making a mistake and to give the project sponsor an idea of what the total project cost will be. Yet, actual mistakes discovered early in Agile iteration are often less costly then the guaranteed costs and efforts of enterprise planning. As well, enterprise-wide planning projects don't seem to increase the accuracy of cost estimates. In fact, Agile breaks programs of work into smaller, measurable, more tangible chunks.
An iterative approach has the ability to make a few cheap test runs to determine if the project is possible. Each iteration should select a few data elements and deliver something of useful value with that slice of data to the end users. Start small and deliver in prototype form, so that users can give their feedback quickly. Most importantly, don't be discouraged if the data is not valuable, this is what you are trying to determine as cheaply as possible.
With an iterative approach, the first value is produced in the first month with most of the team members starting work on day 1. This not only establishes the team with can-do credibility, but also reduces the need and likelihood of requiring a full ROI evaluation before the project can begin producing value. From a funding perspective, working with users using early prototypes builds excitement and understanding of value throughout the organization, supporting budgets for each subsequent iteration.
Objections to rapid prototyping and quick iterations
Often, people think that an approach comprising a series of quick, small-scope iterations ignores some of the key elements of proper planning and jumps too rapidly into implementation. It is absolutely true that delivering BI without an approved roadmap (and budget) is risky, but removing long planning doesn't mean ignoring proper strategy and BI goal alignment to corporate goals. Understanding and communicating corporate strategies and goals can be done while other critical start-up efforts such as reviewing existing architectures and assessing data readiness are underway.
An approach that moves quickly to a first prototype and proceeds in very rapid, tight iterations is rarely used in the field. BI projects tend to be organized in phases with full data marts that support the needs of an entire department. Sometimes this is the only way to deliver BI, due to complex interdependencies or "layering" of solution elements (i.e. calculations built on other calculations). In many other cases quick prototyping or even formal "Agile" could be used but is not understood by the project team. Iteration planning is the art of goal decomposition into iterations, and BI teams may not have the skills to understand how goals relate to the strategy or the business processes. For iterative BI to work, the BI team must have an understanding of how the business will derive value from the solution in each rapid phase.
Posted by Kelly Lautt and John E West at 3:30 PM | Comments (2)
Twitter 
LinkedIn 
YouTube