We’re currently running a series of blog postings on what to really focus on to get the most business value when your resources are limited. The postings are based on a presentation given to leaders in small to medium sized companies. This is the third in the series.
Example project plan using Agile methodology
Those of you familiar with the Agile approach to projects will probably have spotted that what I’m outlining is pretty close to Agile: delivery is in bite-sized chunks designed to give the benefit that each one provides some direct business value. There are no long waits of many months until the final product is delivered, instead there’s a drip-feed of incremental scope. That’s what’s so attractive, the ability to keep project risk low and keep a business sponsor on side with some progress to see regularly.
There are some downsides to Agile on information and data projects. The first one stems from what everyone who’s worked on a data warehouse project knows: you can’t tell if your design is any good until people see their own, real data in reports that are meaningful to them. So you need to particularly careful in what you commit to if you’re undertaking a business process change project at the same time as putting in a reporting system. The timeline on the slide shows the issue: you don’t have any real data to use until the source system is running live, so if you’re building data marts while the source system’s still changing you may well end up with rework to do once the systems are both live.
Another issue with Agile on information and data projects is that the real business value delivered in a single release tends to increase as the releases progress. In other words, the business value you get accelerates. The usefulness of the first release tends to be much less than that of the fifth or sixth, so you need to set the expectation when you’re agreeing the project delivery schedule.
In the next posting we’ll be applying dimensional modelling and Agile in practice using RED from Wherescape.
