The Project Brief

Bringing every project member on the same page at the same time.

What is a Project Brief?

A condensed document that will give each project member both a clear view of the 'Big Picture' as well as the specific requirements of the project. It is intended to keep everyone aware and aligned on Scope, Timelines and Budgets.

The idea of the document is that anyone who reads through it at any point in time will have a clear understanding of what the project is about, why it's being done, what is needed by when, how much we are getting paid for the work we are doing and who is in the team.

Parts of the Project Brief

There are 4 main parts.

First, General Information. This covers:

• Date Briefed - The day and date this document is discussed with the Team. Ideally, one or two days after the project has officially been signed off on and initial payment has been received.

• Client Name - Use the client's legal name. Spell it right! If they have another name by which they are referred to internally, put this down as well so everyone knows who you mean by or are referring to.

  • For example, JLC's official name is S.E.A.D. Holding Pte. Ltd.

  • For Inarra, the client is private individual, Annie Lao.

• Project Type - Sometimes it's a simple Branding requirement. Other times it's a Website project that has a hundred other parts or sub-projects within it. Whatever it is, identify it properly.

  • For example, the Tilleke & Gibbins Website Project has a specific photography component that might need its own Brief altogether.

The second part is the meat of the matter - Project Details.

• Background of the Client - Who they are, what they do or industry/industries they are in, where they are based or have presence in, who their target users or audiences are. If competitive information is available, share that too. Help your team understand who we're working with.

• Top 3 Issues - By the time the Brief is to be written, these issues have been identified from the initial meeting, all the way to the SOW and Proposal development. This section is simply lifting that information already stated in the Final Proposal.

  • These would usually be business issues, communication issues or process issues. Or a combination of them. Or other things entirely.

  • These issues should be addressed in the next section.

• Deliverables/Requirements - A clear breakdown of everything that needs to be done/created by the Agency. There are deliverables that have further pre-requisite items/steps so it's important to list all of that down.

  • Similar to the 'Top 3 Issues', this information is from the approved Proposal document. If the list from the Proposal is not exhaustive, it needs to be itemized in the Brief. This will help us avoid forgetting deliverables that we committed to.

  • Best practice: group the requirements in batches so everyone will know which ones to prioritize and which ones will be done at a later time.

    • Arranging requirements in batches is not by whim nor at random. There are clear reasons why some requirements need to be done before others. If you are unsure, discuss this with the team and get consensus.

• Working Timelines and Project Milestones - This will also be lifted from the approved Proposal.

  • Ideally, the timelines provided to Client already include a reasonable buffer. This is to account for other ongoing/delayed projects or any other unplanned surprises while allowing us to still fulfill our scheduled commitments to Client.

• Budget Breakdown - Taken from approved Proposal. Budget is usually divided between a 50% initial payment and xx number of monthly payments, depending on how long the project was projected for.

• Other relevant information - These would be bits of information that are culled from the various interactions, meetings, calls with the Client during the Sales process. They may not fall neatly into the earlier sections of the Brief but would be helpful for the team to know about.

  • These could be things like the Client leading the project having no clue about website development, or having extremely long approval internal processes; or there are other parties in the project that may be directly or indirectly involved. Or the Client has requested for a special arrangement (i.e. grant applications, etc), or the main Client contact will be leaving soon.

  • Information such as Client personalities are also good to know so it can help the team figure out how to approach the project or interact with the Client.

Third section is the Project Team.

• Project Owner - He or she is responsible for the project on a day to day basis, regular client interface, managing timelines, project status, budgets, manpower.

  • It's possible to have more than one owner if the project has specific components that will be led by different people. Be specific on who owns which part.

• Project Lead/s - Depending on the project, there may be more than one lead. Usual lead roles are Design Lead, UI/UX Lead, Development Lead, Content Lead, Production Lead.

• Support Team - Members who will be involved to supplement the efforts of the Lead/s. Again, be specific on who these will be.

• Escalation Point - To be consulted on discussions regarding material changes to the contract, project strategy/execution, budgets if these matters are not addressed at the Project Owner level. Generally this will @manny.

Final section is for Working Files.

• Links to files on Team Drive or Bloo, where they may have been uploaded or any other references, files or documents.

Who should write the Project Brief?

Ideally, this is written by both the Sales/CRM lead and Project Owner. The assumption is these people will have received all information, including non-verbal clues into the Client, their team, and their organization and will be in the best position to discuss the project with the team.

How should the Project Brief be used?

• Once a draft or v1 of the Brief has been written, the Project Owner must call a full Team Briefing to discuss its content.

  • While the document is supposed to be the singular handy basis of key project details (apart from the Contract but that's not easy to flip through on a regular basis), it is important to keep in mind that anyone in the team can challenge its content during the Team Briefing.

    • It will also show you who is really thinking about the project, as opposed to just 'taking orders' (mwahaha!)

    • The Team Briefing is also the chance for Project Members to raise all and any questions they may have about the requirements, timelines, whatever else.

  • Required attendees are (surprise, surprise) the Project Team.

• If there are any changes/updates from the Team Briefing, then a revised version will need to be drawn up and re-disseminated to the Project Team.