Taming the Trojan Horse: Preparing Agility Effectively

Agility has been a hugely overhyped concept for quite some time. From two-guys-in-a-garage startups to globally active corporations or public sector contracting authorities, more and more organizations are considering the concept in the hope of generating new business potential. All too often, however, these high hopes and great expectations are disappointed because organizations are unaware of the consequences of agility. So how is the necessary understanding to be created?

Open a management magazine or leaf through the program of a specialist convention in 2018 and you will find it hard to dismiss the impression that anyone sees himself as anyone nowadays is in the process of making his projects or his entire organization agile and is thereby pushing the gateway to a bright future wide open. The market is, after all, brimful of agile consultants and service providers who claim to be able to anchor the concept of agility into every organization.

All too often, companies take these promises at face value and hire service providers in the mistaken expectation that these external providers will soon have their structures “up and running” agile. Often, however, it is not quite as easy as that. There are many examples of initial euphoria turning into frustration in next to no time because agility has not had the desired effect and news of these examples spreads by word of mouth like the proverbial wildfire. For the agile movement that is disastrous; it gives rise to suspicions that agility is just the latest craze everyone is talking about.

Everyone Takes Agile to Mean Something Different

Agility itself is not the problem. Instead, many agile initiatives come to grief because people differ in their understanding of what agility is and what may be the consequences of adopting the concept for their organization. This is especially apparent in the above-mentioned collaboration between the principal and an external service provider. In this case, due to different expectations and different knowledge levels and experience values, both sides frequently not only talk at cross-purposes; their views also often differ on what a service provider can or cannot do to bring about structural changes in the principal’s organization. Misunderstandings and dissatisfaction regularly result on both sides, going in the worst case as far as to jeopardize the project.

It is hardly surprising that misunderstandings of this kind occur. Even though agility may at first glance appear to be an easily understandable concept the basics of which can be grasped in next to no time the specific repercussions of the idea for real processes and structures are complex and hard to penetrate. In its effect the concept of agility is like the proverbial Trojan horse. At first glance it appears to be just another project management approach. People often fail to realize that it is in reality a holistic approach for organizations. So the effect of agility is by no means limited to the operational project level. It also has the potential and the aspiration to change the mindset and the working methods at the functional and strategic level of the enterprise – from Procurement, Reporting and Controlling to Accounts and Management. If these consequences are not taken into account and the organization is not prepared accordingly, there is an enormous risk of an interface clash between agile and traditional structures. In this case agility might set fire to the organization just like the Greek warriors who sacked Troy after entering the city in the belly of the Trojan horse.

The temptation to jump onto the moving bandwagon may be great, but this does not mean that the concept of agility is the right choice for every project.

In view of this comprehensive effect standard recipes that can be applied to all use cases can simply not be formulated. Instead, the task of the service provider who is conversant with agility is to impress on his principal the realization that the starting point is different for each organization. The analysis of this starting point is of crucial importance for the decision whether and in which way agility can be implemented at the company. Agility may be in fashion at present and the temptation to jump onto the moving bandwagon without further hesitation may be great, but this does not mean that the concept of agility is the right choice for every project and for every company.

Three points in particular should be clarified to enable a decision to be made:

  1. In which business environment is the organization active? Is the environment highly dynamic and does that require the company to be very flexible? Or is the environment so stable that future developments can already be predicted with a high degree of certainty?
  2. What does the existing corporate structure and culture look like? How ready are employees and management to move tried and tested structures and processes toward agility?
  3. Is there a specific project for which an agile approach is envisioned? If so, what do the properties of the specific project look like? Is it a complicated project, but nonetheless one that can be planned and calculated in advance? Or do complex framework conditions that are never entirely clear make drawing up a plan impossible?

Formulate Expectations – Weigh Up the Options – Make a Decision

Reflection is a fundamental component of the agile mindset, so dealing with the concept of agility should itself begin with a phase of analysis in which, for one, the company must acquire the basic knowledge it needs in order to assess the implications of the decisions that are to be made. For another, the different ways in which agility can be implemented at the company should be developed and evaluated.

The bandwidth of these options is extremely diverse. In principle everything is possible: from an initial agile lighthouse project in which experience is mainly to be gained to the establishment of agile thinking right across the organization. What is important is for the organization to be aware of its expectations in the analytical phase and to take its own starting point and readiness for change into account when assessing its options. This is the point at which external service providers can be brought in to enable the company by a variety of analytical methods to accurately assess the actual and target states by itself and on this basis go on to make the right decision.

An organization can only change itself on its own initiative.

Only then can work begin on specific implementation of the project. If, for instance, the company wants to implement the afore-mentioned lighthouse project by means of an agile approach, it can make sense to separate the project from the organization and so establish a bimodal model. The project team can then work in an agile manner while leaving the structures and processes at the remainder of the company unaffected by the change. In this case, however, the framework conditions and degrees of freedom of this division must be clarified in advance in order to facilitate harmonious interaction at the interfaces between the project and the organization. In this way, for example, it can be made clear to an enterprise-wide crosscutting function like Controlling that the agile project team cannot, due to its iterative approach, submit detailed annual plans even if the rest of the company has done so for years. When commissioning an external service provider the purchaser must in addition understand that in the case of an agile project approach he cannot expect a fixed-price offer and that amendments in scope are then regulated in a current project by means of continuing resolutions (CRs). Agility assumes even greater importance, however, if the entire organization is to become more agile. In that case it will affect every area of the enterprise and will necessarily change processes and structures that have previously been run along traditional lines.

Whichever way the decision goes, a key factor is that the organization must be aware of the effects of the decision and must take the necessary decisions forward with the utmost consistency. Even if scores of external service providers are hired, all that they can do is indicate options and make recommendations. An organization can only change itself on its own initiative, and in this change process any form of half-heartedness will reduce the efficacy of the agility concept.

Conclusion

Be it a higher speed, an improved ability to adapt or a stronger customer-centric focus, there are definitely many reasons to look into agility and to sound out the opportunities it provides for the company. This does not, however, mean that one should go head over heels for it in order not to “miss the boat.” To do so is to run the risk of wrongly understood and practiced agility developing into a stumbling block and of expectations being disappointed as a consequence.

This risk is not limited to the adoption of agility, however. It is a part of every change process and can only be averted by detailed project preparation. That is why a phase of analysis in which expectations are clarified, misunderstandings are resolved, opportunities are developed and evaluated and decisions are prepared is of crucial importance for the success of agility. External service providers can only help by contributing to this preparatory analysis the expertise they have gained in numerous other projects and provide close support with the subsequent implementation. Only the company itself can, in contrast, make decisions and take action.

Image source: Fotolia – psdesign1

Share