Estimation return on investment - a hotly debated topic in some circles, but still a very active and frequent conversation in C levels all over the world. Something that hasn’t changed in the 20+ years I’ve been involved with estimating software development, regardless of methodology, has been the question asked by senior leadership when embarking on developing new functionality - “How much will it cost and when can we deliver?” Despite the emergence of new methodologies, this question is understandably the main driver of whether to proceed with a project or not. The ROI I am focusing on here is the IT budget we are committing to building a project, or portfolio of projects. Very often, we are faced with that question very early on, when we know little about the project’s full intended capability, but the C level is asking for an estimate and we better respond with a defendable answer.
The ROI is realized in several ways - firstly in the form of estimating the appropriate staffing levels. We have often assisted clients who initially estimated their projects with too many FTEs. A relatively simple tweak to the staffing skills combined with empirical data for effort calibration can prove, in many cases, that the FTE count is too high. In the graph below, the yellow diamond represents our current estimate compared to the green dot (adjusted estimate) resting on the blue trendline in the middle representing the industry average for staffing vs. size. Properly adjusting the FTE levels can save thousands, even hundreds of thousands of dollars depending on the project size, and millions of dollars across a portfolio.
Secondly, an ROI opportunity is committing to an appropriate schedule. In the graph below, we see the gold colored circle is the estimate we created based on the business stakeholders assumption for duration. The green circle resting on the trend line shows the industry average for a schedule of this project type. In this scenario, we are saving almost two months of time, thus, much money.
Thirdly, in development shops that work with fixed teams and schedules, we can calculate the amount of functionality possible within a fixed number of sprints or program increments. In the view below, we can see the sprint lines at the top of the view within two program increments showing 231 story points can fit into 10 sprints. If the business is asking for more functionality with the same duration, we can tell them it is not possible, thus avoiding an unrealistic expectation, which would have cost more money in the end.
Finally, we can apply the same technique across our portfolio of projects making the ROI exponential. The view below shows our portfolio of estimates plotted on a quadrant chart with the green shaded area in the middle representing our desired performance (in this case productivity and duration). The project estimates on the lower right hand of the graph indicate low productivity and longer schedules. By adjusting the staffing and/or the size of those projects, we can make them more productive and subsequently less costly. Conversely, the upper left hand of the graph shows high productivity and shorter durations, which perhaps means they are overly ambitious and another opportunity to rein in a costly mistake before it happens. And with those savings, we could take on more projects.
In the end, we all want to confidently commit to a defendable estimate that we know will yield an ROI. To learn more about how our estimation tools and consulting services can help you, contact us.