When CIOs are instructed to cut their IT costs it is often new
software projects that get relegated to the back burner. However,
if these are a critical part of the business plan, the challenge is
to go ahead with the development but ensure costs are controlled
and the finished solution supports business needs and fulfils
expectations, write Michael Bragen of the Software Practice
Group and Paul Michaels, director of consulting atMetri
UK.
IT must reflect business needs
The first imperative is that the application must reflect
business requirements. If it fails to live up to expectations this
may involve many rounds of time-consuming reworks (sometimes taking
years) leading to higher costs and delayed time-to-market and
opportunity loss.
From the standpoint of conserving cash, the less reworking the
better as this may become an out-of-control budget leakage if the
contracted deliverables are ambiguous. Unless the specifications
are mapped out clearly and areas of responsibility defined, most of
cost will likely end up with the customer.
Invest in best-practice planning
Achieving optimum cost savings depends on thorough, disciplined
upfront planning. There must be a clearly defined process in place
for outlining the project's specifications and ensuring all
internal stakeholders are on board.
There also needs to be an established timeline for incremental
review with a sign-off by those responsible for each component.
Nothing should be overlooked. For the supplier, each phase of the
development process should be submitted to the customer along the
lines of: 'Here's what we've done so far - are you sure this is
exactly what you want?' It's easier to course correct along the way
than to reach completion and find the entire project has gone off
the tracks.
Given that software development projects are often rushed there
and are typically insufficient resources to oversee them, and there
is always the temptation to shortcut the process and say to the
supplier: ''It's just a small thing, you guys can code it up
quickly' It's even more dangerous say: "Of course you know what we
want and we haven't got time for all these meetings so let's skip
the formalities."
Yes, best-practice methodology as promoted by CMMI, Prince or
Six Sigma may seem to involve too much preliminary planning time
and over-the-top detail. However unless everything is mapped in a
step-by-step methodical and best-practice way, expensive and
time-consuming glitches and misunderstandings can easily happen
downstream.
Build in unforeseen change
Of course, sometimes unforeseen change happens and reworks are
necessary. In such cases it's crucial to notify the developer as
soon as possible and ensure there is a 'change control' process in
place so that cost impacts can be calculated. For example, in
building a house a good contractor will tell the customer upfront
what impact adding an extra window or a dormer is likely to have on
the overall cost.
What is crucial at this stage is that unforeseen changes are not
used as a 'catch all' excuse for unspecified additional costs.
Benchmark at every stage
Careful records should be kept of milestone and benchmarking of
performance and other indicators to ensure the application is
compliant with requirements. When the first component is delivered,
there should be meetings to ensure the results conform to
stakeholder expectations.
Without this phased benchmarking there is no valid comparison
with best-practice guidelines and errors may get introduced that
are much more difficult to correct later. Often, customers are left
to iron out the coding defects or find workarounds. It is not
unknown for multimillion-pound projects to simply be shelved in
exasperation even though they have been paid for. This may not be
supplier's fault, but the result of vague instructions or a
misunderstanding of the customer's business need.
Settling for imperfection
Nothing will ever be completely bug-free, and usually it is more
cost-efficient to settle for 80% or 90% accuracy than insist on
100% accuracy which will probably involve paying a premium that the
ROI cannot justify. Again, these considerations should be factored
into the original project plan and communicated to the users so
that expectations are managed successfully.