Friday, March 25, 2011

Why do project(s) fail(s)? cite examples

“Often difference between a successful person and a failure is not one has better abilities or ideas, but the courage that one has to bet on ones ideas, to take a calculated risk- and to act”
by Andre Malraux

Now a days, a project is expected to accomplish its goal on ‘time and within budget’. But in reality it tells an opposite story on several projects. Statistics have been proven it. People of today don’t know how to deal with the things they need to accomplish and it’s common to have fail project if they always take things for granted. Most especially when it is related in the field on trade and industry where money is involve. From the above quotation pointed by Andre Malraux, he once said that there is big difference on a person who succeeds on things not because of the idealistic and more intelligence a person obtain, but the characteristics or an attitude of a person really speaks more. What matter most is the courage or the ability to beat or defeat ones idea. Thereof, he/she is determined enough to be a risk taker. Even if the budget and schedule are met, one must ask "did the project deliver the results and quality we expected?" I was been encourage and inspire the movie entitled “KUNG FU PANDA” where Panda awaken into the reality that there is no secret ingredient of his father’s specialty soup but it is to believe that it is especial. Just like managing a particular project “YOU” who has the responsibility and the accountability to formulate and organize task should have to plan things not to fail. When we had the second discussion Mr. Randy Gamboa show unto us at first that a project fails when a person behind on it is fail to plan. However, he is more certain that a project fail it is because person involved into it already has the plan to fail. I had read several site on why do project fail and the factors or reason result in break down. When projects begin to show signs of stress and failure, everyone looks to the project manager for answers. It may seem unfair that the burden of falls upon a single individual. But this is the reason why you chose to manage projects for a living! That’s why manager had been trained to recognize and deal with different types of situations. A project is considered a failure when it has not delivered what was required, in line with expectations. Therefore, in order to succeed, a project must deliver to cost, to quality, and on time; and it must deliver the benefits presented in the business case.

The following are the reason for the project failures which have been involved in our discussion last time.
• Poor estimates
• Scope changes
• Work breakdown failures
• Not enough time/resources allocated
• Incompetent project manager
• Ineffective use of project management discipline and processes
• Lack of proper management support and
• Wrong use of technology


I had read some article from the internet. According to a site, there are many reasons why projects both simple and complex fail; the number of reasons can be infinite. However, if they apply the 80/20 rule the most common reasons for failure can be found in the following list:
• Poorly managed
• Lack of a solid project plan
• Centralized proactive management initiatives to combat project risk
• Poorly defined roles and responsibilities
• Team weaknesses
• Poor communication
• Overruns of schedule and cost
• Scope creep
• Ignoring project warning signs
• Undefined objectives and goals
• Lack of user input
• Enterprise management of budget resources
• Inadequate or vague requirements
• Unrealistic timeframes and tasks
• Insufficient resources (funding and personnel)
• Estimates for cost and schedule are erroneous
• No change control process
• Inadequate testing processes
• Lack of management commitment
• Lack of organizational support

Even the solid plans for projects can crook if it has not been manage properly. Project manager must recognize a warning sign and take and adequate action. In addition to applying the processes and principles taught in project management class, you can also use your personal work skills of communication, management, leadership, conflict resolution, and diplomacy to take corrective action. Thus, even an employee under its management has the right to correct and take the chances to hear his suggestions or opinion in good terms.
Project may possibly fail maybe because they were cancelled because of cost overruns, or that’s why systems were launched with fundamental errors. Cost overruns means spreading rapidly of big cost of amounts require which is not expected and so it becomes infested and overcrowded. The requirements for success of a project should be are clear and absolute – right? Unfortunately, it's not that simple. Things are not simple to obtain. Because the second part of definition of success is that the project must be delivered "in line with expectations." It is essential that most of the cases a project is fail when the client for instance, speak out because of the result of an expected project. If a stakeholder agreed to the new contract that a project had to exceed its initial budget, the project may still be considered a success. It might be happen when it is not been clearly budgeted during the planning stage. On the other hand, if a project delivered everything that was in the detailed project designs, it may still be considered a failure if it didn't include vital elements that the key stakeholders needed. So a certain project like constructing high ways must finish and end its requirements like the distance and cost, which consist of permit and fees on the workers. This doesn't seem fair, but project success and failure isn't just about the facts, nor is it simply about what was delivered. It's also, critical; about how the project is been observe .One of the article once I had visit showed the following six the most important reasons for failure of project.

1. Lack of User Involvement. The absence of user participation is one of the difficulties of a project that is being fail. Because it may proved fatal or deadly for project. Without user involvement nobody in the business feels committed to a system, and can even be antagonist to it. If a project is to be a success senior management and users need to be involved from the start, and continuously throughout the development. This requires time and effort, and when the people in a business are already stretched, finding time for a new project is not high on their priorities. Therefore senior management need to continuously support the project to make it clear to staff it is a priority.

2. Long or Unrealistic Time Scales. Unpredicted time frame usually happens when setting the time bounded from the start. Long time for a project has led to systems being delivered for products and services no longer in use by an organization. If the person behind the project set the estimated time for doing a project it should be follow in accordingly. If the stakeholders demand for new requirements the time is expected to extend. The key recommendation is that project timescales should be short, which means that larger systems should be split into separate projects. There are always problems with this approach, but the benefits of doing so are considerable. Managers on a project should be aware for fast delivery and some indication prior to the problem on time or unrealistic timescales. The recommendation to this reason of failure is to review and look over all the project plans if it is realistic.

3. Poor or No Requirements. Most of the project has unclear requirements due to lack of stakeholders’ involvement. That’s how important on what kind of technology is going to use for the project. This has led to cases where the developers, having no input from the users, build what they believe is needed, without having any real knowledge of the business. Inevitably when the system is delivered business users say it does not do what they need it to. This is closely linked to lack of user involvement, but goes beyond it. Users must know what it is they want, and be able to specify it precisely. As non-IT specialists this means normally they need skills training. In fact developers must have the right and proficiency of expertise to be competitive.

4. Scope Creep. As I’ve learned about scope creep it is the uncontrolled of the system. Scope is the overall view of what a system will deliver. Scope creep is the insidious or the gradual harmful growth in the scale of a system during the life of a project. As an example for a system which will hold customer records, it is then decided it will also deal with customer bills, then these bills will be provided on the Internet, and so on and so forth. In this scenario it is harmful to have the access on the project. All the functionality will have to be delivered at one time, therefore affecting time scales, and all will have to have detailed requirements. This is a management issue closely related to change control. Management must be realistic about what is it they want and when, and stick to it.

5. No Change Control System. It is a reason for project to fail when there is lack of control or difficulty. It may happen at a faster rate. Therefore, it is practical and reasonable to have changed while a project is being built. However uncontrolled changes might be damage with a system under development and have caused many project failures. When this happen, this reason is the advantages of shorter time frame approach to building system.

6. Poor Testing. During the development of a project, the developers will do the testing before the delivery happen. But eventually users are needed to run a system checking the requirements. However acceptance testing often fails to catch many faults before a system goes live because requirements are poor when tested, unplanned test system, inadequate trained users who doesn’t aware of the purpose of testing and adequate time to perform test of project. Users should allow themselves on learning and utilizing experience of the business, they should do the acceptance.

Failure examples of IT Projects

Project cancellation, project didn’t deliver on the benefits anticipated, the project cost more than anticipated etc. those are several definition of a failure project. IT project failures are not difficult to collect and pile up. What is hard is to get an evaluation of the issues and figures on the extent of the outline of project. What is even harder is to get all the project protagonists or the main character agrees on what caused the failure and where the responsibilities lie. Of course, every project insider or outsider has his own version and those versions, almost inevitably, "cancel out".
IT project failure has to be looked at with extreme humility. Project managers are generally bright, experienced, motivated and knowledgeable. When a project is deemed strategic the best resources are generally pulled in. And sometimes - even quite frequently if we look at the statistics - it fails, thereby demonstrating that good ingredients are not sufficient to make up a good mayonnaise. In other words, good characteristics are not enough to to have a successful project.

To illustrate their point that IT project failure is not just occasional a few impressive examples are presented hereafter. The best documented project failures are the ones involving "public money". The more "public" the money is, the more likely it is that it will be published and, more importantly, documented and quantified, mostly in Anglo-Saxon literature. In other terms, project which involve in the “public money” is more important to work in a success because this may involve well documented view to public.

SOME EXAMPLES of IT PROJECT

As I’ve read several sites about project fail the following are the results based on their studies.

1. In February 1988, hardware problems caused the Bank of America to lose control of several billion dollars of trust accounts. All the money was eventually found in the system but all 255 people – the entire Trust Department- was fired as all the depositors withdrew their trust money. As this scenario, this might happened because of the scope creep or the slowly and dangerous growth scale of the system during the life of the project. The Bank of America lost its clients and thereof the Bank also lost its employee. This failure cost billion dollars.

2. The first night where the US Fed's new system went life, it lost control over 28 billion dollars in transfers and awarded interest to the wrong member banks. Interestingly, the member banks only reported $24 billion dollars in errors the next day. This might happened because of the less security of the bank account or the poor identity of authorization. As the wrong bank account owner identifies him/she didn’t back to full amount of money instead he/she take advantage the opportunity to take 4 billion. He/she fooled!

3. In 1987, the California Department of Motor Vehicles (DMV) launched a major project to revitalize their driver’s license and registration application process. By 1993, after $45 million dollars had already been spent, the project was cancelled. One of the reasons why this happened is because of overruns of schedule and cost. Imagine they spent a huge amount but then 6 years later their capital lost and fail because of exceeding to the amount limit. Wrong planning of amount cost for the renewing drivers license and registration application process failed.

4. In March 1997 the state of Washington killed the biggest IT project in its history, the License Application Mitigation Project (LAMP). Aimed at automating the state's vehicle registration and license renewal processes. The scrapped project began in the early nineties and was supposed to be online in 1995. It planned to create a relational, client-server system using IBM's MVS/CICS architecture. Initially budgeted at $ 16 M, the project cost climbed to $ 41.8 in 1992, $51 M in 1993 and was estimated (March 1997) at $67.5 M of which $40 had spent without result. In 1993, LAMP faded when it became clear that it was doomed to be a colossal money-waster and even if the plug had not been pulled it would have been much too big and obsolete by the time it was finished. LAMP was turned off in 1997, after legislators calculated that the project ultimately would cost $4.2 million more annually to run than the state’s $800,000 per year incumbent system. Why is this happened? Corrupt project builders have been distinguished, I guess wrong techniques used for the project has been done. It might be lack of a solid project plan is the reason while in the planning stage occurred. It was a big mistake in the side of the builders.

5. 5. In early 1993, the London Stock Exchange abandoned the development of its Taurus paperless share settlement system after more than 10 years development effort was wasted. The Taurus project manager, Eliott Manley, estimates that, when the project was abandoned, it had cost the City of London over £800 million (although the Financial Time of Nov. 3, 1993 reports losses of "only" £400 M - this also points out how hard it is to get accurate financial figures on IT project cost, especially failing IT projects). Its original budget was slightly above £6 million. Taurus was 11 years late and 13,200 percent over budget without any viable solution in sight. London Stock Exchange had been in wrong invest imagine in excess of budget was the result. Though the manager has the great accountability of estimating financial figures, he also failed in the first place.

6. In the case of the computer-aided dispatch system for the London Ambulance Service developed between 1987 and 1993, the problem was not so much one of excessive budgets or project delays. The issue was rather the usability of the system that leads to its final failure reported as follows: "...at 2AM on Wednesday, Nov 4, 1993, the system slows down considerably and then locks up altogether. Rebooting does not solve the problem. The automatic back-up system also fails to come on-line. A decision is made to revert to purely manual methods". In this case the system fails to achieve its life span. Budget and project delays are not the preeminent problems instead the crashing of the system was the big problem. Hardware and software didn’t match the requirement of the system I think.

In above mentioned, most of the usual IT project fail is due to the wrong budget of cost and overall scope. Since every project involved money and money is not an easy thing to lose. For a project to be successful, it's not enough simply to manage your project competently, and deliver a good quality product. To avoid failure, make sure you have identified the right business requirements, created an achievable business case, put strong project governance into place, managed a high-quality implementation, focused on benefits, and monitored your changing environment. Also stakeholders must lean on their support in order to help those people doing the project declare it to success. They have to keep the eye along with the project. As an IT student, I come up with the idea that I should have be train well and be persistent in my skills especially in achieving to hold sooner a project. In fact as the one who is doing or operating certain project, he/she must be accountable and in control in planning where it involves time, cost and project scope. Once a project fails I think it is one of the reason to take again and learned from that experience to drive more and strive again in the second time. Life offers continuous chances. Yes! I had been failed in some fields in my life, but here I am looking forward to try hard and make an extra effort to avoid failure might happen again.


RESOURCES:

http://www.coleyconsulting.co.uk/failure.htm
http://www.adaptivepartners.com/projfailb.htm
http://www.mindtools.com/pages/article/newPPM_58.htm
http://www.projectsmart.co.uk/reasons-why-projects-fail.html
http://ezinearticles.com/?Why-Do-Projects-Fail?&id=3598643
http://www.projectperfect.com.au/info_it_projects_fail.php
http://www.it-cortex.com/Examples_f.htm

No comments:

Post a Comment