 | |
| ? Causes of Project failure |
There are many causes of project failure and every failed project will have its own set of issues. Sometimes it is a single trigger event that leads to failure, but more often than not, it is a complexly entwined set of problems that combine and cumulatively result in failure. Generally, these issues fall into two categories. Things the team did do (but did poorly) or things the team failed to do. Based on reviews of the projects in the Catalogue of Catastrophe and statistics revealed based on real life observations and calculations the following list documents of the most common mistakes that lead to, or significantly contribute to, the failure of projects:
Download Also:
Goal and vision
1. Failure to understand the why behind the what results in a project delivering something that fails to meet the real needs of the organization (i.e. failure to ask or answer the question “what are we really trying to achieve?”)
2. Failure to document the “why” into a succinct and clear vision that can be used to communicate the project’s goal to the organization and as a focal point for planning
3. Project objectives are misaligned with the overall business goals and strategy of the organization as a whole (e.g. Sponsor has their own private agenda that is not aligned with the organization’s stated goals)
4. Project defines its vision and goals, but the document is put on a shelf and never used as a guide for subsequent decision-making
5. Lack of coordination between multiple projects spread throughout the organization results in different projects being misaligned or potentially in conflict with each other.
Classic Mistakes
Analysis of the examples in the “Catalog of catastrophe” reveals the most common mistakes. Given the frequency of occurrence, these mistakes can be considered the “classic mistakes”. The following list outlines the most common themes and provides links to examples;
-The underestimation of complexity, cost and/or schedule
-Failure to establish appropriate control over requirements and/or scope
-Lack of communications
-Failure to engage stakeholders
-Failure to address culture change issues
-Lack of oversight / poor project management
-Poor quality workmanship
-Lack of risk management
-Failure to understand or address system performance requirements
-Poorly planned / managed transition
Requirements Issues
1. Lack of formality in the scope definition process results in vagueness and different people having different understandings of what is in and what is out of scope
2.Vague or open-ended requirements (such as requirements that end with “etc”)
3.Failure to address excessive scope volatility or uncontrolled scope creeps classic mistakes award winner
4.Failure to fully understand the operational context in which the product being produced needs to function once the project is over (classic mistakes award winner )
5. Requirements are defined by an intermediary without directly consulting or involving those who will eventually use the product being produced (see also lack of stakeholder engagement above)
6. Individual requirements are never vetted against the project’s overall objectives to ensure each requirement supports the project’s objective and has a reasonable Return on Investment (ROI)
7. The project requirements are written based on the assumption that everything will work as planned. Requirements to handle potential problems or more challenging situations that might occur are never considered
8. Failure to broker agreement between stakeholders with differing perspectives or requirements.
Leadership and governance
1. Failure to establish a governance structure appropriate to the needs of the project (classic mistakes award winner )
2. Appointing a Sponsor who fails to take ownership of the project seriously or who feels that the Project Manager is the only person responsible for making the project a success
3. Appointing a Sponsor who lacks the experience, seniority, time or training to perform the role effectively
4. Failure to establish effective leadership in one or more of the three leadership domains i.e. business, technical and organizational
5.The Project Manager lacks the interpersonal or organizational skills to bring people together and make things happen
6.Failure to find the right level of project oversight (e.g. either the Project Manager
micromanages the project causing the team to become de-motivated or they fail to track things sufficiently closely allowing the project to run out of control).
Decision-making problems
1.Key decisions (strategic, structural or architectural type decisions) are made by people who lack the subject matter expertise to be making the decision
2. When making critical decisions expert advice is either ignored or simply never solicited
3. Lack of “situational awareness” results in ineffective decisions being made
4. Failure to bring closure to a critical decision results in wheel-spin and inaction over extended periods of time
5. Team avoids the difficult decisions because some stakeholders maybe unhappy with the outcome
6. Group decisions are made at the lowest common denominator rather than facilitating group decision making towards the best possible answer
7. Key decisions are made without identifying or considering alternatives (aka ( First option adoption )
8. Decision fragments are left unanswered (parts of the who, why, when, where and how components of a decision are made, but others are never finalized) resulting in confusion
9. Failure to establish clear ownership of decisions or the process by which key decisions will be made results in indecision and confusion.
Stakeholder engagement issues
1. Failure to identify or engage the stakeholders (classic mistakes award winner )
2. Failing to view the project through the eyes of the stakeholders results in a failure to appreciate how the project will impact the stakeholders or how they will react to the project
3. Imposing a solution or decision on stakeholders and failing to get their buy-in
4.Allowing one stakeholder group to dominate the project while ignoring the needs of other less vocal groups
5. Failure to include appropriate “change management” type activities into the scope of the project to ensure stakeholders are able to transition from old ways of working to the new ways introduced by the project
6. Failure to establish effective communications between individuals, groups or organizations involved in the project (classic mistakes award winner )
Planning
-Failure to plan – diving into the performance and execution of work without first slowing down to think
-The underestimation of complexity (Classic mistakes award winner)
-Working under constant and excessive schedule pressure
-Assuming effort estimates can be directly equated to elapsed task durations without any buffers or room for non-productive time
-Failure to manage management or customer expectations
-Planning is seen as the Project Manager’s responsibility rather than a team activity
-Failure to break a large scale master plan into more manageable pieces that can be delivered incrementally
-Team commitments themselves to a schedule without first getting corresponding commitments from other groups and stakeholders who also have to commit to the schedule (aka schedule suicide)
-Unclear roles and responsibilities led to confusion and gaps
-Some team members are allowed to become overloaded resulting in degraded performance in critical areas of the project while others are underutilized
-Requirements are never prioritized resulting in team focusing energies on lower priority items instead of high priority work
-Failure to include appropriate culture change activities as part of the project plan
-Failure to provide sufficient user training when deploying the product produced by the project into its operational environment
-Failure to build training or ramp up time into the plan
-Change requests are handled informally without assessing their implications or agreeing to changes in schedule and budget.
Estimation
1.Those who will actually perform the work are excluded from the estimating process
2. Estimates are arbitrarily cut in order to secure a contract or make a project more attractive
3.Allowing a manager, sales agent or customer to bully the team into making unrealistic commitments
4.Estimates are provided without a corresponding statement of scope
5.Estimation is done based on insufficient information or analysis (rapid off-the-cuff estimates become firm commitments)
6. Commitments are made to firm estimates, rather than using a range of values that encapsulate the unknowns in the estimate
7.The assumptions used for estimating are never documented, discussed or validated
8.Big ticket items are estimated, but because they are less visible, the smaller scale activities (the peanut list) are omitted
9.Estimation is done without referring back to a repository of performance data culled from prior projects
10.Failure to build in contingency to handle unknowns
11.Assuming a new tool, process or system being used by the team will deliver instant productivity improvements.
Architecture and design
1. Allowing a pet idea to become the chosen solution without considering if other solutions might better meet the project’s overall goal
2.Teams start developing individual components without first thinking through an overall architecture or how the different components will be integrated together. That lack of architecture then results in duplication of effort, gaps, unexpected integration costs and other inefficiencies
3. Failure to take into account non-functional requirements when designing a product, system or process (especially performance requirements) results in a deliverable that is operationally unusable
4.Poor architecture results in a system that is difficult to debug and maintain
5.Being seduced into using leading edge technology where it is not needed or inappropriate 6.Developer “gold plating” (developers implement the Rolls Royce version of a product when a Chevy was all that was needed)
7.Trying to solve all problems with a specific tool simply because it is well understood rather than because it is well suited to the job in hand
8.New tools are used by the project team without providing the team with adequate training or arranging for appropriate vendor support.
Configuration and information management
1. Failure to maintain control over document or component versions results in confusion over which is current, compatibility problems and other issues that disrupt progress
2. Failure to put in place appropriate tools for organizing and managing information results in a loss of key information and/or a loss of control.
Team issues
1. Lack of clear roles and responsibilities result in confusion, errors and omissions
2. There are insufficient team members to complete the work that has been committed to
3. Projects are done “off the side of the desk” (i.e. team members are expected to perform full-time operational jobs while also meeting project milestones)
4. The team lacks the Subject Matter Expertise needed to complete the project successfully
5. Selecting the first available person to fill a role rather than waiting for the person who is best qualified
6. Failure to provide team with appropriate training in either the technology in use, the processes the team will be using or the business domain in which the system will function
7. Lack of feedback processes allows discontent in the team to simmer under the surface
8. The Project Manager’s failure to address poor team dynamics or obvious non-performance of an individual team member results in the rest of the team becoming disengaged
9. Practices that undermine team motivation
10. Pushing a team that is already exhausted into doing, even more, over time
11. Adding more resources to an already late project causes addition strain on the leadership team resulting in even lower team performance (Brooks law).
Project tracking and management
1. Believing that although the team is behind schedule, they will catch up later
2. The project plan is published but there is an insufficient follow-up or tracking to allow issues to be surfaced and addressed early. Those failures result in delays and other knock-on problems
3. Bad news is glossed over when presenting to customers, managers and stakeholders (aka Green shifting )
4. Dismissing information that might show that the project is running into difficulties (i.e. falling prey to the “confirmation bias”)
5. Schedule and budget become the driving force, as a result corners are cut and quality is compromised (pressure to mark a task as complete results in quality problems remaining undetected or being ignored)
6. Project is tracked based on large work items rather than smaller increments
7. Failure to monitor sub-contractor or vendor performance on a regular basis
8. Believing that a task reported by a team member as 90% done really is 90% done (note often that last 10% takes as long in calendar time as the first 90%)
9. Believing that because a person was told something once (weeks or months ago), they will remember what they were asked to do and when they were supposed to do it (failure to put in place a system that ensures people are reminded of upcoming activities and commitments).
Risk management
1. Failure to think ahead and to foresee and address potential problems
2. Risk management is seen as an independent activity rather than an integral part of the planning process
3. Risk, problems, and issues become confused as a result team isn’t really doing risk management.
Quality
1. Quality requirements are never discussed, thereby allowing different people to have different expectations of what is being produced and the standards to be achieved
2. Failure to plan into the project appropriate reviews, tests or checkpoints at which quality can be verified
3. Reviews of documents and design papers focus on spelling and grammar rather than on substantive issues
4. Quality is viewed simply in terms of testing rather than a culture of working
5. The team developing the project’s deliverables sees quality as the responsibility of the Quality Assurance group rather than a shared responsibility (the so-called “throw it over the wall” mentality)
6. Testing focuses on the simple test cases while ignoring the most complex situations such as error and recovery handling when things go wrong
7. Integration and testing of the individual components created in the project is left until all development activities are complete rather than doing ongoing incremental ingratiation and verification to find and fix problems early
8. Testing in a test environment that is configured differently from the target production, or operational environment in which the project’s deliverables will be used.
Related Topics:
The Author: Ala'a Elbeheri
About:
A versatile and highly accomplished senior certified IT risk management Advisor and Senior IT Lead Auditor with over 20 years of progressive experience in all domains of ICT.
• Program and portfolio management, complex project management, and service delivery, and client relationship management.
• Capable of providing invaluable information while making key strategic decisions and spearheading customer-centric projects in IT/ICT in diverse sectors.
• Displays strong business and commercial acumen and delivers cost-effective solutions contributing to financial and operational business growth in international working environments.
• Fluent in oral and written English, German, and Arabic with an Professional knowledge of French.
• Energetic and dynamic relishes challenges and demonstrates in-depth analytical and strategic ability to facilitate operational and procedural planning.
• Fully conversant with industry standards, with a consistent track record in delivering cost-effective strategic solutions.
• Strong people skills, with proven ability to build successful, cohesive teams and interact well with individuals across all levels of the business. Committed to promoting the ongoing development of IT skills throughout an organization.
Post a Comment