When CIO’s are mandated by their company to find ways of saving money in a credit crunch, the first port of call is often staff cutbacks, which is reasonable considering the high cost of personnel.

Then they examine their ICT infrastructure and services to identify inefficiencies. When it comes to new software development projects, these are often just put on the back burner.

However, in some cases the project is business critical or promises high levels of efficiency and cost saving, and so is not in the company’s interest to delay it. In these cases, the CIO is under greater than ever pressure to ensure the project is delivered on time, to budget and meets business requirements.

All of which is no small challenge at the best of times – even more so when there is no margin for error.

Supporting business needs

The most challenging aspect of a software project – and the one that often causes the most cost overrun – is ensuring the application accurately reflects an organisation’s business requirements.

If the delivered solution fails to live up to expectations it can involve many rounds of time-consuming reworks (sometimes taking years) leading to higher costs and delayed time-to-market, which depending on the solution may mean considerable opportunity loss. From the standpoint of conserving cash, the less reworking that is needed on a project, the better.

This can, in fact, become an out-of-control leakage of money if the contract with a supplier is ambiguous with regard to deliverables. Unless the specifications are mapped out clearly and areas of responsibility are clearly defined, most of the cost to get an application right may be shifted onto the customer with no comeback.

Step-by-step project planning

For the CIO, therefore, achieving optimum cost savings in a software build depends on thorough, disciplined upfront planning.

This involves ensuring there is a clearly defined process in place for the initial mapping out and reviewing of the project’s specifications and ensuring all internal stakeholders are in agreement.

There needs to be an established timeline for how and when in the development process things will be reviewed and who is responsible for signing off on each component. Nothing should be overlooked.

Follow highlights from ComputerworldUK on Twitter

From the supplier point of view (whether they are internal or external), at each stage there should be a presentation to the customer stating: ‘Here’s what we’ve done so far – are you sure this is exactly what you want?’

This is on the grounds that it’s easier to course correct along the way than at the end of a project when it’s off the tracks.

Avoiding shortcuts

The importance of a best-practice methodology cannot be overstated. Given that projects are often rushed, there are insufficient resources to oversee them, and a host of other exigencies, there is always the temptation to shortcut the process and think: “It’s just a small thing’, ‘We can do it quickly’ or ‘We can get the guy to code it up quickly’ Or even more dangerously, to say to the supplier: “Of course you know what we want, let’s skip the formalities.”

But unless everything is written down, agreed to, signed and embedded within a structured process, step-by-step in a methodical way, expensive and time-consuming misunderstandings ensue, deadlines slip and the result is open to subjective interpretation.

Yes, all of this may seem a huge and pointless amount of overhead, and stakeholders may rebel with: “Why do we need all these meetings?”.

However, time and investment made up front more than pays for itself when the solution is delivered first time right. Of course not all organisations and their software developers and system integration suppliers have equally mature management disciplines.

They may not, for example have CMMI, Prince or Six Sigma processes / frameworks in place. In which case, it is a matter of being as methodical and thorough as is realistic in the circumstances - from specification and sourcing through to software testing and implementation.

Change happens

Sometimes re-working cannot be avoided. Unforeseen events may mandate changes in business strategy. In such cases it’s crucial to notify the developer about the change as soon as possible and ensure there is a process in place for change control.

In fact, the CIO should already have a good idea of what impact change requests will have on the project budget.

For example, in building a house a good contractor will tell the customer upfront what impact various alterations – such as adding a window – is likely to have on the overall cost. It is here where careful documentation shows its worth.

The less exact the original specifications, the easier it is for a supplier to use a customer’s request for change as an opportunity to bundle in additional ‘catch up costs’ if they feel the original quote was underestimated.

Follow highlights from ComputerworldUK on Twitter

Controlling the build process

As part of the software development methodology, careful records should be kept throughout the project and at every milestone measurements should be taken of the application’s compliance with requirements, including benchmarking key performance indicators at every stage.

When the first module or the first phase of delivery is complete there should, for example, be a series of meetings with all stakeholders to ensure the results conform to each of their needs.

Milestone benchmarking saves money

The reason that benchmarking is so important at each stage of development is that without it there can be no context or valid comparison with best-practice guidelines.

Moreover unless these KPI measurements are done along the way problems may only get uncovered late in the day or after delivery, at which point the customer is left with the tedious job of having to iron out the bugs, or find workarounds to the things that don’t work.

It is not unknown for a delivered and paid for solution – and this may amount to millions of dollars – to simply be shelved as unworkable.

Very often this is not the fault of the supplier, or at least is a shared fault. If the specification is loose, vague or just wrong this can be the product of the supplier asking the wrong questions or misunderstanding the needs. Or it may be that the customer has documented the requirements incorrectly – they might, for example, ask for a screen colour to be blue when they mean purple.

Either way, it can mean lost revenue and additional cost.

Acceptable levels of defects

Defects in code need to be identified early to catch mistakes as they are made. This means testing each component of the solution as it is comes off the bench and recording the results.

Nothing will ever be totally bug-free and it is important to decide in advance what level of error is acceptable. For example an 80% or 90% accuracy rate may be sufficient if pushing for that extra 10% means paying a premium that cannot be justified by the return on investment.

Again, these considerations should be factored into the original project plan and communicated to the users so that expectations are managed successfully.

Follow highlights from ComputerworldUK on Twitter