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?