Public Impediment List – Charleston Mar 2014

I am a big advocate of each team having a public impediment list.  Elsewhere I describe that in more detail, and describe some issues with it.  The key thing: the main purpose of the list is to enable us to fix the ‘best’ impediment faster or sooner.  We don’t just have a list to do NOTHING. (Apparently some people think so.)

In the recent course in Charleston they identified the impediments below.  You may or may not agree.  There may be duplicates (although maybe a rough indicator of greater impact).  Maybe some are not clear to the reader, but only to the writer or that Team.  The order is random.

We hope this list makes your Team more creative in identifying its ‘best’ impediments.

  1. Small group supporting sustaining work
  2. Lack of experience (skill set)
  3. Knowledge transfer
  4. Automated build-test / quality
  5. Requirements traceability
  6. Loading radios [To test the functionality of the software in the radios]
  7. Schedule tight
  8. Undefined goals
  9. Inexperienced people
  10. Shifting priorities
  11. Hiring people
  12. Establishing a team
  13. Unresponsive vendors (external)
  14. Issue with external system not in our control
  15. Moving timeline, target date
  16. Lack of ownership from product owner
  17. Changing scope
  18. Team concept
  19. Work distribution
  20. Lack of knowledge
  21. Inaccurate information
  22. No mitigation strategy [for risks, I think]
  23. Lack of buy-in
  24. No planning
  25. Inexperienced people
  26. Insufficient client management
  27. Not understanding client’s true needs
  28. Inadequate skills
  29. Inefficiency
  30. Changing personnel
  31. Over-committed [given too much work, I think]
  32. Don’t understand process
  33. Team not on same page
  34. Lack of pre-plan
  35. Lack of ownership [by team, I think]
  36. Adequate training (lack of)
  37. Weak company management
  38. Failure to commit
  39. Weak PM [in Scrum terms, I might say weak SM — depends what he/she meant by PM]
  40. Changing goals, moving target
  41. Lack of resources, HW, SW
  42. Weak IT
  43. Risk mis-management
  44. Failure to communicate
  45. Do not understand goals
  46. Lack of teamwork
  47. No support
  48. Time Zones
  49. Change of vision
  50. Org not ready for change
  51. Budget
  52. Scope creep
  53. Unrealistic deadlines
  54. Mean team members
  55. Moving timetable
  56. Disorganized
  57. Lack of experience
  58. Under budget
  59. Poor stakeholder management
  60. Over budget
  61. Lack of leadership
  62. Unavailable team members
  63. Inconsistency
  64. No requirements
  65. Changing requirements
  66. Ins. budget [Insufficient budget, I think]
  67. Bad estimates
  68. Lack of participation
  69. Missed deliverables
  70. Poor attitudes
  71. Not enough tech knowledge
  72. Poor communication
  73. Product failure [one might need to identify the root causes here]
  74. Non compliant
  75. No gate reviews [In Scrum, each Sprint is a kind of ‘gate review’ — but not sure this would be enough for the person who raised this concern]
  76. Unrealistic scope
  77. Lack of commit
  78. Employee no shows
  79. Insufficient time allotment
  80. No leadership [person started with ‘A lack…’ and crossed that out]
  81. Creeping scope
  82. Change of scope
  83. Team incompetent [for this work??]
  84. Not enough people
  85. Inadequate schedule
  86. Lack of planning

***

To get this list, I asked two questions, one early and one later:

1. What are the root causes of failure in projects that you have seen?

2. We need to double velocity in 6 months, and we have to change radically.  What do we have to change to get the velocity (productivity) to double?

This may explain some of the duplicates.

 

« « Impediments – Raleigh-Durham Feb 2014 || Definition of Ready » »

Tagged:

Leave a Reply