2.0 WHAT ARE THE MAIN REASONS FOR PROJECT FAILURE?
Like any other projects in engineering such as building houses, finding crude oil etc there are steps which include specification, design, development and testing. After all these steps like any other projects, there are bound to be some failures. Some projects have more failure rates than others. Other engineering projects are subject to the laws of physics and have physical constraints. This is however not the case with IT projects.
There is a common perception that IT projects have lower success rates than other branches of engineering. It was found out after a review of a thousand IT projects (by the Office of Government Commerce) that technology was one of the minimal likely reasons for projects to fail. Programmes seemed to fail due to management reasons rather than technological reasons. The main reasons found were:
- Lack of leadership- the leadership skills in the IT projects are lacking behind compared to other engineering projects.
- Lack of knowledge of what the technologists were trying to explain to the leaders of the organisation and inefficient knowledge about what the business user want.
- Poor risk management- this is not whether the program code is a failure or a success, technologists are not sure if unions will accept the proposed changes.
- We tend to underestimate the complexity of business and human change.
- Programmes sometimes are not able to be broken into little bits. Projects that take more than a year are too long. This is due to the continuous changes that are occurring daily. There is also the problem of people not informing the project of the changes.
- Even though IT projects could be seen as business change programmes, the IT industry must take responsibility for some factors. Bad practices have become established in drawing up IT contracts for example, many suppliers bid low due to the fact that they know that they can get the costs back on scope changes and overruns. This gives incentives to fail because that’s the only way that IT suppliers think they can make money.
- Requirements are often lacking- unlike big engineering programmes such as building sky-scrapers which have spot on specifications. This can provide an additional way to make money other than their lowest cost bids.
- Lack of constraints- both customers and suppliers are susceptible to forgetting or simply not understanding the limitations of IT resulting in unrealistic expectations and over ambitious projects. Software engineers are sometimes to blame for taking risks that surpass other types of engineers. This is due to the fact that there is an impression that software is generally free of constraints and therefore it has an unlimited potential.
3.0 WHAT IS NEEDED TO MAKE CHANGE PROGRAMMES SUCCESSFUL
3.1 Management
Effective management is one of the most important factors that make change programmes successful because such programmes threaten the entire organisation. Basically, the people involved must have the full attention of the people up top. There is a need for managers who can enhance the communication between the technologists and top management. Clear leadership from the top is especially important as some stakeholders are less enthusiastic than others. Stakeholders have to be kept updated and engaged especially the customers or business users.
3.2 More manageable programmes
Programmes need to be broken into smaller bits so that they are more manageable. Customers claim that when the programmes are broken down, they understand the programmes and can cope better. This is common especially with the senior management. When the customers understand what is going on, they are more committed.
3.3 Customer supplier relationship.
“A close, open and robust relationship between buyer and supplier is key” (J.Smith). This statement is very important in the business world. The success of a project relies heavily on the constructive relationship between the consumer and the supplier. This involves trust and good communication between individuals in each organisation on all levels.
3.4 Business outcomes
The dominant factor is money. The project teams can talk about cutting costs and how to streamline but all that depends on money. Businesses need to consider factors that have a financial benefit always. Everything must have a monetary value. Successful programmes need more than just a technological reason for progressing.
3.5 Clear goals
The clarity of what the business is trying to achieve is very important from the beginning. This means that what does not need to be done is clear so therefore what does need to be done is even clearer. It is therefore easier at this stage to break the job into little manageable chunks and therefore there are stages that are obvious towards reaching the goal.
3.6 Framework
After the little chunks have been made, a framework is needed to put the little chunks together. This is a very well established process in other branches of engineering such as civil engineering. A measure of an organisation’s ability to deliver IT is whether is has en enterprise data architecture.
3.7 Contractual agreements
The stakeholders who are going to benefit financially have to be committed. To get this sort of commitment, there has to be some sort of contract. The terms of the contract should reflect the uncertainty associated with a particular project and must also apportion the risks appropriately. It is also very important that the contract includes disciplined and constructive procedures for dealing with the project if something goes wrong. Risk and reward sharing could also motivate both the supplier and the customer to behave in a conducive manner to the business.
3.8 Realistic goals
Although there is a rapid development in technology, project teams need to be realistic with the rate at which the organisation and its staff can cope with a major change. For example the training of each and every team member could be very challenging.
4.0 MAIN STAKEHOLDERS IN AN IT PROJECT
4.1 Senior management
The senior managers’ roles vary in IT projects. The roles of the senior sponsor and business customer are paramount and usually carried out by different people. The business customer is the person who knows the business process that is being implemented or the product that is being manufactured very well. This individual is also the developer and curator of the requirements. Although the senior manager’s role is also taken by other stake holders, their primary responsibility is to the customer and also to the business.
4.2 Senior sponsor
The senior sponsor’s are those responsible for making sure that the project has clear high level deliverables that relate to the overall business strategy. This is a continuous role because the senior sponsor has to continually revalidate the project due to a possible change in the market or regulatory conditions. It is very important to have effective senior sponsors in the customer organisation. Due to the fact that in IT projects there is a change at some level, there can be a negative experience. There will only be a more positive experience if the management are seen to be supportive of the project. There is a high possibility of failure if there is a perception of that the project is being sponsored by the IT department
4.3 End users
These are the people who will use the product daily. It is necessary for them to participate in the specification and development of the project. They can see what is going on from there and can therefore complain to the project manager if there are any queries or parts they do no like. They know the precise procedures in current use and therefore their cooperation is extremely important to make sure the designers get the exact information. The end users need to feel and have a sense of ownership of the project so that there is not a perception that the end package has been imposed on them. There is also a need for time and effort to be put into the training of the users. If there is not enough training, there is a possibility that the success of the project will be jeopardised due to resentment and resistance from the user.
4.4 Systems architect
A systems architect the person who produces an overview of the technical structure of the system but does not include details of the implementation. A skilled architect produces a design which is scalable and evolvable. Experienced architects can incorporate sufficient flexibility to accommodate the changes that arise during the course of the project without element which could disrupt the design altogether.
Systems architects have the essential skills and ability to put a business vision into writing by making a technical blueprint. This blueprint should be expressed in a form that supports formal analysis and reasoning. It has been noted from experience that systems architects have an important role in IT projects but they are in very short supply.
4.5 Project manager
The project manager is responsible for the delivery of the project. This consists of meeting the budget and timescale as well as overseeing the delivery of the specifications. They also test the product and hand it over to the customer. The project manager will have many years of experience and this equips them with leadership qualities, commercial awareness, and willingness to take calculated risks, communication and problem solving skills. The project managers need to be armed with sufficient knowlddge and understanding of the technology to be able to identify possible problems that may arise from the project.
In other engineering sectors, the role of a project manager carries a high status due to the fact that it is associated with commercial success. In the IT sector on the other hand, technical experts can be moved to the role of a project managerial position because of their expertise. This is not advisable because project management requires a lot more than just expertise in the field of IT. Organisations seem to lack defined career paths for their project managers and do not provide them with adequate opportunities their professional development. Organisations therefore need to make sure that the experience the project managers gain is connected and applied to other projects with the organisation.
5.0 TASKS IN MANAGING AN IT PROJECT
As has been stressed throughout this report, management is a critical factor in an IT project. Apart from the knowledge of the product, there are managerial skills which include problem solving and human resource management. There are many tasks involved in managing an IT project. These include:
Contracts
A contract is necessary as it states what it required from each party involved in the project. It lays out who is responsible for what and who makes what decisions. This must be clear and easy to understand. It should state who manages the costs, who knows what the costs are and so on. It should also state (if the work is being broken down) how many programmers/ analysts are being used and what they cost as well.
Cost managements
Programmes and projects need detailed schedules and cost management. This is important because details of how much has been spent and where the risks are should be clear to the people working n the project. One view says that red, amber and green classifications on progress reports should be steered clear of because they are not detailed enough. They just show where the business is lacking and progressing but not in enough detail.
Honesty
There should be openness about problems. If there is a new system there is bound to be the odd failure. The management needs to be frank with the employees if things start to go a bit pear shape.
Progress
In the course of the project, the management needs to review the programmes. They should ask themselves if they are still on the right track and if it is within the time scale they awarded to the project. They should also review the changes within the sponsors or stakeholders. There could be gateway reviews or peer reviews, but there should be someone independent of the programme who can ask questions and the project can be ended quickly if answers are not forthcoming.
The staff should also be questioned and asked about their worries and complaints. This will be more valuable than if they are constantly asked if everything is going on well.
Benefits
The staff should be able to clearly define the benefits that will be delivered by the project which must be comprehensible and defensible. When staff members start to answer the same question differently, there should be a cause for some concern. There must also be knowledge of how the delivery of the business benefits will ultimately be assessed and who will be responsible for the process.
6.0 CONCLUSION
6.1 Missing skills
Most of this indicates that there are is currently lack of management and communication skills. IT people are not very good in communicating and there is an urgency for IT people to develop this skills.
6.2 Lack of Professionalism
There is also huge lack of Professionalism among IT people. This is cause by lack of proper training; even people at the coalface are not bothered whether they know what make a good or bad project or project team.
More so, most IT people are not trained in tradition engineering training, which could cover for example going on site and even arguing with supplier.
Basically most disciplines and applications are crossing boundaries, therefore, IT people should not overlook soft skills if other organisations have these covered.
REFERENCES
British Computer Society Report: Leadership Debate 16 march 2005, “Why are Complex IT projects different”, page 1.
British Computer Society Report: Leadership Debate 16 march 2005, “Why are Complex IT projects different”, page 2.
British Computer Society Report: Leadership Debate 16 march 2005, “Why are Complex IT projects different”, page 3.
British Computer Society Report: Leadership Debate 16 march 2005, “Why are Complex IT projects different”, page 4.
British Computer Society Report: Leadership Debate 16 march 2005, “Why are Complex IT projects different”, page 5.
Royal Academy of Engineering, (2004), “The Challenges of Complex IT Project”, page 4
Royal Academy of Engineering, (2004), “The Challenges of Complex IT Project”, page 7
Royal Academy of Engineering, (2004), “The Challenges of Complex IT Project”, page 13-17
Royal Academy of Engineering, (2004), “The Challenges of Complex IT Project”, page 21-27
BIBLOGRAPHY
Reports:
Royal Academy of Engineering and British Computer Society, (2004), The Challenges of Complex IT Project, London, Royal Academy of Engineering.
BCS Thought Leadership Debate, (16 march 2005),Why are Complex IT projects Different, London.
