System Planning
The term system planning, as used here, refers to the management of the processes for implementing Engineer-it strategies such as the Top-down strategy, risk control, quantification. The efficacy of the processes used is a critical factor in success.
Process map
One way of representing the concept of system planning is to use a process map e.g. Table 1 shows a design process map. The columns are the stages in the Top-down strategy and the rows represent sub processes. For example, in a structural design process, main sub-processes are: cost, sustainability and technical assessment.
A process plan for a complete project such as the design of a building would include more stages such as Feasibiity, Construction, Operation, Decommissioning.
Table 1 Outline of a design process map (Outcomes are in green)
| 1. Inception | 2. Conception | Production | |
| Design programme | Prepare the design programme | Update the programme
Stage 2 review |
Update the programme
Final review |
| Input and Briefing | Gather information
Prepare the requirements statement / project brief Requirements statement |
Continue to gather information
Develop the requirements statement |
Use the requirement statement as a main reference in the proc esses' |
| Concept Design | Options analysis. Propose a solution
Options analysis report |
||
| Sub-process | Outcomes | ||
| Sub-process | Outcomes | ||
| Sub-process | Outcomes | ||
| Design Output | Verification report
Basic design outcomes |
Each outcome results from a process that starts with a set of requirements:
Requirements ----> Process ----> Outcome
To achieve a satisfactory outcome, it is therefore important that:
- the requirements are appropriate
- the process is well suited to delivering the outcome.
The work starts at the top left of the map with the definition of requirements and moves across the stages and down the sub-processes to achieve the basic project outcomes (e.g. in the case of structural design the basic outcome is in the form of drawings and specifications that define what the structure will be). Other outcomes are required that, for example, justify the choices made or show how risk was controlled. The row order of the sub-processes may not be significant.
The map is a simplified diagram of a real system plan. It does not show iterations that are common, especially at the concept stage.
Project Programme
The work of the project is controlled by a programme where tasks are defined and allocated and timelines are established.
The processes move down and across the table, ofen with iterations especially in options analysis, EachoOutcomes results from a process that starts from a set of requirements.
In his paper (p23) about how he developed a retinal scanner, Doulas Anderson wrote that it was necessary to have ‘a very detailed development plan based upon tackling risk first.’
Items in such a plan include:
- Task descriptions
- Task schedules.
- Manpower schedules
- Reviews
Core actions in preparing a project plan include:
- Break down the work into tasks.
- Estimate the time it will take to complete each task.
- Define the precedence of the tasks, i.e. decide which tasks can be carried out in parallel and which need to be handled consecutively.
- Identify any lead times needed for starting the tasks - e.g. where one needs to wait for information to be delivered.
- Identify critical tasks, i.e. those which if not done on time will cause delay in the overall completion
- Draw up a schedule for the work, typically using a bar chart which shows when each task should start and finish. Leave some slack in the system to allow for unforeseen circumstances.
- Record progress and update the task times as the work proceeds.
Task Assignment
When assigning a task, take account of (a) the competence of the person who is to carry out the task and (b) the need to train people to do the task.
Reviews
Regular review meetings should be included in the schedule to address
- Progress in relation to the plan
- Progress in relation to meeting the requirements