Top-down strategy

Explicit use of the top-down strategy

Sources
Internal links Engineer-it Strategies
Papers The Queensferry Bridge

In real world problems, the dominant situation is non-determinate i.e. it is likely that there is no solution that will fully satisfy the requirements. 

In such situations the basic, top-down, strategy is: propose a possible solution and assess whether it will be satisfactory - or more generally: identify a set of solutions and find the most appropriate one to use.  This is the only feasible strategy for non-determinate contexts and may also be needed when the situation is determinate.

For examples of non-determinate and deteminate contexts see: To Engineer (page 5) and The discipline of critical thinking (page 2).

Most decisions are based on the use of the top down strategy e.g. when you are faced with alternatives when making a purchase. It is normally used tacitly i.e.not based on a formal process. However, when working with complex uncertainty and especially where the outcome may affect others, in order to conrol the risk, it is necessary to be explicit about the actions that you take i.e. a formal approach must be used.

An internet search on ‘design process’ or ‘problem solving process’ will give a lot of hits but the processes identified will all be essentially the same. This is because they refer to the top-down strategy that follows logically from the need to postulate solutions and then assess them.

The strategy is used for an overall project and for details i.e. is often used recursively.

Figure 1 Activities in the top-down strategy

Figure 1 shows fundamental activities in the explicit top-down strategy:

• Inception where information about the context is gathered and a Requirements Statement is drawn up. Proposals are assessed against the requirements and it is therefore essential that they are appropriate.
• Conception where options are identified, assessed against the requirements and a decision is made as to the option to by used.
• Production where the solution is developed and implemented
• Review and revise The process is not normally linear.  It is kept under constant review and, although ‘getting it right first time’ is a goal it often necessary to backtrack sometimes to a plan B.

The amount of resource allocated to these activities depends on the level of risk involved.

Inception

Programme

A programme of work (i.e. a plan) should be established that defines the tasks and time frame. It should include scheduled reviews of progress and performance.

Reviews

Team members, everyone inovolved, should operate in a critical thinking mode where all issues are under constant reveiw. Constantly ask and respond to questions and challenge the efficacy of what is being done. At formal review sessions, progress in relation to the programme and in relation to satisfying the requirements is considered.

Information gathering

Typical needed information includes: Records of success or failure in similar contexts. Identification of relevant legislation, etc.

Requirements

Being clear as to the requirements is a critical objective.

A written Requirements Statement should be established with a corresponding checklist. The checklist should be kept 'at the elbow' of all team members and outcomes should be regularly checked against it.

Principles for requirements include:

• The requirements should be in terms of the function that is to be achieved and should normally avoid reference to solutions. For example for assessing the problem of access across the river Forth in 2007, Transport Scotland did not start with a set of bridge options. They started with the a 'crossing' concept that covered tunnels and causeways as well as bridges. Another example: there is an EU directive for member countries to have a proportion of renwable energy in their electricity systems. Using energy from renewable sources is a solution strategy. The functional requirement is to reduce emissions and the directive should address that reduction, leaving it to member states to decide on the best strategies for achieving it.
• Do not set a numerical goal unless there is a feasible plan to achieve it . Focussing on a single goal to the detriment of the other goals is a high risk strategy.
• While every attempt should be made to establish the full set of requirements at the outset, it is common for new items to emerge as the process develops. The requirements statement and checklist should be kept up-to-date.

Client brief

When a client issues a brief, seek to ensure that it does address all the issues that are relevant to the client. If necessary work with the client to develop the brief

Using the client brief as a basis, develop the requirements statement to address technical and other issues that may not be directly relevant to the client.

Conception

Option identification and analysis

At the outset, all options should 'be on the table'. In some situations a very large number of options may be needed. For example, for the design of a £120m Water Treatement Works in Glasgow in 2006,:

“Over 100 technical staff from 25 different disciplines considered 6000 possible options and 17 potential development areas were looked at in great detail. In total some 196 potential schemes were evaluated with respect to environmental impact, cost and risk."

In order to assess an option, information about it needs to be gathered. In design, for example, this means that each option has to be partially designed. The scope of this information is based on the needed accuracy for the assessment. For example, minimising cost is a normal goal and therefore each option needs to have a cost assessment that is accurate enough for comparison with other options.

Candidate options

The requirements should be divided into negotiable or non-negotiable categories. A candidate option must be able to satisfy the non-negotiable criteria. For example non-negotiable criteria should be set for the reliability of an electricity system. A list of candidate options should be drawn up.

Option assessment

Options table

	Options
Requirements	1	2	3
A
B
C

A formal approach to comparing the options against negotiable requirements may be used. For example, one can have a table of options against requirements.

Principles for using an options table include:

• If possilble, assign a numerical value (e.g. a cost value) in the cells of the table. If not, a qualitative assessment can be made e.g. a score of 1 to 5.
• Seek to create combined options using favourable features from across the set.
• Remove options from the table if they are clear losers
• Adding up scores for the options can give an overall score but unless this shows clear advantage for an option, one should be very wary of assuming that this is necessarily the one to be chosen. [needs better explanation]

Decision

It is important not to come quickly to conclusions about the choice of option. One should hold back and think about the relationship between the options and the requirements. For example, a team developing a TV advert may not decide on the final form of the advert until there only just enough time to produce it - in order to allow time for ideas to incubate.

The test proposals principle

"Only accept proposals that have been thoroughly tested: against the requirements; against the inherent risks; against other proposals. If a proposals is shown to be unacceptale, it should be rejected"

This is probably the most important principle in engineered processes. Neglect of its use is common in autocratic leadership and in government policy-making. It may be that: it is not possible to satisfy all the requirements or that all risks can be eliminated. Also it might not be possible to formulate alternative proposals. But if a less than satisfactory proposal has to be accepted, one should go forward with open eyes about the potential consequences of its adoption.

Production

At the production phase the chosen option is fully developed e.g. the design drawings and specifictions are completed or the final version of the advert is recorded.

Learning to use the top-down strategy explicitly

When you buy a pair of shoes, it is normal to think about what the attributes that you want for them, look at shoes in a few shops, pick out one or two that you might buy and then decide on a purchase. That is tacit use of the the top-down strategy.

An an exercise in practising to use the explicit top-down strategy, use it when purchasing a pair of shoes.

• Define the requirements - write them down e.g.: Cost: upper limit. Function: comfortable; intended use; durability; waterproof; sole friction, height of heel. aesthetics: style and material, colour;
• Shop around for candidate options
• Set up an options table and try different methods of ranking the options.
• Decide on your purchase.

There not a lot of risk involved in buying a pair of shoes. If you make a bad choice, the consequenences are likely to be of minor importance and therefore an tacit use of the top-down strategy is justified. But if the risk is high, the explicit approach is essential. Just how detailed the use of the strategy should be, depends on the level of risk. if you are designing a nuclear power plant you have deep focus on the use of the strategy.