My first 100 days in Wellington City Council’s Digital Team

This year, after 7 years in the private sector, I joined the Wellington City Council. I thought I’d share a few impressions of what I’ve seen, what I’ve learnt, and where we’re at.

The Council has many websites

As an outsider coming into the Council, I knew about wellington.govt.nz. I had expected an intranet, and a few other sub-sites, but I was blown away by the complexity of the ecosystem that exists with dozens of different business units (we are still uncovering sites).

That’s not just the number of properties (domains and sub-domains). The main website itself interacts with many systems, and facilitates so many transactions (dog registration, property search, cemetery search, parking tickets, submitting formal submissions, online payments…).

The Digital Team receive many internal requests

On my first day, I opened my inbox… and found hundreds of emails. The lion’s share of these emails were to the shared WCC Outlook inbox GRP:WebCentre. I created email rules and sub-folders to make some sense of it.

The bulk of the messages were requests (and subsequent correspondence) from internal staff to make changes or get help with Council digital properties.

As a response, we are currently trailing a “customer service management system” as a method to manage the volume of requests we receive:

Staff are generally happy with the service they get

We conducted a satisfaction survey with WCC staff who had emailed GRP: WebCentre over the last few months. We did this mainly to get a benchmark to judge the affect of any changes we make in the coming months.

The results showed that staff were generally happy with the service being provided (which is actually a little bit intimidating from a benchmark perspective — hard to improve on “very good”).

The Digital Team is changing

We’ve made workflow more visible

As mentioned above, we’ve funnelled help requests into a system to better manage them, which means anyone can now get a clear overview of requests.

In addition to small help requests, we have our mid-to-large sized jobs represented in Trello, and then duplicated on a team Kanban board on our new whiteboard walls:

The idea behind all of this being to make what is in the pipeline more visible.

“If you can’t measure [see] it, you can’t manage it”

In addition to this, we’re working on a dashboard in our team area displaying:

• people currently on the main website (where they are and what they’re doing)
• live-stream of incoming services requests
• statuses of some key Council digital properties (such as the main website)

We are bringing in new people

To deliver improved digital service delivery for Wellingtonians, the team is bringing in new people with new skill-sets.

We are looking to complement our current team with some specialists, and then to spread those skills to other members of the team, and eventually the whole organisation.

We want to mimic the UK’s Government Digital Service

If you haven’t heard of the UK’s GDS unit, I cannot recommend reading about them enough:

• GDS design principles https://www.gov.uk/design-principles
• GDS service standard https://www.gov.uk/service-manual/service-standard
• GDS service design manual https://www.gov.uk/service-manual

We want to take as many of their approaches, processes, and resources and reuse them to whatever extent we can.

Structuring projects to be user-centred

Digging slightly deeper into GDS’s methods, we want to structure our projects to ensure we are exposed to feedback loops from our users as early and often as possible

Next steps: How do we decide what to work on?

Once we have our new team members, we will be attempting to address:

1. How does an idea become a proposed projects?
2. How do we accurately capture the size and complexity of a proposed project?
3. When should we be working on “foundational” (internal) projects (pattern libraries, platform improvements, etc) versus “business” (external) projects?
4. How do we know as soon as possible that we need to validate the answer to question 2 with actual evidence from customers?
5. Which things, under which circumstances, do we fast-track?
6. How do we triage from all the possible things we could do to the things we will do?
7. What might our “research”, “alpha” and “beta” phase approaches look like? (We’ve recently trialed a Google Venture Design Sprint with Toi Poneke)

As always, if you’d like to get in touch with us, please do!