There is a very insightful passage that Roger Pressman1 quotes from a paper by Nogueira and colleagues that needs to be quoted in full:
The edge of chaos is defined “a natural state between order and chaos, a grand compromise between structure and surprise”. The edge of chaos can be visualized as an unstable, partially structured state… It is unstable because it is constantly attracted to chaos or to absolute order.
We have the tendency to think that order is the ideal state of nature. This could be a mistake. Research…. supports the theory that operation away from equilibrium generates creativity, self- organized processes, and increasing returns. Absolute order means the absence of variability, which could be an advantage under unpredictable environments. Change occurs when there is some structure so that the change can be organized, but not so rigid that it cannot occur. Too much chaos, on the other hand, can make coordination and coherence impossible. Lack of structure does not always mean disorder.
In a SharePoint based project, for example, I found that the management of user requirements can best be done by managing them in an agile based manner, even though the overall project was done in waterfall model. The diagram below (from the Ambysoft site) proved to be very useful.
- Use Case
- Priority (High/ Medium/Low)
- Development Complexity (High/ Medium/Low)
- OOTB/RUC/Configuration/ Customization
- Iteration in which the feature will be built
OOTB: out of the box feature available in SharePoint to be used without any changes
RUC: Reusable component already available
Configuration: an OOTB feature but needs significant amount of effort in configuring it
Customization: Feature that needs custom code to be written, for example, in C#
By keeping the above parameters visible to the customer and end users, I found that it was very easy to negotiate as each iteration of the system was built. Each time this re- stacking was done, a number of features that were initially high priority go down the stack as users became aware of the implementation complexity and its impact on timelines and cost. This negotiation is required because there are always the constraints of time and funds. This excel sheet based “requirements stack” is pretty much all one needs for projects based on platforms like MOSS 2007.
(1) Roger S. Pressman, Software Engineering: A Practioner’s Approach, 6th Edition (2005), page 77