| 4. In which ways is the initiative creative and innovative?
|
|
Elements of the action plan
To start, we looked at what other governments were doing online. We found good ideas but didn’t know what would work in New Zealand, so we asked people what they thought. We ran focus groups and user testing to find out how people wanted government information online.
In order to develop the site, the GIS team at Internal Affairs proposed taking a phased approach and to work in an iterative manner. For our approach we decided to:
1. Base decisions on user needs
2. Build an evidence base
3. Start small and iterate.
We started with an alpha site. This was a wire-frame with basic content that we could test with users to see if our ideas worked. Then we launched our beta site, beta.govt.nz, which was used to gather feedback and additional testing.
Content was grouped in information hubs with labels like ‘driving and transport’ and ‘travel and immigration’. Nothing was grouped by agency; it’s not how the user thinks. The content was based around common tasks which link out to government sites. Agencies fact checked the content before the site went live.
Main activities/chronology
March 2013
Alpha website
GIS built an 'alpha' site in order to test information design concepts and content models. The alpha site was a limited release site, and it was used as an early prototype. It enabled DIA to demonstrate and test early concepts with other government agencies and user groups.
August 2013 – May 2014
Beta website – actively tested and iterated
A beta website was launched in August 2013 and tested and refined during this period. This was a publicly available website which allowed users to provide feedback, report problems and contribute to improvements.
The site was used as a basis for formal user testing, and feedback from testing and the public was folded into the iterative design process. It delivered Govt.nz as an improved website based on user feedback and provided complete, fact-check content that was supported and managed by the project team. The website provided ‘thin content’ that provides summary information and links out to agency sites. The ‘thin content’ provides broad context for the information and links out to existing websites. It is more extensive than the ‘links farm’ content that was available on newzealand.govt.nz and it is accessed through improved information architecture. For example, if the user is looking for information on what they have to do when they have a baby, the ‘thin content’ provides a summary of the things the user must do, and then provides links to where they can do those things.
29 July 2014
Live website – www.govt.nz
Govt.nz officially went live. This phase provides an online all-of-government presence for citizen-focussed content with an operating model for ongoing development. The Govt.nz website provides context to inform the users’ journey that may require them to interact with multiple agencies.
The processes enable the creation and maintenance of ‘thick content’ in addition to the current ‘thin content’ as part of business as usual. It replaces the government-focussed and often duplicated content spread across many agencies. It also allows agencies to work collaboratively on shared content on Govt.nz.
Since the launch, the focus is on continual improvement of the Govt.nz product from a content enrichment perspective to making the product easier for users to find information and eventually to gain a much more visible online presence.
|
|
| 5. Who implemented the initiative and what is the size of the population affected by this initiative?
|
|
The Digital Engagement team led this development project. The team sit within GIS at the Department of Internal Affairs and includes specialists in government online delivery.
Key civil servants on the project include Digital Engagement Manager Laura Sommer, Product Owner Jared Gulian, Information Architect Nathan Wall, content designers including Victoria Wray, Gail Connelly and Katie Johnston. We also had secondees from the Ministry for Social Development and Developers, Business Analysts and Project Management resources from DIA’s Technology Services Group including Karen Hansen, Nicola Duncan and James Goodman.
The support and advocacy of DIA’s Chief Executive, Colin MacDonald, has been instrumental in the delivery of this initiative.
The gov.uk site had made their entire code open source and we adapted the front-end templates – the basic design elements of the site – rather than starting from scratch. One of the great things the UK did was to use ‘responsive design’ so we didn’t have to build a separate mobile site – the code responds to the device.
The Govt.nz content was fact-checked by 44 government organizations. The contact details were fact-checked by more than 400 government organizations.
Silverstripe (private sector) provides the Common Web Platform (CWP) – the technology required to support the preferred operating model is dependant on the CWP.
Optimal Experience (private sector) conducted the user testing and research on our behalf.
The Citizens Advice Bureau helped us by providing their data on high demand services to help us prioritise the information we provide.
An ‘International Working Group on Digital’ was also set up to meet regularly and share learnings across jurisdictions. Talking with other governments we have found that the issues we face are global. It’s been valuable to learn about what they have implemented, what’s worked and what the ‘lessons learned’ are.
|
| 6. How was the strategy implemented and what resources were mobilized?
|
|
Approved in stages, the development of Govt.nz was managed as a complete project, fully funded by the Department of Internal Affairs. A capex budget of $797,839 was allocated for the beta stage in FY12/13 and $1.256m for the move from beta to production in FY13/14. The budget for both stages included all technical and human resource costs as well as the specialist areas (outsourced) of research and user testing.
The costs cover 3 main categories:
1. Usability - user testing, research, design elements and customer focus
2. Content - developing a content strategy and structure, finding relevant content from existing agency websites, fact checking and creating ‘user journeys’ showing how to get something from government.
3. Tech - hosting, infrastructure, development, security and accessibility testing
Roles within the project team were filled by individuals seconded from the Digital Engagement Team, DIA’s Technology Shared Services group and other public sector agencies. As and when required throughout the project, additional resource was created through specialist contractors. Deliverables such as user research and testing was outsourced to specialist private sector organisations and international colleagues experiences were leveraged wherever possible.
The system settings in New Zealand are set up to support individual agencies meeting their objectives. Each agency has their own appropriation and any cross-agency work relies on agencies voluntarily contributing to the initiative. Over the past few years, agencies have been forced to manage with lower baselines and, with the introduction of the Better Public Service reforms, more and more cross-agency initiatives are asking for contributions.
Products like Govt.nz, where the benefits fall to the public and not necessarily government agencies, do not fit with this funding model. The Central Agencies have recognised that, to deliver the Better Public Service reforms, more sophisticated models are required.
While these models are being developed, funding for the current financial year was required to maintain the momentum of Govt.nz. A one off Crown fund was established and an application was made against this for $2.98m operate and continue to develop Govt.nz. This was approved in August 2014 by Ministers. This significant investment shows the strategic importance of this initiative and the high expectations of the difference that it will make to the public.
|
|
| 7. Who were the stakeholders involved in the design of the initiative and in its implementation?
|
|
1. User-led
The development of Govt.nz was led by user research, testing and feedback. An initial round of research was completed to explore customer expectations, focussing on user needs, information architecture and customer experience. These insights were folded into the design of the beta site and two subsequent rounds of user testing were validated and analysed to make improvements and contribute to the subsequent production site. This has been a key success factor for the initiative and is the point of difference with the previous government portal and the majority of agency sites.
2. Content
Content was written based on existing text from agency websites and organised by the information hubs identified through user testing. The text was re-written to meet plain English standards, merged from multiple sources to provide a comprehensive view of the topic area rather than an agency-focused view, and gaps identified. In some cases, content that did not exist in one place was created.
3. Directory
The new Government Directory has information about more than 400 government organisations along with their contact details. This is one of the aspects of the product whose customers include other government organisations as it is the only full directory available.
4. Application Programme Interface (API)
The site uses a public API which is available for anyone who wants to reuse content from Govt.nz. An API is a set of instructions and standards that allows communication from one site to another. Content from Govt.nz can be automatically extracted in a variety of formats and republished in other locations. This ensures robust information is automatically updated when something changes on the API. The benefits of using APIs are about transparency and openness, it saves time, ensures information is correct and can be shared through many sources.
5. Transparency and communication
We have kept a running commentary on the project through the Web Toolkit. Our Minister and senior staff have been briefed at key points, we have posted regularly on a couple of Yammer sites, provided presentations to key groups in government, offered information sessions to web teams and collaborated with other teams across government and through our own intranet. We have also published a number of blog posts about what we’ve learned, tools we use, the approach we’ve taken to writing content, and encouraging other agencies to think about their users’ needs.
|
|
| 8. What were the most successful outputs and why was the initiative effective?
|
|
Planning and development of Govt.nz as an overall initiative utilised the Agile Development approach, however the departments Programme Management Office requires projects to follow their processes and documentation requirements.
Following these two methods has caused the team some challenges (more in question 9), however it has ensured that the team were able to progress at pace with the support and confidence of key parts of the organisation
Each stage of the initiative was divided into separate projects with a business owner as the project executive and a project board. Combining departmental processes and the Agile methodology the following documents were developed and approved for each of these stages and include a strict governance processes to monitor and evaluate each stage’s development and implementation activities.
Business case
Product Definition
Solution Strategic Approach and Solution Architecture
Risk Assessment and full risk and issues logs
System Design Specification
Security Risk Assessment
Environmental Build Document
Technical User Guide
Release Notes
Install Guide
Test Reports
Service Desk Handover Guide
Service Level Agreement
Project Plan
Product Development Plan
Product Delivery Plan
Communications Plan
Security Penetration Testing
Security Vulnerability Report
Benefits Realisation Plan
Status Reports
Exception Reports
End Stage Reports
External review (independent)
Code Quality Review
Solution Acceptance Certificate
System Security Certificate
Usability Report (independent)
Engagement Plan
Research Reports
Sprint Documentation
Throughout the project stages, monthly project board meetings were held where, utilising the documents and processes noted above, all progress was discussed and any actions to address delays, risks or issues documented and actioned.
|
|
| 9. What were the main obstacles encountered and how were they overcome?
|
|
The delivery of Govt.nz encountered some significant obstacles, some overcome and some of which remain work in progress post implementation. The main being:
1. Using Agile Development methodologies
Based on 4 values that fundamentally differentiate it from the traditional approaches that have such high failure rates, the Agile Manifesto values:
“Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more”
The difficulty lay in using Agile methodologies whilst delivering the heavy processes, documents and plans of the government’s well embedded Waterfall approach. The two processes operated in parallel, often duplicating resources/effort.
Successfully an important outcome has been building an understanding and comfort level within the department that Agile methodologies provide sufficient governance and monitoring with progress actually more visible to the executive leadership team. The Chief Executive now champions what he sees as a much more effective way of working and its use, internally, is growing.
2. Integrating Information and Fact Checking
Deconstructing information from so many government organisations re-constructing it to ensure it was easy to find and consume was huge - fact checking took 9 months of a full time resource to complete. There were constant iterations between agencies very attached to their existing content and the Govt.nz team who were determined to present integrated information in plain English content for the user.
3. Funding and Operating Model
Systems in NZ are currently set up to support individual agencies with very specific silo’d accountabilities. The funding and operating models for products and services like Govt.nz are still being developed, meaning finding sufficient funding to continue the project and the ongoing operation remains a challenge.
|