An organization has a cross-functional process that isn't working: unclear ownership, exceptions running at volume, four functions with four sets of requirements, a legacy system nobody will touch. The request that comes out of it is always the same: we need two more builders.

That request is rational. It's also a category error. Every symptom on that list is a definition problem, and the response is a capacity purchase.

More implementation capacity does not solve an undefined implementation. It gives the ambiguity more hands.

What's covered

  • The four things a builder actually needs before day one, and why two to three weeks of concentrated work is the real cost, not a quarter
  • Five predictable consequences of adding capacity to an undefined implementation. Not risks. Consequences.
  • Why builders who look slow are usually a definition problem wearing a quality problem's clothes
  • The Implementation Continuum: eight links, with implementation sixth. You can hire for link six on a Tuesday; there's no job title for link two.
  • The four-stage order: orchestrate, architect, specify, augment, and the artifact each stage has to produce. If a stage doesn't produce an artifact, it didn't happen.
  • The four objections this argument always gets, answered directly, including the one about already having a PMO
  • How to tell a definition problem from a capacity problem, and the three-change-request test that settles it in twenty minutes

What came with it