A guide to project briefs

A project brief, sometimes referred to as the project charter or project proposal, is a key document which outlines the project. A well written brief at the initiation stage can be the difference between project success and failure. Here we walk you through the necessities of a project brief and take a look at navigating complex briefs. Read on...

Project brief components

A project brief will include a number of components, though these may vary depending on the nature of the project. Generally, a project brief will cover all of the following:

Title - It goes without saying that your project needs a name, but it is important to remember that the title is what your project will be referred to in conversation, meetings, and email. It needs to be short and catchy, whilst specific enough that it doesn’t get confused with any other project.

Client summary - Who is the company and what do they do? What is their ethos or vision? What competition do they face? The client summary section is often overlooked for internal projects, but it shouldn’t be. Not only does it serve as a useful reminder for staff and stakeholders, but is invaluable for new recruits, and vital if you involve external talents or investors at any point.

Project description - This should include a summary of the project – the focus, scope, and objectives. It should define the project’s purpose, methodologies at play, responsibilities, and quality expectations. It should also cover details on the SMART objectives for the project (Specific, Measurable, Achievable, Realistic, Timely).

Insights or business case - In the information age it is imperative that your project brief is backed up with data, stats or insights which prove its viability. This section can include research into the client’s user persona - proving you know the audience. And similarly, any stats from the wider industry or competition will show a strong awareness.

Project scope - This breakdown of the work should address some of the logistics of the project. Including but not limited to, the budget and finances, the key schedule or deadline dates, and the resources available for the project.

Success measure - It is important that your project brief defines how you will measure the project’s success. The project’s list of key success factors are much like KPIs (Key Performance Indicators). Setting out the success measurements is important as you will likely be referring back to these throughout the project lifespan.

Other key information - At any point in the brief you may wish to add contact details for any project lead or key person, list the team or define responsibilities.

Understanding a complex project brief

Sometimes project brief documents are anything but brief! When they become lengthy and complex, briefs can be hard to understand.

These are our tips for navigating a complex project brief:

Keep outcomes in mind - Tangible outcomes and strategic outcomes are often very different things and can often compete for a project’s focus and attention. Overcome this by tackling each separately within the brief.

Enlist help - You may opt to delegate parts of a complex brief to colleagues. Or you may wish to discuss the project brief with a fellow worker or a more experienced senior who can assist you with navigation. There is no shame in enlisting help for understanding complex briefs.

Clarifying the scope - The more complex the brief the more important it is that the scope is clear. You need to avoid misunderstanding at all costs, as any misinterpretation has the potential to be hugely detrimental further down the line.

Break down elements - Some elements of more complex projects will need to be broken down further at the project brief stage. Listing individual components will improve understanding and ensure important elements are not overlooked.

Recognise when a project is a programme - When your brief is becoming overly complex, you should ask yourself whether this is in fact a programme? You can read about the difference between a project and a programme here. Essentially, if you have multiple work streams to manage it may be worth breaking them down into a collection of related projects - i.e. a programme.

Source: prince2.com