I was lucky enough to join Rittman Mead last autumn as a Principal Consultant, and one of my responsibilities is to refine our approach and methodology. I’ll be writing about BI and data warehousing methodologies over the next few months and I’d like to talk about Delphi, a methodology I’ve championed within RMC for those projects when we take responsibility for the delivery, or those when we support members of the client team who are responsible for project leadership.

A solid methodology provides a standardized step-by-step plan for approaching projects consistently, clearly defined roles and responsibilities and a framework that enables client and project leadership to maintain control. But at the same time it shouldn’t be so detailed and overly encumbered with so many checks and balances that it slows delivery down or even brings it to a stand still.

I look at methodology as a way of reducing the frustration that everyone feels during IT projects:

•    The business users hate it when we build something they didn’t ask for
•    The developers hate it when they have to re-do things over and over again because the instruction they got weren’t clear or detailed enough
•    The project leadership hates it when the business keep asking for more and more “new features” to be thrown in at the last minute
•    The business management hate wondering what we are up to and hate weeks or months of no news
•    The business sponsors don’t like worrying that they may have wasted money
•    The support team hate having business critical applications thrown at them with little or no documentation and inadequate training

Many of you will have seen the famous “Tire and Tree” cartoon (apparently it has been in circulation since the mid ‘60s!), but it’s well worth including here because it so well exemplifies the dangers of poor communication – which IMHO characterizes all verbal communication:

Often when we work on contract engagements we are asked to use our client’s methodology. In this case, I always look for ideas and suggestions that I can recommend to them to improve their methodology and this advice has always been well received.

Other times the client either has no methodology, or does not practice using one effectively. In these projects it is really important that you try to at least apply a bare bones minimum set of methodology deliverables, not only for them but also for your own protection.

If you can at least minute important design meetings and send confirmation emails of all design changes as you go along, at least you’ll have something to fall back on if all £$%& breaks loose. If I had to choose one deliverable only, it would be the functional or design specification. This document not only encourages discussion about what is going to be developed, but by its very nature it helps to set scope.

If I had to choose one communication device it would be a weekly status update email that copies in everyone who might be wondering what you are up to and why it’s taking so long.

The RMC Delphi Methodology enables project leaders to pick and choose what deliverables and level of status reporting is applicable for each engagement. It’s important to tailor the scope of deliverables and communication for each project.

To aid in a smooth progression through project phases, the Delphi Methodology incorporates exit reviews at the end of each phase. Prior to closing the phase on the project plan, the project manager is required to complete an exit review to ensure all required steps have been taken and that open items are addressed. The review includes development of plans for resolving open issues, as well as a review of project schedule and budget, including managerial approval of changes.

The Delphi Methodology defines standardized responsibilities of logical roles in the data warehouse development for both the Rittman Mead Consulting team and the client team. There are 18 phases within Delphi, which can be fine tuned and/or cut down in scope to fit even the smallest project. The 18 phases are:

1. Project Startup
2. BI requirements definition
3. Data analysis requirements definition
4. Data architecture
5. ETL architecture
6. BI architecture
7. Infrastructure architecture
8. Design data model
9. Design ETL
10. Design BI
11. Design Infrastructure & proof of concept
12. Deployment & Testing Preparation
13. Build ETL
14. Build BI
15. System Test
16. User Acceptance Test
17. Train and deploy
18. Maintenance & Support

It’s important to go through each of the phases, even if vastly reduced in scope, to ensure that you deliver a quality product every time. Whether you are working on a two-year enterprise-wide data warehouse or just adding a new level of aggregation to an existing data mart.

Each phase of the methodology contains a list of deliverables and working documents with links to document templates, such as project plans, statements of work, issues logs, and checklists.

Using templates ensures quality documentation across projects and faster, easier development of documentation based on quality documents from past successful projects. As we complete each project, we try to take the time to update our templates with any improvements we have discovered. Although, I admit this non-funded phase of project work is the most likely to be neglected.

In conclusion, I like to sum up by saying that the key to a successful data warehouse project is a comprehensive methodology that applies best practices and proven experience to guide a data warehouse project team from project launch through to deployment.

I’d like to also say to all the die-hard brilliant developers out there who’d rather walk over hot coals than spend a week doing documentation, try to think of methodology as way to ensure that no one gets frustrated – especially you!

I intend to come back to this over the next few weeks and months and add detail on to the 18 Phases I’ve listed. I’m also keen to get feedback from you as your comments will help me to improve the Delphi Methodology.