I think speed is meaningful within software projects as well. The agile folks have virtually abandoned the idea of plan & estimation driven project planning in lieu of velocity based approaches. The traditional views tried to anticipate the future early on in projects by carefully reviewing requirements, planning end-to-end, and exhaustively estimating tasks (perhaps padding or buffering for all of the inherent uncertainty) all focused towards accurately predicting project outcomes.
Now here comes the bad news, at least for most projects. They rarely got it right and the majority of projects disappoint in some fashion. While I really hate statistics because they’re usually taken out of context, the most recent Standish Group - Chaos Report does provide some insight into this point. And again, I reference it ONLY to show a general view to our track record. The sad news it that we fail on roughly two thirds of our projects. The even sadder news is that we've failed to significantly improve from 1994 - 2006 on these statistics even given our focus on tools, process improvement and methodologies. (read the fine print in the report and only differentiate between success and failure)
Instead of taking that up-front planned approach, what if you iteratively progressed through a project? Of course, you would have made a high level, large grained plan for it. Consider it a road-map if you will. But you would not fool yourself into believing that you can predict every nuance and outcome.
Instead, you could measure frequent deliveries of features or functionality and the effort associated with those features. That becomes your velocity for future work and you adjust your higher level plan as appropriate—based on the realities of your teams' raw capacity. If you want to go faster, then apply some changes. For example adding people, but before getting too rambunctious, measure the velocity implications of the change to be grounded in realism.
That's how the agile methodologies approach project planning - basically aligning a High Level view to a very realistic and velocity based iterative view to performance. Then connect the two for forecasting.
Another part of the agile speed equation is delivering high value features quickly. Once you understand what has value, you want to get it into the hands of the customer as quickly as possible—to determine if it meets their expectations or not. In other words, are you DONE? This philosophy is threaded with notions of Just Enough and Just in Time in your efforts. Instead of working on massive feature sets and delivering (or not) at the end, building incrementally creates a wonderful, earned value and feedback loop that is essential for measuring your TRUE speed and not some artificial interpretation without gaining feedback.
So, if you want to go truly fast:
- work iteratively
- project your delivery based on real team velocity
- and work on the most important things first