Project Kick-off meeting: Guidelines
UPMA Project Management Methodology:
1.0
09 February 2016
Scope
Introduction:
This document explains the use of project kick-off meetings
to begin a project and is intended to be a guide to those
organising and running such meetings.
2.0
Timeframes
Scope/Purpose
The Kick-off meeting will mark the official start of the project
and should be used to ensure that all
stakeholders/attendees have an understanding of, and
agree with, how the project is going to be conducted. This
will require the Project Sponsor and the Project Manager
(PM) to explain the following: the project’s objectives; the
processes and methods to be used to progress the project
and to govern it; any tools that will be used during the project
(that will assist its progress – logs and reports etc.); the roles
and responsibilities of the various team members; the
desired outcomes; and how success will be measured.
3.0
Topics for the meeting:
Therefore several topics should be covered at the kick-off
meeting and these are explained, below, in the form of a
meeting agenda and description.
Agenda item
Introductions
Context for project
Project
Governance
Project
organisation
Roles and
responsibilities
Project approach
Document1
Description
PM ensures that all
stakeholders know each
other and sets the scene
for why they have been
invited.
The project sponsor will
explain why the project is
going to be run and why at
this time. This can be
delivered as part of a
“vision” statement.
The PM explains how
project governance will
work (in terms of project
delivery group). The PM
also explains the extent to
which they have the
authority to continue.
The PM (endorsed by the
project sponsor) will
explain the project
organisation and outline
who will be involved (from
which area)
The PM will explain the
key roles within the project
organisation and will
outline responsibilities
PM outlines the Project
Management
Methodology, reporting,
controls, decision making
processes etc.
Resource
n/a
Major Milestones
Terms of reference for
project delivery
groups, etc.
Reference to Terms
of Reference
mentioned above
Reference to Terms
of Reference
mentioned above
Project Management
Methodology
documentation
Version: 14
PM explains the likely
milestones that will be
used
From Project
Specification/DefinitionBusiness case (or from
previous discussions
with key stakeholders).
From Project
Specification/DefinitionBusiness case (or from
previous discussions
with key stakeholders).
PM explains the
desired timescales
At any point in the meeting risks, issues or constraints may be
mentioned and these should be recorded.
4.0
Inputs:
The theory says that the Project Definition & Business Case
should be prepared and signed off before the kick-off meeting
and be used as the main reference document within the
meeting. In reality this is not always available in sufficient
detail or completeness to be used in the meeting. Where this
is the case the following should be available as a minimum:
 Vision / ideas, underpinning the project
 An outline statement of scope,
 Aims / goals for the project
 The desired timescales
 Sanction from the Governing body to progress to the
next decision point
5.0
Business vision
ISS rolling
programme plan
PM goes through an
outline of the scope of the
project and captures the
input of other attendees to
get to a detailed scope
that can be agreed.
PM explains the desired
timescales and records
any constraints etc. from
attendees
Outputs:
The theory says that the Project Initiation Document should be
able to be prepared following the kick-off meeting. In reality,
the information gathered at the meeting is only part of the
input to the PID. From a practical point the following should
be minimum output that PMs should strive to achieve:
 Sufficient information to confirm scope
 Confirmation of team details and a common
understanding of roles and responsibilities
 Common understanding of the approach to be taken
to drive and govern the project
 An initial view of the major risks, issues or constraints
that are likely to affect the project
Additionally, given sufficient time, an outline of requirements
should be captured / confirmed (based around discussions of
scope). Whilst this will not be presented as part of the PID it
will be useful as input to detailed estimating / planning. The
PM needs to guard against getting into too much detail and
straying into system analysis / design.
Page 1 of 2
Roles – quick reference
guide:
6.0
6.1








6.2


The role of Project Manager
6.4
With Project Sponsor develop project documentation
(Project Specification / Project Definition & Business
Case / PID)
With the Project Team scope and define business
solutions.
Service the Project Delivery Group and Project
Sponsor.
Plan, manage and deliver projects to time, cost and
quality.
Monitor, control and co-ordinate projects, escalating
issues and reporting progress.
Managing issues and risks.
Communicate project information to all stakeholders.
Formally close projects.





6.5


The role of the Project Delivery Group
Be accountable for the quality of the solution delivered
 The business case is sufficiently well defined & realistic
 Quality assurance of documentation (e.g. project
initiation document)
 The right people with right skills are involved
 Project plan is realistic and quality checks in place
 Communications are adequate
 Business is ready and able to implement solution
Provide operational support & direction for the project
 Monitor progress vs. plan
 Be a point of escalation for issues
 Advise on risk mitigation
 Authorise changes to the project
 Communicate with governance bodies (Information
Systems Prioritisation Group) or IT equivalent
 Approve key milestones (e.g. go-live)



Maintain focus on project delivery : Solution good enough
but not over engineered
Communication with Governing Bodies / other steering
groups
The Senior User
Represent the views of the user community
Ensure that business personnel with the correct skills are
made available to the project at the right time
Quality assurance on behalf of the user community, i.e.
specifications are correct; plan is achievable; solution is
usable; benefits can be realised
Ensure user community risks are understood & mitigated
Resolution of escalated issues associated with the user
community
The Senior Supplier
Represent the views of supplier community (most of the
time ISS)
Ensure that supplier personnel with the correct skills are
made available to the project at the right time
Quality assurance on behalf of the supplier(s), e.g.
specifications are correct; plan is achievable; solution is
usable; benefits can be realised
Ensure supplier (community) risks are understood &
mitigated
Resolution of escalated issues associated with supplier
(community)
Alexander Rist
ISS Programme Manager
May 2011
Ensure the business case remains valid
 Benefits are achievable, quantifiable and documented
 Measures & timing of benefits realisation are
understood
 Costs are understood and realistic
 Any changes are fully assessed and don’t invalidate the
business case
 The project is stopped if the business case becomes
invalid
6.3




The Project Sponsor
Overall accountability for delivery of the project
Preparation of the project definition & business case
Appoint Project Delivery Group and ensure it fulfils its
remit
Chair Project Delivery Group meetings
Document1
Version: 14
Page 2 of 2