Solutions that DO help with "large, complex projects" in the enterprise

As I posted earlier, "large, complex projects" in the enterprise tend to suffer from problems of alignment and overconfidence.

I also posted typical "solutions" that don't work.

Here are some solutions that help:

Conquer, then divide

"In XP, we don't divide and conquer. We conquer and divide. First we make something that works, then we bust that up and solve the little parts." 

Kent Beck

Setting aside market risk, the riskiest part of "large, complex projects" is whether all the various parts actually work correctly together (aka integration).

The typical approach most "large, complex projects" is to build separate pieces with separate teams  that they then attempt to integrate.  This tends to cause multiple failures.

A better approach is to start with an integrated solution, focusing on resolving the key integration points, using a single, highly skilled team, and ONLY when the critical integration issues are resolved, work out how to scale up to multiple teams.

Have regular integration checkpoints

Setting aside market risk, the riskiest part of "large, complex projects" is whether all the various parts actually work correctly together (aka integration).

Problems associated with delaying integration is so common that it has its own name: "Integration Hell".

The larger, the more complex, the project, the more difficult and expensive it is to have regular integration checkpoints.

The larger, the more complex, the project, the more essential it is to have regular integration checkpoints.

An integration checkpoint means choosing one or more end-to-end capabilities and synchronising all teams to deliver it at a common point in time.

Milestones on "large, complex projects" that are not integration milestones are mostly theatre and a waste of time.

Reduce accidental complexity

"Accidental complexity relates to problems which engineers create and can fix... Essential complexity is caused by the problem to be solve..."
No Silver Bullet, Wikipedia

Large, complex projects, as the name suggests, are complex enough without adding additional, unnecessary complexity.

Essential complexity reflects what is inherent to the problem to be solved.

Accidental complexity reflects how we choose to solve the problem and is typically related to technology and organisational design choices.

For example, that different customer segments may be using your product for different purposes is essential complexity.  That the product is split into N modules because you had N departments working on it is accidental complexity.  That your mobile product feels like a desktop product because you wanted to reuse your desktop UI is accidental complexity.

Reducing accidental complexity comes down to choosing the right language, tools, design approach, and organisational structure for the problem at hand, not the problem you used to have.

General themes of solutions that do work:

• Addressing the critical aspects of uncertainty first
• Addressing inherent uncertainty with regular feedback
• Not making the situation even more complex with additional constraints