The Hybrid Dynamic Model is a modern approach to structuring an organisations portfolio that allows for multiple ways of working to co-exist from innovation to utility work and for that work to change which processes, cultures and practices it uses over time.
An “Operating Model” describes how an organisation does its business in terms of both its structure and its behaviour – it is the business architecture. An “Operating Model” exists in every organisation, whether it is explicitly written down or simply a collection of processes and practices. The Operating Model includes how strategy flows through planning and delivery, how money is spent and controlled, how governance works, how people are organised and how quality is assured. If the Operating Model is inefficient or unable to react well to change, everything else suffers.
Many organisations evolve an Operating Model that fits their stable way of working, allowing for a focus on efficiency and improvement, driving out variation. This approach can work well in periods of stability but makes organisations brittle and unable to react well to change because the only way the organisation knows how to deal with events is to apply its tried and tested approaches. When the environment is less stable, or the variety of work types increases a Hybrid Dynamic Model is more appropriate.
As organizations recognize that their types of work are different they frequently evolve a Bi-Modal paradigm that involves treating New Investment differently from legacy operations. This creates a two-speed organization, often correlating with the use of Project Management for new work and managing out variance (e.g. with ITIL) for operations/support work. Bi-Modal IT is short sighted, as it doesn’t account for evolution and change. Instead we recommend considering Commoditization as a way of thinking about types of work.
Bi-Modal IT is an example of the black-or-white logical fallacy
A useful mechanism for understanding different types of work, and the different approaches that may be applicable to delivering them within a portfolio is the “Commoditization Scale”. The Commoditization Scale describes a range of types of work from innovation (undefined, rare, speculative and high risk) to more commodity/utility (well defined, ubiquitous, and less differentiated with lower risk).
These different types of work require different ways of working, contractual models, technologies, supply chains, cultures, processes etc. More well understood work is more predictable and manageable by its nature, whereas the opposite is true for less well-understood work.
Commoditization scale originally inspired by Simon Wardley, LEF CSC
As organisations begin to understand their work in terms of a hybrid model they can then look to actively apply a commoditization pressure where possible moving work across this scale. Because commodity solutions (often bought in) are typically cheaper than in-house development, maintenance and hosting commoditizing work earns a "Commoditization Dividend" which can then be used to reinvest into the Innovation parts of a business.
As mentioned in Build or Buy we generally recommend against building utility or commodity components, systems or product (unless disrupting a service industry) - these kind of products are best bought (COTS) or provided by open source alternatives. However, in terms of inventing/innovating and specialist products we see that different processes, working practices, teams and cultures may be necessary. Innovation work is typically riskier and more speculative than more mainstream specialist product development and so will be less tolerant of up front planning. "Failing fast" is particularly important in innovative/inventive work and this type of work is often very unpredictable. As a result, building significant structure (in terms of project, programme and Solution Architecture) around innovation work is unlikely to be productive - this work may also be unconstrained, thought informed, by Enterprise Architecture (and indeed "standard" ways of working).
Unless explicitly necessary we recommend that innovative work is treated as self-organized Product Delivery teams that are directly part of the Portfolio, with no programme structure. This (Small Picture) model is preferred for small, simple projects or organizations generally. Small organizations can often outperform large monolithic organizations due to their lack of process, management and architectural inertia - they are free to innovate. Since the relentless commoditization of technology forces all organizations to innovate to survive we strongly recommend freeing people to innovate in whatever manner they need.
There's nothing worse for innovation than an ideas process
Similarly, and perhaps counter intuitively, there is also less structure required in the Utility and Commodity areas of the commoditisation scale (because the products built are often well-understood, predictable and frequently COTS, much of this work is system integration). This type of very predictable work often benefits from workflow management techniques such as Lean, Kanban or service management processes.
Products that are more Specialist may need a "bigger engineering" approach depending on their scale or risk factors. Many large organizations will adopt more formal processes in this area as they seek to find economies of scale, especially around reuse. However, over time reusable platforms and architectures can become a hindrance rather than a help. Technically skilled people will notice this point and are encouraged to Bubble Up their concerns. Organizations with significant effort in more than one of these areas of the scale above tend to gravitate towards a hybrid model with a structure embedded in the Specialist, Commodity or Utility part of the business. Applying the same structures, architectures, processes and working practices across all of these work types, ignoring their differences, can cause serious problems so a hybrid model is likely to be required for large/complex organizations.
We recommend using a hybrid, dynamic model for organising a large/complex portfolio. Large, complex organisations have significant effort and coverage across the commoditisation scale. Implementation of a hybrid model caters for this variance using unstructured and structured models where necessary. Structure is introduced only by exception when explicitly needed to orchestrate effort across divergent teams and portfolio(s) not as the default approach. Importantly as pieces of work become more understood, or product sets evolve they will likely begin to move on the commoditisation scale and so may need to dynamically change their ways of working.
Any problem or piece of work, including running a business and software development, can be considered in terms of its complexity. Problems range from the simple to the complicated and complex.
The Hybrid Dynamic Model allows for significantly different ways of working, within the cohesive governance of the H-Model of Holistic Software Development. Using the hybrid dynamic model organisations can have multiple ways of working, cultures and practices co-existing peacefully within a single enterprise portfolio. Using different ways of working, practices and techniques across the portfolio helps bring together the otherwise extremely different extremes of innovation and research work with predictable project delivery. Other business models, such as Incubation, can also be used to help bridge the gaps between areas such as innovation and mainstream engineering practices.
Many organisations evolve a Portfolio → Programme → Project → Team model which is then applied to all work in the portfolio due to its past success at delivering large predictable technology projects. However, this model is wasteful when complexity is low and can actually inhibit communication and feedback cycles in high complexity work that is more speculative. The traditional programme/project model can work for mid-complexity predictable work.
Programme and project structures cause layers of separation, which result in emergent transactional behaviour, effort duplication and confusion over roles and responsibilities. As a result, programmes should only be used when there is a genuine requirement for co-ordinating multiple projects that must be integrated for a cohesive product family or business capability. In other cases, programme structures should be condensed - removing programmes that are simply funding lines; Portfolio Management can and should manage funding lines. Stand-alone projects can simply be part of the portfolio.
Reduction in structural complexity will reduce costs, increase flexibility and adaptability while simultaneously improving an organisations ability to react in a rapidly changing environment. Additionally, simplifying structure will reduce the sheer numbers of people involved in project management and supporting work, removing unnecessary barriers between delivery teams and their customers.
This kind of hybrid structure is similar to using the Small Picture of HSD for the pieces of work in the Commodity Portfolio, the team-of-teams delivery elements of the Big Picture for the Specialist Portfolio (and other small team structures) and the Small Picture again for the Research and Innovation portfolio - sharing the same Strategy and Governance layer of the Big Picture.
Adoption of the Hybrid Dynamic Model is actually relatively easy, as you simply add it to what you're currently doing. Regardless of your current structure and operating model, allow variants that are approved ways of working for different types of work. Over time organizations can adjust the amount of work in each part of the model to suit the work, people and disruptive change.