9. Project Planning, Scope and Delivery Strategy

Introduction and Context

Property development is often described as a sequence of activities—acquisition, design, approvals, construction, marketing and handover. In practice, however, development projects rarely fail because one activity is entirely absent. They fail because activities are poorly defined, conflicting objectives remain unresolved, responsibilities are unclear, decisions are delayed, or the chosen delivery strategy is inconsistent with the project’s risk and value requirements.

Project planning provides the discipline through which a development idea is converted into an executable investment proposition. It establishes what the project is intended to achieve, what is included and excluded, how work will be organised, who has authority to decide, how progress will be measured and which delivery model will best coordinate the participants. Planning is therefore not merely the preparation of a programme or a list of tasks. It is a process of aligning business strategy, physical outcomes, financial constraints, regulatory obligations, stakeholder expectations and delivery capability.

In real estate, planning is complicated by uncertainty. Land and planning conditions may be incompletely understood; market demand may change; infrastructure capacity may be constrained; financing may depend on approvals; and design decisions may affect both construction cost and long-term operating performance. A robust project plan does not eliminate uncertainty. It makes assumptions visible, allocates responsibility for managing them and creates controlled points at which the project can be reviewed or redirected.

This chapter examines project objectives, scope definition, work breakdown structures, milestones, governance gates and delivery strategies. It also considers the relationship among time, cost, quality, risk and stakeholder requirements, since these dimensions must be managed as an integrated system rather than as separate targets.

Learning Objectives

By the end of this chapter, the learner should be able to:

1. formulate clear and measurable objectives for a property development project;

2. distinguish project scope from product scope and explain the importance of scope boundaries;

3. develop a work breakdown structure suitable for a real estate project;

4. identify milestones, dependencies, critical activities and governance gates;

5. compare principal delivery models and select an appropriate strategy;

6. analyse trade-offs among time, cost, quality, risk and stakeholder requirements;

7. apply planning and governance principles to a development scenario; and

8. recognise common planning failures, ethical risks and the contribution of digital tools.

From Business Intent to Project Objectives

A project begins with a business intention, but an intention is not yet a project objective. Statements such as “develop a landmark mixed-use scheme” or “maximise the value of the site” provide direction but cannot guide detailed decisions unless they are translated into measurable outcomes.

A project objective should specify the desired result, the relevant performance measure and, where possible, the time or cost condition under which the result must be achieved. A development objective might therefore be expressed as: “Obtain planning approval for a 25,000-square-metre mixed-use scheme by September 2027, within the approved pre-development budget, while achieving the specified affordable-housing and sustainability commitments.”

Objectives normally operate at several levels:

• Strategic objectives express the contribution of the project to the development company’s portfolio, regeneration strategy, social purpose or investment policy.
• Commercial objectives concern revenue, yield, development margin, absorption, valuation, funding conditions or exit arrangements.
• Product objectives describe the required asset, including use mix, capacity, quality, flexibility, accessibility and operational performance.
• Delivery objectives address time, cost, safety, procurement, constructability and certainty.
• Stakeholder and public-value objectives include community benefit, environmental performance, inclusion, infrastructure contribution and regulatory compliance.

These objectives may conflict. A high-quality specification can increase cost and duration; accelerated delivery can reduce design development time; a larger commercial component may improve financial returns but weaken planning acceptability. The project manager’s role is not to pretend that all objectives can be maximised simultaneously. It is to make priorities explicit and establish which constraints are fixed, which are flexible and which can be traded.

A useful hierarchy distinguishes the project purpose, success criteria, constraints and assumptions. Purpose explains why the investment is being undertaken. Success criteria define how achievement will be judged. Constraints are conditions that limit choice, such as a statutory deadline, funding covenant or site boundary. Assumptions are propositions treated as true for planning purposes, such as anticipated rents, utility capacity or approval timing. Assumptions should be recorded because they represent sources of uncertainty and may require validation.

Scope: The Boundary of the Project

Scope is the defined extent of work and the resulting deliverables. It answers two fundamental questions: what must the project produce, and what work is required to produce it? Scope is not synonymous with design detail. At an early stage, the scope may define performance, capacity and use without fixing every architectural solution.

Two forms of scope are particularly important. Product scope describes the characteristics and functions of the completed development: number and type of units, floor area, public realm, parking, energy performance, amenities and operational systems. Project scope describes the work required to create that product: feasibility studies, surveys, design, consultation, approvals, procurement, construction, commissioning, marketing support and handover.

A scope statement should normally include:

• the project purpose and intended outcomes;
• principal deliverables and acceptance criteria;
• site and development boundaries;
• inclusions and exclusions;
• key interfaces with external parties or adjacent projects;
• assumptions, constraints and dependencies; and
• the process for approving changes.

Scope boundaries are especially significant in property development because ambiguous interfaces create disputes. For example, “landscaping completed” may not establish whether it includes irrigation, public art, maintenance access, boundary treatments or adoption by a public authority. Similarly, “retail units delivered” may not clarify whether tenant fit-out, utility upgrades or statutory testing is included. The more precisely acceptance criteria are stated, the less likely that disagreement will arise at handover.

Scope Management and Change Control

Scope management is continuous. Changes may arise from planning conditions, market research, tenant requirements, design development, legislation, ground conditions or investor decisions. Not every change is undesirable. A disciplined project can benefit from controlled changes that improve value or reduce risk. The problem is uncontrolled scope growth, often called scope creep, in which additions are made without recognising their effects on budget, programme, approvals, procurement or operations.

A formal change-control process should identify the proposed change, its origin, rationale, alternatives, effects on cost and time, consequences for quality and risk, and the authority required for approval. A change register provides an auditable record. The principle is simple: no significant change should be accepted merely because it appears small in isolation. Its cumulative effect must be considered.

Organising the Work: The Work Breakdown Structure

The work breakdown structure (WBS) decomposes the total project scope into progressively smaller and more manageable components. It is a hierarchy of deliverables and work packages, not simply a chronological task list. A well-designed WBS provides a common language for estimating, scheduling, assigning responsibility, monitoring progress and controlling change.

At the highest level, a development WBS may contain land and feasibility, planning and stakeholder engagement, design, finance, procurement, construction, commercialisation, commissioning and close-out. Each major deliverable is then decomposed. For example, “planning approval” might include planning strategy, baseline surveys, environmental assessment, transport assessment, community consultation, application preparation, submission and response to conditions.

The WBS should satisfy the principle of 100 per cent scope coverage: collectively, its elements should represent all work necessary to achieve the approved project scope, while avoiding duplication. The lowest useful level is the work package, which should be sufficiently defined to estimate duration and cost, assign an accountable owner and verify completion. Excessive decomposition creates administrative burden; inadequate decomposition conceals dependencies and makes progress difficult to measure.

A WBS is different from an organisation chart and a programme. The WBS describes what must be delivered. The organisation chart describes who is involved. The schedule describes when activities occur and in what sequence. These structures should be linked but should not be confused.

A practical planning sequence is to:

1. identify the final asset and major deliverables;

2. break deliverables into sub-deliverables;

3. continue decomposition until work packages can be estimated and assigned;

4. define acceptance criteria for each important deliverable;

5. map responsibility using a responsibility assignment matrix; and

6. connect work packages to the cost plan, risk register and master schedule.

The responsibility assignment matrix, often expressed through a RACI model, identifies who is responsible for performing work, accountable for the outcome, consulted before a decision and informed of the result. It prevents the common assumption that attendance at a meeting constitutes ownership.

Time Logic: Activities, Dependencies and Milestones

A project schedule represents the logical relationship among activities. In a development project, design cannot be fully coordinated before essential surveys are available; a planning application may depend on environmental and transport information; construction procurement may depend on design maturity and funding approval; and occupation may depend on testing, statutory certification and utility connections.

Dependencies may be finish-to-start, start-to-start, finish-to-finish or, less commonly, start-to-finish. They may also be internal, external, mandatory or discretionary. External dependencies—such as utility authority decisions, planning determinations or lender approvals—require particular attention because the project team may not control them.

A milestone is a significant event or decision point with zero duration, such as land acquisition, planning submission, planning approval, financial close, contract award, start on site, practical completion or first occupation. Milestones are not merely dates placed on a chart. They represent evidence that a condition has been met or a decision can be made.

Critical path analysis identifies the sequence of activities that determines the minimum project duration. Activities on the critical path have little or no total float, so delay to them may delay completion unless corrective action is taken. In real estate, the apparent critical path may change as the project develops. A planning decision may initially dominate the programme, while later the critical path may run through design coordination, long-lead procurement or utility connection. Programme management therefore requires regular re-evaluation rather than reliance on the original baseline.

Schedule compression can be achieved through fast-tracking, in which activities normally performed sequentially overlap, or crashing, in which additional resources or expenditure are used to shorten duration. Both methods introduce risk. Fast-tracking may create rework; crashing may reduce productivity or increase cost. A professional recommendation must compare the value of earlier completion with the additional cost and risk.

Governance Gates and Decision Rights

Governance is the system through which authority, accountability, oversight and escalation are established. Project governance is particularly important in development because decisions involve substantial capital, public interest, regulatory scrutiny and long-term reputational consequences.

A stage-gate process divides the project into phases and requires a formal review before the next phase is authorised. Typical gates include:

• Gate 1: Strategic and investment concept—Does the opportunity fit the organisation’s strategy and risk appetite?
• Gate 2: Feasibility and land commitment—Are the site, market, planning, technical and financial assumptions sufficiently credible to proceed?
• Gate 3: Development definition and approval strategy—Is the brief mature, are stakeholders engaged and is the route to approval realistic?
• Gate 4: Investment and procurement authorisation—Are design, cost, programme, funding and risk sufficiently developed to commit major expenditure?
• Gate 5: Construction and change control—Is delivery performing within approved tolerances, and are changes being governed?
• Gate 6: Completion, operation and benefits review—Has the asset been safely handed over, and are the intended benefits being realised?

A gate is not a ceremonial presentation. It should be supported by evidence, including an updated cost plan, programme, risk register, design information, approvals status, market evidence, funding position and benefits assessment. The decision may be to proceed, proceed subject to conditions, defer, revise or stop. A willingness to stop an uneconomic project is a sign of mature governance, not failure.

Decision rights should be defined in advance. The project sponsor typically owns the business case and provides strategic direction. The project manager coordinates delivery and reports performance. The design authority protects design integrity and compliance. The cost manager controls cost information, while the commercial and legal functions manage contracts and claims. A steering committee resolves matters beyond the project manager’s delegated authority. Clear escalation thresholds are needed for cost variance, programme delay, safety events, scope changes and risk exposure.

Selecting a Delivery Strategy

Delivery strategy concerns how the project will be organised, procured, contracted and controlled. It should be selected after considering the project’s objectives and risk profile, not simply because an organisation has used a particular contract before.

Under a traditional design–bid–build approach, design is substantially developed before construction procurement. The client retains greater control over design before tender, but the process may take longer and the separation between designer and contractor can create interface risk. Cost certainty is improved only when the design and information are sufficiently complete.

Under design and build, a contractor accepts responsibility for both design and construction, subject to the employer’s requirements. This can simplify interfaces and support faster delivery, but the client must define performance requirements carefully. Excessive transfer of design responsibility without adequate briefing can produce quality disputes or an asset that meets the contract but fails the owner’s operational expectations.

A management contracting or construction management approach allows earlier involvement of the contractor and progressive procurement of work packages. It can suit complex or fast-moving projects, but the client retains more cost and coordination risk. These approaches require strong client capability and prompt decision-making.

Integrated project delivery and collaborative contracting seek to align the client, designers, contractor and specialist participants through early involvement, shared information and, in some arrangements, shared risk and reward. Such models can improve coordination where trust, transparent data and mature governance exist. They are not a substitute for clear scope or competent management.

A delivery strategy should assess at least the following dimensions:

• desired speed and certainty of completion;
• design maturity and likelihood of change;
• market capacity and contractor availability;
• client expertise and resources;
• allocation of design, ground, cost and programme risks;
• quality and operational-performance requirements;
• funding and lender conditions;
• regulatory and stakeholder interfaces; and
• whole-life value rather than only initial capital cost.

Risk allocation should follow the party best able to manage the risk. Transferring a risk to a party that cannot price or control it generally results in inflated contingencies, disputes or failure. Contract form must therefore be considered alongside capability, information quality and behavioural incentives.

Integrating Time, Cost, Quality and Value

The familiar project triangle of time, cost and quality is useful but incomplete. In property development, scope, safety, risk, carbon performance, stakeholder legitimacy and operational value are also material. A decision to reduce cost may affect durability, energy consumption, tenant satisfaction and future asset value. A decision to accelerate may increase defects or reduce the time available for consultation.

Integration requires a common baseline. The approved scope establishes what is to be delivered; the cost plan translates it into financial terms; the schedule establishes timing; the risk register records uncertainty; and the benefits framework explains why the outputs matter. These management instruments should be updated together. A scope change without a cost and programme review is not proper control.

Cost planning should distinguish land, professional fees, statutory charges, construction, finance, marketing, contingency, taxes and other development costs. Contingency should reflect identified risks and the maturity of information; it should not be used to conceal an unrealistic estimate. Forecasting should focus on the estimated final outcome, not only on expenditure incurred to date.

Quality should be defined through measurable requirements, not vague aspirations. Relevant criteria may include spatial performance, materials, maintainability, accessibility, energy use, acoustic performance, fire safety, durability and user experience. Quality assurance concerns the systems and processes intended to prevent defects, while quality control involves inspection and testing of actual outputs.

Illustrative Case: Riverside Exchange Development

Background

Riverside Exchange is an illustrative case involving a development company considering a 600-unit mixed-use scheme on a former industrial site. The concept includes housing, small retail units, a community facility and public realm. The site is close to public transport but has possible soil contamination, a constrained drainage network and strong community interest in affordable housing and open space.

Situation and Problem

The investment committee initially set a target of completing the project within four years and achieving a specified development return. The concept design expanded from 500 to 600 units after an early appraisal suggested that additional density was necessary to support infrastructure and remediation costs. However, the planning brief, cost plan and community commitments were not revised consistently. The project team also proposed appointing a contractor before the design had adequately addressed ground conditions and utility diversions.

Analysis

The project’s apparent schedule was attractive, but the underlying logic was weak. The additional units altered the scope, transport assessment, affordable-housing negotiation, fire strategy, servicing requirements and construction cost. The site investigation was incomplete, making the remediation allowance uncertain. The proposed early contractor appointment could provide buildability input, but it would not by itself resolve an immature brief or allocate unknown ground risk fairly.

A review identified four major uncertainties: the extent of contamination, the capacity of the drainage network, the planning authority’s response to density and the financial effect of affordable-housing requirements. These uncertainties were entered into the risk register with owners and investigation actions. The project was also divided into stage gates rather than treated as one continuous commitment.

Approach and Strategy

At the feasibility gate, the sponsor required completion of intrusive surveys, a utilities strategy, a revised market assessment and three development options: 500 units, 600 units and a mixed-tenure option with greater public realm. Each option was assessed against return, planning acceptability, carbon performance, infrastructure burden and delivery complexity.

The selected option retained a lower density than the original concept but improved the mix of unit sizes and public space. The scope statement defined the community facility, affordable-housing commitment, public-realm standard and infrastructure interfaces. A WBS was developed, with separate work packages for remediation, drainage, planning obligations and public-realm delivery. A responsibility matrix clarified the roles of the developer, local authority, utilities provider, design team and future operator.

The delivery strategy combined early contractor involvement with a later guaranteed-price construction contract, subject to agreed design and ground information. This avoided premature transfer of poorly understood risks. Governance gates were linked to planning submission, planning approval, financial close and contract award. The investment committee retained authority over density, affordable housing, total budget and material scope changes.

Outcome

The revised plan took several months longer before construction commitment, but it produced a more credible cost range and reduced the likelihood of major redesign. The planning submission was better aligned with community discussions, and the contractor’s early input improved the sequence for remediation and utilities. The project did not achieve the highest theoretical unit count, but the approved option offered greater planning resilience and a clearer basis for investment decision-making.

Learning Points

The case demonstrates that planning discipline can reduce apparent speed while improving actual delivery confidence. It also shows that scope, stakeholder requirements and financial appraisal must be updated together. Most importantly, an early commitment to construction cannot compensate for unresolved strategic and technical assumptions.

Common Failures, Risks and Professional Responsibilities

Frequent planning failures include beginning design before agreeing the brief, using optimistic approval periods, ignoring external dependencies, underestimating interface work, treating risk registers as static documents and measuring progress by activity rather than verified deliverables. Another common error is selecting a delivery model because it appears to transfer risk, without checking whether the market will price that risk efficiently.

Governance can also fail through unclear authority. If the project manager is accountable for the programme but lacks authority to approve design decisions, delay becomes institutionalised. Conversely, informal executive intervention may create unrecorded changes and undermine the agreed chain of control.

Ethical practice requires honest reporting of cost, risk and progress. Suppressing bad news to preserve approval or funding can expose investors, communities, contractors and future occupants to greater harm. Development teams must also consider conflicts of interest, procurement fairness, safety, accessibility, environmental impact and the distribution of benefits and burdens. Stakeholder consultation should not be presented as meaningful if decisions have already been closed without disclosure.

Regulatory compliance is a minimum condition, not a complete definition of quality. A project may satisfy a statutory requirement yet perform poorly in energy use, accessibility, maintenance or social value. Professional judgement therefore requires consideration of the asset’s whole life and its effects on users and the surrounding place.

Digital Planning and Emerging Practice

Digital tools increasingly connect scope, schedule, cost and design information. Building information modelling can support coordination and quantity extraction; common data environments provide controlled information exchange; dashboards can display approval status, cost movement, risk exposure and milestone performance. Geographic information systems assist site and infrastructure analysis, while scenario models can compare density, phasing and financial outcomes.

Automation and artificial intelligence may help classify documents, identify schedule risks, compare design alternatives or detect inconsistencies in project information. Their value depends on data quality, traceability and human review. AI-generated forecasts should not be treated as objective merely because they are computational. Sensitive commercial, personal or design information also requires appropriate security and governance.

Emerging practice is moving toward outcome-based briefs, whole-life carbon assessment, modern methods of construction, more collaborative procurement and increased attention to climate resilience. These developments reinforce rather than replace the fundamentals of scope clarity, accountable decision-making and integrated planning. New technology can accelerate poor decisions as efficiently as good ones if governance is weak.

Best-Practice Principles

Effective project planning in property development is supported by the following principles:

1. define the business case and success criteria before fixing the solution;

2. distinguish product scope from the work required to deliver it;

3. make assumptions, constraints and exclusions visible;

4. decompose the scope into accountable work packages;

5. link scope, cost, schedule, risk and benefits information;

6. use milestones as evidence-based decision points;

7. establish governance gates with genuine authority to proceed, revise or stop;

8. select delivery strategy according to risk, information maturity and capability;

9. allocate risks to parties able to manage them;

10. control changes through documented impact assessment; and

11. report performance honestly, including uncertainty and adverse trends.

Chapter Summary

Project planning converts a development intention into a controlled and reviewable delivery proposition. Clear objectives establish strategic, commercial, product, delivery and stakeholder expectations. Scope defines the project boundary, deliverables, exclusions and acceptance criteria, while change control protects the approved business case from unmanaged expansion. The work breakdown structure decomposes scope into measurable work packages and connects deliverables to responsibility, cost, risk and schedule.

Milestones and critical-path logic provide a basis for managing time, but schedules must be revisited as uncertainty changes. Governance gates create structured decisions about whether to continue, revise or stop. Delivery models—including traditional, design and build, management-based and collaborative approaches—should be selected according to project objectives, information maturity, capability and risk allocation. Throughout the process, time, cost, quality, safety, stakeholder legitimacy and whole-life value must be considered together. Digital tools can improve coordination and analysis, but only when supported by reliable information and professional governance.

Key Terms

Project objective: A defined result the project is intended to achieve, expressed through outcomes or measurable performance.

Success criterion: A condition or measure used to judge whether the project has achieved its intended objectives.

Scope: The total set of work and deliverables included within the project boundary.

Product scope: The characteristics and functions of the completed development.

Project scope: The work required to create, approve, construct and hand over the development.

Scope creep: Uncontrolled expansion of project requirements without corresponding approval or resource adjustment.

Work breakdown structure: A hierarchical decomposition of project deliverables and work packages.

Work package: The lowest practical WBS element that can be estimated, assigned and monitored.

Milestone: A significant event or decision point with no duration.

Dependency: A logical or external relationship governing the sequence of activities.

Critical path: The sequence of activities that determines the shortest possible project duration.

Float: The time an activity can be delayed without delaying a defined project milestone or completion date.

Governance gate: A formal review point at which authority decides whether a project may proceed.

Stage-gate process: A project control system that divides work into phases separated by approval gates.

Delivery strategy: The planned approach to organising, procuring, contracting and controlling project delivery.

Design and build: A delivery model in which a contractor accepts responsibility for design and construction under defined requirements.

Change control: The formal assessment, approval and recording of changes to project scope or baseline conditions.

Risk register: A structured record of risks, causes, effects, owners and planned responses.

Responsibility assignment matrix: A tool that maps project activities or deliverables to participant responsibilities and decision roles.

Review Questions

Short Answer Questions

1. Why should project objectives distinguish between purpose, success criteria, constraints and assumptions?

2. What is the difference between product scope and project scope?

3. Explain the 100 per cent scope coverage principle in a work breakdown structure.

4. What is the purpose of a governance gate?

5. Distinguish fast-tracking from crashing in schedule management.

Long Answer Questions

1. Explain how a property developer can translate a broad business intention into an integrated set of project objectives.

2. Discuss the role of the work breakdown structure in estimating, scheduling, responsibility allocation and change control.

3. Compare traditional design–bid–build, design and build, and collaborative delivery approaches for a complex mixed-use development.

4. Analyse how time, cost, quality, risk and stakeholder requirements should be managed as an integrated system.

5. Explain why governance gates are valuable in uncertain development projects and identify the evidence required at a major investment gate.

Analytical / Application Questions

1. A residential project is six months behind schedule because utility approval and planning-condition discharge were not included in the baseline programme. Diagnose the planning failure and propose corrective actions.

2. A client wants to add a community facility and increase the number of housing units after financial close. Design a change-control assessment covering scope, cost, time, risk, approvals and stakeholder effects.

3. Select an appropriate delivery strategy for a contaminated urban site with an immature design, a demanding completion date and a client with limited technical resources. Justify your recommendation and identify the risks that should not be transferred without adequate information.

22. Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes project scope from product scope in a property development?

A. Project scope concerns only construction cost, while product scope concerns only revenue.

B. Project scope describes the work required to create the asset, while product scope describes the asset’s characteristics and functions.

C. Project scope applies to consultants, while product scope applies only to contractors.

D. Project scope is fixed by law, while product scope is always negotiable.

Correct Answer: B. Project scope describes the work required to create the asset, while product scope describes the asset’s characteristics and functions.

Question 2

A project team adds tenant amenities during design without assessing their effect on cost, programme or approvals. This is primarily an example of:

A. Scope creep

B. Crashing

C. Float management

D. Benefits realisation

Correct Answer: A. Scope creep

Question 3

What is the principal purpose of a work breakdown structure?

A. To replace the project organisation chart

B. To identify only the activities on the critical path

C. To decompose project deliverables into manageable and accountable work packages

D. To determine the preferred construction contract automatically

Correct Answer: C. To decompose project deliverables into manageable and accountable work packages

Question 4

Which event is most appropriately treated as a project milestone?

A. Painting a typical apartment bedroom

B. Reviewing an internal email

C. Planning approval being formally obtained

D. A labourer arriving on site

Correct Answer: C. Planning approval being formally obtained

Question 5

Fast-tracking a project generally involves:

A. Adding contingency to the budget

B. Overlapping activities that would normally occur sequentially

C. Removing quality inspections

D. Transferring every risk to the contractor

Correct Answer: B. Overlapping activities that would normally occur sequentially

Question 6

At a governance gate, the most appropriate decision is based primarily on:

A. Whether the project team has produced attractive presentations

B. Whether evidence supports proceeding within approved objectives, risks and tolerances

C. Whether all uncertainty has been eliminated

D. Whether expenditure has already begun

Correct Answer: B. Whether evidence supports proceeding within approved objectives, risks and tolerances

Question 7

Which delivery approach normally gives a contractor responsibility for both design and construction?

A. Design and build

B. Traditional design–bid–build

C. Construction management by the client only

D. Direct land acquisition

Correct Answer: A. Design and build

Question 8

A risk should generally be allocated to:

A. The party with the least information about it

B. The party best able to control or manage it

C. The party with the smallest contract value

D. The regulator in every case

Correct Answer: B. The party best able to control or manage it

Question 9

In the Riverside Exchange case, why was early contractor involvement not treated as a complete solution by itself?

A. Contractors cannot contribute to buildability

B. It could not resolve an immature brief or unknown ground conditions without further investigation and governance

C. It always prevents planning approval

D. It eliminates the need for a cost plan

Correct Answer: B. It could not resolve an immature brief or unknown ground conditions without further investigation and governance

Question 10

Which practice best supports responsible use of AI in project planning?

A. Accepting AI forecasts without human review

B. Using AI only when it produces a shorter programme

C. Ensuring data quality, traceability, security and professional validation

D. Allowing AI to approve scope changes automatically

Correct Answer: C. Ensuring data quality, traceability, security and professional validation