Industrial Case Study: Moving to Commercial Off-the-Shelf and Open-Source Software Usage in Telecommunications

Outcomes and lessons learned

The numbers in Table 4-5 tell the story. Developing custom software doubles the schedule and adds $244 million, or about a 70 percent increase in costs, to the effort. Yes, there might be risk in using COTS and open-source software. But there is lots of risk in pursuing a custom development as well.⁵ Also, the desired three-year schedule for the project is infeasible if you use custom development.

When you review your numbers with the planning project team, they are impressed. But your team lead is not. He says the battle has just started and that you better check and double-check your numbers. He suggests that the engineering department will use every trick in the book to discredit you. Power, jobs, and budget are on the line. Therefore, the fighting will be fierce. He asks the member of your team from the finance group to dig up past engineering costs to determine if the cost model’s assumptions are in line with actual results. He then asks the team if they know of any metrics that senior management uses to test estimates. The response is that the magic number used in the firm for validation is $100 per SLOC (source line of code). Where that figure comes from nobody knows. However, when you apply it, the results of using this rule of thumb seem to compare nicely with the $92.50 per SLOC that was the output of the cost model ($370 million divided by 400 MSLOC).

The financial person on the team reports his findings, which are surprising. The cost per SLOC actually delivered six years ago for the switching system that is currently in the field was $125 per SLOC. When you think about it, you can build a case that you would expect current costs to be less, especially because you plan to exploit advances that have been made in technology when you build the new system. You and your boss feel comfortable about your numbers and feel ready to defend them when management calls you as they try to settle the debate over the use of COTS and open source. In the interim, you plan to research the numbers more completely in an attempt to further validate your findings. Your strategy is to let the numbers do the talking.⁶ Management can ignore them if they want, but they paint a compelling case for the use of COTS and open-source software packages in the new switching system. As a change agent, you also need to recognize the need to use techniques to address resistance.

The lessons learned in this telecommunications case were many and include, but are not limited to, the following:

• COTS and open-source software represent new ways of doing business. As such, you should apply change management principles to enable early, frequent, and ongoing communications with stakeholders to deal with the inevitable resistance that will be encountered.
• There are many advantages and disadvantages associated with the use of COTS and open-source packages. Be sure to evaluate each carefully before making a commitment.
• COTS and open-source software packages do not come for free. Besides the license costs, there are other expenses associated with getting the package ready to be interfaced and used as part of the system in which it will operate.
• When looking to use COTS and open-source packages in systems, be sure to identify and license all of the packages you need in the systems, applications, and support domains during development, maintenance, and operations (run-time licenses).
• Recognize that most COTS and open-source packages do not plug and play directly out of the box. Some effort might be needed to configure, tailor, integrate, maintain, and sustain these packages throughout the life cycle. This is especially true if there are architectural mismatches and the packages do not support your data model.
• Maintenance of COTS and open-source software packages can be difficult because they are updated at a different frequency than the system they are part of. In response, you have to plan to synchronize package updates with your releases and map the features.
• Plan also to try to influence the direction COTS and open-source software package vendors take through relationship management. Although you might not be the vendor’s biggest customer, you want to be one of their most important ones. Realize that you might have to pay a premium or make investments to achieve this status.
• When performing a make/buy analysis as in the case study, recognize that the numbers will do the talking unless there are compelling reasons why they should be discarded.
• Take care to make your numbers believable and credible. Whenever possible, validate them against your past performance and rules of thumb that are part of your firm’s history.