opportunity and implementation
Computer in an electronic device
What is a devic?
The use of systems concepts and models forms part of a process of investigation that is often described in the literature of systems, design and decision-making as a ‘methodology’, where a methodology is a process of enquiry, not a method to produce a predetermined result.
A systems methodology has the following characteristics:
• It is, or it provides, the means for the investigator to draw up a plan for studying a situation. This encourages important avenues to be explored and considered.
• It is not a simple checklist of actions that will lead to the ‘right’ answer; instead, it poses open-ended questions that can be answered in a variety of ways.
• It is generally iterative; stages may well be passed through several times before the investigation is complete.
• It enables a statement to be made of the objectives of the study and allows these objectives to be reviewed and modified.
• It provides guidelines for tackling problems, based on proven experience with similar types of problem.
• It provides team members and others with a common language for discussing the project.
• It is a framework for setting objectives, timescales and cost targets for the project.
• It makes it easier to manage project progress, identify problem areas and put things right.
Systems methodologies developed from operational research work during the Second World War and from subsequent work on technical and social problems by the RAND Corporation and others in the United States. Since then, systems engineering methodology has developed.
Today there are two main generic variants:
• The hard systems approach - used when problems and opportunities can be clearly defined.
• The soft systems approach - used when there is little or no agreement about the problem.
The development of systems engineering methodologies will be discussed in detail in the following units but I will outline briefly the two major generic variants here.
The stages of the hard systems approach are illustrated in Figure 34 and simplified in Figure 35. The model shown in these figures was developed by the Open Systems Group from earlier work by de Neufville and Stafford (1974).
The stages ‘problem/opportunity’ and ‘implementation’ are shown in solid boxes because they occur in the real world. The other stages are in dashed boxes to indicate that they are thought processes.
For the sake of diagrammatic simplicity, two features of the hard systems approach are missing from Figures 32 and 33.
First, iteration between stages is not shown. The stages of the approach are shown occurring in a logical sequence - this orderliness is the essence of the methodology.
Jumping from one stage to another in a haphazard sequence is to be avoided. But there is always the possibility, and in some cases the necessity, of referring back to an earlier stage and then repeating subsequent steps.
This iteration can occur for two reasons:
• Subsequent work has uncovered a mistake in earlier reasoning or an area of uncertainty
• Something happens in the environment of the investigation that makes previous assumptions invalid.
The second feature missing from the diagram is agreement. After each stage, it is essential that all stakeholders:
• Agree that the work has been carried out correctly
• Agree with the aims, content, timescale and people involved in the next stage.
Each stage is described briefly in the following 3 units
The aim of the first stage is to identify and describe the problem or opportunity. While each stage depends on the success of the previous stage, it is the initial stages of a project that set the direction for the work as a whole. For this reason a clear definition and firm agreement on the problem or opportunity are essential.
Problems and opportunities are like two sides of a coin: one of them can always be formulated in terms of the other. The best way to distinguish between them is to think of a problem as an unwelcome deviation from a standard or expected state of affairs - its solution involves the restoration of the existing, satisfactory state of affairs an opportunity as a chance to improve on the existing state of affairs.
Having defined and agreed on the problem, it is necessary to decide on the system in which you consider it plays a part.
In practice the two stages are closely linked and the analysis of the existing system nearly always means a redefinition or refinement of the problem or opportunity. Identifying and defining the problem and the system or systems that relate to it are critical for the success of subsequent analysis.
This stage forces the project team to make explicit the objectives and constraints associated with the problem or opportunity. This is valuable for several reasons.
• It forces everyone concerned to clarify what they hope to achieve.
• The need to agree objectives and constraints can bring into the open disagreements that otherwise might emerge only at a later stage of the approach.
• The process of defining, elaborating and agreeing objectives and constraints helps to maintain commitment to the project.
• It lays the foundation for subsequent activities, since once the objectives and constraints have been defined it is possible to decide what is needed to achieve or avoid them.
Objectives and constraints can be quantitative or qualitative.
This stage explores the different ways of achieving the defined objectives. It is the most imaginative and free-thinking stage of the approach.
The idea is initially to generate as many ideas as possible, then to whittle the list down to two or three ‘definite possibilities’ that can be carried further in the development stage.
The hard systems approach emphasises the need to have measurable means of assessing the efficacy of any potential solution or design, but recognizes that this may not always be possible.
The objective here is to develop the routes to objectives generated in Stage 4 to the position where they could be implemented if the decision to go ahead were given.
This involves doing sufficient work on each option for technical and other details to be defined, and for costs and benefits to be assessed, and for a sound decision to be taken, while at the same time minimizing the time and resources devoted to the task.
While the identified objectives and constraints have been referred to constantly during the development stage, the testing stage of the approach is a more formal analysis of each option.
Its objective is to determine whether:
• The option will meet the operational objectives,
• It is technically feasible,
• It is organizationally feasible,
• It will meet the financial objectives.
You might imagine that after all that has gone before, the decision about whether to go ahead or not would be automatic, but this is rarely the case. There will still be much discussion and ‘fine tuning’ necessary to ensure that the proposal is acceptable. It is at this stage that any qualitative measures of performance are brought into play.
Implementation involves all the detailed design, development and installation tasks required to get the agreed proposal operating.
Figure 34 shows an arrow leading from ‘implementation’ to ‘problem/opportunity’; this recognizes that implementation is never the end of the story.
The successful completion of a project will give rise either to other opportunities or to a further set of problems that need to be tackled.