Escaping the Jaws of the Project Monster

Escaping the Jaws of the Project Monster

The other day, while I was musing about the reasons why many large organizations see many of their IT initiatives fail or underachieve, I came up with a rather simple conclusion: ‘project thinking’ is the root cause of these disappointments. Let me explain.

The basic tenet behind a project approach is that each project has a clear goal, a fixed budget, a start, a delivery date, and a concrete result. An important reason for this approach is that it gives management a feeling of governance through an illusion of control: they think they know at the start what they will get at the end, they can measure progress by looking at spending, and they can shout at someone (i.e., the project manager) when things go wrong. Because a project is temporary, line management does not feel responsible. They can defer to (and blame) program and project managers for decisions they themselves should take.

The project approach suffers from various other shortcomings, too: new teams that need to familiarize themselves with the problem and solution space; an overbearing bureaucracy enforced by management’s insistence on methods like Prince2 (because they are ‘industry-standard best practices’); the start-stop moments required by these methods, which interrupt progress and slow the project down; building features just because they are in the project plan, not because they are actually needed, et cetera.

Moreover, such an approach only works (if barely) in static circumstances. In today’s complex and changing environment, a project’s clients often cannot give a clear statement of what they want or need (‘I know it when I see it’). And even if (they think) they can, these goals start shifting even before the project is under way. Classical project management sees this ‘scope creep’ as a threat to a project’s success. As a reaction, project managers defend their scope by building walls, excluding important requirements and relevant external influences. Thus, user satisfaction is unattainable and failure is guaranteed.

Scope
Making things worse, this scope itself is often defined much too broadly. Without applying proper separation of concerns, projects are defined that should solve business or government problems by building one huge ‘application’ or ‘system’. Next to the fallacy of technology optimism, which I will discuss another time, this approach fails with a big bang if even a small piece of this large puzzle does not fit. If you define monster projects, the project monster will devour you…

Finally, there is the idea that an IT project has a moment of ‘delivery’, when the result is finished and ready for use. As we all know, over 80% of IT spending in large organizations is on ‘maintenance’; a muddled concept, since this usually means adding new functionality, so how is this different from ‘development’?

The way forward
We should stop treating change as the exception, to be handled by projects and programs that are put outside of the ‘normal’ operations. Organizations in the ‘New Normal’ are in a constant state of flux. As stated by Gartner (keynote ITXpo 2013):

“In 2017, every company will be a digital company. Capabilities to change fast and remain agile will be imperative.”

We need to take a more holistic approach to the entire life cycle of IT and business capabilities and resources, doing away with this artificial distinction between ‘building’ and ‘maintaining’. The business and IT landscape should be seen as a portfolio of elements, each with its own business value, life cycle and rhythm. We can allocate and reallocate budget to these capabilities and resources based on their expected and measured business value. By matching their rhythms and reacting fluidly to external influences, we can create more agile organizations that are in tune with their surroundings.

Various practices in the agile movement are steps in this direction. Short iterations in close interaction with the customer, continuous delivery with DevOps practices, and the ‘always in beta’ approach of companies like Google, Netflix and Spotify are examples of this. Management methods like Lean and Kaizen also take this continuous improvement and life-cycle stance. The concept of ‘value streams’ as adopted by approaches such as the Scaled Agile Framework is an important step in the right direction as well.

We advocate the use of enterprise architecture as a knowledge hub to connect various disciplines involved in change in your organization. Enterprise architecture helps you to integrate and share information on various structures across your organization. It provides you with relevant input for prioritizing and planning transformations. It gives you program-level coordination across value streams to realize these changes in a coherent manner. It helps you to track the realization of the expected benefits, and hence to correct your course if necessary. Closely related to this, enterprise portfolio management enables you to take a value-based approach to managing the assets and change initiatives in your organization. This helps to keep everything aligned with the desired business outcomes, which should of course be focused on the customer or citizen.

Forward-looking CEOs and CIOs are starting to think in different ways about organizing and managing the evolution of their organizations’ capabilities. Over the last years, I have spoken with several managers at organizations in government, banking and insurance who realize that a new way of working is needed. They are building their change capability based on such a value stream, life cycle, and continuous delivery approach, focused on developing and growing a portfolio of business capabilities. Let’s hope other organizations will follow their example and escape the jaws of the project monster. At BiZZdesign, we are happy to help our clients with building such a business transformation capability.