|
|
| (20 intermediate revisions by the same user not shown) |
| Line 1: |
Line 1: |
| The term ''System planning'', as used here, refers to the management of the processes for implementing [[Strategies for engineered outcomes|Engineer-it processes]] such as the Top-down strategy, risk control, quantification,.
| | Planning can be defined as the formulation and implementation of processes. The simple model of: |
|
| |
|
| It is useful to work with a process map e.g. Table 1. The columns are the stages in the ''Top-down Strategy'' and the rows represent sub processes. For example, in a [[Framework for structural design learning#Process mapping|structural design process]], main sub-processes are: cost, sustainability and technical assessment.
| | Input -----> process -----> outcomes |
|
| |
|
| Table 1 Outline of a project process map
| | prompts the observation that deep focus on the quality of the inputs and on the quality of the processes is critical for achieving successful outcomes. When working with complex uncertainty, it is necessary to ensure that the processes used are the most appropriate in the context. In ''system planning'', such focus is applied to the overall process and to the sub-processes. |
| {| class="wikitable"
| |
| |
| |
| |'''1. Inception'''
| |
| | '''2. Conception'''
| |
| |'''Production'''
| |
| |-
| |
| |'''Project programme'''
| |
| |Prepare the [[System Planning#Project Programme|project programme]]
| |
| |Update the programme
| |
| <span style="color:#FF0000;text-align:right;"> Stage 2 review</span>
| |
| |Update the programme
| |
| <span style="color:#FF0000;text-align:right;"> Final review</span>
| |
| |-
| |
| |'''Input and Briefing'''
| |
| |Gather information
| |
|
| |
|
| Prepare the requirements statement (i.e. the project brief)
| | System planning for structural design is discussed [[Structural design processes|here]]. The need for system planning for energy is discussed [[Energy planning|here]]. |
| | |
| <span style="color:#FF0000;text-align:right;"> Requirements statement</span>
| |
| |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
| |
| | |
| <span style="color:#FF0000;text-align:right;"> Options analysis report</span>
| |
| |
| |
| |-
| |
| |'''Sub-process'''
| |
| |
| |
| |
| |
| |style="color:#FF0000;text-align:right;" |Outcomes
| |
| |-
| |
| |'''Sub-process'''
| |
| |
| |
| |
| |
| |style="color:#FF0000;text-align:right;" |Outcomes
| |
| |-
| |
| |'''Sub-process'''
| |
| |
| |
| |
| |
| | style="color:#FF0000;text-align:right;" |Outcomes
| |
| |-
| |
| |'''Project Output'''
| |
| | |
| | |
| | |
| |
| |
| |
| |
| |style="color:#FF0000;text-align:right;" | Verification report
| |
| Project outcomes
| |
| |}
| |
| | |
| === 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 [http://info.iesis.org/papers/Journal+V156_web_secure.pdf 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 [https://eit.engineers.scot/index.php?title=Top-down_strategy#Requirements requirements]
| |
Planning can be defined as the formulation and implementation of processes. The simple model of:
Input -----> process -----> outcomes
prompts the observation that deep focus on the quality of the inputs and on the quality of the processes is critical for achieving successful outcomes. When working with complex uncertainty, it is necessary to ensure that the processes used are the most appropriate in the context. In system planning, such focus is applied to the overall process and to the sub-processes.
System planning for structural design is discussed here. The need for system planning for energy is discussed here.