Slow BI and the BIG Method Part 3

Continuing on from my recent posts introducing the BIG Method of Slow BI, here are the major steps and also the amount of effort I would usually expect each step to take (expressed as a percent of the total budget):

So under Slow BI, you expend a minimum of 65% of your budget before you start the strategic development. If you were to do this under a more traditional SDLC, you would probably lose political support for your program, quickly followed by loss of budget. And you will not have had the time to deliver anything close to justifying the money you have spent up to that point in time. On the other hand, if you launch into rapid prototyping you will know so little about the underlying data, any prototype you show the business is unlikely to be successful and/or feasible.

How can you afford to spend this 65%? Well, you can still implement and deliver value to your stakeholders prior to this but you do it as a rapid response. In a sense, you mask the main activities of your team (data analysis) with a series of tactical, quick wins that address the low hanging fruit. You identify a portfolio of deliverables that are:

• quick to …

Continuing on from my recent posts introducing the BIG Method of Slow BI,
here are the major steps and also the amount of effort I would usually
expect each step to take (expressed as a percent of the total budget):

So under Slow BI, you expend a minimum of 65% of your
budget before you start the strategic development. If you were to do
this under a more traditional SDLC, you would probably lose political
support for your program, quickly followed by loss of budget. And you
will not have had the time to deliver anything close to justifying the
money you have spent up to that point in time. On the other hand, if
you launch into rapid prototyping you will know so little about the
underlying data, any prototype you show the business is unlikely to be
successful and/or feasible.

How can you afford to spend this 65%? Well, you can still implement
and deliver value to your stakeholders prior to this but you do it as a
rapid response. In a sense, you mask the main activities of your team
(data analysis) with a series of tactical, quick wins that address the
low hanging fruit. You identify a portfolio of deliverables that are:

• quick to achieve
• specific to a small group of stakeholders
• a solution has clear support from the benefiting stakeholder(s)
• do not require an enterprise platform
• solve a problem that is causing business pain
• if at all possible, result in a concrete benefit – i.e. dollars
  saved through removal of a cost item, especially staff cuts. Mitigation
  of an identified risk is also good (especially an audit
  finding/compliance risk)
• have a commitment from a stakeholder to quickly realise the benefit(s). 

What sort of projects are these in my experience? Usually they involve one or more of the following:

• Replacement of a manual  (time consuming and/or unreliable) process. Usually involving Excel or Access
• Involve a single department
• Take less than 3 months from start to benefit realisation
• Have permission from IT Architecture and Risk Management.

What are the main activities and deliverables of step 03?

03 Rapid Response

03.1 Business Problem Prioritisation

03.1.1 Risk/Reward Matrix

03.1.2 Rapid Response Priorities

03.2 Solution Design

03.2.1 Impact Statement

03.2.2 Business Benefit Statement

03.2.3 Business Commitment Statement

03.3 Rapid Response Program Schedule

03.9 Solution Build and Implement.

Next post: Planning, Analysis and Design.

Previous posts in this series:

• Slow Business Intelligence
• Slow BI and the BIG Method Part 1
• Slow BI and the BIG Method Part 2

Link to original post