Donald Beckett's blog

Donald Beckett's blog

The Laws of Software Staffing

Frederick Brooks famously said that adding staff to a late project only makes it later.  The reasons are readily apparent.  The project is already experiencing difficulties, most of which were not caused by understaffing.  The usual culprit is an unreasonable schedule constraint; but starting work before the requirements were well defined, poor change control, or weak configuration management could also be the villains (or at least play a contributing role).  None of these root causes is staff related and adding staff does not fix them: it merely adds more bodies to the confusion.

But, how do we determine the most appropriate staffing profile for a software project?  Parametric estimation models suggest a way: these models have determined that there is a relationship between the functionality that a project delivers (called size in the software estimation vernacular) and staff.  Fitting a regression line through hundreds or thousands of software projects determines an average and deviation from that average. The regression is a reflection of how software projects have performed.  This is what has worked.  This capability is built into estimation software like SLIM-Estimate.  A wise approach is to take the average as a starting point, then adjust the modeling parameters that would increase or lower the staff.  A word of caution here: if you find that your adjustments cause staff, effort, or duration to be more than 1 standard deviation above or below average, you are probably being either too optimistic or pessimistic.  Don’t do it! 

Blog Post Categories 
Team Size

Schedule, the Eternal Enemy

“More projects have gone awry for lack of calendar time than for all other reasons combined” - Frederick Brooks, The Mythical Man-Month

These words were penned by Frederick Brooks in “The Mythical Man-Month” over 35 years ago.  Think back to that time for a moment.  The first personal computers were being born as kits assembled by electronic hobbyists.  Serious programmers considered them to be toys.  A good knowledge of COBOL could get you a job just about anywhere.  Computers and IBM were virtually synonymous.  Structured programming was the process improvement silver bullet of the day.  Something called ARPANet, the parent of the Internet, had come into existence.  And software projects experienced serious problems because they weren’t given enough time to complete and test their work.  Everything has changed except for the last item.

Why?

Over this span of time a host of solutions have been attempted with very modest results.  Only the elephant in the living room has been ignored:  since project schedules are chronically and habitually underestimated, why not allocate more time to them at the outset?  The reasons for doing so are compelling:

Blog Post Categories 
Schedule

Staff That Project!

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.

Productivity Rates

Blog Post Categories 
Team Size

Let's Get Serious About Productivity

Recently I conducted a study on projects sized in function points that covers projects put into production from 1990 to the present, with a focus on ones completed since 2000. For an analyst like myself, one of the fun things about a study like this is that you can identify trends and then consider possible explanations for why they are occurring. A notable trend from this study of over 2000 projects is that productivity, whether measured in function points per person month (FP/PM) or hours per function point, is about half of what it was in the 1990 to 1994 time frame.

Median Productivity

 1990-19941995-19992000-20042005+
FP/PM11.1179.215.84
FP/Mth17.163.929.7422.10
PI15.316.413.910.95
Size (FP)394167205144

 

Part of this decline can be attributed to a sustained decrease in average project size over time. The overhead on small projects just doesn’t scale to their size, thus they are inherently less productive. Technology has changed, too. But, aren’t the tools and software languages of today more powerful than they were 25 years ago?

Blog Post Categories 
Productivity Project Management

Haste Is Expensive

Large companies often seem to have a few people in key positions with extra time on their hands. Occasionally, this time is used to invent acronyms that are supposed to embody corporate ideals. Mercifully, these usually fade away in time. A former employer of mine had two beauties: LOCOPRO (Low Cost Provider) and BEGOR (Best Guaranteer of Results). Unfortunately, besides being grating on the ear, LOCOPRO and BEGOR don’t always march in tandem. LOCOPRO deals with cost and the effort required to deliver something. BEGOR is a bit more amorphous dealing with quality and an organization’s efficiency and consistency in meeting requirements.

What are the normal requirements for a software project? Here’s my short list.

  • Cost. What is being created and delivered has to be worth the expense in the mind of the person or organization that is funding it. (LOCOPRO is good)
  • Schedule. The timeframe in which a project creates and delivers its software is frequently a key constraint. Meeting this is important. Consistency and predictability (BEGOR are good)
  • Quality. In Business IT systems this is often an implicit requirement that is most noticed when it is absent. Real time, telecommunications, military, and life support systems are more frequently developed and tested to explicit quality standards.

The mantra of Faster/Better/Cheaper captures most organizations’ desires for Cost, Schedule, and Quality – all at the same time. If only the laws of software would cooperate! But they don’t. Software is like a balloon. You constrict it in one place (schedule, for instance) and it expands in another (cost). The problem isn’t going to disappear; but by prioritizing requirements, conscious and realistic tradeoffs can be made.

Blog Post Categories 
Schedule

Why Are Conversion Projects Less Productive than Development?

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.

Blog Post Categories 
SLIM-Estimate Function Points Database

Process Improvement and the "Normal" Project

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.

While there is nothing earth shattering in these numbers, I saw a disconnect between the typical, relatively small project and massive lifecycle methodologies and process sets, such as CMMI, that are designed for BIG projects.  These processes and methods usually make some effort to be scalable; but the time and effort required to understand and scale them appropriately is a significant endeavor all by itself!  

Blog Post Categories 
Function Points Process Improvement

Seven Steps to Software Project Failure

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.

Blog Post Categories 
Risk Management Program Management

Why Do We Keep Having the Same Problems?

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.  

Blog Post Categories 
Program Management

Tuning Effort for Best in Class Analysis and Design

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.

Blog Post Categories 
SLIM-Estimate Tips & Tricks Effort