Most people will agree that a project is an activity that is constrained by a number of variables, including time, money, environment, people etc. One important variable is the expectation level of the recipient. Meeting or managing this expectation is key to project success.

The IT industry provides the fertile conditions needed to maximize the chances of project failure. A lack of standards coupled with a plethora of half-baked technologies turns the most mundane requirements into groundbreaking exploratory science. There is little project managers can do about that except trying to use the same ‘tried and tested' technologies for every situation regardless of the business requirement. A safe but innovation-free approach.

Let's focus on the reasons that lead to failure that are within the control of the project manager. Firstly, failure is in the eye of the user. Traditional quality assurance systems define success in reliability terms, which will no doubt suit the six-sigma vendors. However quality could equally mean usability ("I don't care if it crashes once per week, what's important is that my slave wage IT-illiterate temp staff can use it") or even speed of delivery (A 100% fault tolerant parcel logistics solution will be of no use to Santa Claus if it is delivered after Christmas). With the exception of a minority of applications, most users will trade reliability for other benefits. One well-known software house has built a business on this.

A common phenomenon in the IT industry is that clients complain that they have received exactly what they asked for. This problem highlights two issues. One is that the client was asked what they wanted two years ago and then did not hear from the project team until the day of delivery. A more user-involving development philosophy would get around this. But I do empathise with the IT department for not taking the customer's phone calls during the development process. The established approaches to system development need to be more agile to keep pace with ever changing business requirements. Secondly the client does not fully know what they want and just because they signed off a thick functional requirements document should not be taken as an indication that they have read it. In court, this document counts for little. It's all about fitness for purpose. Again a more user-inclusive approach is required.

Software engineering, which by the way is on the verge of coming back into fashion, has a large part to play. The principles of building a McDonnell Douglas Phantom jet fighter bomber out of Airfix parts does not scale up to building a working model. The software engineering industry has in many ways still not recognized this. You are encouraged to turn all big-bang projects into a series of little phuts; the latter is currently state of the art.

To avoid board level disappointment, ensure that IT department projects are underpinned with a strong business case and board sponsorship. Large spend that has no link to the business strategy will slow down the CIO's ascent to the board.

In conclusion the IT department has a responsibility to allocate its resources in line with the needs of the business, to involve the sponsors and users throughout the project and to have a sufficiently flexible approach that can absorb unforeseen changes in direction. If ever there was a case for project outsourcing...