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.