Keys to a Winning Team: Part 3

Summary

Throughout this vlog series, we’ve highlighted a real-world example of a winning team and discussed the qualities that make it successful. They are:

1. Strong Leadership
2. Common Goal
3. Rules of the Game

The fourth key to a winning team is Action Plan. Every effective team has an Action Plan that engages and involves everyone. It defines who does what by when.

Watch this 8-minute vlog to learn how a manufacturing company was able to develop and complete a detailed Action Plan for the shutdown of a massive piece of equipment within a given timeframe.

Transcript

All right, welcome back. In the first two blogs, we talked about Strong Leadership, the importance of a Common Goal, and the Rules of the Game. Now we’re going to move on to putting together an Action Plan because the action plan is really critical for the team to be successful. And so you want to really think about the action plan, and how it engages and involves everybody. So your action plan is to find who does what, by when. And in this particular instance, Chad was interested, or the organization was interested in developing a project plan for the shutdowns of some major pieces of equipment. 

 Now, this piece of equipment, it was like, it covered six stories in this thing, the thing was bigger than my house in Tennessee, three-story farmhouse, this thing dwarfed it! And all the ancillary equipment around. So the shutdowns consisted of about 300 tasks. And they were basically glommed together in a pseudo work plan, and they would span some period of time, like basically, how much time can we afford, based on some factors that didn’t really make sense.

But they would come up with a game plan and say, This outage is going to take, you know, 15 days, and then, as you can see here, the time would slip, right. And the 15 days would turn to 16 days, 17 days, 18 days. And generally, at some point, management will say, just put in the damn thing back up and get it rolling again, we need to make tons we can’t afford this thing down again. And that’s what happened. 

And Critical Path Method isn’t what they were using at the time, they’re not using anything but the critical path has a problem. And projects that are done with the critical path method, often, if not always, turn into chaos, and finish late. And there’s a better technology based on some thinking of The Theory of Constraints. And it comes about because, when you look at the tasks in the shutdown, and you look at the purple bar being what was planned, and the green was when work was actually done, there’s actually a lot of dead time. And there’s a lot of time that tasks aren’t actually advancing. 

And so what Chad and the team learned to do, was to use a tool called Critical Chain Project Management, or critical chain scheduling. And they use a tool by ProChain Solutions Incorporated, which automated it and made it much easier to do. And so what they would do, and what you do in the critical chain is you take all those extended task time, and you collapse them down. So the green part of this drawing here is the actual task times and you do something really radical, you build your plan, based on those condensed times. 

Now, the likelihood that you’re going to finish that project is pretty dang slim. So you take all that extra time, and you tack it on the back end by this project buffer here. And this project buffer basically is a shock absorber for things that could go wrong. I won’t go into the math, but you can actually take that time and cut it in half. And say we’re actually we don’t need all that extra time. Because chances are that everything is going to go absolutely wrong are slim to none. And so you move the commitment up and right off the bat, just by design, they ended up with a project plan that was significantly shorter than any outages in recent history. Right? 

Then they identified the key tasks that would make up the set of tasks that would determine how long the outage should take. Alright, and there was a handful, I think in the first outage, it was a little over a dozen. And those key tasks, then the team set about figuring out, how can we do these tasks better? How can we collapse this? And how can we make sure those are the only tasks that dictate how long an outage happens? and this became the basis of an experiment, right? And so there’s the critical chain later, and it’s project buffer and date. And here’s the experiment. If we do these nine tasks, in this order, then by the commitment date, we should complete the shutdown.

And the interesting thing about this structure is the odds of getting that completion date are extremely high, as in the high 90s. 99 point something percent of the time if you’d set it up properly, alright, and this right off the bat, set up the notion of continuous improvement. And this is what was so exciting and energizing for the team.

So here we have content, sequence, timing, and outcome as an experiment. That was the plan, right? And when they executed the outage, they would do the plan. And after the execution, they would actually take time to check and learn and see what happened, what can we learn, and then revise the next plan. Because the cool thing about shutdowns is every six or eight weeks, they did another mill. And so it was rinse and repeat, rinse and repeat, they would do these projects over and over again. And so they were setting up a process of continuous improvement. That would drive the constant improvement of the shutdowns. 

And then we got down to the specific tasks. So within the critical chain, you can look at a task and say, okay, what’s its content sequence and timing and outcome, and make sure that the work plan or the work order was consistent with that, and that it had content, it had sequence, it had timing, and it had outcome.

Now, when you do this, you end up having to do a second body of work, because the timing that you come up with on a test is dependent on whether you’re prepared to do that task, right. In order for timing to be true on the work design, you need to have the equipment in place, you’d have the tools, you need to have the materials and the supplies and the information at your fingertips to do that job.

And that’s exactly what they did. Chris, the master mechanic, built this toolbox for the first of all of the tasks on the critical chain. And so this toolbox had this specific equipment, specific tools, specific materials, supplies, and the information necessary to do the work on that component of the mill. And in the first iteration of the outage, he built five of these custom toolboxes, and they were world-class, absolutely amazing. 

And so just like content sequence, timing, outcome creates a hypothesis, the tool design or the workplace design creates a hypothesis that we believe if we have everything we need, we can get this work done in this timeframe. And so do we? so we have a plan, this toolbox, we do it, we check it, and we act upon it. All right. And that’s how you start engaging everybody in the continuous improvement process at your business. It’s through experimentation.

So the action plan was very specific. It called for structuring for the first time, their shutdowns, that clearly defined the small set of tasks that would dictate how long the outage should be, and structuring everything else, so it didn’t dictate how long the outers should be. And then within that started the process of defining the work of designing the work as sub experiments, alright. And that brings us up to the fifth key for winning team and that’s supporting risk-taking. Again, thank you for joining our blog. We’ll continue on in the next one. Have a great day.