Action Plan
We come to the end, and for everybody's mental health it is very important to come to a conclusion.
The first thing to do is to capture all the good work that you've completed as part of the analysis. This means creating a report that contains:
- A statement about the success (or otherwise) of the exercise - essentially did you accomplish what you set out to achieve in the statement of intent. Yes - all well and good. No - its a good idea to outline what factors or events stopped you from achieving the outcomes you wanted.
- All the rich pictures with detail around how they were completed and by who,
- The user stories with detail around how they were captured and by who,
- All root definitions that were produced,
- All the business capability models created,
- Heat maps to show system and organisational boundaries within BCMs, all system diagrams, data descriptions and any metrics gathered,
- All business process models produced,
- Outcomes from the use of any of the Tech Tools,
- A reference to the separate document that contains any requirements that were developed,
- And finally the separate Action plan.
Here is the thing - the action plan can be one statement that says something like Having completed the analysis the client at this stage has decided to take no further action.
That is perfectly fine. In the Cellar Door example the outcome was not to proceed with the implementation of a CRM simply because they discovered that their top customers numbered less that a hundred. A CRM would have been expensive, complex and just plain overkill for that number of people. The action plan explained that in the first instance they would transfer the card data to a spreadsheet and develop the spreadsheet over time. The second action was to look for a low cost CRM plug-in for the financial management system. A good outcome for the Cellar Door business.
If, after the analysis, there is a desire to take a next step, the action plan becomes a little more involved. A typical plan has the following sections:
- Current situation: a paragraph describing the current situation As Is and commentary on why this is problematic. This commentary should not be opinion, but rather based on facts.
- Future situation: a paragraph describing the situation once the action plan item has been successfully completed To Be and a description of the benefits being sought by the organisation - what does success look like? Both the Current and Future situation descriptions may be supported by user stories which help to keep the organisation focussed on its customers.
- Solution design: a paragraph describing the type of solution currently envisaged which can bring about the Future situation. Even though the solution design may change radically as further work is completed, it is important to have a concept at this stage so that costs and impacts can be estimated.
- Metrics: estimated timescales, costs, commercial arrangements and any other dependencies.
- Organisational change description: how will the project change the organisation, what organisational resources will be needed and how will the transition be managed?
- Data impacts: what organisational data will be impacted by the change and how will that be managed?
- Next steps: given all of that what are you actually going to do? Write more requirements? Undertake a business case? Talk to system vendors? Talk to similar organisations about how they dealt with this situation? Write down what those steps will be, who will do them, when they should be done by ensuring there is money in the budget to make it all happen.
And there you have it - Rupert's Analysis Process. I hope it serves you well.