Glasgow Community and Safety Services
Project Management A corporate approach to managing projects Guidance on the methodology, processes and procedures.
Document Control Version No: No. 0.1
Created: 07 December 2012
Review Date: 07.12.13
Reviewed by: Eileen Marshall
Author: Stephen Miller
NOT PROTECTIVELY MARKED
CONTENT:
1.
PURPOSE / AIM…………………..……………………….………….………………..………..3
2.
INTRODUCTION....……..……………...…………………………..………………………..…..3
3.
WHAT IS A PROJECT?....………………………………………………………………….…..3
4.
THE DEFINING PRINCIPLES…………………..…...………………… …….……..…………4
5.
PROJECT MANAGEMENT…………………….……………………………………….………4
6.
PROJECT STRUCTURES…………………………………………..…………………………..4
7.
PROJECT LIFE CYCLE ……………………………………..…………………….……………5
8.
PROJECT INITIATION……………………..……………………………………….…….……..7
9.
PROJECT PLANNING………………….....…………………………………………………….9
10.
PROJECT EXECUTION……………………………………………………………………....11
11.
PROJECT CLOSURE……………………………………………………………………..……14
12.
GLOSSARY……………………………………………………………………………………...15
APPENDICES Appendix A – Business Case template
1
NOT PROTECTIVELY MARKED
1.
PURPOSE / AIM
1.1
The purpose of the document is to provide a clear and consistent approach to those members of staff who are asked to manage or to become part of a team expected to deliver a project within GCSS. The document is intended to act as a guide for individuals at all levels of the organisation.
1.2
Furthermore, the document aims to outline a structured and practical method for the effective management of projects irrespective of the anticipated scale and duration.
1.3
The document is intended to be used when it has been decided at a senior level not to implement a PRINCE2 (P2) approach (the preferred method). However, the P2 approach requires qualified practitioners to undertake and deliver its methodology, hence the raison d’être for this particular document.
2.
INTRODUCTION
2.1
Without a project management method, those who commission a project, those who manage it and those who work on it will have different ideas about how things should be organised and when the different aspects of the project will be completed.
2.2
Those involved will not be clear about how much responsibility, authority and accountability they have and, as a result, there will often be confusion surrounding the project.
2.3
Without a project management method, projects are rarely completed on time and within acceptable cost (which is especially true of larger projects) and therefore a good project management method will guide the project through a controlled, well-managed, visible set of activities to achieve the desired outcome.
3.
WHAT IS A PROJECT?
3.1
There are many definitions of what a project entails. However, the following definition puts it succinctly: ‘a project is a management environment that is created for the purpose of delivering one or more business products according to a specified business case’.
3.2
Each project falls within a specific business context. A project may be standalone, it may be one in a sequence of projects or it may form part of a programme or corporate strategy.
3.3
A project, by its very nature is a temporary structure, created to achieve a specific business benefit or objective. When the work has been completed the project is disbanded.
3.4
A project has a life cycle, which is the path and sequence through the various activities to produce the final product. The life cycle covers the tasks of specifying and designing the product, through to its testing and handover into operational use.
3.5
Projects are different from standard business operational activities as they are: •
Unique in nature: (they do not involve repetitive processes)
•
Have a defined timescale: (a start and end date)
•
Have an approved budget: (an agreed level of financial expenditure)
•
Have limited resources: (labour, equipment and materials)
2
NOT PROTECTIVELY MARKED
•
Involve an element of risk: (a level of uncertainty about the outcome)
•
Achieve beneficial change: (to improve the organisation in some way)
4.
THE DEFINING PRINCIPLES
4.1
The following are the fundamental and defining principles that all projects within GCSS should be based upon: •
A project is a finite process with a definite start and end
•
Projects always need to be managed in order to be successful
•
For genuine commitment to the project, all parties must be clear about why the project is needed, what it is intended to achieve, how the outcome is to be achieved and what their responsibilities are in that achievement.
5.
PROJECT MANAGEMENT
5.1
Project management can be defined as; “the skills, tools and management processes required to undertake and deliver a project successfully.”
5.2
Project management (per se) comprises: Ø A set of skills – specialist knowledge, skills and experience are required to reduce the level of risk within a project and thereby enhance its likelihood of success. Ø A suite of tools – various types of tools are used by project managers to improve their chances of success. Examples include: document templates, registers, planning software, modelling software, audit checklists and review forms. Ø A series of processes – various management techniques and processes are required to monitor and control time, cost, quality, and scope on projects. Examples include: time management, cost management, quality management, change management, risk management and issue management.
6.
PROJECT STRUCTURES
6.1
Each project undertaken must address all the relevant processes concerned and should have:
6.2
•
A stated business case indicating the benefits and risks of the venture
•
A properly defined and unique set of products and deliverables
•
A corresponding set of activities to construct the products
•
Appropriate resources to undertake the activities
•
A finite life span
•
Suitable arrangements for control
•
An organisational structure with defined responsibilities
•
A set of processes with associated techniques which will help plan and control the project and bring it to a successful conclusion.
The project should be divided into a number of stages, each forming a distinct unit for management purposes. Like the project, a stage should be driven by a 3
NOT PROTECTIVELY MARKED
series of sub-processes, has a defined set of products and activities, a finite life span, control elements, and an organisational structure. 6.3
The delivery of these products, to the agreed quality standards, marks the completion of the stage.
6.4
The following diagram identifies the fundamental management within a quality management framework:
aspects
Project management within a quality management framework
BUSINESS CASE
Products & activities
Project plans
ORGANISATION OF THE PROJECT & IT’S STAGES
Processes
Techniques Controls
7.
PROJECT LIFE CYCE
7.1
A project life cycle consists of four distinct phases and these are: Ø Initiation Ø Planning Ø Execution 4
of
project
NOT PROTECTIVELY MARKED
Ø Closure 7.2
The following diagram demonstrates how they are interconnected:
Project Initiation
Post Implementation Review
Project closure
Project Definition
PROJECT LIFECYCLE
Monitoring & Control
Project planning
Detailed Planning
Project execution
7.3
Project initiation: the initiation phase is the first phase of the project. In this phase a business problem (or opportunity) is identified and a business case which provides various solution options is defined. A feasibility study is then conducted to investigate the likelihood of each solution option addressing the business problem and a final recommendation is proposed. Once the recommendation solution is approved, a project is initiated to deliver the approved solution. A ‘Project Initiation Document’ (PID) is completed, which outlines the objectives, scope and structure of the new project, and a Project Manager (PM) is appointed. The PM begins organising a project team and establishes a project management office (PMO) environment. Approval is then sought to move into the detailed planning phase.
7.4
Project Planning: Once the scope of the project has been defined in the PID, the project enters the detailed planning phase. This involves the creation of documents to support the PID: •
Project plan timeframes)
(outlining
the
5
activities,
tasks,
dependencies
and
NOT PROTECTIVELY MARKED
•
Resource plan (listing the labour, equipment and materials required)
•
Financial plan (identifying the labour, equipment and materials costs)
•
Quality plan (providing quality targets, assurance and control measures)
•
Risk plan (highlighting potential risks and actions to mitigate them)
•
Acceptance plan (listing the criteria to be met to gain customer acceptance)
•
Communications plan (listing the information needed to inform stakeholders)
•
Procurement plan (identifying products to be sourced from external suppliers).
7.5
At this point the project has now been planned in detail and is ready to be executed.
7.6
Project execution: This phase involves the execution of each activity and task listed in the project plan. While the activities and tasks are being executed, a series of management processes are undertaken to monitor and control the deliverables being output by the project. This includes the identification of changes, risks and issues, the review of deliverable quality and the measurement of each deliverable being produced against acceptable criteria. Once all of the deliverables have been produced and the customer has accepted the final solution, the project is ready for closure.
7.7
Project closure: This is the final phase and involves releasing the final deliverables to the customer, handing over the project documentation, terminating supplier contracts (if they exist), releasing project resources and communicating the closure of the project to all stakeholders. The last remaining step is to undertake a post implementation review to quantify the overall success of the project and list any lessons learnt for future projects.
7.8
Each of the 4 phases will now be explained in more detail.
8.
PROJECT INITIATION
8.1
The initiation phase essentially involves the project ‘start-up’. It is the phase within which the business problem or opportunity is identified, the solution is agreed, a project formed to produce the solution and a project team appointed. The following diagram illustrates the activities to be undertaken:
Develop a business case
Establish the ‘project initiation document’
Undertake a feasibility study
Appoint a project team
6
Establish a project management office
Perform phase review
NOT PROTECTIVELY MARKED
8.2
Develop A Business Case: Once a business problem or opportunity has been identified, a Business Case is prepared. This includes: •
A detailed definition of the problem or opportunity
•
An analysis of the potential options available. For each option, the potential benefits, costs, risks and issues are documented. A formal feasibility study may be commissioned if the feasibility of any particular option is not clear.
•
The recommendation implementation plan
of
the
preferred
option
and
a
generic
8.3
The Business Case is approved by the project sponsor and the required funding is allocated to proceed with the project. A template Business Case is attached at appendix ‘A’.
8.4
Perform Feasibility Study: At any stage during (or after) the development of a Business Case, a formal Feasibility Study may be commissioned. The purpose is to assess the likelihood of a particular option achieving the benefits outlined in the Business Case. The Feasibility Study will also investigate whether the forecast costs are reasonable, the option is achievable, the risks are acceptable and/or if any likely issues are avoidable.
8.5
Establish ‘Project Initiation Document’ (PID): After an option has been agreed and the funding allocated, a project is formed. The PID defines the vision, objectives, scope and deliverables for the project. It also provides the organisation structure (roles and responsibilities) and a summarised plan of the activities, resources and funding required to undertake the project. Finally, any risks, issues, planning assumptions and constraints are listed.
8.6
Appoint a Project Team: At this point the scope of the project has been defined in detail and the project team are ready to be appointed. Although a Project Manager can be appointed at any stage of the project, the PM will need to be appointed prior to the establishment of the project team. The Project Manager documents a detailed job description for each project role and appoints a human resource to each role based on his/her relevant skills and experience. Once the team are ‘fully resourced’, the Project Management Office (PMO) is ready to be set-up.
8.7
Creating a Project Management Office (PMO): The project management office is the physical environment within which the team will be based. Although it is usual to have one central project office, it is possible to have a ‘virtual PMO’ environment, with project team members in various locations. Regardless of the location, a successful project management office environment will comprise the following components: •
Comfortable, suitable and spacious location
•
Communications (telephones, PC’s, data storage & back-up facilities)
•
Documentation (methodology, processes, templates and registers)
•
Tools (accounting, project planning and risk modelling)
•
Any other facilities and support, as required by the Project Team
7
NOT PROTECTIVELY MARKED
9.
PROJECT PLANNING
9.1
By this stage, the benefits and costs of the project have been clearly documented, the objectives and scope have been defined, the project team has been appointed and a formal project management office environment established. It is now time to undertake detailed planning to ensure that the activities performed in the execution phase of the project are properly sequenced, resourced, executed and controlled.
9.2
Develop a project plan: The first step is to document the project plan. The ‘Work Breakdown Structure’ (WBS) is identified, which includes a hierarchical set of phases, activities and tasks to be undertaken on the project. After the WBS has been agreed, an assessment of the effort required to undertake the activities and tasks are sequenced, resources are allocated and a detailed project schedule is formed. The project schedule will become the primary tool for the Project Manager to assess the progress of the project
9.3
Develop a resource plan: Immediately after the project plan is formed, it is necessary to allocate the resources required to undertake each of the activities and tasks within the project plan. Although general groups of resources may already have been allocated to the project plan, a detailed resource assessment is required to identify: Ø The types of resources (labour, equipment and materials) Ø Total quantities of each resource Ø Roles, responsibilities and skill-sets of all human resources Ø Items, purposes and specifications of all equipment resources Ø Items and quantities of material resources
9.4
A schedule is assembled for each type of resource so that the Project Manager can assess the resource allocation at each stage in the project.
9.5
Develop a financial plan: Similar to the resource plan, a financial plan is prepared to identify the quantity of money required for each stage in the project. The total cost of labour, equipment and materials is quantified and an expense schedule is defined which provides the PM with an understanding of forecast spending versus the actual spending throughout the project. Preparing a detailed financial plan is extremely important as the project’s success will depend on whether or not it is delivered within the ‘time, cost and quality’ estimates for the project.
9.6
Develop a quality plan: Meeting the quality expectations of the customer is critical to the success of the project. To ensure that the quality expectations are clearly defined and can reasonably be achieved, a quality plan is documented. The quality plan: Ø Defines what quality means in terms of the project Ø Lists clear and unambiguous quality targets for each deliverable. Each quality target provides a set of criteria and standards which must be achieved to meet the expectations of the customer Ø Outlines a plan of activities which will assure the customer that the quality targets will be met (i.e. Quality Assurance Plan) 8
NOT PROTECTIVELY MARKED
Ă˜ďƒ˜ Identifies the techniques used to control the actual level of quality of each deliverable as it is built (i.e. a Quality Control Plan) 9.7
Finally, it is important to review the quality not only of the deliverables produced by the project but also of the management processes which produce them. A summary of the management processes undertaken during the execution phase is identified, including time, cost, quality, change, risk, issue, procurement, acceptance, and communications management.
9.8
Develop a risk plan: The foreseeable project risks are then documented within a risk plan and a set of actions to be taken formulated to both prevent each risk from occurring and reduce the impact of the risk should it occur. Developing a clear risk plan is an important activity within the planning phase as it is necessary to mitigate all critical project risks prior to entering the execution phase of the project.
9.9
Develop an acceptance plan: The key to a successful project is gaining acceptance from the customer that each deliverable produced meets (or exceeds) their requirements. To clarify the criteria used to judge each deliverable for customer acceptance, an acceptance plan is produced. The acceptance plan provides the criteria for obtaining customer acceptance, a schedule of acceptance reviews within which customer acceptance will be sought and a summary of the process used to gain acceptance of each deliverable from the customer.
9.10
Develop a communications plan: Prior to the execution phase, it is also necessary to identify how each of the stakeholders will be kept informed of the progress of the project. The communications plan identifies the types of information to be distributed, the methods of distributing information to stakeholders, the frequency of distribution and responsibilities of each person in the project team for distributing information regularly to stakeholders.
9.11
Develop a procurement plan: The last planning activity within the planning phase is to identify the elements of the project which will be acquired from external suppliers to the project. The procurement plan provides a detailed description of the products (i.e. goods and services) to be procured from suppliers, the justification for procuring each product externally, as opposed to from within GCSS, and the schedule for procurement. It also references the process for the selection of a preferred supplier (preferably through PECOS) or through a tender process and the process for actual order and delivery of the procured products (i.e. the procurement process).
9.12
Contract suppliers: Although external suppliers may be appointed at any stage of the project, it is usual to appoint suppliers after the project plans have been documented, but prior to the execution phase. Only at this point will the PM have a clear idea of the role of the supplier and the expectations for their delivery. A formal tender process is invoked to identify a short-list of interested suppliers to help select a preferred supplier (if they are not already on the approved list) to meet the procurement needs of the project. The tender process involves creating a statement of work, a request for information and request for proposal to obtain sufficient information from each potential supplier to select a preferred supplier. Once a preferred supplier has been chosen, a supplier contract is agreed for the delivery of the requisite product.
9.13
Perform phase review: At the end of the planning phase, a review is performed. This is basically a checkpoint to ensure that the project has achieved its stated objectives as planned.
9
NOT PROTECTIVELY MARKED
9.14
An overview of the project planning phase:
Create a project plan
Create a resource plan
Create a financial plan
Create a quality plan
Create a risk plan
Perform phase review
Contract the suppliers
Create a procurement plan
Create a communications plan
Create an acceptance plan
10.
PROJECT EXECUTION
10.1
The execution phase is typically the longest phase of the project (in terms of duration). It is the phase within which the deliverables are physically constructed and presented to the customer for acceptance. To ensure that the customer’s requirements are met, the PM monitors and controls the activities, resources and expenditure required to build each deliverable throughout the execution phase. A number of management processes are also undertaken to ensure that the project proceeds as planned.
10.3
Build Deliverables: This phase requires the physical construction of each deliverable for acceptance by the customer. The actual activities undertaken to construct each deliverable will vary, depending on the type of project (e.g. engineering, building development, computer infrastructure or business process re-engineering projects). Deliverables may be constructed in a ‘waterfall’ fashion (where each activity is undertaken in sequence until the deliverable is finished) or an ‘iterative’ fashion (where iterations of each deliverable are constructed until the deliverable meets the requirements of the customer). Regardless of the method used to construct each deliverable, careful monitoring and control processes should be used to ensure that the quality of the final deliverable meets the acceptance criteria set by the customer.
10.4
Monitor and Control: Whilst the Project Team are physically producing each deliverable, the PM implements a series of management processes to monitor and control the activities being undertaken. An overview of each management process will follow.
10.5
Time Management: Time Management is the process within which time spent by staff undertaking project tasks is recorded against the project. As time is a scarce resource on projects, it is important to record the time spent by each member of the team on a timesheet to enable the PM to control the level of resource allocated to a particular activity. A ‘Timesheet Register’ provides a summary of the time currently spent on the project and enables the Project Plan to be kept fully up to date.
10
NOT PROTECTIVELY MARKED
10.6
Cost Management: Cost Management is the process by which costs (or expenses) incurred on the project are fully identified, approved and paid. Expense Forms are completed for each set of related project expenses such as labour, equipment and materials cost. Expense Forms are approved by the PM and recorded within an ‘Expenses Register’ for audit purposes. The Finance section within GCSS can assist with this aspect of the project.
10.7
Quality Management: Quality is defined as: “the level of conformance of the final deliverable to the customer’s requirements”. Quality Management is the process by which the quality of the deliverables is assured and controlled for the project, using Quality Assurance and Quality Control techniques. Quality reviews are frequently undertaken and the results recorded with a ‘Quality Register’.
10.8
Change Management: Change Management is the process by which changes to the project’s scope, deliverables, timescales or resources are formally defined, evaluated and approved prior to implementation. A core aspect of the PM’s role is to manage change within the project successfully. This is achieved by understanding the business and system drivers requiring the change, documenting the benefits and costs of adopting the change and formulating a structured plan for implementing the change. To formally request a change it is often necessary to complete a Change Control Form (CCF). The change request details may then be recorded within a ‘Change Control Register’.
10.9
Risk Management: Risk Management is the process by which risks to the project (e.g. to the scope, deliverables, timescales or resources) are formally identified, quantified and managed during the project. A project risk may be identified at any stage of the project by completing a Risk Form and recording the relevant risk details within the ‘Risk Register’ (similar to the pre-existing Operational Risk Registers).
10.10 Issue Management: Issue Management is the method by which issues currently affecting the ability of the project to produce the required deliverables are formally managed. After completion of an Issue Form (and logging the details within the ‘Issue Register’), each issue is evaluated by the PM and a set of actions undertaken to resolve the issue at hand. 10.11 Procurement Management: Procurement Management is the process by which a product is sourced from an external supplier. To request the delivery of a product from a suppler, a Purchase Order must be approved by the PM and sent to the supplier for confirmation through the GCSS procurement team. The status of the purchase is then tracked using a ‘Procurement Register’ until the product has been delivered and accepted by the project team. 10.12 Acceptance Management: Acceptance Management is the process by which deliverables produced by the project are reviewed and accepted by the customer as meeting their specific requirements. To request the acceptance of a deliverable by the customer, an Acceptance Form is completed. The Acceptance Form describes the criteria from which the deliverable has been produced and the level of satisfaction of each criterion listed. 10.13 Communication Management: Communications Management is the process by which formal communications messages are identified, created, reviewed and communicated within a project. The most common method of communicating the status of the project is via a Project Status Report. Each communication item released to the project stakeholders is captured within a ‘Communications Register’.
11
NOT PROTECTIVELY MARKED
10.14 Perform Phase Review: At the end of the Execution Phase, a Phase Review is performed. This is basically a checkpoint to ensure that the project has achieved its stated objectives as planned. 10.15 An overview of the project execution activities:
Build Deliverables Perform Phase Review Monitor & Control
Perform Time Management
Perform Risk Management
Perform Cost Management
Perform Issue Management
Perform Quality Management
Perform Procurement Management
Perform Change Management
Perform Acceptance Management
Perform Communications Management
12
NOT PROTECTIVELY MARKED
11.
PROJECT CLOSURE
11.1
Following the completion of all project deliverables and acceptance by the customer, a successful project will have met its objectives and be ready for formal closure. Project Closure is the last phase in the project and must be conducted formally so that the business benefits delivered by the project are fully realised by the customer.
Perform Project Closure
11.2
Review Project Completion
Perform Project Closure: Project Closure involves undertaking a series of activities to wind up the project, including: •
Assessing whether the project completion criteria have been met
•
Identifying any outstanding items (activities, risks or issues)
•
Producing a handover plan to transfer the deliverables to the customer environment
•
Listing the activities required to hand over documentation, cancel supplier contracts and release project resources to the business
•
Communication closure to all stakeholders and interested parties
A Project Closure Report is submitted to the customer and/or Project Sponsor for approval. The PM is then responsible for undertaking each of the activities identified within the Project Closure Report on time and according to budget. The project is closed only when all activities identified in the Project Closure Report have been completed. 11.3
11.4
Review Project Completion: The final activity undertaken on any project is a review of its overall success by an independent resource. Success is determined by how well it performed against the defined objectives and conformed to the management processes outlined in the planning phase. To determine performance, a number of questions are posed. For example: •
Did it result in the benefits defined in the Business Case?
•
Did it achieve the objectives outlined in the PID?
•
Did it operate within the scope of the PID?
•
Did the deliverables meet the criteria defined in the Quality Plan?
•
Was it delivered within the schedule outlined in the Project Plan?
•
Was it delivered within the budget outlined in the Financial Plan?
To determine conformance, a review is undertaken of the level of conformity of the project activities of the management processes outlined in the Quality Plan. The above results, key achievements and lessons learnt are documented within a Post Implementation Review report and presented to the Project Sponsor for approval. ========================== 13
NOT PROTECTIVELY MARKED
Glossary Terms The following definitions apply to the terminology used within the Project Lifecycle: Acceptance Management: The process by which deliverables produced by the project are reviewed and accepted by the customer as meeting their specific requirements Acceptance Planning: The process of identifying the milestones, criteria and standards for the acceptance of project deliverables by the customer Business Case: This document outlines the justification for the initiation of a project. It includes a description of the business problem (or opportunity), a list of the available solution options, their associated costs and benefits and a preferred option for approval. Change Management: The process by which changes to the project scope, deliverables, timescales or resources are formally defined, evaluated and approved prior to implementation. Communications Management: The process by which formal communications messages are identified, created, reviewed and communicated within a project Communications Planning: The process of identifying the type and regularity of information to be provided to all project stakeholders to keep them informed of the progress of the project Cost Management: The process by which costs (or expenses) incurred on the project are formally identified, approved and paid. Deliverable: A quantifiable outcome of the project which results in the partial (or full) achievement of the project objectives Dependency: A logical relationship between two or more project activities. The four types of dependences include: start-to-finish, start-to-start, finish-to-start, finish-to-finish Feasibility Study: A document which identifies each of the solution options to a particular business problem (or opportunity) and assesses the likelihood of each option’s achieving the desired result Financial Planning: The process of identifying the financial resources required to undertake the project. This includes a list of the types of costs to be incurred on the project (e.g. labour, equipment, materials and administration costs) and a schedule outlining which the respective costs are likely to be incurred Issue: Events which are currently affecting the ability of the project to produce the required deliverables Issue Management: The process by which issues are formally identified, communicated, monitored and resolved Job Description: A document which describes a particular role and its responsibilities within a project Milestone: The recognition of an important event within the project, usually the achievement of a key project deliverable Procurement Management: The process by which product is actually sourced form a preferred supplier, including the on-going management of the supplier relationship Procurement Planning: The process of identifying the products to be sourced externally and the methods of acquiring them Product: A good or service which is acquired from an external supplier to assist with the production of a project deliverable
14
NOT PROTECTIVELY MARKED
Project: A unique endeavour to produce a set of deliverables within clearly specified time, cost and quality constraints Project Activity: A set of project tasks which usually results in the partial (or full) completion of a project deliverable Project Lifecycle: A series of project phases which are undertaken in either sequential or parallel order Project Management: The skills, tools and management processes required to successfully undertake a project Project Office: The physical premises within which Project Administration staff (e.g. the Project Manager and support staff) reside Project Phase: A set of project activities and tasks which usually result in the completion of a project deliverable Project Plan: A document which lists the phases, activities, tasks, timeframes and resources required to complete the project Project Schedule: A series of planned dates within which activities and tasks have to be completed to achieve project milestones Project Task: A specific work item to be undertaken which usually results in the partial completion of a project deliverable Project Team: A collation of people who report to the Project Manager Quality: The level of conformance of the final deliverable(s) to the customer’s requirements Quality Assurance: The preventative steps taken to eliminate any variances in the quality of the deliverable produced from the quality targets set Quality Control: The curative steps taken to eliminate any variances in the quality of the deliverable produced from the quality target set Quality Management: The process by which the quality of the deliverables and management processes is assured and controlled for the project, using Quality Assurance and Quality Control techniques Quality Planning: The process of identifying the approach taken to ensure the quality of the deliverables produced by the project and of the management processes undertaken. This includes a list of the quality criteria and standards to be achieved as well as the Quality Assurance and Quality Control techniques to be undertaken. Request for Information: This document is issued by a project team to a wide group of potential suppliers to enable those suppliers to provide summarised information outlining how they will meet the procurement requirements of the project. Request for Proposal: A document which is issued by a project to a short listed group of suppliers to enable the suppliers to submit a detailed proposal outlining how they will meet the procurement requirements of the project Resource: The labour, equipment and materials used to complete the activities in the Project. Resource Planning: The process of identifying the resources required to complete the project. This includes a list of the types of resources required and a schedule providing the use of and activities undertaken by each resource. Risk: Any event which is likely to adversely affect the ability of the project to achieve the defined objectives.
15
NOT PROTECTIVELY MARKED
Risk Management: The process by which risks to the project (e.g. to the scope, deliverables, timescales or resources) are formally identified, quantified and managed during the project. The process entails completing a number of actions to reduce the likelihood of occurrence and the severity of impact of each risk Risk Mitigation: A set of actions to be taken to avoid, transfer or mitigate a risk, based on its priority. This includes the preventative actions to be taken during the project to reduce the likelihood of the risk’s occurring as well as the contingent actions to be taken to reduce the impact on the project should the risk eventuate Risk Planning: The formulation of a document that will outline the foreseeable project risks and provide a set of actions to be taken to both prevent the risk from occurring and reduce the impact of the risk should it eventuate. Scope: The total aggregation of deliverables to be produced by the project Solution: A set of deliverables which, once combined, solve a particular business problem (or realise a particular business opportunity) Stage-Gate: A checkpoint at the end of each project phase to ensure that the project has achieved its stated objectives and deliverables as planned Statement of Work: A document which defines the procurement requirements of the project in sufficient detail to enable potential suppliers to determine if they are able to meet those requirements Supplier Contract: An agreement between the Project Team and an external supplier for the acquisition of a defined set of products to meet the procurement requirements of the Project Tender Document: A formal document included during the tender process which outlines the information required to provide the Project Team with the confidence that a supplier can meet the procurement needs of the project. The RFI and RFP are both examples of Tender Documents Tender Management: The process, by which interested suppliers are identified, evaluated and selected for the supply of products (goods or services) to the project. This process entails formalising the procurement requirements and tender documentation, receiving tender responses and selecting a preferred supplier Terms of Reference: A document which outlines the purpose of the project, the manner in which the project will be structured and how it will be successfully implemented Time Management: The process within which time spent by staff undertaking project tasks is recorded against the project
=========================
16
NOT PROTECTIVELY MARKED
APPENDIX ‘A’
BUSINESS CASE - TEMPLATE TABLE OF CONTENTS IN A BUSINESS CASE
1.
Executive Summary 1.1 1.2. 1.3 1.4
Issues Anticipated Outcomes Recommendations Justification
2.
Business Case Analysis Team
3.
Problem Definition 3.1 3.2 3.3
4.
Problem Statement Organisational Impact Technology Migration Project Overview
4.1 4.2 4.3 4.4 4.5 4.6
Project Description Goals and Objectives Project Performance Project Assumptions Project Constraints Major Project Milestones
5.
Strategic Alignment
6.
Cost Benefit Analysis
7.
Alternative Analysis
8.
Approvals
17
NOT PROTECTIVELY MARKED
1. EXECUTIVE SUMMARY This section should provide general information on the issues surrounding the business problem and the proposed project or initiative created to address it. Usually, this section is completed last after all other sections of the business case have been written. This is because the executive summary is exactly that, a summary of the detail that is provided in subsequent sections of the document. This business case outlines how the proposed project will address current business concerns, the benefits of the project, and recommendations and justification of the project. The business case also discusses detailed project goals, performance measures, assumptions, constraints, and alternative options. 1.1. Issue This section should briefly describe the business problem that the proposed project will address. This section should not describe how the problem will be addressed, only what the problem is. 1.2. Anticipated Outcomes This section should describe the anticipated outcome if the proposed project or initiative is implemented. It should include how the project will benefit the business and describe what the end state of the project should be. 1.3. Recommendations This section summarises the approach for how the project will address the business problem. This section should also describe how desirable results will be achieved by moving forward with the project. 1.4. Justification This section justifies why the recommended project should be implemented and why it was selected over other alternatives. Where applicable, quantitative support should be provided and the impact of not implementing the project should also be stated. 2. BUSINESS CASE ANALYSIS TEAM This section describes the roles of the team members who developed the business case. It is imperative that participants and roles are clearly defined for the business case as well as throughout the life of the project. The following individuals comprise the business case analysis team. They are responsible for the analysis and creation of the business case (please note, not all roles are used in every project). Role
Description
Name/Title
Executive Sponsor
Provide executive support for the project
Project Manager
Manages the business case and project team
Process Improvement
Advises team on process improvement techniques
Technology Support
Provides all technology support for the project
Software Support
Provides all software support for the project
18
NOT PROTECTIVELY MARKED
3. PROBLEM DEFINITION 3.1. Problem Statement This section describes the business problem that this project was created to address. The problem may be process, technology, or product/service oriented. This section should not include any discussion related to the solution. 3.2. Organisational Impact This section describes how the proposed project will modify or affect the organisational processes, tools, hardware, and/or software. It should also explain any new roles which would be created or how existing roles may change as a result of the project. 3.3. Technology Migration This section provides a high-level overview of how the new technology will be implemented and how data from the legacy technology will be migrated. This section should also explain any outstanding technical requirements and obstacles which need to be addressed. 4. PROJECT OVERVIEW This section describes high-level information about the project to include a description, goals and objectives, performance criteria, assumptions, constraints, and milestones. This section consolidates all project-specific information into one chapter and allows for an easy understanding of the project since the baseline business problem, impacts, and recommendations have already been established. 4.1.
Project Description This section describes the approach the project will use to address the business problem(s). This includes what the project will consist of, a general description of how it will be executed, and the purpose of it.
4.2.
Goals and Objectives This section lists the business goals and objectives which are supported by the project and how the project will address them. A table similar to the one below should be used to show the business goals and objectives that the project supports and how it supports them: Business Goal/Objective Description
4.3.
Project Performance This section describes the measures that will be used to gauge the project’s performance and outcomes as they relate to key resources, processes, or services.
19
NOT PROTECTIVELY MARKED
A table similar to the one below should be used to show the key resources, processes, or services and their anticipated business outcomes in measuring the performance of the project. These performance measures will be quantified and further defined in the detailed project plan. Key Resources, Processes or Services
Performance Measures
4.4. Project Assumptions This section lists the preliminary assumptions for the proposed project. As the project is selected and moves into detailed project planning, the list of assumptions will most likely grow as the project plan is developed. However, for the business case there should be at least a preliminary list from which to build. 4.5. Project Constraints This section lists the preliminary constraints for the proposed project. As the project is selected and moves into detailed project planning, the list of constraints will most likely grow as the project plan is developed. However, for the business case there should be at least a preliminary list from which to build. 4.6. Major Project Milestones This section lists the major project milestones and their target completion dates. Since this is the business case, these milestones and target dates are general and in no way final. It is important to note that as the project planning moves forward, a base-lined schedule including all milestones will be completed. A table similar to the one below should be used to show the major project milestones identified at this time. As the project planning moves forward and the schedule is developed, the milestones and their target completion dates will be modified, adjusted, and finalised as necessary to establish the baseline schedule. Milestones/Deliverables
Target Date
20
NOT PROTECTIVELY MARKED
5. STRATEGIC ALIGNMENT All projects should support the organisation’s strategy and strategic plans in order to add value and maintain executive and organisational support. This section provides an overview of the organisational strategic plans that are related to the project. This includes the strategic plan, what the plan calls for, and how the project supports the strategic plan. Plan
Goals/Objectives
Relationship to Project
6. COST BENEFIT ANALYSIS Many consider this as one of the most important parts of a business case as it is often the costs or savings a project yields which win final approval to go forward. It is important to quantify the financial benefits of the project as much as possible in the business case. This is usually done in the form of a cost benefit analysis. The purpose of this is to illustrate the costs of the project and compare them with the benefits and savings to determine if the project is worth pursuing.
Action
Action Description Type
Net First Year Savings
21
First year costs (indicates anticipated savings)
NOT PROTECTIVELY MARKED
7. ALTERNATIVES ANALYSIS All business problems may be addressed by any number of alternative projects. While the business case is the result of having selected one such option, a brief summary of considered alternatives should also be included - one of which should be the status quo, or doing nothing. The reasons for not selecting the alternatives should also be included. No Project (Status Quo)
Reasons For Not Selecting Alternative
Alternative Option
Reasons For Not Selecting Alternative
Alternative Option
Reasons For Not Selecting Alternative
8. FINAL APPROVALS The business case is a document with which approval is granted or denied to move forward with the creation of a project. Therefore, the document should receive approval or disapproval from its executive review board. The signatures of the Approver’s in a table similar to the one below indicate an understanding of the purpose and content of the business case by those signing it. By signing it, individuals indicate that they approve of the proposed project outlined in the business case and that the next steps may be taken to create a formal project in accordance with the details outlined therein.
Approver Name
Title
Signature
22
Date