How to write a Project Brief that wins executive confidence

A step‑by‑step guide for writing Project Brief's with real, board‑ready examples and templates.

Before you choose a system or a vendor, you need everyone aligned on the problem you’re trying to solve. The fastest way to an approved project is to provide executives with all the info they need upfront. A Project Brief is the founding document for a project, used to align executives, management, and delivery teams around a single shared understanding of:

• What problem(s) exist

• Why they matter

• Who they impact

Then the Project Brief gives executives confidence to proceed by outlining;

• What the approach to solving the problem(s) will be

• When they will be solved

• Where the change will happen

• How risk will be managed

Below is a step‑by‑step guide to writing a winning Project Brief, with real examples taken directly from our own transformational projects to show what “great” looks like in practice.

You can download our FREE template at the end of this article to help write your own winning project brief, too!

Step 1: Get everyone on the same page by setting the scene

Open your Project Brief by establishing a shared understanding of the current state.  The background section should clearly set the scene by describing how the organisation operates today, the systems and processes it relies on, and the direction things are heading. A strong background gives everyone the same starting point and is the foundation for the need for change.

“The organisation operates a highly customised, internally maintained system, implemented over a decade ago. The platform underpins core operational, financial, and customer‑facing processes, but is now approaching the end of its useful life with limited vendor support and constrained integration capability.”

This works because it is factual, specific, and unemotional. It establishes dependency and risk without selling a future state, ensuring all stakeholders start from the same baseline understanding of the situation at hand. The background section should also detail the timeline of events, decisions, or inaction that created the current state.

Step 2: Define the Problem so anyone can understand it

An effective problem statement clearly describes the risk or issue, presents the evidence, and outlines the business impact, enabling executives to grasp the urgency and context without being steered toward any specific solution.

Here’s a clear example:

“In October 2025, Audit and testing of the organisation’s on‑premises system backup identified that the operating system had been out of vendor support since June 2025. The environment was deemed insecure, with a high risk of service interruption and no effective resiliency in place.”

This works because it:

• Ties the problem to a specific incident and point in time,

• Clearly states security, continuity, and resilience risk

• Uses plain, executive‑level language (“high risk of service interruption”)

• Makes inaction indefensible without prescribing a solution

A winning problem statement always answers this question for decision‑makers:

“What are we exposed to right now if we do nothing?”

If that answer is clear, then justification foir the project can be assessed against a well understood current state.

Step 3: Set the Main Goal and Define What “Good” Looks

A strong Main Goal defines what success looks like now, next, and later, giving leaders a shared view of the future state that resolves the problem statement. Executives rely on these goals to monitor progress, maintain control, and make informed decisions as the project moves forward.

In one effective brief, the Main Goal was framed around moving the organisation from fragmented and reactive practices to a single, trusted source of information:

“Design and implement a fit‑for‑purpose, integrated asset management system that enables the organisation to move from reactive, fragmented practices to proactive, streamlined operations.”

This worked because it defines success in business terms and not system features. It clearly described the future operating condition leadership expect to see at the end of the project.

Step 4: Outline the approach to solving the problem

A project approach outlines the pathway for moving from the current state to the desired future state. It sets out the key tasks and, where helpful for control and governance, organises them into phases. Each phase can define its own outcomes or goals, all of which contribute to achieving the Main Goal.

A typical approach for a system upgrade or replacement may begin with a Discovery & Requirements phase, often supported by early quick wins:

“Discovery will deliver a unified asset register, an increased understanding of the organisation’s systems, a completed risk assessment and prioritisation, and approved requirements, and a clear roadmap for resolving key ICT risks.”

This phase works because it delivers value early by addressing the fragmented‑information problem identified in the problem statement. It also strengthens organisational understanding of what is required from a future system, setting up later phases for success.

The project may then progress to an Options Analysis and Business Case, where the requirements and risks identified in Phase 1 become the basis for evaluating how different options address the problem.

“Short‑listed system providers will be evaluated against requirements, with a comparative assessment of project costs, risks, and due diligence, resourcing and change implications implementation time and integration complexity, supported by an evidence‑based business case.”

This phase equips management with the information needed to make a defensible recommendation. It ensures trade‑offs and risks are explicit and gives executives confidence that all relevant considerations have been assessed.

Once a recommendation is endorsed by management and approved by executives, the project may proceed to Implementation, where value is realised:

“Implementation delivers real‑time visibility and control, strengthened compliance and governance, improved asset efficiency and cost management, enhanced financial transparency, and a single source of truth that supports sustainable business growth.”

This phased approach works because:

• Each phase has a clear purpose and outcome

• Risk is reduced before significant resources are committed to the project

• Leadership retains control over direction and quality at every stage

Step 5: Define deliverables

A strong approach only works when each phase produces clear evidence that its outcomes have been achieved. Deliverables are the tangible products or artefacts the project will produce, enabling leaders to verify quality, assess risk, and confirm readiness before the project moves forward.

In the early phases, deliverables establish control and clarity:

“Project governance, stakeholder responsibilities, and delivery authority were formalised through approved terms of reference, a project management plan, and a documented operational blueprint.”

These artefacts demonstrate that the project has clear ownership, defined decision rights, and a shared understanding of the environment before complexity increases.

As the project moves into requirements and planning, deliverables shift toward evidence and traceability:

“Business requirements were formally defined and traceable, supported by use cases, process models, data migration strategies, and change impact assessments.”

When deliverables are tied directly to outcomes and phases, progress is can be easily monitored and independently quality checked, giving confidence to your leadership team and board.

Step 6: Build a timeline with decision points to stay in control

A strong project timeline is built by sequencing deliverables and decision points onto a calendar. The purpose of a project timeline timeline is to show how work progresses across phases, how dependencies and resources are considered, and where leadership retains control over direction and quality.

The process starts by identifying the major phases of work—such as discovery, requirements, planning, development, testing, deployment, and stabilisation. Each phase is then anchored by one or more key deliverables that must be completed before the project is allowed to move forward. Dates are applied to those deliverables, not to individual tasks.

The timeline must account for resource availability, consider business‑as‑usual commitments, limited availability of subject matter experts, and coordination with other programmes.

Milestones are used as control points, represents a moment where a significant deliverable is reviewed, quality‑checked, and formally accepted. These points allow the board or steering group to confirm readiness before entering a phase, or adjust resourcing and make decisions based on evidence presented in the milestone.

This approach works because:

• Dates are tied to outcomes, not effort

• Dependencies are respected before commitments are made

• Resource limits are acknowledged up front

• Milestones preserve governance and decision control

A well‑designed timeline doesn’t create pressure to move faster. It creates confidence that the project is moving at the right pace, for the right reasons.

Step 7: Show how mitigation changes the risk profile

We have had good success demonstrating how risk profiles of a project change over the lifetime of a project and result in a reduced risk profile for the organisation, overall. This usually becomes central argument in a detailed business case.

Some risks begin at an unacceptable level. For example:

“Aged and unsupported on‑premise infrastructure presents a severe impact with a certain likelihood, resulting in a high inherent risk of service interruption.”

Mitigation focuses on removing the root cause through migration to a supported, resilient environment, supported by monitoring and failover readiness. After these controls are implemented, the same risk is reassessed:

“Following migration and resiliency controls, the likelihood of service interruption is reduced, resulting in a medium residual risk to be reviewed prior to production cutover.”

Other risks are driven by uncertainty rather than failure:

“Unknown complexity of legacy customisations and data structures is assessed as almost certain, creating a high inherent risk to delivery.”

Early discovery, technical assessment, and compatibility validation reduce that exposure before build begins. The risk is then re‑scored:

“Once discovery and planning are completed, the residual risk is reduced to medium and scheduled for re‑assessment at the development entry gate.”

Each risk follows the same discipline:

• inherent risk assessed

• mitigation applied

• residual risk re‑scored

• next review date set (aligned to a phase or milestone)

This works because leadership can clearly see:

• Current risk profile of the project

• how risk is expected to change over time

• what residual exposure remains

• and when it will be reviewed again

Ready to write a winning Project Brief that holds up under scrutiny?

If you want to put this thinking into practice, download the Pro Partner Project Brief Template and use it to write your own winning Project brief. The template has received great feedback from our clients and we keep it up to date to address changing board expectations we experience.

It will help you clearly define the problem, set clear goals and create a roadmap that the board will have confidence in.

If you’d like help tailoring the brief to your project, pressure‑testing your thinking, or sense‑checking a draft before it goes to executives or vendors, email us at getstarted@propartner.co.nz.

A winning project starts with a winning brief. Download the template and get started.