Don’t Worry About the Sign Off

A traditional DW/BI project has requirement, design, build and test phases. And between each phase we have deliverables. Dimensional Model for example, is one of the early deliverables, produced at design phase. If you look into the design phase in more detail, it consists of several activities: ETL Design, Dim Model Design (aka Warehouse Design), etc. At some point, a design document (or business requirement/analysis document) needs to be signed off, and it is used as a base for the next phase.

Here’s an example: business requirement document (BRD) –> functional requirement document (FRD) –> technical specification (TS) –> coding/build. The person writing the FRD will use the requirements defined in BRD. And the person writing the TS will use the functionalities defined in the FRD. Of course there are other things like quality requirement, non functional requirement, etc but that’s beside the point.

So a BRD needs to be signed off, before the FRD can be written. And the FRD needs to be signed off, before the TS can be written. And the TS needs to be signed off, before the code can be written. Right? Wrong. That’s the old concept. In these days and age, in BI projects, we don’t wait until a document is signed off, before we start the next stage. A soon as the author declared “I think I have the guts of it written”, then the next stage begins. Of course, when the upstream document changes, the downstream document needs to be updated. But that’s fine, because usually it’s minor changes. This method can save the project delivery time by a quarter. Now we are talking huh?

The second reason is: because no body knows the requirement in details. They can only specify the requirement to the best of their knowledge at that time. Of course it will change. Especially in BI project. Once you show the cube/report only then the business understand it better, and from that understanding comes out new requirements. Of course. That’s natural. Best systems are the ones which achieved version 5. This means that the software have incorporated feedback from the first version, second version, etc. It is a mature product.

The same goes with BI. It’s not a good idea to do it like 20 years ago: spending a lot of time interrogating the business users to get the requirements and then ask them to sign it off. So that if something goes wrong, you have it on paper. That’s a thing of the past. We don’t do that any more in 2011. Why? Because 20 years ago, the pace is very slow. You have 3 years to design a system. Now? A year is probably too long. Especially in BI and data warehousing.

Agile? Yes. Should we use Sprint? Absolutely. This actually removes the responsibility for the project team to “deliver on time”. Because we are not measured by time. We are measured by the user satisfaction. What’s the point delivering the system on time and on budget but doesn’t satisfy the business? We delivered according to the requirements, and they signed off the requirements. That’s why it’s not difficult to sell the Agile concept to the business, because what they need is satisfaction, not a system that is delivered on time.