Do you feel your organization is immature when it comes to software development estimation?  Software estimation process maturity isn’t all or nothing! And chances are you’re selling yourself short. Let me share one client’s journey to higher software estimation maturity and the lessons they learned along the way.

A Common Perception

Many organizations don’t feel mature enough to estimate their software development releases and portfolios using something other than a spreadsheet or expert judgement.  That’s understandable to a degree, because spreadsheets are familiar, they are often introduced to us when we first learn about computers. There’s a comfort we feel in the spreadsheet world.  And spreadsheets and expert judgement don’t typically incur any significant extra costs. The overall feeling that their processes are immature is due to the misconception that formal software process assessments are required to validate the good practices already in use.

Making small improvements relative to current practices increases your maturity. To get real value out of accurately estimating software projects — delivering quality features on time and within budget — consider using a software estimation tool that offers objective analytics and insights a spreadsheet cannot.  You don’t have to be very mature to glean the benefits from an estimation tool and your maturity will grow with continued use.

Quantifying software project risk and having a systematic way of accounting for it in software estimates helps firms determine how much contingency (or management reserve) is needed to protect against factors like scope growth, lower than anticipated productivity, or technical challenges that keep teams from executing project plans as originally intended.  When risk mitigation is an explicit part of the software estimate, we can set reasonable client and management expectations and negotiate practical project plans with a higher likelihood of success.

Dealing with Uncertainty

At the time most software estimates are performed, detailed design is incomplete and major decisions about how the system will be designed, coded, tested, and delivered have not yet been made.  Faced with imperfect information, estimators must supply educated guesses – hopefully based on sound requirements and performance data from completed projects - about the final delivered size, productivity, team size, and schedule.  Because the inputs to the estimate are uncertain, the final outcomes are also uncertain.

When we estimate that a project will most likely take 6 months and 8 full-time staff to execute, we really should say, “Based on our analysis and past performance data, we expect the project to take 6 months and use 8 people, but the schedule could vary by as much as 15% and the budget by up to 20%.” But all too often, clients and management expect “single point” estimates based more on optimism than careful risk analysis.

Larry Putnam, Jr. recently presented a short tutorial on the benefits of Top-Down Estimation for Software Projects:

• Top-Down Estimation methods provide the data needed to make early decisions because most software project schedule and cost decisions are made early in the project or product lifecycle 
• Savings Associated with Top-Down Estimation
• Top-Down Estimation vs. Detailed Planning
• Sum of the Parts Don’t Equal the Total Time & Effort Required
• SLIM Software Equation Supports Effective Negotiation

Watch the video or continue reading to learn why the QSM SLIM methodology gets you the data and analytics to make software project commitments with confidence.

Benefit: Provides Data Needed for Early Software Project Cost and Schedule Decisions

What you measure matters! Your data analysis is only as good as the data you are collecting. As a project manager and process improvement consultant, I was so excited when I first learned about QSM's project tracking software, SLIM-Control^®, because product size, quality, and custom metrics are the best metrics to show the true project status.

Mind you, this discovery took place a long time ago when project tracking was primarily limited to data on staff levels, cost, and duration. These measures provided indirect evidence that work was being done, but gave little insight into exactly what work was actually being done and when it would be completed. I remember a large project team at my company that got into hot water because they overran a fixed-priced project by $1 Million!  My process improvement team member said, "You don't overrun by $1 Million overnight!"  There were probably several issues that contributed to this colossal failure, but certainly one was the lack of visibility into the project status or health on a regular basis to help managers and teams identify potential problems and fix them before they became unsurmountable.

With over 45 years of experience in the software estimation field, you might say we know a thing or two about the subject.  This is why we wanted to define key principles with our Software Estimation Basics series. Let's start with a common question we hear a lot: what is a top-down estimate?

What Is Top-Down Estimation?

Top-down estimation is a technique that uses high-level, summary project goals or constraints - scope, cost, schedule, resources, and productivity - to evaluate all possible scenarios to meet a project's goals and the risks associated with each scenario.  Top-down estimation is the best approach to employ early in the project and project portfolio planning process when very little is known.

A common misconception about top-down estimation is that it is used solely to produce a ballpark figure for cost. As we'll explain more in this post, good top-down estimates calculate values for key management metrics, not just cost.

A top-down estimate can be generated by anyone who needs to know a software project's budget, schedule, or staffing - project managers, anyone in the PMO, technical architects, cost analysts, and product owners. C-suite executives can leverage top-down estimates when they need to approve project budgets and schedules.

Software development has always been challenging.  In the digital age, where every company is a technology company, successful business outcomes depend on successful software project outcomes.  A well-designed, flexible software process improvement plan is critical to getting the right technology, people, and practices in sync and delivering at the highest level.

This in-depth guide will teach you everything you need to know about software processes improvement. You will learn critical strategies, like:

• how to to build practices that align with organization strategies,
• how to promote efficiency and quality,
• and how to adapt to business and technology innovation.

Written by industry expert Laura Zuber, this guide shares a wealth of knowledge from Laura's 28 years of experience in software development consulting and early adoption of Capability Maturity Model (CMM) guidelines. Implementing these best practices will help you achieve process maturity at your organization.

Read the guide!

Would you say it's resource capacity planning? Building continuous integration? Knowing if vendor bids are competitive? As a follow up to a recent post I shared on reducing uncertainty in digital transformation, I posed this question to my LinkedIn connections in a poll, giving them options I sourced from respected colleagues with experience in digital transformations. I also asked for suggestions not listed, in case there were challenges I might not have considered.  I appreciated the great feedback I received and wanted to share the valuable insights I gleaned from the poll.

42% voted for “Capacity Planning” as their biggest challenge, 29% voted for “Continuous Integration,” 10% voted for “Vendor Bid Evaluations,” and 19% voted “Other."