Now that it’s officially summer I’ve been feeling the pressure to do some of the home improvement projects that I’ve been putting off since winter.  I figured watching one of those cable shows about flipping houses would inspire me to get started.  But instead, I started thinking about all the parallels between the show and software projects.

In our training classes, we often make the analogy that software projects are like construction projects.  When you start a project, you need to determine its scope.  That would include how big it is and how much functionality it will have.  You need to determine what resources are available to you.  This includes what tools you have to build your project, the number of people available, their skill levels, and your budget.  You also need to determine how much time you have to complete this project and the level of quality you’re willing to accept.

This particular episode began as most home improvement shows do.  A team of overly ambitious stakeholders with limited construction knowledge decide that they are going to flip a house because it’s all the rage this year.  They do some calculations based on the costs of acquiring, renovating, and maintaining the property, which determines that the house needs to sell in 60 days or else they will lose money.  Already, we’re looking at a high risk project.  

They hire a team of carpenters and contractors to start the work, but during the initial survey of the property they discover that the scope of the project is not possible given the allotted schedule or budget.  The team then engages in a series of spirited discussions about which features they can cut without compromising the overall quality of the house.  The remainder of the episode is then spent watching the team rush to finish the project on time.  

Database validation is an important step in ensuring that you have quality data in your historical database.  I've talked before about the importance of collecting project data and what you can do with your own data, but it all hinges on having thoroughly vetted project history.

Although it's nice to have every tab in SLIM-DataManager filled out, we really only need three key pieces of information to calculate PI:

• Size (Function Unit): if the function unit is not SLOC, a gearing factor should be provided (97.3% of projects in the database report total size)
• Phase 3 duration or start and end dates (99.9% of projects in the database report phase 3 duration)
• Phase 3 effort (99.9% of projects in the database report phase 3 effort)

These fields can be thought of as the desired minimum information needed, but even if one is missing, you may not want to delete the project from the database. A project that is missing effort data, for instance, will not have a PI but could be used to query a subset of projects for average duration by size. Likewise, a project with no size will not have a PI, but does contain effort and duration information that could be useful for calculating the average time to market for a division. However, if possible, it is a good idea to fill out at least these three fields.

If you were unable to attend "Building an Estimation Center of Excellence," the webinar replay and slides are now available. Here are the Q&A highlights:

How do you handle estimating change requests (scope creep). Do you estimate the entire project again, or do you just estimate the impact of the change requests?

It would depend on where we were in the project lifecycle. If we were still fairly early on (somewhere between the feasibility assessment and the refined estimate), I would add those into my sizing assumptions and re-estimate the project. If I'm already farther along and I get changes when I'm already constructing the system, then I would use my adaptive forecasting and add those in within the context of everything else I have to build as part of the deliverable release. This is because the impact will be bigger if we're farther along and we already have everything integrated and we're into testing versus earlier on when not a lot has been constructed. QSM's forecasting capabilities will be able to tell us the impact on schedule and cost.

Should the center of excellence estimate all projects regardless of size, or if the project is small, then have the project teams estimate it?

The latest version of QSM’s Performance Benchmark Table is live!

QSM is excited to announce the release of their latest version of the Performance Benchmark Table.  Last updated in 2009, the table provides a high-level reference for benchmarking and estimating IT, Engineering, and Real Time Systems.  It displays industry average duration, effort, staff, and SLOC (or FP) per Person Month for the full range of project sizes encompassed by each trend group. 

The results were analyzed from a database of 1,115 high or moderate confidence projects completed between 2008 and 2012.  Sixteen countries and 52 different languages were represented in this sample.  In addition to the industry average, minimum and maximum values were also provided for each metric to help give a range of possible results.

The project sizes differed somewhat from the previous version to accommodate the new range of sizes present in the data.  Rather than using the same project sizes across trend groups, we selected project sizes specific to each trend.  Since Business projects are typically smaller than Engineering or Real Time projects, this allows readers to select a size relevant to the type of project they’re estimating or benchmarking.  

This tool can be particularly useful to developers and/ or project managers who are new to estimation or do not have historical project data.  

In the previous articles in this series I presented SLIM-Estimate’s use of uncertainty ranges for size and productivity to quantify project risk, and how to build an estimate that includes contingency amounts that cover your risk exposure.  In this post I will identify the project work plan reports and charts that help you manage the contingency reserve.  You will see how to use SLIM-Control bounds and default metrics to keep your project on track. 

Understand the project work plan documents.

In our example so far, you have estimated a project to deliver a software product in 11.7 Months, with a budget of $988,223.  This estimate includes an 80% contingency reserve, or risk buffer, on both effort and duration.  Your work plan is based upon SLIM-Estimate’s 50% solution; 11 Months and $755,400.  Thus, the uncertainty about size and productivity are accounted for; it is built into your plan.  The probability that you will meet the project goals is driven by many factors ‒ too many to measure.  You can only manage what is within your control, and escalate issues so they can be resolved in a timely manner.

Managing the project well begins with a solid understanding of the detailed project plan.  SLIM-Estimate provides several default and customizable charts and reports that document the plan.  Here are a few key reports¹ to study in order to identify the core metrics you will want to monitor closely.

On Thursday, June 13, at 1:00 PM EDT, Larry Putnam, Jr. will present Building an Estimation Center of Excellence.

The pressure to succeed in software development is higher than ever - the current economic climate demands we do more with less, there is fierce global and domestic competition, time-to-market expectations are high, and your company's reputation is on the line. When projects fail, the failure to meet expectations is more often an estimation or business decision failure than a production or execution issue. In this webinar, industry expert Larry Putnam, Jr. takes you through the key elements and step-by-step process for setting up an estimation center of excellence that will ensure your projects succeed.

Larry Putnam, Jr. has 25 years of experience using the Putnam-SLIM Methodology. He has participated in hundreds of estimation and oversight service engagements, and is responsible for product management of the SLIM Suite of software measurement tools and customer care programs. Since becoming Co-CEO, Larry has built QSM's capabilities in sales, customer support, product requirements and most recently in creating a world class consulting organization. Larry has delivered numerous speeches at conferences on software estimation and measurement, and has trained - over a five-year period - more than 1,000 software professionals on industry best practice measurement, estimation and control techniques and in the use of the SLIM Suite.

Watch the replay!

Several months ago, I presented SLIM-Estimate’s use of uncertainty ranges for size and productivity to quantify project risk.  Estimating these two parameters using low, most likely, and high values predicts the most probable effort and time required to complete the project.  This post shows you how to use SLIM-Estimate’s probability curves to select the estimate solution and associated work plan that includes contingency amounts appropriate to your risk.

Begin with an unconstrained solution

The default solution method used for new estimates, whether you are using the Detailed Method or another solution option, is what we call an unconstrained solution.  Just as it sounds, no limits have been placed on the effort, schedule, or staffing SLIM-Estimate can predict.  It will calculate the resources required to build your product (size) with the capabilities of your team (PI).  Assuming you have configured SLIM-Estimate to model your life cycle and based your inputs on historical data, you have produced a reasonable, defensible estimate.