Agile Transformation is everywhere so that we can almost speak about an agile era today like we already discussed topics related to the digital era in the past. Many big companies are indeed actively re-shaping the way their employees communicate with each other as well as the way entire departments collaborate in order to become more flexible, manoeuvrable, and, therefore, more competitive in a volatile global market.
However, if we are being honest, we have to ask ourselves whether we are talking about an agile transition or whether it is, indeed, mostly a hybrid transition. Since I believe that we are actually witnessing a hybrid transition, let me first clarify my understanding of “hybrid” on a project level. I understand “hybrid” as a combination of sequential (e.g. agile transition in projects that started traditionally), parallel (e.g. simultaneous co-existence of agile and classical project teams) and/or integrated (e.g. use of agile methods in classic project environments) approaches.
The hybrid transition is not only what we observe in reality but, as I believe, the most realistic way to optimize the value of project´s products in big companies submitted to multiple internal as well as external restrictions and requirements. Next, we need to figure out how to conceive a hybrid project approach based on existing requirements in the project environment. Therefore, I choose to proceed in a structured way inspired from the theory of systems.
The theory of systems is based on the assumption that people interact in various social systems. For example, companies can be seen as systems. These systems can be themselves fragmented into sub-systems such as departments. These systems are connected with each other in a so-called environment, which influences every system and determines various interactions between systems.
In our particular case, the environment includes material aspects such as hardware and physical systems and immaterial aspects such as regulations.. The portion of the environment, which influences a specific system in reality is called the system context. Our specific system is a hybrid project approach. Here, I assume that this system is already in its final integrated state, i.e. it is fully integrated/embedded into the system context.
In general, following aspects are contained in the system context which directly influence the system and can be categorized as follows:
- Human aspect (displayed by the “man” icon) considers the influence of the different stakeholders on the system. It can be:
- the behaviour of the client or end user of the project´s product, e.g. how “tight” does he/she wants to be involved in the review and testing
- the way project teams interact with each other, e.g. agile vs. traditional or on-site or remote
- the orders of the higher management on the way the product needs to be developed and released but also on the product quality.
- Soft- and Hardware aspect (displayed by the “computer” icon) represents:
- the interface to the existing soft- and hardware in the department or enterprise
- the soft- and hardware, which could be replaced by the project´s product.
- Operational aspect (displayed by the “arrows” icon) that are related to the existing technical and physical operations or processes in the department or company.
- Document aspect (displayed by the “document” icon) corresponds to the type of documents, which need to be created and exchanged between the system and its project context during the project lifetime.
- Cultural aspect (displayed by the “temple” icon) displays the corporate culture and its influence on the corporate employees. This aspect might for instance evaluate if the company attach great importance to self-organization and empowerment.
Reflecting on these aspects of the system context can help us to define two abstract, non-static borders as follows:
- Define the context border, i.e. the border between the system context and the irrelevant part of the environment: This is important to isolate correctly the system context from the irrelevant part of the environment to make sure that we only consider the part of the environment, which influences our system. For instance, an irrelevant part of the environment would be the consideration of the existing processes related to customer relationship management in China when dealing with a project approach planning the release of a PMO software in Germany.
- At the beginning, we observe a “gray” or unknown zone, which will eventually move to a clearer context border since we gain better insights during the project about the exact influencing aspects contained in the system context. For instance, the industry regulator might be an overlooked aspect at the beginning, which might have to be included in the system context due to its active interaction with our system.
- Define the system border, i.e. the border between the system and the system context: A “gray” zone instead of sharp system border is understandable at the beginning since some extensions or restrictions on the system features might have to be figured out over time. An example would be the modification of our system, i.e. project approach, in such a way that additional project activities need to be included into our system.
As we understand, there are a lot requirements and questions to address systematically and regularly during the conception and implementation of a new hybrid project approach. A sustainable answer to these questions is highly important, since a short-living integration of such project approach in the corporate context is mostly not desired. Much better is a viable change management concept to ensure a durable anchoring of the new project approach in the enterprise context, i.e. as an embedded system in the system context.
At TEAMWILLE we can help you to tailor such system and system context based on your specific project environment in order to find out the best possible hybrid project approach for you to reach your project´s goals.