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.

Project managers and estimators have long struggled with the issue of how to measure software size. Really, before you can calculate cost and schedule, you will need some notion of how big the project will be. There are myriad of ways to size a project depending on the methodology you use and where you are in the planning process. Here at QSM, it's one of the common questions we receive, so we've devoted many years of research to the topic. Our website features a wealth of resources on sizing and in this post, we will highlight a few of the most valuable for anyone grappling with this issue or looking for a place to start.

General Sizing

• QSM's Software Sizing infographic is a great place to start. This easy to understand visual resource helps explain the most popular sizing methods and when to use them, the difference between functional and technical size, sizing challenges and more!
• Measuring Software Size - Insights from the Past to Guide the Future is another helpful guide if you're struggling with which sizing units to use. This PDU-approved webinar will help you determine what sizing measure will work for you based on your own historical data. This presentation is worth a watch no matter what development methodology you use and can help improve future estimates and in-flight project forecasts.

Function Points

Stripped down to the bare bones, value in software estimation measures the functionality that a software product provides to its users (both human and non-human) while production cost measures not just value but the work that is required to deliver that functionality. Software estimates need to account for both. Examples of non-functional cost items include configuration, throw-away code, cloud architecture, and quality requirements. Size measures such as IFPUG and NESMA function points quantify value (delivered functionality) and are recognized as functional size measures. Both measures intentionally ignore technical requirements. They can be very useful when used for asset management, measuring scope creep on a project, or assessing software quality (defect density per delivered unit). For estimating they are an important input; but one that needs to be supplemented to reflect the non-functional cost factors: i.e. what needs to be done behind the scene to create that functionality.

If you were unable to attend our recent webinar, "Increase PMO Collaboration to Improve IT Portfolio Management," a replay is now available.

IT project portfolios are diverse - technologies, platforms, methods, resources and more! Ensuring that project priorities align with business strategies and resource demand requires project intelligence and better estimation capabilities. Join Keith Ciocco and Laura Zuber for this PDU-approved webinar to learn how to leverage centralized data about scope, capacity, cost, staffing and quality to explore estimate solutions that overcome common PMO challenges of shrinking budgets and scarce resources. See how tailored access and process workflow increase visibility and provide the tools for effective project prioritization, review and governance.

Watch the replay!

IT project portfolios are diverse - technologies, platforms, methods, resources and more! Ensuring that project priorities align with business strategies and resource demand requires project intelligence and better estimation capabilities. Join Keith Ciocco and Laura Zuber for this webinar on Thursday, Oct. 22 at 2:00 PM EDT to learn how to leverage centralized data about scope, capacity, cost, staffing and quality to explore estimate solutions that overcome common PMO challenges of shrinking budgets and scarce resources. See how tailored access and process workflow increase visibility and provide the tools for effective project prioritization, review and governance.

Register here!

During a recent consulting engagement, a customer asked if the QSM defect discovery model applied to Agile projects.  Of course, the best (and only) way to determine this was empirically.  From our database we extracted a sample of business IT projects that had completed since 2013 that recorded pre-implementation defects.  81 of these projects were Agile and 354 did not specify Agile as their development methodology.  We created average trend lines for both datasets and they displayed very similar patterns that conformed to the QSM defect discovery model.  This allowed us to answer our customer’s question affirmatively.

Having a large project sample at hand and being curious, we decided to compare these metrics:

• Mean time to defect (which measures the average time a system runs defect-free in the first month after implementation)
• Average development time in months
• Staffing
• Cost/effort

In a nutshell, the Agile and non-Agile projects used very similar staff sizes.  The Agile projects completed sooner and expended slightly less effort.  Quality was where the two project sets differed significantly.  Pre-implementation, Agile projects recorded fewer defects than non-Agile ones.  However, post-implementation the non-Agile projects operated longer between discovering defects in production than did Agile projects.

If you were unable to attend our recent webinar, a replay is now available.

Agile methods have brought vast improvements to software development practices, but as with any process, still pose many implementation challenges. Estimating, planning, and tracking Agile projects is particularly difficult because the formality, consistency, and repeatability of Agile practices vary widely across organizations. In this PDU-approved webinar, Laura Zuber shows how macro level metrics gathered for completed projects and used as the basis of estimation and project control promote repeatability and predictability. Learn how SLIM-Suite tool’s customizable modeling parameters, such as Agile increment lines and sizing techniques, let you balance the needs of teams and the business.

Watch the replay!

Agile methods have brought vast improvements to software development practices, but as with any process, still pose many implementation challenges. Estimating, planning, and tracking Agile projects is particularly difficult because the formality, consistency, and repeatability of Agile practices vary widely across organizations. In this PDU-approved webinar presented Thursday August 13 at 1 PM EDT, Laura Zuber will show how macro level metrics gathered for completed projects and used as the basis of estimation and project control promote repeatability and predictability. Learn how SLIM-Suite tool’s customizable modeling parameters, such as Agile increment lines and sizing techniques, let you balance the needs of teams and the business.

Register now!

The onset of COVID-19 has revealed many dependent synergies in the world and their mutual effects on one another.  For example, the decrease in human consumption of fossil fuels, not as many cars on the road nor planes in the air has reduced carbon emissions resulting in cleaner air, at least for the time being. 

Another synergistic COVID-19 result affects the IT world, including estimation of software delivery.  Many organizations wisely instilled a work from home (WFH) policy to mitigate the potential spread of disease.  This new work format introduced a fascinating human experiment – can we be as productive en masse during a WFH situation as opposed to being in the office?  The lack of physical proximity stresses the importance of fluid and effective communication.  During pre-COVID-19 days, estimating software delivery was orchestrated through meetings in hallways and conference rooms to communicate project assumptions, constraints and lobbying for project expectations.  But post-COVID-19, we are reliant on remote/virtual contact, limiting the nuances of physical meetings.  Thankfully, there are capabilities in place to make this a fluid process within our SLIM-Collaborate solution. 

Imagine a software development process where “Big Picture” estimates can be generated before detailed planning takes place, where the estimates can be accessed on the web, and where only three or four inputs are needed to generate reliable information. This process would include intelligent models that take into account historical data and there would be a back office team that specializes in software customization available to do the heavy lifting. Finally, there would be business analytics and industry data (plenty of both) to help with project target negotiations and risk trade-off analysis.

Thankfully, there are science-based estimation solutions available that include the capabilities mentioned above. These packages can make estimation easier, more transparent, and help manage the uncertainty that can come with early planning. There are technology organizations that are using these types of tools to improve their time to market and the accuracy of their software development estimates.

But there are many organizations that still struggle with estimation. They spend millions of dollars each year developing and delivering software. The planning usually starts with senior management asking tough questions about cost and schedule targets. The project leads then try to come up with effort estimates for each person on the project based on experience and gut feel. These effort numbers are tallied up in spreadsheets to come up with an overall estimate, the numbers are usually negotiated and then a final estimate is born. The problem with this process is that it takes a long time to carry out and the estimates are usually inaccurate. This is because the methods don’t take into account the non-linear relationships, integration, and overhead that we often see in software development.  When the estimates are off, millions of dollars are spent trying to change course. The rest is history.