Objectives, Concepts and Principles
I’ve been mainly occupied today working on the next evolution of our organisation, which comprises several thousand people supporting a couple of hundred customers globally. I did most of this work at Caffe Nero in Preston, working on my laptop, but I worked through the ideas with a senior manager on an A3 pad of paper.
The way I start any exercise like this is to try and develop three key areas, in an iterative fashion:
- Objectives, which define what we are trying to achieve in broad terms
- Principles, which define how we are seeking to achieve the objectives
- Conceptual solution, which provides a high level view of the ‘shape’ of the organisation that we would follow from 1 and 2
At this stage I’m not worried about documenting assumptions and constraints, because they can be artificially limiting, I will come back to them much later.
You might wonder why it makes sense to work on this iteratively since in theory it probably appears that I should have defined each area in order. Since I’ve always worked iteratively I’d not considered this before so I’m not sure I have the answer, but here goes:
- When I’m starting an activity I often have many objectives but I’m trying to find the few from which all the others can be derived. Working through the principles and concepts helps me with this process of simplification
- Often I confuse principles and objectives in the early stages, it’s only through the process that I clarify in my mind the difference between the what and the how of the strategy
- I’m trying to get clear in my mind the matrix that shows which principles contribute to which objectives
- Objectives, for example ‘reduce cost’ are so obvious that without the supporting principles that describe how we are going to reduce cost they are pretty worthless
- The conceptual shape of the organisation allows me to test the validity of the principles against real world constraints like scale, management bandwidth and complexity so it helps me make sure that the principles will be robust enough to guide the next phase of development
It was interesting how often I had to stop the discussion, because it was being dragged into the details rather than defining the shape. It’s key to develop the conceptual shape first, if you don’t you will end up with a mess that try’s to accommodate every bottom up requirement and perceived constraint.
I love this way of working, balanced between research, prototyping, discussing and refining. The day went roughly like this:
- 30 minutes meditation
- An hour reading at the Beach Terrace Cafe
- A 20 minute drive into Preston listening to podcasts
- A 45 minute walk to Caffe Nero listening to podcasts down by the river
- An hour developing a straw man covering the objectives, principles and conceptual solution
- A 20 minutes walk to the office thinking through the straw man
- A 30 minute conversation on some of the specific challenges we face in the organisational transformation
- A 90 minute discussion, in which I sketched out the straw man. I sketched it rather than presented it because that allowed me to easily incorporate feedback that refined the straw man, in a way that’s not possible when presenting. Presenting constrains the debate.
- A 20 minutes walk back to Caffe Nero thinking about the implications of the two conversations
- A 90 minute session capturing in presentation form the first draft objectives, principles and conceptual solution
- A few minutes writing this post
- A 30 minute walk along the river listening to some comedy shows to relax
- A 20 minute drive home listening to podcasts
- An hour scanning my news feeds ready for tomorrows reading
- TV hour
- Reading before bed
The inspiration for this post came from an article that I read this morning on developing a strategy : Without a map you have no strategy. They key points of which were:
- Determine your environment (starting with user needs)
- Determine where you can attack (the options)
- Determine why you would attack one space over another (i.e. the games you can play, the advantages / disadvantages, the opponents, how you can exploit inertia or constraints, possibilities for building ecosystems etc)
- Determine the how (i.e. the method – using an open approach, co-creation with others, alliances)
- Determine the what (the details) and finally the when.
Although it’s not directly relevant to designing an organisation, it started me thinking.
1 Response
[…] of a laptop producing plans, estimates, registers, and deliverables and not enough about scope, objectives, people, progress, discussion, review and quality. Joel has written a great book, that has […]