The People, Process, & Progress Podcast - How to Make "Done" Mean Done

Episode Date: November 24, 2025

A clear definition of done can make or break a project. In this episode, How to Make "Done" Mean Done, I share lessons from projects where success was obvious, as well as moments where even well written requirements failed to reflect what the customer really needed or what the leader intended. I also talk through how expectations get added quietly, why shadow scope appears, and how to protect the finish line so teams can deliver with confidence.What You Will Learn:How to define done based on outcome, not activityHow to translate requirements into real customer needsHow to align what done means for each stakeholder groupHow to prevent shadow scope and last minute additionsHow to call work finished and protect your team’s momentumResources:People Process Progress: https://peopleprocessprogress.comThe People, Process, and Progress of Project Management: https://a.co/d/49be40gPeople first, Process aligned, Progress together.

I've led projects where done was so clear that the team moved like a single unit and the final handoff felt effortless. I've also led projects where we gathered all the requirements, checked every box, and still missed the mark because the requirements did not reflect what the customer actually needed or what the leader truly intended. And sometimes, even when we really are done, someone still believed we were not. That tension between finished and unfinished is one of the quietest project killers. Let's quote Dennis Waitley and say, clarity is the starting point of success, right?

So clarity is one thing teams often assume that they have when they don't. Welcome to the People Process Progress Podcasts, where we talk about how to bring people together, align process, and build progress together. I'm your host, Kevin Pinell, author of The Stability Equation, and The People Process and Progress of Project Management. To connect with me and learn more, visit Peopleprocessprogress.com. If you find this episode helpful, subscribe, leave a review, and share you. share it with others. Now let's get started. In today's episode, how to make done mean done, we're going to address the real challenge that done means different things to different people. The biggest challenge with done is that the meaning shifts depending on who you asked.

Developers thinks done is functional. Business owners think done means valuable. Operations think done means stable. Leaders think done means aligned to the original intent. And none of them we're wrong. But if these perspectives are not aligned, the team delivers one thing while the customer expected something else. It's kind of like the sidewalk we build and then people walk through the corner to cut the corner. The second challenge is kind of hidden. Sometimes people are afraid to say what they really want. So they disguise expectations as requirements. Other times maybe they change their minds halfway through. And sometimes one more thing sneaks in because the team did not establish the boundaries early enough. This episode is about eliminating that friction and creating

a definition of done that is strong enough to guide the work and flexible enough to support the customer. So let's talk about some actions we can take to build a definition of done that works in real life. Step on, I would say anchor in the outcome, not the tasks, right? Task can be completed without ever achieving a goal, right? Outcome-based definitions, though, help keep teams focused on impact. and if we put those tasks toward every outcome we want to achieve, its impact, not just activity, right? So we can ask ourselves, what will be possible once this is done that is not possible now?

So we've kind of changed the game with ever product or workflow or thing or personnel change or whatever the project is, right? The question helps expose mismatches maybe between tasks and intent, right? What's going to be possible when we're done here? The second thing we can do is translate requirements into reality, Requirements offer to capture what people think they want, but maybe it's not what they actually need because we haven't dove that much into their workflow before we try to apply technology to it. So instead of accepting requirements at face value, let's add this question. If we delivered everything written here perfectly, would that solve your problem?

Sometimes technology is a band-aid for an operational issue. If the answer is no, then we need to redefine the work, so it actually fits and we're going to solve the problem. and truly make done beneficial, right? This step helps prevent rework by surfacing gaps before the build begins, right? So first, we've anchored the outcome, not the tasks. Step two, we're gonna translate the requirements into reality, and then we're gonna say for step three,

define what done looks like to each stakeholder, right? And I know I've done this maybe single-threaded for the business owner and the sponsor, but what about everybody else, right? Each group sees differently. So let's say, for example, done for the customer means, dot, dot, dot, done for operations means, done for the technical team means, done for leadership means, right? And this takes minutes, but it saves you weeks of time. And then you can cross match

these and go, okay, where are these the line? Where are they totally off? What do we need to change? But then we've addressed each stakeholder, each team member, each person that's going to be affected by the outcome of this project. Step four, let's prevent the shadow version of scope, right? And what I mean by this is there's an official scope. We document it. We show everyone. And maybe there's a shadow scope that people kind of carry quietly thinking, oh, we could just add this or what about this thing, right? And it resurfaces when someone says, oh, I thought you included that when maybe you had a whole work session or multiple sessions, right, where it was never brought up before. So we can kind of shut it down nicely, but by asking, what expectations

have we not talked about yet? Right. So if we have a clear idea of scope and we're pretty sure we've communicated that and we double check it, when something comes up, be able to look, well, what have we not touched on? What have we not talked about yet, right? And kind of disarms people in a respectful way, gets the truth on the table, though. So we are, to build the definition of done, right, that works in real life, we're going to first anchor in the outcome, not the tasks. Second, we're going to translate requirements into reality. Third, we're going to define what it looks like to each stakeholder. Fourth, we're going to try and prevent that shadow version of scope by making sure we've talked

about the expectations. And five, we're going to make this public, right? We're going to put out kind of a press release, if you will, in a project. We're going to document it, right? We're going to write the definition of done in simple language and share it with everyone that could see it. I find this very helpful early on and bring it up maybe a couple of times to make sure, right, that done is a shared agreement instead of some private opinion, right? The team performs better when the finish line is visible. And when we see something and it's repeated to us, it sticks in our brain more. And the last step to make done something that's grounded in reality that works in real

life, let's lock the finish line and protect the finish line. It's kind of a new value that we haven't talked about before. But when the team hits the finish line, call it. Hey, we're done. This is it. This is the last task, implementation, training, whatever it is, for this project. We're going to celebrate it, document it, communicate it, capture those lessons learned, of course, but we can protect it by asking this question. Is this a new requirement or is it part

of the original commitment? So if it's part of the original, then okay, maybe we miss something. If it's new, we're going to say, hey, let's close out this official project that everyone approved and we funded and we put time towards and let's start to regather these new requirements into a next phase or a different project because, as you all know, companies don't have a lot of extra people sitting around, right? They should have a portfolio that's planned out. now and for the future, whether you're agile or waterfall or a mix of those, you should see what's coming down the road and have some wiggle room for stuff that comes up that you have to do that you didn't plan for. But if we keep adding requirements when we've gone through

the project, then we're never going to stop. It's not going to be a project, right? A project is unique. It's a one-time thing. But it can help stop that one more thing pattern, right? If we kind of lock it down, document it and say, is it new or is it part of the original? So what happens when we make done clear is when we define it the right way, we reduce emotional friction among the team, right? We eliminate silent expectations. We try and prevent that shadow scope. We protect the timelines, the original, and even if we updated them a bit. We strengthen trust amongst the team because we're open and transparent.

We're talking about things all the time. We give teams confident to finish strong. And that clear definition of done makes momentum easier to build and easier to maintain because we're all working. and toward the same thing, and it's clear and we reiterate it regularly for the team. Now, defining Don and sharing it and making it obvious is a leadership tool. It's not just a checklist item, right? It's not just the finish line. It's how we communicate.

It keeps people aligned, stakeholders honest, teams confident. And it's not about perfection. It's about agreement. And this is a useful tool as well to look back and go, hey, we all agreed on this. Even if a high level person says, well, I want to add this thing, we can say, well, we agreed on this. We set aside this many people this much time, this much money. How about if we work towards, you know, a next phase and next project like I talked about? And the best leaders I've worked with and folks I've seen do this and then I've done a few times myself, we create that agreement early and enforce it or remind ourselves of it pretty often.

So how can you all apply this that I believe will be helpful to find done for one real deliverable this week, right? Pick one deliverable, sit with your team or your customer or whoever you're working with if you're leading the project or program or organize a portfolio, whatever level you're at. And think about this and talk about it. What will this allow us to do that we cannot do today? What expectations have we not talked about yet? What will done look like for each group that's vested, right? Those stakeholders, what's not included in this? Because remember when we say scope, it's not just what's in scope,

we want to say what's out of scope or what's not part of this done. And what happens after we call it done, right? We're going to set up a celebration. We're going to shut it down. We're going to say, okay, all new issues is going to be a new ticket or a new request that goes to operations because that's part of that handoff, right? That pillar seven from the projects. We're going to write it down at a paragraph.

We're going to share it, reference it, protect it, and we will really feel the difference in the way that people work, communicate, and finish in all the projects and teams that we lead. Thank you so much for listening to People Process Progress Podcast. If this episode help you, share it with your team, subscribe wherever you listen, Apple Spotify, all the big players, leave a review that helps raise the show up, get more visibility. and go to people processprogress.com from our tools templates, links to my books, both the stability equations, seven pillars for a balanced life that will help you as a leader be more squared away yourself so you can help your teens and the people process and progress

of project management. They're both available on Amazon. The second book there is just what it is. It is in those sections talking about who are the people typically involved in all different types of project management offices or processes. And then what are processes that work that, you know, not even are official or that'll get you certified. But what gets, stuff done and what's progress and how do we celebrate it and how do we monitor and really a manual for real application in a quick way to keep people first make process aligned and make progress together. Thank you all so much for listening to the podcast. Godspeed.