Project Management Training & Consultancy Services

The light touch non-bureaucratic FFWD PM Project Master file is a one stop shop for key high level project documentation. Other supplementary pages of your choice can be added to include Executive Brief, Project Definition, Stakeholder plans, Risk & Issue registers etc.

The purpose of the Master file is to give the Sponsor, the Project Manager and Team a high level view of what's planned and how things are progressing without the need for expensive systems and supplementary software packages. Each of the pages can be easily copied into PowerPoint slide packs for presentation purposes.

Repeated information such as project name, owners, dates etc are auto linked to other sheets for convenience. This Master file can however be used in conjunction with other project tracking and monitoring systems such as MS Project.

0. Summary Data

This is the data sheet that will copy repeat information such as project name, key dates etc onto subsequent worksheets.

1. Scope

The Project Scope template is an aid to defining project Goal and Objectives and to build on knowledge already gained from the project sponsors Executive Brief. Ideally the Sponsor will be part of the initiation process , this simple format can be used during the Initiation stage and set-up or Mobilisation of the project. The scoping exercise enables the project team and other stakeholders to surface many factors that could aid or hinder the delivery of the desired outcome. This is a collaborative exercise that importantly poses many questions at the Front End of the project and will establish the boundaries of the project and move the sponsor and other stakeholders towards the creation of a common goal and supporting objectives.

Statements of scope are useful in identifying and aligning the different assumptions that may be held about what the project is and is not responsible for and reminding people of what has been done already that could help or impact this project. Ultimately we should have a shared view of what this project is responsible for whilst raising awareness to other work completed or in progress but related and therefore preventing unnecessary duplication; it will also identify areas of related work to be done on completion of this project and thus build on developing working relationships and provide a better understanding of any dependencies.

2. Goal & Objectives 

A Goal statement should be a specific statement intended to give the project team, the Sponsor and Stakeholders a quick summary of the projects intended outcome, the benefit and purpose and the completion date. An objective is in itself a goal or planned / intended outcome, it is important that we express the Goal and Objectives as outcomes, ask yourself the question "What will be different when we achieve the Goal/Objectives?" By a <date> we will have.... 

The Project Goal and supporting Objectives are key to establishing where a project is going and will enable the formulation of a plan and route map to achieve the specified objectives "If you don’t know where you are going, you will never get there".  This simple template for use during the Initiation stage simply records the agreed project Goal and Objectives. Goal statements and objectives must be tested and articulated against SMART criteria: Specific, Measurable, Achievable, Relevant and Time bound. Time bound criteria for Project Objectives may not always align with the Time bound criteria of the overall Project Goal, although you may find that some objectives will have a specific date included. An Objective may be achieved either via completion of a single Milestone or a combination of one or more Milestones.

3. Milestone Plan 

This Milestone Plan template is simply a Plan on a page and gives the Sponsor the project team and stakeholders a view of the route map to achieving the project goal and supporting objectives.  The plan will be reviewed monitored and updated by the Project Manager and team on a weekly basis.

The Milestone Plan will be formed by a number of Milestones ideally no more than 15, the Milestones will be organised into Result path themes and will have dependency and inter dependency linkages, the Result paths will ideally be no more than 4. Each Milestone will have a name, a reference and start and end date, it will have an owner supported by a Milestone team.  The template also captures a definition of the end state for each of the Milestones and also the Project Goal statement.

4. Milestone Contract Definition

The Milestone Contract Definition is the delivery contract between the Project manager and the Milestone owner and provides further granularity in the form of high level activities needed to satisfy the definition of the end state for the Milestone.  This can be supported by further detailed activity plans or even MS project plans.

There will be a definition for each Milestone. Each of the high level activities will have a corresponding success measure with activity and measure references. It is the responsibility of the Milestone Team led by the Milestone Owner to devise actions to achieve each of the activities and ultimately the end state definition which must be expressed in outcome terms. This single page document is a quick reference source for the Project Manager to assess progress against the plan.

5. Responsibility Matrix 

The Responsibility Matrix is primarily a means of identifying key players and project resource, in this version we have used RACI role descriptors, although there are other alternative descriptors you could use. The Milestone Contract Definition and the high level activities are used to identify the key players needed to deliver the identified activities, by using the RACI codes we can annotate the role an individual or groups will perform.  From this we can move towards securing and contracting the appropriate resource to deliver, identify communication activities and the people key to the success of the project. 

R - Responsible: The individual (s) responsible for actually doing the work in the Milestone, activity or decision. The degree of responsibility is defined by the accountable person, responsibilities can be shared.

A  - Accountable: One person is ultimately accountable for a Milestone, activity or decision & assigns the responsibility or completes  themselves.  Push accountability down to most appropriate level. 

C - Consulted: The individual (s) to be consulted prior to final decision/action being taken. They may not participate in the task but is impacted by its completion & their input may be needed. 2 way communications.

I - Informed: The individual (s) that need to be informed after a decision or action is taken. Input from     the informed party is not needed - but they will need to know. 1 way communications.

6. Resource Summary

The Resource Summary is used to record the key project resource for the delivery of the project. It will detail named individuals, skill area, days required and time frame. By using pay per day for specified grades we can also gauge the cost to resource the project, we can identify who is working in what Milestone and also the Activity. The resource contract coupled with information from the Responsibility Matrix will enable negotiations to take place with the line managers of the specified resources leading towards resource contracts and project related personal objectives.

7. Stakeholders

Stakeholders are individuals or groups with interests in a project or programme who could be impacted positively or negatively by the project and its outcome. This Stakeholder analysis template enables the team and other stakeholders to record the assessment of stakeholder feelings, resistance or support for the intended change, and therefore begin to understand how the change will affect them and how this can support or block the projects outcome. From this analysis we can then make plans and take action to influence the groups or individuals to either ally fears change negative perspectives and grow or encourage support for the project and its intended outcome.

8. Issues & Risks Summary

This simple template records the top 3 Issues and Risks and can be used for high level reporting. This template will be supplemented by Issue and Risk registers, and management of such needs to be reviewed and managed systematically. It is essential that Issues and Risks are identified and actions identified and managed as part of the Project Control responsibilities. Firstly we must be very clear on our understanding of, and the difference between, an Issue and a Risk:                                
An Issue is something that has occurred and needs to be addressed - its probability is certain, its there, its occurred and we can therefore readily address the problem it will have a negative impact on the achievement of project objectives if not addressed.

Risk is an uncertain event or set of circumstances that could have a negative impact on the achievement of the project objectives. It has not occurred but if it does it will hinder or even stop the project from progressing.

Every Issue and Risk must have an owner, an identified action and a date for completion, we must avoid having Issue and Risk registers managed outside of the Project plan and other control mechanisms, identified actions should therefore be built into the plan. The level of Risk management applied will be dependant on the size and complexity of the project and in some circumstances use of Risk specialists will be required.

The word Mitigate is a term often used with Risk management which means: 'To lessen or to try to lessen the seriousness or extent of'

9. Healthcheck

The Healthcheck is a multi dimensional view used to assess the maturity of a project or programme, and is made up from a number of key dimensions to assist the team when setting up a project and provides in life check points throughout the lifecycle. It is not intended for reporting purposes but more about the teams conscience, it acts as a self audit tool enabling the team to identify where in the project they need to focus their efforts which in turn leads the team to address areas where fundamental project disciplines have not been applied or need to be improved.  

Each of the Healthcheck dimensions can be assessed against the maturity scale from Tin through to Gold status; the team needs to agree the applicable dimensions to be used and where in the maturity scale the dimensions need to be at an agreed point. As the project progresses the Team using the Healthcheck as their conscience will regularly review the maturity status against the dimensions and take action to move to the agreed maturity level. The Healthcheck can be used to make cross project comparisons and from this project and programme communities can identify the disciplines requiring attention from a community perspective.