Musing on a Friday afternoon about the reasons why nearly all large organizations see most 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. The main reason for using this approach is that it gives management a false sense of security through an illusion of control: they think they know at the start what they will get at the end, they can measure progress, for example by looking at spending vs. intermediate results, and they can shout at someone (i.e., the project manager) when things go wrong.

Because a project is temporary, line management does not take sufficient responsibility, deferring to (and blaming) program and project managers for decisions they themselves should take. Moreover, projects are often seen as a threat to and disturbance of the going concern by the line organization, who make no effort in contributing to and absorbing their results.

Moreover, this approach only works (barely) in static circumstances. In the complex and changing environment of today, a project’s clients cannot give a clear statement of what they 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 approaches see “scope creep” as one of the main threats to a project’s success, and as a reaction, project managers defend this scope by building walls, excluding relevant external influences and ignoring possible reuse of project results by others. Thus, failure is guaranteed and user satisfaction unattainable.

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 leave for another time, this approach suffers from equally huge failures if even a small piece of this big puzzle does not fit.

Then 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”, an equally muddled concept. Instead, we should treat the entire life cycle of IT and business artifacts and capabilities as a whole, doing away with this artificial distinction between “building” and “maintaining”.

Rather, we need to look at the life cycle of the integrated business and IT landscape, consisting of elements of different granularity that each have their own business value, life cycle and rhythm. Managing such a cycle of cycles is completely different from classical project management. Defining clear interfaces between elements, matching the impedance of their life cycles, reusing existing capabilities to create new business value, and reacting fluidly to external changes should be the order of the day.

Some practices in the agile movement are steps in the right direction. Continuous integration, short iterations with close interaction with the customer and the “always in beta” approach of companies like Google are examples of this. Other management approaches such as continuous improvement and Kaizen also take this life cycle stance, and a portfolio approach to application landscapes is a step in this direction as well.

Still, even within the agile movement project thinking is rife. Perhaps this is unavoidable, because management needs the illusion of control that projects offer. Unless forward looking CEOs and CIOs start thinking in radically different ways about organizing and managing the evolution of their organizations’ capabilities, we will continue to be faced with overspending and underachieving IT shops that are seen as a hindrance rather than as a partner by their business counterparts.

Comments (1)

Only registered users can write comments.
Please login or register.