Agile Project Planning

ExtremePlanner: Agile Project Management for Distributed Software Teams
Click For Your Free Online Trial

Thursday, June 07, 2007

The High Cost of Management Indecision

Rob Walling writes about the high cost of management indecision on software projects.

Essentially, the argument is that even wrong decisions allow developers to keep momentum and push a project forward. The cost of reworking areas winds up being less than the cost of delaying, doing nothing, or switching to other tasks. Here's an excerpt about the cost for a team of 10 developers:

If we decide not to make any decisions we lose 10 times $822, for a total of $8,220 per week. Let me say that again: blanket indecision loses $8,220 per week; making decisions (including bad ones) loses $1,680 per week. That's a difference of $6,540 per week.

It's actually a pretty powerful argument for doing everything possible to lower the perceived cost of making a decision for managers or customers. Perceived cost is that fear-driven idea that if you make a certain decision, you'll be stuck with the results forever if it doesn't work out, due to the high cost of changing it.

This is exactly the problem that Agile methods were designed to solve. By reducing the perceived cost, we encourage our customers to make more timely decisions, learn from them, and adjust as needed without incurring high costs.

Of course, this doesn't necessarily apply to technical decision making. "Should I use a database or direct file storage?" is a question that doesn't need a final answer right now. The right question for technical decision points is "How can I encapsulate that?" That lets developers move forward while keeping the cost of future change low.

If it truly does cost more to delay management decisions, wouldn't it be wonderfully freeing to start making some?

Even if you don't have all the possible information you'd like?

Even if you could be wrong?

Labels: ,

Get your copy of the new book! Agile Thinking: Leading Successful Software Project and Teams


  • I agree and thanks for this note David. Just to add a few thoughts, consider iterative software development to be not just knowledge accumulation, but not creation, within an iterative cycle of data gathering, analysis, decision and action. What is critical is the realization that knowledge creation comes only through action. If we get frozen in indecision, for want of courage, we should remember that any action, any design or implementation of a story in agile development, will create new knowledge both within the team and in the customer's feedback on our artifact.
    This is just a bit of a spin on your valid argument regarding the cost of indecision. Add to this the fact that indecision incurs another cost - the delay in the required creation of knowledge on the path to the software product.

    By Blogger jd, at 12:32 PM  

Post a Comment

<< Home