Stage 2: Project planning and defining design and approach
Once the project mandate has been approved (Gate 1), the Project Manager can commence detailed planning of the project.
This is an important phase within the project as it determines the preferred approach along with the key milestones, deliverables, activities and resources (people and money), and the project benefits including success measures.
This includes:
- defining the governance structure for the project, involving setting up regular project board or steering group meetings and defining the roles and responsibilities of project team members. The documents by which you will manage and control the project will also need to be put in place. Further information is available in the meeting guide
- describe the delivery approach i.e. big bang, phased, pilot, feasibility or design study
- baseline the anticipated benefits
- identify the resource profile; quantify resources, identify skills required and whether they exist within the University or will need to be procured externally
- undertake full consultation with stakeholders. This involves those who will need to contribute to the project, will influence the project and or are impacted by the project. If the project requires existing resources to work on the project, approval must be sought from the relevant business area/Head of Department prior to submission of the business case
- develop a project plan which sets out the timescales and key milestones for delivery of activities, products and completion of project phases
- describe how the project will transition to business as usual
If the project requires the procurement of a system, it is important that key requirements are captured and reviewed by IT during the business case development, and attached to the business case as an appendix.
Project objectives
Project objectives should be a short statement describing the positive change the project aims to make. They should define the desired benefits, outcomes or performance improvements that the project expects to deliver.
Objectives can be outputs, such as the delivery of a new system or a new building; outcomes, such as all teams being trained to use a new system, or moving a team in to a new building; or benefits, such as increased turn over due to new system, or reduced building costs as a result of the new building.
Project objectives should not describe what you plan to do or how you plan to do it.
- Include a list of outcomes that the project hopes to achieve.
- For each, be as specific as possible and think about how to measure success. Key objectives should be SMART, for example:
- action (increase, decrease, eliminate, improve etc.)
- area of change (expenditures, errors, costs, revenue, paperwork, turnaround, time etc.)
- measurable value and units (percentage, numbers of people, number of days etc.)
- date (deadline)
- include time estimates where possible Be realistic; only include objectives that are achievable
Example
Objective: Reduce spending on printer paper by 50% by December.
- Specific: What exactly needs to be accomplished?
- Measurable: How will the objectives be measured?
- Achievable: Is the objective achievable?
- Realistic: Can the objective be met?
- Timely: The time by which the objective should be delivered?
How the objectives should be written
Project objectives should be presented in the following format:
“To (improve / increase / reduce / enhance) something, by (amount) (£ / %), by (date)".
- To reduce the number of student complaints by 50%, by December 2016.
- To reduce time to respond to student complaints from 5 days to 2 days by December 2016.
- To increase the student satisfaction score by 10%, by January 2017.
- To increase the University website traffic by 50%, by June 2017.
Business case
The business case (.docx) sets out the reasons why the project is required and should give full consideration to the nature, organisation and implementation of the project including how it will contribute towards the achievement of our University’s strategic objectives.
The business case will consider the following key areas:
- strategic rationale – what problem is the project seeking to address
- key objectives
- business options: Be clear about what you hope to achieve. Consider the different ways in which they could be achieved and assess the costs, benefits and risks of the different options
- project deliverables – list the key activities, products and milestones
- project benefits
- financial investment
- project planning – what is the resource profile (how will the project be resourced) and the delivery approach
- communication strategy – how will the project engage with its stakeholders
- privacy impact assessment
All relevant stakeholders must have been consulted with, for example if the project requires IT services resource, the project manager must work in conjunction with the subject matter expert in IT Services to determine realistic timescales for delivery of activity or products and obtain agreement that the resources are secured.
The business case should be created during the Stage 2 planning phase and once approved, maintained throughout the lifecycle of the project. This allows the business case to act as a key reference point and provide an audit trail of approved decision making.
The privacy impact assessment (.docx) should be used in conjunction with the business case template.
Gate 2: Approval of the business case
Once the business case (.docx) is developed it should be shared with the Project Sponsor for approval before it is submitted to its respective sub-group.
The sub-groups have two roles at this stage:
- provide a forum for discussion, advice and guidance on business cases. Project Managers are invited to attend the meeting of the sub-group at which their project is considered in order to answer any queries or requests for additional information
- endorse business cases to the relevant committee for approval, and make recommendations on the timing and delivery of newly proposed projects
PCG may make one of three decisions when considering a business case:
- Approved for implementation: The proposed project is approved for implementation within the agreed budget, scope and timescales set out in the business case
- Referred: The project mandate is referred back to the Project Manager as further work is required. PCG will recommend a future date for submission of the revised project mandate
- Rejected: The proposed project is rejected and should not be submitted to PCG for consideration within the next 12 months
If the project budget is greater than the amount approved at Gate 1 (approval of the project mandate) the business case will be endorsed by PCG to the appropriate committee for consideration for approval.
It is the responsibility of the secretary of PCG to inform Project Managers and Project Sponsors in writing of the decision made by the authorising committee.
