If your team keeps telling you the project is 90% done, this article is about the questions that both support them and get you the answers you need, so you can trust whatever deadline comes out of the conversation. The catch is doing it without micromanaging, and I'd argue that coming across as a micromanager is one of the quickest ways, ironically, to make a team perform worse.
Hearing 90% for the third time is demoralizing. Sometimes you don't even notice you've heard it in the last two meetings until you're sitting in this one, hearing it again. As a non-technical leader, you may not know how to dig in, and you worry about getting dragged into the weeds.
I've been called into two projects where the team kept saying, "We're almost done. We're almost done." Both times the date was at risk, and my team came in to get the project across the line. Both times, it shipped.
Why a team keeps saying 90%
It's rarely malicious. Usually the team keeps uncovering new work, or the developers have strong feelings about the infrastructure or the architecture. Sometimes they hit problems nobody expected. Sometimes the product manager, product owner, or technical product manager reporting progress doesn't have a firm grasp on it.
Start from the assumption that people are doing their best. It's possible someone doesn't have the skills yet to report the state of things accurately, and that's fixable with training and collaboration. A skill someone doesn't have yet isn't a personal moral failing. It's also possible the team never had the information infrastructure to report well: one source of truth, a shared definition of done, and a clear path from idea to release. That isn't a moral failing on the leader's part either. Both gaps are fixable, and closing them is part of the leader's job.
I'm going to harp on this one until I harp on it into the ground. Most projects start with a few people agreeing on what they want to build, and then the plan goes one of two ways. Someone writes a War and Peace document that covers everything you could imagine, often a three-year plan for what everyone thinks is a three-month feature, or the decisions live in direct messages and private chats. Either way, there's no single source of truth. The happy medium sits somewhere between documentation that only lives in private messages and a freaking Wikipedia's worth of information.
Most teams know the software development lifecycle well. What's often missing is the whole path from "we think we want to build this" all the way out the door. That path has so many handoffs that it gets brittle and fragile, and that's where things fall apart. You get the project that's 90% done for six weeks in a row, arguments over RAG status, and requests to build RACIs. RAG stands for red, amber, green: red means the project is really off track, yellow means it's starting to slip, and green means it's on track for its target date. RACI stands for responsible, accountable, consulted, and informed, and I hate them.
When I came into one of these projects, the first thing I did was get everyone in a room to agree on what done looks like. We started from what users should be able to do once the work is complete and worked backward into user journey slices. Those slices became a contract for what the project would deliver. From there, the team could estimate, and we could report accurately on what was feasible.
What to do on Monday
If you keep hearing 90%, Monday is the day to start finding out why.
Start by knowing your people. Support them, stay as hands-off as you can, and ask humble inquiry questions that get them to walk you through their plan. Humble inquiry is a term from the organizational psychologist Edgar Schein. In my words, it means asking questions out of curiosity, never as a gotcha or to shame someone, because you want to understand the situation, the problem, or the person well enough to collaborate. It reminds me of exploratory talk, from the psychologist Neil Mercer, where people explain their thinking, criticize ideas, and hold their own ideas loosely so the group can move toward a common goal. That's the conversation you want, instead of a power struggle.
Be aware of the institutional power you hold. The higher you rise in an organization, the more your position shapes how people show up in conversations with you. When you can cost someone their livelihood, the dynamic changes, so you have to work extra hard to show them you have their back.
If you've had three check-ins and the answer is still 90%, the team probably needs more scaffolding to dig in and report accurately. That's when I offer it, directly and with evidence:
"My goal isn't to micromanage you. What I see is three check-ins where we've heard 90%, which tells me you might need more resources, or better guidance from me on how to report where the project stands."
That's the needle to thread. Even if you don't think you're micromanaging, your team may experience it that way, so check in with them often about how your involvement is landing.
There's also a version of this story where the dev team tries to drown you in technical jargon. You don't have to understand the jargon, and needing it explained in plain terms isn't a failure on your part. It's fine to call it out: "I think you're trying to drown me in technical detail so I'll stop asking questions. I want to believe that's not the case, and the evidence of this conversation says otherwise."
Even then, the team isn't acting out of malice. They're protecting themselves from a leader they expect to be upset that they're behind, or they don't have the language to explain the problem. There's no villain in this story. It's a miscommunication and/or a skill gap, and in most cases, both can be fixed.
You don't need every question
You don't need to ask every question, only the ones that matter. Most of them fall into three groups.
What's behind the number?
- "I've noticed we've been at 90% for the last couple of meetings. Can we dig into how you're getting that number?" For more on how to get them to speak about confidence accurately, check out our post on confidence score.
- "Of what's left, which piece is the biggest?" The last 10% is rarely split evenly. Asking which piece is biggest shows you where the remaining time and risk sit, and sometimes the answer is a piece everyone called small. “Cleanup” is a common one: it can turn into a junk drawer for everything the team has been meaning to get to, so make sure there are boundaries on what’s included.
- "Have we been keeping track of why the date keeps moving?"
Sometimes not even the team realizes they’re letting the date slip. That’s why it’s important to document new challenges that arise or even just the pattern of confidence percentage and how it fluctuates or remains static.
What does done look like, and what's in it?
- "Do we have a document that lays out the original plan and what done looks like?"
If nobody agreed on what done looks like, the team can't tell you how close they are, because there's no finish line to measure against. If the document exists but hasn't been touched since kickoff, that's worth knowing too. - "Is this piece a dealbreaker for the customer, or something sales really wants? If nobody here knows, that's fine. I'll check with sales."
Scope often grows after kickoff, through a sales call or an email thread the team only sees later. Separating what the customer needs from what someone promised tells you what can wait for a fast follow, and taking the follow-up yourself or delegating to someone outside the development team keeps it off the team's plate. - "What other open questions do you need answered before you can confidently give me a date?"
This is the question that turns up what nobody has mentioned yet, like a review the customer requires before launch. It also tells the team you'd rather have a date they believe in than one that sounds good in the meeting.
What's in the way?
- "What's been taking up most of your week? If you need help, I can find someone."
The person closest to the work usually knows exactly where their time goes, and it isn't always this project. On-call work or side requests can quietly eat days every week. Offering help up front makes it safe to say so. - "What are we waiting on, and is it blocking development?"
Some blockers sit outside the team, like paperwork, system access, or another team's approval. Teams often assume everything is their job, so chasing those down eats the time they'd otherwise spend writing code. Once you know what's in the way, you can get it to the person who owns it and give the team that time back.
There's one warning that comes with "I can find someone." Adding people to a late project usually makes it later. Fred Brooks wrote about this in The Mythical Man-Month: new people have to be trained, and the person training them falls further behind in the meantime. This close to a date, it's often better to eat the cost, borrow someone from another team for a narrow task, and make sure the estimate counts the time that's already going elsewhere.
When someone hints at a problem, don't let it get moved to a side conversation you won't be part of. If someone offers to sort out the details offline, you can say, "We don't have to take this offline. I'd like to hear more about this piece."
Part of the skill is knowing what to focus on. If a security review will take two to three weeks, it doesn't need an owner today; it needs to be in the timeline you take to the customer. Knowing which things to worry about right now keeps the conversation from overloading everyone. When something does need an owner, assign it to the person who should be responsible, and if there's no clear process, build one with them.
What success looks like
Success means you aren't in this position again. Your team has grown its skills, and you've built a product lifecycle, workflows, and processes that make it easy to go from a feature idea all the way to the customer. Your team knows what to communicate, when, and how.
What you're paying for
This is where we are worth hiring. We know which questions to ask, and we know when a room has hit cognitive overload. You're paying for that expertise, and for someone who can facilitate these conversations efficiently, because we can do the calculus in our heads fast about which questions are worth asking in a given context and which aren't.
You can't outsource that to ai, either. When you're in the room, you can't pause and say, "Let me ask ChatGPT what I should ask next."
If you're hearing 90% right now (for the third time), bring it to us. Ask us a specific question, and we'll answer it on the blog. You can also come to office hours, free every Tuesday at 8:30 am Pacific, and talk it through with us and a small group. If you want to discuss your specific situation one-on-one, spend an hour with webs.