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 » »