| dc.description.abstract | Software projects have a long history of delivering projects over budget, behind schedule, and not meeting expectations. Software development teams have typically tried to follow the “waterfall” or building paradigm of “define, design, and develop” in a proscribed fashion. The problem with this approach is it provides no mechanism for innovation or evolution of the software. In reality users often don’t really know what they want in software until they see it in action and gain new insights on how they would like it to work.
The contrasting approach is “iterative development” where software is delivered as a series of working features. The family of development processes surrounding iterative development is referred to as “Agile Methodologies” and is characterized as being adaptable to change (Highsmith 2004). This approach embraces the uncertainty surrounding the requirements by measuring the project on vision, cost and schedule rather than scope, cost and schedule. The overall idea with this approach is to turn development into a collaborative process with the customer and illicit feedback early and often. This approach, in turn, allows development to adapt and evolve with change.
The challenge is applying these methodologies to small business environment. In the small business environment, budgets vary from very small to medium in scope, typically on the order of one week to three months. Projects also vary from completely new domain to those that just modify existing features. It is not realistic to follow the same process for these widely varied scenarios. It is also import that costs associated with documenting and managing project must scale with the nature of the project.
The author, through research and experience as a small business developer with Blue Ocean Consulting, lays out an approach that breaks the Agile methodology into phases. These phases provide a framework for skipping aspects of the process that are not needed in certain scenarios.
Projects that fall within a completely new domain would go into a discovery process to define vision, high level features, ballpark of investment, and data sheet. Projects that fall into an existing known domain but have completely new features would skip discovery and start with the analysis phase. Projects that are updates or expansions in the scope of existing features in an existing domain would jump right to the innovation phase. | |
