Richard George
Published on 20 November 2025
Why recognising uncertainty can be a project in itself
Most software projects involve a degree of uncertainty, especially those that deliver competitive advantage. The problem with uncertainty is that it comes in many forms and often surfaces when you least expect it. So, how can teams embrace and navigate uncertainty?
"Everybody has a plan 'til they get punched in the nose." -- Mike Tyson
Not every project is as dangerous as getting in the ring with a World Heavyweight Champion boxer, but there is similar potential for challenges and surprises. Not knowing what will happen – or assuming that we do – can be the root of many project problems.
Donald Rumsfeld, US Secretary of Defense from 2001 to 2006, is famous for introducing many of us to the concept of 'unknown unknowns' as the most dangerous form of risk. But I would argue that we're at much greater risk from the things that we think we already know.
Why? Because our assumptions often form the basis of our projects, and we stack critical decisions on top of them. If any of our assumptions prove to be wrong, then our entire project can come crashing down like the blocks in a game of Jenga.
Building on assumptions
Just because we think we know something at the outset, it doesn't necessarily remain valid throughout the project. Perhaps it wasn't even true at the beginning.
Teams often build their plans and projects assuming that certain things are known and true. I find that these are more dangerous than 'unknown unknowns' because they're the assumptions that we don't think to challenge. Hindsight teaches us that things can and do change, or they turn out to be different from what we thought.
The challenge is that if we spend too much time asking whether things are actually true or whether they've changed, nothing will ever get done. However, if we don’t spend any time reviewing, sensing, and questioning, we risk making or holding onto the wrong assumptions and doing the wrong things. The longer a project takes, the risk of such surprises can rise.
What do teams typically underestimate or overlook, and why?
When we embark on a project, we are effectively instigating some kind of change in an environment, but our project may not be the only thing introducing change to the environment: the problem itself may be changing, and sometimes, quite quickly.
I tend to think of a project as operating in a 'dynamic problem space'. That way, I can analyse the actors, forces and dynamics we’re operating with.
Risk management is a difficult task for most teams and organisations, and there can be a sense that risk management is only concerned with stopping things from changing.
In reality, it's actually more about understanding and managing how things change: both the changes that we as a project team introduce, and the changes that are occurring regardless.
We should see risk as a crucial means of helping us evaluate and navigate potential problems. We don't have to eliminate risk. However, if we acknowledge it, explore it, and try to overcome the urge to pretend it doesn't exist, our projects and initiatives have a greater chance of success.
Effective risk management also helps us overcome the biases which naturally exist in a team or an organisation – most typically confirmation bias (selecting information that confirms pre-existing beliefs) and anchoring bias (relying too heavily on the first piece of information received when making decisions) to uniqueness bias (seeing our requirements as unique and requiring new solutions, rather than selecting pre-existing code) or availability bias (making decisions overweighted with the readily-available information).
Preparing for change
One effective way of dealing with environmental change is to keep our project activities quick and small. As Nobel Prize-winning physicist Murray Gell-Mann said, "Do as little as possible; then do a bit less."
That reduces the opportunity for change to undermine your deliverables or the assumptions you've made. It also means you can more clearly see the cause and effect in what you've developed and use what you've learnt in the following deliverable.
A rapid accumulation of small, quick changes will often get you further faster than a carefully analysed and planned project executed over many weeks or months. It also has the added benefit that you will learn about the environment more quickly, and your knowledge will be more up to date when entering your next phase of change.
Another aspect of the delivery dynamics is the team's skills, mindset, and outlook. Not everyone is suited to pure innovation; likewise, not everyone is suited to carefully maintaining a mature service.
To borrow from Simon Wardley, some are best suited to being explorers, comfortable with experimenting and roaming uncharted territory. Settlers take the explorers' raw ideas into workable, robust, and usable products. Others may be more suited to the town planner role, scaling the product based on efficiency, standardisation, and reliability.
Each outlook has advantages and benefits, especially when carefully matched to your situation. People are, of course, not so one-dimensional. However, avoiding asking people to work against their natural aptitude can make sense, especially if time is against you.
Understanding a project’s 'geography'
In my experience, you need good maps to deliver good outcomes.
The idea of a map is helpful because they're visual and shareable, helping us collectively understand the environment and the obstacles, even if they're peripheral.
Mapping the stakeholders of your environment is especially useful – both inside and outside your organisation. If, for example, you operate in an ecosystem, there may be vendors, partners, or other advisers to consider. Of course, there will likely be customer stakeholders and end-users to consider and understand.
When you map out the risks and make the map accessible and collaborative for all, you help to build consensus and shared understanding. You can never be 100% sure everyone understands in precisely the same way, of course, but it's crucial to try. For example, in a product development project, I might create a grid to capture and map the key risks as follows:
| BUILD RISKS | USABILITY RISKS |
|---|---|
| BUSINESS RISKS | MARKETING RISKS |
Tools like Miro are perfect for this task. You can make a start, then share it, get feedback and evolve the maps.
Once the project is underway, the team can refer back to it quickly and update it with new information. Sharing is the most essential aspect of this process. It's really about collaboration, aligning understanding, and encouraging the team to be cross-functional, continuing to sense, test and learn as it delivers.
What you need to do versus what you need to know
The most effective teams combine thinking and doing. They are curious and prioritise building to learn over planning. The more we build, test, and iterate our ideas, especially quickly and in small steps, the more effective our products and services are.
You don't have to write code to learn, but you can. Alternatively, you could use a wireframe or some other kind of prototype. Ultimately, the process of learning needs to deliver commercial value. Learning by doing keeps the focus on value and velocity.
The process of releasing software is less of a barrier to testing and learning than ever. In most environments there are options to deploy dark launches (the code is deployed to production but only available to specific users), A/B tests, or beta releases so that you create something and get feedback. Whichever route you choose, cut code as soon as possible, even if it's ultimately thrown away.
The Agile process suggests building a 'walking skeleton' of your solution. That means creating the least development needed to develop a working solution for the key user journeys. It should deliver end-to-end, but only just be good enough. That way, you can establish a proof of concept and do as little as possible to get to the moment of truth – i.e. does it work, meet real user needs, and is it commercially viable?
Setting up the team for success
Successful software projects are built on staying focused on learning and progressing, simultaneously keeping different ideas and horizons in view. There are several traits to beware of:
- Overconfidence in the dimensions and details of the project: Try and stay open to the idea that information might be wrong or that the facts might have changed.
- Building for the sake of building: Be sure you have a sound rationale for the task and a clear understanding of the environment.
- Undue faith in following the process: Processes are tools for reaching an outcome; they don't guarantee the right outcomes.
- Siloed or functional working: When information doesn't flow, or people are working in an insular way, the team tends to be less risk-aware.
To use football (or soccer) as an analogy, it makes sense to set up your team with a system/strategy, put specific players in each position and establish a way of playing. However, if the opposition does something to counter or negate you, you must change your strategy. You'll keep losing the ball if you keep playing the same passes. Football is an agile sport in which the opposition is the environment.
In software development, too, you should continually adapt to the changing environment rather than doggedly sticking to the plan you had at the start. You need to score goals when the opportunities arise and not according to some predefined schedule: the more in-the-moment and better-skilled your players are (and the better they play together as a team), the more opportunities you'll create.
Mitigating change and delivering consistently
Dealing with shifting foundations, dynamics, or uncertainty is fundamental to Agile. Take small steps and do as little as possible, as quickly as possible, to test the hypothesis and get feedback on the solution. That way, you confirm that you understand the problem and whether your solution is useful (and valuable).
Don't be afraid to cut down the scope. Feeling that, once you've started with a particular scope, you must carry on until you've delivered them is one of the most significant contributors to failing projects. Similarly, don't assume you can't change the environment. Think about the stakeholders and the levers you can (and can't) pull. What influence do you have? It might be zero, but don't assume that’s the case.
Teams that are focused on learning with a predisposition to action and learning by doing tend to be more effective. Ultimately, the best measure of software development teams is commercial success because it indicates that their senses are tuned to finding out what customers really value as fast as possible.
Want more insights like this?
Follow The Adaptavist Group on LinkedIn and check out our other blogs.