This video is about a pattern that I have noticed lately in the IT industry. It‘s actually an anti-pattern or a fallacy and I would like to call it „this shot must be a winner“. Or in other words, this project must be a success.
Despite all our knowledge about large and complex IT programs, I see that these are planned and started again and again. We know, they have a high risk of failing, they become late and exceed their budgets and customers are often not happy about the end results. I personally have been a member in some of these death marches so I know what I am talking about.
But why do people still consider these large and complex IT projects? Despite the knowledge of their implementation risk. Despite the knowledge that chances of success can be improved, e.g. by decreasing the batch size. In other words be cutting large initiatives into several thin slices.
To be frank, let’s acknowledge, there are some programs which are large and complex by nature. Think of building a large bridge or a train track from one city to another. An agile approach of delivering value fast, breaking down initiatives and experimenting with MVPs does not really work there. At least to my knowledge. Please let me know if you know any examples in the comments. I am really interested. So some of our challenges don‘t lend themselves to reduction in size, complexity, risk and time. And as a side note and teaser, the Cynefin framework can help us to understand why and how some challenges are different than others.
Ok, back to today’s IT programs. A few days ago I moderated a round table about portfolio management. A participant said that the days of large and complex programs have passed. I thought, yes, she‘s right, but at the same time, this is not what I am seeing out there. Again and again, I am seeing large and complex IT programs kicked-off. With unrealistic time lines, unclear outcomes and high risks. I hear IT managers say: „This project must be a winner“. „We really need to get it right this time“, „we are setting everything on one card“. Or even „The future of our company depends on this strategic opportunity“.
Then I think, they should know better. They should know about the risks of large and complex IT programs. They should see the possibilities to cut out thin slices, start with MVPs. Or use methods like R.A.T (riskiest assumptions tested). Why don‘t they get it? It’s all there, right in front of them. The evidence, on the one side, and the principles, techniques and tools on the other side. And yes, I hear complaints from some managers in these death marches. So what‘s happening?
I came to believe that it is not the individual‘s desire for large and complex IT programs that creates this anti-pattern. I rather believe the problem is systematic. I came to believe that the root cause lies in way how mature companies have grown over time to become what they are. And it’s these mature companies where I see this anti-pattern. I believe this anti-pattern is rooted in the management hierarchy that mature companies have established over years of growth. You know this management hierarchy. It’s the predominant org structure in well developed or mature firms.
In short, as firms grow and mature they utilize efficiencies of scale to offer once differentiated services at lower prizes as the competition it catching up. They need to, in order to survive in a competitive environment. And by doing that, they create silos. And these silos can make a firm more efficient, but also less able to change and adapt.
So, the management hierarchy and silos.
Let‘s have a look at how decisions are made in the hierarchy.
Decision move up the management ranks. They bubble up. Look, managers usually don’t push decisions downwards to the teams or people affected. One of the reasons is that teams usually don‘t have end-2-end responsibility for the services or products they create. Usually, they are not autonomous. They are dependent on the input and alignment with other teams. It’s a direct consequence of having silos. Let‘s not forget why we have these silos in place to begin with. Within them, people can specialize, they can build deeper knowledge and skills with peers who are working on the same kind of problems. They gather more work of a similar type and thus can automate and use pooling to become more efficient.
Let‘s say, one team decides to implement a certain capability or change. As this team is not autonomous, it requires support from one or more other teams or colleagues from other departments. Thus, now, it‘s not a single team working on this initiative any more, but people from different teams or even a coordinated effort from several teams. And therefore the scope gets larger. And due to alignment and required hand-overs the duration also increases. So it‘s not the team‘s decision alone any more. Thus, decisions naturally move up the hierarchy. And they become larger in scope and impact as more teams get affected. So changes and the associated decisions naturally become more and more complex. And consequently they also become more risky. And management is aware of that. They ask teams to go back and further analyze the proposed change to make it less risky. Obviously, this well-meant task further slows down execution speed. In my practice I have witnesses several of these analyses and feasibility studies being executed, the result were nicely prepared, but NOBODY, yes nobody, actually looked at the results. Since further more urgent questions came up in the meanwhile. That‘s a large source of waste. And obviously, people doing the tedious analysis work also loose their motivation over time.
As changes in mature firms take longer to implement they also miss the chance to quickly see the impact and the results of initiatives. So instead of learning and making further decisions based on these learnings, they need to rely on business cases and management narratives.
With that in mind, I don‘t blame any individual for starting a large and complex program. For saying „this shot must be a winner“. It‘s the org structure of mature firms that creates large and complex IT projects. It‘s the system. And as long as we don‘t start changing the structure of the organization, digital transformations will continue to fail. And we will continue to see large and complex projects and many of these will fail, as well.
So what can we do about this? To be frank, I am not sure. Digital Transformations are difficult. Yet, considering the agile principle of starting small, the first thing is awareness. Understanding the impact of the management hierarchy and silos. And seeing how it can be done differently. Seeing truly agile firms. Experiencing how autonomous teams operate. But beware of faux agile or cargo cult agile. So go visit the valley or start here in Berlin. And that is not just for the development teams, especially managers should consider the impact of silos and the management hierarchy Go and read about the evidence. Read about Conway‘s law. Then, if you are a VP or director, think twice the next time you ask for a feasibility study. Why don‘t you ask for an MVP instead and learn from the user feedback. If you are a program manager, think twice and ask yourself if you really want to wait for 18 months to see the first results. And be honest to yourself, chances are that you don‘t even get results in 18 months, it might be later and you might not get what you have hoped for in the first place. Listen carefully the next time somebody tells you this project must be a winner. Investigate how a thin slice could look like. It‘s not easy, to be fair, but so are these large and complex programs and death marches.
