Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

10 reasons why projects fail or common mistakes to avoid

23.821 Aufrufe

Veröffentlicht am

The goal of this presentation it to summarize practical experience and theoretical knowledge to outline 10 main reasons for the projects failure and common mistakes you can avoid on your projects to make them succeed. I hope you will find good tips and a valuable practical advice while reviewing it.

10 reasons why projects fail or common mistakes to avoid

  1. 1. Why projects fail? July 26, 2014
  2. 2. Why projects fail? 2
  3. 3. 3
  4. 4. Project success factors 1. Meet an agreed budget (Cost) 2. Deliver on time (Time) 3. Meet quality requirements (Quality) 4. Meet the project's objectives/requirements (Scope) 4
  5. 5. What projects are considered successful? Long story short – successful project is the one meeting stakeholder’ expectations 5
  6. 6. Reason 1: Insufficient stakeholders management Common mistakes: 1. Not all the project stakeholders are identified 2. Stakeholders are not analyzed from the perspective of their influence and interest in the project 3. Failure to view the project through the eyes of the project stakeholders, as the result no accurate understanding how the project will impact the stakeholders or how they will react to the project’s results 4. Failure to identify and meet the needs of all stakeholders, allowing one stakeholder group to dominate the project while completely ignoring the needs of other groups 5. Failure to establish effective communication channels between different stakeholders 6
  7. 7. Who are your stakeholders? 7
  8. 8. Stakeholders Management 1. Identify Stakeholders – identifying everyone affected by the work or its outcomes 2. Plan Stakeholder Management – deciding how you will engage with the stakeholders 3. Manage Stakeholder Engagement – communicating with stakeholders and ensuring appropriate stakeholder engagement 4. Control Stakeholder Engagement – monitoring the overall relationships and adjusting your strategies and plans as needed 8
  9. 9. Stakeholders influence on the project 9
  10. 10. Reason 2: Inefficient communication 10
  11. 11. Common mistakes: 1. No time is spent on development of a communication plan 2. No identified and approved escalation boundaries and related rules (when and to whom to escalate issues) 3. Roles and responsibilities are not identified or are not clearly communicated to all the stakeholders 4. Priorities of different communication channels are not identified (when to email, to call, to use Skype, etc.) 5. No records for oral communication (no meeting minutes) 6. National specifics and corporate culture are not taken into account (when to CC management, whether it is appropriate to CC senior management, whether Manager in CC is treated as an escalation or you just want to keep other stakeholders informed, etc.) 7. Manager blocks direct effective communication between technical specialists 8. Bad news are glossed over when being presented to customers, managers and stakeholders 9. Too much meetings, unnecessary people are invited to the meetings 10. Meetings are not effective (no goal set, no agenda, etc.) 11 Common communication mistakes
  12. 12. 12
  13. 13. Reason 3: No sufficient project initiation and planning phases Common mistakes: 1. No project initiation and/or planning phases at all 2. Working under constant schedule pressure, not spending enough time and efforts to plan the project 3. Assuming effort estimates can be directly equated to elapsed task durations without any buffers or room for non-productive time, unforeseen tasks, etc. 4. Planning is done based on 8 h/day team availability for planned tasks 5. Planning is seen as the project manager’s responsibility rather than a team activity 6. Failure to break a large scale master plan into more manageable pieces that can be delivered incrementally 7. No milestones and deadlines are set 8. Unclear roles and responsibilities led to confusion and gaps 9. Un-prioritized requirements resulting in team focusing energies on lower priority items instead of high priority work 10.Change requests are handled informally without analysis and management of their implication to the project plan 13
  14. 14. Reason 4: Project constraints are not identified Common mistakes: 1. Project constraints (Scope, Time, Budget, Quality) are not identified and discussed with the client 2. Project constraints are not taken into consideration during the project initiation and planning phases 3. Project constraints matrix is not created and not discussed with the stakeholders 14
  15. 15. Constraints Matrix 15
  16. 16. Reason 5: Poor product requirements Common mistakes: 1. Product development starts without requirements  It happens! 2. Requirements are not Unitary, Complete, Consistent, Current, Verifiable, Unambiguous, Traceable, Prioritized 3. Requirements are not tested 4. Lack of formality in the scope definition results in different people having different understanding of what is in and what is out of scope 5. Open ended requirements (such that end with “etc.”) 6. Failure to fully understand the “big picture” - the operational context in which the product being produced needs to function once the project is over 7. No or lack involvement of those who will eventually use the product during the requirements development 8. Individual requirements are never checked against the project’s overall objectives to ensure each requirement supports the project’s objective 9. The project requirements are written based on the assumptions 16
  17. 17. 17
  18. 18. 18
  19. 19. Why projects fail according to Gartner research Source: Gartner Survey, Analyst : Lars Mieritz. Published: 1 June 2012 ID:G00231952 19
  20. 20. Reason 6: Inaccurate estimates Common mistakes: 1. Failure to not involve those who will actually perform the work to the estimating process 2. Forcing the team to provide estimate without a defined scope 3. Forcing the team to cut the estimate in order to secure a contract or make a project more attractive 4. Estimation is done based on insufficient information or analysis 5. The assumptions used for estimation preparation are not documented, discussed or validated 6. Big items are estimated, but because they are less visible, the smaller scale activities are omitted 7. Estimation is done without analysis of the historical data collected from previous similar projects or phases of the existing project 20
  21. 21. Reason 7: No streamlined software development process Common mistakes: 1. No methodology is used (as is or tailored to project specifics) 2. The project plan is published but there is no follow up or tracking to allow issues to be surfaced and addressed early 3. Believing that although the team is behind schedule, they will catch up later 4. Schedule and budget become the driving force 5. Project is tracked based on large work items rather than smaller increments 6. Failure to monitor team performance on a regular basis 7. Believing that a task reported by a team member as 90% done really is 90% done  8. 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 9. No recurring review and demonstration of the work done 10. No value increment is added on recurring basis 11. No retrospective of the process and no analysis of its gaps and required improvements 21
  22. 22. How often do PMs use a project management methodology on successful and failed projects? Source: KPMG Project Management Survey 2013 22
  23. 23. 23
  24. 24. 24
  25. 25. Reason 8: No risk management Common mistakes: 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 and execution process 3. Risk, problems and issues become confused as a result team isn’t really doing risk management 25
  26. 26. 26
  27. 27. Reason 9: Insufficient quality assurance (not to be mixed up with software testing) 1. No quality assurance activities are planned, only software testing activities are performed 2. No systematic activities are performed to evaluate quality of the development process used to produce a product 3. Failure to plan into the project appropriate reviews, tests or checkpoints at which quality can be verified 4. Quality requirements are never discussed, thereby allowing different people to have different expectations of what is being produced and the quality standards to be achieved 5. Quality is viewed simply in terms of testing rather than a culture of working 6. The team developing the project’s deliverables sees quality as the responsibility of the Quality Assurance group rather than a shared responsibility 7. 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 8. Testing with a test data only 9. No proactive measures to prevent bugs from occurring in a product being developed, only reactive measures to address found issues 27
  28. 28. Reason 10: Decision making problems 1. Decision makers and areas of responsibility are not identified 2. Key decisions are made by people who lack the subject matter expertise to be making the decision 3. Expert advice is not requested when making key project decisions 4. Lack of situational awareness results in ineffective decisions being made 5. Failure to bring closure to a critical decision results in delays, unused time, team demotivation 6. Team avoids the difficult decisions because some stakeholders maybe unhappy with the outcome 7. Team is not involved into the decision making process (when appropriate) 8. Key decisions are made without identifying or considering alternatives 9. Decision fragments are left unanswered (what to be done, how to be done, when to be done, who are performers, who IS responsible for the outcome, etc.) 10. Failure to establish clear ownership of decisions and responsible people 28
  29. 29. 10 reasons why projects fail? 1. Insufficient stakeholders management 2. Inefficient communication 3. No sufficient project initiation and planning phases 4. Project constraints are not identified 5. Poor product requirements 6. Inaccurate estimates 7. No streamlined software development process 8. No risk management 9. Insufficient quality assurance (not to be mixed up with software testing) 10. Decision making problems 29
  30. 30. 10 rules to make your projects succeed! 1. Identify and manage project stakeholders and their expectations 2. Setup effective communication channels and escalation boundaries, run effective meetings, always keep records 3. Do spend time on the project initiation and planning phases 4. Identify project constraints with stakeholders and document those, always keep them in mind through the project length 5. Do no start software development with poor product requirements and not defined scope 6. Learn how to improve accuracy of estimates, collect and analyze historical data and previous experience 7. Follow software development methodology – tailor the existing one or develop you own. The process should be defined and streamlined to be controlled! 8. Do risk management, foresee problems and address potential problems 9. Software testing is not enough, do quality assurance activities and make quality a working culture 10. Make decisions fast and smart 30
  31. 31. … and a piece of advice  1. Any experience, including failures and mistakes, is your chance to learn and self-develop 2. When you enjoy what you are doing you are way more effective and productive 3. Something interesting and challenging can be found in any assignment if you keep being positive, open-minded and creative 4. Thinking out of the box helps to find good and new solutions 5. When you are working hard and doing your best, people around respect you and appreciate what you are doing 6. Positive attitude always help to find the right solution 7. People are over process  - respect yourself, your colleagues and clients 31
  32. 32. Thank you! Dev-Pro.net 7260 W. Azure Dr Suite 140-829, Las Vegas, NV 89130 USA ©2014 Dev-Pro.net, Inc. All Rights Reserved 32