CVEN9702 Chap.1 Planning Logic and Project Strategy
Planning Logic and Project Strategy
Planning in this course covers the method of work, activity timing and order, money, non-monetary resources and quality. The practical aim is not to predict every detail perfectly. It is to create a baseline that exposes assumptions, coordinates parties and supports monitoring, control and replanning. A useful plan keeps the approved baseline distinct from actual progress and the latest forecast.
What this chapter covers
- 01
Define the project finish condition before decomposing work
- 02
Move from objectives to work packages and then to activities
- 03
Record duration, resource and interface assumptions
- 04
Preserve baseline, actual progress and forecast separately
- 05
Use monitoring evidence to control and replan future work
- 06
Balance planning effort against the value of better decisions
Worked example · free
Plan a temporary site facility
- +1Define ready for use as completed access, live power and an accepted safety inspection.
- +1Place layout approval before fencing and the power application, which may then proceed in parallel.
- +1Make inspection follow both fencing and power because it cannot accept an incomplete facility.
- +1Track approval receipt, fence completion, energisation and the signed inspection record as completion evidence.
Key terms
- Planning baseline
- The authorised scope, timing and resource plan against which performance and approved change are compared.
- Work package
- A manageable block of project scope that can be decomposed into activities, responsibilities and measurable outputs.
- Forecast
- The latest evidence-based estimate of future timing and outcomes after actual progress and known change are considered.
- Replanning
- The deliberate revision of future methods, sequence or resources in response to new project information.
- Interface
- A dependency or handoff between packages, organisations, locations or technical systems that requires coordination.
Planning Logic and Project Strategy FAQ
Why should the baseline not be overwritten?
The baseline preserves the authorised intention needed to measure variance and understand why performance changed. Actual dates and the current forecast should be updated separately. A formal baseline change needs a visible approval and reason rather than a silent rewrite of history.
How much detail should a project plan contain?
Use enough detail to coordinate work, expose interfaces, assign ownership and measure completion. Detail added before major dependencies are understood creates false precision. Start with objectives and work packages, then deepen the plan where decisions and control genuinely need it.
What makes a planning assumption useful?
A useful assumption names the uncertain fact, the value used, its evidence, the consequence if it changes and the trigger for review. That structure lets the team challenge one input without losing the rest of the schedule logic.
What belongs in a basis of programme?
Record scope, calendars, access and approval assumptions, resource logic, the data date and unresolved constraints. Assign an owner and review trigger to each completion-sensitive assumption.
Exam move
Practise planning with a small real or invented construction package. Write the finish condition, divide the work into packages and identify every external approval, access restriction and specialist resource. For each activity, state its output, owner, duration basis, predecessor reason and completion evidence. Then create three columns for baseline, actual and forecast so the distinction becomes automatic.
Revise benefits of planning as actions rather than a memorised list: clarification improves decisions, early problem identification protects options, risk evaluation supports contingency, coordination resolves interfaces, resource optimisation improves efficiency and a baseline enables control. When answering a scenario question, explain what is missing and how it affects a decision.
Avoid claiming that more detail is always better. The best plan is detailed enough to support coordination and control, yet simple enough to maintain as facts change. Extend the exercise by writing a one-page basis of programme. Record the scope boundary, work calendar, assumed access dates, approval lead times, weather allowance, crew logic and the person responsible for each unresolved input.
Rank assumptions by their ability to change the finish rather than by how easy they are to document. Convert the highest-ranked assumption into a visible constraint with an owner and review date. At the first status point, preserve the original values, enter actual progress and explain every change to the remaining forecast.
If a baseline change is proposed, state the approving authority and the evidence that separates approved scope from execution variance. Rehearse explaining the plan to three audiences: the site supervisor needs tomorrow's workable sequence, the project manager needs forecast consequences, and the client needs a traceable commitment. The same schedule should support all three without silently changing its logic.
Finish by deleting any activity whose output cannot be described and splitting any activity that mixes unrelated owners or completion evidence. This editing test makes the work breakdown operational rather than decorative and reinforces why an auditable plan is a management system, not merely a drawing of dates.
