Donald Beckett's blog

Donald Beckett's blog

Why Software Projects Confound Business Leaders

Why Software Projects Confound Business LeadersThere is an old adage that if your only tool is a hammer, everything looks like a nail.  We use the lessons learned and experience we have gained to address current issues.  But if the problem (or software project) we face today is fundamentally different from those we’ve dealt with previously, past experience isn’t the proper framework.  In effect, we will be using a hammer when a saw or a chisel might be the tools we need.

The solution, of course, is to first gain an understanding of the problem at hand.  What are its defining features?  How does it behave?  Only then can a proper solution be designed and the appropriate tools selected.

To a large degree, our understanding of how products are developed comes from knowledge gained from manufacturing since the beginning of the Industrial Revolution.  Mentally, our first instinct is to try to apply those lessons learned to software development.  But there is a huge problem with this approach. The creation of software is not a manufacturing process, but rather a knowledge acquisition and learning process that follows different rules.  Here is a simple example.  If I have an assembly line and want to double my output, I have several choices.  I might add a second shift of workers or I could install an additional assembly line.  Because manufacturing is a repetitive process in which design problems are solved before product construction begins, the relationship between labor required and output remains fairly constant.  In a nutshell, we already know exactly what we need to do (and how to do it).  

Blog Post Categories 
Project Management

Is Better Software Productivity Always the Right Goal?

Some years ago, the large systems integrator I worked for brought in a new CEO in an attempt to jump start the company.  We had lost our position as number one in the industry and leadership had become stagnant and ingrown.  The new CEO, who did not have a software background, liked to promise that we could deliver our projects “Faster, Better, and Cheaper."  That sounds wonderful, but is rapid process improvement in three dimensions really possible?  The short answer is “No” – at least not in the short term.  Here’s why.

To deliver a software project faster one of two things has to occur:  

  • Productivity must increase or
  • More effort (cost) must be applied to the project.  

Increasing productivity is a long term strategy that entails improving how the organization works.  It has nothing to do with mandating unpaid overtime or telling developers to “work smarter.”  In fact, those strategies are usually counterproductive.  

Blog Post Categories 

Modeling Uncertainty in Software Development Projects

I am a professional software project estimator.  While not blessed with genius, I have put in sufficient time that by Malcolm Gladwell’s 10,000 hour rule, I have paid my dues to be competent.  In the past 19 years I have estimated over 2,000 different software projects.  For many of these, the critical inputs were provided and all I had to do was the modeling.  Other times, I did all of the leg work, too: estimating software size, determining critical constraints, and gathering organizational history to benchmark against.  One observation I have taken from years of experience is that there is overwhelming pressure to be more precise with our estimates than can be supported by the data.  

In 2010 I attended a software conference in Brasil.  As an exercise, the participants were asked to estimate the numerical ranges into which 10 items would fall.  The items were such disparate things as the length of coastline in the United States, the gross domestic product of Germany, and the square kilometers in the country of Mali: not things a trivia expert would be likely to know off hand.  Of 150 participants, one person made all of the ranges wide enough.  One other person (me) got 9 out of 10 correct.

Blog Post Categories 
Risk Management Estimation

The Problem of Measuring Software Productivity

Measuring Software ProductivitySo, just why do we want to measure software productivity (without using the root word “productive” in the answer)?  I believe that it comes down to the desire to numerically evaluate an inherently complex process so that quantitative comparisons can be made to provide a basis for decision making:

  • Is output per unit of labor or cost increasing or decreasing?
  • Benchmarking against “the industry” or “the competition”
  • Identify practices that either promote or impede increased output and better quality

I’m sure there are many others that could be added to the list.


Traditionally, software productivity has been measured as a ratio between units of output and units of effort.  Simple productivity measures worked fairly well for well defined, repetitive manufacturing processes where a 10% increase in input reliably translates to a comparable increase in output, but there are massive problems with applying simple productivity measures to complex, non-repetitive design processes like software development.

Blog Post Categories 

How to Build Better Software

The problems of software projects are concentrated in three areas: schedule, cost, and quality.  These problems have accompanied software development from the beginning, so they are not new.  Nor have they been ignored.  Huge amounts of thought and effort have been focused on them with unfortunately modest results.  Improvement efforts have been concentrated on management technique (think PMO), process improvement (CMMI, for example), and better tools.  These are all good things, and I can’t imagine embarking on a development activity of any magnitude without them.  However, they have not significantly reduced the incidence of schedule, budget, and quality problems.  Since the problems remain, obviously these remedies have not effectively addressed the root causes of schedule and cost overruns and poor quality.

How to Build Better Software

Blog Post Categories 
Project Management

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.


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 

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

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