One Project, Two Clocks

A product team is developing an AI-assisted workflow. The model quality is uncertain, users have not agreed on the right interaction, and every test changes what the team believes it should build next. Short iterations are the sensible way to work.

The same project has a launch tied to a major industry event. Marketing has purchased the space. Customer demonstrations are booked. A security review must finish six weeks earlier, and a government submission has a fixed window.

The team is working in iterations, but the business is working toward dates that will not move.

This is often presented as a choice between agile and waterfall. It is the wrong choice. The project has two clocks, and each needs a different form of management.

The learning clock and the commitment clock

AI development fits the learning clock particularly well. Teams rarely know in advance which model, retrieval method, prompt structure, evaluation set, or human control will produce an acceptable result. Product discovery, performance optimization, and much R&D work have the same shape.

The clocks are connected, but they are not interchangeable. Iterations generate evidence. Gates use that evidence to release money, accept risk, change scope, or stop the work.

A fixed date does not make the work waterfall

Waterfall is not another word for planning. It describes a predominantly sequential flow in which one phase is expected to finish before the next begins. That can be entirely appropriate when the work is well understood, changes are expensive, and the order of operations is real.

A fixed date, however, does not make uncertain work predictable. Giving an AI training program a detailed twelve-month task plan does not eliminate uncertainty. It only records assumptions as though they were facts.

The opposite mistake is to treat uncertainty as a reason not to make commitments. Executives cannot reserve capital, coordinate partners, or approve a marketing spend against a backlog whose answer to every question is that priorities may change.

The Agile Manifesto principles emphasize working software, frequent delivery, and responsiveness to changing requirements. They do not say that businesses should stop budgeting, governing risk, or coordinating external obligations. The Project Management Institute similarly describes delivery approaches as a continuum from predictive through iterative and incremental to agile, with hybrid approaches combining practices to fit the work rather than forcing one method across every project (PMI, A Spectrum of Approaches to Project Agility).

The useful question is not, “Are we agile?” It is, “Which parts of this work can be predicted, which must be learned, and where must the organization make a decision?”

Build gates around decisions, not documents

A gate should exist because someone must make a consequential decision. Completing a document is not a business decision.

Useful gates include:

• Approve a larger experiment after a small one reaches a defined quality threshold
• Commit production infrastructure after load and cost have been measured
• Begin a regulated validation process after the design has stabilized
• Release marketing spend after the product demonstrates the required customer journey
• Migrate customers after rollback, support, and incident procedures have been exercised
• Stop a project when the evidence no longer supports its business case

This structure gives the iterative team room to learn while giving the wider business a reliable point at which learning becomes a commitment.

Plan backwards, learn forwards

First, plan backwards from the external event. Identify procurement lead times, approval windows, integration freezes, training periods, customer notices, and other dependencies that genuinely constrain the schedule. These are facts to manage, not stories to estimate away.

Second, work forwards through short evidence cycles. The team runs experiments, releases narrow slices, and updates its understanding. The content of later work can change as long as the evidence needed at the next gate arrives on time.

Third, protect a viable fallback. If a conference demonstration depends on a model reaching 95 percent accuracy, decide in advance what will happen at 90 percent. The fallback might narrow the use case, add human review, use a deterministic workflow for part of the process, or change the demonstration. Discovering the fallback two days before the event is not agility. It is late risk management.

Separate forecasts from commitments

Teams lose trust when every estimate is heard as a promise. Executives lose control when every promise is later described as an estimate.

Use different language for different levels of certainty:

An early AI prototype may have a target and a forecast. A regulatory submission has a commitment. The decision to include the AI capability in that submission is a gate.

This vocabulary prevents a backlog estimate from quietly turning into a public launch date.

Match the method to the workstream

One program can contain several workstreams with different operating methods.

An AI model evaluation may be highly iterative. A data-centre installation may be mostly predictive because equipment, permits, and physical sequencing impose real dependencies. A government validation may require prescribed evidence and review periods. Customer onboarding may use an incremental rollout by cohort.

Trying to make all four workstreams follow the same ceremony creates overhead without improving control. A stronger program gives each workstream the method it needs and joins them through shared milestones, risks, and decision gates.

This is hybrid delivery in a useful sense. It is not a compromise halfway between two methodologies. It is an explicit design for coordinating work with different levels of uncertainty.

The minimum management system

The roadmap should be stable at the level of business outcomes and gates. The work between those gates is allowed to change.

Leadership is the connection between the clocks

The hardest part is rarely selecting a project-management framework. It is maintaining an honest connection between technical learning and business commitment.

Someone must decide when the evidence is strong enough, when uncertainty remains acceptable, when scope should move, and when an external promise should not be made. That person also needs enough technical depth to challenge a weak experiment and enough commercial context to understand the cost of waiting.

This is often the missing role in a mid-size business. The engineering team can run iterations. The executive team can set dates. Neither group, on its own, necessarily owns the translation between them.

A good operating model does not make uncertain work certain. It makes uncertainty visible early enough for the business to act on it.