Understanding the problem(s)
The IT governance process is the start of all governance. You request for IT governance when you:
- Have an idea for a new system
- Need to recompete and existing system
- Need to decommission a system
At the end of creating a new system or recompeting an existing system, you receive a Lifecycle ID (LCID) which is a unique identifier at CMS. This unique identifier gives CMS visibility into the progress of your system and prevents projects from becoming “shadow IT” or not accounted for in CMS records.
We learned a lot during our Discovery work. Over the course of 8 weeks we conducted 30+ interviews with potential users and stakeholders, ran workshops to better understand their journeys through IT governance, and iterated on several concepts before aligning on an approach.
We learned that from a stakeholder perspective, the biggest pain for Rajiv (CIO) is that there is too much “shadow IT” within CMS because people circumvent governance processes. Shadow IT then runs the risk of putting CMS in jeopardy of getting sued for not having visibility into all systems, what is live, and what is compliant.
Stakeholder needs synthesized from 12 user interviews
From a Business Owner perspective, they have no idea why IT governance exists, how it benefits, and the point of a lifecycle ID. They are seeking a clear, transparent process that lets them know how they are progressing through a process and what they need to do to complete it.
User needs statements captured from 20+ interviews and contextual inquiries
Our Discovery work with the back office came on a bit later, because the back office team (admin leads) didn’t have any huge problems outright. Our focus was primarily on Rajiv and Business Owners based on our Product Owner’s direction and the impact of the problem. Overall, they relied on Sharepoint which supported their process quite well. Eventually some pains on their end were: navigating through email/finding details about a request within email, requesters not completing their documentation, and making sure the appropriate form of governance is applied to a request (full governance or LCID reissuance).
Service blueprint of the to-be system
How we solved it
This is a process that can span over several weeks and involve many steps and review points. We want Business Owners to know a) what the whole process is b) which step they are in the process c) what they need to do at that specific step. Our process spanned many user interviews, concept tests, and eventually resulted in us testing and delivering a gated task list with statuses. This task list helped Business Owners see all the steps and bring focus onto the step that they were currently in.
The gated tasklist we released to end users. See it in Figma.
The gated task list also meant that someone needed to move the Business Owner onto the next step. To facilitate this, we created a back office tool for the IT Governance team. This tool allowed them to manage requests in one central place, keep all associated information together, move the task list status, assign a team member, make internal notes and send emails. While the back office tool was a consequence of the solution for Business Owners, we took the opportunity to make some efficiency improvements and solve some of the problems that came with manual emails and using SharePoint.
The admin segment of the application. See it in Figma.
The two documents in this process are the Intake Form and the Business Case. Business Owners found it difficult to answer the questions within them and thus resulted in a lot of back and forth for clarifications. To help Business Owners confidently answer these questions, these forms were digitised. This included, refining the form fields to make them clear, adding help and guidance and preventing errors from happening.
One of the forms with help and guidance. See it in Figma.
What we didn't get to
Requesters prefer to fill out forms in a non-linear way because that’s how they gather information
We built and tested a hub and spoke pattern for the Business Case that users preferred over the linear version. This helped users hone in on parts of the Business Case they knew the answers to, without needing to cycle through page-by-page. Overall, users wanted to know how they were progressing through the Business Case, where their errors were and the ability to get to those errors quickly.
The hub and spoke pattern. See it in Figma.
Learnings
At the start of the project we were told by our Product Owner to focus on the customer experience because the “back office works for CMS and doesn’t need all the bells and whistles.” Given how much generative research we needed to conduct, I decided to follow his direction.
A few months into the project we learned that although the back office was going to be forced to use this application, they had significant requests to ensure a seamless transition to the new system. Conversations were frustrating and painful, because we didn’t include their needs and problems in the preliminary discovery work.
This experience taught me to always start with the back office, learn how to best support their process, and then dive into the customer experience. It is only through prioritizing the back office that you can build a service that effectively supports the customer experience.
Ultimately we were able to replace their tooling without any hiccups, but it took us descoping the customer experience and many challenging conversations.