ICT deals are unlike other technical deals. Whilst engineering deals may be ‘complicated’ with their detailed technical details, ICT deals are often exponentially more ‘complex’ because they blend loose business concepts with technical specifications. Technical success is pegged to business benefits or unknown end states at the end of lengthy business transformations based on multiple increments of capability. For this reason the standard Colour Phases of bid development do not adequately support large, complex ICT deals. Robust process is a must in order to ensure adequate cross-functional collaboration across large, dispersed organisations. However, tech deals need to evolve through iterative stages of architectural development. The diagram below sets out a colour phased development lifecycle for large and complex tech deals. In this way, they get the process to manage the organisational governance as well as the architectural focus necessary to develop a winning value proposition.
The issue is never designing the solution it is unpicking it. Tech deals are not only complex they are aggregations of complexity: security systems, infrastructure, applications, business rules, benefits, integration – it all develops in isolation and it all has its own logic and its own costings and commercial parameters. It does, however, all work together. So, when it comes to the end of the bid and the team have to reduce costs in order to hit their estimated price-to-win it is somewhat akin to playing a giant game of “Kerplunk“. Straw by straw the architecture is unpicked and all the stakeholders around the metaphorical table just hold their breath and hope that not all the marbles fall down. If they don’t it is pure luck.
Technical ICT architectures are not like normal technical engineering projects or other capital works. The customer is not building an independent means of production. ICT (less robotic systems, i.e. embedded technology) is an integral and entwined part of business capability. It is inextricably linked to the business. If the dots are not all joined at the outset of the bid then when it comes to reducing costs at the end, the executives will strip down random parts of the technical solution which is usually the foundation of the value proposition. What will be left is a patchy solution that has obvious structural weaknesses (to the intelligent customer).
The problem is how to design elegant and sophisticated architectural solutions within cost, commercial and time parameters. The individual system components will be designed in splendid isolation with a variety of assumptions and guesses. The entire solution, however, needs to be designed, costed, stress-tested and reviewed within tight timeframes and against aggressive price points. In order to lead a large and disparate (often virtual) team to achieve these goals will take a robust process and a strong personality exerting herculean effort. The crux of the matter is how to manage varied personalities through a convoluted development process without stifling the elegance of the design yet still manage to corral such strong temperaments through tight review gates.
The solution is a blend of both the traditional colour-phased bid structure and the complexities of the architectural development process. Together it might be referred to as Colour-Phased Architecture. In this way the bid team are cognisant and appreciative of the subtleties and complexities of the architectural design process and the executive get a strong process which even the strictest governance may rely on.
Adapting Krutchen’s 4+1 Views the architecture is developed through 5 critical structures:
- Use Cases. The Customer narratives and scenarios are developed to produce and update the various iterations of the architectural solution.
Architecture. The solution should develop through 4 iterations:
- Logical – This will ensure that it is anchored by the strategy and accurately reflects it.
- Physical – This is where specific solutions are developed and the tighter parameters are loaded.
- Transition – This addresses the specific issues around the deployment, transition and change management issues for the customer.
- Transformation – The vendor should make the majority of the margin during this phase and so much of the strategy, modelling should focus on the incremental capability uplifts. This is where the primary benefits realisation management should focus.
The architecture of the solution is defined by a careful communication between elements. The interaction between the structural colour-phases and the functional solution development supports this in two ways: (i) the Use Cases inform the design of the solution, and (ii) the phases inform the development of the solution. Initially, the customer use cases determine solution design. The solution must be derived from a desire to solve the customer’s problem. A list of requirements is essential and usefully but may only result in a patchwork quilt of technical components and business benefits. The logical solution will then be molded and developed using the vendor strategy and broad parameters.
The physical solution along with more detailed attention to the Transition and Transformation stages is then pushed through another 3 phases of development. In this way, the team ensures that the architecture is not only technically comprehensive but that it is a sensible, well costed solution that will meet the customer’s needs well into the future.
The colour phases are essential because without them the architectural development process would just spiral out of control. The colour phases ensure:
- that the development of the solution occurs within a structured governance framework,
- that there is cross-functional collaboration between the technical silos and the commercial support, and
- that the progress of development is measurable and communicable to the non-technical executive.
To that extent there are 4 essential phases to ensure that the technical solution does not exist in splendid isolation but is a well costed, commercially sensible plan to make money by delivering something which plays to the vendor’s strengths whilst delivering something of real value to the customer. In order to do that the process must ensure it develops:
- Strategy. The strategy must be developed from the outset. Architecture is not strategy. Without strategy there is nothing to anchor the technical development with and nor is there anything to prod and cajole business partners with.
- Architecture. Solution development is only part of the process. As with any design process, the artistic talents and temperaments of the team must be constrained and focused.
- Commercials. The commercials have to be right. No matter how elegant or sophisticated the solution, unless it works commercially it will not be signed off.
- Viability & Review. The solution must be able to be reviewed internally by peers and colleagues. It must exist as a coherent body of documents (which will be pulled together into the bid document). The team must be able to prove that the solution will work over the long term and exist as a part of the customer’s enterprise architecture.
There is both art and science in the design, development and management of large and complex bids. Bids team not only require the gravitas of deep technical ability but also leadership and communication skills. Without these the solution will not be balanced but rather a mess of technical solutions competing to over-deliver functionality. There is no easy way to navigate the issue but a colour-phased process of architectural development blends the best of both worlds into a practical and deliverable lifecycle.
Figure 1 – A colour-phased lifecycle for technical bids.