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.

Table 1

Conversions are often undertaken with the idea of reusing existing processes and functionality rather than re-inventing (and debugging) them.  The objective is to save time and money while taking advantage of existing processes.  While the intention is admirable, conversions are not always time and money savers.  Here are a few of the confounding factors that should be considered before embarking on a conversion project.

• The staff that developed the system you want to convert may no longer be available.  In fact, the actual work you are planning may be done in another country by a team that has no previous exposure to the system.  When application knowledge is minimal, the conversion team will spend a lot of time understanding how the current system works.  Being human, they’ll make a few mistakes, too.
• Application documentation, if it exists at all, may not be current.  New teams with minimal application knowledge may have few resources on hand to help them gain that knowledge.
• While the business processes may be the same, their technical implementation on another platform may differ significantly.  You will know what you want to accomplish; but how to do it still has to be fleshed out.
• Applications are developed around the available technology.  The system you are converting does things in ways that may not make sense (or even be possible) on the target system.  Some processes will have to be rewritten.  At this point you are developing, testing, and integrating new code with an existing system. 
• Changes will creep in.  One of the best reasons for converting to a newer technology is to take advantage of the features it offers.  You probably don’t want your new web-based system to mimic the touch and feel of the IMS-COBOL one it is replacing. 

All of these factors can reduce productivity and should be addressed honestly before beginning a conversion.  

To illustrate this, I modeled both the development and the conversion of a 500 function point project in SLIM-Estimate.  I used an average productivity factor (PI) for the development project and a PI that is standard deviation below average for the conversion project.  I assumed 25% re-use for the conversion project which lowered the actual function points being developed to 375.  A labor rate of $10,000/person month was used for both projects.  The results are captured in the following table.

Table 2

While the assumption of 25% re-use is arbitrary, it illustrates that a significant part of the functionality will not have to be redeveloped in the conversion project.  However, in this example the lower productivity of the conversion project offsets this and cost, schedule, and effort are all greater than on the 500 function point development project.

What does this all mean to a software project estimator?  While development projects are demonstrably more productive than conversions, he or she needs to keep in mind how that productivity is determined.  Parametric estimation tools like SLIM-Estimate use the amount of software that is developed or modified as the size basis for determining productivity.  If function points are used, this would consist of added, changed, and deleted function points.  

Ideally, in a conversion project a great deal of the functionality is not modified and would, therefore, not be counted as part of the project size.  As a result, a conversion project may deliver significantly more functionality than is accounted for in traditional productivity measures.  

The decision to convert or redevelop a software system needs to account for the total amount of functionality that will be delivered.  A good way to compare the alternatives in SLIM-Estimate is to create a scenario for the development project based on developing all of the functionality that will be converted using an average productivity index (or one that is appropriate for your organization). Next, create an estimate based on the size of the conversion using a PI a little lower than 1 standard deviation below average.  Be careful not to underestimate all of the functions that will require tweaking.  Then, compare the two scenarios keeping in mind the degree to which the confounding factors mentioned above will come into play on the conversion.

All of this is not to say that conversions cannot succeed; they can.  The completed conversion projects in our database testify to this.  But, before you embark on one, keep in mind that converting a legacy system can be far more complex than it initially seems. In some cases redevelopment may be a viable alternative. Comparing what it takes to convert a legacy system to the resources required to build it from scratch can help you decide on the best course.