At the Oxford Futures Forum 2014, hosted by the Saïd Business School, I was invited to be a participant in a generative dialogue. Each of the invitees was requested to submit a 250-word abstract and an image four months ahead of the event. In two days, we had three group discussion meetings, where individuals were free to go to other groups (or form new groups) according to the ideas emerging from the dialogue.
This event runs on the Chatham House Rule:
When a meeting, or part thereof, is held under the Chatham House Rule, participants are free to use the information received, but neither the identity nor the affiliation of the speaker(s), nor that of any other participant, may be revealed.
Further, in a generative dialogue, ideas flow and merge as participant learn from each other, so representations related to people outside of the involved group don’t get a full appreciation for the unfolding learning. Having been a participant in a series of prior IFSR Conversations that similarly focus on generative dialogue, any describing of the experience turns out somewhat inadequate. The most that can be related to others are “proceedings”, where some of the ideas in progress are captured. As a participant in Oxford Futures Forum, I was involved in three rounds of conversations, which can be roughly framed as:
- design and scenarios to instigate change (as an introductory clustering to start the first round);
- methods framing (as the emergent theme from the first round to go into a second round); and
- scenario-buffered design (as the label that was presented as the conclusion of the third round).
Based on the abstract I had contributed some months earlier, the conference organizers initially slotted me into the “Design and Scenarios to Instigate Change” group. A few of us had brief contact on a teleconference a few weeks before arriving at the event, and then in the pub on the night of arrival. When the full group finally met face-to-face, we still didn’t really know each other. As a way of getting involved with others, we were asked to present the abstract of another person from the group. From those foundations, we started a loose discussion making sense of some common themes. The organizers helpfully provided a note taking volunteer, Saba Riaz, to record some of this preliminary dialogue — a challenging flow to track, as the round 1 groups tried to make sense of the ideas of others, as well as ourselves! The proceedings (final report) included the following synopsis:
Round 1: Design and scenarios to instigate change
Points from Discussion
- Redesigning new organizations using scenarios
- Link (and difference) between risk and uncertainty
- Who bears which uncertainty and who bear which risk?
- Reflexivity in scenarios – individuals are implicitly bringing their values into the scenarios
- The question is whose behaviour is being changed – whose scenarios are being studied here
- Scenarios could prevent design issues
- Scenarios can present design approach but not vandalism approach
- Do not worry about how you got there as far as you got something
- What is the purpose of scenarios – instigating change?
Design and Creative Output
- What is the amount of design to have the maximum of creative output?
- No direct relationship between design and creative output
- There should be inductive scenario agenda
- Eliminate the unnecessary – focus on the core
- In scenarios you are in the position to realise what might be around
- Perceptions are also necessary
- How can we get government procurement people to ‘buy’ from the development people?
- New methodologies collide with old organization systems – which scenarios bring competition?
Key points which are intriguing/interesting/sticking in your mind? Which are the ones really interesting?
- Building maps for scenarios: Mapping is a way to structure, to already impose a logic already there, or to put a new frame / structure in there
- Use of maps for mapping the processes to help generate ideas and to make the process simple maps as ways to organize information
- How can we support the functions to do this?
- Inductive approach – how to use design to present scenarios in a better way
Waterfall / Structured Method
- Large projects have more failure rate as compared to small projects using the waterfall method
Scenarios Emerge
- Scenarios – they keep on improving and emerging
- Better to call scenarios an emerging/acting kind of thing rather than staged things!
- Scenarios are emerging (ongoing) rather than project scenarios – it’s an ongoing process you get better and better as you go on
Behaviour change
- Behaviour change in scenarios — whose behavior is being changed and what is being done here?
Ambiguity
- People never know what they want until they see it – this increases the pressure point
- You make things for people and when you deliver they say that is what I ask for but that is not what I want
- This is a fundamental thing that people never know what they want
- People don’t want to know unless something wrong happens – They don’t need to know the design
Agile Method
- Agile method is to avoid the type 3 problem – agile schedule is built to avoid error – it evolves and emerges by incorporating changes (adaptable)
- It is a learning approach
- Agile allows a certain amount of emergence — people don’t know what they want
- Agile shortens the feedback cycle — start with — what is it that you want as a user?
- Agile methods contradict organizational processes
- Agile is a lot about are you solving the right problem.
Learning Cycle
- You can do the things as a learning cycle but you’ve to break down the assumption that first you know what you want
Effort versus output
- We have to tell people that what our effort versus output approach is
Taguchi Matrix
- As a pragmatic practitioner you have to be careful in your language
- When user tells us this is what I am looking for we say Ok you told me
Issues
How do you get groups who are using scenarios together?
- How you make them there?
- How do you facilitate people to be part of the organization so that they put themselves in the positions?
- How will you make them part of the system?
- How they relate to organization themselves.
- Can an org prototype using scenarios.
- How you go about facilitating that and making people part of that scenario.
How do you have this scenario thinking into the organization?
How do these methodologies blend and how they are different globally/culturally.
- How can they be adaptable?
- Where they will work and where not?
- How to Blend?
- What is the application of these things?
- Pragmatism and practicality are the real issues
Questions arising from the discussion
- In redesigning the organization what do scenario thinking gives you?
- Why are we using it — what methods and how to create this?
- How to include perceptions of people/users into scenarios?
- Can we use the prototype to learn the actual scenarios?
- Are scenarios prototypes or are they part of prototypes?
- How to review the formal function of organization using scenarios?
- What to consider and what not to consider?
- Is scenario part of the process or is it a prototype to learn?
- Is scenario part of prototyping experience or are they prototypes themselves?
- Is there a direct relationship between creative output and design?
- How much design is needed to make that creative output? /What is the amount of design to have the maximum level of creative output?
- Can you develop policy through agile methodologies?
- How much creative output do we need for design interventions?
Points to carry forward
- Use of Maps in Scenarios, and scenarios as maps: maps to help think; maps to communicate
- Purpose of scenarios
- From Tacit –> Touch it: how do you make explicit what is implicit?
- How do you achieve “Economy of Line”? (In other words, the fewest amount of lines necessary to draw something”)
- Methods (comparing waterfall ‘buyers’ and ‘agile’ sellers)
Summary
- Purpose should be clear from the beginning
- Developing scenarios is an iterative process
- Whether the scenarios are end product or whether they are ways to reach to the end product
- The Economy of Line – Not too much but just enough information so that people can have little bit of idea to start with
An illustrator following the first round summarized the group discussion, which the Round 1 group labelled as “Methods Framing” to generate a Round 2 discussion group.
After an “ideas market”, where representatives from each team tried to explain themes for further inquiry, individuals chose directions for continuing discussion. From our original group of 9 people, 3 or 4 stayed with the theme, and some new people joined in.
Round 2: Methods framing
While the Round 1 group tended to be more managerial in orientation, the Round 2 group somehow shifted more towards a design orientation. A new note-taking volunteer, Candy Chan, observed:
Points from Discussion
The discussion was themed on framing and reframing projects to instigate change. Participants highlight that the predominant method of planning is to have the strategy for change developed upfront. In contrast, a more iterative and agile process is required in order to cater for the uncertainty present in all projects.
- Therein lies the relevance for the development of new methods of framing (ie. reframing). The debate is on how we can change the structured and linear method of business operations and change processes for greater responsiveness and adaptiveness in all areas of the organisation. Agility can be made to apply to strategy development, organization, and externally-interfacing functions e.g. procurement.
- Agile practices have become prominent in software development methods, in both commercial and government enterprises.
Participants noted that different organisations tend to display different degrees of receptiveness to agility.
- For instance, a small start-up may not have the legacy of structured standard-operating-procedures and have a less visible brand to protect. On the other hand, a conservative large enterprise may have accumulated a burden of protocols so that it tends to resist changes.
- Cultural background practices may be instrumental in the organisation’s predisposition to be agile or structured. For example, organisations in Western countries treat contractual agreements very differently from those in China. In Western countries, contracts are binding and followed very strictly while the Chinese tend to prioritise long term relationships.
Boundary objects as a method to frame issues
- In developing a boundary object, participants sometimes mutually create a tangible artifact (e.g. a document of understanding) in order to articulate common ground.
- The content of the boundary object can be temporary in nature, evolving when parties gain more mutuality during the exploration process. As the explorative and iterative process reach points of stability, so will the boundary object. The boundary object can become an artefact that aids in change, or anchors continuing evolution.
- For example, in developing scenarios, participants can agree on the axes of the 2x2matrix of the scenarios. The axes are then recognized as a frame for the boundary object. However, if participants eventually find that these axes are inadequate, the boundary object would evolve.
Why do companies have to be more agile?
- Many companies face a new kind of turbulence due to a change in the contextual environment e.g. globalisation, technology
- Customers are increasingly empowered by these changes, and companies need to shift their focus on their customers, away from the traditional norm of product orientation. In order to be customer-oriented, organisations aspire to greater ability by reifying linear internal processes mechanisms in favour of greater customer primacy.
- Customer centricity may or may not lead to inclusive and/or consultative visioning. The ways in which scenario planning is engaged can depend on interpersonal and/or inter-organizational relationships.
- An organisation may espouse a desire to change but the internal policies may be so immutable and locked-in that transformation could take years or decades.
Service system thinking
- In order to respond to the rise of a service economy, internal processes in organizations with manufacturing mindsets will have to be changed. Changes could include the style of management, standard operating processes, etc.
- Systems thinking can aid the development of such a dramatic organisational change. As an alternative to (i) contextual scenario design and (ii) solutions designed as sequential and independent steps, systems thinking may provide some insights useful for top organisations.
Risk vs uncertainty
- The distinctions between uncertainty and risk should be appreciated.
- In many cases, uncertainty is repackaged as risks and monetized with another party, ie. uncertainty that is part of the contextual space, is transactionalised.
- When uncertainty is transactionalised, the entire system is weakened because uncertainty is not being dealt with directly. Transactionalisation also leads to a locking-in of the package (or plan), which in turn mitigates organisational agility. Eventually this could lead to dire consequences for the project.
Designing for risk vis-à-vis designing for uncertainty
- Designing for/with risk entails a different strategy to designing for/with uncertainty.
- Not every quadrant (or situation) requires scenario planning. Some situations may require the development of a vision as opposed to the development of a scenario.
- Towards an end point of developing a product, organisations may opt to go through a style of structured designing or alternatively, a more agile style.
Scenarios can be seen either as a framework or as a narrative that organisations can develop.
- To develop effective solutions to problems involving uncertainty, clarity about the purpose of scenarios may be a virtue.
Round 3: Scenario-Buffered Design
After the Round 2 discussion, everyone collected in the library hall, where exhibits on the theme of scenarios and design were explained by their curators. Into Round 3, most of the participants carried on from Round 2, with a few people leaving and some others joining, based on hallway conversations. At the end of the day, groups were asked to prepare a 5-minute report summarizing their discussions. As we were leaving for the conference dinner that evening, the group had some debate as to whether to draw on one of the volunteer illustrators to help on the summarization. In the end, the group decided that I should be the presenter. Since I’m well-accustomed to creating presentation slides, I can (attempt to) replicate some of the narration on the presentation slides reported the next morning.
At the end of the day, when the group was trying to grapple with what we had been discussing, we recalled that the idea of scenarios and design had been surfaced in 1994 by Stewart Brand, in How Buildings Learn: What happens after they’re built. Chapter 21 is “The Scenario-Buffered Building”. Since we didn’t have a copy of the book at hand, one of the activities for follow-through after the Oxford Futures Forum event would be to reread that chapter. In the meantime, the idea of “scenario-buffered design” would suffice as a label for our discussion.
How can scenarios and design mutually support each other? On the whiteboard, one of our group had drawn the cyclic arrows between scenario and design: scenarios influence the design, and the design influences the scenarios. From some previous slides I did have on hand, I resurfaced some excerpts from the chapter on “The Scenario-Buffered Building”. Stewart Brand reminds us that:
- Scenarios are supposed to produce a strategy, not a plan. Thus, instead having an interplay with “strategy as plan” (as described by Henry Mintzberg), design may have interplay with strategy as ploy, pattern, position and/or perspective.
- A building can be designed to learn in the context of the pacing (shearing layers) that change at varying rates: the “site is eternal”, and the structure changes less rapidly than the services, space plan or stuff contained with. The careful use of scenarios with design would emphasize greater deliberation with slower changing (i.e. infrastructural) layers, than the more rapidly changing (i.e. ephemeral) layers.
In software development practices, there’s been movement away from structured methods — commonly known as the waterfall model — of sequential steps of requirements, analysis, design, coding, testing and operations, as described by Royce (1970). The challenge has been the premise that iterative interaction between the steps is successive: e.g. if the design is not working out, work should revert back into analysis for correction, then enabling a resumption of design. In practice, many projects jump back multiple steps, e.g. a problem in testing doesn’t just lead to a revisiting of coding, but questioning of requirements, which leads to disruption of analysis and design, as well.
The alternative has been agile development (e.g. the Open Unified Process, illustrated). A project that is expected to take months to be completed can be broken down into iterations — each that a team might complete on the scale of weeks — and micro-increments, e.g. work items to be completed by individuals on the scale of days. With these iterations, the large scale steps of requirements, analysis, design, etc. are broken down into learning cycles. Resources are less likely to be wasted due to regular reviews with project sponsors at the end of each iteration (e.g. every 2 to 3 weeks) rather than a long elapsed period.
Could scenarios in the context of designing an organization be reconsidered from the linear structured approach, in favour of an agile, iterative approach?
The metaphors of architectures and design as being “like a building” may be dangerous though. In software architecture, Grady Booch suggests it may be better to think “like a river“.
The metaphor of software development as building construction is an old one. [….] If you’re building a doghouse, you don’t need a set of blueprints. If you’re building a house, a high rise, or a city, having an architectural vision is generally a good thing. There’s a difference between significant design decisions (such as where to place the load-bearing walls) and low-level ones (such as choosing the crown molding or carpet). Distinctive styles evoke a particular feel, born of a set of well-chosen patterns. Obduracy grows relative to the structure’s size. The symmetry goes on and on.
The greatest limitation of this trope, for me, is that the image of building construction never really captures the vibrant dynamics of software development. [….]
The image of a river offers a fresh way to express the dynamics of the life cycle of an enterprise’s architecture. Take a vertical slice through a river, from surface to river bottom, from shore to shore: the architecture of an enterprise’s software-intensive systems is akin to the instantaneous structure and behavior of a river captured in that slice. Alternately, consider a river segment, from that slice to a point upstream some distance and then to a point downstream an equal distance: the life cycle of that architecture is akin to the intentional and accidental morphing of those instantaneous architectures over a region of time. [….]
While most vessels will be piloted for specific missions, there might be larger ones whose purpose is to dredge the bottom, reshape the banks, or even redirect the channel. [….]
In a project of any size, it’s not a single individual who rechannels a river. It’s multiple people, who have a variety of roles and responsibilities towards the larger endeavour. Each person may have a different perspective on scenarios, leading to different design decisions that could have an impact on the whole.
Designing in not usually considered to be a linear process. If we look at design thinking, as described by Tim Brown (2008, 2011), there is (i) a series of divergent and convergent steps, and (ii) an interplay between analysis and synthesis. During divergence, choices are created; during convergence, choices are made. During analysis, problems are broken apart; during synthesis, ideas are put together.
Scenarios could learn to recognize these cycles in their development.
What happens during design? In our discussions, the distinctions between (i) designing with, and (ii) designing for, emerged. If we think about design with other human beings, we can be following a process of (i) designing with, i.e. coproducing outcomes, or (ii) designing for, i.e. taking accountability to produce a product. If we think about designing a systems with an environment, we can be (i) designing with, i.e. negotiating changes, or (i) designing for, i.e. establishing rules that could be subsequently followed.
A scenario engagement could be either with or for.
During the discussion, in trying to unravel what happens in the variances between expectations and real outcomes, the distinctions between uncertainty and risk arose. We attributed this to recently reading Ramírez and Ravetz (2011), but upon presentation, Jerry Ravetz disavowed the idea coming from him. In rereading the article, proper attribution should go to Knight (1921).
… Uncertainty must be taken in a sense radically distinct from the familiar notion of Risk, from which it has never been properly separated. The term “risk,” as loosely used in everyday speech and in economic discussion, really covers two things which, functionally at least, in their causal relations to the phenomena of economic organization, are categorically different. [….] The essential fact is that “risk” means in some cases a quantity susceptible of measurement, while at other times it is something distinctly not of this character; and there are far-reaching and crucial differences in the bearings of the phenomenon depending on which of the two is really present and operating. There are other ambiguities in the term “risk” as well, which will be pointed out; but this is the most important. It will appear that a measurable uncertainty, or “risk” proper, as we shall use the term, is so far different from an unmeasurable one that it is not in effect an uncertainty at all. We shall accordingly restrict the term “uncertainty” to cases of the non-quantitative type.
Dealing with uncertainty that is non-quantitative, as compared with risk that is quantifiable, may require different approaches.
Having two dimensions led us to the exercise of trying to fill out the 2×2 matrix.
- Designing with uncertainty calls for agility: when negotiating through turbulence, we wouldn’t want to venture much farther ahead than we can see.
- Designing for risk calls for hedging: we can quantitatively estimate probabilities of outcomes, and insure ourselves against negative consequences.
- Designing with risk calls for betting: we know that there’s no reward without risk, so we can play the game with a strong hand when the odds are with us, and a cautious hand when the odds are against us.
- Designing for uncertainty calls for resilience / structure: we can’t quantify the outcomes, but we may be able to anticipate the damages and prepare to respond rapidly should they occur.
The Round 3 discussion was up against the deadline to complete for the day, so the 2×2 matrix is a starting point for additional reflection.
The idea of iterative discovery led to a whiteboard drawing where scenarios and design were enclosed inside repeating cycles. Design has generally been considered iterative; scenarios less so. If design happens incrementally, what is the time horizon in which scenarios should be framed? The time horizon may not be a single point, but multiple points which have to be considered simultaneously and dynamically. The future may be described as unfolding.
Unfolding is part of an idea of “unfolding wholeness” by architect Christopher Alexander (1996, 1999).
It turns out that these living structures can only be produced by an unfolding wholeness. That it, there is a condition in which you have space in a certain state. You operate on it through things that I have come to call ‘structure-preserving transformations,’maintaining the whole at each step, but gradually introducing differentiations one after the other. And if these transformations are truly structure-preserving and structure-enhancing, then you will come out at the end with living structure.
Just think of an acorn becoming an oak. The end result is very different from the start point but happens in a smooth unfolding way in which each step clearly emanates from the previous one.
Very abstract, I know, but the punchline is the following. That is what happens in all the living structures we think of as nature. When you analyze carefully just what’s going on and how things are happening in the natural world, this sort of structure-preserving transformation tends to be what’s going on most of the time. That is why, when nature is left alone, most of the time living structure is produced.
However, in the approaches that we currently have to the creation of the built world and the environment (planning design, construction, and so forth), that is simply not what is happening. The process of design that we currently recognize as normal is one where the architect or somebody else is sort of moving stuff around, trying to get into some kind of good configuration. Effectively this means searching in an almost random way in configuration space, and never homing in on the good structure.
That is why the present-day structure of cities, buildings, conventional halls, and houses are so often lifeless. The processes by which they are generated are — in principle — not life creating or life seeking. If a process doesn’t go in the structure-preserving way that I’m talking about, the result is never living structure.
For scenarios to come to life, we may have consider how the design unfolds over time.
The multi-round discussions of the Oxford Futures Forum leaves each of the participants with a different perspective on their learning experience. The second day concluded with a “Projects and Initiatives Market”, which represents strategic dialogues amongst participants to find like-minded partners who may be interested in pursuing a collaboration. A small group of us signed up to coauthor an article. The contents are yet to be determined. The article could be about some of the discussion captured above … or possibly a synthesis of the original abstracts submitted before the event. We’ll have to work on some scenarios for future joint design.
References
Alexander, Christopher. 1996. “Patterns in Architecture” presented at OOPSLA ’96, October 8, San Jose, California. https://www.youtube.com/watch?v=98LdFA-_zfA.
Alexander, Christopher. 1999. “The Origins of Pattern Theory: The Future of the Theory, and the Generation of a Living World.” IEEE Software, 16 (5): 71–82. doi:10.1109/52.795104.
Booch, Grady. 2009. “Like a River.” IEEE Software 26 (3): 10–11. doi:10.1109/MS.2009.74.
Brand, Stewart. 1994. How Buildings Learn: What Happens after They’re Built. New York: Viking. http://books.google.com/books?id=zkgRgdVN2GIC.
Brown, Tim. 2008. “Design Thinking.” Harvard Business Review 86-92 (6): 84. http://www.ideo.com/by-ideo/design-thinking-in-harvard-business-review.
Brown, Tim. 2011. “Why Social Innovators Need Design Thinking”. Stanford Social Innovation Review. Technology & Design. http://www.ssireview.org/blog/entry/why_social_innovators_need_design_thinking.
Eclipse Foundation. 2010. “Open Unified Process — Getting Started: Basic Process Concepts.” http://epf.eclipse.org/wikis/openup/.
Knight, Frank H. 1921. Risk, Uncertainty, and Profit. Boston, MA: Hart, Schaffner & Marx; Houghton Mifflin Co. republished at http://www.econlib.org/library/Knight/knRUP1.html.
Mintzberg, Henry. 2005. “Are Strategies Real Things?” FT Press. Management & Leadership. http://www.ftpress.com/articles/article.aspx?p=378964&seqNum=5.
Ramírez, Rafael, and Jerome Ravetz. 2011. “Feral Futures: Zen and Aesthetics.” Futures, Special Issue: Community Engagement for Sustainable Urban Futures, 43 (4): 478–87. doi:10.1016/j.futures.2010.12.005.
Royce, Winston W. 1970. “Managing the Development of Large Software Systems: Concepts and Techniques.” In Proceedings, IEEE WESCON, 328–38. IEEE. http://dl.acm.org/citation.cfm?id=41801, reprinted in ICSE ’87, Proceedings of the 9th International Conference on Software Engineering.
