I should be the last one to complain about overstaffed projects; I may owe my career to one.  My first job in information technology (IT) was with a mortgage company that was a textbook example of bad practices.  Annual personnel turnover was 90% and after six months on the job, I was the person on the IT staff with the most seniority.  After a year, I knew it was time to go.  I applied for a job with a large systems integrator that was hiring furiously.  I was drug free, did not have a criminal record, and knew COBOL, so I was a perfect match.  The project to which I was assigned had planned to ramp up to a peak staff of 25 and last about 8 months.  I was team member number 60 of the 80 it eventually grew into by the time it completed (in 18 months).  I stayed with that company for a number of years and have no complaints about the wide range of experiences that I had and skills I gained. 

What is the best way to determine how much staff a software project should have?  QSM has conducted a productivity study on projects sized in Function Points that suggests a way.  A large sample of projects (over 2,000) was split into size bins.  Within each bin the projects were divided into quartiles based on their staffing. The average and median productivity (Function Points per Person Month) were determined for each quartile.  The following table compares productivity and staffing levels for the smallest and largest staffing quartiles.

Having seen incredible growth in our business domestically and in Europe, QSM continues its interational expansion by partnering with RedBay Consulting. RedBay will provide SLIM tool licensing and consulting services, as well as local customer support in the Australia, Asia, and Pacific regions. 

RedBay Consulting is a major provider of Schedule Compliance Risk Assessment Methodology (SCRAM) assessments, which use SLIM as an important component of a schedule compliance review. They help organizations to be more effective in the delivery of their software products and services. Services include consultancy, training and assessment of organizational processes for the acquisition, development and support of software intensive systems. When working on behalf of QSM, RedBay Consulting will conduct business as Quantitative Software Management-Asia/Pacific. 

Read more about this exciting partnership!

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.