|
organic planning |
|
organic planning - the third way
organic planning - principles
|
|
"Le plan est le générateur.
Sans plan, il y a désordre, arbitraire. Le plan porte en lui l’essence de la sensation." Le Corbusier Vers une Architecture |
This document is not about the design of individual artefacts, satisfying a set of requirements, built by individual projects. It is about programmes of designing many coordinated systems, satisfying the complete requirements of a large organization, forming a ‘whole’.
What do we mean by the word ‘whole’? It denotes coherence, lack of fragmentation. If a structure is whole, its parts are also in a sense whole, not fragmented but coherent. This may be because all parts are guided by the one single process, by a development programme which follows the same principles at all levels, from the preliminary sketch to the tiniest detail. Such a development programme will of course contain many projects, in series or in parallel, each developing one part. Any two parts are related, in sometimes very complex and indirect ways, but remain compatible, consistent. And yet the boundaries between parts can be clearly perceived, each part is visible and makes sense on its own, as well as within a wider context.
In most development programmes today, this vision of coherence is at best only partly achieved. We can analyse what goes wrong; more importantly, we can identify what improvements can be made in planning and executing these programmes, subject to the culture and environment of the organization.
Common sense and experience shows that such wholes cannot be implemented in a single step. Such projects are too large to be successful, producing a system too monolithic to be meaningful. The best we can achieve allows the whole to grow in many steps, over many years. Its final form cannot be predicted, except perhaps in ambiguous generalities, partly because the form is sensitive to details that cannot (and should not) be worked out in advance, but partly (and more importantly) because the organization itself learns during the development - the systems do not merely support the organization but transform it, or rather allow it to transform itself.
There are two common approaches to such multi-system design, with multi-project development. One can be called hacking, and the other can be called grand plans..
Hacking means that each system or individual component is built piecemeal, according to its own needs alone. Its features are determined by its direct costs and benefits. Each project is started and steered in isolation of other projects; communication between projects only takes place if of immediate benefit to the projects themselves. Piecemeal growth, by itself, will not create coherent wholes. This is exactly why people produce plans.
This is not to dismiss the value of the hacker's craft. Professional hackers can produce items of extreme elegance and beauty, as well as great power. The fragmentation doesn't come from the craft itself, but from the planning and management framework (or its absence).
Grand plans means that each system is built to fit a prearranged position, within a preconfigured framework or blueprint. The aim of such planning is to create coherent wholes in advance, and thereby provide order and organization in the large. The trouble with this form of planning is that it often fails to achieve the sought order. In the worst case, such a plan can be a mixture of meaningless generalities and ill-considered rigidities.
It is worth noting here an important ambiguity in the word ‘plan’. This word may be used to refer to a preconfiguration or blueprint, as in a building plan or an urban development plan. It may also refer to a scheme or schedule of activity, as in a military plan of action, or development programme. It may even refer to a combination of both.
The architect Christopher Alexander developed an organic planning approach originally for the purposes of town planning (as an alternative to the top-down approach adopted by both Ebenezer Howard and Le Corbusier). He uses a metaphorical language to describe the intended results: whole, repair, fabric, centre, healing. We shall adopt his metaphors, and then try to define what they mean for Component-Based Business.
The overriding principle is that every project must ‘make whole’. It should repair and maintain existing wholes (this implies respect for the coherence of existing structure, although a project may abandon any particular mechanisms); it should create new wholes; it should establish a continuous fabric of wholes around itself. Thus a good project is not merely fabricating new fabric, but repairing and patching torn/worn places in the existing fabric. (Christopher Alexander calls this ‘healing’.)
(The wholes are of course sociotechnical ones. This means that there are several perspectives on wholeness, including the social and the technical. A range of stakeholders must perceive order and stability in the result.)
Each project has a ‘centre’. Around this centre is arrayed several other, smaller centres. The rule is that, as one such centre is produced, it must contribute to larger structures, and also bring together smaller structures - it must be both unifying and unified.
|
There is a much deeper notion of centre
than
that implied in what I originally wrote here.
It is connected with Borgmann's notion of focus - focal things and practices. |
For another example, consider a project centred around the issue purchase order process. It will bring together aspects of supplies, contracts, subcontracts, service contracts and perhaps even insurance policies. It therefore unifies several views of the same process. And at the same time, it contributes to a larger structure, containing deliveries and invoices and payments to suppliers.
In general, an object contributes to a larger structure by being a subtype of a more general object, or by playing a role shared with other objects. And a process contributes to a larger structure by taking part either in the lifecycle of a given object, or in a control loop. Or both.
Peripheral objects will contribute by being part of the horizon of a central object, or by providing a supplementary information structure (e.g. an historical or geographical breakdown). Peripheral processes will contribute by establishing the preconditions for a central process. But these peripheral objects and processes become in turn the centres of their own, smaller areas.
Thus we can restate our goal as follows: to weave a fabric of centres, such that each centre supports one or more larger centre, and is supported by smaller centres. Furthermore, the fabric should be complete: there should be no ‘negative space’.
In traditional design of computerized information systems, the spaces between systems are often merely the areas that nobody has bothered about. This is negative space. But the redress for this ill is not total automation, which leaves no space at all, but deliberately created space. Space in which the system users can be imaginative and innovative, freed of the burdens of repetitive and inflexible administration. This is positive space.
(Although these concepts of positive and negative space are metaphorical, they can be linked to concepts being developed in Scandinavia and elsewhere, about human-centred systems design. The relevance of these concepts increases as IT projects have shifted in emphasis from the automation of clerical transaction processing, and towards cooperative decision-support systems. Many people now believe that user-friendliness is profoundly affected by system scope and structure, and is not simply a matter of having the right front-end.)
Systems development principles
In this approach, projects are selected,
planned and managed according to a set of principles. Each organization
may define its own principles, but here is a reasonable set to start from:
 |
Size matters | Provide firm guidelines to avoid excessively large projects.
A maximum project size may be defined
in various ways, and will vary from one organization to another.
Restrict projects to what is feasible with existing project management skills and procedures. You may hope to enhance these skills and to redesign these procedures, but don't start planning ambitious projects until you are sure you've got the capability and infrastructure is in place. |
|
Balance matters | Maintain a balance between small and medium projects.
There
is an ideal mixture of project sizes in progress at a given time. Within
the maximum size already defined, there will be large, medium and small
projects. A rough guideline should be established for the relative numbers
of such projects, or for the proportion of resources devoted to projects
of different sizes. (This will enable, among other things, a skills development
path for project managers.) There should also be a mixture of high-risk
and low-risk projects, and a mixture of urgent and non-urgent projects.
Time-critical projects should be mixed with innovation-critical projects,
and projects requiring much attention from senior management should be
mixed with projects requiring relatively little attention.
Balance the projects evenly across the subject domain. The projects in progress at the same time should not all be concentrated on the same small corner of the overall fabric, but should be distributed between different functions, different groups of users. This allows not merely political balance but also systems balance and resource balance. |
|
Stay centred. | Each project must
have an identifiable centre, and contribute to an identifiable larger whole,
more significant than itself. Those managing the project must be able to
show how their project will contribute to the overall fabric. The growing
awareness
of such larger wholes provides a helping hand towards our goal. Some of
these wholes may be predicted, but some may emerge as you go along, and
must be allowed to develop without preconceptions or forcing.
A larger whole has a discernible life cycle. First, one project hints at a more general structure, which it is outside its own scope and terms of reference to explore. Then other projects help to indicate the outlines of the larger whole, which gradually takes shape as each project enhances our understanding of it. A series of further projects then completes the whole. A project will usually play simultaneous but different roles with respect to different larger wholes. Each project should therefore aim to do three things. First, it should help to complete at least one major whole that is already clearly defined. Second, it should help to pin down some other, less clearly defined whole(s), previously only hinted at. Third, it should hint at some entirely new whole(s), which will only clearly emerge with later projects. A project may use both ‘development’ and ‘maintenance’ tools and techniques. |
|
Build a network of centres | Each project should
be expressed clearly in advance. A communicable vision of the project can
be provided through a well-defined portion of the conceptual structure,
which the project is to analyse, or for which the project is to design
a system.
Each project must create, and each system must have, coherent and well-shaped decision space next to it. Each system must either be a simple and compact unity, or it must be made up of several simple and compact parts, one of these being major and the others minor, hanging onto it. |
|
Bridges serve systems
systems serve users. |
Interface bridges with other systems are built afterwards, incrementally. The bridges should serve the systems, and the systems serve the users. You don’t design the systems to serve the bridges. |
|
Evolve and grow the programme. | The programme will evolve as the organization develops new concepts. Each project may feed new insights back to the programme, making it richer and more powerful. |
A similar evolutionary approach
has been tried by Christopher
Alexander and colleagues in California. They developed a set of principles
for urban development, and then conducted a large-scale simulation to test
the principles. A group of architecture students surveyed a real area of
the city, discovered what kinds of buildings would be required in a redevelopment
of the area, and used the principles to grow a series of coordinated designs,
without any zoning or grand design. Although such an artificial experiment
cannot be regarded as a definitive proof of the approach, the obvious merit
of the models and drawings give some plausibility to its claims, at least
as an alternative to traditional town planning.
Empirical experience with the approach recommended here is admittedly limited. The plausibility of the approach rests on the known difficulties with the other approaches, and on the analogy with architecture and urban development. But the arguments for the grand planning approach are usually based merely on the comparison with the hacking approach. This statement of a third option should at least serve as a challenge for the proponents of grand plans to develop a new and stronger justification.
| Chris Alexander et al, A New Theory
of Urban Design
Oxford University Press, New York, 1987. |
Alexander shows how large complex yet coherent structures
can emerge from an organic process.
|
|
||
 Stewart
Brand, How Buildings Learn
Viking Penguin 1994. |
Brand shows how buildings adapt to changing requirements
over long periods. The book inspired a 6-part TV series by the BBC.
Comments critical of the architect Lord Rogers have been removed from the British edition. |
|
||
| Kevin Kelly, Out of Control
UK edition, Fourth Estate, 1994. |
Kelly shows how large complex systems maintain stability
and other emergent properties, outwith human management.
|
|
||
| Richard Veryard, The Component-Based Business | In this book, I show the business opportunities and challenges of new modes of system constructing and evolution. |  |
| top |  |
|
|
Copyright © 1994-2001 Veryard Projects Ltd http://www.veryard.com/sebpc/planning.htm |
