15 Questions to Audit Your IT Project Status

You’re sitting in a status meeting. The dashboard glows green. Everyone nods confidently. Yet something feels off. Your gut says the project is slipping, but you can’t prove it.

You’re not paranoid. According to the Standish Group’s analysis of roughly 50,000 projects, about 66% of technology projects end in partial or total failure. The green light on your screen might be hiding a red reality underneath. This gap between reported status and actual health is sometimes called the “Watermelon Effect”: green on the outside, red on the inside.

If something feels off, it probably is. This article gives you 15 questions to find out. They cut through polished status updates and expose what’s actually happening in the codebase, the process, and the team.

Move Beyond Status Reports to Uncover the Truth

When status reports become unreliable, you need to interrogate the system, not just the manager. A misleading status report is a communication failure, and poor communication is a leading cause of project failure. Reports filter through layers of optimism, politics, and honest miscommunication. The truth lives in the raw data: commit histories, build logs, unfiltered backlogs. But only if you have direct access.

Think of this as shifting from passive monitoring to active inquiry. Passive monitoring means trusting the report. Active inquiry means asking for evidence and verifying it yourself. The questions below are designed to do exactly that.

Questions About Process and Progress That Reveal the Real Status

The goal here is to distinguish between reported activity and actual deployable value. A task marked “complete” doesn’t mean a feature is usable. A green status doesn’t mean the project is healthy. These questions force your vendor to show their work.

1. “Show me the deployment pipeline for the feature marked ‘Complete’ this week. Can we deploy it to production right now?”

This exposes what we call the Deployment Gap. Vendors often mark tasks “Done” when coding finishes, not when the feature is tested, integrated, and deployable. Ask them to pull up the CI/CD dashboard and walk you through it live. If the answer is “It works on dev, but needs integration,” the status report is misleading you. A feature that can’t ship isn’t complete.

2. “I want this small change made. How long until it’s live in production?”

This is Lead Time for Changes in plain language: the time from request to running in production. High-performing teams deploy on-demand, often multiple times per day. Low performers take weeks or months. If a trivial change takes forever, the process is broken and tech debt is out of control. If they can’t give you a confident answer, they don’t know their own velocity.

3. “Show me your active blockers and how long they’ve been open.”

Every project has friction. Blockers, dependencies, waiting on decisions. Ask to see them. Some teams track blockers in the issue tracker; others use Slack threads or standups. Either can work. The point is: can they show you what’s currently blocking progress and how long it’s been stuck? If the answer is “nothing,” probe deeper. Zero obstacles usually means the blockers exist but aren’t visible to you.

4. “What are you worried about on this project?”

Everyone worries about something. Deadlines, dependencies, a tricky integration, a team member struggling. This question invites honesty without sounding accusatory. If the answer is “nothing,” probe deeper. Every project has friction. A team with zero concerns may be in a rare calm period, or they may not feel safe sharing. Either way, follow up. Listen for whether they share real concerns or deflect with safe answers like “just the usual timeline pressure.”

5. “Let’s pull up the issue tracker right now.”

Not a question, a statement. Watching them navigate the system live removes the curation layer. You see the same data they see. If they hesitate, offer to send you a report later, or need to “prepare something first,” ask why. It may be a reasonable request, or it may signal a habit of filtering what you see. A confident team opens the screen without flinching.

Questions to Expose Hidden Technical Debt and Code Quality Issues

Technical debt is the silent project killer. It accumulates invisibly until suddenly every change takes twice as long and breaks twice as much. Non-technical stakeholders rarely see it coming. These questions surface the rot before it’s too late.

6. “How does quality improvement happen here? Show me an example.”

Every healthy project invests in quality: refactoring messy code, improving test coverage, simplifying complex logic. Some teams create dedicated refactor PRs; others bundle improvements into feature work. Either approach works. What matters is that it happens. Ask them to show you a recent example—a commit, a PR, or a pattern they follow. If they can’t point to anything, the codebase is accumulating technical debt and nobody is doing anything about it. Developers spend an average of 33% of their time dealing with technical debt. Ignoring it won’t make it disappear.

7. “What’s your automated test coverage? Show me.”

Automated tests catch bugs before they reach production. Low coverage means large parts of the codebase can break without warning. The right target depends on project complexity and risk tolerance, but as a general benchmark: 80% and more coverage is solid; below 50% is often a warning sign. If they can’t show you a number, they’re not tracking it. If they’re not tracking it, they’re relying on manual testing or luck. Neither scales.

8. “Show me your oldest open bugs.”

A bug that’s been open for six months is stuck for a reason. Ask why. If it’s a dependency, complexity, or architectural issue, that tells you something real about the codebase. But if the answer is simply “it’s not a priority,” that’s a different problem. Ask how many other bugs are piling up behind that same excuse.

Questions About Team Culture and Development Practices

Process theater looks like Agile but doesn’t adapt. Blame culture punishes honesty and hides problems. Misalignment turns developers into order-takers. High turnover drains knowledge. These questions expose the team dynamics that status reports never show.

9. “Tell me about a time a retrospective led to a real change. What was it, and did it stick?”

Agile is built on continuous improvement. Retrospectives exist to surface problems and drive change. If they can’t point to a specific example, or if the “change” was trivial, the retrospectives are theater. If the change didn’t stick, ask why. A team that identifies problems but can’t sustain fixes has a deeper issue.

10. “Tell me about the last significant mistake the team made. How did the team handle it?”

This tests psychological safety, which DORA research identifies as a predictor of high-performing teams. Listen for whether they describe fixing the system or blaming a person. Healthy teams run blameless post-mortems and focus on process improvements. If blame enters the story, note it. A culture that punishes mistakes teaches the team to hide the next one.

11. “Let’s pull a developer into this call. I want to hear them explain the ‘why’ behind this feature.”

Don’t ask the manager to vouch for the team. Get a developer on the call and hear it yourself. If they can explain the business problem the feature solves, you have partners. If they can only describe what it does technically, you have order-takers. Order-takers build exactly what you specified, even if it’s the wrong thing. Partners understand the goal and push back when the spec doesn’t serve it.

12. “How many people on this project have changed in the last 6 months? Pretend I’m a new team member. How would you onboard me?”

Every departure takes institutional knowledge with it. Don’t accept “we document everything” at face value. Make them walk you through the onboarding process as if you were joining tomorrow. Watch what they pull up: is it a clear guide or a scramble? Then ask to speak with the newest team member about their actual experience. If it took them months to get productive, the process isn’t working.

Questions to Confirm Your Vendor Delivers Real Value

Activity isn’t progress. A team can be busy without being productive. These questions check whether requirements are clearly defined, whether the team understands business priorities, and whether the work translates into real results.

13. “Show me some user stories from the backlog. Walk me through how one is written.”

If the stories are vague one-liners (“implement login”), the PM isn’t doing their job. And if the PM isn’t defining clear requirements, how can developers deliver what you need? Look for acceptance criteria, context, and the “why.” Empty tasks mean nobody owns the requirements, and that won’t be fixed by better documentation.

14. “Let’s pull up the build. I’ll pick a few items marked ‘done’ and you show me how they work.”

You control what gets verified. If they hesitate or need to cherry-pick what to show, ask why. Some items may have legitimate dependencies, but repeated hesitation is worth noting. Features marked “done” should work. If they don’t, the status reports aren’t reliable. This takes minutes and reveals more than any dashboard ever could.

15. “What would you cut from the backlog? And why hasn’t it been cut already?”

If they can identify low-value items, ask why those are still in scope. If everything is “essential,” they’re not prioritizing. A team that treats all features as equally important doesn’t understand the business well enough to make trade-offs. They’re building bloatware and burning your budget on work that doesn’t matter.

What to Do When the Answers Concern You

Evasive or defensive answers signal systemic failure. Internal meetings won’t fix a problem the vendor can’t or won’t acknowledge. At some point, questions reach their limit.

Watch for these warning signs:

• Repeated “I’ll get back to you” without follow-through
• Defensiveness or deflection when you ask for evidence
• Conflicting narratives between managers and engineers
• Metrics that are always green or conveniently unavailable

If these patterns emerge, your next step depends on where you stand:

• If you choose to escalate: Bringing project concerns to leadership requires careful framing. Our framework for communicating IT project problems to executives helps you structure that conversation without losing credibility.
• If you’re considering switching vendors: Before making that call, assess how dependent you actually are. Our guide to spotting and preventing vendor lock-in includes a self-assessment and practical safeguards.
• If you want to quantify the damage: Technical debt came up in several questions. If you need hard numbers to make a decision, our guide explains how to calculate the real cost of accumulated technical debt using 9 metrics.
• If you choose to get an outside perspective: Sometimes the patterns are clear but the path forward isn’t. An independent project audit can dig into the codebase, process, and team dynamics to give you concrete options with cost estimates.

Conclusion

These 15 questions shift you from passive report consumer to active investigator. They demand evidence, expose gaps, and distinguish performative vendors from genuine partners.

The goal isn’t to catch your vendor in a lie. It’s to surface problems early enough to fix them. A vendor who welcomes these questions is demonstrating confidence and transparency. A vendor who evades them is telling you everything you need to know.

Start with one question from each category in your next status meeting. Document the answers. Look for patterns. If evasion or inconsistency emerges, escalate to a formal audit before the project crosses the point of no return. Your gut brought you this far. Now you have the tools to prove it right or wrong.