The information technology industry needs to learn how to tackle complex projects from the building and construction industry (1054)

This paper outlines the very strong parallels between Information Technology (IT) projects and Building and Construction (B&C) projects. It also makes the point that, whereas large B&C projects (eg over two hundred million dollars) have a very high completion success rate, IT projects of this scale have very low completion success rates. Furthermore, according to McKinsey, '17 percent of IT projects go so bad they can threaten the very existence of the company'. The differences between IT and B&C projects, and the differences between how the project teams are set up are investigated and any disparities between the two highlighted and examined. Each disparity is outlined below and recommendations on what action should be taken for each is presented. The first, and very obvious, difference between IT projects and B&C projects is the visibility of their respective outcomes. In the B&C industry there is a very high level of project visibility. If a construction project fails people could be killed or injured and it physically remains there for the world to see, sometimes for many, many years. On the other hand, failures in the IT industry are much less visible and can easily be hidden from those that have funded the project (i.e. the shareholder and/or taxpayer). This leads to fewer questions being asked and project failures being investigated, i.e. little accountability, and therefore a general disregard in the IT industry for a high level of governance and project discipline. It is suggested therefore that, unless IT project failures are thoroughly investigated, for instance by bodies independent of the Board/Government, then new IT projects will forever continue to experience very little accountability and hence a very high failure rate. The next, and also very obvious, difference between IT projects and B&C projects is the fact that most, if not all, IT project methodologies do not include the equivalent of the Clerk of Works. This means that the client has little visibility in relation to the software quality, progress and adherence to standards and specifications, and finds it difficult therefore to make reasonable judgements on value for money, project risks and likelihood of success. It is suggested therefore, that all organisations commissioning an IT project should ensure they have the equivalent of a Clerk of Works, who has excellent technical and communications skills, working within the project team. A third observation is that IT industry has adopted job titles from the B&C industry without really understanding what those titles mean, and therefore does not correctly match job titles with the roles they are undertaking. The worst case of this is when project staff call themselves architects when they are actually performing an engineering role. The IT industry has also adopted the concept of architecture, for which the architect is responsible, but often confuses it with structure, for which the engineer is responsible. In order to address this problem, the paper describes the role of the architect and engineer in the general sense (i.e. not relating specifically to B&C, IT, Landscaping, Shipbuilding, Town Planning, and any other industries where there are both architecture and engineering elements). It also describes the difference between architecture and structure. It is suggested that the IT industry needs to clearly distinguish between the roles of architect and engineer and also distinguish architecture from structure. Only then can members and stakeholders of an IT project be able to understand the specific roles and responsibilities of each team member, and have a better understanding of the fundamental elements of the system they are building.