Solving the Gordian Knot of Chronic Overcommittment in Development Organizations

The difference between successful people and very successful people is that very successful people say “no” to almost everything . Warren Buffet

Why do we as humans and organizations have such a strong tendency to promise more than we can deliver? One simple explanation is that we want to please those around us. We want to say yes when someone asks for our help. Saying no could mean that people see us as being rude or less capable. While being of service to others is a positive thing, when taken to excess it can be devastating - leading to stress, poor productivity and congestion (both physical as well as work-wise).

Another less flattering and perhaps more dangerous reason for overcommitment is external pressure to promise what we know that we can’t deliver.  The forces behind these external pressures can include the following:

• Implicit and/or explicit threats to our job security if we don’t accept work that is being pushed upon us.
• A view that the role of the IT-organization is to support the business and cannot stand in the way of business development.
• An erroneous understanding of how work works, based on efficiency being a virtue in itself, without understanding the damages of high levels of work in process.
• A high pressure on sales organizations that overpromise on behalf of the delivery organization in order to close more deals. This behavior is often reinforced through dysfunctional incentive systems.

This behavior is often displayed in a fractal way throughout the organization; people overcommitting on a personal level, project managers committing their teams to fantasy project plans, sales selling features that the organization lacks the capacity to implement, and top management making promises that won’t be delivered. This cultural aspect becomes self-reinforcing; when everyone else promises to deliver whatever is being asked for it’s easier for individuals to become part of this ever-growing mass than to be the troublemaker saying no. After all, when the problem becomes impossible to ignore, it might have already landed on someone else’s table.

When the organization fails to analyze its mistakes, or make a too shallow analysis, it’s easy to come to the conclusion that the plan was flawless and the problem lies entirely with the delivery. And this is where most organizations focus their efforts to come to terms with the problem; how to deliver according to corrupt plans.

Organizational Behaviors Driving Overcommitment

The main behaviors for chronic overcommitment in organizations are:

1. Delivery capacity is unknown or hard to measure so it is easy to accept more and more work. It is common at several levels in the organization. Investment and schedule decisions are taken without knowing what delivery capacity exists. Projects are started and shoehorned into the unknowingly overloaded organization.
2. Projects and work is not prioritized. “We already have 234 projects ongoing and suddenly Marketing/Finance comes with a high priority project that is a must. We do not know how it stacks up against the 234 other projects since most of them are high priority projects and a majority are must”.
3. Lack of a single point of entry for projects. Projects are started on many different levels and places in the organization.
4. Political; there is no structured & holistic approach to stop projects from starting or killing projects for the benefit of more important projects. This causes zombie projects running long past their expiration date.

All of these causes enforce each other to create a vicious cycle that companies have a hard time recovering from. To examine this vicious cycle more closely, let’s take a look at a hypothetical case study.

CASE STUDY – Claes Claesson at MegaRetailer AB

Claes Claesson is an IT manager at MegaRetailer AB, a company that sells thousands of different products both in its own retail shops as well as through third party retailers and through their own popular Internet shop where some of the product families are available.

Claes attended a management meeting where the Marketing Director presented a two-pronged approach to increase sales and revenue for MegaRetailer AB. The first required change is to provide real-time inventory data for their own retail shops so that sales people can direct customers to another location if their shop does not have the item the customer wants. The real-time inventory data must be made available both in the retail shops and the Internet shop (showing closest retail shop carrying the item).  It needs to be implemented in time for the Christmas shopping season. The business case for this change is good, there is no denying that.  A 12% increase in sales is projected for the Christmas period on top of the existing sales figures providing a substantial revenue increase and lowering the inventory costs.

The second required change is to provide the Internet sales channel on mobile and tablet formats and enhance it with state of the art visual product recognition. The customer can take a picture of an item (s)he wants and the app will identify the product and recommend MegaRetails own brands or similar products.  The app will also identify the closest location to purchase the item or to buy it from the net channel.

The overall plan is to implement these changes over the coming 12-24 months in multiple projects. Sourcing and Logistics have already started to look at scanning systems to provide product-matching data when new products are brought into the MegaRetail line.

There is no debate that the end result of these changes will be good for MegaRetail, but Claes already has hundreds of projects in various states of progress and the question remains whether there are enough people to staff these additional projects? There was no understanding or acceptance in the meeting that the IT department teams are already busy. In addition, the Marketing Director somewhat heavy handedly reminded Claes that business drives the company forward and IT is to be a supporting function and not a roadblock.  Here Claes’s boss, the CIO, stepped in and said, “That’s right, IT supports the business and Claes here is our go-to guy for solving difficult problems and delivering the most challenging projects. But in all fairness Claes and his people should be given some time to analyze how we can deliver these work packages in the best way.”

At this time the Supply Manager could not refrain from sniping, “Well, maybe Claes could take a look at another challenge, our Delivery Control System, since it is already over 8 months delayed.” Luckily the meeting ended before that discussion escalated any further.

The decision was made, Claes and his organization are to analyze the marketing requirements and come up with a development and implementation plan. His boss told him, “Claes I know that we are stretched thin but these two items are crucial and have the backing of the CEO and the board, look at hiring consultants if you need but no hiring of employees beyond the current plan.  We do not want to add to our cost mass. I have all faith in you and your people.”

Understanding the Dynamics at Play in the Case Study

In this section we will work to understand the dynamics at play for Claes and his team.  We will map out the situation described in the case study using Causal Loop Diagrams. If you are not familiar with Causal Loop Diagrams you can read through the following short How-To section.

(Click on the image to enlarge it)

Figure 1 - How to read Causal Loop Diagrams

Claes is on the path of starting new projects to deliver what the Marketing Director requested. One of the reasons why it is so hard to say no is that the perceived benefits are seen as great and no one at the table understands the consequences of starting one or more new projects. Even if Claes or anyone else on the team has an instinctive feeling that we are already overloaded it is very hard to debate or discuss it without facts and numbers for consequences.  The harder it is to understand the consequences the harder it is to say no to new work and we cannot get a good understanding of the coming consequences without understanding our current capacity.

(Click on the image to enlarge it)

Figure 2 - Acceptance of new work

When you continue to add projects in an uncontrolled manner long enough, the IT organization will be overcommitted, it may take some time but in the end, it will happen.

When existing projects get delayed, trust between IT and the business deteriorates and business stakeholders will start to take any opportunity to get their needs on the agenda. This will show up in the form of requirements being forced into projects that have already gotten clearance to start, skunkworks projects done by departments without any IT participation causing additional work for the IT department in the form of integration, maintenance and security issues. All of this can be summarized as pressure to accept more work. Eventually this will become a reinforcing loop that keeps heaping pressure on the team to accept additional work.

(Click on the image to enlarge it)

Figure 3 - Increasing pressure to accept more work keeps the organization in a perpetual state of Overcommitment

One of the actions Claes and his boss can do is to kill projects that are less important to create space for projects that are more important. This would lessen the strain on the IT organization and provide a more even flow of deliveries from the projects and allow Claes to come out on top of the situation.

(Click on the image to enlarge it)

Figure 4 - Killing projects to lessen overcommitment problems

Unfortunately other dynamics come into play when Claes wants to kill some of the existing projects.  When the organization is overcommitted it usually has hundreds of projects with a multitude of stakeholders making it very difficult to kill a project. Project champions and stakeholders will want to keep their projects running in order to get the anticipated benefits, so they will point to other projects and say “find another project to kill, my project is important”.  Basically Claes is trying to sell the message “Your baby is ugly and needs to be closed so someone else’s baby can be started”.  He will not find many sympathetic listeners.  This gives us the “Do not kill my project” reinforcing loop; the more overcommitted our organization is the harder it is to pinpoint the right projects to kill in order to bring us back to a stable execution mode.

(Click on the image to enlarge it)

Figure 5 - "Do not kill my project" reinforcing loop

Unfortunately, killing a running project will tear further on the trust between IT and Business and increase the pressure on IT to accept new work. So once we are in this “Catch 22” of over commitment, it is hard for an organization to get out of the hole they are in.

In summary, the IT organization can be viewed as a bathtub. When the “bathtub” overflows it creates extra costs and problems and delays delivery of existing projects. The basic rule is never add more work than flows out of the organization once you have reached your capacity limit.

Figure 6 - IT department as a bathtub

Resolving the Gordian Knot between Business and IT

A Gordian Knot represents a difficult, intractable and often insolvable problem, which is exactly what it feels like in an organization with chronic overcommitment.  But there is hope.  Let's see what Claes and his boss could do to improve things.

Claes could try to solve his resource issues by using external suppliers and doing various workarounds to provide functionality faster, but none of these methods address the main reasons for overcommitment.  While workarounds may help, they will only serve to keep the organization in the Catch 22 situation they find themselves in. Even more worrisome is that over the long run, performance will deteriorate since the IT department’s capacity gets worse and worse over time.

Instead, Claes should apply the following four steps:

1. Learn to deliver on a small scale

Isolate some value stream or function where it's possible for a team to deliver value without dependencies on other parts of the organization. Have the team deliver with quality, accept no shortcuts or deliveries where the quality is unknown. Feed the learnings on how to organize around a value stream back to the organization and then slowly begin to scale up being careful to avoid unnecessary dependencies between the value streams.  Use Agile and Lean practices and principles to improve your delivery capacity.

2. Have a clear strategy and live by it

You cannot kill project #265 without a clear strategy. By articulating the business vision and priorities in a concrete manner, with clear real examples, people can make the right decisions. Remember that everyone is prone to overcommitment and the job of management is to make sure that the delivery engine is not overloaded. Create hard rules of limits for the system and enforce escalation procedures like requiring CEO level acceptance to exceed the limits for work in progress. Companies like Volvo and Harley Davidson have learned this lesson and created a strategy to deal with it. At Volvo the strategy was codified in the quote “666 is the highway to hell” meaning that they should never do three major projects in parallel (major projects are called category 6 projects at Volvo).  Similarly, Harley Davidson made huge progress by understanding that they could not do more than one big project per year.

3. Change your habits around problems

Normally when a problem occurs, management rushes in to help solve that problem but often making things worse by enforcing more control, status reporting, and other work that is disconnected from reality.

By doing what should be the work of the front line people, managers lose their strongest card since their focus shrinks. Once you have ensured that your people have the needed expertise and any other resources necessary to solve the problem, make sure you have a structure to share information about the issue.

 Finally, think about how the problem might have side effects on the organization, both today and in the future, and try to answer the following questions.  How could this problem have been detected earlier? Is there anything in the current system and strategy that creates this problem? How do we share new knowledge gained from this problem?  Innovation requires space, how can you create this space for your teams so that this problem does not impact you again?

4. Create common knowledge

If you are responsible for the delivery engine in your organization, you will need to create a common understanding between all parties so that everyone understands the strategies and rules of the game. It is important to create this common ground so that everyone understands that the decisions and behavior is optimal for the organization and not done for local silo optimization.

In Conclusion

We have hopefully shown that the problem of chronic overcommitment is the result of many patterns and people interacting with each other and that any solution to this problem must be applied across several different layers. As a rule of thumb though, until you have a clear understanding of your organization's capacity, don't start any new work until you've closed something old. Our business is not to start as much as possible; it's to finish as much as possible.

I'm as proud of what we don't do as I am of what we do. – Steve Jobs

About the Authors

Rolf Häsänen is the founder of Value At Work and a systems thinker whom is passionate about improvement and innovation. Combining principles and methods of Systems Thinking, Lean Product Development, Design Thinking and the Agile world, Rolf helps people solve complex business problems and improve their organizations. Currently Rolf is working with challenges involved with large-scale product development and how to capture and share knowledge across organizational boundaries and unlock the full potential of team learning.

 Morgan Ahlström combines a broad experience from several different roles in IT organizations in many different industries such as banking, media/television, automotive, telecom, travel, fashion and facilities management. This has given him a great ability to help his clients find new solutions to their challenges. For more than ten years, he has continuously nurtured a strong interest in Agile software development and change management in organizations and uses these skills to help his clients develop more effective and efficient organizations. Today, Morgan is mainly working as a lean/agile coach, helping individuals, teams and organizations implement Agile processes.