Bringing Trouble Under Control: Quality, Estimates, and Closing [Vendor Control, Part 3]

When Problems Hit, How Do You Bring Them Under Control?

Part 1 covered the preparation you do before placing an order, and Part 2 covered managing a project once it's underway. Even so, problems never drop to zero. This final installment lays out how to bring trouble under control when it strikes, and how to bring a project to a clean finish. The common thread is a single stance: don't muscle through on sheer effort—deal with it through structure.

Deliverables That Fall Short of the Required Standard

A vendor's deliverable comes up for review and the verdict is "we can't use this." Saying nothing more than "please redo it" gets you the same thing back. Taking it in-house to fix yourself is the wrong move too.

• Document the quality standard: Spell out up front what makes something "usable."
• Set up reviews early: Don't wait for completion—insert reviews at intermediate stages.
• Provide a sample: Show a concrete example of "this is the level we expect."
• Ask for an improvement plan: Instead of just "redo it," have them deliver the root cause and the countermeasure together.

Quality isn't something you measure after the fact. When the buyer puts into words ahead of time what counts as a "pass," you prevent rework.

A Flood of Bugs in Testing

User acceptance testing (UAT) turns up many times more bugs than expected. If you panic at the number and commit to "we'll fix all of them," you lose control. The fast way to bring it under control is to look not at the count but at severity and cause.

• Classify by severity: critical / high / medium / low.
• Fix only critical and high immediately: It can be a sound call to push medium and low to the next phase.
• Analyze the root cause: Why did so many surface—insufficient testing, vague requirements, design problems?
• Put a prevention measure in place: Don't let it end as a one-off fix.

For example, in a situation where three times the expected number of bugs is reported, you'd move like this:

1. Classify by severity (2 critical / 8 high / 30 medium / 60 low).
2. Make the 10 critical and high bugs the target for this round, and get agreement to defer medium and low to the next phase.
3. Analyze why so many appeared (in this case, "vague requirements" turned out to be the main cause).
4. As a prevention measure, change the way the remaining development runs so that intermediate reviews are built in.

Rather than panicking over "100 bugs," break it down into "the 10 critical and high bugs by when, and how the rest will be handled." That alone gives you a clear line of sight.

More Volume Than Expected, or Not Enough Budget

You get started and find it takes twice the effort you estimated; you've burned 80% of the budget but you're only 60% through. These are the classic resource problems. Quietly stretching the schedule, or finishing on the remaining budget by cutting quality, are the worst possible moves.

• Calculate the overrun precisely: Build it up from effort, not from gut feel.
• Report to stakeholders early: Be specific—"we need another X yen and X weeks."
• Present three options: (1) extend the deadline, (2) add resources, (3) cut scope.
• Document the re-plan: Keep a record of what changed and who approved it.

Here, too, instead of "what should we do?" you lay out the options and have the decision-maker choose.

Not Enough People, and a Frontline Burning Out

Key members are telling you "I can't take any more." Just cheering them on or watching from the sidelines invites the worst outcome of all—people quitting.

• Make the workload visible (numbers showing who is carrying how much).
• Redistribute tasks (absorb them with other members or outside help).
• Consider cutting scope (narrow down to only the features you truly need).
• Escalate the attrition risk to upper management (ask for a decision on adding headcount).

Keep Pulling Out or Scaling Back on the Table

When there's truly no way to turn things around, continuing because "it would be a waste of everything we've spent" is dangerous. The money already spent is gone for good.

• Decide based on "the value still to be gained," not "the investment to date."
• Consider the middle path of scaling back (drastically narrowing scope and landing on a bare minimum).
• Present pulling out or scaling back as options to the decision-maker.

The courage to stop is also a mark of good project management. The call to keep the damage to a minimum is made with numbers, not emotion.

A Critical Problem Right Before Launch

One week before launch, a serious bug surfaces. Pushing the launch through anyway and postponing everything are both lazy choices.

• Pin down the scope of impact: Which features, which users are affected?
• Make the decision criteria explicit: If it's critical, postpone; if it's limited, get by with a workaround.
• Present three options: (1) postpone, (2) phased release, (3) ship on schedule with a workaround.
• Bring in the decision-maker: Don't make the call as PM alone.

To begin with, putting every feature into production at once magnifies the impact when something goes wrong. Where possible, ship the high-volume core operations first and push peripheral operations and exceptions to later stages. A phased release like this limits the blast radius when a problem appears and makes it easier to roll back.

"Nobody's Using It" After Go-Live

Even after a smooth launch, you may hear "I don't know how to use it" or "the old system was better." Just adding more training and manuals won't solve it.

• Analyze why it isn't usable: a UI problem, a workflow problem, or psychological resistance.
• Involve a key person on the frontline: have the frontline leader be the first to start using it.
• Create an early win: stage a moment where people genuinely feel "this is handy."
• Promise continuous improvement: respond with "we'll reflect your feedback and improve it."

Don't Settle an Estimate in One Pass

The first estimate is a starting draft. You organize the requirements, add and subtract features, and lock it down through back-and-forth alignment on both sides.

• Don't stop at "over budget"—work through "if we cut this, what drops out?" together.
• For a re-estimate, document the delta from the first version (what, how much, and why it was cut).
• When additional requests come in, don't refuse them—offer a change proposal like "drop A and add B, and the net is +X yen."

A vendor that turns down the conversation with "we already gave you a number" is more likely to blow up a project than one that responds "let's do another round of alignment." The buyer, for their part, engages in a way that draws out that attitude.

Don't Pass Acceptance on Gut Feel

Acceptance—the step where you accept the delivered product—is the last gate before trouble gets in. If you pass it on "it mostly works, so OK," it becomes hard to speak up later when problems emerge.

• Check the acceptance criteria against the requirements and definition of done you set before ordering.
• Verify not just functional requirements but non-functional ones too (performance, security, and so on).
• Test the behavior of failure cases too (error conditions, operations outside one's permissions).
• If there are open issues, agree on "when, who, and how they'll be fixed" before accepting.

Acceptance moves forward realistically when you treat it not as a binary "pass / fail" but as the place where you nail down "what's left and when it gets cleared." It also helps to split contract and payment milestones along the work phases—that makes a "never-ending project" less likely and lets both sides operate with a clear line of sight.

Closing That Won't Move Forward

A state of "almost done" drags on for months—the classic never-ending project. Stop repeating "just a little more" and build in a mechanism to finish.

• Make the completion criteria explicit: what counts as "done."
• Make the remaining tasks visible: "X items left to complete," in numbers.
• Set a deadline: "the closing meeting is on this date."
• Push unfinished tasks to the next phase: don't aim for perfection.

Create a Space Where "Bad News" Surfaces

Whether you can bring trouble under control quickly hinges on whether bad information surfaces quickly. "I'll report it once I've solved it" is the single biggest cause of delay. And the moment a problem hits, if you start hunting for "whose mistake was this," reports surface even less.

• Put out bad information the instant you spot it, in the form "there's a problem, and here's what we'll do."
• When you communicate it, separate the facts (what happened), the impact (on whom and how much), and the proposed measures (options 1–3).
• Don't blame "the person who surfaced bad information early"—commend them.
• Don't write off the cause as "carelessness"—fix the process and the checks (look at the mechanism, not the person).

A blame culture delays bad news, and delayed reports invite a blowup. Maintaining psychological safety is, in the end, what brings trouble under control early.

Look Ahead to Post-Launch Operation and Maintenance

Launch isn't the goal—it's the start of operations. So you aren't scrambling at the end, decide on the maintenance and operations setup early.

• Decide the contact points and response hours for incidents (the scope of the maintenance contract) ahead of time.
• Settle who handles minor fixes and configuration changes, and up to what point.
• Have manuals and a support contact ready before go-live.

When you design all the way through to a state where the system "keeps being used," not just "built and done," post-launch trouble goes down.

Turn the Retrospective Into Something You Use Next Time

A retrospective is pointless if you repeat the same failure on the next project. The key is not to let it end at "we'll be careful next time."

• Organize with Keep / Problem / Try: what to keep, the problems, what to try.
• Convert it into a concrete mechanism: not "be careful," but "add a check for X."
• Reflect it into the plan for the next project: turn the retrospective results into a template.
• Turn it into organizational knowledge: make one person's experience the organization's knowledge.

Wrapping Up: The Three Basic Principles of Project Management

The before-ordering, in-progress, and trouble-response phases we've walked through across this series ultimately boil down to these three principles:

1. Detect early, act early: Problems get worse over time. "Let's watch it a bit longer" is the most dangerous of all. When you sense something is off, act within 24 hours.
2. Structured information sharing: "Going well" and "we're fine" aren't information. Report with numbers + a deadline + an owner as a set. The worse the news, the more detail.
3. Present options: Not "what should we do?" but "which of (1)–(3) do you want?" Minimize the burden on the decision-maker, and include your own recommendation alongside.

Stick to these three principles and most troubles can be brought under control before they "blow up."

Series Wrap-Up Checklist

• Are you documenting the "pass criteria" for quality up front and reviewing at the intermediate stage?
• Are you classifying problems by "severity and cause" rather than by "count"?
• Are you reporting resource shortfalls early and presenting three options?
• Are you treating estimates as something to be aligned, and recording the delta?
• Have you set the completion criteria and the deadline for closing?
• Are you converting the retrospective into a "mechanism" and carrying it forward?

Related learning material: The requirements-definition and project-management courses this series is based on are covered in detail in the freely available IT Consulting Guidebook.

In Closing

Vendor control isn't a special talent—it's the accumulation of unglamorous habits. Nail down agreements before ordering, don't let things drift while underway, and bring trouble under control through structure. Just practicing these three installments will change the landscape of your projects dramatically.

That said, it's also true that carrying all of this on internal resources alone is a heavy load. Precisely because we've done the hands-on work as a development company, we can stand on the buyer's side as a PMO and provide hands-on support from validating the soundness of estimates through progress management and trouble response. When you reach the point of "we're not confident steering this on our own," feel free to reach out.