Knowns & Unknowns in Web Development
When I was a teenager, United States Secretary of Defense Donald Rumsfeld gave a press briefing in which he talked about “known knowns” and “unknowns unknowns.”
At the time, this statement was roundly ridiculed.
In my professional life, however, I’ve come to understand that Secretary Rumsfeld was making a meaningful point and not misspeaking. A few months ago, when I came across another perspective on known and unknown knows from Chris Voss’ brilliant book Never Split the Difference, it reminded me of an internal document I wrote a few years ago around the impact of knowns & unknowns when it comes to successfully managing web projects.
I’d like to adapt some of this internal content for you here today.
The Origin of Knowns & Unknowns
The concept of knowns and unknows evolves from “the Johari window,” a cognitive psychology technique from the 1950s “designed to help people better understand their relationship with themselves and others.”
Adapted to web development, or project management more generally, here is a very simplified overview of the four quadrants inspired by this technique.
Known Knowns
These are things we are aware of, and we understand.
In the context of web development, we know and understand things like what platform we will build on (WordPress? SquareSpace?), how we will handle project updates (by email? biweekly meetings? in a project management software?), and what skills are available on the team (a developer might be strong in PHP but less adept at React).
The more known knowns the better, and likely the more smoothly a project will run. This is why many agencies and vendors have a narrow scope of offerings, with templates and blueprints that keep things very clear and aligned. They don’t offer “web development”—they offer five-page Wix websites with locked-in layouts.
The further you stray from your core awareness and understanding, the more unknowns—and therefore risks—you introduce to a project.
Known Unknowns
These are things we can identify, but that we are missing. An example might be receiving a confirmed sitemap; we are aware that until that confirmed sitemap is received, other aspects of the project (like budget and timeline) cannot be confirmed. Another consideration might be integrations. You may know that the site needs to integrate with a CRM, payment gateway, or third-party software, but the specifics of those systems (e.g., API limitations, data syncing issues) could present challenges once you start the integration.
Known unknowns are very common in web development, and often what makes a given project unique. The key here is being aware of these, the risks they may cause to the project, and how to mitigate.
Unknown Knows
I like to think of these as biases or assumptions. These are factors that we can uncover, and turn into “known knows” with discovery and curiosity.
An example is language. We might be scoping a website as unilingual (English only), while the client may be anticipating the site as bilingual (English & French). If we ask the right questions and unveil this gap, we can get aligned and avoid unmet expectations and frustration.
Unknown Unknowns
As you might anticipate, this is the trickiest—and riskiest—category. Unknown unknowns are things that are not known and cannot be planned for.
I have a great real-life example of this. We scoped out a new brand identity and website in late 2019 for a client who was looking to create a sister brand, a new dental clinic. We designed the logo and got to work on the development of a new website. During the website development, we were struck by a global pandemic.
While our team was able to continue work on the website, the client’s priorities changed. Due to challenges with the ongoing pandemic, supply issues, and uncertainty about normal service resumption, they put their opening plans on indefinite hiatus. Of course, this meant they wouldn’t need the new website to be finished.
No one at the time would have anticipated this external event to derail a web development project, but these are the types of things that happen in the real world.
Why is this important?
Web development has enough potential landmines that we don’t need to introduce any unnecessarily. You only need to accidentally overwrite style.css with no back-up one time to understand the importance of risk mitigation.
With proper planning, we can also effectively “defuse” landmines that might otherwise cause serious problems for the successful delivery of a project.
This is why I think it’s very important to list all of the knowns and unknowns in the planning stage of the project and provide a detailed technical specifications document to be reviewed with the client.
If we say a blog is included in development, does this include the design of the main blog feed and individual layouts, or just activating the default template that comes with the theme? Are we transferring blogs? Does this mean we’re also transferring images and associated assets? Are we Q/Aing for formatting issues? Are we building category pages, author pages? Do authors need accounts? Are we activating comments? Is search required?
You can see how one simple inclusion can actually lead to dozens of possible conditions, adding anywhere from 5 minutes to 500 hours of additional development.
This process, while time intensive, will also reveal assumptions made by the client and the agency, and give space to correct if necessary. Educating and guiding the client here is critically important, because while you might build one site a week this might be the only web development project the client ever experiences.
How to apply this framework to web development
- Known Knowns – these are our known facts and specifications. List these out as the foundation of your project. The great thing about following this process is that this list will grow as more information is uncovered.
- Known Unknowns – these are questions that still need answers. Where will we host? Whose account should we register the API key under? These answers will be decided on, and you can move them to known knowns.
- Unknown Knowns – these are things we know but aren’t necessarily aware of. Typically, they are biases or assumptions that are uncovered through dialogue and discovery. If they are not uncovered until late, they may need to be put aside as unimportant, or addressed in a later phase of the project. Unknown knowns should not be detrimental to the success of the project with the right questions asked.
- Unknown Unknowns – these are things that cannot be known or anticipated specifically. That said, you can still have risk mitigation plans. What if the project has to be paused due to external factors? What if we can’t see the project delivery through? While the specific cause of these derailments may not be known (budget, global crisis etc.) you can still decide on common exit pathways.
Web development is a beautiful act of collaboration and creation, but it’s not without its risks. Having worked on hundreds of web projects at seoplus+, I’ve been able to see first-hand the many ways a project can be delayed or derailed, even with the best intentions from all parties.
While this framework may seem a little abstract, I’ve found it very helpful in creating clarity and alignment on web projects over the past two years at seoplus+. Since tangling with these notions, we’ve shed light on assumptions, asked better questions, created better project plans, and set ourselves (and our clients) up for successful project delivery.
Consider applying this framework even more widely to other project types, or even internal initiatives and processes, and see what you uncover as a result.
