Accelerate
your project

February 2016

Material on this website is protected by copyright. Unless otherwise stated in relation to specific content, copyright in material on this website is owned by the Department of Internal Affairs on behalf of the Crown and is licensed for re-use under theCreative Commons Attribution 3.0 New Zealand licence. In essence, under this licence you are free to copy, distribute and adapt such content and material, as long as you attribute it to the Department of Internal Affairs and abide by the other licence terms. Please note that this licence does not apply to any logos, emblems and trade marks on the website or to the website’s design elements, which may not be re-used without express permission.Where applicable, this website identifies specific copyright content that is owned by a third party and/or is subject to any licence or other terms in addition to (or in place of) the Creative Commons Attribution 3.0 New Zealand licence referred to above. Your use of that content is subject to those terms.

Contents

Overview

Introduction

Accelerate phases

Which projects are good candidates for Accelerate?

How to use this toolkit

Key terms used in Accelerate

Tailoring Accelerate

Hot tips

Agile development processes

Phase 1. Prepare

Introduction to Prepare

Getting started

Unpack the problem or opportunity

Align with strategic priorities

Determine the benefits

Identify who is responsible

Outline the strategic response

Choose the path forward

Present the case

Preparing for Discover

Phase 2. Discover

Introduction to Discover

Explore the business ecosystem

Elaborate the customer view

Elaborate the product

Engage the coalition of the willing

Elaborate the solution architecture

Elaborate the business case

Gain project approval

Preparing for Alpha

Phase 3. Alpha

Introduction to Alpha

Preparing to sprint (sprint zero)

Product grooming

Release planning

Sprint

Business change management

Phase 4. Beta

Introduction to Beta

Releasing the product

Tracking the releases’ progress

Phase 5. Live

Introduction to Live

Customer acquisition

Benefits realisation

Enhancing the product platform

Phase 6. Grow

Page 1

Overview

Introduction

Important / Please read all of this overview, and then refer to the sections for each phase as required.
Intended audience / This toolkit has been created for:
  • managers wanting to invest in improving their service or business capability
  • managers and team members involved in an Accelerate project.

Contacts / r help or feedback.
What is Accelerate? / Accelerate is a scalable framework of tools bought together in a high-level process to support faster delivery of benefits, using a multi-function team from several disciplines, including policy, technology, development and assurance. It supports rapid design, prototyping, testing, and learning for improved citizen centred experiences.
Existing delegated authority, responsibilities and accountabilities continue to apply, including the Treasury investment management processes.
It incorporates proven techniques from a number of disciplines to support a project from the point when the opportunity is identified, through to maximising the benefitsof the completed working product.
Why use Accelerate? / Using Accelerate can help projects to:
  • define the opportunity and benefits
  • incorporate customer-centred service design
  • create a roadmap for evolving the product over time
  • ensure projects align with cross-agency strategic priorities
  • identify business benefits and appropriate business changes
  • makecross-agency collaboration and coordination easier
  • deliver the most valuable components to customers and investors earlier and in working form
  • identify opportunities for cross-agency common capabilities.

Accelerate can reduce delays / Accelerate includes the following processes, which can reduce delays:
  • establishing a multi-discipline team across policy, delivery, and technology
  • adopting a simplified governance environment
  • considering pre and post-delivery phases to optimise work flow
  • using agile techniques during development and release
  • coordinating the cross-agency release of integrated services.

Assurance / Accelerate projects need to follow the all-of-government assurance guidance provided on ICT projects and programmes available at (search for project assurance).
This guidance encourages tailoring assurance processes to match the risks and value of the project.
Risk management / The following features in Accelerate (including agile development) mitigate common risks associated with traditional project methodologies:
  • frequent engagement of customers during design and development
  • prioritization of high value work for early delivery
  • short inspect and adapt cycle
  • clear definitions of ‘done’
  • high engagement of the team with the business via the product owner
  • small frequent iterations
  • automated testing
  • test-driven design
  • explicit review and management of technical data
  • prototyping of solution components
  • cross functional teams - many perspectives
  • delivery of working systems.

What makes Accelerate different? / Accelerate uses approaches for managing projects that can deliver benefits safely and reduce delays.
Accelerate is flexible, and builds on the natural increase of information as a project progresses, so more decision making is based on real information, rather than on predictions. In this approach, changes are welcome.
This compares with traditional project management methods, where the details of a project are approved and locked in before the work begins, using assumptions which are based on the available information. In these methods, change is minimised and carefully managed.
Accelerate facilitates better financial control as it delivers the product in smaller and more frequent working releases, so the Project Board is able to reprioritise investment at the end of each release.
Background / For many years agencies have been providing public services and carrying out projects following well-understood methods, largely independent of each other.
Recently a number of new methods have become available that have been shown to improve how public services and projects can be delivered.
The Government has identified delivering better public services within tight financial constraintsas one of its top priorities. This and the Government’s ICT Strategy place new demands on Government agencies:
  • a focus on customer-centred services
  • greater collaboration between agencies
  • shorter time to realising benefits
  • investing in common ICT capabilities.
Research undertaken with project managers and sponsors indicates there is significant opportunity to improve the current project environment.
The GCIO’s team has developed Accelerate as an approach to organise and support projects delivering customer-centred services that are enabled by technology.
Accelerate’s phases / Acceleratehas six phases – Prepare, Discover, Alpha, Beta, Live, and Grow (see Accelerate phaseson page 10). These phases are divided intostages that describe the main tasks that need to be considered.

Figure1: Accelerate’s phases
This toolkit describes each phase including its:
  • stages
  • goals
  • possible techniques.
The techniques come from successful projects of varying size and complexity.
What is Accelerate based on? / Accelerate is based on the successful Government Service Design Manual (see
Their approach has been tailored to the New Zealand environment and includes:
  • proven customer service design techniques (NZ Government Service Design Guideline), architecture techniques (the Government Enterprise Architecture for New Zealand v3.0, GEA-NZ Data and Information Reference model and Taxonomy v3.0, TOGAF and ArchiMate®), and agile project delivery techniques.
  • benefits planning and change management to Discover, Alpha, and Live
  • the Grow phase, to support co-ordinated investment planning for cross-agency common capabilities.

Accelerate phases

Accelerate is made up of six phases, summarised below.
Prepare / The purpose of Prepare (page 27) is to:
  • clearly identify the problem or opportunity
  • engage stakeholders and align the project with their investment objectives
  • identifya sponsor for the change.

Discover / The purpose of Discover (page 44) is to:
  • identify the most valuable customer and stakeholder needs
  • explore the root causes, constraints and critical success factors
  • build a coalition of the willing to support the change
  • create the business case for the investment.

Alpha / The purpose of Alpha (page 62) is to:
  • build theproduct in increments, according to the product roadmapand the release plancreated during Discover.

Beta / The purpose of Beta (page 75) is to:
  • release the product to market
  • coordinatethe multi-agency release.

Live / The purpose of Live (page 80) is to:
  • add customers to the customer base
  • add capacity to the platform
  • monitor the performance of the product
  • start benefits realisation activities (benefits owner).

Grow / The purpose of Grow (page 85) is to:
  • progress the product capability based on customer feedback and continuous improvement processes.

Which projects are good candidates for Accelerate?

Deciding to use Accelerate / The sponsor (senior responsible officer), together with the GCIO’s team, chooses whether to apply Accelerate to projects that they consider have the required features and support.
The use of Accelerate is not mandated. The characteristics of projects that fit well with Accelerate are described below.
Accelerate projects / Accelerate is:
  • for projects (including projects that are part of programmes), rather than programmes
  • designed to support multiple agencies collaborating to achieve common customer service goals.

Potential Accelerate projects / A potential Accelerate project is one that will:
  • deliver benefits to customers (New Zealanders and/or the Government)
  • contribute to the Government’s strategic outcomes
  • have:
○buy-in from the participating agencies
○high technology reuse potential
○future value.
Accelerate is scalable, and can be used for a project with a single team of three people, up to cross-agency projects involving several teams.
Best use / Accelerate is best used when:
  • there is a clear customer service outcome which involves a technology change
  • there is uncertainty in the outcome, change in the details of the features is likely, and variability in the delivered scope can be tolerated – it is not suited to life or death issues, fixed-scope or fixed-price contracts, or whenscope variance cannot be tolerated
  • high levels of engagement with the business leaders can be sustained throughout the project.

Accelerate unsuitable for… / Accelerate is not for situations where:
  • the outcome is predominantly a technology change with low customer involvement
  • the initiative involves life or death issues, fixed-scope or fixed-price contracts, or when cost variance cannot be tolerated
  • the outcome requires a programme approach
  • the outcome is predominantly and organisational change or design.
Accelerate is not a substitute for Better Business Cases, or investment management processes such as risk profile assessment.

How to use this toolkit

Follow the phases, choose your tools / All the Accelerate phases and stages are considered in every project.
However, the effort and formality for each stage needs to reflect the project’s size, complexity and uncertainty.
Effective use of Accelerate relies on the sponsor and project manager using their judgement (with the assistance of an Accelerate navigator) to decide which tools will best benefit the project, and to what depth to complete the stages.
How to start / The Accelerate quick start guide supports project managers and sponsors getting a project underway as soon as possible. It is available on the Accelerate downloads page. This covers:
  • Starting (also in the Getting started section of Prepare)
  • Tailoring Accelerate (also in this overview)
  • Hot tips (also in this overview).
The quick start guide is intended to be used initially, and then once things are underway in Prepare, the project manager or sponsor needs to refer to the main guide to get more context and more detailed information about Prepare, and the other phases.
Most roles used during Accelerate are described in the glossary (available on the Accelerate downloads page). More detailed descriptions of the architecture owner, and product ownerare given inKey terms used in Accelerate on page 11, as they are likely to be less familiar in the Accelerate environment.

Key terms used in Accelerate

Some key terms used in Accelerate that may be less familiar to the sponsor and project manager that are explained below are:
  • architecture owner
  • architecture runway
  • product owner
  • project space.

Architecture owner

What is an architecture owner? / The architecture owner is:
  • part of the project’s core team
  • responsible for facilitating the development of the product’sarchitecture.

When is an architecture owner required? / Architecture owners are needed for complex or largesolutions, when the development teams are unable to anticipate the complexities outside their immediate environment, or understand every aspect of the entire system.
Assigning an architecture owner:
  • supports the ability to respond to changes to the solution as more information is available
  • reduces the production of redundant or conflicting features.

Architecture owner’s responsibilities / The Architecture Owner’s responsibilities are listed below.
Across project life:
  • understanding the IT strategy and standards
  • ensuring the solution is fit for purpose
  • understanding and applyingrequired information security controls to the solution
  • developingan architecture runway supporting the product roadmap
  • making scope vs quality trade-off decisions for the team
  • carrying outagreed assurance activities
  • supporting the sponsor to socialise and convey the project vision and intent to the team and primary stakeholders, along with the product owner
Continued…
Architecture owner’s responsibilities (continued) /
  • communicating the emerging solution design with technical review boards
  • contributing to the:
○assurance plan and risk register
○business operating model
○product release roadmap
○product release board(s)
  • understanding and applying enterprise technical standards
  • assessing changes to the scope for assurance implications, andrecording the decisions and their rationale in a project log
During development:
  • organising milestone reviews
  • participating in project planning, daily stand up meetings, reviews, retrospectives, sprint and release planning
  • providing input to the feature analysis and discussion during sprint planning
  • considering the readiness of the IT services to accept the change, prior to approving the release for Live, along with the product owner
  • reviewing test results prior to the approval of sprint deliverables with the product owner
  • providing input to the product owner when they are determining whether to approve the release of sprint deliverables
  • working closely with the change manager to ensure alignment of release and change management activity
  • liaising with the IT owner regardingthe release’s IT change management
  • reviewing issues raised in testing during Alpha and Beta,and ensuring suitable remediation plans are established, with the product owner.

Architecture documentation requirements during development (Alpha and Beta) / In Accelerate, the architecture is developed in iterations that are presented to stakeholders. These descriptionsof the solution are intended to:
  • align designs across teams
  • synchronize iterations between teams
  • communicatethe descriptionof the solution to support teams (for example, security, technical operations, quality,assurance, or privacy).
In an agile environment, the suitable level of architecture documentation is the minimum amount necessary for current discussions with the intended audience. A critical part of this is provided by the architecture runway (see below).
Principles for architecture owner / Principles that guide the architecture owner include:
  1. Collaboration – the architecture owner works collaboratively with the team to develop and evolve the architecture, benefiting from inclusion of a range of viewpoints.
  2. Empowering the team –70% of skills development occurs on the job, so architecture owners and other team members with more skills and experienceshare their skills.
  3. Reducing complexity and uncertainty – thearchitecture owner identifies areas of technical complexity in the architecture, and addresses them. This may involve setting up an architectural prototype.
  4. Communication– the architecture owner communicatesdecisions and guidelines (including coding standards, database, security, and control objectives) to the team. They also communicate the description of the solution tostakeholders as part of reviews.
  5. Ensuring the solution’s integrity – the architecture owner reviews the product backlog and the completed product increments to ensure the integrity of the product and the overall system.

Architectural runway

Architectural runway / An architectural runway:
  • is the responsibility of the architecture owner
  • is a forward-looking view of the product’s architecture, the capabilities it needs, and the product increments that will provide them
  • plans capabilities just in time for uninterrupted deployment of new business features to customers
  • is recommended for managing technical complexity in agile projects.

Architectural runway and the product roadmap / The architecture runway aligns with the product roadmap created by the product owner. It considers the changes in IT components needed to realise the customer benefits and creates a plan to deliver them. The architecture runway forms the “bottom half” of the product roadmap as it describes the changes needed to provide the customer benefits described in the top half. A draft example from the BABII project is available on the Accelerate downloads page.

Product owner

The product owner is:
  • a member of the ‘core team’,along with the project manager, and architecture owner (and scrum master during development)
  • thestakeholders’ representative on the team, and vice versa
  • thevoice of the customer
  • accountable for ensuring that the team delivers value to the business and the customer.

Communication and the product owner / Communication is a main function of the product owner, and the engagement of the product owner with the development team and stakeholders is extensive.
The communication tasks of the product owner to the stakeholders include:
  • communicatingbetween the team and stakeholders
  • demonstrating the solution to key stakeholders
  • announcing releases
  • communicating team status
  • organising milestone reviews
  • educating stakeholders in the development process
  • negotiating priorities, scope, funding, and schedules
  • communicating the product vision, strategy, roadmap, and releases to relevant parties.

Key relationships / The product owner’s key relationships are:
  • internally:
○architecture owner
○business owner
○business representatives
○benefits owner
○business analysts
○project managers
○lead solution analysts
○architects
○testing
  • externally:
○external service providers
○provider, vendor representatives
○other government agencies.
General responsibilities / The product owner’s general responsibilities include:
  • ensuringthe solution provided is fit for purpose for the business
  • carrying out agreed assurance activities
  • prioritisingfeatures and user stories
  • makingscope versus quality trade-off decisions for the team with the architecture owner
  • liaising with the benefits ownerregarding change management and benefits management
  • developing the product vision and strategy
  • co-authoring the business operating model with the sponsor and the stakeholders
  • workingwith the sponsor to define the business acceptance criteria
  • workingwith the change manager and architecture owner to ensure alignment of release and change management activity
  • contributing to and approving the product roadmap and product release board(s)
  • ensuring the product backlog is visible, transparent, and clear.

Development responsibilities / The product owner’s responsibilities during development (Alpha and Beta) include:
  • reviewingtest results prior to the approval of sprint deliverables,with the architecture owner
  • reviewingissues raised in testing during Alpha and Betaand ensuring suitable remediation plans are established for risk accepted issues, with the architecture owner
  • participating in daily stand up meetings, reviews, retrospectives, sprint and release planning
  • provide input to the feature analysis and discussion with the team during sprint planning
  • approvingthe sprint deliverables at the sprint review meeting with input from the architecture owner
  • refining the product backlog.

Project space

A project space is a dedicated physical area for:
  • some or all of the team to work in
  • organising and displaying project materials
  • team meetings.
The main benefits of a project space are that it:
  • enables the team to collaborate and communicate more effectively and efficiently
  • allows project information to be displayed visually helping with processing, organising and communicating information.
The importance of co-location is discussed in the Hot tips section on page 23.

TailoringAccelerate

Follow the phases, choose your tools / All the Accelerate phases and stages are considered in every project.
However, the effort and formality for each stage needs to reflect the project’s size, complexity and uncertainty.
Effective use of Accelerate relies on the sponsor and project manager using their judgement to decide which tools will best benefit the project, and to what depth to complete the stages.
Goal of tailoring Accelerate / The goal of tailoring Accelerate is to apply a level of project management and control that:
  • does not overburden the project, and
  • provides an appropriate level of oversight given the risk, complexity and significance of the project.

Using navigators / The GCIO’s team can identifyAccelerate coachesand navigators who can help you choose the best path forward.
After you read through this section, contact the GCIO’steam at to locate a navigator or an Accelerate coach.
How to tailor Accelerate / The first step for the project manager or sponsor when tailoring the approach is to determine the complexity of the problem, the certainty of the outcome and approach, and the possible impact of the project. They need to consider:
  • achieving things is straightforward when they are well understood – even if they are complex
  • even straightforward things can be a challenge - if you’re unsure what to do next
  • when the impact is high it is wise to take extra care – even when you know what to do.
Possible factors to consider are given in Table 1.

Table 1: Factors to consider when tailoring Accelerate