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!)
- The business stakeholders are asking “Is the software done yet?” and you’re still planning.
- The requested delivery date for the software passes and you’re still planning.
- You spend more time in planning meetings than you do with your family.
- Every time you go to a planning meeting, you meet new people.
- You have to schedule meetings to plan the planning meetings.
- You call meetings but no one shows up any more.
- You’ve revised the planning documents at least 5 times.
- The planning documents are so complex you create a taxonomy to organize them
- The planning document set is so large you can’t use email to distribute it.
- Everyone answers “I’ll get back to you.” to information requests yet no one ever does.
- Writing the code is expected to take 4 weeks yet the planning has dragged on for 6.
- People assigned to work on the project are being re-assigned.
- Writing your risk management plan has become a project in itself.
- The name of the project has changed at least twice.
- Your email distribution list is so long you need Constant Contact to manage it.
- Every time you print your planning documents the printer runs out of toner.
- The same issues, discussions and debates occur over and over again.
- The development team spends more time playing video games than writing code.
- The business, tired of waiting, shows you prototype software they are developing on their own.
- 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?
Leave a comment
- June 2013 (8)
- May 2013 (13)
- April 2013 (13)
- March 2013 (13)
- February 2013 (12)
- January 2013 (12)
- December 2012 (7)
- November 2012 (11)
- October 2012 (12)
- September 2012 (8)
- August 2012 (11)
- July 2012 (13)
- June 2012 (12)
- May 2012 (13)
- April 2012 (13)
- March 2012 (13)
- February 2012 (12)
- January 2012 (13)
- December 2011 (12)
- November 2011 (12)
- October 2011 (13)
- September 2011 (14)
- August 2011 (18)
- July 2011 (13)
- June 2011 (18)
- May 2011 (19)
- April 2011 (16)
- March 2011 (21)
- February 2011 (20)
- January 2011 (22)
- December 2010 (21)
- November 2010 (16)
- July 2010 (2)