Project Delivery · Project Control Methods
Starting Up a Project: Control Checks Before Initiation
Starting up protects the organisation from committing significant effort to an unclear or poorly owned idea. It converts a mandate into a concise project brief, outline justification, initial product definition, delivery approach, leadership structure and initiation-stage plan, then asks the governing authority whether the project is ready to be initiated.
Executive summary
What this guide enables
Starting up protects the organisation from committing significant effort to an unclear or poorly owned idea. It converts a mandate into a concise project brief, outline justification, initial product definition, delivery approach, leadership structure and initiation-stage plan, then asks the governing authority whether the project is ready to be initiated.
Learning outcomes
- Explain the purpose and lifecycle position of starting up a project.
- Recognise the entry triggers, control evidence and completion conditions.
- Assign activities and decisions to the correct governance, management and delivery roles.
- Tailor the process without weakening accountability, product focus or exception control.
Control guidance
Purpose and lifecycle position
The purpose is to ensure that the prerequisites for initiating a project are in place by answering a focused question: is there a worthwhile and viable idea that deserves the cost of detailed initiation? It is deliberately lighter than initiation. The organisation should learn enough to avoid launching a fundamentally weak project without attempting to design every control or delivery detail before authority exists.
Lifecycle position: This is the pre-project process between receipt of a mandate and the decision to authorise detailed initiation. The mandate may be a strategy action, problem statement, opportunity, feasibility finding, customer request or regulatory need. It can be brief, but it must identify a commissioning authority able to appoint leadership and make the initiation decision.
Control depends on the resulting decision and evidence, not on reproducing a particular flowchart. The process begins on a recognised trigger, uses current controlled inputs and ends with an explicit status, product, authorisation or request.
Control guidance
Entry triggers and prerequisites
Treat the trigger as the reason to act and the prerequisite as evidence needed to act safely. Confirm authority, applicable tolerance, status date and current product or plan versions; expose missing inputs rather than silently assuming them.
Project mandate received
A recognised authority states a need or opportunity and asks for project assessment.
Executive and manager appointed
Named people can own business value and coordinate startup work.
Sufficient discovery access
The team can consult users, suppliers, lessons and relevant organisational standards.
Initiation decision required
The authority needs a concise, evidence-based request before funding detailed planning.
Control guidance
Activity sequence
Activities may overlap or be combined, but each outcome must remain visible: what was considered, who acted or decided, and which authorised position now applies.
- 1
Appoint the business lead and project manager
Confirm one accountable business owner, a project manager for startup and initiation, their authority, availability and role descriptions.
- 2
Capture previous lessons
Seek relevant project and operational experience, record applicability and apply lessons to the brief, team, approach and initiation plan.
- 3
Design the project management team
Identify business, user and supplier interests, direction, management, delivery, assurance and support responsibilities needed for initiation.
- 4
Prepare the outline business case
State reasons, initial options, benefits, dis-benefits, cost and time ranges, major risks and why initiation expenditure may be justified.
- 5
Select the project approach
Compare plausible ways to create the product, including internal or external supply, reuse, build, buy, sequence and delivery method.
- 6
Assemble the project brief
Define project purpose, scope boundary, project product and acceptance, constraints, interfaces, approach, team and outline justification.
- 7
Plan the initiation stage
Define products, work, resources, controls, tolerance and cost needed to create a robust initiation baseline and decision.
- 8
Request authority to initiate
Present the brief and initiation-stage plan for approval, rejection, conditions or further discovery.
Control guidance
Management products and evidence
The record may be a document, workflow item, database entry or integrated view. Give every item a purpose, owner, status, update trigger and audience; protect baselines from silent change and ensure reports trace back to source evidence.
| Management product or evidence | Control purpose |
|---|---|
| Project mandate | Provides the commissioning need and initial authority. |
| Lessons log | Captures relevant experience and how it will influence the project. |
| Role descriptions | Clarify startup and initial governance accountabilities. |
| Outline business case | Shows why spending on initiation may be worthwhile. |
| Project product description | Defines the initial final product, quality expectations and acceptance. |
| Project approach | Explains the selected delivery solution and major alternatives. |
| Project brief | Integrates the foundation for the initiation decision. |
| Initiation-stage plan | Authorises the detailed work needed to prepare the project baseline. |
Control guidance
Roles, decision rights and assurance
Keep direction, day-to-day management, product delivery and independent challenge distinguishable. If compatible duties are combined, map responsibilities and add an independent decision or review wherever self-authorisation, self-acceptance or self-assurance would otherwise result.
| Role or level | Core responsibility | Decision or evidence |
|---|---|---|
| Commissioning authority | Provides mandate and appoints accountable business leadership | Authorises or rejects initiation |
| Business lead | Owns outline justification and governance design | Recommends whether initiation is worthwhile |
| Project manager | Coordinates discovery, brief and initiation plan | Produces the initiation request |
| User representation | Clarifies need, acceptance and benefit expectations | Contributes to product definition |
| Supplier representation | Tests feasibility, approach, estimates and capability | Contributes to approach and plan |
| Assurance or specialists | Challenge assumptions and mandatory constraints | Advise the initiation decision |
Control guidance
Interfaces and control logic
Map incoming evidence, outgoing authority and response deadlines so products or decisions do not stall between roles. Forecast breaches move to the tolerance-setting authority; baseline impacts follow change control; weakened justification returns to the accountable business authority.
- Do not begin significant delivery work under a startup mandate unless explicitly authorised.
- Keep the outline case proportionate but disclose uncertainty and major assumptions.
- Define the final product and acceptance before detailed initiation planning.
- Treat the initiation-stage plan as a genuine limited commitment with its own products and tolerance.
| Control question | Evidence to inspect | Decision or response |
|---|---|---|
| Is the input authoritative? | Version, status, owner, approval and data date | Use, clarify or reject the input |
| Is action within delegated authority? | Plan, tolerance, budget, role and external constraints | Act locally or escalate |
| Has the activity produced a usable output? | Defined completion, assurance, decision and conditions | Pass forward or return for action |
| Has the overall forecast changed? | Integrated impact and remaining-work evidence | Update plans, business case, risks and reports |
Control guidance
Tailoring the process
For a simple low-risk project, startup may be a short workshop and a concise combined brief. It may be combined operationally with initiation, but the authority should still recognise the point at which discovery ends and delivery commitment begins. Complex, regulated or multi-supplier projects may need feasibility studies, market engagement, specialist assurance or competitive procurement planning before a credible initiation request exists.
Record the selected form, role mapping and evidence route in the initiation baseline. Revisit it when risk, suppliers, obligations, pace or decision lead time changes; tailoring must preserve purpose and authority even when format and frequency change.
Tailoring and readiness check
- The trigger and decision authority are explicit
- Inputs are current, approved where required and linked to their source
- Products and activities have one accountable owner
- Forecast impact covers time, cost, quality, scope, benefits and risk
- Issues, decisions and assumptions are recorded at the appropriate level
- Interfaces with the preceding and following processes are controlled
- Tailoring preserves the process purpose and required evidence
- The completion decision and any conditions have a traceable record
Control guidance
Worked application
Stopping a vague improvement idea from becoming uncontrolled work
Situation: An operational team requests a new digital tool and has already contacted a supplier, but the user problem, expected benefit and data obligations are unclear.
- The commissioning authority appoints a business lead and project manager rather than allowing the interested team to self-authorise delivery.
- Startup discovery defines the end product at outcome level, identifies affected users and captures lessons from an earlier failed adoption.
- The outline case compares process improvement, reuse of an existing tool and new procurement; data and integration risks are visible.
- Governance authorises a limited initiation stage to validate requirements and options, with no supplier commitment beyond approved discovery.
Control outcome: The organisation funds the next decision, not the preferred solution. Ownership, product definition and uncertainty are visible before significant commitment.
Control guidance
Failure modes, recovery and common questions
| Failure mode | Consequence | Control response |
|---|---|---|
| Mandate treated as full project approval | Delivery begins without controls or viable justification | Limit authority to startup and initiation; stop unauthorised work |
| Solution chosen before need is defined | Options and benefits are biased | Define product and outcome, then compare feasible approaches |
| No accountable business lead | Project manager is forced to own value decisions | Appoint one business owner before initiation |
| Initiation plan omitted | Detailed planning becomes unbounded | Authorise initiation products, cost, time and tolerance explicitly |
Is startup the same as a full business case?
No. It creates enough outline justification to decide whether detailed initiation is worth funding.
Can feasibility work occur in startup?
Yes when authorised and proportionate. Significant studies may be their own stage or project.
What if the mandate is mandatory?
Define a viable delivery approach and consequences; obligation does not remove affordability, option or ownership checks.
Can startup be skipped?
The activities may be combined with another lifecycle, but the organisation still needs the startup decisions and evidence.