How to Push Through the Cone of Uncertainty

At any given moment, Postlight is building digital platforms of various shapes and sizes for multiple clients across industries. Part of my job is to monitor those efforts: the quality of our deliverables, the project timeline, and the health of our relationships with our clients (via our QORE framework).

There are several tangible things you can look at to see how an in-progress software effort is going: the artifacts that have been created, the roadmap ahead, how well the team is collaborating with one another and with the client, and the team’s velocity on the ground. Another way I like to look at in-flight software efforts, especially the ones in the beginning stages, is through the lens of uncertainty: How much uncertainty is there? How effectively are we reducing that uncertainty over time?

Steve McConnell envisions this as the Cone of Uncertainty — a cone, on its side, with a large degree of uncertainty to begin (the opening of the cone), which decreases over time as you take away variability. The key there being: YOU take away variability by drilling in, getting answers, and making decisions to drive the effort forward.

When we partner with clients, Postlight is biased toward embracing change in software. We’ve been in this game for a long time, and we know that variability is a part of it. A million decisions have to get made along the path to a successful software project delivery, and the majority of those decisions have not been made at kickoff — not even close. We estimate as best we can, and then we work toward getting more information for even better estimates.

That’s why I think about the process of making digital products as a practice of creating clarity. When we build software platforms, we’re defining a world: a world of objects, workflows, and pathways for users to take in order to complete tasks. We use phrases like “call to action” and “happy path” when we design digital products, and we decide what those things are. (It’s a profound responsibility!) What action should the user take? What is the journey to completion? What does success look like? Answering those questions means we must create clarity about intentions, goals, and paths forward.

An infinite loop

A healthy software effort is always reducing uncertainty and creating clarity. At a high level, the process for doing that is pretty simple. If I had to write the process as a BASIC program, it would be a five-line loop:

Every time this loop executes, the amount of uncertainty around an aspect of the project reduces, and the number of answers, decisions, and clarity increases.

To the programmers out there: Yes, this is an infinite loop. Living, breathing software that has attention on it is never truly “done.” But most of the time, attention and investment in software activates and has a timeline and a budget with a finish line defined. So let’s take a more linear approach.

The linear path

When Postlight takes on a software effort, there’s a progression of artifacts we produce. If we’re doing our job well, these artifacts answer questions and reduce uncertainty along the way. 

They include:

• A Statement of Work (SOW): We put this together before the engagement starts, to create an understanding of what we’re going to do and deliver. It’s a list of high-level, shared goals between Postlight and our client.

• Project Plan: When a project kicks off, we put forth an outline of a project plan. This is a living document that gets more detailed and granular over time. The first version is pretty low-resolution. The main thing we know is that we start with a stakeholder and user research and discovery phase, which will help us color in the details.

• Product Strategy: The information we gather in the discovery phase helps define our North Star. Our overarching strategy answers the questions: What specifically are we trying to accomplish? What are our measures of success? Often — but not always! — this is an evolution of the SOW’s goals, and it lays the groundwork for the product requirements to take shape.

• Product Requirements: What must the product do? What functionality must it contain? What forms will it take? What are the limitations and dependencies involved? Product requirement definition tees up design and engineering to begin putting pencil to paper.

• Designs: In the design phase, the team begins to produce the user-facing parts of the product with increasing levels of resolution, from wireframes that are just gray boxes and black lines, to high-fidelity, colored-in design to development-ready interactive prototypes.

• Software Releases: With requirements and design in hand, engineers can begin implementing releases — again, with increasing levels of functionality, from alpha to beta to release candidates to the live production release.

• Post-Launch Roadmap: Every production software release leaves behind a list of things that didn’t make it in, that got deprioritized, that needed more clarity, that weren’t apparent they were needed until too close to launch. Running up to and post-launch, the team synthesizes the needs and requirements that didn’t make it in but should into a next-phase roadmap. Additionally, once working software is in the wild with real users putting it to the test, it quickly becomes apparent which parts of the product are getting used well, and which need work. Those optimizations should also be part of that future-looking plan.

Each of the artifacts listed above answer questions raised in the ones that came before it. I imagine the team working on each of them cycles through that BASIC loop dozens of times to get to each deliverable. When each one is complete, the effort moves forward through the cone.

Ultimately, creating clarity benefits everyone, from the team working on the effort, to the business stakeholders, testers, and users. When in doubt, leaders and builders always drive toward making decisions, getting clarity, reducing uncertainty, and clearing the path forward to completion.

Gina Trapani (@ginatrapani) is a Managing Partner who heads up Digital Strategy at Postlight. Get in touch: gina.trapani@postlight.com.