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:
