Here's a look at some of the issues to be addressed in the words of LeadingAnswers:
- Specification problems – software projects are hard to define because they are intangible and hard to reference.
- Evaluation Problems – We really need to see and use software to say if it is suitable for us, reading a spec is a poor method for validating functionality. IWKIWISI – I Will Know It When I See It applies.
- Knowledge Worker domain – we are using subject matter experts to collaborate and share information rather than industrial works to repeat a defined process.
- Speed of business change – system requirements change frequently as businesses evolve and change. Change rates are higher than in many other project domains.
- Building with bits and not atoms – we are manipulating information and models not concrete and steel so our processes and controls need to be different.
- Non-Linear progression – progress is often non-linear. Some things go quickly some things take a long time. Approaches that assume a linear progression to completion are more problematic to apply on software projects.
- Uncertainty – We have more technology uncertainty and requirements uncertainty than many other industries and so need more tools to checkpoint and adjust if necessary.
- Extreme modifibility – unlike physical construction where is difficult to move a bridge upstream when it is 75% complete, there are some changes that can be done late in software projects that have few parallels in other domains.
Here's my take: Software projects are "idea" projects. They are almost without boundary, both internally and externally. Not entirely of course: where the software meets the hardware, there is a boundary to be sure, especially if you are developing for an embedded processor, like a guidance computer in the tip of a weapon.
About ideas: ideas have no natural limitations: we all know that; it's unreasonable to imagine all ideas are ever known; ideas are volatile; ideas emerge and evolve with experience; ultimately ideas drive vision; and vision is the source of business value.
So, software projects are always going inherit the basic properties of ideas. As such, we need methods and management paradigms like agile to deal with ideas.
At the same time, projects more often than not spend other people's money (OPM). When you are responsible--and, gasp!, accountable--for OPM, your whole perspective changes. Order and predictability become very important.
A marriage of enterprise management skills and agile management skills perhaps is the answer. Anyway, that's what I been saying for a few years now.
