You Deserve a Break
Assimilation is the process of learning and understanding something so fully that you can use the skill without thinking about it. For new features and functions, assimilation is to absorb and adopt them so they become habits. Once a project is delivered it takes time for the features and functions to be fully understood and assimilated into the business operations or a daily routine. The more complex the features and functions the harder it is to absorb and adopt skills and turn them into habits. In addition, the larger the number of new features and functions the longer it takes for them to become habits. The time between the number and complexity of features and functions introduced before they become habits is exponential, not linear.
The Standish Group has long advocated that organizations deliver application or system functions and features using microprojects. Microprojects deliver a limited number of functions and features. This technique improves application assimilation. However, the time between assimilation and the delivery of the next microproject with a wave of new features and functions is often too short. Therefore, The Standish Group promotes the benefits of taking a break from the application. Benefits of a break include improved feedback and buy-in. The major benefit of taking a break is the possibility for the cession of future microprojects for that application. In other words, you stop creating new features and functions and move that application into maintenance mode.
Application cession or resolution can be accomplished at any time the users and stakeholders are satisfied with the application and the delivered features and functions. A good place to consider this event is after the delivery of a microproject. Two charts in our Modernization in Place paper depict both the usage and value of features and functions. It is clear from the data in these charts that developing all the features and functions is a waste of time, money, and resources. In addition, overbuilding or completing an application can lead to higher maintenance costs and delays in future valuable features and functions.
One of the drawbacks of delivering application features and functions in microprojects is the inevitable backlash and knee-jerk reaction from the users and stakeholders on the missing expected features and functions. This is where a break really helps. Taking a two- to three-month break and having the team move on to another application lets the users and stakeholders grumble and gripe as they work with the current features and functions. During this period the users will typically find they do not really need many of the missing features and functions. They will also find they do not need some of the delivered features and functions. This means the first thing a team should do after the break is a refactoring microproject. After the refactoring microproject the team and the users will be more in-tune for the next microproject or acceptance of the application as complete.