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.

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!

I work for QSM, a leading software project estimation and demand management company. We focus on top-down estimation, meaning we figure out the total project duration and effort before any detailed planning occurs. We use SLIM-Estimate also known as the Putnam Model. Larry Putnam Sr. introduced SLIM in 1978. It is one of the leading software estimation tools in the world, validated with over 35 years of industry leading research and updated regularly with the latest technologies. 

Many people call us for help with team size software project estimation, they want to see how many people it’s going to take to deliver a specified amount of functionality within a certain duration and budget. At the time they call us they are often using task level planning tools to try to figure this out. 

The problem is that it’s tough to allocate people and the number of hours they will work when they haven’t figured out the specific requirements of each task and when they haven’t estimated the total duration and effort for the overall system. A manager could spend days creating a task level plan that doesn’t add up to the overall project duration and budget that is needed to deliver the functional requirements. When it doesn’t add up then re-planning has to take place costing more time and money. This is why QSM recommends estimating the big picture first, the scope level. 

Software process improvement efforts often fail because we try to accomplish too much too soon.  Aside from the cultural and organizational obstacles to change, people need time to learn and assimilate new ideas and skills.  “Human memory and comprehension are limited, and it is easy to design processes that are beyond peoples’ capacities,” says Watts Humphrey  (Humphrey, 1989).  This is true in any situation, but I think it is compounded in the software world because time is always a scarce resource.  The pressure is high in every organization to justify process improvement dollars and increase capabilities.

Establishing and maintaining software best practices requires that you design clear processes and plan a pace of implementation that promotes lasting change.  A key component is accommodating human learning and skill development challenges.  Borrowing from a training class I developed 14 years ago (yes, implementing best practices is still a challenge), let’s follow a team of water bugs as they progress through Watts’ four stages of Human Methods Adoption to understand what good pacing requires.

Installation – Initial installation of the methods and training in their use.  Process documentation and training should answer questions like:

A recent article in the New York Times about farm robotics, of all things, made me think about software process improvement.  In the article, dairy farms in New York are beginning to use robotic milkers to feed and milk cows without the use of farm hands.  The solution was born out of several issues for dairy farmers, first, manual labor was hard to come by, and second, dairy prices were soaring.  What farmers needed was cheap, reliable labor; the solution was farm robotics.

In my previous blog post, I discussed the similarities between software and home improvement projects, and how the planning process greatly impacts the project lifecycle.  Better planning in and of itself is a great way to streamline the Construct & Test Phase of development.  However, when you plan is equally important to the development process.

While watching home improvement shows, like Discovery Home’s "Flip That House," one of the primary concerns of the project manager is often how quickly the team can get started so that they can meet their target deadline.  One cringe-worthy line that I distinctly remember was “as long as we have activity, we have productivity.”  Unfortunately, activity and productivity do not necessarily go hand in hand.  

For instance, in software development a project manager may tell a developer at the beginning of a project to start building a system.  If the requirements have not yet been determined, it’s challenging for the developer to build anything.  Yes, it’s possible for the developer to start building something while the project manager decides what should actually be built.  However, once the requirements are finalized it’s very likely that the developer will have to go back and rework the code so that the system will have the desired functionality.