This is Why IT Projects Fail

‍1. Plans go stale before they're delivered.

Big plans, long lead times, no customer feedback until the very end. It's a late and expensive reality check.

How this manifests itself:

• Unpredictable amount of delays despite generous timeline padding
• Missed requirements tagged as defects or change requests
• Copious amounts of regression defects (bug-fix whack-a-mole)
• Accumulated bad decisions, risks, and assumptions
• Late realisation due to having no customers in the picture, no analytics or any form telemetry

If you can't get it right, get it wrong faster.

What would you choose; learning in one go (at the very end), OR learning sooner where it is significantly cheaper to course correct?

‍

2. Mercenaries: Disposable, single-use teams

Forming - Storming - Norming - Performing and later Adjourning. It's known as Tuckman's stages of team development. Taking a team through these stages takes time and costs money. But it pays off generously. Teams that stick together achieve remarkable results with consistent predictability. They build trust, they establish processes, they retain knowledge, and know their customers.

But some organisations form teams around projects, rather than ongoing value.

Signs to look out for:

• Teams adjourn when they hit a project deadline, and parachute into various new "projects"

‍

3. Floodgates and the flow of value

Businesses are systems that take customer and market input through value-adding activities, until they become valuable.

Here's the obvious; if price > perceived value, you won't get customers. There's no willingness to pay (WTP) if customers don't think they're getting the best bang for their buck.

There are lots of things customers don't want to pay for. Decisions that take weeks to make, approvals that get stuck, expensive assumptions that are not grounded in reality, and so on.

‍

How to spot this

• Work waits in various queues within an organisation before it comes to life
• Months of effort handed off to the next department by throwing documents or code over the wall
• Departments with fragmented, misaligned, and even competing incentives and goals

What's causing all this?

The approach. These are not projects. They're mistreated platforms or products. Cementing a scope document from the first day in an ever-changing environment is a disaster waiting to happen.

Doing what works

Give them the treatment that works. Set a clear and compelling goal, collaborate with your customers, establish telemetry and analytics, and deliver continuously.

Give teams purpose, not subtasks.

‍

I help organisations build product-led operating models that deliver consistently. If your software delivery methodology feels like a civil infrastructure project, let's have a chat.