Failed, or designed not to succeed?

What if project failures were not really failures at all?

Failure sounds like something happening by accident that can be remedied by fiddling with team dynamics and user story construction, sprint constitution, and priorities. It’s not like failure is an entirely binary condition. Many “failures” are declared success to save face, and lots of failed projects may have succeeded with little or no change.

What we’ve been calling failure might better be understood as a war waged by clients, developers, and middle managers over control of project and team policy, without a focus on project success.

What’s that mean? If your product manager, project manager, and architect (the core team) are working together and doing their jobs, you should know within the first few weeks of a project whether it will succeed or not.

Signs that your core team is not working together include discussions about the Statement of Work and who promised what. Is it in scope or out of scope? While necessary to a certain degree, these conversations can also signal that people within your project are vying for control, rather than focusing on success.

Working together the core team should produce a project plan. This plan starts with an architecture informed by the requirements but designed to insulate the project from volatilities.

Without the architecture and the project plan, the odds soar that the project will fail. The important distinction here is whether you are making decisions against a plan designed from the start for success. If your decisions are based on something else (the backlog perhaps, or the statement of work) then it’s hard to understand how these decision will affect the plan.

The plan is how you move from the accident of failure, to the goal of success.