May 07, 2021
Get in touch
The challenges of (agile) IT projects are in no way limited to matters of technology. Yes, technical expertise is an essential requirement for all projects involving IT – but it is definitely not the only thing that matters.
In this article, I would like to share a few thoughts on the topic of complexity in IT projects, especially within the context of development teams. I am thinking here in particular about innovation projects, the kind that are of potentially crucial importance to your company’s future, in exploiting your existing business or exploring new (business) opportunities. These projects are situated within the company but should be understood as being exposed to a complicated set of internal and external pressures.
The success of the project – and, by extension, the entire company – relies on the team’s ability to handle this complexity as effectively as possible.
Precisely in the current environment, where major social issues and crises are ascendant and changes to our society, and especially to our economic system, are progressing with increasing speed and momentum, functional complexity management systems are essential. Companies that are better able to adapt and work with the pressures at play in these complex shifts will be poised for greater success.
Established organizations (such as large corporations) in particular may, as they are forced to react to change, find these challenges all the more difficult. In such cases, it is often clear that IT initiatives, however well–intentioned and considered at the start, fail to achieve the critical mass and impact they require, and are ultimately doomed to be regarded as overpriced and ineffective IT measures once scaled up. And instead of carrying the seeds of agile transformation out into the rest of the company, helping it take root in all departments so that its benefits can truly be harnessed, you instead sow cynicism and frustration.
A set of conflicting priorities that arises at established companies frequently produces dynamics that can negatively impact even experienced development teams – wasting so much potential valuable learning.
A situation can be described as complex when it is not possible to predict what exactly will happen. When it is not possible to account and plan for all associated elements. Among other effects, such scenarios make structuring decision-making processes more difficult. Yet a constant flow of the best possible decision-making is precisely what is needed for projects to succeed.
There are no simple solutions for complex situations. As such, we cannot expect that simply introducing agile methods and following management or transformation manuals will remedy the situation in the long term.
We should nevertheless feel motivated to learn constantly, and to consistently improve our complexity management skills and how we communicate them to others. A functional system for complexity management can be achieved through differentiated consideration of sensible perspectives and aspects, and by fostering the formation of connections. This also requires teamwork in this effort, and functional communication and collaboration. Modern system and organizational theories provide valuable perspectives that allow for better analysis of key interdependencies.
Companies work within an economic system and solve problems (to which they dedicate themselves), generally for payment that is ultimately required to deliver the profits that keep the company alive.
If we regard this kind of company as a complex system, then on the one hand we have the complex system at play in the company itself (internal reference), and on the other hand complexity from the company’s environment (external references).
Both provide many dimensions and differentiations that must be taken into consideration to make potentially good decisions. A few examples of external dimensions would naturally include customer needs (serviced scarcities), various competing companies, partner and supplier relationships, expectations of investors and shareholders, rules and regulations, existing networks and of course interactions with politics, the impact of crises, etc.
Internal factors are focused on the reality of corporate culture and established collaborations. For example: existing assets, hierarchical structures, self-improvement and career opportunities, and whichever goals employees are (truly) pursuing. Expressed systematically, this means the established communications model within the company as a system.
The goal is to work with this ambiguity and complexity – there are rewards to seeing and contemplating interconnections, to identifying conditioned elements that encourage dysfunctions, to collaborating creatively in teams, to networking, and to engaging in joint development of visions and solutions, etc.
Many outstanding thinkers have expressed their philosophies on the topic of complexity, and there is an active community of thinkers, consultants and coaches specializing in corporate organization, offering real experience and expertise in handling complexity and systematics.
In light of this, I wish to highlight a few limited points to provide inspiration on this topic which I personally consider to be sensible. These can also be found to some extent in the agile principles and are often important components of the transformation project.
Learning:
Today’s companies must always view themselves as educational and learning organizations. If the problems to be resolved change (in complex ways), then learning must inherently be part of the value chain. Handling of complexity can also be studied: Complexity management skills can be observed and learned. This includes an understanding of how learning (or more accurately: self-instruction) works for us as humans.
Systematic thinking:
Here, you should consider how to establish systematic thinking – to avoid returning (again) to simple models and theories and to avoid falling into previously instilled patterns, conditioning or ideologies.
Decisions:
Many of the decisions in projects do not need to be made at the beginning, but rather later in the process, once you know more about the topic. This increases the chances that better decisions can be made based on that acquired experience and expertise. If new information has been acquired, then these insights must be assimilated – clinging to obsolete decisions typically does nothing to demonstrate real learning. If you want decisions to be made well, then it also matters where and how decisions are made and on what they are based.
External perspectives:
People are normally good at resolving (real) problems. An orientation toward external references, toward value creation, is essential to encourage creativity and problem solving to serve the company’s objectives. On the flip side, an orientation inward (toward internal references) can have a dysfunctional impact and cause unnecessary (self)-preoccupation. This in particular makes things more difficult in many corporate structures.
Teams and communication:
Collective intelligence is important for success, since multiple perspectives (or dimensions) come together, and you can achieve a greater impact collaboratively. To allow this ‘collective intelligence’ to come about, clear, reflected communication and identification of competencies is required.
If you now apply this perspective to truly (agile) development teams with a track record of success, then you can see that those teams develop a working structure that has learned from a complex, demanding and dynamic environment and is shaped by constant change and innovation in technologies and shifting project and customer requirements.
Within such teams, there is frequently end-to-end responsibility for a given topic, and a high-quality product is delivered to market on a regular (iterative) basis. Because we are starting here from the presumption that the team is successful, it is worthwhile to observe what models have been developed.
Because the team is constantly solving new problems, the team has established the habit of routinely trying out new things and learning. Within such teams, there is a high degree of self-learning expertise. The routine feedback loops and moments of reflection that are an especially common part of agile development are applied to joint learning at various levels.
Team members have also learned than no one can do everything and that individuals’ skills matter: Members of the team work with each other on equal footing and recognize the importance of working effectively and learning from one another.
A team’s framework conditions change, of course, with each new project and each new customer. It can happen that effective collaboration is disrupted by intrusiveness. Creativity and energy are then deflected within the team. For example, a focus on poor decisions made externally, on fulfilling sub-optimal processes, harmonization, over-formalization or constant co-consideration of senseless or competing specifications or rules. The reasons for this are mostly complex and lie in the client’s long-ingrained patterns — and unilateral dependencies (customer <> vendor) can also be a reason for this. The entire thing has a creeping nature, often eluding notice because it happens unconsciously. But such dysfunctional impacts cannot be in the company’s interest.
It is recommended that extensive and complex IT projects include learning and training concepts involving agile processes, all supported by experienced consultants/coaches familiar with complexity management and able to apply systematic perspectives.
These coaches can help uncover dysfunctional models and dynamics. But that too can only have a positive effect when it fits with the overall organization and there is truly opportunity for sensible intervention. Here it is helpful, and often necessary, to include roles with formal authorization within the company throughout the joint learning and reflection process with the consultants.
Complexity is part of our reality. The things we learned yesterday will likely no longer be applicable tomorrow. For companies that want to remain or become successful, that means learning to handle this fact better — because others will be doing so.
If established agile development teams are to be commissioned and incorporated into the planning of innovation projects, then there is significantly more for the organization to learn and ensure than ‘just’ the necessary technical expertise within the project.
Joint reflection and learning processes with experienced (systematic) consultants should be included in the planning for many projects and approached with the conscious awareness that much more can potentially be done for the success of the project, not to mention the entire organization, than may be evident at first glance.
This article first appeared in the magazine Computerwoche. We appreciate your feedback and sharing the article.
