One thing that I hear from project managers on a regular basis is that estimating a software project is a really tough thing to do. I have to tell you that it doesn’t have to be that way. Here are some reasons why project estimation can be easier than you think.
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.
QSM is pleased to announce the release of a new book, Understanding Software Estimation, Negotiation, and Demand Management: An Executive Primer. Historically, only 20% of software projects are completed successfully and with software becoming critical to nearly every company and industry, having such a high rate of failure is simply unacceptable anymore. It is for this reason that QSM has compiled this collection of articles that will aid anyone from project managers to CIOs in implementing software estimation, negotiation and demand management methods efficiently to reduce costs.
Larry Putnam, Sr., founder of QSM and a pioneer and top problem solver in the software estimation and measurement field, provides the foreword to the book, which is co-authored by his son and granddaughter, Doug Putnam and Taylor Putnam-Majarian. Combined, the authors bring more than 40 years of experience in software measurement to a range of topics, including:
While creating estimates is a fundamental step toward improving productivity on software development projects, it is not enough. In "Full-Circle Estimating," recently published on Projects at Work, Doug Putnam and Taylor Putnam-Majarian present a full-circle model that organizations can apply to track actual performance against estimates, reforecast when significant changes occur, and then continually refine the process through post-mortem assessment.
Doug Putnam is co-CEO for Quantitative Software Management (QSM). He has 35 years of experience in the software measurement field and has been instrumental in the development of the SLIM Suite of software estimation and measurement tools. C. Taylor Putnam-Majarian is a consulting analyst at QSM with over seven years of specialized data analysis, testing and research experience. In addition to providing consulting support in software estimation and benchmarking engagements to clients from both the commercial and government sectors, Taylor has authored numerous publications about Agile development, software estimation and process improvement.
I have been a software project estimator for 20 years. Like many people who have worked a long time in their profession, I find myself applying my work experience to other events in my life. So, when a family member tells me that he or she will be back from a trip into town at 3:30, I look at their past performance (project history) and what they propose to do (project plan) and add an hour. Usually, I am closer to the mark than they are.
Focused on planning for software projects, this IEEE presentation by Keith Ciocco explains some of the key components of a successful estimation process. This is a summary level view focusing on the importance of leveraging historical data, sizing, and measuring productivity when estimating at the organizational and project level. This presentation includes a demonstration of the SLIM Suite of tools to show how we can automate and streamline the estimation process.
Beginning with the release of SLIM-Suite v8.1, two new SLIM-Estimate solution methods were added to let you see what a “typical” project would look like: that is, the resources it would require, based upon historical projects from either the QSM database or your own. The two methods are:
- Solve from Trends Wizard
- Trend Based Solution
SLIM-Estimate provides several different ways to solve the software production equation and produce an estimate. The solution method you select depends upon the information you have available. The traditional methods, known as Quick Estimate Wizard and Detailed Method, take inputs of Size and Productivity (PI), and calculate Effort and Time. The Solve for Size Wizard, perfect for time-boxed estimates, takes inputs of Time, Effort, and PI, and determines the amount of functionality that combination of resources can produce.
The trend solutions require only one input – Size. Using the specified Primary Trend Group, Time and Effort are read from the average trend line and productivity (PI) is calculated. These methods extend the capabilities of producing a defensible project estimates very early in the life cycle. You can determine the feasibility of project goals, assess risk, and manage stakeholder expectations even if all you can estimate is a relative application size, expressed as a “T-shirt” or bin size, as shown in the figure below.
When an organization wants to proactively manage their software activities from inception through development and sustainment, an enterprise software estimation or acquisition Center of Excellence (COE) is a great solution. A significant portion of our professional services business at QSM is helping companies design and stand up enterprise COE operations.
There are three main components to a successful COE implementation. They are:
- People – Finding people with the right characteristics and developing their skills;
- Business Processes – developing the right business processes to support decision making; and
- Tools – Acquiring and configuring analytical tools to support the business processes.
Our clients often ask us to identify the best characteristics and skills for a person that they plan to staff into a COE. We went back and looked at our most successful implementations, and here is what we found.
Ideal Enterprise COE Skill Set:
Software size, the amount of functionality in a given software release, is arguably the most important of the five core metrics of software estimation. There is little point in tracking effort, duration, productivity and quality if you are unable to quantify what you are building.
Yet, despite its critical importance, software sizing is often a difficult concept for many to understand and use properly in the estimation process. Sometimes a picture is better than 1,000 words. With that ideal of visual simplicity in mind, we developed a software sizing infographic that helps explain:
- Why we care about size
- Challenges in sizing
- When size should be measured during the software development life cycle (SDLC) to narrow the cone of uncertainty
- The difference between functional and technical size
- The most popular sizing methods and when to use them
The infographic begins by introducing the five core metrics of software estimation (size (scope), schedule (duration), effort (cost), quality (defects) and productivity) and the nonlinear relationship between them.
At QSM, we have one of the largest industry databases in the world of completed software projects. The data comes from our clients with their permission and this data has been the backbone of our software estimation business for over 35 years. We can see what is reasonable on software development projects as it relates to cost, team size, effort, duration, size, and reliability. Because of our experience we are often asked about risk factors and estimation accuracy early in the project lifecycle. We explain that increased accuracy comes with having historical data and good sizing information.
But what happens on the early estimates when clients don’t have history and detailed sizing information? Can they still generate scope level estimates so they can make good business decisions? The answer is yes. Risk management techniques can be applied and project uncertainty can be calculated so organizations can plan effectively. This is very important because big business decisions are often made early. Decision-makers need to know if they should move forward with a project and they need to know how much time and effort to allocate.
We use SLIM-Estimate, which is a leading estimation tool that leverages the Putnam Model. It generates reliable estimates based on QSM’s time-tested forecasting models and historical data and it also provides scope level estimates when project information is hard to find. It will allow you to see the chance you have of hitting your project goals and it will allow you to factor in your uncertainty.