Working with Uncertainty in Software Projects
Uncertainty
We all like certainty. Whether we are very risk-averse or comfortable with a certain amount of risk, there's comfort in believing that whatever happens, the sun will rise tomorrow.
In business especially, we often seek certainty. But the reality is that uncertainty is just a part of life. And a part of software.
Uncertainty early in a project is normal. What matters is whether there's a shared way of making decisions whenever the uncertainty shows up.
Scope Creep and Project Drift
Because uncertainty exists at the start of almost every project, pivots along the way are not only likely, they're expected.
That initial idea that someone wrote on the back of a beer mat will not be the final product. It's a spark. As the project progresses, ideas are refined, tested in practice, and shaped by feedback from real users.
This is not unusual, or unexpected, it's how things work.
Seen in that light, scope creep was always bound to happen. No-one had all the information at the beginning. No-one had a crystal ball.
Phases
So how do we balance our desire for certainty with a world full of uncertainty?
When building software, phases of development can help.
A large goal that might take weeks or months can be broken down into smaller, more manageable phases. First we build the X, then the Y, and then the Z - provided the order makes sense and there's a reason for it.
Even when phases take days or weeks, there can still be regular progress reports and ongoing discussion about how things are going and how the product is shaping up. If the direction looks wrong, that's the moment to pause and rethink before going too far down the wrong path.
The Problem With Fixed Quotes
In our search for certainty we often want firm answers upfront. How long will it take? How much will it cost?
Even when work is broken down into phases, problems arise when early goals are treated as fixed and final. Future changes are hard to imagine at the outset, and it's unrealistic to expect a project to rigidly follow an early plan once new information emerges.
Even when everyone acts in good faith, estimates can become inaccurate quickly, not because anyone was wrong, but because new information appears. That might come from technical constraints, user feedback, or even human availability.
For very small, well-defined pieces of work, estimates can work well. But for larger or more exploratory projects, they tend to get outdated surprisingly fast.
What I do
For all these reasons, my modus operandi is this...
- Split large projects up into smaller parts
- Provide rough estimates for each part, keeping scope intentionally small
- Invoice monthly for the hours worked for that month
In theory, you could add all the parts together to estimate the whole project, but since each part is still an estimate, that total should always be treated cautiously.
I'm often uncomfortable quoting a fixed monetary amount upfront when everyone knows ideas evolve and projects drift. That drift is normal. It's rare for a project to remain unchanged from inception to maturity.
In practice, this looks like...
- We agree what I'm working on
- I do the work.
- At the end of the month, I send an invoice and a summary of what's been completed
- There's a natural pause point each month - invoices are settled, progress is reviewed, and we decide together what comes next.
Conclusion
The world is uncertain. Software is uncertain. People change their minds. Developers encounter unexpected problems.
The healthiest projects allow flexibility on both sides. Founders need space to learn and pivot as they see the product take shape. Developers need space to build software that isn't brittle and can be maintained over time.
Uncertainty isn't something to eliminate in software projects - it's something to manage openly, together.