Much of what I do in my working life is to come up with frameworks for delivering IT services (and then implementing them). A framework is a nice general term that covers everything from general principles to detailed work-instructions and should include every concept needed to deliver IT services for an entire organisation or for a team.
Having recently discovered to my surprise that certain elements of Mahayana Buddhism have become a part of me, I became curious as to what my actual framework for living is and even what the components of such a framework would be. I thought it would be interesting to see if the kind of analysis I do in my work would be useful in my life as well.
NOTE: This rest of this post describes a perhaps overly-analytical approach to identifying a framework for living and not the contents of one (every individual will no doubt have very different frameworks).
The kind of frameworks I deal with generally have clearly defined objectives – what the framework is actually for. In living, values provide the same function. I also define targets as part of a framework, the targets usually falling into one of two categories: performance (maintaining a certain level over a period of time) and improvement (achieving a certain level by a certain time) . In living, goals provide the same function. To achieve the targets (which should always be aligned with the objectives), I then design a whole lot of things that need to be in place and operating together (aka the operating model); these in turn usually consist of three components: people, process and technology. In living, activities provide the same function.
The interaction between objectives, targets and operating model are pretty simple in organisations but in living, the interactions are more complex. It seems to me, the primary interactions between the three components values, goals and activities are:
- values inform goals;
- activities achieve goals
- values direct activities;
- activities express values;
I would normally use a diagram (FYI systems design geeks: an ER diagram with many-to-many relationships between all three entities). At work, I spend almost equal amount of times between diagrams and text. Of course, in living our values can be contradictory and we can certainly act in ways that don’t accord with our values or seemingly achieve any goals whatsoever. For many of us, underlying health and other issues can get in the way. In my line of work, this is pretty much the usual scenario and what I try to correct (or at least improve).
While there are quite a number of analytical approaches that can be used, I generally favour a combination of top-down and bottom-up approaches. A top-down approach in this case would start by identifying values and then progress to goals and activities. This results in an aligned state. A bottom-up approach would instead first list common activities, identify goals from these activities (if any) and then from there attempt to work out what values both activities and goals actually represent. This results in a realistic description.
In my line of work, the ideal solution is the future-state or target-state, while the realistic description is the current-state. The difference between the future-state and the current-state is called the gap. After the design, I spend a lot of time in the gap, working with teams and individuals to bridge it and to bring about the future-state (which can be quite dynamic too). Often the whole process is phased and iterative. Sometimes when people want to use business-cliches, the work needed to close the gap is called a transformation project. Regardless, the smallest component in my work is technical, much of it is to do with people.
In living, it seems to me that the gap exists too and a lot of the initial work would be about identifying new activities (or prioritising existing ones) that will move oneself closer to the aligned state.
At work, one analytical / design approach is to run a workshop using diagrams where each instant of an object (eg: an instant of an activity object is: “going to yoga class once a week”) is depicted as a separate bubble with lines then drawn between relevant bubbles. Orphan or unconnected objects very quickly emerge leading nicely to the question of whether they should be kept in the diagram or not. Objects to be removed can then be clearly crossed-out with new objects (in a different colour) drawn in to connect orphans. Work can then be identified to either permanently remove crossed-out objects or to embed new objects. From there, work can be prioritised, allocated and collected into a plan, usually a project plan, with the usual disciplines that project management requires.
Here however is where the difference between my work and living become clear: at work, I get a project manager (or coordinator), in living, there is no such equivalent: I have to manage my own transformation project. And I am a terrible project manager (or rather I really really don’t like doing it).