Beyond estimates: building an information stack for risk - Part two

In the previous article, we looked at real cases from our day-to-day work, showing how we deal with a familiar scenario: estimates distorted by cognitive bias and poor data measurement. But what happens when we also need to account for the client’s focus on time and cost, while managing complexity across long-running projects? Let’s take a closer look.

One particularly interesting aspect is how we approach the conversation with the client. The initial request is almost always the same: provide the most accurate possible estimate of time and cost. But the more useful question is often: what can we actually ship within the available time and budget? This shifts the focus from predicting costs to managing scope and priorities.

As complexity grows, the problem is not the level of detail, but whether the risk assessment is fit for purpose. Agile practices support a non-deterministic approach by setting project boundaries upfront and managing priorities as the work goes on. But what happens when the client still expects a deterministic plan, despite significant unknowns?

Once we’ve outlined the scope well enough to get a broad sense of the effort involved - for example, a project that will take at least a year and require a team of at least six people - we’ve sometimes proposed a dedicated discovery phase, which also allowed us to identify the deliverables that needed a closer look because they involved more unknowns.

Moving risk analysis into this phase can make time and cost estimates more accurate. However, it requires an upfront investment from the client and still doesn’t provide certainty around either. In some cases, it can even make the uncertainty feel greater.

Agile ways of working, on the other hand, require collaboration and trust between everyone involved, with the client playing an active role as the project evolves. This is where our team feels most at home. We start with our methodology, expertise we’ve developed iteratively by applying it to our own work, refining it over the years, and continuously researching best practices to make our workflows more efficient and our delivery more effective. We then share and extend this approach, adapting it to the client’s environment and organisation in an inclusive way that makes collaboration easier and helps everyone feel comfortable taking part. The client has full control over the project, its evolving scope and priorities, and decisions about time and cost but they are not left to navigate those decisions alone.

For the scientific publishing client mentioned earlier, this methodology has been the foundation of a multi-year partnership. The model combines a fixed base fee with a variable component: within a shared planning process, the client ultimately decides how much of the assigned team’s engineering capacity to use.

In another case, we’ve been supporting a neobank since 2023, providing full-stack development with Django, Python, and Tailwind for a B2B2C portal integrated with Azure cloud services. Here, the main risk came from aligning the client’s different internal departments around shared goals and requirements, as well as from our team’s dependencies on several of those departments, which often operate independently.

We chose to set clear boundaries around the project by assigning a highly senior cross-functional team with a fixed allocation and defining an explicit, detailed workflow. This covered both governance and risk management across the operational workflow, from roadmap prioritisation and dependency management to the shared backlog, and technical risk management, including how requirements affect technical solutions and rework.

Reducing uncertainty isn’t necessarily about making estimates more and more accurate. It starts with breaking the problem down into units that are small and clear enough to estimate reliably. In this context, iteration becomes the main tool for gradually separating what is essential from what is optional, reducing the project’s overall risk.

We often work on open-ended, scalable projects that continue to evolve over multi-year lifecycles. We’re used to managing that complexity through robust analysis and solid software architecture. That’s why we use technologies such as Django: a mature, stable framework that is particularly well suited to this kind of project. It allows us to keep building over time without running the risk of having to throw everything away and start again, even years later. On this basis, reducing estimation risk means breaking work items down into units that are small and manageable enough to estimate reliably.

We recently tested an LLM-assisted technical estimation workflow on a set of 36 change requests raised by an international client. The requests concerned one of the many internal workflow tools we’ve built for them: a platform used to approve business travel for employees based around the world.

In this case, Juliana Nicacio, a backend developer on the team that worked on the project, started with the T-shirt sizing commonly used for technical estimates, followed by an internal validation step. She then developed and documented the analysis process further, introducing a set of clear criteria.

For each item, the analysis starts from the code, not from the change request description. This makes it possible to clearly distinguish bug fixes from new business rules. At the same time, she groups items by shared functional area and collects the open questions for each group. Items that are ready to move forward are kept separate from those blocked by questions for the client.

She then addresses complexity by distinguishing, for example, between functionality that needs to be built from scratch and functionality that can reuse similar patterns or mechanisms. Larger estimates are broken down and explained in terms of their individual parts, such as coding and testing hours. When an answer from the client could expand the scope, the additional work is estimated separately as an add-on. She also assesses the blast radius of each change to understand how much of the system it could affect and the level of risk involved.

In short, the method systematically separates what can be verified from the assumptions that still need to be confirmed with the client. It keeps estimates anchored to a fixed scale and breaks each one down into coding, testing, and manual verification, making the reasoning behind it clear and defensible rather than leaving the client with a gut-feel number. The result is a multidimensional analysis document that the client can use to set priorities and make decisions independently, based on their own goals. They can adjust those priorities over time without having to ask, at every iteration, “How much will this feature cost?”.

If there is one thread connecting the four experiences described here, it is that none of them tries to solve the estimation problem by making estimates more precise. Instead, each one aims to make them better informed: by considering who produces and validates them, what gets measured afterwards, how the question is framed with the client, and howsmall and well-defined each unit being estimated is.

This, ultimately, is the information stack we refer to in the title: not a more reliable number, but a set of practices (peer review, planning poker, data-driven time tracking, targeted discovery, and systematic breakdown) that work together to contain uncertainty rather than pretend to eliminate it. Estimates remain an imperfect tool, and they always will be. But they become reliable when we stop asking them to predict the future and start using them to help us govern it, one iteration at a time.

We know there’s still a lot to learn, and we’ll keep sharing what we discover along the way.

***

This is the second and final part of Beyond estimates: building an information stack for risk management. If you missed part one, you can read it here.

***

We wrote this article with the support of AI. If you’re interested in how we use these tools as part of our writing process, you can read more here.