Top-down strategy

The basic, top-down, strategy is to propose a possible solution and assess whether it will be satisfactory - or more generally:to propose a set of solutions and identify the most appropriate one to use. 

Explicit use of the top-down strategy

Figure 1 Stages in the top-down strategy

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 control 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 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 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:

• At the start of the process, all options should be 'on the table' and therefore the requirements should be stated in terms of the function that is to be achieved avoiding reference to solutions. For example, for assessing the problem of access across the river Forthin 2007, Transport Scotland started by considering the use tunnels and causeways as well as bridges. After the decision to adopt a bridge solution had been made, the requirements were updated to be relevant to bridge construction. Another example: there is an EU directive for member countries to have a proportion of renewable 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

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 may need 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.

Test proposals

Weaknesses in proposals need to be actively identified and addressed.

A test proposals principle is: "Only accept proposals that have been thoroughly tested:

• taking account of all requirements, both objectives and constraints, addressing the complexity
• against other proposals
• using the most appropriate testing methods for the context
• by a multidisciplinary team, if that is needed
• by being open-minded, sceptical, not relying on intuition, avoiding bias
• using reliable evidence and logic to the limits of their potential"

This is probably the most important principle in system planning. It may be that it is not possible to satisfy all the requirements or that all risks can be eliminated. 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.

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.

Production

At the production phase the chosen option is fully developed.