« Mistaking Milestones for Value in BI Projects | Main | Delivering Data Is Not Enough »
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 March 10, 2010 3:30 PM
Comments
It's appropriate time to make some plans for the future and it's time to be happy. I have read this post and if I could I want to suggest you few interesting things or tips. Perhaps you could write next articles referring to this article. I want to read more things about it!
Posted by: London escort girls at May 16, 2011 6:28 PM
There is noticeably a bundle to know about this. I assume you made certain nice points in features also.
Posted by: www.Alegro.pl at May 17, 2011 1:39 AM
Twitter 
LinkedIn 
YouTube