The Transformation’s scope was delivered using a product-based strategy requiring business functions, processes and technology to be safely transitioned, product by product, to the new application platform (START).
In preparation for the major START releases we were required to complete a product strategy and a roadmap for each of the products being transitioned into START. Product strategies provide a view of the vision and desired outcomes for that product, for example student loans or payday filing, while the product roadmap captures the delivery of new, continuing and emerging requirements including policy and delivering legislation.
The product strategy was viewed alongside:
- Business profiles, to provide a view of the current state.
- The business solution blueprints (see high level design), to provide a view of the future state.
- Cost to benefit analysis, providing a Must do/Should do/Could do view of scope.
Collectively these documents helped us decide our baseline scope.
The design phase for each Release was split into 2:
- High-level design.
- Detailed design.
High-level design is the start point. Through each subsequent part of the process, each design was validated and updated until we had developed a detailed design for that release of work.
Product designs (target business profiles) were developed at each release, to provide a point-in-time release specific view of the current state.
The design captured the current issues and business pain points and identified opportunities we could bring into our future design.
Product designs are used to develop the solution designs or Business Function Definitions (BFDs).
Business Function Definitions are detailed release specific solution requirements mapped to level 3 processes and contain:
- Business rules
- Coexistence approach
- Customer impact
- Channel impact
- Key business process considerations
- Organisation impact
- Technical integration
- Detail around how it will operate, for example who will use it, metrics and reports, content and correspondence
Completing the Business Function Definitions at each release was always a big milestone as they inform other important plans and artefacts which support delivery, such as test scenarios and change plans.
One of the most important ways we applied what we learned was through a change in approach to Customer and Digital Design (CX, DX)
- We designed an integrated end-to-end customer and digital experience across all channels to compliment the technical implementation methodology. Inland revenue’s Channel Strategy and Customer Blueprint were key inputs.
- We considered customers’ preferred channels and contact points. Customer research, journey maps and voice of the customer reports helped us identify preferred inbound and outbound contact points.
- For specific processes, we tested the design through demonstrations with selected customer groups and with internal teams.
Bringing the right people into the design process was a significant lesson learnt after Stage 1 of the transformation –for both customers and our front-line staff.
From release 2 to Stage 4, 60 front-line staff from across the organisation came together to help us understand if what we had designed would work for customers and our people in future and were there any gaps or things to consider.
Over a 3-day workshop, attendees participated in deep dives by product or process area, during which they received an overview of the technical designs, a walk-through of the associated business process and were given the opportunity to gain hands-on experience in START, the new platform.
These events were helpful to the programme team and very well received by attendees. It created advocates for the new system who then went back into the business, and we identified potential testers, trainers and change champions to bring into the programme at later stages of the release.
Change is inevitable during the lifetime of a programme, and it is important that there is a well understood, consistent approach to recording, assessing and approving change.
We had a very robust change control process which was there to confirm that where change was required, it was agreed to by the relevant authority before it was executed.
In all cases, the impact of the change had to be considered against a baseline (what had been previously agreed), covering schedule, scope, business benefit, resource, and financial impact.
Programme change requests (PCRs) were managed by our Project Management Office using issue and project tracking software, (JIRA). The team monitored quality, ensured consistency, reported change status to governance forums, managed physical documents and ran the approvals process using an agreed delegation framework.
A Programme change request which involved a design change, required approval by the Design Authority to ensure it would still deliver the agreed design outcomes.
The accountability for change lay with the person who knew most about it. Throughout the change request process, the change owner was responsible for:
- drafting the programme change request
- co-ordinating the impact assessment (including impact on costs, benefits, and risks)
- coordinating mandatory consultation with all relevant parties, such as Programme Leadership Team members, implementation or delivery partners, and the Finance Manager
- liaising with the Contract Manager if any impacts on third party Statements of Work were identified
- presenting the programme change request
- completing any necessary activities to action the change.
We learnt a lot, particularly after our first release. This helped us make changes to optimise solution delivery and improve outcomes for our people and our customers. These included:
- involving customers early in the design process
- ensuring the design of each release set us up to deliver transformational outcomes and benefits as we’d set out in the Business Blueprints and Product Designs
- getting the right people involved in design decision making at the right time
- having a mechanism and process in place to capture design decisions and escalate promptly at the right time based on risk.