Project Diagnostics: When Your Delivery Approach Is Not Working
A project in trouble produces symptoms that all look alike. Dates slipping, rework climbing, a team working late, stakeholders losing confidence. Those symptoms are equally compatible with three quite different causes, and most organisations are practised at investigating two of them.
The work might be harder than anybody thought. The people might be short of skill, capacity or clarity. Or the method might not fit what is being done. The third gets examined least, partly because the method was usually chosen by somebody more senior than whoever is living with it, and partly because raising it sounds like an excuse.
Separating the three
Separating them is easier than it sounds, and it starts with the last five surprises. Write down the five things that went wrong or arrived unannounced in the past two months, then ask of each one whether the method could have surfaced it earlier.
Where the answer is mostly no, because nothing in the way the work is organised would have exposed it before it landed, the method is the candidate. A predictive plan that could not have shown a requirement changing, or an iterative approach that could not have shown a dependency on another programme, has a blind spot sitting exactly where this project keeps getting hit.
Where the answer is mostly yes, meaning the method would have caught it and nobody looked, the problem is execution or capacity. That is a different conversation, and usually an easier one.
Where the surprises were genuinely unforeseeable by any method, the work is harder than anybody thought, and the honest response is to change what is being promised rather than how it is organised.
What a mismatch looks like
Section 3.6 of the PMBOK® Guide Eighth Edition brings diagnostics into the tailoring work, and what helps most in practice is that the two common mismatches have distinct fingerprints.
A predictive method on uncertain work shows up as churn in the plan. Change requests arriving weekly, a baseline reset every quarter, estimates accurate at task level and badly wrong at plan level, and a team spending more hours re-planning than building. The giveaway is that the re-planning keeps producing a plan of the same shape. The plan is not learning, because the method assumes the learning was finished at the start.
An adaptive method on defined work shows up as motion without discovery. Iterations complete and nothing is learned from them, because there was nothing there to learn. The backlog is a decomposed specification with story points attached. The review is attended by fewer people each time. And the question stakeholders keep asking is when something will be finished, which is precisely the question the method was designed not to answer definitively. Teams in this position are often working well and getting no credit for it.
Two-week sprints and a question nobody could answer
A telecoms operator was deploying a new network management platform across six regional operations centres. The programme ran adaptively, two-week sprints, a product owner and a demonstration every fortnight, largely because the previous programme in that directorate had run that way and had gone well.
Eight months in, the sprints were completing, the team was competent, morale was reasonable and the sponsor had lost confidence. The five surprises told the story inside twenty minutes. Three of them were regional readiness problems, each discovered as a region was approached: a site without the network capacity, a team of forty needing training nobody had scheduled, a regulatory reporting change in one nation that altered the configuration. None of the three could have been surfaced by a sprint, because sprints look at the product and those were sequence problems.
The diagnosis was that the platform work was genuinely defined. The requirements came from a vendor product and a reporting obligation, so there was configuration and testing to do and very little to discover. The regional rollout, meanwhile, was a sequence with dependencies running through it, and nothing in the method was looking at it at all.
The change was one dial. The two-week cadence stayed, because it suited the configuration work and the team liked it. A regional rollout plan was built with dates, dependencies and named regional owners, reviewed monthly, and the first committed date for region four reached the sponsor in month eleven. The demonstrations dropped to one a month, because six people were attending a session designed for twenty. Nobody changed approach. The approach acquired the part it had been missing.
For a PMP® candidate, the question to put to any method is what it can see. A project surprised repeatedly by the same kind of event is describing a blind spot, and the fitting response adds the missing visibility rather than replacing everything that works. A team delivering steadily into an unhappy sponsor is often running an approach that answers a different question from the one being asked. Separating a problem with the work, the people and the method before choosing a response is the kind of reading a structured PMP exam preparation course sets out to rehearse.
The diagnostic takes half an hour and needs nobody senior. List the last five surprises, mark each as visible-in-advance or not, and look at the pattern. Then count the reporting events in a fortnight. A team carrying a stand-up, a sprint review, a retrospective, a steering group, a change board and a stage gate is running the ceremonies of two approaches and the controls of neither, and that count is a diagnosis on its own.
Interested in going further?
Telling a method that does not fit from a team that needs help is the hard part, because the two produce an identical status report. Omega's PMP® Exam Preparation works through situations where the symptoms match and the right response does not.
The diagnostics material sits alongside the rest of the tailoring work in the PMBOK® Guide Eighth Edition.
Ad · Amazon affiliate link.
References
A084: Selecting the Initial Development Approach
A066: How Project Characteristics Shape the Delivery Approach
A080: Tailoring the Life Cycle and Development Approach
A065: Choose the Approach Around the Deliverable
A064: Choosing Predictive, Agile or Hybrid for a Real Project
PMP and PMBOK are registered marks of the Project Management Institute, Inc.
