20 Ways to Tell If Your Project Planning Is Taking Too Long

I see too many organizations spending too much time in project planning. Actually, I take that back. They spend too much time thinking they are planning. If you want to be agile, you need to deliver software. Planning helps get you there but it can also get in the way if you over do it.

With that in mind, here are 20 ways to tell if your company is spending too much time planning the project, and not enough time delivering it. (Warning: A few of these may be slightly over the top — at least I hope they are!)

1. The business stakeholders are asking “Is the software done yet?” and you’re still planning.
2. The requested delivery date for the software passes and you’re still planning.
3. You spend more time in planning meetings than you do with your family.
4. Every time you go to a planning meeting, you meet new people.
5. You have to schedule meetings to plan the planning meetings.
6. You call meetings but no one shows up any more.
7. You’ve revised the planning documents at least 5 times.
8. The planning documents are so complex you create a taxonomy to organize them
9. The planning document set is so large you can’t use email to distribute it.
10. Everyone answers “I’ll get back to you.” to information requests yet no one ever does.
11. Writing the code is expected to take 4 weeks yet the planning has dragged on for 6.
12. People assigned to work on the project are being re-assigned.
13. Writing your risk management plan has become a project in itself.
14. The name of the project has changed at least twice.
15. Your email distribution list is so long you need Constant Contact to manage it.
16. Every time you print your planning documents the printer runs out of toner.
17. The same issues, discussions and debates occur over and over again.
18. The development team spends more time playing video games than writing code.
19. The business, tired of waiting, shows you prototype software they are developing on their own.
20. You’ve been planning for so long that the original project goals are no longer valid.

I’m fairly sure you’ve witnessed at least one of these patterns in at least one of your projects. The cure? Stop. Just stop. Write some software. Test it. Deliver it. Plan a little more — caution, I said a little. That’s how agile teams do it.

Have anything to add to the list?