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.
As we explored in our article covering the use of agile development over waterfall, an advantage of the former 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.