Chapter 17: Meetings and oversight: what the vendor should show you

Agree on the meeting rhythm at signing

The meeting calendar belongs in the contract or in the project plan you sign. An indicative plan for two-week sprints:

Holding meetings is not enough on its own. The participants must work with data and make decisions. In the digital building permit system project, the steering committees met, but according to the audit, nobody responded effectively to the warnings from independent technical oversight, and regular status reporting was missing DSŘ audit, technical part, 2025 (more in chapter 20).

A demo means running software, not a presentation

The demo runs in your test environment, not on a developer’s laptop or in PowerPoint. The product owner, key users, and IT attend it, not just the project managers. A canceled or “local” demo is a red flag.

Prepare your own review plan. The 18F guide recommends checking quality indicators at every demo, usually every two weeks, as part of accepting the work 18F, 2024. One page is enough:

What to ask to see every sprint:

• running software in your test environment,
• which user stories are done according to the Definition of Done and which are not,
• results of automated tests and the security scan,
• open defects by severity and how they are developing,
• an updated backlog with estimates,
• what input or decisions the vendor needs from you.

What to ask to see every month at the steering committee:

• what percentage of the budget has been spent and what percentage of the MVP has been accepted,
• an estimated MVP completion date based on the team’s actual velocity, not just the original plan,
• the risk register and the status of the measures to address the risks,
• change requests: approved, rejected, pending, and their impact on the price.

Access from day one, written into the contract

Without access, you only check what the vendor chooses to show you. Ask for:

• the code repository, ideally administered by your organization,
• the task tool with the backlog,
• continuous integration and the results of tests and scans,
• the test and staging environments,
• documentation and records of technical decisions,
• cloud accounts in your name.

The Czech adaptation of 18F puts it directly: all outputs, from software to graphic designs, belong to the contracting authority and are handed over at the end of every sprint Česko.Digital, 2022. The answer “you don’t have access to the code for security reasons” means that you have no control.

A few numbers every manager understands

• Value: how many user stories you have accepted compared with the plan. A chart where the line of finished work rises toward the scope line is called a burn-up chart.
• Money: X% of the budget spent against Y% of the MVP accepted. If the share of the budget spent exceeds the share of scope accepted by 15–20 percentage points, it is time to intervene. This is an indicative threshold.
• Quality: open defects by severity and their trend.
• Forecast: the MVP date calculated from the team’s actual velocity.

The technical team can also track the five DORA metrics: how often the team deploys, how long it takes for a change to reach production, how often deployments fail, how quickly the team restores service, and what share of deployments are unplanned fixes DORA, metrics. You do not need to understand them in detail; it is enough to ask to see them and watch whether they improve.

The “90% done” syndrome

When a vendor reports 90% for several months in a row, it is a red flag, not evidence of progress. The last 10% usually contains integrations, data migration, performance, and security, which is the hardest part. It is like a painter who has finished all the walls, and only the ceiling, the windows, and the cleanup are missing. So measure accepted scope, not percentages estimated by the vendor. An indicative threshold for escalation: 4–6 weeks without a new result that could be deployed (chapter 19).