Preparation is the key to successful projects

Making sure that the groundwork is done thoroughly before an IT project begins will reduce the risk of cost or time overruns...

Making sure that the groundwork is done thoroughly before an IT project begins will reduce the risk of cost or time overruns undermining its value.

IT projects have a poor record for remaining within budget, despite signs of a recent improvement in the management of UK projects.

Confusion about the total cost of the national programme for NHS IT - Computer Weekly revealed that it could rise to more than £18bn, three times more than originally stated - is just the latest example of budget confusion or overrun.

Recommendations from experts on improving project management may appear common sense, but can be forgotten amid time constraints and budget cuts.

Often, problems with a budget can be traced back to before the project began.

"You need an understanding of what will be the business benefits," said Martin Heath, partner in the information and communications advisory group, KPMG. "There are two types of benefit from IT: to increase revenues or reduce costs or both. There must be an agreement which it is and a very clear business case to support it. If the costs outweigh the benefits, do not do the project."

It is also important to involve all parts of an organisation that will be affected by a project from the outset. "A key factor is the scale of the project," said Ashley Braganza, a senior lecturer in information systems at Cranfield School of Management.

"Any large IT project will affect a significant part of the organisation. The problem is ensuring that all the affected parts are included in the project [from its inception]. Often the project team scopes the project against deliverables and objectives only to discover that a part of the business that ought to have been included [at the planning stage] has not been."

Another common mistake when drawing up a budget is failing to include the cost of having managers from the general business working on the project in addition to normal responsibilities.

Staff from the general business need to be involved in specifying what the project covers at the design, build and testing stages, with their time explicitly costed, and in the primary development budget, he said.

A budget should also reflect the cost of training staff to use the new system. In some cases the technology will change the nature of their jobs. "It is not just the cost of training users how to use the new system, but the cost of retraining them in how their jobs are now done differently. For example, they may need to work with different parts of the organisation," said Braganza. "That cost of change is all too often not explicitly included in project budgets. Yet it can be a major cost to the organisation - maybe six to 10 times the amount spent on developing the new system."

Repeated requests from directors and line managers to change the technical specifications of IT systems can also play havoc with budgets and point to other problems with the project. "If the spec changes it is symptomatic of deeper causes," Braganza said.

"It is either because not all the right people were included from the start, so the project did not embrace all their needs, or those needs have changed because the business has changed. You should only ever change the specification if you are going to get bigger benefits which outweigh the extra cost," he added.

Keeping the same staff working on the project will also improve the likelihood of it running smoothly and sticking to its budget. "I know of a project where five out of seven of the project team have moved, and now they are waiting for new people, which causes delays, and it takes time for them to come up to speed. The project is six months behind schedule just because of project staff turnover," he said.

Setting up sound accounting techniques rather than using the latest financial software will also help to keep a budget under control. "A large project will entail incredibly complex accounting," said Heath.

"For example, you have to collect huge amounts of data, such as hundreds of timesheets from employees and sub-contractors and invoices from suppliers who may invoice weekly or monthly and so on, and there will be multiple project modules being worked on simultaneously. You do not realise how much money is being spent, or how to allocate it. If there are three project modules, and only one is over-budget, how can you tell which one?"

Heath advised firms to monitor budgets each day and compare progress made against the original aims each week.

Delivering an IT project using small stages, known as agile methodology, can also keep budgets on a tight rein. The three most common agile methodologies are known as "extreme programming", the "dynamic systems development method" and "rational unified process".

John McDermid, a fellow of the British Computer Society, said that using a technique such as the dynamic systems development method could help companies deliver parts of the project in manageable chunks. "It defines a window of time and scope of work to deliver in increments that are small enough to help you deliver them. If you do [a project] in a big bang it is harder to control."

IT directors trying to regain control of a project that is running over budget might have to scale back the scope of the project, change technical specifications or deadlines, he added.


How project management is improving     

The management of UK IT projects is improving and is better than previously thought, according to exclusive research by Computer Weekly and Oxford University's Templeton College which was published last year. 

The survey, of 1,500 IT project managers across the UK in all industry sectors, found that just 16% of IT projects hit their targets for budget, schedule and scope. 

However, many more missed their targets only narrowly. Templeton's Chris Sauer said, "We found that 55% of projects come within 5% of their schedules, 5% of scope and 4% of budget." 

The performance of UK IT projects in the survey showed a marked improvement when compared with IT projects surveyed by the Standish Group in 1995. 

Standish found that 31% of projects were abandoned, but Computer Weekly's more recent research showed only 9%. The drop indicated better project management and better choice of project, said Sauer. 

The Computer Weekly Project Management Survey was carried out by Chris Sauer and Christine Cuthbertson of Templeton College and sponsored by the French Thornton Partnership.

Read more on IT project management