A project brief is a one-page summary that aligns a team before work starts: the problem, how success is measured, what is in and out of scope, the main risks and the questions still open. A project charter is the formal document that authorizes a project and gives the project manager authority over resources. A product requirements document goes deeper into what a feature must do. The brief comes first and feeds both.
A project brief explains the case for a project, and a project charter formally authorizes it. The PMBOK Guide defines a charter as a document issued by the project initiator or sponsor that formally authorizes the existence of a project and gives the project manager authority to apply organizational resources to project activities. A brief is usually shorter and less formal, written to align the team on the problem, the goal and the scope. In many organizations the brief comes first, and its content feeds the charter once the sponsor approves the work. Source: Project Management Institute, A Guide to the Project Management Body of Knowledge, Seventh Edition (2021).
Describe who has the problem, what happens today and what it costs, without naming the solution. In a survey of 106 senior executives, Thomas Wedell-Wedellsborg found that 85 percent agreed their organizations were bad at diagnosing problems. His remedy is reframing: get each person's definition of the problem in writing, ask what the description leaves out and question the goal behind it. In his slow elevator example, mirrors cut complaints because the real problem was an annoying wait. Ask two colleagues to write the problem in their own words and compare. Source: Thomas Wedell-Wedellsborg, Are You Solving the Right Problems?, Harvard Business Review (2017).
Pick a few metrics that would show the problem is solved, give each a number and a date, and name who tracks it. George Doran's SMART criteria, first published in 1981, describe a good objective as specific, measurable, assignable, realistic and time-related. Assignable means a named person is responsible for it. Pair an adoption metric with a quality metric so one cannot improve at the expense of the other. Record today's baseline so each target has a clear starting point. Source: George T. Doran, There's a S.M.A.R.T. Way to Write Management's Goals and Objectives, Management Review (1981).
List anything a reasonable reader might assume is included, plus work you plan for a later phase. The PMBOK Guide treats project exclusions, a statement that explicitly identifies what is excluded, as part of defining scope. Writing exclusions down turns later debates into a quick check against an agreed page. Moving an item to a named phase, such as Phase 2, keeps the idea alive while protecting the current timeline. Revisit the list when the team learns something that changes the effort or the value of an item. Source: Project Management Institute, A Guide to the Project Management Body of Knowledge, Seventh Edition (2021).
Run a premortem: imagine the project has failed and ask everyone to write down why. Gary Klein developed the method and cites research by Deborah Mitchell, Jay Russo and Nancy Pennington showing that prospective hindsight, imagining that an event has already happened, increases the ability to identify reasons for future outcomes by 30 percent. Give people a few minutes to write alone, then collect one reason at a time from each person. Add the top concerns to the brief's risk section with a mitigation for each. Source: Gary Klein, Performing a Project Premortem, Harvard Business Review (2007).