Have you ever heard of a “Standish Chaos Report”? Trust software developers to come up with fantastic terms for an otherwise prescient trend occurring in development projects: the incidence of project failures and the factors that contribute to them.
The failure records of software projects in the United States alone is quite staggering. According to the Chaos Report
- 31.1% of projects will be cancelled before they ever get completed
- On average, across small, medium and large enterprises, over half of projects will cost 189% of their original estimates
- While companies in the U.S. spend more than $250 billion each year on IT application development, spanned across approximately 175,000 projects, only 29% of these are ever counted as “successful“
- Meanwhile, Tricentis estimates that software failures cost the U.S. economy up to $1.7 trillion in financial lossesSource: Chaos Report 2017
The truth is that poor estimation can lead to a score of issues, besides simply a time or cost overrun.
It can lead to changing requirements, poor testing practices, software vulnerabilities, glitches, bugs and overall “challenged” projects doomed to reproduce technical failures if launched merely to meet cost and time budgets but not quality standards.
Source: Software Fail Watch — 5th Edition
In a survey of the negative effects and the “erosion” of value on a brand, Tricentis found that, in 2017, consumer tech companies were most vulnerable, with software challenges spanning everything from cost overruns, failures and recurring bugs.
So why aren’t estimations more aligned with the project’s development and parameters?
If failures are occurring consistently, costing companies more than just money — crossing the boundaries into brand equity and power territory — then why can’t we aim to use better estimation methods on projects?
The Cone of Shame
Dog-owners will know how much their furry friends resent the cone of shame.
Software development and estimations are not too fond of the cone either. In our case, it’s the Cone of Uncertainty that hangs, like a dark specter, looming above the commencement of every single project.
Where there should be enthusiasm and anticipation, there is dread. Even though we’re eager to roll up our sleeves and learn from our “past mistakes,” there’s still an edge of uncertainty when we recast our estimations for projects.
In almost 30 years of software development project studies, expert research has concluded that initial estimates on a project can vary as much as four times more or less because neither the estimating team nor the client can yet fully define the scope of the project right at the outset.
In the “waterfall” method (which is the classic approach to development), the Cone of Uncertainty tracks the variance in these estimate-versus-reality scenarios.
As time progresses, a greater amount of the project reveals itself and the scope narrows — which then trickles down to a tighter estimate and a reduction in uncertainty.
Source: Envoc Glossary
But — you knew there was a “but” coming, right? — can we reduce uncertainty to a greater extent and even earlier in the process? Notice that a “reduction” doesn’t have to be an elimination in order to make the project successful.
There are three specific aspects of software development that the brooding Cone of Uncertainty affects:
Consistently “good” products — Maintaining a product or project’s quality requires a particular standard to be set and achieved in a short period of time. Software projects usually have changing features, according to customer needs, and this calls on either a greater level of agility (towards deployment) or more certainty, earlier on in the project’s development.
The requirements of “custom” built software — The Cone of Uncertainty undercuts the amount of foresight and planning that custom software development requires. The latter is more about engineering, where even the foundational building blocks must be custom-built. Integrating these building blocks then initiates multiple possibilities and logical paths to be covered so teams will need to constantly refine these concepts.
The ongoing nature of development —As the Cone of Uncertainty progresses over time, the variance in estimation versus reality reduces. But using the waterfall method also significantly bloats the time that teams spend in the phases of “What are we building?”, “How does it work?” and “What will it look like?”
So we know what those failures look like — but what about success?
In its survey of IT executive managers, the Standish Group’s “Chaos Report” found that, besides user involvement and executive management support, a “clear statement of requirements” (i.e. scope maturity), tied into proper planning can yield overall consistently successful project results.
Source: Chaos Report 2017
The Cone of Uncertainty, however, seems to make even these success criteria seem less than certain.
How can we hope to have more accurate estimations in an ever-changing environment?
Because the consequence is not only a possible failure or a particularly tricky bug that could, as in the case of Provident Financial, a U.K.-based sub-prime loan company, result in a £1.7 billion loss, the largest one-day share price plummet and a CEO resigning over the fiasco.
Factors Affecting Estimations
Now that we know what failure looks like (and, worse yet, feels like), let’s take a look at the factors that affect the estimations on a project.
Massaging the scope into proper maturity
Scope maturity is tied into estimations on software projects. During the planning phase, the development team will need to finalize requirements and think through the requirements from a few different angles.
But the Cone of Uncertainty almost guarantees that designing and anticipating everything up front is almost an impossibility — especially with proper depth.
So what is the solution?
Favoring the incremental approach helps smooth out the development process, making it much more responsive, shortening the initial phases of variance within the Cone of Uncertainty. That’s because the “responsibility” of accurate estimations is spread over the whole development.
In our own experience with developing a web app that models a Digital Transformation Company’s internal processes, we had two parallel goals: to lay down the foundations of a long-term project and to deliver features within hard deadlines.
The custom solution needed to be the only app/tool the business used for internal researching, analyzing and planning. So we allowed the scope to evolve to maturity along the way, using our automated deploy-and-build process.
This bias for agile development is also what enabled our QA team to provide the best quality code for the client.
Concept elaboration
Estimation accuracy relies on more than just scope maturity — it also calls on the elaboration of the concept.
With custom-designed software projects, there is an opportunity, as with digital transformation projects, to use the principles of continuous and iterative building and deploying in order to mature the project in a way that costs less time and cost up front.
But this also calls on developers to have a firm grasp on the concept or specification up front.
This is one factor in estimations that provides more control than others. Teams will no doubt have to perform sprints and rely on breakout sessions to really get to the heart of the concept.
The details uncovered therein for the requirements on a project — such as problem, solutions, features, technical requirements, marketing requirements, etc. — can help anticipate a more aligned budget.
The point is to get as detailed as possible because details uncovered after tells the development team that an estimation was based on basis of flawed assumptions.
Change requests
You may have noticed by now that time is the wily variable that can bog down or uplift a project. Certainly, development teams are always racing against time to capture the right scope and concept.
It’s a reality our team has come across in our over eight years of development and one that especially pitted us against time during a project for Mitt Telenor’s official iOS and Android app.
If the product is set to launch at a specific date, we need to keep CRs at bay and be transparent with the client about how their ever-changing concept puts their project at risk of running well beyond the estimated project numbers.
CRs may well be warranted — but if they’re not anticipated, as agile SCRUM methodology allowed us to do with Mitt Telenor, the project can quickly become “challenged.”.
Source: Chaos Report 2017
Change requests and re-writing code are tasks that fare best in shorter, more responsive sprints.
In the case of Mitt Telenor, these short sprints are exactly what allowed us to uncover issues at an earlier (and more critical) point in development. This then allowed us to keep the development lights on, so to speak, continuing in a more self-aware (or, rather “software-aware”) manner.
The Place of Estimations in the Agile Methodology
To handle these changes and deliver a successful project, both parties (Client & Developer team) are better off with an agile methodology.
Agile allows us to be incremental, responding to a change in business as well as project needs in a more natural way. It’s also easier and more realistic to estimate and then implement changes in small increments, at closer intervals.
Software development is all about change, by its very nature. It is not now, nor has it ever been, a static undertaking. This is why development cannot employ a templated approach, especially in the landscape of digital transformation.
Source: Envoc Glossary
Notice how the Cone of Uncertainty here is significantly leaned out, from its original bloated physique. The result of a consistent diet and exercise? Not in this case. This is the benefit agile methodology brings to the table.
You’ll notice that we’re not claiming that we can simply eliminate or mitigate the Cone of
Uncertainty — no. To do that, we might as well not embark on a development journey at all.
What agile does allow us to do, however, is to drastically reduce the time spent at the initial stages, those questions of:
- “What are we building?”,
- “How does it work?” and,
- “What will it look like?”
And the rest of our time? Well, instead of hemming and hawing, thinking and scratching our heads, only to come up with shaky estimations that are flawed at best and wrong at worst, we can spend our time in our zone of genius: Development.
Indeed, the “development” zone is where our initial estimates are proven or adjusted, requiring less upfront and overall time, and with greater accuracy.
A more aligned estimate and a smoother planning process.
That’s the advantage of agile
