1. <project> Governance Meeting
<Date>
<Time>
<Location>
Project recommendations must be included - When presenting, ensure the project recommendations (e.g. for roadblock) are clear. The analysis by the project team should result in a clear recommendation - do not just report the project findings. Make sure any recommendations has been agreed and approved by the appropriate stakeholders. Make the message clear - Each & every slide should have a clear message as to what it is conveying. The message must be succinct and immediately clear to the reader Project approvals should be clear - What specifically is the project seeking approval for? For example, is the approval for a phase of the project or the entire project?
 Use plain English - Where terms and acronyms are used ensure the term is clearly explained. Acronyms must be written in full the first time they are used with the acronym in brackets after the first use. Stakeholder Management - To optimise the likelihood of success for your project approval, ensure that your stakeholders are supportive with all facets of the proposal. Ensure you schedule sufficient time in the preparation of your submission to gain stakeholder support.

2. <project> Status
<This page should always be used. Increase or decrease the controls depending on the type of monitoring required for project. Remove this comment when used for project instance> 2 2

3. <project> Budget
<This page can be optionally used to provide granular financial detail for the project. I found in most projects this is one of the more used pages. If used, it should be tailored for financial structure of the organisation. Remove this comment when used for project instance>< 3

4. <project> Roadblock, Approval or Variation
Detail 1
Describe
<Describe the roadblock/approval/variation how it has come, why now, key parties involved, etc.> 2
Impact
<Describe the impact of the roadblock/approval/variation, especially how it may effect the governance team. Also describe impact if we do nothing. This needs to create the motivation for governance to do something> 3
What we need
<What we want the governance team to do, be specific and direct. If you do not say exactly what you want they will give you what they think you need> 4
Background
<Provide any extra detail>
<This page can be optionally used to provide detail about an Issues impacting the project which can not be resolved by project manager or project owner. It can also be used to detail any variation require governance team approval. Recommend if more than one have a separate page. Minute all agreed actions. Remove this comment when used for project instance.><

5. <project> Risk and Issue
<This page can be optionally used to provide granular detail about key Risks & Issues impacting the project. Remove this comment when used for project instance.>< 5

6. <project> Achievements
Category
Detail
Planned
< List the key achievements for this period … >
Behind Plan
< List the key tasks not delivered or behind schedule … >
Unplanned
< List the key tasks undertaken that were not planned … >
<This page can be optionally used to provide high level of overview of progress. This could be replaced by milestone plan or summary Gantt chart what ever is appropriate for organisation. Remove this comment when used for project instance.><

7. <Project> Other
<Blank page to be used for other communications.
Remove this comment when used for project instance.>< 7