In the “What makes a good strategy?” post, I explained the structure which we used for the School of Data strategy document. The basic structure was for each goal to have an aligned rationale and methods which would be used to attain it. This exercise is a way of producing or revising a strategy document, which pops out nicely in that structure - so it could be handy to revise.
This is an exercise to:
- Surface what the high-level goals of the project should be
- Establish whether everyone on the delivery and management team is on the same page about why those goals have been selected
- Prioritise activities which support attaining the goals
Background material & preparation
- From Days 1 and 2 - you should now have: outputs 4a, 4b and 6 . Together, these outputs make up a list of items in your strategy that you should revise from the previous time you wrote it (or need to think about if this is your first time writing one). It may be helpful to have a summary written up of them by this point.
- Write out the headline goals from your previous strategy - one per piece of A4 paper (make sure you have another A4 colour forlater on in the exercise).
- Before you start, it might be an interesting question to ask your team how many goals they think is reasonable to have in a strategy. This doesn’t need to be binding, it’s just useful to have this thought at the forefront of their brains when inevitable excitement of all of the possibilities in the world kicks in!
- As a group, brainstorm the “headlines” of your strategy - the high level goals. First do this organically (i.e. let people come up with them without being constrained by what went before). Write each goal in 3-5 words (one of which should ideally be a verb) in large letters on an A4 piece of paper. Don’t waste time disagreeing what should and should not be a headline, write all options down for now as they surface. If you do this quickly, there will be time for another sort later.
On version control
I have always wanted to use proper version control of strategy documents to help keep record of why a particular decision was made and have written this exercise with this aspiration in mind.
I am talking here specifically about technical solutions to version control, rather than simply good practice around properly naming, dating and storing your documents.
I use git, which allows you to produce a visual representation of what has changed in the file without having to painstakingly compare two documents to see what changed. Git is commonly used to collaborate on code, but there is no reason why it cannot also be used to manage content. Github has private repositories for works in progress and sensitive information! Some wikis also allow similar features when browsing their history.
There should be at least some parts of your strategy which remain constant from iteration to iteration and it is really helpful to understand and flag what those are. This way, the team knows they can focus on getting their head round the implications of anything that is new. For the new parts - it is often useful to see when a decision was made to change away from a particular way of doing something and if possible, the rationale behind it.
In order to do this, you will need to put in some effort to align the previous categories with the existing ones... Read on for a suggestion!
- You might want to appoint a note-taker at this point to capture rationale for any decisions made. Take the pre-written headlines from the previous strategy and lie them out on the floor. Have the team match the new headlines with the previous ones. If there are any headlines which appeared in the previous iteration, but not in the updated one, double check and discard (there are always more points than energy and it is easier to add in than cut). You should end up with 3 groups:
- Perfect match - these are essentially exactly the same, possibly using different words from the previous time. For the sake of version control, take the original wording. (In the case where you want to change the wording, probably better to move to the next category.)
- Slight (justifiable, explicit) change required - ask people to specify out loud what the change that is required is. For purposes of speed, if there is not agreement for the change, park and nominate the most fitting responsible person for making the call.
- Entirely new - new headlines, up for consideration.
- Fast brainstorm: each team member writes down a 1-2 sentence rationale for each of the headlines to answer the question: "Why are we doing this?". For points that are carried over from the previous strategy, this can be a mini quiz to see if people remember the original motivation, if they do not, perhaps it should be revised or people refreshed on it.
- Cluster the rationale postits if there are similar ones. Then allow people to each underline one word which they feel is essential to capture the essence of the rationale. The responsible person will need to aggregate and narrow down the options after the exercise, but this is a good opportunity to see if there are any vastly disparate views on why we are doing what we are doing.
- Now that the rationales are also understoof. Ask the team to vote *at headline level*, using sticky dots as to their top priorities for the strategy. This will give the person responsible for aggregating a temparature check on where the team's priorities would lie and the aggregator will need to use their judgement or discretion for the order chosen.
- Next, allow people to revisit the outputs listed above from the previous days. Ask people to write one activity which they think should take place within the next X months (however long you are targeting your strategy for) on an individual postit note. Next, lay out the A4 paper with the headlines on the floor. Ask people to cluster their activities around the headline that is most appropriate.If they can't find a headline - you will need to ask yourself if this is really valuable. </ol>