It used to work!

Over a century, we have optimized classical project management and project governance practices to nearly perfection. But there is one serious issue. The problems we are trying to solve have become more complex, and the classical methods do not deliver the level of control we need and expect.

The classic methods assume that the scope is well-defined and that the project cost can be estimated with reasonable accuracy. This assumption is fair for simple projects, which made up the majority of problems solved in the last century.

Today, most simple problems are solved, and slowly and gradually, they have become exponentially more complex. The scope is unclear, and we expect to learn how to exploit the potential during the project. At the start of the project, we may not even know which strategy to follow to solve the problem in the fastest and cheapest way. In fact, a fixed deadline and budget make no sense, but they are still the prevailing management controls.

Then what, you may ask?

There is still no silver bullet, but plenty of great methods have emerged during the last decades that try to solve the real problem with different approaches. Cynefin, Open strategy, Agile, Beyond Budgeting, DevOps, BIM, Autonomous Teams, Technology Readiness Levels,... (Each will have their own "Short Take")

All these methods have three things in common:

1. They have emerged from ambitious professionals who, from a more sophisticated level, are striving to solve the real problem.

2. They have proven useful in specific contexts—not all, but that does not make them bad methods. It points to the greatest challenge of them all: You must find the methods that apply to your context.

3. Their success depends on true leadership and support from senior management, which is, unfortunately, the most commonly reported obstacle.

   
   

Before we move on, we must acknowledge that some methods are becoming increasingly counterproductive in complex environments.

• Financial controls. More frequent and precise reporting of the time that has passed and the money spent will only distract from the real problems and add to the administrative cost.

• Change Requests. Each one comes with a transaction cost and a time delay, which again introduces a ripple effect in the projects. There is a break-even point where the ripple effects become impossible to catch up with. Due to the delay, we recognize that point too late. To my knowledge, there is no data to tell where the break-even point is, but surely, it is much sooner than we would like to believe.

We do not need more of the classic methods. We still need them for simple projects and also for the simple parts of complex projects. We need to exploit the benefits of new methods and find out where they can bring more control and predictability to complex projects.

This is where you become essential! Your real-life experience with a method AND the context in which you had success(or failure) with it. Contribute to the community - we need your experience.

Contribute