Coherent actions

It’s been a while since I’ve written about family matters (good things), and the truth is that it’s about time I started writing here again.

I want to talk about a book that I think I’ve mentioned before, but which I’ve been rereading recently and which seems quite relevant to current politics and which I’m sure we’ve all seen in our companies. The book is called “Good Strategy/Bad Strategy” by Richard Rumelt.

At one point, Richard talks about one of the ways of having what he calls a bad strategy:

“Bad strategy tends to skip over pesky details such as problems. It ignores the power of choice and focus, trying instead to accommodate a multitude of conflicting demands and interests.”

and a little further on he clarifies:

“they have multiple goals and initiatives that symbolize progress, but no coherent approach to accomplish that progress other than ‘spend more and try harder'”

The reader has surely already imagined a similar situation.

How many times have we seen the ruling party, in order to get enough votes to approve a proposal, promise one thing to an allied party and the opposite (or almost) to another party? This makes it seem like progress is being made. They can come out saying that steps have been taken in the right direction because they have convinced the other parties to vote in favor of a proposal. But then come the coherent actions. That is when they try to deliver on their promises to both sides. In most cases, this is not possible, and a law or proposal is created that does not convince either side, or is so convoluted that it complicates the system.

One example could be the Lockheed Martin F-35 fighter jet from the United States. This multi-role fighter sought to meet the needs of the Air Force, Navy, Marine Corps, and even international allies, incorporating everyone’s requirements into a unified design. The result was a “Swiss Army knife” of an aircraft with enormous cost overruns (estimated at $1.65 trillion over its lifetime), decades of delays, technical problems such as software and hardware instability, and performance that was called into question by trying to be everything to everyone. Unnecessary complexity was created that ended up .

Another example could be the National Health Service’s National Programme for IT in the United Kingdom. This project aimed to modernize IT systems, electronic records, and digitization for all hospitals and communities. To satisfy politicians, suppliers, and local stakeholders, changing and contradictory specifications were accepted, resulting in a politicized approach that did not adapt to real local needs. The result: delays, technical problems, lack of accountability, and a waste of around £10 billion. It is considered the biggest IT failure in UK history. It was abandoned before completion.

More in the world of technology, the case of Windows Vista was very well known. When the requirements for “Longhorn” (the development name for Windows Vista) were being established, proposals from all internal teams were assimilated without a clear focus. In addition, they were all proposed for the same version, which would be revolutionary. This caused what is called “feature creep,” a system overloaded with unnecessary functions. The consequence of this was instability, delays (development began in May 2001, with the idea of releasing it in October 2003, but it finally saw the light of day at the end of 2006) and poor performance. The result was a criticized OS that damaged Microsoft’s reputation.

I remember a company that sold several applications that did practically the same thing. It was decided to reduce the portfolio to lower operating costs and improve maintenance. The idea was simple:

If there was an application that had a function that worked well, that function would be used by the rest of the applications.

If there was a function that did not exist, a new one would be created and everyone would use that function.

The least-used applications would be eliminated, thus reducing complexity and the number of systems to maintain.

A presentation layer would be created above all the applications so that users would not notice that they were using services from different applications.

During the presentation of the idea, a diagram was shown with all the applications under that presentation layer. Everyone was happy; their applications were in the final diagram, everyone was there, so everyone accepted the idea without stopping to think about how to carry out the plan. The coherent actions.

The result was not as expected. Each group responsible for the applications logically said that theirs was the best in each functionality and that the rest should use theirs. They refused to implement the functionalities of others. If a new service was needed, there was no consensus on the details of how it should be implemented or which unit would pay for it, so each one implemented its own functionality. No one was happy, but now they had to maintain the entire previous portfolio, and an additional presentation layer that they skipped when they could, but that no one wanted to eliminate completely, because it had cost so much.

So, as Richard Rumelt says,

“Strategy should mean a cohesive response to an important challenge” … “is a coherent set of analyses, concepts, policies, arguments, and actions.”

And part of this response, of these coherent actions, is to make decisions that may sometimes be uncomfortable for some of the parties involved.