Donald Beckett's blog

Donald Beckett's blog

Are Your Software Projects Too Small?

We hear a lot about software projects that are too large or attempt to do too much in too short of a time.  They are very visible and negatively impact both budgets and careers in a not positive manner when they fail.  Small projects may fly under the radar.  This is a mistake.  Most IT projects aren’t large undertakings like Healthcare.gov; rather, they are enhancements and customizations to already existing software systems and account for the majority of most enterprises’ software budget.  Planning these projects to be optimally productive is an area in which most companies can realize the greatest returns.

How do you know what is the optimal amount of software to develop in a project?  In a newly published software benchmark study QSM analyzed productivity, cost/effort, and time to market of a large sample (over 600) of business IT projects that have recently completed.  The projects were divided into quartiles based on the amount of software they developed or customized, which were then compared to each other.  Fully ¼ of the projects were smaller than 3,200 implementation units in size or 68 function points for projects that used that size measure.  Projects in this quartile had a median productivity of 200 IU per staff month or 5 function points per staff month.  The median duration of these projects was slightly more than 3 months. The second quartile contained projects from 3,200 IU up to 8,000 (or 69 to 149 function points).  These projects had a median productivity of 377 IU per staff month (or 7.62 function point per staff month) and lasted a little more than 5 months.  This is a productivity improvement of 89%.  The smaller projects were markedly less productive.  So, simply by bundling software work into larger packages there are significant efficiencies to be gained.

Blog Post Categories 
Estimation Sizing Productivity

Estimating Program Increment Capacity in Scaled Agile (SAFe)

Scaled Agile (SAFe) is a methodology that applies Agile concepts to large complex environments.  QSM recently worked with an organization that had implemented SAFe to develop an estimation methodology specifically tailored to it.  This article discusses how it was implemented.

Software estimation typically addresses three concerns:  staffing, cost/effort, and schedule.  In the SAFe environment, however, development is done in program increments (PI) that in this case were three months in duration with two-week sprints throughout.  Staffing was set at a predetermined level and varied very little during the PI.  Thus, the three variable elements that are normally estimated (staff, cost/effort, and schedule) had already been determined in advance.  So, our job was done, right?  Wrong!  What remained to be determined was capacity:  the amount to be accomplished in a single PI.  And that was a very sore “pain point” for the organization. 

Blog Post Categories 
Agile Estimation Capacity Planning

Software Project Size and Road Construction

Software Project Size and Road ConstructionI have been a software project estimator for 20 years.  Like many people who have worked a long time in their profession, I find myself applying my work experience to other events in my life.  So, when a family member tells me that he or she will be back from a trip into town at 3:30, I look at their past performance (project history) and what they propose to do (project plan) and add an hour.  Usually, I am closer to the mark than they are.

Blog Post Categories 
Software Sizing Estimation

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 
Productivity

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.

Issues

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 
Productivity

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.

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