While doing research on projects counted in function points, the sample size was large enough (over 2000 projects) to allow me to compare the productivity of different project types.  The QSM database uses these project categories:

• New Development (> 75% new functionality)
• Major Enhancement (25% - 75% new functionality)
• Minor Enhancement (5% - 25% new functionality)
• Conversion (< 5% new functionality)
• Maintenance

I calculated the normalized PI’s for projects in each development classification compared to the QSM Business trend lines.  The advantage of this is that it takes into consideration the impact of size and shows how the productivity of each project “application type” differs from the QSM Business IT average.  The datasets included medium and high confidence IT projects completed since 2000.  When I obtained the results, I went back over my selection process and calculations to make sure I hadn’t made a mistake.  The numbers were that surprising.  But, no, I hadn’t fat fingered anything (neither physically nor mentally).  Average productivity for conversion projects  was more than a standard deviation below the QSM Business IT average.

When I think about software projects, my memory goes back to the large ones I worked on when I was a developer.  These projects lasted for many months and usually had teams that were divided into sub-teams that worked on specific areas of functionality.  They typically created major systems for the customer.  But was that the normal life of a software developer?  Not really.  Years were spent on production support handling change requests, while the many small projects we completed are now only vague memories.

Recently, for some research I am doing on function points, I worked with a database of over 2000 recently completed software projects. As a byproduct of that research, I was able to come up with a portrait of the “average normal” Business IT project that I would like to share.

• The normal project is not new development.  In fact, only 16% of recently completed IT projects in the database were new development.
• 75% were either major or minor enhancements.
• Median project duration from the beginning of analysis until implementation was 7 months.
• Median effort was 22 person months (or 3520 hours at 160 hours per person month)
• Average staff (team size) just over 3 FTE people.
• Average size – 160 unadjusted function points.

In spite of 30 years of structured programming, CASE tools, OO development, 4th GL languages, CMMI, and PMI, the failure rate for larger projects has failed to respond to all of this love and attention. We normally think of failure as a negative thing; but it can have its upside. Saddling a competitor or enemy with a doomed project could stain their career or at the very least inflict a high level of pain on them. A CEO about to retire, or whose focus is on near term stock options, may be able to boost quarterly profits by continuing to add staff to a doomed effort:  one for which the customer pays for the added staff, of course.

Since failure is a constant, here is a management guide on how to assure failure. While any one step in the process can be overcome, taken together they create the perfect software project storm.

Step 1: Start work as soon as you can

Come on. You don’t really need to spend all that time in requirements meetings and documenting assumptions. Real projects take the ball and run.  Be sure to begin coding as quickly as possible. Call it prototyping if you will; but do get started. You can always circle back to tweak things if needed.

Step 2: Estimation is overhead

Nothing is more frustrating and time wasting as having to go to some external group who know nothing about your project and have them tell you how long your project should take, how many people should be on it, and what the trade-offs are. What can their mathematical models possibly know about your project? A good end run around this situation is to create a project plan and call it your estimate. Make sure that it is very detailed and contains decimal points, since these will make it more difficult to challenge.

The thirty years I have spent in software have bridged a period of remarkable and ever accelerating change. Mercifully, coding an online system on a black and white CRT that accesses an IMS database is mostly a quaint memory. Technology, tools, and processes have all evolved. Why is it, then, that we continue to have the same problems we experienced in the Information Technology Dark Ages? Here are the symptoms:

• Software projects that continue to overshoot their schedules
• Quality problems have neither disappeared nor lessened to an acceptable level
• Budgets are regularly exceeded: sometimes wildly
• Project estimates are inaccurate

I see two principal reasons. I’m certain there are others.

Our Focus on Technology

We are not Luddites resisting change; we love technology and embrace it whole heartedly. We have a rich array of programming and testing tools at our disposal. Why, then, have problems with cost, schedule, and quality persisted?  

One reason is that we focus on technical solutions to problems with many non-technical components. Suppose you have the choice of coding a project in COBOL or Visual Basic. (Suspend your disbelief for a moment and accept that both languages are suitable for the task at hand.) You will produce far less code in VB than in COBOL. You may see some slight reduction in cost and schedule; but it will not approach the 40 – 50% reduction in code that will be seen if you choose VB over COBOL.  

The reason is fairly simple. On a project of any size, coding and unit testing is not where most effort is expended. One number that is touted puts coding/unit testing at 30% of total project effort. This means that a 50% reduction in coding effort yields only a 15% reduction in project effort. While we want and need more effective tools for coding and testing, they have little impact on the remaining 70% of project effort.  

After reading Best Projects/Worst Projects in the QSM IT Almanac, a SLIM-Estimate^® user noted that the Best in Class Projects expended around 28% of their total project effort in analysis and design (SLIM Phase II) compared to 10% for the Worst in Class Projects. She wanted to know how she could tune her SLIM-Estimate templates to build in the typical best in class standard for Analysis and Design.

In SLIM-Estimate, effort and duration for phases I and II are calculated as a percentage of Phase III time and effort. To create a template for estimating phases II and III that will automatically allocate 28% of total project effort to analysis and design (Phase II), follow these simple steps.

• From the Estimate menu, select Solution Assumptions.  Make sure the “Include” check boxes for Phases II and III are selected.  Then click on the Phase Tuning tab.
• Click on the tab for Phase II.  (If you have previously customized the phase names, the default name for Phase II will reflect that).
• Click on the Manual button under Effort, and enter 28% for the effort percent.

That’s it. Your estimates based on this template will now automatically allocate 28% of total project effort to Analysis and Design (Phase II).

This procedure assumes that your estimates will be for SLIM Phases II and III, which, we have found, is the typical scope for most project estimates. However, if your estimates include Phases I and/or IV, you may have to increase the effort percent a bit to achieve the desired result.

"Everything should be made as simple as possible, but not simpler."

-  Albert Einstein

How’s your software measurement program doing?  Is it well funded and supported by management, or do you worry about your job the next time the organization decides it needs to be “leaner and meaner”?  Many measurement programs are cancelled or fade into meaningless obscurity.  Why?  Some things are out of your control; but here are a few that will improve your odds for success:

Seen from an airplane window, the ground looks almost two dimensional.  Only the largest features: cities, rivers, and mountain ranges, stand out against the background.  The true complexity of the terrain only becomes apparent after we land and have to navigate through congested traffic, bad weather, and one-way streets.

Software projects are similar.  Staffing and budget plans are often based on high level requirements that tell us what needs to be done, but not how to accomplish it.  As business objectives are translated into the actions that need to be taken and the work products that must be produced, the size of the project, whether expressed in lines of code, function points, or RICEF objects, increases along with the time and effort required to create them.

This level of detail cannot be seen at the Requirements stage; it is invisible.  But, it can be accounted for and managed.  Software consultant, Capers Jones, has stated that software projects grow 1.5% per month.  A QSM study based on IT projects found that 90% of those projects were larger than they were initially estimated to be.  The average size growth was 15%.  This bias towards size growth was not the result of poor estimating.  At the time the initial estimates were done, the components that accounted for the size growth were simply not apparent.

I'm pleased to make available "Beyond the Hype," a presentation that I delivered at the 2011 Practical Software and Systems Measurement Conference.  "Beyond the Hype" is a metrics-based analysis of Agile development that both confirms some “common wisdom” and contains a few surprises.  Does Agile really have higher productivity?  How does Agile quality compare with traditional development?  What are Agile’s demonstrated strengths and weaknesses?  How can you size and track Agile projects?  Using Agile project data from the QSM Database, "Beyond the Hype" addresses these and other questions about Agile.

Read the full presentation here.