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.  

That leaves us with the second choice: apply more effort to reduce the schedule.  Does this work?  The honest answer is “Not the way we would like it to work”.  Ideally, we would like effort and schedule to trade off evenly.  So if our software project plan calls for 6 persons to complete the work in 7 months, we could assign a seventh developer to the project and complete it in 6 months.  Unfortunately, the relationship between schedule and effort is not linear: one unit of schedule reduction requires many additional units of effort.  While it may be possible to reduce the schedule by a month, it will require more than one additional body, thus increasing the overall software project cost.  Quality will likely suffer, too.  More people needing to communicate with one another in a shorter period of time is a perfect recipe for more defects.

So, what should a business leader do?  Here are some suggestions.

• Determine what is possible.  Using a parametric software estimation tool, model the project to determine the industry averages for staff and schedule.  In addition, find out how much variability there is around each parameter.  The best way to do this is to use your own project history which is a record of your capabilities.  Whatever staffing and scheduling strategies you decide upon, make sure that they remain within your demonstrated capabilities.
• Identify the primary project constraint and plan accordingly.  If schedule is most important to you, be prepared to compromise on cost and quality. If cost is most important, be prepared for the project to take longer (bonus: software quality generally improves in this scenario).
• Avoid wishful thinking.  Every project contains some unknown factors that will affect performance.  Your project plan should have enough uncertainty buffer in both schedule and cost to accommodate some bumps along the road.  Never make a best case scenario your project plan.

So, is better productivity the right goal?  In the long term, yes.  In the short term, if reduced cost is the most important consideration, higher productivity can be achieved with a lean staffing strategy and longer time to market.  If, however, time to market is your key driver, be prepared for the lower productivity and higher cost that this strategy entails.  Just be sure to keep that schedule within the boundaries of your demonstrated capabilities. 

The graphic above illustrates the relationship between schedule, cost, and quality.  Note that there is no place where all three overlap.  You can pick any two, but they will determine the third variable.  The new “turnaround” CEO could never accept this.  His tenure was tumultuous and he left the company in worse shape than he found it.