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
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
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.