Controlling Software Development Costs

Software projects performed in today's economic environment are under more pressure to reduce costs more now than ever. Although projects have always striven to achieve the biggest "bang for the buck", today we're putting the emphasis on "buck" more than ever before. Project managers are being asked to do more with less and this leads to a temptation to strip away requirements that we might view as "nice to haves" or gold plating, but may very well have merit for the user community. Before you adopt any slash and burn policies with your requirements, here are a few tips for shrinking the budget for that new software system.

COTS vs. Home Grown Software

COTS stands for Commercial off the Shelf and when considering components for any new system the Project Manager must compare the advantages and disadvantages of a COTS product vs. creating the application from scratch. Nowadays there is a wide selection of COTS products available. 20 years ago the issue was: is there a product commercially available that performs the functions we require? Most often the answer was "no". Today that's changed and there are very few applications that can't be closely approximated with a COTS product.

The advantage of COTS products is that they tend to be much cheaper than developing a similar product in-house. It stands to reason; the vendor develops the application and sells many copies so is able to sell the software for a fraction of the cost of developing it and still make a profit. The trade-off is that the product will not suit the system requirements exactly. It's sort of like buying a suit. Most people buy a suit off the rack and then have it altered because it is much cheaper than to go the bespoke tailoring route where the tailor custom makes the suit for one customer. The off the rack suit won't be exactly what the customer wants but they are prepared to live with that in return for the money they save.

The disadvantage of COTS is that you must sacrifice fit for cost and that means that often the application does not perform all the functions you would like it to, or that it does not perform some functions the way that your users would like it to. This drawback is actually addressed, in many cases, by an ability to customize the software to make it meet the user needs. This ability will not extend to major functionality but some vendors have been very creative using a combination of settings and data to custom fit their application to the purchaser's needs. Larger, more complex, and expensive products tend to have the most flexibility.

Project managers will tend to focus on their project budgets rather than lifecycle costs for the software product, but you should compare the support cost of the COTS product vs. the cost of supporting an in-house application. Much of the cost to support a COTS product will be covered by the vendor. There is usually a charge back to you for a support license but that cost will be less than the cost of supporting the application with your in-house support staff. Cost savings realized during the lifecycle of the application should factor in to the buy/make decision.

Overtime vs. Lieu Time

Overtime comes at a premium in many organizations so using overtime to overcome a schedule slippage will increase the project budget. Overtime pay is the brute force method of getting the project back on track but is not necessarily the only alternative and is not always the most effective. Offering staff time off in lieu of overtime pay can be an attractive alternative to staff and can save the project money.

Lieu time is not always possible to arrange within the confines of the project schedule, unless you are managing a project that has a duration marked in years and not months. You are looking at ways of shortening the schedule and giving team members time off will adversely affect that goal. Look for slack in your schedule for opportunities to provide time off in lieu of the necessary overtime. The trouble is that most often we have plans to move the resource on to the next task and slack time doesn't affect their schedules.

You will have to arrange the lieu time with someone external to your project if the project can't absorb it. This may mean a functional manager or another project manager. Engage your project business sponsor if negotiations prove difficult. They may be the sponsor for the next project the resource will be working on, or have influence over that project's sponsor. There will be a cost to providing the lieu time, regardless of who bears it. You may be required to absorb some of the cost on your project, and that's only fair. Regardless of who bears the cost, the organization is still saving the overtime premium.

A couple of words of caution here. Always ensure that any promises to provide time off in lieu of overtime worked are honoured. Nothing will kill your reputation quicker than reneging on a promise of time off. It doesn't matter whether the promised time off is just postponed, not giving the resource the time off on the agreed upon date will still cause dissatisfaction. Also, excessive overtime will ruin productivity. Studies show that productivity tends to tail off after about 10 hours. Extended periods of 60+ hour weeks will also damage productivity and cause burnout. Look for symptoms such as increasedabsenteeism, lack of motivation, decreases in morale, and skipping meetings. When the team begins to exhibit these symptoms, it's time to cut back on the OT.

Automated Tools

The use of automated tools is one way to increase productivity. The value of these tools is their ability to assume some of the testing tasks your programmer or tester would normally perform manually, thus saving time that can be used for coding or designing. Automated tools are available for software testing, regression testing, user testing, performance testing, and stress testing. The drawback to these tools is twofold: the initial cost and the cost of training. The cost of training covers training sessions that teach the student how to use the tool and the learning curve as the resource gains experience and proficiency using the tool.

The cost of acquisition should be spread over the lifetime of the tool. If the tool can only be used by the current project, it is a poor investment. If the tool will benefit every project your organization undertakes, it may be a great investment. Look for applications in operational areas as well. Productivity gains from the tool may be realized during the support phase of the application's lifecycle. The cost of acquisition for these tools should be borne by the organization rather than the project. If the project does bear any cost, it should be proportional and not the whole cost. The choice of tools should be driven by the organization so operational requirements and the requirements of future projects should be taken into consideration when making the choice.

Combining User Testing and Training

The implementation of any new software system often requires training of the user community. Combining the training of the user community with User Acceptance Testing can reduce the cost of the project. The project is expected to perform unit testing, function or thread testing, and system testing. You may also be expected to perform some form of end-to-end testing that will simulate the user experience, but if you have engaged the user community to perform User Acceptance Testing, the amount of time spent on end-to-end testing can be greatly reduced, or eliminated altogether.

How does training enter into the discussion? Users are usually eager to train on the new system. It is to their advantage because it not only provides a break from the normal routine, it also gives them a chance to get their hands on the new system and have their questions answered before they have to use it in production. Making training contingent on signing up for User Acceptance Testing is one way of harnessing the attraction of training to drive UAT. Another way of combining the 2 is to build the tests into the training exercises. "Hands on" training is desirable and completing tests that exercise the entire system from end to end should offer all the coverage of a complete UAT plan.

These are just some ideas for reducing project costs, but certainly not all the options available to you. The idea is to think outside the box, assume nothing, and take nothing for granted. Maintaining a constant vigil for cost cutting opportunities and making cost cutting a project objective will help you find opportunities to cut costs. It will also focus the team on cost cutting and they may identify opportunities to cut costs. Project work is a team effort. So is cost cutting.