This report summaries the views expressed at a BCS Thought Leadership Debate aimed at exploring issues surrounding IT projects and why much research shows that only around 20 per cent can be considered to have been successful.
The event was on 16 March 2005 at the Royal Society in London. Two speakers stimulated debate with short talks and then the 41 participants discussed the topic in small groups over dinner.
Each table included senior people from IT suppliers, commerce, industry, the public sector and universities. At the end of the evening each table reported back to the entire gathering.
IT Projects: a Misnomer
Are IT projects characteristically different from other engineering projects? We should stop calling them IT projects: they are instead major programmes of change. Very few are specifically IT projects.
The much publicised UK Passport Office project was not a technology failure but to do with management failures in business processes and change control. The National Health Service (NHS) IT project is not an IT project but a huge change programme.
Similarly the NHS or any other big organisation is not necessarily a single entity running a unified business change programme with a unified objective and agreed scope.
Indeed, big programmes can highlight that an organisation is in fact dysfunctional, in that it is a group of disparate functions. Perhaps this could be a starting point for major programmes: clarifying the nature of the organisation and the programme.
If we get all this terminology right we might start to view 'IT projects' differently.
We shouldn't beat ourselves up too much in any case: programmes without IT as a central element have also failed in terms of missed schedules and budgets.
The Concorde aircraft programme was budgeted at £175m and came in at £800m; the Channel Tunnel costs more than doubled from £4.8bn to £10.9bn; and the Scottish Parliament building costs rose from £40m to £374m.
Reasons for Project Failure
A review of 1,000 projects by the UK Office of Government Commerce (OGC) found that technology was one of the least likely reasons for a project to fail. Programmes fail for management reasons, not technical reasons.
The OGC found the main reasons for failure to be:
- Lack of leadership
- Lack of knowledge at the top of the organisation about what the technologists are trying to explain - and lack of knowledge among technologists about what business users want. This leads to a huge gulf
- Poor risk management - not in terms of whether program code is accurate but rather in terms of whether, for example, unions will accept the proposed changes
- Underestimation of the complexity of business process change and human change
- Inability to break down programmes into bite-size chunks. Programmes or projects taking 12-18 months are too long, because things change. There is also a problem that people might not tell the project that things have changed.
Other factors can be added to this list.
Major programmes often involve some firsts; a lot of firsts can indicate that this could be a high-risk programme, something the budget and schedule should to take into account. These firsts need to be thought about early on.
Is this the first time this team has worked together? Is this the first time this activity has been computerised? Is this the first change programme for this function or group of people? Is it the first time that this programme team has had to identify stakeholders and get them committed?
Although IT projects might be renamed as business change programmes, the IT industry must take responsibility for some factors. Bad practices have become established in drawing up IT contracts, and these must be addressed.
For example lowest-cost bidding is prevalent. Many suppliers bid low, knowing they can get back the costs on scope changes and overruns. So accepted practice actually gives incentives to fail, because that's the only way IT suppliers feel they can make money.
Requirements are often lacking - unlike in big civil engineering programmes such as bridge building, which have more precise specifications. This again can give suppliers another way to make money on top of their lowest-cost bids.
Success Factors
So what is needed to make change programmes successful?
In complex programmes the management must come from the very top, because such programmes threaten the entire organisation. So those involved must have the attention of the chief executive, or the government minister.
Clear leadership from the top is especially important if some of the stakeholders are less than enthusiastic. Stakeholders must be kept engaged throughout, especially the customers or business users.
The need for hybrid managers who can build communication bridges between technologists and top management was articulated many years ago and is still best advice.
Hybrid managers are people who can cope with the business, aren't afraid of the technology - to the extent that they have been there, done that - and have the personality to talk to a wide range of people, be credible to users and technologists, and get their cooperation.
BCS might have a role here in promoting the development of hybrid managers, who are in short supply.
Programmes need to be broken into smaller and more manageable chunks. When this is done, people say they now understand what is happening and can cope with it, especially senior management.
This understanding gives people conviction and commitment. As well as system development chunks there might be ones covering tasks such as training the users or negotiating with unions.
A framework or architecture is needed to piece the chunks together. These are long established in civil engineering, and IT should be developing such frameworks an architectures and methods of practice.
The idea of data and systems architecture is relatively new to IT but these are the bedrock of an organisation's technology and their absence can be a reason for project failure. A measure of an organisation's IT maturity and its ability to deliver IT is whether it has an enterprise data architecture.
Clarity of vision of what is to be achieved is needed at the outset. Such vision also clarifies what the programme is NOT going to do, which is also an important issue. In addition, vision leads the team to start splitting the work into chunks, because stages towards the vision are identified.
The business outcomes must be agreed. The overriding factor here is money. Teams can talk about cutting costs and streamlining processes, but everything must come down to money: if we do this, with these stakeholders, where will the financial benefit be?
It could be increased revenue, or ideally increased profit, but it must have some true monetary value. Successful programmes need a real business reason for progressing, not a technology reason.
The stakeholders who are going to benefit financially must be committed, and there must be a contract of some sort with them, otherwise it will just be seen as an IT project - and you should forget it.
The process at the heart of the programme or project should be simplified if possible before IT development starts. Practice has shown that this can account for 80 per cent of the benefit of a programme.
Technology develops quickly - but think realistically about how fast an organisation and its staff can cope with major change.
Identify the technology involved and consider if it is new, or a first for the organisation: this increases the risk and needs to be allowed for at the start.
Working with IT Suppliers
Make sure the people needed are available or can be bought. Hiring consultants might not be the answer, although this approach might be useful if the programme is a one-off, for example, introducing a major package such as SAP: not all the implementation skills will be needed in future. But the user organisation must have the programme management skills.
Shared risk and reward contracts can help to build a joint sense of purpose between suppliers and the customer organisation - but if things go wrong the customer is the one that cannot walk away.
If IT suppliers are being contracted in, the client might ask whether they actually use internally the software and techniques they are proposing.
Does a single supplier have the capacity to handle the entire programme? Are there enough suppliers big enough to handle major complex programmes?
If a big software package is being taken on, the main options are to accept that one size fits all and change processes to match the product; or to go for an exact fit.
The former is usually more successful; with the latter option the procurement can often take longer than the implementation or the technology cycle the organisation wants to move to.
The budget must reflect all this, and also include a contingency for inflation, technology changes, software licence policy changes and so on.
Managing the Programme
The contract must lay out clearly who has what responsibility to make which decisions, and it must be managed. Who has to be kept informed? Who's managing the costs? Who knows what the costs are?
Is there a work breakdown so you know how many analyst-programmers are being used, what the function points are, what the contract programmers costs are? IT contracts rarely lay out responsibilities in clear detail.
One view says red, amber and green classifications on progress reports should be avoided, because they do not show the detail of how much of the budget has been spent or where the risks are. Programmes and projects need detailed schedules and cost
management.
There should be openness about problems, and indeed the odd failure should be allowed, especially if something is being done for the first time. Management should be frank with staff if things start to drift.
Projects and programmes should be continuously reviewed and their scope challenged. Is this still the right thing to be doing? If it is taking more than 12 months, what is changing in the organisation that might affect it?
Are the people changing, especially the sponsors or stakeholders? Are they allowed to change, these people who were supposed to be the beneficiaries? There could be gateway reviews or peer reviews but there should also be someone, perhaps independent of the programme, who can ask telling questions and kill a project or programme if the answers are not forthcoming.
Missing Skills
Much of this suggests that there is currently a lack of management and communication skills.
IT people generally lack good communication skills, and there is a need for focus on developing these softer skills.
There is also a lack of professionalism among core IT people. This is again largely down to lack of training, to the extent that people at the coalface do not consider whether they know what makes a good or bad project or project team.
Furthermore IT people do not get traditional engineering training, covering, for example, going on site, arguing with suppliers and so on.
Such training might produce contracts more like those in big civil engineering programmes. Civil engineering practices are long established, and IT could benefit from them.
BCS and other industry, employer and supplier bodies could look at certification of project managers - and indeed these bodies are starting to explore common ground, with some sort of certification as a possible ultimate outcome.
Many disciplines and applications cross boundaries, so engineering bodies should not reinvent the wheel if there is an IT element; similarly, IT bodies should not reinvent the wheel on soft skills if other organisations already have these covered.
