Demanding Solutions: A Four-Zone Model of Technological Intervention

Richard Veryard, March 1997

This is a fairly theoretical view of technology change.
For a more practical description, please click here.

Summary

requirements - technology - quality - capability maturity - intervention

Requirements and technology - desire and demand

more Technology and Magic
Thinking Superstition

Technology and quality


Requirements engineering process

  
The requirements engineering process can be regarded as a progression. 

It starts with a sense of something lacking (e.g. from an organization or process or system). It proceeds via a vision or fantasy of what might compensate for the lack It concludes with an engineerable specification of an engineerable product or service.

lack -> vision -> specification -> product

Construction of a solution

The management theorist Elliot Jaques traces a similar view back to Hegel: 'A goal-directed episode begins with a sense of something particular which must be done. It may be stimulated from outside by some thing or occurrence which attracts our attention and which we then choose to pay attention to - by a chance encounter which must be followed through or by an invitation to take part in some event, or by an instruction to carry out an assigned task. Or it may be self-initiated, beginning with a lack, a felt need, a gap, a sense of something missing, an absence, and a wish that this gap or lack or absence did not exist. This sense of lack next begins to take shape as a desire - the Desire emphasised and written with a capital D by Hegel. Desire takes the form of wishing or willing the existence or the completion of something which can replace the lack or somehow complete or close the episode.' [Elliot Jaques, The Form of Time (London: Heinemann, 1982) p 112]
But although this may be the starting point for requirements engineering, much of the time is often spent working out what is lacking in the solution. The specification is itself always incomplete or incoherent or inadequate. This may be discovered when the product or service is being designed, or when it is delivered. The diagram shows a simplified view of this iterative process.  lack -> vision -> specification -> product or service

Iterated construction of a solution

And whence the demand?

  
During the requirements formulation process, the requirements owner is himself transformed: from a 'naive' client who articulates an infinite (imaginary, fantasy) demand for a magic solution, into a 'mature' client who articulates a moderated (symbolic, formal) desire for a realistic solution. schema Z

Parallel development of requirements and client

The 'maturing' of the client is a function of language. It is the putting into language of the solution that is important, transforming the vision into a requirement, and at the same time effecting a transformation in the client himself. This maturing of the requirements owner is a developmental process of which the requirements engineer needs to be aware, as it affects the relationship with the client, and may also well affect the nature of the contract - at least for the next system, if not for this. Indeed, this aspect of organisational learning as an outcome of a requirements process is one that is often unrecognised, but it is part of any engineering discipline to suggest and incorporate organisational learning improvements in the processes of that discipline. This transformation can be a highly fulfilling experience for the participants, as Christopher Alexander reports. 'Dr. Ryan told us, after his clinic was built, that this one week he spent with us, shaping the building, was the most important week he had spent in five years,- the week in which he had felt most alive.' [Christopher Alexander et al, The Timeless Way of Building (New York: Oxford University Press, 1979), p 453]


Quality and capability


Capability and intervention

  • The discourse of understanding is an analytical one, concerned with gaining systematic insight. It is also a catalytical one, concerned with stimulating the recognition of opportunities. This discourse is commonly associated with the consultant's mode of operation, talking about the underlying causes and structures, and building conceptual models.
  • The discourse of action is about decisive exploitation of knowledge in a specific context. This discourse is commonly associated with the behaviour of managers as agents, talking about the solutions, designing and planning actions for their construction and implementation. Debates between management and trades unions are commonly held within the discourse of action, with labour representatives using the language of management to discuss management decisions. (Of course, these debates are often conflictual, but even conflict requires a common language.)
  • The discourse of change is about 'symptoms', and their 'treatment', 'relief' or 'cure'. This discourse belongs to the organization itself, talking about a (presenting) problem or opportunity that requires attention or change.. (In many organizations it is a discourse of resistance - the cultural or technological legacies that serve to resist and frustrate any action.) This is what 'speaks' to the consultant.
  • The discourse of knowledge is about knowledge-as-product, which should be generalized or generalizable. That which can be illustrated or theorized in academic papers, contained in text books, taught to students, or even tested in examinations. This discourse belongs in part to business schools and universities, but is also partly contained within any 'learning organization', talking about the general scientific or practical lessons that can be extracted from the other three discourses (by induction), and then fed back in (by deduction).
  • These four discourses also correspond to a set of stereotypes: the superintelligent but passive consultant who appears in many anti-consultant jokes, the 'strong' manager who believes only in action and despises reflection, the organization that frustrates or counteracts any positive intervention, the business school that teaches simplistic frameworks and generalized slogans.

    Descriptions of the four-discourse structure often (or, as some would argue, always) tend to privilege one of the four discourses. For example, the title of the model ('Organizational Change') privileges the CHANGE discourse.

    Some of the interactions between discourses


    Negative discourses


    Zonal Issues

    more Zone Theory


    Medical intervention

    Four zone model applied to medical intervention


    Authority and knowledge

  • How much authority does the doctor need to take (for medical effectiveness)?
  • How much authority does the doctor want to take (for the doctor's psychological comfort)?
  • How much authority does the patient need/want/expect to give the doctor?
  • How much authority does the doctor inherit from the prevailing social institutions (including NHS bureaucracy, but also the socio-economic system as manifested through education levels and accent)?
  • How does the doctor's authority relate to his access to medical and pharmaceutical knowledge? How does the doctor refresh his/her knowledge? How does the medical community refresh its knowledge?
  • To which medical authorities does the doctor defer? How influential are the drug companies? How influential are the medical research trusts? How visible are these influences?
  • These questions are relevant to the doctor contract, but extend beyond this.


    Intervention and requirements


    Authority in organizational interventions

    Four zone model applied to technology transfer


    Roles and responsibilities

  • Desired and actual change is located in the user organization
  • The requirements engineer facilitates an understanding of the problem and what would count as a solution
  • Reusable knowledge is located with the technology supplier and his products
  • Action to adapt the technology solution to the user organization, and vice versa, may be coordinated by
  • an implementation manager (working for the user), and/or
  • a delivery manager (working for the technology supplier), and/or
  • an independent 'consultant'
  • Note that the model only depicts the process of implementation or delivery of a solution to satisfy a user demand. The arrows mostly go from right to left, from the suppliers to the users. This omits both the short-term feedback loops and the longer term marketing (requirements gathering) processes that guide the further development of technological products.


    Supplier demands

  • sufficient financial reward to cover the costs and risks (including future development)
  • additional 'sales capital', in terms of success stories and reference sites, as well as an improvement in the relationship with this customer, facilitating future sales
  • additional 'knowledge capital' to support future product development, marketing and sales
  • and, above all, a stream of interesting problems and opportunities.
  • Some large technology users have well-worked-out procurement policies which allow for deliberate intervention in the product R&D strategies of their key suppliers. This form of intervention can also be represented in a four-zone model.

    References

    This document is partially based on a paper for CEEDA 96, the 3rd International Conference on Concurrent Engineering & EDA, 18th-19th January 1996, Poole, UK. It also draws on the following papers:
    top

    home page

    contact us

    veryard projects - innovation for demanding change
     
    Content revised on March 6th, 1997.
    Technical edit: February 22nd, 2002
    Copyright © 1996, 1997 Veryard Projects Ltd
    http://www.veryard.com/tcm/ds4ztt.htm