Project management was the worst thing that ever happened to IT

When we impose fixed time, money, and deliverables, which is the classic project management formula, then the only variable available to a project manager is the quality of the outputs. So the moment they encounter anything at variance with the requirements and the business case (which they inevitably will, as these are complex systems), they cut short testing, training, and documentation; and they start preparing a formal defect list to be heaved over the wall into production.

We end up in the extraordinary position of being in the business of manufacturing defects which we formally deliver to our customer tied up with a ribbon and ask them to sign them off as delivered.

This is clearly insane. Agile introduces the concept of zero known defects. This is the idea that we should stop manufacturing defects for a living.

The thing that kills IT is unplanned work. And the major cause of unplanned work is poor quality. Every time we push more known defects into production, we eat our future. We pile up technical debt, to be paid or foreclosed on one day. It is unsustainable.

We have to stop pushing defects. We have to commit to zero defects. By lifting quality we reduce unplanned work, which frees up time to further lift quality. it is a virtuous circle. It is the path out of hell. The only way to sustainable higher velocity is higher quality. The fundamental explanation of how Devops succeeds is VELOCITY THROUGH QUALITY.

So we changed the equation to say that we will fix the time, the money, and the quality; which means that the remaining variable is the deliverables. Traditional project management does not deal well with this: the fallacy of project management is that we are building simple systems. It leads to the myth of define once and execute perfectly, which is impossible in IT because we build complex systems where the outcome is unpredictable at the time that we begin our journey.

.

So how did we get in such a ridiculous position as to be manufacturers of defects?

The answer goes back to the 1980s, and the failure of organisations to effectively govern their IT. All enterprises manage three primary resources: people, money, and information. Back then, governors of organisations were good at managing money, and were starting to understand how to manage people, but information was a black art. As the sophistication and complexity of information management grew, governors and executives became nervous at the increasing amounts of money being put into this resource and their complete lack of understanding of why and how the money was used.

Rather than actually learn and understand as they did for finance and HR, governors responded by imposing a project management framework around IT, where the benefits were promised upfront before money was handed over, and the outcomes were measured at the end. This would have been OK if it had been done in an agile way - where a program defined what the benefits to be derived were but not how to derive them. unfortunately IT responded in its usual excessively fastidious way by imposing pedantic engineering methodologies like Prince2 which defined in detail how to execute on delivering the outcomes.

This led to the theatre and excessive levels of ceremony of project mangement:

• hundreds of pages of requirements which everybody knew would not or could not be delivered
• phased approach
• complex stage gates
• specialisation of function
• third parties assuring risk, compliance, and quality
• etc

Most of all it led to the lunacy where you don't get your money until you commit to time, cost, and deliverables. All such business cases are theatre, ceremonial, a lie.

At their heart, Agile and DevOps are fundamentally about shedding the yolk of project management and redesigning IT ways of working from first principles to build complex systems without theatre or excessive ceremony. We build systems where we iterate towards a hypothesis, exploring, failing, and incrementally growing a solution. That does governors' heads in.
.

Before you leap to defend orthodoxy, make sure you are familiar with

• complex systems theory, eg Cynefin
• antifragility
• product not project
• agile/devops thinking, e.g. iterate-increment-experiment-explore; fail fast; shift left; lean enterprise
• agile at scale, e.g. SAFe

It's the New Way Of Working
.

See also A project is a wave.