Introduction Planning dimensions
Planning starts with broad assumptions which are steadily refined, as more information comes to hand. Planning typically proceeds from the broad to the detailed.
Planning is typically done from the general to the particular, from coarse to fine, in two directions (or two dimensions) (Figure 4.1) at the same time:
• In hierarchical levels involving breaking (the work in) projects into subprojects (for subprojects other than that based on stages), sub-subprojects, , activities, elements and constituents. Detail emerges with lower levels. Project work is dissected into manageable portions through work breakdown (discussed later).
• Over time. Detail evolves as the project progresses.
The launching point for the main project planning is at the time of estab-lishing the initial scope (Figure 4.1), which derives from the objectives and constraints. For each and all levels and at any time in Figure 4.1, a planning problem exists.
A plan near the top left of Figure 4.1 might be called a ‘project preliminary plan’ or similar name. It contains broad information on work method, resources, dates and so on. And it may be used as a basis for approval to do further project work, as might other plans at later stages.
As a synthesis problem
Planning is a synthesis problem. As such, there are multiple solutions (choices of control) possible. In most cases, planners are only after a sat-isfactory solution, or a solution that they can live with, and do not put
The planning process 123
Coarse Fine Coarse
Fine
Level
Stage Initial
scope
Final scope Detail evolves over time
Detail unfolds with project, subproject, ..., activity, element and constituent
Figure 4.1 Evolution of planning problems.
additional effort into searching for the optimal solution. A planner may also be under pressure to come up with quick solutions.
Planners are unaware of and do not understand the components of the synthesis problem, and so they never know where they are relative to the optimum. They are unable to vocalise or formulate the synthesis problem components. Such discussion goes to the very heart of current planning knowledge being in its infancy, and current planning education (read train-ing) being superficial and low standard.
As an iterative analysis problem
The solution of any planning problem via an iterative analysis mode involves the conventional steps in systematic problem solving or systems engineering.
Feedback occurs between steps in trying to refine the problem. (This is additional to the feedback that can occur between levels.)
Alternatives might be arrived at through the generation techniques used in a value management/analysis/engineering study, which aims at developing alternatives that perform a desired function but at a lower cost, or in a work study, which is concerned with the method and timing of work activities and their optimisation. Both value management and work study are no more than versions of systematic problem solving (Carmichael, 2004).
Case example – Small commercial buildings
This case example looks at one contractor’s procedures for plan-ning the construction of small commercial buildings involving minor
124 Conventional treatment from a systems perspective
earthworks, concrete work, stormwater drainage, steel fabrica-tion/erection and electrical fitout.
Three phases/types of planning – initial, detailed and ongoing – are used.
The initial or preliminary planning occurs during preparation of a tender. A program is developed for submission with the tender and to assist the estimating department in pricing the project; the program may be required to assist the owner to further assess the contractor’s offer.
The project duration may be set by the owner and it is a case of allocating sufficient duration to each activity so that the overall project is completed within the nominated duration.
The detailed planning does not occur until the tender has been successful. When a contract has been awarded, and within the first couple of weeks, a detailed construction program is developed. It is commonly a contract requirement that a construction program be submitted within 14 or 21 or 28 days of contract commencement.
Work on the construction program incorporates a review of the ini-tial program, specifications and drawings. After possible discussions with the site foreman, it is determined which activities of the initial program can be retained and which activities require further breaking down. The aim is to develop a program with sufficient detail that can be easily followed and updated. Experience helps in determin-ing activity durations and overlappdetermin-ing relationships to complete the project in the nominated time frame. This information is then input to a commercial project management computer package so that the critical paths, floats etc. can be determined and so as to have the pro-gram in a professional form for submission. The propro-gram is presented as a connected bar chart.
Ongoing planning of the project leads to updating the construc-tion program on a monthly basis and the preparaconstruc-tion of fortnightly programs (programs for the following two weeks). The fortnightly programs contain considerably more detail than the construction pro-gram and are usually updated on a weekly basis.
Planning problem components
The main components of any (optimal) synthesis problem (Figure 4.2), to which planning belongs, are (Carmichael, 1981):
• Model
• Objective(s)
• Constraints.
The planning process 125
Optimal synthesis (inc. planning) problem components
Model
Objective(s)
Constraints
Figure 4.2 Optimal synthesis and planning problem components.
Objectives and constraints are developed below. Models are developed separately (Figure 4.3):
• Hierarchical models – Chapter 5, Chapter 9
• Multistage models – Chapter 8. The project is broken down into stages, or equivalently the project duration is discretised
• Probabilistic models – Chapter 7.
These problem components are expressed in terms of control, state and out-put variables. The system notions of control, state and outout-put variables are central to the development of models and thinking for planning purposes.
Models
Hierarchical models
Multistage models
Probabilistic models
Figure 4.3 Model development in this book.
126 Conventional treatment from a systems perspective Control
Control is equivalent to a planning decision, action or input. The term
‘control’ is favoured here in place of decision, action and input. The planner exerts control on the project in order to bring about a desired project behaviour. The most obvious controls are work method, resource (people and equipment) selections and resource production rates. Work method, resource selections and resource production rates may be freely selected by the planner, subject to any constraints being present. The preferred controls are those that extremise the objectives.
State, output
The output describes external or observable response, performance or behaviour. Internal behaviour is usually given in terms of system state. By the nature of projects (in the stripped-back form treated in this book), the internal and external behaviour are the same. (The observation equation of control systems theory [Carmichael, 1981] becomes ‘output = state’.) There is a one-to-one transformation between output and state. The terms
‘output’ and ‘state’ become interchangeable when referring to projects, and there is no noise in the observation device. There are no observability (or controllability) (in the sense of Kalman) issues for projects thought of in a stripped-back form.
The most obvious states are the resources used so far (cumulative resources) or the cost so far (cumulative cost) and the production so far (cumulative production).
Disturbance
In most systems studies, there is something that prevents the hoped-for out-put being obtained exactly. Commonly this is because of a changing project environment brought about because of delays, disruptions, adverse climatic effects and so on. Collectively the corruption is referred to as disturbance below, though control texts may use the term ‘noise’ (Figure 4.4).
Disturbance
State (System)
Control/input Output
Figure 4.4 Schematic representation of control, state and disturbance.
The planning process 127
Example
Planning establishes how and what work will be carried out, in what order and when and with what resources (additionally expressed in a money unit).
Consider the simpler (subsystem) problem where it has already been largely established how the work will be done and with what type and number of resources, and at what resource production rates. As such, the controls available to the planner are the order or sequence of the work including when particular work items will be done.
This establishes when resources are used, or, if expressed in a mon-etary unit, when money is used.
What the planner is trying to influence is the utilisation of the resources (state variables), and thereby the duration of the work.
There may be constraints on costs, duration of the work and resource availability.
Ultimately, what the planner might be trying to achieve is a work sequence of minimum cost or minimum duration or a compromise between these two objectives.
A suitable system model is the time-scaled critical path network or connected bar chart, with development to resource plots and cash-flow diagram.
As the planner adjusts the sequence of work, so resource utilisations, alternative cash flows and project durations evolve. By a series of iterations, the planner settles on one particular sequence of work.
Using an optimal control approach, the components to the planning problem are:
Model – Time-scaled network, connected bar chart
Constraints – Related to work duration, costs, resource availabil-ity and resource production rates.
Objective(s) – (Minimum) cost and/or (minimum) duration.
(After Carmichael, 2004)
Simplifications to planning
Ideally, project planning should be carried out as a probabilistic (inverse) synthesis problem. However, the tools are not currently available for this as a stand-alone mathematical problem. The full planning problem and its solution are very complicated, requiring ingredients of creativity and
128 Conventional treatment from a systems perspective
Figure 4.5 Simplifications to make the planning problem more tractable.
experience. Instead, planning is simplified and made more mechanical in three main pragmatic ways as shown in Figure 4.5.
• Instead of solving the planning problem in a synthesis format, it is converted into an iterative analysis format. Analysis is much easier than synthesis, and if a good initial guess is made, then there may be only one iteration (or even zero iterations) needed to give a sufficiently good answer. Iterations may modify the method, resource usage and resource production rates until satisfactory (without necessarily being optimum).
For most planners, the step of generating alternatives is relatively straightforward without knowing how close to the optimum the guessed solution is.
In some cases, where the planner is feeling his/her way, the analysis may become a ‘what if’ or sensitivity analysis examining the impact of alternative controls.
• The project (work) is broken down (hierarchically) to lower level sub-projects, sub-subsub-projects, and so on to activities, elements and con-stituents. Subprojects may be chosen such that the interaction between subprojects is minimal and is commonly neglected, permitting sub-projects to be planned independently of other subsub-projects. The same holds true where multiple projects are combined on an organisation level. However, interaction at levels lower than subproject is commonly strong.
Interaction occurs because of the work method (implying an order/sequencing of work). Iterations (between levels) can largely be removed by the planner being aware of what is happening on other lev-els when solving an individual level problem. The levlev-els are uncoupled as far as possible, for tractability reasons, to make the level problems less complicated.
• The planning problem is assumed deterministic. The analysis is made deterministic. Estimates for resources, productions, durations, costs are made deterministic in nature. Future events (leading to both upsides and downsides) are anticipated. Where future events have
The planning process 129 a likelihood (uncertainty), this is incorporated into thinking akin to risk management; there some probabilistic analysis technique, such as Monte Carlo simulation, may be used, but more usually is handled deterministically through a ‘what if’ or sensitivity analysis.
Planning is always carried out over the full project time span. Planning stage by stage, without consideration of upcoming stages, could be expected to lead to a suboptimal solution.
Replanning
Replanning is carried out according to stages or at discrete points in time, but this follows from the nature of what replanning is. Replanning is no different in form to planning. The planning problem (for the remainder of the project) becomes better defined as the project progresses. Information assisting the planning problem could be expected to be better the less far into the future. Replanning is based on the remaining duration of the project using the current state of the project as initial conditions. A good plan allows for some flexibility and can be adapted to changing circumstances that may occur during a project. However, attempts are made to foresee potential influences in upcoming stages, and controls are chosen with these influences in mind. According to Machiavelli in The Prince: When trouble is sensed well in advance it can easily be remedied; if you wait for it to show itself any medicine will be too late because the disease will have become incurable.
Whether replanning is necessary or not is established through monitor-ing/sensing the project output (‘as-executed’) through time, and comparing this with the current baseline (planned’). The difference between the ‘as-planned’ and ‘as-executed’ values (together with an updated view of future influences) may then be used to indicate what controls need to be modified, that is, to help in the generation of alternative controls for replanning.
Planning at some stages may take on increased importance for differ-ent stakeholders, for example for an owner at project outset, and for a contractor when tendering and while undertaking the work.
Objectives and constraints General
Objectives and constraints derive from the value system of the project/
end-product owner. Objectives and constraints lead to scope, and other planning matters. Scope is selected based on stated objectives and con-straints. Without defined objectives and constraints, the ensuing scope and planning is ill-defined.
130 Conventional treatment from a systems perspective
The term ‘planning objectives’ can occasionally be found in writings on planning, but its intent is not in a systematic problem-solving sense, and hence is not used here.
The objectives and constraints carry through to all planning problems at all levels (project, activity, element and constituent) and over time. They may be decomposed to finer detail and stated more specifically for use in lower levels, and later times.
Objectives
There will be an identified need or want for some product, facility, asset, service etc. This end-product is achieved through a project.
The materialisation of the end-product can be performed, possibly, in an infinite number of ways. In systems studies terms, the problem is an inverse problem, and hence there is no unique solution.
The criteria by which the preferred materialisation of the end-product is selected are the project objectives. Scope and other planning consid-erations on projects follow.
In a similar idea, there are possibly an infinite number of versions of end-products. The criteria by which the preferred end-product is selected are the end-product objectives. Form, function, finishes etc of the end-product follow. The selection of the preferred end-product form is a design problem.
That is, on any project there are two types of objectives
• End-product objectives
• Project objectives.
See Figure 4.6.
Commonly, project objectives say something about project cost, project [duration] and deviation from specification, but other objectives are possible. And these may apply throughout the project (for example minimum deviation from specification), or at the final (terminal) point of the project (for example minimum [duration which is related to the project] completion time). That is, general project objectives will con-tain a component over the time domain of the project and a component at the final (terminal) point.
Objectives
End-product objectives
Project objectives
Figure 4.6 End-product and project objectives.
The planning process 131
Example issues included in objectives
End-product objectives and project objectives (and constraints) may relate, for example, to:
• Money (end-product – sales, benefit:cost ratio (BCR), net present valueNPV project – cost, budget )
• Duration (end-product – lifetime ; project – duration )
• Resource usage
• Quality issues
• Community acceptance
• Environmental (natural) effects
• Safety
• Risks
• Public impact
• Extreme event impact (floods, cyclones )
• Social impacts
• Geotechnical considerations.
These are expressed in terms of end-product matters or project matters, as the case may be.
Confusion can arise when people start expressing project objectives in terms of the end-product requirements or end-product objectives.
For any situation there may only be a single objective or there may be many objectives (multi-objective). Where there are multiple objectives, they may be non-commensurate and conflicting. One or more of the objectives may be more dominant than the others.
The solution of such multi-objective problems generally involves some subjectivity while the solution of the single objective problem does not.
Constraints
All projects have genuine constraints such as funding, environmental (nat-ural) and political. Constraints limit the range of controls possible; they restrict the options that are possible.
As with objectives, many people confuse a project constraint with an end-product constraint. End-product constraints may influence project con-straints (Carmichael, 2004).
The higher levels and early project stages constrain the choices in the lower levels and later project stages respectively. Detailed planning is estab-lished within the parameters of previous broader planning.
132 Conventional treatment from a systems perspective Constraints can be converted to objectives (and vice versa).
Example objectives (project, activity, element and/or con-stituent levels)
• (Minimum) impact of activities on the natural environment
• (Minimum) project duration
• (Maximum) utilisation of resources
• (Maximum) return on money invested (in project and end-product) – related to usage of available money.
Example constraints (project, activity, element and/or con-stituent levels)
• Availability of resources, of the required type and in the required quantities when needed; a smoothed requirement for resources
• Availability of money, in the required quantities when needed
• A certain specified amount of interaction with the community
• Complete the work for less than (money). Cost. Budget. Spending limitations. Profitability. Cash flow
• Hazards and local factors; safety issues
• Statutory, legal requirements; environmental considerations
• Allowable sound volumes
• Site space restrictions; resource movement, storage, access, work
• flowA lower limit on the standard of work; quality assurance
• Designated milestones. Deadlines. Project completion time (may be imposed or as-planned)
• Production/schedule delays due to, for example, funding approvals, regulatory approvals, site access limitations, manpower availability problems and weather problems
• Events that are required to happen at the right time
• Technical knowledge, capabilities
• Transport, delivery issues.
It is frequently the case that a duration constraint or a cost constraint will be binding in the planning solution. That is, the preferred planning solution will lie on either the duration constraint or the cost constraint.
The planning process 133 Care has to be exercised that any imposed constraint, especially an unre-alistic cost constraint, does not prevent the free choice of sensible controls (method, resources and resource production rates). A certain desired stan-dard/quality in performance may leave little flexibility in the choice of resources. In the extreme case, a constraint imposed without thought may be such that there are no feasible controls. Hence if the project proceeds in whatever form, the constraint will be violated; this may represent, for example, a financial loss or a completion time overrun, or the scope may have to change – ‘you get what you pay for’.
Case example – Fruit processor upgrade
This case example discusses the practices used within a company to assign resources to a project involving an upgrade of an owner’s exist-ing fruit processexist-ing. The upgrade involved civil, structural, mechanical and electrical work, and the completion date was fixed by the need to have the work completed and the fruit processor running when the
This case example discusses the practices used within a company to assign resources to a project involving an upgrade of an owner’s exist-ing fruit processexist-ing. The upgrade involved civil, structural, mechanical and electrical work, and the completion date was fixed by the need to have the work completed and the fruit processor running when the