A Green Project Can Still Carry a Red Assumption

Delivery can be on plan while one untested condition still has the power to change the release decision.

One of the more uncomfortable lessons in software delivery is that a Green project and a dangerous assumption can exist at the same time. I saw this on a payment-management mobile application where the team was working in regular sprints, planned functionality was moving, and the delivery evidence we were tracking supported a Green status against the current plan.

Real-user validation changed the picture. Some banking integrations completed the payment flow, while others failed because they required an additional authentication or security-validation step that our initial integration did not yet support correctly. Delivery had been progressing, but one condition underneath the plan had not been tested broadly enough.

The assumption mattered more than we realized

I am using “Red assumption” as a practical description, not as a formal project-status category. It is an assumption that has enough leverage to change the release decision if it proves false.

In this project, we had validated a payment path and were effectively relying on that path being representative enough of the intended integrations. Real-user validation showed that it was not. Once the additional authentication path surfaced, the release decision changed: the affected integrations were held back from the MVP while the team worked through the extra requirements, updated the flow, revalidated it, and added those integrations later.

That sequence matters because the issue was not a lack of delivery activity. The issue was that part of the release decision still depended on a condition we had not proved across the operating environment.

Assumptions often hide inside ordinary project language

Some assumptions are explicit in an assumptions log, but many are embedded in everyday statements such as “the external dependency should behave the same way,” “the approval should arrive before release,” “the test data should be representative,” or “the process should work the same way in production.”

None of those statements is automatically a problem. They become important when the project status or release decision depends on them and nobody is actively checking whether they still hold. A project can therefore look well controlled while remaining exposed to one unproven condition.

The important question is whether the assumption is decision-critical

Every project contains assumptions, and trying to eliminate all of them would stop delivery. The useful distinction is whether a particular assumption can change scope, timing, release readiness, or another material decision.

If proving an assumption false would change the release date, remove part of the scope, or alter the project status, it deserves more than a routine line in a log. It needs evidence appropriate to the condition: an end-to-end test, supplier confirmation, pilot, user-validation exercise, approval, or another direct check.

The artifact itself is secondary. What matters is whether the condition has actually been tested in the environment that matters.

Green can still be the right status

The lesson from the payment project was not that the earlier Green status was fabricated. Green was a reasonable description of delivery progress against the evidence available at that point; the weakness was allowing that status to imply more than the evidence covered.

Delivery progress and operational readiness are related, but they are not identical. A team can be building the planned functionality on schedule while still carrying an assumption that has not survived contact with the real operating environment. When new evidence changes that assumption, the responsible response is to update the decision rather than defend the old color.

One useful check before accepting Green

At the next status review, identify the assumption that would cause the biggest change if it proved false, then check whether it has actually been tested recently enough and in the environment that matters.

This does not require another large reporting process. It requires knowing where the current status still depends on belief rather than evidence. In the payment case, finding that gap during validation allowed the team to narrow the rollout, correct the integration, and expand later instead of discovering the problem after a broader release.

Check what your project status is actually supported by

If you want a quick way to inspect what your current project evidence supports, what is inferred, and what may still be missing, run the free Project Delivery Health Check.