
How do you manage expectations in software development?
Expectations can be a powerful, yet unavoidable force in any project. In the following article, we explore some of the ways in which you can best manage these through the lifecycle of your software project.
Expectations can be a powerful, yet unavoidable force in any software project, emerging at the earliest stages and following you through the entire development life-cycle. As we explored in our article covering top 10 risks in software development, setting and managing these expectations is a crucial risk mitigation strategy, particularly for those that emerge among the relevant stakeholders as they more often than not represent a core benchmark of a project's perceived success.
As far as estimates are concerned, whilst you can strive to set realistic parameters around time, cost, quality and scope, they are always inherently vague at the very beginning of any project. So, how do you ensure a stakeholder never misconstrues these estimates as certainties, on which unrealistic expectations could be founded? In particular, we need to be mindful that any uncertainties built into estimates should be visible in our project plans.
The cone of uncertainty
Trying to estimate how long it will take to complete something is like looking into a crystal ball to predict the future, especially when it comes to building a bespoke piece of software. In reality, no two projects are the same. An estimation is based solely on the past experience of a team and the project requirements (that are likely to change over time), making it near impossible for it to be considered accurate initially. Even for a software development team with years of experience, the further into the future you want to predict, the less accurate it will be.
The cone of uncertainty is a depiction of the level of uncertainty around the length of time required to complete a project based on the amount of knowledge at the beginning of a project. It accounts for the risk of the project time blowing out due to this uncertainty. As such, there is always a trade-off present between scope and time that any stakeholders should be made well aware of at the outset.

How can you best estimate around uncertainties?
To best avoid inaccurate estimations, your team should focus only on small amounts of work at a time. Not only does this give them a chance to familiarise themselves with the product and relevant requirements in question, but also helps to build their confidence when it comes to estimating again for future work.
An advantage of agile methodology exists in the use of trade-off sliders that allow stakeholders to convey their expectations to the development team. By doing so, you will be able to provide the relevant stakeholders with a significantly more accurate view of a given software project, setting realistic expectations in the presence of inevitable scope variations, optimistic time estimations, and the inevitable unknown unknowns in software development.
Discover More
Your Knowledge Base Is Lying to Your AI
AI has become capable of doing real work. But most organisations are feeding it knowledge that was never designed for machines. The result is subtle, expensive, and increasingly hard to ignore.
The Next Phase of Enterprise AI: Inside the CodeBots Roadmap
Enterprise AI is entering a new phase. The early wave focused on access to powerful models and rapid experimentation across teams. Now the challenge is operationalising AI. Organisations need structured ways to build reliable systems that are governed, repeatable, and maintainable at scale. In this post, we outline the three phases of enterprise AI and share what is coming next in the CodeBots roadmap, including Chat Studio, Knowledge Base, Metamodel Visuals, and DataIQ.
Meet BotBot from CodeBots
Starting a new bot should not mean inventing structure or accumulating technical debt on day one. BotBot scaffolds a best-practice repository, evolves it as standards improve, and makes your bots agent-ready so teams can build with confidence from the first commit.