ABCD

KPMG IT Procedure
Systems Development Lifecycle (SDLC)

Revision History
Version Date
0.1
0.2
1.0

25/01/2016

Description

Author

Initial draft

Alistair Morgan

03/02/2016 Expanded methodology section

12/02/2016 Edits from review feedback

Alistair Morgan
Alistair Morgan

Table of Contents
Systems Development Lifecycle (SDLC)..................................................................................1
Revision History................................................................................................................... 1
1.

Overview.......................................................................................................................... 3

1.1

Purpose..................................................................................................................... 3

1.2

Background............................................................................................................... 3

ABCD

KPMG IT Procedure Systems Development Lifecycle

1.3

Executive Summary................................................................................................... 3

1.4

Scope........................................................................................................................ 3

1.5

Compliance, Enforcement and Exceptions.................................................................3

2.

Roles and Responsibilities................................................................................................ 4

2.1

NEC........................................................................................................................... 4

2.2

ITSC........................................................................................................................... 4

2.3

Product Owner........................................................................................................... 4

2.4

Senior User(s)............................................................................................................ 4

2.5

Senior Supplier(s)...................................................................................................... 4

2.6

Scrum Master............................................................................................................ 5

2.7

Project Assurance...................................................................................................... 5

2.8

Team Member............................................................................................................ 5

2.9

Key Users.................................................................................................................. 5

3.

Lifecycle Overview........................................................................................................... 6

3.1

Identify Need............................................................................................................. 6

3.2

Prioritise.................................................................................................................... 6

3.3

Project Initiation........................................................................................................ 7

3.4

Build.......................................................................................................................... 7

3.5

Pilot........................................................................................................................... 7

3.6

Deploy....................................................................................................................... 7

3.7

Post-Implementation................................................................................................. 7

3.8

Acceptance into Service............................................................................................ 7

4.

Methodology.................................................................................................................... 8

4.1

Scrum........................................................................................................................ 8

4.2

Governance............................................................................................................... 9

4.3

Key Documents....................................................................................................... 10

Document Sign-Of............................................................................................................. 10

1. Overview
1.1 Purpose
This document sets forth policy for the use of disciplined SDLC processes, practices, and
procedures for planning and managing IT systems being developed or improved by and for
KPMG NZ. This policy has been developed to assure that SDLC discipline is used across all

2 | Page

ABCD

KPMG IT Procedure Systems Development Lifecycle

KPMG projects that require implementation of IT solutions and/or changes to existing IT

solutions.

1.2 Background
The KPMG NZ Chief Information Officer (CIO) provides IT policy, planning, programming, and
budgeting guidelines for IT investments to ensure that quality, budget, security and timeline
objectives are met.

1.3 Executive Summary

All IT-related projects within KPMG NZ are implemented using the Scrum methodology, with
a Prince 2-style Project Board providing support for the Product Owner. Formal project
discipline commences from the start of the lifecycle and remains in place until the
deliverables have been transitioned into service. It is the role of the CIO to ensure that
projects are executed efficiency and efectively.

1.4 Scope
This policy applies to all KPMG projects that require implementation of IT solutions and/or
changes to existing IT solutions.

1.5 Compliance, Enforcement and Exceptions

The KPMG NZ CIO assumes the following responsibilities to assure the SDLC is wellgoverned:
1

Develops and issues SDLC policy and guidance to serve as the foundation for firm-wide
practices, processes, and governance;

Will typically fulfill the role of Senior Supplier and may participate in milestone reviews or
similar SDLC monitoring and control activities;

Monitors system lifecycle activities and progress through IT capital planning and
investment control processes.

Establish and maintain local SDLC processes, practices, standards, and governance
consistent with this SDLC policy with stakeholder participation;

Consistently apply the KPMG NZ SDLC processes and governance activities to IT project
development and system maintenance; and

Periodically report on SDLC activities, including advance notice of formal milestone

reviews or other similar control activities for major systems, to the NEC.

3 | Page

ABCD

KPMG IT Procedure Systems Development Lifecycle

2. Roles and Responsibilities

2.1 NEC
The National Executive Committee is responsible for reviewing the project Business Case,
and approving expenditure where this exceeds $25,000. In addition, projects with budgets
in excess of $2million require the approval of the Board. Once a project is underway, they
are kept informed of progress and act as the ultimate escalation point for critical project
issues.

2.2 ITSC
The IT Steering Committee is responsible for identifying opportunities for improvement
within their area of the business. Potential projects are reviewed by the ITSC and prioritised
in relation to other projects, resulting in a project roadmap, which is validated by the NEC.
The ITSC are also responsible for promoting new IT solutions.

2.3 Product Owner

Every project is assigned a single Product Owner. The Product Owner has ultimate
responsibility for the success of the project; that it delivers ROI, and that the demands of the
business, user and supplier are balanced. They will appoint people to the roles of Senior
User, Senior Supplier and Scrum Master, will chair project board meetings, and conduct
briefings throughout.
The Product Owner must have a clear vision for the final product and works with the project
team over the course of the project to deliver it by:
1
2
3
4

Developing and maintaining the Business Case and Project Initiation Document
Working with users/stakeholders to establish clear requirements
Maintaining the Product Backlog, ensuring that Backlog Items are prioritised and
sufficiently detailed
Attending planning meetings to answer questions from the Project Team

2.4 Senior User(s)

The Project Board contains one or more Senior Users. Each Senior User represents the
requirements of a group of users/stakeholders and is also responsible for identifying Key
Users and supplying testing resources from their area. Splitting the role between too many
people risks losing efectiveness, so this role should be limited to 2-3 people at most.

2.5 Senior Supplier(s)

The Project Board contains one or more Senior Suppliers. Each Senior Supplier represents
one or more of the parties responsible for the technical delivery of the project. There will
always be one Senior Supplier from KPMG IT, along with a Senior Supplier from any vendor
that has a significant responsibility for delivery.
4 | Page

ABCD

KPMG IT Procedure Systems Development Lifecycle

The Senior Supplier advises on the technicalities of the project; including method, design
and strategy. They are the product specialists - they approve the product descriptions and
represent those who are designing the product, developing it, operating and maintaining it.
The Senior Supplier has the authority to utilise any resource needed to achieve the final
product. They exercise quality control and must ensure that any operating standards are
defined and achieved. They will need to be able to brief other management staf on the
technical aspects of the projects.

2.6 Scrum Master

The Scrum Master is the owner of the processes used to deliver the project, ensuring that
the deliverables identified by the Product Owner are delivered efectively. Scrum Masters
should have completed a relevant certification. Their responsibilities include:
1
2
3

Facilitating key project team meetings; planning, daily scrums, and sprint retrospectives
Coaching team members on the values and practises of Scrum
Intervening whenever necessary to ensure that good practises are followed and that
project team members have sufficient time and resources to fulfil their responsibilities to
the project

2.7 Project Assurance

Project Board members are not a part of the project full time and so place a lot of reliance on
the Product Owner. They may assign Project Assurance functions to ensure that the project
is meeting its aims. Project Assurance is in place to give the board members confidence that
they are being given accurate reports on the progress of the project and the expected
quality of the output.

2.8 Team Member

Project Team Members are identified at the beginning of the project and a proportion of their
normal working hours is assigned to the project for its entire duration. Roles for each team
member (e.g. developer, business analyst) should be clearly defined, but there is an
expectation that team members will work outside their area of specialization from time to
time to ensure that work is delivered to agreed deadlines.

2.9 Key Users

Key Users should be identified during the Initiation Phase of the project. It is the job of the
Senior User(s) to identify Key Users and to ensure that they are suited to the role; cover a
good cross-section of user types; and have sufficient time to perform project activities. Key
Users perform the following activities within the project:
1
2
3

5 | Page

Provide input into requirements and solution design

Review and test functionality
Support deployment through assisting other users and championing the solution

ABCD

KPMG IT Procedure Systems Development Lifecycle

3. Lifecycle Overview

3.1 Identify Need

Requirement for a solution is identified and a Business Analyst from KPMG IT performs initial
analysis; working with the requestor to prepare a Business Case.

6 | Page

ABCD

KPMG IT Procedure Systems Development Lifecycle

3.2 Prioritise
Potential projects are reviewed by the IT Steering Committee and then assigned a window
within the IT Roadmap. The IT Roadmap is reviewed and validated by the NEC whenever
there are significant changes.

3.3 Project Initiation

A project is initiated once its allotted delivery window has arrived. Project Initiation is run
within a project discipline the project before the project. The following steps take place as
part of the Project Initiation Phase:
1 Form Project Board
2 Phase Planning
3 Select product(s)/vendor(s)
4 Security review of selected product(s)
5 Project Initiation Document completed and signed by Project Board and NEC

3.4 Build
The solution is developed iteratively with a Scrum framework. Initial focus is placed on
delivering a Minimum Viable Product with continuous input from Key Users throughout.

3.5 Pilot
The completed solution is piloted to ensure that it is fit for purpose prior to full scale
deployment. Solution development continues for the duration of the Pilot, driven by
feedback from the Pilot group. The pilot takes place within the production environment. The
NITSO must sign-of on security before a solution is moved into production.

3.6 Deploy
Upon successful completion of the Pilot, the solution is deployed across the remainder of the
user population.

3.7 Post-Implementation
The project team maintains primary accountability for the solution during the postimplementation phase. Issues and improvements are delivered within a Scrum framework.
A post-implementation review is conducted at the end of this phase. The requirement for a
further review of the solution at a later date may be identified as part of this process.

3.8 Acceptance into Service

The project is closed and the solution is handed over to operations. As part of the handover,
a formal Acceptance into Service document is completed and signed of by the Project
Board, Service Owner (this is the person within IT that is responsible for the service once
operational, including change control approval), NITSO, and Service Delivery Manager. In
addition, Service Level Agreements are created/reviewed and the Service Catalog is updated
accordingly.

7 | Page

ABCD

8 | Page

KPMG IT Procedure Systems Development Lifecycle

ABCD

KPMG IT Procedure Systems Development Lifecycle

4. Methodology
4.1 Scrum
Projects are delivered using the Scrum methodology. It is the primary responsibility of the
Scrum Master to ensure that the methodology is applied efectively across the lifecycle of
the project, escalating issues to the Project Board and/or CIO where necessary.
Full details of the Scrum methodology may be found elsewhere
(https://www.scrumalliance.org/); listed below are the core components:
1
2
3
4
5
6

Early and continuous engagement with key users of the solution

Feature-based product decomposition, with features delivered in order of importance
Frequent inspection of the product throughout the development lifecycle
Self-managing teams
Iterative solution development across 2-4 week Sprints
Daily scrum for the team to review progress and identify issues

9 | Page

ABCD

KPMG IT Procedure Systems Development Lifecycle

4.2 Governance
The role of the Project Board is to assist and support the Product Owner in the successful
delivery of the project. The Board is accountable to the NEC, who delegate the necessary
authority to deliver the project. The Board should meet periodically to review the health of
the project.

The Product Owner is responsible for distributing regular Project Highlight Reports to the
Project Board, NEC, and other interested parties.

10 | P a g e

KPMG IT Procedure Systems Development Lifecycle

ABCD
4.3 Key Documents

The following core documents are prepared and maintained over the course of the project:
1
2
3
4

Business Case
Project Initiation Document
Product Backlog
Acceptance into Service

These documents are owned by the Product Owner.

All other documents (Agenda, Minutes, Logs, Business Requirements Documents, etc.) are
considered non-core and fall outside this policy.

Document Sign-Of
Person

Role

Paul Herrod

CEO

Duncan Smith

COO

Alistair Morgan

CIO

Ross McKinley

NMP - Risk

Philip Whitmore

NITSO

11 | P a g e

Date

Signed