Digital project estimation: The dark art
It’s been said that most clients will accept a 25% to 50% variance between an estimate and the actual cost of their project.
However, in the software industry, project estimates have been shown to be off by a factor of 4. That means that a single project can take up to 4 times more (or less) than its original estimate.
Why is that?
Back in 1981, in his book Software Engineering Economics, Barry Boehm applied the Cone of Uncertainty to the software industry.
It basically illustrates that the faster we estimate, the less accurate we are.
Of course, project management has evolved a lot since then and processes have been put in place to prevent this.
One proven method for better estimation is prototyping. It allows stakeholders and decision-makers to visualize and even test their projects beforehand. Another method is going into the design phase before estimating. Both take time and are very risky.
When you work in a fast-paced environment, with lots of projects and aggressive deadlines, you soon realize that you simply don’t have the time, nor the team, to prototype each one. Not to mention the valuable time dedicated to prototyping (or designing) projects that never see the light of day.
But wait, there’s more.
There are two additional factors that we must bring into view.
Technology
A single project can contain a plethora of technologies required for its functionality, and each one represents a unique development effort. Thus, one might require considerably more time than the other.
Some can be:
Programming languages, frameworks, libraries, etc.
Platforms or APIs to be implemented
Infrastructure requirements, such as specific servers, databases, etc.
And many more
If these variables are not properly defined in the beginning, or if they change during the process, the impact on time and budget can be considerable.
Client involvement
This is the most common factor affecting project budgets.
As technology evolves, so does the complexity of projects. Function and user experience in software products can be very hard to visualize, especially in the early stages. So, the initial product vision changes as the project comes to life.
As a result, project management methodologies and frameworks like Agile and Scrum have been developed to help.
They focus on breaking projects into small increments and receiving client feedback for each. They also account for the fact that projects continually evolve as the product vision becomes clearer. This has caused a dramatic increase in client involvement. It has gone from providing feedback once or twice per project to constantly testing and sharing feedback for each piece instead.
In the slides below, you can see how client involvement has increased and how it impacts the initial product vision as the project becomes clearer and more tangible.
Now, additional client involvement is good (great, actually) since the project continually evolves, focused on the business goals. Also, any questions are quickly addressed, minimizing guesswork.
So then, why is it such a challenge?
Because even though the software development lifecycle has evolved so much, project owners are not used to these processes and usually request quick (and precise) estimates that cover the entire project and don’t change over time.
The fact is that projects, and budgets, evolve during development. It’s also a fact that clients need budget clarity and visibility to plan their efforts accordingly. However, implementing stricter change request policies only complicates and delays projects.
So, we find ourselves in quite a dilemma.
A “let’s meet halfway” approach
An initial approach, to start moving in the right direction, can be:
Share your development process with clients (so both parties participate)
Break down large projects into simpler/quicker project increments
Create high-level estimates for each increment
Fully define and estimate the first few increments only, the main project will change as it progresses
Clients should add 25% to estimates to compensate for potential project changes
Get client feedback whenever an increment is ready
Discuss budget consumption in weekly status meetings
While this new structure becomes adopted as the norm, the teams can slowly add agility methods until both teams feel comfortable and find the correct workflow.
Feel free to contact us, our team is ready to help you tackle your digital projects.