Agility needs a strategy

Agility is another idea frequently posited as being superior to strategy.

The argument goes that the world is changing too quickly for long-term plans and strategy to add value. So, firms should instead just focus on being agile and quick to respond to change.

Once again, this presents a false dichotomy. (See also False dichotomies and the noise before defeat.)

Agility is not an alternative to strategy. In fact, as a goal, agility itself requires a strategy:

1. What should firms do to become (more) agile?
2. How should firms avoid the pitfalls of agility?
3. How do firms decide where to pivot and where to stick? etc.

Agility is a well-developed concept in the field of software engineering and development. A cursory review of the literature will reveal how many different approaches and methodologies for agility there are. Each has pros and cons. Each is likely to be more or less suitable under different circumstances. That same literature is also full of cautionary tales of firms who have failed to implement these approaches well.

Strategy itself is not only about the long term. Strategy should also be about the here and now. In fact, this is one of the advantages of a solid strategy process. It ensures that the myriad decisions that firms face on a daily basis can more easily be made in a way which aligns towards a common goal.

Strategy facilitates agility. When faced with an unforeseen event, stakeholders can more quickly agree which responses most closely align with the strategy. They can then respond more quickly and with greater confidence and alignment. Contrast this with a firm which makes each and every decision independently. Decisions will take longer and involve more frequent changes of direction and even reversals.

However, agility often conceals strategy. Commentators easily observe apparently agile changes without appreciating the underlying strategy which guides them. As Sun Tzu said:

All men can see these tactics whereby I conquer, but what none can see is the strategy out of which victory is evolved.

Update 13 July 2018: I am honoured that Scott Adams seems to have taken up this cause. See his Dilbert Comic for 2 July 2018.

photo credit: Sebastiaan ter Burg Design A Better Business Workshop @ Zoku Amsterdam via photopin (license)

How organizational hierarchies deliver strategy

In an organisational hierarchy, each person must be able to deal with the level clarity and specificity (or lack thereof), ambiguity and conceptual thinking they will get from their boss, whilst adding the detail they need in order to provide their subordinates with the level of clarity and specificity they need in order to be able to do their jobs.

Each layer in the hierarchy must add just the right amount of detail. The exact amount of detail each layer must add depends on factors such as the complexity of the business and it's environment, the depth and breadth of the organizational hierarchy, and the complexity and intellectual content of the activities which must eventually be performed.

In this way, leaders are able to work in terms of visions, strategies, high level plans, principles policies and other abstract concepts, trading of competing and subtle agendas, whilst workers are able to deliver very specific, tangible activities.

If any layer in the hierarchy adds too little detail, their subordinates will find it difficult to understand the organisation's strategy and what they are expected to do to deliver it. On the other hand if any layer provides too much detail, then the layers below it may feel disempowered and disengaged.

Sun Tzu advises that we should manage many as we manage few. Organizational hierarchy is an important tool in achieving this. Whilst many people consider middle management to be an an obstacle to effective communication between leadership and the workforce, I think they must play a vital role in translating strategy into implementation.

How to use a RAID log

Most of the projects I work on use some form of RAID log.

RAID stands for Risks, Actions, Issues and Decisions. The RAID log is a simple tool to keep track of all of these, which can be very useful in regular project meetings as well as for audit purposes.

• Risks represent those things that could go wrong, either in the execution of the project (project risks) or in the underlying business being changed or created (business risks). For each risk we normally estimate the probability and impact of it happening, and also any actions we are taking to mitigate against it. We also normally assign an owner, who is responsible for monitoring and mitigating against the risks, and set a future review date on which it will next be assessed.
• Actions represent all the things that need to be done. These are typically actions that arise during project meetings and don't necessarily include all of the actions already on the project plan. Each action should have an owner, a due date, and eventually a date on which the action was completed. Each project meeting should review actions, to mark off those completed and review progress against those not yet completed.
• Issues are known problems within the project or the business being changed or created. Many people think of issues are risks which have already happened. Issues are typically notified up the management chain, for example to a project steering committee or business executive team. For each issue, you should identify what you intend to do about it, who should do this, and when it should next be reviewed. Issues should be marked as resolved once the problem is sorted out or the project moves past or around the obstacle.
• Decisions are simply a list of decisions made in a project. They are simply listed as a record of decisions made. You can also record when the decision was made, and by whom it was made.

The secret to a good RAID log is to record the right risks, issues and decisions at the right level of detail. Too many and in too much detail simply creates unnecessary bureaucracy. Too few in too little details does not provide a sufficient record of the state and progress of the business. For example, I have often seen risk logs populated with boilerplate risks: these are generic project risks, such as 'we may not get sufficient executive sponsorship' which don't really add any insight to the project. (If you genuinely think that is a risk, you be better of identifying the underlying reasons which might cause this, and then expressing the risk in those terms.)

RAID logs are an excellent governance mechanism, and worth keeping even if for no other reason than so that you have all of the information to hand if the internal audit department or some other stakeholder decides to audit your project. But don't forget that projects are fundamentally about doing things. So identifying risks and issues without also identifying actions to mitigate them, and making decisions to resolve them will not get you very far.

Resources: You can create and manage your own RAID logs with your team in our secure and collaborative online tool at StratNavApp.com - simply register and select "Control".

Strategy Implementation: The Weakest Link

If you've ever watched the British TV Game Show "The Weakest Link" (or one of its numerous international spinoffs) you've probably learned some of the most important lessons of strategy implementation.

First, a quick overview of the rules. The contestants are asked questions one at a time. Each time a contestant gets a question right, an amount of money is added to the prize pot. The objective is to chain as many correct answers together in a sequence as possible. Each correct answer in a chain of correct answers is worth more than the one before it. The chain is broken when a contestant gets a question wrong or says "bank" just before their turn. If the chain is broken because a contestant gets a question wrong, then the money in the pot is lost. If the chain is broken because a contestant says "bank" then the pot is added to the prize purse and cannot subsequently be lost. In either case, the value which can be won be answering the next question correctly is set back to the initial amount and must be gradually built up again.

It follows from this that the most amount of money that can be won in a round is won by answering all the questions correctly and never saying "bank". However, if the contestant answers just the very last question incorrectly, then the whole group gets nothing for the round even if they'd answered all the other questions correctly. The reward and risk are maximised by following this strategy.

Alternatively, if each contestant says "bank" before every question, then the purse will be increased for each correct answer. But the amount by which it is increased will never increase, limiting the total amount that can be won.

The key to success in "The Weakest Link" is to bank at the right times. Don't bank often enough and the risk becomes to high; bank too often, and the rewards are limited. It is the same in strategy execution.

Lesson 1: Bank often to reduce risk. In strategy execution, banking means delivering a change into an operating business. Documents, plans, blue prints, strategies are all well and fine, but they are not bankable until the are effected as changes to the operation. Similarly, programme code is fine, but it is not banked until it is launched into production. Strategies are worthless until they are executed.

This can be likened to work-in-progress (WIP) in manufacturing terms. WIP is treated as an asset on the balance sheet in accounting terms. But in financial terms, it remains a cost until the work is completed and the product is sold. Just as firms should reduce work in progress, so to should they aim to reduce plans not yet executed to completion.

The way to achieve this is to break big changes into smaller changes. This is not the same as breaking projects into phases, such as analysis, design, implementation and testing. This means breaking changes into smaller changes which can be implemented and each of which improve the operating business.

Lesson 2: Banking too often reduces returns. It is a fine balancing act. If you change too often the organisation will start to suffer from change fatigue, and the operation will never become stable enough as a platform for future changes. For example, where change is implemented through computer systems, each change needs to be fully testing, data needs to be converted and operating procedures need to be changed. All of this costs money and so cannot be undertaken too often.

Every operation requires a natural rhythm of change. If change is infrequent and irregular it will be hard to analyse and control. However, unlike in "The Weakest Link", the rules are not cast in stone. Once you have established a natural rhythm, you should aim to speed it up, achieving higher rewards at lower levels of risk.

See also: Big business appears to favour big change

photo credit: rickh710 via photopin cc