In the previous posts, we've covered goalposts: how to set them, how to communicate them to your team. And in this post, we are talking about the times you want to move those goalposts, because we all know you will.
And I want to change your mind about change. Now, I'm not here to convince you to never change your mind. I want you to be able to connect the dots better between great ideas and great outcomes.
The Documents:
Next Up:
I suggest watching this video next:
The Transcript:
So in the previous lessons, we were covering goalposts how to set them, how to communicate them to your team. And in this lesson, we are going to talk about the times you want to move those goalposts, because we all know you will. And I want to change your mind about change. Now, I'm not here to convince you to never change your mind.
I'm here to convince you that you're not Vito Corleone. The godfather created this huge organization of loyal uncomplaining folks who dedicate their lives to pleasing him. And that is not you, but more importantly, I want you to be able to connect the dots better between great ideas and great outcomes. You're an idea person. Visionaries are idea people. It's what defines you as visionaries.
And when you change your mind, it's because you've hit upon a good new idea sometime after putting the project in motion. But being in business is not just about what ideas you can dream up. It's about what you can make real. And one of my favorite quotes on this is by author Scott. Belsky, it's not about ideas. It's about making ideas happen.
And in business, that means that execution is at least as important as the idea that it's trying to bring to life. So great ideas can absolutely be squandered by poor execution and B minus ideas can become fantastic customer experiences when they are well executed. So if you think of those as two end points, which would you rather have in your business? So changing things up,
changing what done looks like comes with consequences to execution, and those consequences need to be named and made visible so that the decision to make the change can be made with full information. So let's get to the best practices. They're brutally straightforward here. One is have a process, number two, use it. So let's break them down. Have a process.
Now in traditional project management change control is a very formal process. Imagine if you're building a skyscraper and you have plumbers and the electrician team and the drywall guys, and they all need to be in the same space within hours of each other. And it absolutely matters which order they go in. So making any change in that condition has this cascading effect over multiple departments.
And it absolutely impacts the deadline, the budget and or the quality of the work. So in a formal change control process, the project manager would review a change request, come back with the estimated impacts on time or budget or work quality and armed with that data. The boss would make a decision about whether to go ahead with the change or not. And I recommend a similar three-step process for you,
define your change, map the implications, and then make an intentional decision based on the full, the full scope of the review. So I'm going to flip over to the tool set, and we'll go through this at the detail level. So the first is to define your change. Let's create a full design brief to describe what done looks like. And we need to be as thorough with this one as we were with the first one.
So we fully understand what the new done might look like. And then we can compare it against the original one so that we truly know what's being changed. Number two is determine the implications to the change. So this is where you would turn it over to an expert in project management. So this is the project manager themselves. They have that title or it's the integrator,
it's the COO. Sometimes it's the online business manager, whoever runs project management on your team is the person to take the ball at this step and review the request by looking at the project plan, the full scope of work and estimate what that will do to the original deadlines. So there's going to be deadline implications, whether a milestone will happen, have to happen later,
or the entire project needs to happen later. There might be budget implications. Something might cost a little bit more, whether it's rework or you need to bring somebody that you hadn't intended on to the team to do whatever the changes there also might be. Work. Quality implications were quality implications means that sometimes we try to do more within the same period of time.
So, so it wouldn't necessarily impact the deadlines and or the budget. And of course that means it could mean that the quality of work comes down a little bit, but basically those are the three aspects of a project that are impacted when you make a change deadlines, budget, and work quality. So when the project manager has those has that data has the implications.
There needs to be a moment where it is reviewed and discussed and negotiated. So it's quite possible that the project manager manager comes back with the implications, the consequences, and there to whatever, for whatever reason they're not. Okay. And so then a dialogue, this kind of negotiation begins well, what if we do have to propose changes or what if we do this,
but not that. And you sort of work through what the consequences would be by tinkering with the change requests. And then the CEO really does need to recognize and accept that those are the implications and the consequences to the change. You know, this is, I don't want to gloss over this because sometimes this is the part that it just doesn't sink into the head that,
that the fairies can't work any faster or that the change is. So, gosh, darn Marianna minor, that I cannot believe that this is the kind of implications that I'm looking at. You need to trust your team and your team needs to do a good job, of course, of mapping out the consequences. And then we need to realize them and then making an intentional decision about what you're moving forward with.
So those are the three big steps of a change control. So use it, I'm cautioning you here to not go Through the motions, to actually use this in a very real way. So there's a couple of ways that change control process won't work. And the first one is that it's just a fig leaf for the same old behavior where the change is a foregone conclusion and the attitude is great.
Now there's a process to impose my will on the team. It just looks like I've collaborated because we have this process in place. This is Vito Corleone with a pretty face. It's not change control. So don't be like veto. It will wear out your team because it's just the same old, same old. And it's going to start to erode trust because everyone can know,
everyone knows a fig leaf when they see one, the second way that it can, it won't work is that you were loose and fast with the original specs. And we can't really tell what's a change and what isn't because the original wasn't really locked down. And so we don't really understand what the impact is. And all we really know is here, we are again,
mid fire drill, trying to pull off a whole lot of work. Even though we have these gorgeous procedures and SOP is written down and they're somewhere in the Google drive. So that means that there's a number of points of failure in the process, not just change control, because these things all work hand in hand, you need to plan and scope the project,
and then you need to be deliberate about making a change. So when these all work hand in hand, you're going to get so much better at the upfront work of determining which projects are worthy, defining those original end goals and cultivating the discipline of bringing all the projects to the finish line before you're getting distracted or needing to change things up and all of that amounts to good business.
So the tool is the change control process that I just outlined a second ago. And the homework is to personalize the project. The real homework actually is committing to using the process when the heat is on, when the urge to change is really strong. And you just want to go, go, go. So personalizing the change control process helps make it real.
Instead of this thing, that's hanging out there that just has nothing to do with you or very little to do with you. So let's flip over to the homework and see how we can personalize it. So the first one is to let's designate where the design briefs are stored. And that to me is just a little bit of a marker that you really are going to do design briefs for all of your projects.
So we know what the goalposts should be. And then I would like for you to discuss probably with your project manager or the person who plays that role on your team, what are the conditions for a, what is the kind of change that we're talking about that would invoke this process? So what we're trying not to do is be ridiculously regimental. That's no fun for anybody.
There are ways that you can change something without going through a formal process, but there's something that kind of flips over from being I can make that change to, you know, what we need to stop and review it. And it could be simply that the project manager is deputized to throw a flag on the play and say, oh, this kind of request.
We need to do a formal process with this one. And maybe it's up to them to just sort of determine, or you two can talk through what the magnitude is. If there's a timing change, that's more than a week or more than a couple of days or something like that. What are the conditions of the change that would invoke let's actually have let's slow down and take a really good look about whether we want to do this or not.
So under determined implications that second step let's actually name the person who will review, who will do that review. And that's the project manager or the integrator COO that role and how will they present their findings? It could be that you actually have to call a special meeting. It could be that they simply do the work, and then they can do a five minute loom to you.
So you can digest it, just talk through how they will present their findings to you, and then how are you going to discuss them? So it also could be a formal meeting. If you're meeting up here, you might want to just continue the conversation and have a meeting that goes through the consequences sifts through them, sees if there's additional tweaks to the tweak that you want to make,
or maybe it's just a simple slack channel where you just chat it through and come to your decision. I do suggest that you have at least one other C-suite or in this discussion. Now your project manager may not be a C-suite or they may be a champion. I, if there is a C-suite or on your team, even if their job isn't directly involved in the change,
it's really good practice to have them involved in the discussion. And the reason is because they are used to speaking truth to power and can step in and sort of give you advice and be the one who can speak up when perhaps the person, the project manager on your team might not. And you really do want to hear truth here, no matter which way you ultimately decide you really do.
Don't want to be bit by an implication that was just swept under the rug. Let's get them out in the open and make a wide eyes wide open decision. And then who are the ultimate decision makers for 99% of you? You're going to type your name right here and hit hard return. And that's perfectly fine. If you do want to have a more collaborative, actual decision-making, then go ahead and state it here. But if you're, if you're the boss, you're the boss. And that just means you need to be very involved and very open-minded when you are hearing about the consequences of your change. So that is the homework for change control and bring any questions or discussion items to the weekly call.
Member discussion