about.brighton.ac.ukabout.brighton.ac.uk/is/itprojects/pid_guide_02.docx · web viewuniversity of...

University of BrightonIT Programme Management Office

Project Initiation Document - Guide

Author(s): Betsy Brewer, Paul Sayers Date Created: 9 September 2014

Related Documents Version Number: 02

RevisionsVersion No.

Revised By Revision Date Notes

01 PS 15-Mar-2013 Extracted from ‘Guide_to_OBC_and_PID.doc’, restructured and reformatted

02 PS 9-Sep-2014 ToC reduced, minor changes and simplifications

CONTENTS

1 Project Description........................................................................................................................22 Project Size....................................................................................................................................23 Business Case.................................................................................................................................24 Project Benefits, Outputs and Outcomes......................................................................................35 Acceptance Criteria.......................................................................................................................36 Project Scope.................................................................................................................................47 Risks, Constraints and Assumptions..............................................................................................58 Project Organisation......................................................................................................................69 Project Controls.............................................................................................................................710 Reporting...................................................................................................................................911 Stakeholders and Communication.............................................................................................912 Budget.....................................................................................................................................1013 Planning Approach...................................................................................................................1214 Project tolerances & exceptions.............................................................................................1215 The Last Word..........................................................................................................................1316 Appendices..............................................................................................................................14

9-Sep-2014 document.docx of 14


INTRODUCTION

The purpose of this guide is to put some context around the headings used in the Project Initiation Document (PID) template and so make the template easier to use.

The PID is essentially the ‘master plan’ for the project and is the place to capture the Project Manager’s understanding of what the project is about and how the Project Manager plans to implement the project. Other ‘tools’ exist to assist with the completion of different sections, and for some projects the PID may well refer to other documents (e.g. Communications Plan, Test Plan, etc.) if appropriate.

The following should appear on the first page of the template:

Project Name: Project Size:

Project Manager: Extn:

Project Number: (if known)

Date:

1 PROJECT DESCRIPTION

Brief background and description of the project.

2 PROJECT SIZE

Projects are treated differently according to their size, generally requiring more, and preferably experienced IT project management, the bigger they are.Use the IT PM Project Sizing Form to give the size of this project, and enter at the front of this form. This will help you define the size of your project, according to its level of risk, priority, budget and strategic importance.

3 BUSINESS CASE

This is really obvious, but use the Business Case to help complete the next few sections.

3.1 OVERVIEW

A description of how the project supports dept./local strategy and plans, and why it is needed.

3.2 DETAILS OF SUPPORT FOR STRATEGIC PLAN OBJECTIVES:

Support for other strategies can be described here as well

3.3 REASONS WHY THE PROJECT IS NEEDED

This should present the context, justification and value to be gained from undertaking this project by making some measurable statements about the nature of the problem.



4 PROJECT BENEFITS, OUTPUTS AND OUTCOMES

4.1 BENEFITS

This describes the reasons why the University should do this project by identifying the impact on the University, describe the benefits to be achieved – some of which may not happen until after the project has finished.

4.2 OUTPUTS

Detail the things/products/deliverables created by the project.

4.3 OUTCOMES

Detail the result of the changes introduced by the new system, developed further from the Outline Business Case. These should be SMART (Specific, Measurable, Achievable, Realistic, Time bound)

5 ACCEPTANCE CRITERIA

These represent a specific defined list of conditions that must be met before a project can be considered to be completed and handed over to the Senior User. At that point the Senior User takes full responsibility for the project’s deliverables e.g. a system running in a live environment. Acceptance Criteria can be developed on from the objectives detailed in the Outline Business Case. They should be outlined in specific detail at this stage before work on the project has commenced. They should represent certain essential requirements that must be met within the final deliverables, or the specific conditions during their development. Acceptance criteria can be based on features such as ease of use, ease of support, ease of maintenance, ease of operation, appearance, major functions, development costs, running costs including energy, capacity, availability, reliability, security, accuracy, and performance. The following list suggests some acceptance criteria that might be considered for IT projects. This list is not exhaustive and you should include any relevant criteria for your project.• Hardware/software specifications as initially detailed.• Functionality and features implemented and web site(s) fully operational.• Operational, performance and reliability.• Contribution to the University’s carbon reduction target.• Access and security considerations.• Costs (project, maintenance and running including energy).• Hardware and software installation procedures.• Product descriptions and User Guides.• Product support (Roles & Responsibilities – In-House/External) established and operational.• Support and Operational Manuals.• Support info available to support service points.• Training material and training completed.• System/Supplier/Contractor contact/contract info, SLAs.• Health & Safety, Building Regulations or Legal Requirements approved



Once acceptance criteria has been defined and prioritised and how the acceptance will take place is detailed, they must be met as these are serious commitments. Otherwise a positive decision made by the Senior User/Project Sponsor that they need not be met before the project can be completed and closed down.

At the end of the project’s ‘Deliver It’ stage they will need to be formally signed off on the Customer Acceptance Form as being accepted, or as having been consciously agreed not to be met, by the Senior User/Project Sponsor before the project can be closed.

6 PROJECT SCOPE

What the project includes and what it excludes - sometimes it is not always obvious where the boundaries of the project are being set, and the purpose of these headings is to make that clear.

6.1 INCLUDES

Be clear and concise on what is included in the project. This will help you avoid ‘scope creep’ (which tries to happen on most projects).

6.2 LINKS

How does this project relate to other work, projects, and systems, or is it part of a larger programme?

6.3 DEPENDENCIES

Does it depend on something else that is outside your control that needs to have taken place? If so, then list it here. You cannot deliver on time if another piece of infrastructure, or management decision, is not delivered on time.

6.4 INTERFACES

What other systems does this project need to work with?Interfaces often appear straightforward but can be difficult to get right first time, so allow extra time for test/fix cycles.



7 RISKS, CONSTRAINTS AND ASSUMPTIONS

7.1 RISK MANAGEMENT

A Risk is something that might happen. (When it has happened, it is an Issue).Include here a description of the approach you are taking to manage risks, including responsibilities for recording risks and implementing appropriate risk management strategies. Note how you will report newly identified risks to the Project Board.

Risks should be recorded in a risk log. A template is provided in the ‘Project Logs’ spreadsheet to hold all project logs (Risks, Actions, Issues, Lessons, and Change).

7.2 RISK MANAGEMENT ROLES AND RESPONSIBILITIES:

Note here how risks are going to be managed and by who. It is up to you to decide what you think would be appropriate for your project. A common model is as follows: Risk log Created and maintained by the Project Manager. Reviewed by the Project Team at each meeting as appropriate. Reviewed by the Project Board at each meeting. All members of the Project Team and Project Board are responsible for raising any risks that they

may identify. These should be brought to the Project Manager in the first instance.This is a suggestion of a possible option, however, it is up to you to decide if appropriate.

7.3 IDENTIFIED RISKS

Please include the major risks you have already identified in your risk log to date here.It is important to list possible risks to the successful conclusion of your project, as once they are visible they can be managed. Once identified, think what would be the best way to handle this situation if it arose. This might cause you to re-think how you might approach the project to make things easier and more manageable.

7.4 CONSTRAINTS

These are imposed on the project and you have limited influence over them. This section summarises any constraints that affect the scope of your project or how you carry out the project e.g. project staff are only available during the summer vacation, project has only been part funded, requirements of external bodies affect the extent to which you can alter a process etc.

7.5 ASSUMPTIONS

You could view ‘Assumptions’ as the project manager’s ‘get out of jail card’, i.e. the planning has been based on these assumptions, something has changed, so the project manager has a reason as to why the schedule/deliverable/cost has changed.

This is a list of assumptions on which the project plan is based. Examples may relate to many areas including: provision of infrastructure, IT support, resource availability, communication, training, staff development, working arrangements and user expertise, as well as decisions being made to plan or



when needed. A common assumption is that operational staff will be released and that they have sufficient time to complete work on the project. Take particular care in defining what is expected of people inside and outside the project team, and obtain their agreement and commitment.

Should any of the assumptions prove to be invalid and adversely affect the project more than the agreed tolerances, then the project manager should raise it with the Project Board and develop an appropriate contingency (exception) plan.

8 PROJECT ORGANISATION

You may find it useful to show an organisation chart or diagram for the project.See also IT PM Roles and Responsibilities, IT PM Plan It and the IT PM Glossary:

8.1 PROJECT BOARD

Describe the project board and its members, and the roles they play within the project and details such as frequency of meetings

Project Board Role ResponsibilitiesSponsorSenior SupplierSenior UserProject Manager

Note: The PMO is available to attend the first Project Board meeting to outline the Project Board’s roles and responsibilities.

8.2 PROJECT TEAM

Describe the project team and its members, and the roles they play within the project and details such as frequency of meetings. It is good practice to have a project kick-off meeting with all members of the Project Board and Project Team attending. Please see ‘Kick-off Meeting Guide’.

This section should record the actual detail of roles and responsibilities of individuals within the project and may need regular updating during the course of the project.

Project Team Role ResponsibilitiesProject ManagerTeam Members

You may want to consider some stakeholders as part of your Project Team. For more information on Stakeholders see ‘Stakeholders – Identification and Analysis’, page 9.



9 PROJECT CONTROLS

This describes how the project will be monitored and controlled on a day-to-day basis, and how it will be evaluated.

9.1 ISSUE MANAGEMENT

An issue is something that has happened, or is happening, that affects the project in either a positive or negative way. This section should define how the project team is going to deal with issues. Project issues must be identified, prioritised and dealt with swiftly to ensure that dependent activities are not affected. An issues log is an ideal way of keeping a record of issues as they arise and also recording how they are resolved. A template is provided for a single spread sheet to hold issues as well as all the other project logs – see the ‘Project Logs’ (Risks, Actions, Issues, Lessons and Change). A Risk becomes an Issue when it actually happens.

9.2 CHANGE REQUESTS

This section should document what happens when someone proposes a modification to a planned output of the project. Each Change Request should be documented (including initiator, reasons and a description of the change required) and evaluated in terms of its impact. The appropriate actions required to resolve the requested change can then be determined. Use the Project log to record a request for change and see the ‘Change Request – Guide’ for more information.

9.2.1 REQUESTING CHANGEA change request may be raised by any project team member. It is sent to the Project Manager, who will ensure that all change requests are assessed, communicated, and actioned.

9.2.2 SMALL CHANGESMinor changes that have little impact on scope, benefits, cost, timescale, or other projects, can be authorised by the Project Manager and reported to the Project Board, if appropriate.

9.2.3 LARGER CHANGES These are outside the tolerances set by the Project Board and will need to be raised to the Project Board for a decision. Depending on the scale of the requested change, the Project Board may ask for it to be considered by other senior management.

9.2.4 FURTHER INFORMATIONFor more information, please see the ‘Change Request – Guide’ in the IT PM Framework support library.

9.3 LESSONS LEARNED

Anything that comes up that would be useful for future projects should be recorded in the Lessons Log. The log is useful when compiling reports like the ‘Highlight Report’ that mention lessons learned and the Project Closure report. This log will be part of the ‘Project Logs’ spreadsheet.



9.4 FINANCIAL MANAGEMENT

Outline responsibilities for the control of expenditure and budgets. You may wish to attach the project budget as an appendix to this document, but you will need to consider the confidentiality of such information especially where you are working with third parties.

Where third party invoices are involved, you may want to state the process to be used to authorise and process payment. Always liaise with Finance early in the project to establish any specific controls required by the University.

9.5 QUALITY MANAGEMENT

It is the quality of the project’s deliverables that is being described here, and what standards and processes are being applied to it to control them, and who signs the quality activity off.

Some examples of these quality activities are: review by key personnel that written specifications have not misinterpreted requirements, specialist system integration testing, and end user testing including any user help, quality check on any support documentation needed by operations teams, piloting a new system with a small number of users.

The University of Brighton operates largely in an informal manner, and has no over-arching single quality management system in place. IT PM process assumes that quality management is built into working practises, and notes that practically speaking these working practises will vary from project to project, and department to department. Some examples of statutory, institutional, or departmental quality standards you might apply are: Equalities and Health and Safety guidelines, building regulations, Institute of Electrical Engineers standards, software development quality management methods, ITIL, etc.

Where software development forms part of the project you may want to include an overview of how testing will be carried out and by whom (see example PID on the IT PM Framework website).

9.6 INFORMATION MANAGEMENT

How project information is to be held. Ideally all project documentation should be available to the whole team. Naming standards of documents should be such that the final version is clear, and a suggestion is made in Appendix 16.1.2 ‘Footer & Version Control’, page 14. The importance of information management should not be underestimated – people working to different versions of a document can really cause problems.

9.7 PROJECT ASSURANCE

Project assurance is checking that the project is being run as it was stated to be run, and ensuring that the project is working to its business case, delivering what was asked for within the boundaries described. Some project assurance will be done by the PMO, and Internal Audit may also audit projects to make sure that they are being run in accordance with the IT PM Framework. IT PM Framework is not prescriptive and allows for different levels of detail to suit different projects, and so additional project assurance would be on a case by case basis.



10 REPORTING

This section should define how and when the project team members report progress. An example is below but is only an indication of the sort of things you need to capture as it is not a definitive list:

Level FrequencyProject Manager to Project Board Monthly plus exceptions

Project Team to Project Manager As agreed

Sponsor/Project Manager As needed in between Project Board meetings, and will be less frequent if the project is running to plan and more if it is not. Can be by phone and email as well as meetings

Sponsor to Senior Management As agreed, if appropriate for this PID

Project Manager to PMO As per Project Board reports

Other

11 STAKEHOLDERS AND COMMUNICATION

11.1 STAKEHOLDERS – IDENTIFICATION AND ANALYSIS

A Stakeholder includes anyone with a vested interest in the project (those who: benefit/contribute/ impacted by the project). It is important for Project Manager’s to know their Stakeholders because: They will be judging the success or failure of the project. Projects are difficult – you need the support of the Stakeholders to succeed. Happy or unhappy stakeholders can make or break a project (or make your job difficult!)

It is a mistake to be unaware or ignore a negative Stakeholder (those who are negatively impacted by the project), as it is likely that they do not want it to succeed. Stakeholders are not just senior managers, it also includes workers who will be forced to change the way they work.

It is useful at this stage not only to identify your key stakeholders but to undertake some analysis of what their perceptions of your project are likely to be – see it from their point of view. This will help to show that you are aware of their views and will help you focus communications. Once you start communicating you will soon find out.



11.2 COMMUNICATION & ENGAGEMENT

Appropriate two-way communication with stakeholders is crucial to the success of the project. Project team members should also be considered as Stakeholders and be part of planned communication. Remember that ‘media’ can be group meetings or one-to-ones etc, not just email or paper based.This matrix gives examples from an existing project of how you may start to think about the interested parties and the suggested communication channels to be used for each group. It is not intended as a complete list and has been reduced from the original.

Stakeholders Expected Communications

Frequency Media

Project Board Status reportingIssues reporting

In line with Project milestonesDependent on timing and priority

Generally formal reports to be followed up by face-to-face contact where appropriate

Project Team Documentation and standardsProject knowledgeInternal communications

In line with planAd hoc as necessary

Shared folderGroup e-mailTeam meetings

Academic Advisory Panel

Requirements gatheringProject updates; dissemination within school

In line with planAd hoc as necessary

Shared foldersGroup e-mailMeetingsWorkshopsSystem usage

Deans Requirements gathering: Project updates

Ad hoc Verbal and written reports, presentations to Dean’s group, invitation to workshops.Academic Advisory Panel

Head of Schools Requirements gatheringProject Updates

Ad hoc Verbal and written reports, presentations to FMG, UMGAcademic Advisory Panel

Research Committees

Policy and Process approval

Committee cycle Formal reports to committeesSystem Presentations?

ITS Interface requirements During data mapping and build

WorkshopsProject Team

IS Libraries Publications requirementsProject Updates

Ad hoc WorkshopsProject Team

Where the project impacts many people in various groups it may be appropriate to have a separate ‘Communications Plan’.The Marketing & Communications department have a communications team who will provide consultancy on your communications plan and offer guidance. Please contact Anna Jones, Internal Communications Manager at [email protected]


mailto:[email protected]


12 BUDGET

The estimated costing of your project from your Outline Business Case should be refined further and the IT PM Project Costing Form updated and submitted with the PID.

The intention is to be able to show the cost of the project, even when they are being part paid for out of departmental budgets, e.g. existing staff time. Another aim is to be able to show planned expenditure profiled over years if relevant, so that budgets can be more realistically allocated and spent year by year.

Always contact Procurement Services in Finance in the initiation stage and they will guide you through the procurement process. You should not start formal procurement until you have the funding, and you will need to allow between 2 to 6 months, or more, for the full process to run depending on the size of the project.

12.1.1 EXISTING UOB STAFF COSTSThese are the costs associated with assigning existing university staff onto the project, for whom additional funding is not sought, but needs to be identified in order to provide the total project costs. The existing staff costs, in terms of the amount of FTE, department and grade should be stated. It will be expected that each department with staff identified will have signed off the PID and by doing so, they have committed that the staff resources will be available at the times stated.

12.1.2 NEW OR INCREASE TO EXISTING STAFF These are the costs associated with the recruitment of additional staff to assist with the delivery of the project, or to backfill existing posts to free up existing staff to work on the project. These costs need to be accounted for as part of the project funding.

12.1.3 NON-STAFF COSTSThese are the costs for anything other than staff in the headings:• IT equipment: (PCs, Macs, laptops, printers, peripherals)• IT network equipment: (Network equipment: servers, racking, cabling, switches, trunking, leads)• Software : (ALL system software, network and server software, desktop software)• Mobile technologies: (PDAs, smartphones, netpads, iPhones, iPads)• Consultancy Services: third party resource. (If a procurement exercise needs to be undertaken

as part of the project then at this stage it would be advisable to obtain indicative quotes from a selection of vendors and take the average of these to give an indication of the likely costs).

• If you need another heading please use ‘Other’ and describe what the item is.

VAT must be included unless Finance has specifically advised that the purchase is VAT exempt (if exempt state reason for exemption).



12.1.4 FUTURE RUNNING COSTSThe future running costs of providing a supported service should be stated separately. Any new system needs some form of operational support locating and resourcing. Again no additional resource may be necessary but support for IT systems (servers, databases, applications, etc) need to be clearly identified and explicitly agreed with IS and/or additional staff for administration agreed with local department management.

12.1.5 CONTINGENCYA contingency of 15% will be added to the new project funding totals

13 PLANNING APPROACH

A milestone plan (high level) of the major achievements for the project and its expected stages will be outlined here. Please also attach a Gantt chart for this (can be produced in MindGenius, Excel, or MS Project).

An integral part of any new service or system is planning for the operational support. Staff effort is being committed here, and any IS staff time will need to have been estimated and agreed by IS managers. Where interfaces to other systems are involved remember to gain department management commitment for their staff to carry out the interface testing on their systems.

A useful technique to help with the accuracy of detailed planning is to write a detailed stage plan of individual tasks immediately before the stage starts and it should be approved by the Project Board. Typical stages for an IT project might be Review Processes, Requirements Specification, Design, Develop, Develop Support, Test, Pilot, and Roll-out.

Tip: Plan one step at a time.

13.1 MILESTONE PLAN FOR PROJECT

Stage Milestone Completion Date



14 PROJECT TOLERANCES & EXCEPTIONS

Tolerances are the pre-agreed boundaries for the project in terms of time and cost which can be dealt with without escalating the problem to the next level of management - usually from Project Manager to Project Sponsor. The situation where a project is forecast to exceed its pre-agreed tolerances is known as an exception. The project manager should work out a way to manage the exception (with an exception plan) and raise this immediately with the sponsor. The exception will by its nature, be raising a threat to the planned project delivery. Tolerances are usually stated as: Time: Plus or minus amount of time on planned completion date Cost: Plus or minus amounts of money on planned budgetsTolerance levels can also be set for quality and scope.

15 THE LAST WORD

This is your document, so you need to make sure that it is useful to you, as the Project Manager. The structure of the template was created from years of project management best practice and experience, and is something that works! Treat the PID as your ‘master plan’ of how you are going to manage the project and deliver it to time, cost and quality. You can use it as a constant source of reference for you, and others involved in the project. It is recommended that you copy to all the key resources on your project to share your plans and to assist their understanding of the project.

The PID is also a useful communications tool and can inform interested parties what your project is going to do, and how it will be done. It can be summarised as “If it is not in here . . . then is not part of this project”.

Experienced project managers view the PID as their most useful document within a project.

The completed and Project Board approved document should be sent to: [email protected] for logging.


mailto:[email protected]


16 APPENDICES

16.1 IT PM DOCUMENT STANDARDS

These are the document standards that are being applied to all PMO documents. You can adopt these or develop your own, as appropriate.

16.1.1 FONT, SPACING, & HEADINGSThe style is the Microsoft ‘Modern’ with only the following changes: Font: Calibri 11pt Line spacing at 1.15 with zero spacing before and after Use heading with auto-numbering

Headings: Use “1.1.1. Heading 1” etc.

Where possible use standard MS Word margins

16.1.2 FOOTER & VERSION CONTROLTo ensure document control regarding naming and version control there is a need for the following on all documents:

A unique document ID to ensure that the correct document has been used. This should be within the footer and can be either:o Filename with incremental amendments for each change e.g. filename-a, filename-b,

filename-c, or filename-01, filename-02, filename-03 etc.o Filename plus dateo Filename plus version number

Page numbers where there are more than one page. It is important to know if the document is missing some pages, and therefore it is essential to know which is the last page. This can be done with either:

o Page number of the total pages, e.g. ‘1 of 23’, ‘2 of 23’, etc.o Page number plus ‘This is the last page’ on the final page

An example of the above footer is:14-Mar-2013 PID – Guide 01.doc Page 1 of 1

This convention has also been used on this document.
