The difficulties of an overly-complex Program
A complex system is difficult to build in view of the number of interactions between its elements.
We often talk about a "can of worms" to refer to complex IT Solutions. Each time we change one part of the Solution, we destabilize the overall solution: the "non-regression" tests, which are designed to check that the Solution remains robust despite the most recent changes, sometimes turn out to be far more expensive than the modification itself: we can carry out a modification in a week and then execute non-regression tests during 2 months. When a problem appears, correcting it takes even longer as we have to search for the cause in too big a whole.
The only method consists in architecturing the Solution in Modules so that the number of interactions is more limited.
This strategy does not just have an advantage of overall simplification. It also enables us to deliver the initial concrete results quickly to the Operational users, it avoids the tunnel effect and gives credibility to the Program because the initial Projects deliver Value fast through the first Modules. It is also a way of gradually testing the viability of the Solution without waiting for an overall delivery at the end of the Program.
But how do we divide up a Program into Projects?
How to divide up a Program into Projects
Build the framework before the Solution
Each Project of the Program will be easier if it is part of a well-structured framework. The clarity of scope, the preciseness of the interfaces with the other Solutions, the reuse of Information access Functions are all assets in focusing the energy of the Project manager on his/her Model and not on the environment.
Before beginning to build the initial solution, we have to have a framework at our disposal into which the solution will fit. This framework has two dimensions:
Simplify the existing system little by little
When the complex Solution is already in position and we want to simplify it, another possible strategy is to gradually simplify the Solution as the Projects advance.
To define the road map of gradual simplification, we have to isolate little by little the information access components to make data evolution independent of software evolution. Then we gradually isolate the reusable Business Functions. From there, deduce standardized interfaces between Solutions.
This strategy has been defined in the CEISAR white paper entitled "Simplify Legacy Systems": we recommend that interested readers download this white paper from www.ceisar.org.
The first Version of a Solution is the most difficult
Creating Version 1 of the Solution is more expensive than each of the following Versions as it includes Building the Solution and the Foundation Architecture, which will be kept by each of the following Versions.
But, in view of the life span of the Solutions, the total costs of Versions 2 to n represent 2 to 3 times the original cost of Version 1. Agility is therefore not only the art of Building the first version of the Solution fast, it is also the art of Building, right from this first Version, an efficient Solution Architecture enabling the following Versions to benefit. Agility at a given time (T) must not mortgage agility at T+1: this is the definition of sustainable development applied to Information Systems.
Give a "Business" meaning to the division
It is also important that the project milestones correspond to "business stages", that is to say stages that make sense to the business and not just to IT. Otherwise, it will be very difficult to get the buy-in of business partners to the project. We must therefore be more than capable of "telling a story" around the project, and talking about the business value brought at each step.
The story of George the Baker is made available under the terms of the
Creative Commons Attribution - NoDerivatives 4.0 International license.