A Project That Doesn’t Fit One Box

It is Tuesday afternoon, and the project manager is in a meeting with the compliance lead, a product owner, and the vendor team building a patient portal for a hospital network. Compliance needs formal sign off on a set of controls by a fixed audit date. The product owner shows a new set of changes from clinicians that arrived this morning, and they are meaningful changes, not wording tweaks. The vendor asks for a stable requirements document so they can finish build and testing. Everyone is making a reasonable request, but they cannot all be true at once. Each week the team locks requirements to satisfy sign off, then reopens them to respond to real user feedback. Rework piles up, testing gets squeezed, and the audit trail starts to look messy because decisions are revisited without clean approval records.

Before you name a delivery method, predict where this project fails first if you do nothing.

The trap is thinking the team is choosing between being fast and being compliant. The real issue is that the project has two different kinds of work mixed together. One part needs traceability, which means we can show how a requirement became a design, then a build, then a test, then an approval. Another part needs rapid learning, which means we expect to revise what we build as we learn from users. When you force rapid learning into a heavy approval path, you get bottlenecks. When you force traceability into a fast cycle without clear controls, you get audit findings. A beginner instinct is to ask everyone to align and freeze scope. It feels like leadership because it reduces noise in the moment, but it often produces a later explosion of change requests when reality catches up.

PM Reality
In regulated work, you do not negotiate the audit date. You negotiate what is in scope for that date and how changes flow through approvals.

What you are actually choosing

When people say Agile or Waterfall, they often mean a bundle of decisions. For this course, we will separate that bundle into three practical levers you can design on purpose.

The first lever is the feedback loop, meaning how often you get real input from users or stakeholders and turn it into changes to what you build. Short loops help you learn quickly, but they also create more change traffic that must be managed.

The second lever is the planning horizon, meaning how far ahead you plan in detail before you commit to build and test. A long horizon can raise predictability, but it assumes requirements stay stable. A short horizon accepts uncertainty, but it requires stakeholders to stay engaged so the team is not guessing.

The third lever is control points, meaning moments where work must meet defined criteria before it can proceed. A control point might be a formal approval, a security review, or an entry gate into testing. Control points reduce risk, but they add governance overhead and waiting time.

Map these three levers to project outcomes, and notice the trade offs.