Appendix One Grants Management System Business Case.pdf

BUSINESS CASE

1982

Act

Grants Management System
March 2023
s9(2)(a)

Information

Official

the

under

Released
For use with projects >$300K or if financial approver requests it. This is a template. Please
download and save to your document library.

Distribution List
This following parties have received and contributed to the development of this document:
Role
Name
Date sent
Chief Financial Officer
s9(2)(a)
31 March
Chief Technology Officer
s9(2)(a)
31 March
Director Digital Product
s9(2)(a)
31 March
Director International Growth
s9(2)(a)
31 March
Fund
Chief Data and Analytics
s9(2)(a)
31 March
Officer
Korako Project Lead
s9(2)(a)
31 March
Version History
Changes made to finalise this document.
Version
Date
Author
Summary of changes
0.1
20/01/23
s9(2)(a)
Initial draft
0.2
17/03/2023  s9(2)(a)
Review with Governance
0.3
31/03/2023  s9(2)(a)
Updated with supplier information
0.4
12/04/2023  s9(2)(a)
Updated following review by finance and data
governance
Approval
I approve this Business Case to release OPEX funding of $650,000 of known costs and ring-
fencing of additional 25% contingency ($162,000), totalling $812,000.
Role
Name
Signature
Date
Chief Executive
Peter Chrisp
under the Official Information Act 1982
Released
[Date]
2

Contents
Distribution List ............................................................................................................................... 2
Version History ................................................................................................................................ 2
Approval .......................................................................................................................................... 2
Purpose ........................................................................................................................................... 4
Executive Summary ........................................................................................................................ 4
1982
Proposal .......................................................................................................................................... 4
NZTE Strategy ................................................................................................................................ 5
Act
Solution Options .............................................................................................................................. 5
Cost of Ownership .......................................................................................................................... 9
Deliverables .................................................................................................................................. 10
Benefits ......................................................................................................................................... 11
Timeline ......................................................................................................................................... 13
Financial Breakdown..................................................................................................................... 14
Risks.............................................................................................................................................. 16
Governance................................................................................................................................... 17
Information
Delivery Team ............................................................................................................................... 17
Appendix 1 – Assessment Criteria ............................................................................................... 19
Appendix 2: Background and assessment of Claims risk model ................................................. 19

Official
the
under
Released
[Date]
3

Purpose
The purpose of this business case is to seek approval for OPEX funding of $650,000 of known
costs and ring-fencing of additional 25% contingency ($162,000), totalling $812,000, to replace
the existing custom-built grants management application (Tipu) with a Software as a Service
grants management application. This will provide fit-for-purpose technology for the International
Growth Fund.
Executive Summary
1982
●  The International Growth Fund experience has been a pain point for the Export
Customer Team, customers and the IGF Team. The Smarter Working squad recently
undertook a Discovery piece on what the ideal IGF Experience could look like, from
Act
customer application all the way through to closure and reporting and developed a
roadmap to set out the direction for this goal.
●  As part of this exercise, s9(2)(b)(ii)
were engaged to undertake an
assessment of our current technology and look at our options to provide the best value
to the IGF experience against our key assessment criteria (Appendix A). This includes
an assessment of our current solution (Tipu).
●  Based on the evaluation and estimated costs, a SaaS product was recommended to
deliver the best value for NZTE against the current and future backlog requirements for
the International Growth Fund and customer experience, and supercharge our people
through smarter working.
Information
●  A SaaS product is also the best fit for our digital transformation, digital and IGF
strategies to enable us to adapt and scale.
●  Following Requests for Proposals and demonstrations from the 3 shortlisted candidates,
NZTE has selected Enquire by Tactiv as the best-fit technology and the preferred
candidate.
Official
●  This business case proposes to retire Tipu and the Risk model and replace them with
Enquire, which will cost significantly less (savings of $73,000 per month) to maintain and
support, as well as a best-in-breed user experience. There are additional benefits in
other areas including data, speed of delivery, improved collaboration and transparency
the
for customers and our people.

Proposal

under
NZTE needs a grants management system to underpin the end-to-end grants management
process and achieve a beautiful, scalable experience for customers.
●  The existing core grants management system, Tipu, has been constantly refined over
the years to meet the requirements of stakeholders, and doesn’t meet the expectations
of users. The current solution would require a significant rebuild to meet the Ideal IGF
Experience, against what is already significant spend to meet the demands of a
constantly evolving experience.
●
Released
  In addition, the risk model application supported by s9(2)(b)(ii)
does not return the
investment, and there is an additional opportunity to replace the Risk model and use the
highly configurable rules engine provided by the SaaS candidate to reduce IGF workload
and automate some of the claims processes.
[Date]
4

●  In addition to these problems to solve, there is the opportunity to enable a more
omnichannel experience and improve customer transparency by enabling the external
portals provided.

NZTE Strategy
Replacing the existing custom-built solution with a SaaS solution will help achieve the Digital  1982
Transformation strategy through the following outputs:
•  Smarter Working: Supercharge automation, scale and adaptability in the IGF space by
automating low-risk payments and applications.
Act

•  Supercharge speed and quality of delivery: Deliver an excellent user experience for
our people and customers working with the IGF by
o  Being able to deliver at pace using configuration instead of coding to swiftly
respond to changing business needs
o  Better transparency and collaboration.

•  Optimise our direct-to-customer digital channels: Integrating the SaaS solution with
our external portal to allow customers to make applications and claims directly without
our people being a middle man, if certain criteria are met.

Information
•  Buy over build, configure over customise: be efficient and design for scale. Our
Digital Strategy looks to use commercial off the shelf products where possible and flex
our processes by configuring solutions rather than costly customisation.

Solution Options
Official

Option 1: RECOMMENDED: Replace Tipu and claims risk model with Software as a
Service application
the
Rather than continuing with custom-built solutions, NZTE could implement an application that is
already built specifically for grants management. There are a number of options on the market
and these are being used for Grants Management by many other organisations, including NZ
Govt Departments like MFAT and DOC.
See appendix 2 for further information on the risk model background.
under

PROs
•  Cost-effective and low total cost of ownership
NZTE will no longer need to invest in costly development to maintain, enhance and support the
needs of the International Growth Fund.
•  Flexibility to scale and adapt to organisational needs.
SaaS products are designed to easily scale and configure. If a new fund is needed this would
be operational in days rather than weeks/months, and new notifications can be actioned in
Released
minutes by business administrators, reducing blockers.
•  Best fit with current and future IGF requirements
[Date]
5

The SaaS product already supports our future requirements so we will achieve our goals much
faster, at our desired change pace.
•  Support and maintenance is vendor responsibility
Security and regulatory requirements and updates are handled by the vendor – we can focus
on delivering a great experience.
Reduced IT operations maintain and support footprint.
•  Quickest time-to-value
Once the system is in, we can take advantage of all the features and our internal staff have
1982
more ability to unlock value for smaller areas.
•  Benefit from improvements to SaaS product without needing to pay more.
Improvements will continue to be made to the experience by the vendor, but our costs to use it
remain the same.
Act

CONs
•  Will not own the IP (this is almost a pro)
While we won’t own the IP of the system, we will still own the IP of the process and how it is
implemented.
•  Any functional changes not on the roadmap will need to be negotiated with the vendor,
and would be out of our control.

Information

Option 2: Rebuild Tipu to meet expectations
In order to achieve our ideal IGF experience, we could rebuild Tipu and invest in ongoing
development to meet our business needs and strategic goals.
PROs
Official
•  Users familiar with application
There is less of a change and learning curve as we would be evolving the existing stack
•  Limitations well understood
•
the

We can build to our existing processes.
Updates can be made as and when needed, according to prioritisation. Note these still cost $$.

CONs
•  Complex solution not well-architected, would need significant reinvestment.
under
•  Difficult to maintain and add additional functionality,
Any changes are slow as need to be built and tested.
•  Lack of API support and difficult to integrate with other applications
Built using a known code framework Ruby, this is a language none of the Dev team in NZTE
have skills in.
•  Vendor and technology risks
•  High cost involved and slow time to value with a risk of same mistakes being made
again.

Released

[Date]
6

Option 3: Leverage the Dynamics platform
Microsoft Dynamics 365 provides capabilities that can be used to implement a grants
management system.
PROs
1982
●  Dynamics CRM already a strategic platform within NZTE
●  Flexibility of the configuration platform means we can build what we need.
Act
●  Dynamics 365 provides excellent workflow capabilities
●  Integrates well with other Microsoft products used within NZTE
●  Good API support

CONs
●  Greenfields platform requires development and configuration
●  High cost of ownership
●  Long time-to-value
Information
●  Requires additional licensing
●  Dynamics user interface not popular with NZTE people
●  Unlikely to empower IGF team to be able to tweak the flows as required without digital support.
●  No external portal - would need to develop myNZTE further to enable future roadmap.

Official

the
Option 4: Do nothing

PROs
•  Known entity, users will settle into familiar process.
under

CONs
•  Will not meet Ideal IGF Experience
•  Poor fit with strategic direction
•  Existing pain points will continue to be felt due to fundamental issues with existing technology
•  High cost to NZTE
$300k a year just to maintain with no enhancements.
•  Clunky experience for our people and customers will continue.
•
Released

Technology and Support risk will remain

[Date]
7

Additional consideration: Callaghan Innovation
s9(2)(g)(i)

1982

Act

Information
Official
the
under
Released
[Date]
8

Cost of Ownership
Option 1 is recommended after looking at the total cost of ownership of each option across a 5
year timeframe. Note that Option 4: do nothing means support, bug fixes and necessary
upgrades only. It assumes no improvements or changes at all.
s9(2)(b)(ii), s9(2)(g)(i)1982
Act
Information
Official

•
the
Indicative high-level costings based on as estimate of what would be required for each option

under
Released
[Date]
9

Deliverables
At the end of the project, NZTE will have a SaaS grants management system integrated with its
current applications, the risk model will be retired, and there will be a plan in place and agreed
for the retirement of Tipu.

In scope
Out of scope
1982
Identified and accepted future state end to
Process changes that materially impact
end process first version for current IGF fund
timeline and cost
types.
Act
Main integrations with existing technology

stack in IGF process
Reporting

End user training

Training materials and documentation
Strategic Investment Fund

Resource plan and costs for retirement of
Retire Tipu (likely to be a handover /cross
Tipu.
over point that needs to be analysed as part
Information
of proposed migration approach)
Data cleansing and migration of data to new

system

Identification and plan for clean-up of existing
code in integrated applications
Official

Claims via external portal

the
Retire Risk model

under
Released
[Date]
10

Benefits

Benefit
Quantification
Timeframe benefit
Benefit owner
will be realised
See below example:
Reduce vendor spend on
$10k per month
Benefit will begin in
Chief Digital Officer
1982
reporting
September 2021
Experience benefits – happier people and customers
Increase NZTE
Joyous survey–
July 2024
GM CSG
Act
people and
Average rating of 7 or
customer’s
higher in response to
satisfaction with IGF
the question: I am
technology and
confident in the
process
technology and
process to complete

an IGF with my
customer.
Our Voice survey
Minimal (few)
Information
negative comments
regarding IGF.
Increase in positive
comments regarding
IGF process and
tools.
NPS Survey  Official
Collect ratings from
internal and external
audiences on their
the
experience. NPS will
be done before
application
completed so it
doesn’t get biased by
outcome ideally. Tool
under
will fit with myNZTE
experience. Rough
goal of +30, collect
data and then
baseline after 3
months.
Faster customer
Current SLO is 20
June 2024
GM CSG
payment of claims
days is 80% from
received to approved.
Released
[Date]
11

Aim to increase to
90% of received from
approved.

Cost benefits – savings of $73,000 per month on vendor spend.
Reduce vendor
60k
November 2022
Chief Technology
1982
spend on
Officer

development
Reduce vendor
6k per month
From Tipu retirement
Chief Technology
Act
spend on
Officer
maintenance
Reduce vendor
2k per month
From Tipu retirement
Chief Technology
spend on hosting
Officer
Reduce vendor
s9(2)(b)(ii)
5k per  From risk model
Chief Technology
spend for risk model
month
retirement
Officer

Efficiency benefits – save time for our people by reducing tickets and emails
Reduce support
Currently 40 tickets
Feb 2024
Chief Technology
Information
tickets + time for all
per month, reduce to
Officer
staff
10 tickets per month
after transition has
been completed.
Time saved = 600
mins per month for it
ops (average 15 mins
Official
per ticket)
Increase number of
20% auto-approval
From implementation
GM CSG
automated
rate in first calendar
the
approvals to pay
year from
claims
implementation.
Increase %

automated annually
for claims less than
$50,000.
under
Reduction in staff
Reduction in admin
Unknown
GM CSG
through natural
tasks related to IGF
attrition.
means a future
coordinator role is
unlikely to be
required. Reduction
in headcount of 1.0
through natural
Released  attrition. Any fund
decrease in size
(from $60m to $30m)
will reduce the
[Date]
12

number of advisors
and reallocation of
resources as well.

Timeline
1982

The project is expected to take 6 months depending on final set of requirements, with an
additional two months for contingency and early life support. The project is expected to start in
Act
May and complete over a six to nine month timeframe.
Tactiv’s implementation methodology enables business processes to be delivered iteratively.
The proposed implementation would start with the Expansion grants, while NZTE has the full
support of Tactic. Following this, NZTE leads the Validation implementation with Enquire’s
support, and then self-configures the remaining 3 fund types.

Month 1
Month 2
Month 3
Month 4
Month 5
Month 6
Initiate, Design,
Configuration &
Configuration
promotion to
Training & Go
Supported self
Information
Implement, Test,  testing (Fund 1)
testing (fund 1)
Production
Live Supported
configuration
Deploy Enquire,
(Fund 1)
self
rollout (Fund 3,
Workshops &
configuration
4, 5 +)
configuration
Self-
rollout (Fund 3,
configuration
(Fund 1)
4, 5 +
training &
supported
configuration /
joint testing
Official
(Fund 2

the

under
Released
[Date]
13

Financial Breakdown

This Business Case seeks approval to seek approval for OPEX funding of $650,000 of known
costs and ring-fencing of additional 25% contingency ($162,000), totalling $812,000. System
implementation projects come with a number of assumptions and unknown unknowns that only 1982
become clear once we delve into the detail. This often results in overruns of time and cost as
the project progresses.
Act

Role
PM
BA
External
s9(2)(b)(ii)
Architect

Total

IGF SME
Dev
Information
Digital Analyst
Change/Comms
Systems Engineer
Internal
Training
Product Manager
Official
Data Analyst
Data Engineer
the
Tester
Total

Other
Vendor cost
Total Other

$350,000
Total

$649,201
under
Contingency
= 25%

$162,300

1. Feasibility (Opex)
Released
Cost Type
Detail
Cost (NZD)
Already sunk

[Date]
14

2.
Vendor Costs
Cost Type
Detail
Cost (NZD)
Implementation fixed  – as per statement of work
$186,000
fee
s9(2)(b)(ii)1982
Act
Cyma Architecture
Statement of Work for detailed system design
$35,200
estimate
only
3.
Project Team
Cost Type
Detail
Cost (NZD)
Information
Personnel
1 x IGF SME for 9 months
1 x developer for 5 months
1.0  x digital analyst for 3 months as part of project dropping to
0.5 support opex after
1 x change and comms
Official
1.0 data person (reporting and potential impacts, does it need
re-doing dashboards, data quality assessment, ETL)
0.2 x Systems Engineer for 3 months s9(2)(b)(ii)

the
0.1 Tech Lead for 6 months + 0.2 Soln Architect s9(2)(b)(ii)
Training Lead – 0.5 for 3 months and 1.0 for a month at go-live.
0.2 Dynamics Configuration s9(2)(b)(ii)  CRM)
s9(2)(b)(ii)
under
4.
Post implementation and ongoing cost (Opex)
Cost Type
Detail
Cost (NZD)
Personnel
Half an internal SaaS specialist / Digital Analyst to support
$60,000
ongoing changes and triage
$60,000
Released  Half a support engineer for 6 months post implementation
support
Contractor
[Date]
15

s9(2)(b)(ii)

Risks

1982
Risk Description
Risk level
Mitigation
Owner
(High/Medium/ Low)
If…then

Act
Changes to IGF
High
Agree scope before
s9(2)(a)
process during
project starts at
project impacts
Governance, any
system delivery and
changes to scope
blows out timeline
and additional
timeframes need to
be signed off by
Governance. Few
and low effort scope
changes can be
Information
signed off by
programme manager.
Delayed start and
High
Continual evaluation
s9(2)(a)

delivery delays
of progress to plan
means project will be
and early warning of
due to land right
potential overruns.
before Christmas
Official
Iterative delivery to
when appetite for
minimise impacts
change is very low,
closer to Xmas.
delaying until
the
February.
Risk that wider
Very High
Any
s9(2)(a)
consultation with
recommendations
other stakeholders
from process
(outside the project)
improvement
is needed to make
consultation that
under
key decisions.
require consultation
Project gets stalled
will not be
by indecision.
implemented as part
of the project, but fall
to a later
enhancement phase.
Change Fatigue for
High
Make it amazing -drip  s9(2)(a)
the organisation – too
feed awesomeness
Released
much change
so people are
happening from other
begging to use it.
projects
[Date]
16

Timing of delivery,
open channels of
communication in
change team and
projects.
Competing priorities
High
Ring fence key
Governance
(due to volume of
resource.
1982
change) causes
conflicts in resource
allocation to the
project.
Act
Governance
Project Role
RASCI
Name
Position
Business Sponsor
A
s9(2)(a)

GM Customer Solutions
Governance support
S
s9(2)(a)

Director, Digital Product
Business Owner
R
s9(2)(a)

Director, IGF
Information
System Owner
S
s9(2)(a)

Chief Technology Officer
Governance support
S
s9(2)(a)

Head of Manufacturing,
ECT
Governance support
S
s9(2)(a)

Regional Director,
AUSPAC, International
Official
Delivery Team
the
List the team member who are responsible for delivering the project products/deliverables.
Resource
Area of Responsibility
s9(2)(a)

Project Lead
s9(2)(a)

Change Manager
under
s9(2)(a)

IGF Lead (SME)
s9(2)(a)

Business Analyst
TBC
Digital Analyst
TBC
Data Analyst
TBC
Test Engineer
s9(2)(a)

Support Engineer
Released
TBC
Training Lead
s9(2)(a)

International team rep
[Date]
17

s9(2)(a)

Customer team rep

1982
Act
Information
Official
the
under
Released
[Date]
18

Appendix 1 – Assessment Criteria

Assessment
Current
myNZTE + SaaS
myNZTE + Workfl
myNZTE +
Criteria
+ CRM
ow Tool + CRM
Dynamics
MyNZTE +
+ CRM
Tipu + CRM
1982
E2E User
Issues
Good
Good
Good
Experience
(customer/inter
nal staff)
Act
Support Costs
High
Low
Medium
Medium
Enables future
Dev Required
Some Supported
Dev required
Dev required
business
requirements
(run)
Scalability
Low
High
Medium
Medium
Information
Smarter
Low
High
High
High
Working
(Automation)
Integration with
Low
High
High
High
Official
API Support
Time to Value
Medium
Low
High
High
the
Reputational /
High
Low
Low
Low
support /
technical risk under
Data Mgmt /
Insufficient
Quality
Quality
Quality
Reporting /
Auditability
OVERALL
Avoid
Evaluate
Partial
Partial
Released

Appendix 2: Background and assessment of Claims risk model

[Date]
19

The Claims risk model was initially developed because Tipu could not risk assess and was set
up as an additional integration. It was cheaper to do as a standalone rather than develop Tipu
further.
It’s purpose was to reduce workload by providing risk assessments of incoming claims based on
scores provided from data.
This goal has not been realised because of low trust and understanding in the model, and a
fundamental flaw in the model trying to hit thresholds rather than assessing based on risk
1982
business rules. In addition, the latest report from KPMG to assess the risk model effectiveness
was rated “Not Effective” “The Model was developed to improve the efficiency of IGF
assessment process while managing overall risks from the applications. The Model calculates
risk scores of applications and applications with risk scores above the guideline are reviewed
Act
manually. However, there is no clear link or analysis on the risk scores and probability of failure,
which make it hard to justify the process of setting a risk score guideline for manual review.”
The SaaS product has business rules configuration engines that achieve the same intended
outcome as well, so by continuing with the risk model we would be paying very similar
functionality twice.
Using the SaaS model moves to a more binary yes/no decision-making model for clear
outcomes and decision making based on the risk in each claim.

Information

Official
the
under
Released
[Date]
20