Project management header
products page

The Project Notebook


This is the project Bible.
The exact nature of its contents will vary according to the project and style of the Project Manager.
This is the cornerstone of every project.

The Project Notebook contains all of the information used to initiate the project.
The exact amount of detail will depend upon the nature and size of the project.
It should be agreed and signed off by stakeholders.


These should be recorded in order to understand the background to the plan.
Compare these with constraints. Any implications and actions should be recorded.
Make sure that the real impact of not meeting these is recorded.

Problem statement

Sound definition is needed so that you know the exact problem that you are solving.

Mission statement

This identifies ‘what, for whom and how’.
This should indicate the overall goal, identify the client and general approach.
This will vary in depth according to the size of the project, but there should be one.


How do we go about the project?
Outside contractors? Make or buy? Use what technologies?
This is described in PRINCE2® under Project Approach.


This looks at what will and will not be included in the project.


Could be technical, financial, performance, quality etc.
Without objectives there will be no direction to the project.

Customer analysis

This identifies how the Project Team finds out what the customer really wants, i.e. what method(s) does the team use.
Communication between the project team and the customer is vital but if good techniques are used the information collected will be more valuable and accurate.


All the deliverable items should be listed.
What must the project produce (and when) e.g. reports, prototypes, other documentation.
Good to have deliverables at each major milestone.

These are just known as ‘products’ under PRINCE2 with the projects goal being the ‘final product’.

Exit Criteria

How will you know if a phase of work has finished otherwise?

Product specification

This is a complete list of any criteria that the end product must meet, for example, engineering specs, building codes, market performance specs, government regulations.
These could be physical attributes and performance ones.

Work Breakdown Structure

Gives a point of reference for tracking, forms the schedule and provides a good visual aid for control.
It is the complete list of all the tasks needed to complete the final product.
The schedule translates these into a time frame and includes any interdependencies.


Detailed tasks and milestones with deliverables.
Shows the interdependency of the tasks.

Resources (cost)

Includes personnel, equipment, materials, facilities.

Control System

How do will we measure the progress of tasks and know when they are complete?
How frequent? Doe we need reports? To whom? How do we handle project modifications or the approval process?

Authority / roles / responsibilities

Who does what? What is the level of authority?
It is important to make sure that such aspects are made clear.
Without clarity here there will be poor leadership [see 'The Complete Leadership package‘].

Risk areas

What could go wrong? Consider options, see the later section on strategy and S.W.O.T. Analysis.
Don’t forget to have a suitable backup plan in the event of a disaster.
Also, consider technological redundancy.

Risk is examined in much greater detail in 'The Complete Risk Management package'.


This would include the Business Case under PRINCE2.

The Project Manager should convince himself that all of the statements and calculations on which certain information is presented are correct.
Before the Project Notebook is signed off it is wise to arrange for a review with the interested parties.
Note that should the scope of the project change, for any reason, then risks, assumption etc should be revisited and agreed again.

These areas of the Project Notebook are each covered in more detail.
It is likely that the Project Notebook will be updated on a regular basis.

The ‘Project Notebook’ described here is very similar to the Project Initiation Documentation under PRINCE2 2009.

There needs to be a focal point at which all information relating to the ‘what, why, who, how, where, when, and how much’ of the project is:

  • Gathered for agreement by the key stakeholders
  • Available for guidance and information for those involved in the project.

This information is collated into the Project Initiation Documentation.
[see Initiating a project – Activities - Assemble the Project Initiation Documentation]

In addition, the generation of the individual documentation in the Project Notebook will be similar to the Product Descriptions under PRINCE2 2009.
These are provided in ‘Appendix A Product Description outlines’ in the product package.

Also under PRINCE2 2009 [see ‘The Complete Project Management plus PRINCE2’], the Project Product Description is a special form of Product Description in that it includes the customer’s quality expectations and, at this level, the quality criteria and quality methods constitute the acceptance criteria and acceptance methods for the project overall.

The Project Product Description is created in the Starting up a Project process as part of the initial scoping activity and may be refined during the Initiating a Project process when creating the Project Plan.
[see Quality - The PRINCE2 approach - Quality planning - The Project Product Description].

PRINCE2® is a Registered Trade Mark of the Office of Government Commerce in the United Kingdom and other countries.