Factors Influencing the Success or Failure of Project Essay Example

project successful or a failure. Below are some of the success factors and some of the failure factors.

Success Factors User Involvement

When the user is involved from the beginning of the project the project team will be getting input from the people who are going to be most affected by the system that is being built. The project team can use their experience and knowledge to help in setting out what is expected, what is useful and can use their feedback as the project progresses to find out whether what is wanted is being delivered. Without user involvement people are likely to be hostile to the project because people fear change.

Management support

Support from the management is essential if a project is to succeed. The management have to agree with the project and they have to support it with money and personal commitment. Managers are often busy people and unless they support a project it is unlikely that they will put the time and effort in to make it succeed or that their staff will. Skilled experienced project managers and staff A successful project needs project managers who can manage the project well. It also need to have staff who have the right mix of skills to do all the jobs that are needed.

Clear expectations

Everybody involved in the project needs to know exactly what they will get out of the project, what needs to be put into the project, who will be doing what, when it will happen, how much it's going to cost and so on. These clear expectations about everyone involved to matter

whether the project is going to be successful or not. Well defined scope This is one of the most important factors in a successful project. The scope of the project shows exactly what will be done and what the boundaries of the project are. It will also show what other systems the project has to communicate with.

Many government projects which are subject to project ‘creep’ fail in the end because the scope has not been successfully defined. For example, a system that is designed to hold customer records is being developed. During development is decided it will also deal with customers bills, that these will be dealt with over the Internet etc. The functionality for this has to be built and this will affect timescales. Clear statement of requirements A clear statement of requirements is part of understanding what the expectations are. The statement of requirements says this is what the client wants and tells everybody what should be produced.

Without a clear statement the developer is working in a fog, building what they hope the user wants. When it's developed the user is likely to say that's not what I wanted. Prototyping Prototyping is used in developing systems. It shows the user at an early stage what the system will look like and what it will do. If the user does not like what is being shown on the prototype can be thrown away or adapted very quickly. This means that lots of feedback can be gathered from the user of the system at an early stage and throughout the development of the project.

Sound methodology used Some methods the

developing systems are easier to manage than others and some more likely to succeed, particularly in large-scale projects. Using a sound methodology that is understood by all involved will help the project to succeed. Extensive testing During the development of the system, testing needs to take place at every stage. The requirements need to be checked with all involved; the designs need to be tested; prototype's need to be tested by the user and others involved; each part of the system needs to be tested and the whole system tested.

There is statistic that says that 80% of the effort should go into testing and only 20% into development. The more testing that takes place the more likely it is that the project will finally be successful. Testing will also involve adequately training users so that they can do user testing. Time must be built in to do this Comprehensive planning A well planned project that has been broken down into all the parts that are needed and all the tasks that are required will make it clear what are the critical path is. The critical Path shows deadline is that must be met if the project is to be delivered on time.

It will also show any dependencies, were one task is dependent upon another task being completed. This makes it clear what resources are needed and when. Clear milestones should be set out at checkpoints for progress on the project. Contingencies should be built in to allow for unexpected problems.

Factors in Failure Expectation Mismatch

Where all the people involved in the project are not agreed on what can

be expected then there is little chance that the project will be successful. One person might be expecting a Rolls-Royce and another person might be expecting a Mini.

But what the developer gives them is a Mondeo. In the end none of them will be satisfied Bad idea if the project is a bad idea right from the beginning then it's not going to be successful. This could be because none of the users want it, or because it is ethically wrong and causes a reaction, or any one of lots of reasons. Poor communication Poor communication between people involved in the project is similar to the expectation mismatch; unless people are kept up to date with what's going on it is likely that they'll be pulling in different directions.

It can also cause bad feeling among the project team and between users and developers all users and management or developers and client. Assigning staff with lack of skills if the staff assigned to the project don't have the right skills to carry out the tasks that are needed or to do the jobs that are needed then the project won't succeed. You have to have the right staff doing the right things at the right time. One people factor involved here could be people who can't say no. This often means that the project team promises something they can't deliver and stores up problems for later on.

Inflexibility in delivery dates Complex projects can be very difficult to predict and manage. With the best will in the world it's not always possible to meet deadlines. If there is complete inflexibility in

delivery dates for parts in the project or the project overall then it is likely that either things will be rushed to meet the deadline and will fail in other parts, or that too much effort will be put into meeting the deadlines and calls cost overruns, or any one of a number of reasons. Successful and unsuccessful large-scale projects

As I have mentioned above the Standish group found that most projects that was successful had a limited number of people involved, had a well-defined scope, and a fairly short timescale. Most complex, large-scale projects have lots of people involved, scope tends to not be well-defined and they usually are carried out over a long time period. This makes them prone to failure. I'm done to look at for large-scale projects, one successful and three unsuccessful. For each of these I will pick out some factors that may have been involved in their success or failure.

VOSA On-line Licensing Project

The Department of Transport uses agencies to control motor licensing in the UK. The Vehicle and Operator Services Agancy (VOSA) is one of the agencies. It deals with 120,000 commercial vehicle operators in the UK. In 1988, the goods operator licensing system was computerised in order to create a more efficient system using the available technology. This was before the common use of the Internet. In 2004 VOSA started its Operator’s Online Self-service Licensing project. The system uses the Internet to allow oods vehicle operators direct access to their own licensing records and allows them to input and track applications in real-time. The project also allows the agency to work easily with

other agencies that are involved in vehicle licensing. It is a secure system that allows payments by credit or debit cards. Before 2004 the agency as a whole had very little information technology and few IT skills. The management started to make changes to the culture because outside influences from the government were making them think about how they could provide joined up services.

This meant that the senior management were committed right from the start and provided the vision for the project. The on-line licensing project was just one project out of seven that were developed by the agency. Right from the start of the project outside users were consulted and they agreed to take part in pilot programmes. Also substantial training of staff took place to give them the skills necessary to use the system was developed. The project team was led by staff who understood the business processes necessary.

These worked alongside the technology developers who had the skills necessary to develop this part of the system. Where the agency did not have the necessary skills in their own staff they outsourced, so bringing in the skills necessary. The scope of the project was well-defined. Although it was ambitious because of the lack of technology skills in the agency the boundaries of the project were clear and what the project was aiming to do was very clear. A well understood methodology called Prince2 was used to make sure that the rapid development was reliable.

Substantial testing took place throughout the development. Even though the project was a complete success in terms of what is offered, the agency did find

that there were challenges in persuading external users who had not been involved in the pilots and other government agencies to use the system. In order to encourage more users to use the system further projects have been put in place to increase the systems functionality. It is clear that this project many of the success factors that are listed above.

Passport Office project

The United Kingdom Passport Agency (The Passport Office) issues all passports in the United Kingdom. It has a number of regional offices but deals with most passport applications by post. In the summer of 1999 The Passport Office hit the headlines as queues of people built up demanding passports that they needed to go on holiday. People were having to wait between 25 and 50 days to get their passport by post, instead of the usual 10 day target. By June the backlog was 565,000 applications – almost a month’s work. Emergency measures had to be implemented in July and by the end of August the crisis was over.

The Press had a field day. A major enquiry was launched into what had caused the problems. Although several factors were identified one of those was a major cause-the introduction of a new computerised passport processing system in two of the six regional offices, Liverpool and Newport. The system was needed to replace an old computer system and to allow the issue of a more secure passport. The system should have been introduced into all its offices before the busy season but difficulties at Liverpool and Newport meant that this was postponed.

Although the new system worked, it

was not as productive as the developer had said it would be. The Passport Office did not allow enough time for staff to learn and work the new system which involve changes in clerical and admin processes. Also, not enough time was allowed for computerising these processes. The agency and the developer never did succeed in raising output to target levels. It was clear that there had been insufficient testing of the new system before it went live. The piloting of the system was on too large a scale initially.

Not enough attention had been paid to the views of the users on how practical and usable system was The Passport Office and the developer did not plan well enough. They didn't build in enough contingency time or work out what they would do if the introduction of the system in the first office did not go according to plan the first office to use the system was Liverpool and the problems there had not been overcome before it was introduced to Newport which just made the problems worse. The failure by the developer to live up to expectations meant that they had to pay ? 9m compensation to the Passport Office.

What really made matters worse is that the communication with the public and media was very poor. Its telephone enquiry bureau became overwhelmed with calls from the public as the media got hold of the story. The Passport Office did not take the steps necessary to make sure that enquiries from the public were answered promptly. It should have seen that as processing times lengthened so the number of enquiries would

increase, but it didn't. As waiting times got longer and the publicity grew so more people put in applications early because they were expecting delays, and that increased the problem.

Another factor that affected the project was that in the 1990s the Home Office target was to reduce costs, increase efficiency, whilst giving customers a reasonable service. This meant that the service was operating close to its capacity. Because of this focus, when the problem occurred, the Passport Office was reluctant to employ new staff because of the cost. Instead they relied on using staff and managers working longer and longer hours to try to cope. This is because they have not analysed the risk of failure properly.

The Passport Office had not learned from previous problems that occurred in 1989 when it computerised some procedures. A new system had been piloted in one office and implemented in another before initial problems were sorted out. This caused severe delays in processing applications and eventually led to the staff going on strike report then also said that the Passport Office had been very optimistic in going ahead with the implementation and that the project had not been managed well. The overall cost of this project failure amounted to about ? 1 million and the cost to the customer of issuing a passport rose to ? 14 and rose again over the coming years. This was very different from the expected decrease in costs stated in the business case for the project. NASA’s Mars Climate Orbiter Project In 1999 NASA lost a Mars space probe. The obvious cause was that two teams of scientists working

on the project were using different systems of measurement. One was using metric, one was using imperial. This was the cause that hit the headlines, but it didn't tell the full story.

An investigation into the failure showed that the navigation software and related software had not been tested as a whole system. As well as that communication and training within the project had been poor. Other reasons the failure included no clear success criteria to state how the project outcomes should be measured; the project wasn't funded adequately and its scope was too large for the money available; communications between the teams working on the project was poor and the staff were not properly trained in project management.

As a result of this failure that decided that in future they should focus on smaller, low-risk products that could be incorporated into larger scale products this would minimise the risk of failure.

Heathrow Terminal 5

One project that was in the news a lot in 2008 was the opening of Heathrow Terminal 5. The terminal was opened by the Queen in March but on the first day that it went live everything went wrong despite six months of testing with up to 15,000 volunteers. British Airways (BA) had described a new terminal as being like a natural, logical journey that’s so calm you'll flow through.

It shouldn't take long to get from check-in to departures. Transferring and arriving are just as simple and calm! Terminal 5 cost ? 4. 3 billion to build and equip. It was an enormous project with 180 IT suppliers and 163 IT systems. It took

400,000 man-hours of programming to develop the complex system. Within hours of the terminal opening the baggage-handling system broke down and by 4:30 in the afternoon, just 12 hours after it opened, all check-ins had to be suspended. The causes of the problems were very simple but the effect, both for the passengers and for the prestige of the country were massive.

There were some technical problems with the baggage handling system, including the fact that bags got jammed because they were not being unloaded fast enough. Also the system told baggage handlers that planes had taken off, even though they could still be seen on the ground, so the handlers took the luggage back into the terminal rather than loading it onto the waiting planes. Some staff said that the problems with the baggage system had been discovered during testing in the weeks prior to the terminal’s opening but had not been sorted out. There were also problems with staff finding car parks and getting through security checks.

This meant that not enough staff were on duty as the terminal opened; that check-ins could not be opened and that bags were not moved from the conveyor belts fast enough to prevent jams occurring. What was obvious from this was that staff had not been trained well enough and were not familiar with the systems they were using, even though training had started a year before the terminal opened. In addition, the lack of familiarity with the terminal itself increased the problem as staff could not get to work on time, putting others under stress.

Testing had not been carried out properly,

though BA and the British Airports Authority (BAA) had been confident that everything would go well. In fact, nearly every major airport that opens is late and has major operational issues. The testing that was done was not tough enough to find all the problems that would occur. As mentioned above over 15000 volunteers were used to ‘test’ the terminal, but it was not tested with all the staff, some of whom had never been in the terminal until the day they started working there.

There had never been a dry run using all the staff – only small teams had been used in the testing that did take place. All the bits of the terminal had been tested but the whole thing had never been tested together – that’s why the staff couldn’t find the car parks or get through security on time. So, another project that did not have adequate testing failed spectacularly on the first day, though it has been sorted out since!