Tip:
Highlight text to annotate it
X
Step 4 of the ideal system redesign methodology is compiling a design notebook.
The underlying theory of a design notebook has to do first of all with brainstorming.
Brainstorming produces prolific and diverse information and also the same type of information
in different contexts. So this requires a categorisation and elimination of duplications.
This is done in a design notebook. A more important and systemic point is, especially
if one works in a team and with more than one part of a system, like in our organisation
transformation programme, one will produce a lot of information about parts of the system
in different contexts of other parts of the system. The reason is that because of co-production,
the problem co-factors and also the strategies that one brainstorms to achieve the ideal
belong to different parts of the system and also to different stakeholders. So if we are
recategorising or compiling a design notebook, that information needs to be recategorised
under the correct slot. For example, if I am an HR manager and in one of my problems
I list as a co-factor that I have got that problem because the IT system is not supporting
whatever I need to do there, then I cannot solve that problem within HR, but that particular
IT problem needs to be redistributed to the IT system. All IT related co-factors that
cropped up anywhere in the organisation - in production, in marketing, in HR, in legal
and so on - will be categorised under the IT heading for the IT system to process. And
this requires redistribution of information to the various parts that can deal with that
particular information. And that of course requires a systemic framework.
So how do we go about compiling a design notebook? We integrate the brainstorming output under
the headings of a relevant design framework. And we also add generic organising principles
that we derive from Biomatrix systems theory under the relevant sections. This is part
of the following module. It is important to keep the following points
or tips for compiling a design notebook in mind. First of all, the most important tip
is: do not lose detail through generalisation and abstraction. It is amazing how people
after they have done very detailed brainstorming, had very good discussions in great detail,
write down on a flip chart an overarching sentence which becomes almost meaningless
because it captures none of the rich debate that they had.
Likewise, when we do these exercises, that of problem analysis and brainstorming, what
happens often that as we group together different related strategies or different related problems,
we are inclined to summarize them into one abstract statement and thereby lose all the
detail. For example, if I am looking at my work situation and I identify a variety of
communication problems - that I am not communicating the correct information to my staff in a detailed
enough manner, that I am not communicating with my stakeholders around a specific issue,
that my boss is not giving me enough information about a particular project - those would be
detailed communication issues which we may club together under communication. But it
would be deadly if we are eliminating all the detail and write that there are communication
problems in the system. And very often that is exactly what people do as they compile
workshop output or design notebook. We don't need to do brainstorming if we make such abstractions
and generalisation. I cannot emphasize enough, do not lose detail. We don't need to save
space on a piece of paper by reducing information. Another related point is, do not eliminate
brainstorming information on the basis of judgement. The notebook is not yet the place
where we judge if this is a useful idea or not. We still put all the ideas that we produced
in the brainstorming phase into our notebook phase. We only cluster and categorise and
regroup the information. We are not eliminating information because we think it is not important.
As one eliminates duplications or integrates related items, the same point applies: do
not abstract, do not lose detail and do not lose subtle differences. If one has two similar
statements and integrates them into one, one should not lose the subtle differences that
may have been between the two of them. Often output fits under more than one heading.
And it should be deposited under those different headings. Because in the context of the other
heading, information assumes sometimes subtle and sometimes not so subtle new meaning. Again
we must not lose those ideas, so we rather put them there anyway for evaluation later
on during the design phase. The same goes for overlaps. Sometimes issues overlap with
other issues and then it is useful to deposit that issue here and there. So one eliminates
overlaps by actually depositing the same information in two places or more.
If one does brainstorming in a team situation, or if various parts of an organisation for
example are involved in brainstorming online or in workshops, then it could be useful to
include the original brainstorming output before it was recategorised and clustered
and duplications eliminated and so on. It is useful to include the original brainstorming
output as an appendix in the notebook. And that is for the sake transparency, not so
much the necessity for future reference. Although that may also be the case. Very often in systemic
brainstorming as one develops higher order ideas, the original frogs that gave rise to
the new idea are not directly recognisable. If one sees health, one does not necessarily
see a specific disease. And sometimes staff members may want to go back and check if my
frog is covered by that new design and has been processed by the new design.
Any brainstorming situation produces large amounts of outputs which need to be categorised
to make them useful. The frog prince exercise produces a large number of strategies that
belong to different potential actors. This could be the system itself, for example a
function in an organisation, or parts of the system, like some of the sub-functions, or
different stakeholders outside the system, for example other departments or even stakeholders
outside the organisation. We need to recategorise the brainstorming output to allocate them
to those potential actors. If you are part of a team, for example within the organisation
transformation programme or the societal transformation programme, than your output will be integrated
with the output of the other delegates in the notebook phase. The different strategies
that you designed for different actors will be integrated with the strategies for the
same actors designed by other delegates in the programme. In order to be able to do that
you need to do the following exercise. You need to determine who owns each of the strategies
you designed. If you are working for yourself, not being part of a team, it is useful to
have all the strategies that you are responsible for also grouped together and to have those
strategies that you think others are responsible for grouped together, because you may have
to design strategies on how you can persuade the other actors to change the behaviour so
that your design can be implemented.