1. INTRODUCTION
2. CONTROL
3. REPORTING
4. COMMUNICATION
5. LIST OF MANAGEMENT PRODUCTS (DOCUMENTS) AND THEIR USE.
5.1 PROJECT START-UP PRODUCTS / DOCUMENTS
5.2 PLANNING PRODUCTS / DOCUMENTS
5.3 PROJECT MANAGEMENT PRODUCTS / DOCUMENTS
5.4 PROJECT QUALITY PRODUCTS / DOCUMENTS
5.5 PROJECT CLOSURE PRODUCTS / DOCUMENTS
INTRODUCTION
This document is a designed as a support / procedures document to assist running projects in the implementation phase (after start-up and Project Initiation). It assumes that the reader is familiar with the PRINCE method of project management and the project planning tool Microsoft Project.
For those unfamiliar with PRINCE a summary is provided in the Project Managers Companion file. If you have any training requirements for PRINCE, project management or Microsoft Project please see the training department.
Do not read any further until you have at least a basic understanding of PRINCE.
CONTROL
Management of a project means being in control, identifying what decisions have to be made and making sure that the decisions are taken by the right people in a timely way.
| CONTROLS | USAGE |
| Weekly Or 2 Weekly Checkpoint Meeting | A face to face meeting with people to ensure that things are going OK. This is easier and better than a memorandum because personal contact gets to the heart of the matter and is normally more efficient and effective. As well as an opportunity to review progress for the last period it is an opportunity to agree the plan of action for the next. A summary record of what was agreed should be sufficient (dont do long reports!) |
| End Of Stage Meetings Or Reviews | At the end of any critical period, or upon delivery of a phase, stage or product there should be another meeting at which the key stake-holders (including customers or end-users) get together to verify that they are happy with what has been delivered and current progress. If people are unhappy agree a plan of action as soon as possible, projects go wrong a little bit at a time, dont wait until this has accumulated into a big problem which is harder to fix. A summary record of what was agreed should be sufficient (this may give rise to one of the following PIR, OSR, RFC see below) |
| PIR Project issue report | If something is wrong then raise a formal notice about it and involve the stake-holders and Project Board in agreeing what should be done, if anything. Dont be silent on an issue and hope it will go away. If the decision is do nothing then agree and note that decision, just in case it comes back to haunt you! |
| OSR off specification report | After a PIR (see above) if it transpires that something is wrong and it is someone elses fault, because they did not do what was previously agreed, then an off specification report should be sent to record what action you expect them to undertake to put things right. This is usually used when you expect a supplier to put something right free of charge. |
| RFC request for change | After a PIR (see above) if it transpires that something is wrong or needs to be changed from what was previously agreed then a request for change should be agreed with the stake-holders and Project Board. This must clearly identify the impact on the project of any changes staff, money, time-scale etc. |
At the end of your project the difference between what you agreed to do (in the Project Initiation Document ) and what you did do (Project Closure Report) should be documented by a combination of the above.
The Project Managers Reports (see below) should prove that you have communicated this information at each stage throughout the project so that there should be no surprises about the eventual outcome of the project.
REPORTING
If you are managing a project you are responsible to other people to report progress the users, the Project Board and other interested people.
Try to meet with the Project Board at the end of each critical period, stage or milestone (or at least 2 monthly) so that if something isnt going according to plan it is communicated and action agreed as soon as possible.
Reports are simplest if given orally at a meeting and documented through the minutes of the meeting. If however the project does require formal reports then these are probably all you will need.
| Report Name | Responsibility and Distribution | Summary Purpose & Content |
| Project Manager Monthly Progress Report | By Project Manager to Project Board 4 days before Project Board Meeting | To report progress/issues to Project Board Actions completed in period Actions not completed in period Problems areas and required action Request for Change |
| Project Budget & Financial Control Report | By Project Manager to Project Board 4 days before Project Board Meeting | To support supplier payments against progress Milestones achieved and satisfaction Payments compared to budget |
COMMUNICATION
It is not enough to do a Project Managers Progress Report if nobody sees it. Communication is essential to the success and control of a project.
All projects should circulate the Project Managers Progress Report or Minutes of the Progress Meeting in the letter-book. Moreover projects that effect people outside the section or department may merit a 1 side of A4 summary to be used as a newsletter to be put on the notice boards so that everyone knows what is happening.
LIST OF MANAGEMENT PRODUCTS (DOCUMENTS) AND THEIR USE.
PROJECT START-UP PRODUCTS / DOCUMENTS
| PRODUCT | USAGE | CONTENTS / HEADINGS |
| PROJECT INITIATION DOCUMENT | A Project Initiation Document should answer the following questions Why are we doing this project, what is the business case? How will this project be managed? Controls & Budgets Project Reporting Meetings The Products and Plans, when agreed, form part of the Project Initiation Document Agreed by Project Manager and Project Board | Date Title Introduction Confirmed Project Brief Business Case Definition Of Organisation And Responsibilities Quality Plan Project Pre-Requisities Project Risks Management Of The Project Project Tolerances Project Reporting Financial Control |
| PROJECT BRIEF | A Project Brief should answer the following questions What is the purpose of the project, what are the aims and goals? What are the assumptions, constraints and risks? What is the organisation structure, who reports to who, who is in-charge? What is everyones role / job description? Agreed by Project Manager and Project Board | Date Title Background Definition Of Business Goals Project Aims Specific Objectives Constraints Assumptions Executive Senior Users Senior Technical User Project Manager Business Change Manager User Stage Teams & Project Assurance Function |
PLANNING PRODUCTS / DOCUMENTS
| PRODUCT | USAGE | CONTENTS / HEADINGS |
| PRODUCT DESCRIPTIONS | To explain, in detail exactly what needs to be done / delivered / produced and set the standard (quality) demanded. Agreed by Project Manager and Stage Team(s) | Date Title Purpose Composition Derivation Format And Presentation Allocated To Quality Criteria Quality Check Required Approving The Product. |
| PROJECT PLANS | To record at high level the schedule of activities and stages through the project. Agreed by Project Manager and Project Board | Date Title Activity Cost Start Date End Date Resources |
| STAGE PLANS | To record at detail level the schedule of activities for a given stage, period, or activity. Agreed by Project Manager and Stage Team(s) | Date Title Activity Cost Start Date End Date Resources |
| END OF STAGE REPORT | To record progress at the end of a stage, period, or activity, comparing actual results against plans and putting forward the next period plans. Used by stage managers to report to Project Manager. | Date Title Management Summary Progress This Period - What Happened Potential Problems Suggested Next Period Activities Budget Status Resource Implications |
PROJECT MANAGEMENT PRODUCTS / DOCUMENTS
| PRODUCT | USAGE | CONTENTS / HEADINGS |
| PROJECT MANAGERS PROGRESS REPORT | To record progress, report issues and agree next period activities. Used monthly to communicate to Project Board. | Date Title Management Summary Progress This Period - What Happened Potential Problems Suggested Next Period Activities Budget Status Resource Implications |
| PROJECT RISK REGISTER | To record risks, and possible contingencies / avoiding action. Used by Project Manager to communicate risks and impact to Project Board. | Date Title Risk Detail Impact Notes Likelihood Impact Risk Action(S) |
| CHANGE CONTROL | To control changes to the project where they impact upon the quality, scope, end-date or budget. Agreed between Project Manager, relevant Stage Team(s) and Project Board. | Date Title Problem / Reason For Change Change Required Impact (Budget / Time) |
| OFF SPEC REPORT | To report back where a product or deliverable fails to meet the specified requirements. Agreed between Project Manager, relevant Stage Team(s) and Project Board. | Date Title Agreed Specification How This Fails The Specification Impact Change Required |
| PROJECT ISSUE REPORT | To alert the Project Manager or Project Board to an issue which can either require no further action, or might give rise to a Change Control or Off Spec Report. (see above) Agreed between Project Manager, relevant Stage Team(s) and Project Board. | Date Title Problem / Issue Factors / Impact |
PROJECT QUALITY PRODUCTS / DOCUMENTS
| PRODUCT | USAGE | CONTENTS / HEADINGS |
| INVITATION TO QUALITY REVIEW | To notify relevant people that a product has been submitted for acceptance and to give them the opportunity to review that product before acceptance. | Date Title Fix Of Meeting (Time / Venue) Enclosure Of Product |
| MINUTES OF QUALITY REVIEW | To record acceptance or otherwise of a product. If a product is not acceptable to record actions / changes required. | Date Title Comments From Meeting Action Required |
PROJECT CLOSURE PRODUCTS / DOCUMENTS
| PRODUCT | USAGE | CONTENTS / HEADINGS |
| END OF PROJECT NOTIFICATION | For the Incorporation Programme Manager to report to the Project Board / Corporate Team on how the project has performed against its goals. Created by Project Manager for the Project Board. | Date Title Achievement against objectives Performance against plan and budget Summary of outstanding issues Fix of post implantation review date |
| LESSONS LEARNT REPORT | To pass on any lessons that have been learnt from this project that may be used to benefit Project Managers, Jersey Post Office or other projects. Created by Project Manager for the Corporate Team. | Date Title What went well What went badly What improvements could be made |
| POST IMPLEMENTATION REVIEW | To find out whether the project has delivered expected benefits and if the project has caused any problems. Created by Project Manager for the Corporate Team. | Date Title Achievement of expected benefits Unexpected benefits Unexpected problems User reaction Follow-on work requirements |
