Scoping new products in the context of COVID-19 : 3 tips for delivering at the speed of need
November 4, 2020
by Katherine Benjamin, Deputy CTO for Digital Services
Tl;dr summary: Urgent digital requests require exceptional intake and scoping. Expediting the scoping process means tackling awkward conversations head-on. Leverage the precedent and resources used by leading digital government jurisdictions to rapidly scale your process.
Following the completion of our first cohort of NYC[x] Innovation Fellows, one question we get asked often is how teams can scope and oversee rapid product development. This post outlines 3 steps to help user-centered and agile teams respond to time-sensitive product requests.
- Orient yourself to your partner’s environment
Start by assessing digital maturity. Of course, a time of urgency may not be the right time to talk to partners about their comprehensive five-year digital strategy (or lack thereof). The viability of a given product request can be quickly ascertained by understanding if the team in question has a clear vision on how to incorporate that product into their overall digital strategy.
Thankfully, there are pre-established ways to do this. The UK’s Government Digital Service has a 7 Lenses maturity matrix for digital transformation. Similarly, the Harvard Kennedy School has a detailed assessment framework for digital service teams. While it may not be feasible to run an entire workshop and go through every point, a quick spot check on a 30 minute telephone call can help you orient yourself. As a start, I use question like:
- Vision: Tell me about your digital strategy and vision, who owns this?
- Design: Tell me about when you last conducted user research, and how that has been incorporated into product design/product vision?
- Plans for multichannel and accessibility: Tell me about how your plans for digital services relate to your ongoing services, and how is that being managed today? What are your plans to ensure nobody is left behind?
And if you have time for, here are some bonus questions:
- Growth: Do you plan on doing less digital work next year than this year? What investment decisions are you making to align with plans for growth?
- Transformation: How much do you really want to change?
By getting a sense of where a partner is now, you can help get a realistic sense of where to start and the first steps on the journey.
2. Reach an agreement with your partner on roles and responsibilities
In agile user-centered projects, it is tricky to outline what exactly is in and out of scope. This is because the scoping process generally requires writing documentation up front when we know the least about the end-user — ahead of user research. And typically until the user research is complete, we are really just cataloguing assumptions.
While some of the leading digital government jurisdictions are debating moving away from the “Discovery/Alpha/Beta/Live” linear construction of the product development lifecycle, I find that model continues to be an incredibly handy jumping-off point to quickly frame the point of entry for given engagement, particularly in times of rapid response. This model helps to de-risk projects by always starting with discovery and frame any expected deliverables, as detailed below:
- Discovery — User needs are researched and identified, the problem framed, and an ecosystem of stakeholders outlined.
- Alpha — A core service is built to meet the main user need(s) but is not generally intended for release to the general public or wider audience.
- Beta — The service is improved, then tested in public (but not relied on for critical service delivery at scale).
- Live — The service is public, used at scale, and works reliably. It will be continually improved to meet user needs.
Finally, once you’ve scoped out the project, document your plans. At the New York City Mayor’s Office of the Chief Technology Officer (MOCTO), our partners complete a roles and responsibilities document that outlines how an agile, user-centered collaboration will work. Our Roles and Responsibilities template draws from a range of leading digital government teams, including the Ontario Digital Service Project Charter model, the 18F Partnership Principles, and the approaches to scoping projects used by Code for Canada, and Code for America.
3. Embrace unpolished Work-in-Progress
Having attended and run countless Show & Tells, I have never met a single person who has attended a Show & Tell then concluded that “a written brief would have made the product development work more clear.” The rally-cry of the digital government movement — “Demos Not Memos” — illustrates how making work tangible aligns stakeholders and allows for iterations based on feedback.
Show & Tells are meant to be raw, unpolished work in progress. If your team is spending more time prepping for a Show & Tell, or polishing a narrative about a product than building the product, you are doing it wrong. Show & Tells are not about what you intend to do. Rather, they are an unfiltered showcasing and discussion or what you have done and a preview of your immediate next steps.
Some of the world’s most advanced digital government teams, like the UK’s Government Digital Service and the National Health Service, and Canadian Digital Service post Show & Tells on Youtube. But generally, invitation-only Show & Tells are how most digital government teams, including the Mayor’s Office of the CTO, operates. Don’t be shy about inviting friends and well-wishers, you would be surprised how many people are keen to observe work in progress; at our final NYC[x] Innovation Fellows Show & Tell, we had 65 attendees from 16 NYC agencies. If you would like an invitation to our next Show & Tell, or a copy of our Roles and Responsibilities template, email cto@cto.nyc.gov.
Honey Dacanay, Katy Lalonde and I made a cheat-sheet outlining this work for a workshop on Delivering at the Speed of Need for FWD50, the world’s largest annual digital government event for public servants. Feel free to use or adapt our work!
