No matter how careful and detailed the plans are, the projects still go over time, and budget. Is there one thing that makes both the construction works and software development hard to estimate? The answer comes from Carl von Clausewitz, a famous 19th-century Prussian general.

But before we dive into military theory let’s consider an almost-too-real example of how things can go wrong in software development.

A story of a “simple feature”

Imagine a Product Manager in a mature B2B SaaS company. He sets out to solve a customer problem: currently, reports provided by the product make little sense to some of the customers. Customers from larger companies expect their data to be grouped and filtered using the divisions they are used to: teams, departments, regions, and such. Workarounds are costly and ineffective.

The PM does his research, drafts a solution proposal with his team, and with sufficient support from higher-ups the project gets kicked off. The solution: companies will be able to import their org charts into the product to later slice and dice the reports as they please. The initial feedback from customers is lukewarm but positive. One of the customers even agrees to be an early adopter.

Engineers prepare the technical design. And there lies the first hurdle - the type of data we want to process (company tree-like structure) does not sit well with the storage mechanism we have in place. It can be done but there are missing features in the storage platform. No problem, the platform team can add those. But, they are swamped this quarter: there is a larger initiative that trumps all the other work now, sorry. In the end, the product team finds a (costly) workaround and things are back on track.

Soon the feature set is ready to be tested with a customer. The PM reaches out to the initially-interested company but gets no meaningful response. A quick meeting with Customer Success makes the situation clear: the client company is in the middle of a painful reorganization and can’t be bothered right now. It’s a setback but with support from Sales and some convincing another customer agrees to participate.

It only takes a few weeks of meetings to get in contact with a person who is capable of implementing the org chart import on the client side. She is very busy but can squeeze us in. And with that, we get the first piece of actual user feedback: the data cannot be imported as it is formatted in a way not supported by the system. We spend a week painstakingly customizing the import procedures for this special case. With other clients already in the pipeline, we are off to the races.

Now it’s time to open the floodgates and launch the feature in a beta program. As with many B2B SaaS products, ours too is sold with the help of consulting firms and other partners. The Product Manager prepares a short presentation - no need to oversell, the customer value is clear. But during the call, there is a sense of uneasiness in the air and there are not many questions at the end. The person responsible for partner relations explains: “They are worried about the complexity of deploying the integration. We will have to train them or something. I can prepare something”. PM jumps on the proposal. But, when the training materials are ready he realizes that it was prepared strictly for one consulting company - the one present in the meeting. It references its special operating procedures and goes into detail about issues they might experience. It has to be redone.

In the end, the feature gets launched - over time and budget. People wonder if it was worth the squeeze as some of the customers still choose the deprecated workaround instead of adopting the new feature. The PM also has his doubts but brushes them off and sits down to send an e-mail congratulating the team about the launch and thanking everyone else for their support.

Friction

None of those events killed the project but all of them required additional effort and time. With sufficient experience and well-trained intuition, some of those could have been anticipated but there is much better learning here: friction is a part of every sufficiently complex project. One has to learn how to manage friction and, ideally, how to use it to one’s advantage. To do that, we need to understand it first.

“Friction makes doing simple things difficult and difficult things impossible.” – Stephen Bungay

The unexpected cost is visible in the story. Now, let’s step back and consider what is the underlying source of the friction. For that, we will have to consider the most obvious part about companies building software.

Causes of friction

Organizations are made of people, with all their flaws.

• We act on imperfect information
• We process and pass information in an imperfect way
• We each have personal goals
• Even if our goals align, we might have different ideas and priorities regarding how to go about them
• …and, in the end, some of the things are totally outside our control

Those “flaws” are the core reason why things don’t go as planned. But they are not very actionable. There is not much we can do about the fallibility of humans in general. Carl von Clausewitz, based on his experience in the army, formulated a theory of how intentions translate into plans, those turn into actions, and actions into effects. Based on this theory, Stephen Bungay in “Art of Action” named 3 gaps in that process that are the core source of friction:

Knowledge gap

Knowledge gap etween the actual situation and our understanding of it: “We didn’t know so we planned the wrong thing”

In the story, the platform team wanted to help but had different priorities. The PM did not know about the larger platform initiative.

He also did not know about consulting companies having very different goals than his. The lack of enthusiasm from consulting firms was justified from their perspective: their goal was to sell and deploy the product as quickly as possible, and getting involved in a high-effort beta program was not something they were enthusiastic about.

Alignment gap

Alignment gap: between the plans and actual actions taken: “The plan was good but we misunderstood it and did the wrong thing”

The partner relations person did their best but assumed a slightly different intention.

Effects gap

Gap between the activities and outcomes: “We did the right thing but did not get the result we wanted”

Even though the beta version of the feature was ready the customer could not participate because of the unanticipated re-org (effect gap).

Only a first step

With the knowledge of the mental model, you should be able to apply it for a better understanding of why things tend to be harder in practice than initially expected. Understanding the nature of the challenge is the first step. By knowing the possible gaps one can anticipate and take a shot at managing the friction.

Both Stephen Bungay and Carl von Clausewitz give some advice on how to deal with friction and how to use it to your advantage - this will be a topic of the next post in this series, stay tuned.