Why do projects fail?
The first reason why the projects do fail, it is because the project did not correctly manage the time and the project did properly delivered. As what I have written in my paper when we had a reflection paper in our subject Project Management in the question why do projects fail, so for me based on my own understanding of why do projects fail, it is because the project did not meet all the requirements that is being needed and the project does not pass during the time duration given. So as we all know that a project is just only a partial task that is need to be finished or to be done on time. Maybe projects do fail due to the time consciousness. As what we have been discussed in one our topic last semester in our subject System Analysis and Design, it is said that in order to have a project successfully and well effectively it should be finished or done on time, within the scope and specifications and it should be within a budget. The project should be done planned properly in terms of its boundaries in which the scope must have in it. The project should not over be in budget, it should be on the quality in terms of the budget. Making a project is just like having a time management; it must be made or done on time as what it should be. Beside in time management, planning is also one of the most important key in order for the project not to be failed. If a project is not well or properly planned, it could affect the total amount time that was spent on a project. So if more time is focused on the project, then this will lead the quality of the project into a successful one. So if a sufficient amount of time planned for the project, then the important information of the project would be wasted. A project can only be said successful when it is has a good quality, finished on time, within the budget and within the scope and the most of all is the quality of the planning made in the project. It is a sad fact that many projects, particularly those involving information systems, fail to deliver against their objectives on time and within budget. Projects fail when they are not managed well - when planning is not rigorous (or ignored altogether), when insufficient control is exercised, when the necessary skills are missing and when elements or people are ignored or forgotten. Just like the case in our project in System Analysis and Design subject, we all in our group get a grade of incomplete because we did not manage our time thoroughly and we did not planned well on what we first to do about our project.
So during our discussion about the real meaning of the project management, my entire classmate answered the same reason and that is the management of the time, and for me I agreed also about the answers of my classmate, but sad to say that our professor was not agree about the answers of my classmates. But somehow our professor shared that the only reason why projects fail it is because we plan to fail. We have planned for the failure while doing the project, so all the same the result is also a failure. In a ideal world every project would be "on time and within budget." But in reality (especially the proven statistics) tells a very different story. It's not uncommon for projects to fail. Even if the budget and schedule are met, one must ask "did the project deliver the results and quality we expected?" True project success must be evaluated on all three components. Otherwise, a project could be considered a "failure." So when a project begins to show signs of stress and failure, everyone looks to the project manager for answers. It may seem unfair that the burden of doom falls upon a single individual. But this is the reason why you chose to manage projects for a living! You've been trained to recognize and deal with these types of situations.
As based on the Project Management Book of Knowledge or PMBOK the reasons behind on the failures of the project are as follows: First is Poor Estimates – it only implies that we might have a poor result in managing the time or the any phase of the development of the project. Second is Scope Changes – it only implies that we did not defined definitely the scope on what the project should be. Third is Work breakdown failures – it only implies that we lack of efficiency while during the process of development of the project. Fourth is not enough time or resources allocated – it only implies that the time and the resources made during in the project was insufficient, and the only reason is the time management. Lastly is incompetent project management – it only implies that a project should have a proficient or competent project management to manage the project or the task equally and accordingly. And that is the reason why most of the projects fail because of the incompetent project management during the making of the developing the project. These five reasons are being defined in the Project Management Book of Knowledge or the PMBOK.
So in order for me to understand deeply the reason of the failures of the project, I made some research on the internet. And as what I have read in the site of projectsmart.co.uk, these are some of the common reasons of failures of the project or projects:
Poorly managed – the project is poorly managed because of its undefined objectives and goals and lack of management commitment.
Lack of a solid project plan – the project is lack of a solid project plan, it is because through the lack of user input and lack of organizational support.
Central practical managing initiatives to combat project risk - Enterprise management of budget resources; Provides universal templates and documentation
Poorly defined roles and responsibilities – the project is poorly defined roles and responsibilities, it is because through the inadequate or vague requirements and the Stakeholder conflict.
Team weaknesses – it is because the team of the project has a unrealistic timeframes and tasks and competing priorities.
Poor communication –the project is poor in communication, it is because through the insufficient resources.
Overruns of schedule and cost - Estimates for cost and schedule are erroneous; Lack of prioritization and project portfolio management
Scope creep - No change control process; Meeting end user expectations
Ignoring project warning signs - Inadequate testing processes; Bad decisions
So if you understand the difference between symptoms and problems and can spot warning signs of project failure, your training will help you take steps to right the ship before it keels over. During the course of managing a project, the project manager must monitor activities (and distractions) from many sources and directions. Complacency can easily set in. When this happens, the process of "monitoring" breaks down. This is why the project manager must remain in control of a project and be aware of any activity which presents a risk of project failure.
According to the site I have research; there are six key factors that are involved in any particular project failure. And these are the followings: First is Lack of User Involvement - Lack of user involvement has proved fatal for many projects. Without user involvement nobody in the business feels committed to a system, and can even be hostile 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. Second is Long or Unrealistic Time Scales - Long timescales for a project have led to systems being delivered for products and services no longer in use by an organization. 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. Many managers are well aware of the need for fast delivery, leading to the other problem of unrealistic timescales. These are set without considering the volume of work that needs to be done to ensure delivery. As a result these systems are either delivered late or only have a fraction of the facilities that were asked for. The recommendation here is to review all project plans to see if they are realistic, and to challenge the participants to express any reservations they may have with it. Third is Pitiable or No Requirements – there are many projects have high level, vague, and in general unhelpful requirements. 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. Fourth is the Scope sneak – the scope is the overall view of what a system will deliver. Scope sneak is the sinister 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. 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. Fifth is the rebuff change managing organization - despite everything businesses change, and change is happening at a faster rate than ever before. So it is not realistic to expect no change in requirements while a system is being built. However uncontrolled changes play havoc with a system under development and have caused many project failures. This emphasizes the advantages of shorter timescales and a phased approach to building systems, so that change has less chance to affect development. Nonetheless change must be managed like any other factor of business. The business must evaluate the effects of any changed requirements on the timescale, cost and risk of project. Change Management and its sister discipline of Configuration Management are skills that can be taught. Sixth is the pitiable test - the developers will do a great deal of testing during development, but eventually the users must run acceptance tests to see if the system meets the business requirements. However acceptance testing often fails to catch many faults before a system goes live because:
• Poor requirements which cannot be tested
• Poorly, or non planned tests meaning that the system is not methodically checked
• Inadequately trained users who do not know what the purpose of testing is
• Inadequate time to perform tests as the project is late
Users, in order to build their confidence with a system, and to utilize their experience of the business, should do the acceptance testing. To do so they need good testable requirements, well designed and planned tests, be adequately trained, and have sufficient time to achieve the testing objectives.
So during our discussion about the real meaning of the project management, my entire classmate answered the same reason and that is the management of the time, and for me I agreed also about the answers of my classmate, but sad to say that our professor was not agree about the answers of my classmates. But somehow our professor shared that the only reason why projects fail it is because we plan to fail. We have planned for the failure while doing the project, so all the same the result is also a failure. In a ideal world every project would be "on time and within budget." But in reality (especially the proven statistics) tells a very different story. It's not uncommon for projects to fail. Even if the budget and schedule are met, one must ask "did the project deliver the results and quality we expected?" True project success must be evaluated on all three components. Otherwise, a project could be considered a "failure." So when a project begins to show signs of stress and failure, everyone looks to the project manager for answers. It may seem unfair that the burden of doom falls upon a single individual. But this is the reason why you chose to manage projects for a living! You've been trained to recognize and deal with these types of situations.
As based on the Project Management Book of Knowledge or PMBOK the reasons behind on the failures of the project are as follows: First is Poor Estimates – it only implies that we might have a poor result in managing the time or the any phase of the development of the project. Second is Scope Changes – it only implies that we did not defined definitely the scope on what the project should be. Third is Work breakdown failures – it only implies that we lack of efficiency while during the process of development of the project. Fourth is not enough time or resources allocated – it only implies that the time and the resources made during in the project was insufficient, and the only reason is the time management. Lastly is incompetent project management – it only implies that a project should have a proficient or competent project management to manage the project or the task equally and accordingly. And that is the reason why most of the projects fail because of the incompetent project management during the making of the developing the project. These five reasons are being defined in the Project Management Book of Knowledge or the PMBOK.
So in order for me to understand deeply the reason of the failures of the project, I made some research on the internet. And as what I have read in the site of projectsmart.co.uk, these are some of the common reasons of failures of the project or projects:
Poorly managed – the project is poorly managed because of its undefined objectives and goals and lack of management commitment.
Lack of a solid project plan – the project is lack of a solid project plan, it is because through the lack of user input and lack of organizational support.
Central practical managing initiatives to combat project risk - Enterprise management of budget resources; Provides universal templates and documentation
Poorly defined roles and responsibilities – the project is poorly defined roles and responsibilities, it is because through the inadequate or vague requirements and the Stakeholder conflict.
Team weaknesses – it is because the team of the project has a unrealistic timeframes and tasks and competing priorities.
Poor communication –the project is poor in communication, it is because through the insufficient resources.
Overruns of schedule and cost - Estimates for cost and schedule are erroneous; Lack of prioritization and project portfolio management
Scope creep - No change control process; Meeting end user expectations
Ignoring project warning signs - Inadequate testing processes; Bad decisions
So if you understand the difference between symptoms and problems and can spot warning signs of project failure, your training will help you take steps to right the ship before it keels over. During the course of managing a project, the project manager must monitor activities (and distractions) from many sources and directions. Complacency can easily set in. When this happens, the process of "monitoring" breaks down. This is why the project manager must remain in control of a project and be aware of any activity which presents a risk of project failure.
According to the site I have research; there are six key factors that are involved in any particular project failure. And these are the followings: First is Lack of User Involvement - Lack of user involvement has proved fatal for many projects. Without user involvement nobody in the business feels committed to a system, and can even be hostile 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. Second is Long or Unrealistic Time Scales - Long timescales for a project have led to systems being delivered for products and services no longer in use by an organization. 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. Many managers are well aware of the need for fast delivery, leading to the other problem of unrealistic timescales. These are set without considering the volume of work that needs to be done to ensure delivery. As a result these systems are either delivered late or only have a fraction of the facilities that were asked for. The recommendation here is to review all project plans to see if they are realistic, and to challenge the participants to express any reservations they may have with it. Third is Pitiable or No Requirements – there are many projects have high level, vague, and in general unhelpful requirements. 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. Fourth is the Scope sneak – the scope is the overall view of what a system will deliver. Scope sneak is the sinister 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. 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. Fifth is the rebuff change managing organization - despite everything businesses change, and change is happening at a faster rate than ever before. So it is not realistic to expect no change in requirements while a system is being built. However uncontrolled changes play havoc with a system under development and have caused many project failures. This emphasizes the advantages of shorter timescales and a phased approach to building systems, so that change has less chance to affect development. Nonetheless change must be managed like any other factor of business. The business must evaluate the effects of any changed requirements on the timescale, cost and risk of project. Change Management and its sister discipline of Configuration Management are skills that can be taught. Sixth is the pitiable test - the developers will do a great deal of testing during development, but eventually the users must run acceptance tests to see if the system meets the business requirements. However acceptance testing often fails to catch many faults before a system goes live because:
• Poor requirements which cannot be tested
• Poorly, or non planned tests meaning that the system is not methodically checked
• Inadequately trained users who do not know what the purpose of testing is
• Inadequate time to perform tests as the project is late
Users, in order to build their confidence with a system, and to utilize their experience of the business, should do the acceptance testing. To do so they need good testable requirements, well designed and planned tests, be adequately trained, and have sufficient time to achieve the testing objectives.
For me when we say project, it is not only a preferring to a term paper work or a final project. But anywhere in our place now have comprises of a different establishments or any buildings in which it also considered as a project. Why? It is because it also undergoes a solemn plans and applications for those proposed project plans to be finished within time and within a budget. It is not a building which also considered as a project but also the construction of the public highways, bridges, houses, malls, schools and institutions, and roads, and even also the government establishments. So all of these I have mentioned can be considered as a project, particularly when it needs expertise which might be think as a complex projects. A project like buildings must have project assembly supervision which will be applied in managing and building process of a building. Also I have read some articles that say communication is still a part of the process of project management. In that fact, organizations nowadays are lacking the aspects of communications, ineffective communications and downright confusing communications. This is because in organizational viewpoint, only few who are involved in the project is taking the constraints of it on head. It’s just the same as having an intelligent mind but then again does not have the ability to apply what’s on his/her mind. We may also spot the reason of failure or cancellations of the project because of cost overruns, or the project were launched with essential errors mistakes.
In making or implementing a project, there may be all sorts of things going wrong, such as being behind schedule, over budget, under resourced, or having poor quality deliverables leading to non-acceptance. So how do you recover from this coming up project failure? So the first thing to do in project recovery is to evaluate the overall project - an audit or project review using a series of standard questions should identify the key problems and the severity of each one. This will allow you to priorities project recovery planning and activity so that you tackle the most serious problems first, and then work down the list. During the review, you might find some areas where you can stop the bleeding - for instance, if scope is unstable and forever changing, the introduction of a strict change control process should at least help to firm up and stabilize the scope. And after the assessment of the troubled project you may determine that there is no good business case for project recovery so we may need to cut our losses and move on rather than waste time and money on project recovery planning. In this case, of project failure, we need to plan euthanasia - let the project die as painlessly and with as much dignity as possible. A failing project needs the help of a well-trained project planning professional, also called a recovery Project Manager to minimize recovery time, cost, and residual damage if the project can be saved, or to recognize when euthanasia is the recommended option.
Finally, in order to prevent a project failure you must have a good project planning based on a well-constructed deliverables-based Work Breakdown Structure and proper controls. However, once a project starts to fail, there are also techniques to recognize it, minimize the extent of the project failure and make the project recovery as successful as possible. There may be some casualties along the way, such as some reduction in scope, additional time, and/or additional cost, but with good project planning and timely intervention where required, these can be minimized. A project manager needs to be trained in these techniques not only to recover a failing project, but more importantly, reduce the chances of creating one themselves in the future.
No comments:
Post a Comment