Friday, September 26 - For Immediate Release: Shape Minds, Build Brands, and Deliver Results with Game-Changing Public Relations (2015)

For Immediate Release: Shape Minds, Build Brands, and Deliver Results with Game-Changing Public Relations (2015)

Chapter 20

• Friday, September 26

Three days later, I’m at my desk, trying to read a report on Phoenix progress from Kirsten on my laptop. As it whirs and wheezes, I wonder how many weeks it’s been since John’s security patch bricked my laptop.

Getting replacement laptops is like a lottery. It’s tempting to bribe one of the service desk people, as one of the Marketing managers suggested, but I refuse to jump the queue. I have to keep playing by the rules since I’m the person responsible for making and enforcing them. I make a note to talk with Patty about our urgent need to reduce lead times on these laptop replacements.

Finally, the e-mail comes up:

From: Kirsten Fingle

To: Steve Masters,

Cc: Bill Palmer, Chris Allers, Sarah Moulton

Date: September 26, 10:33 AM

Subject: Great news on project front!


We are finally making headway. The project freeze and the resulting IT focus on Phoenix has broken the logjam. We’ve accomplished more in the previous seven days that we typically get done in an entire month.

Kudos to everyone on the team!

On a side note: many project sponsors are very frustrated about their projects being put on hold. In particular, Sarah Moulton believes that her projects are exempt from the freeze. I referred her to you.

Attached is the formal status report. Please let me know if you have any questions.


Although the note about Sarah making trouble again makes my jaw clench, this is absolutely fantastic news.

We were expecting it, but the good news is welcome, nonetheless, especially after earlier in the week. We had a big setback because of a Sev 1 incident that took out all the internal phone and voicemail systems, bringing Sales and Manufacturing to its knees on the last day of the quarter.

Two hours into the outage, we discovered it was caused by one of our networking vendors who accidentally made a change to our production phone system instead of the hot spare.

The outage will impact our quarterly revenue, but we don’t know how much yet. In order to prevent this from happening again, we’re putting together a project to monitor our critical systems for unauthorized changes.

This monitoring project is what Wes, Patty, and John are talking about, huddled around Patty’s conference table.

I say, “Sorry to interrupt, but I wanted to share the good news.” I show them Kirsten’s e-mail.

Wes leans back and says, “Well, that makes it official. Your project freeze is actually working.”

Patty looks over at him, appearing surprised. “You actually doubted it? Come on, we’ve both been talking about how we’ve never seen people so focused before. It’s amazing how the project freeze has reduced the priority conflicts and bad multitasking. We know it’s made a huge difference in productivity.”

Wes shrugs then smiles. “Until Kirsten gives us credit, it’s all just in our heads.”

He’s got a point. It really is great to have Kirsten acknowledge the progress we’re making.

“By the way,” Patty says, “She’s is not kidding about the business managers freaking out. I’ve had more and more VPs calling me, demanding a waiver for their various pet projects or asking to get some work done off the books. It’s not just Sarah—she’s just the most blatant and vocal.”

I frown. “Okay, that’s part of our job and we expected this. But, I don’t want this kind of pressure being applied to any of our people. Wes?”

“I’ve told everyone on my team that they’re to route any complaints to me. And trust me, I call each of those guys back and give them an earful,” he says.

Patty says, “I’m already getting anxious about what we do after we lift the project freeze. Won’t that be like opening up the floodgates?”

Once again, she has put her finger on something important. I say, “I’ll call Erik, but before I do, how do we currently prioritize our work? When we commit to work on a project, a change, a service request, or anything else, how does anyone decide what to work on at any given time? What happens if there are competing priorities?”

“That happens every freaking day!” says Wes, looking incredulous. “That’s what’s so great about freezing all the projects except for one. No one has to decide what they’re working on. No multitasking allowed.”

“That’s not my question,” I say. “When we have multiple streams of work going on simultaneously, how does anyone decide what needs to get worked on at any given time?”

“Well,” Wes says, “we trust them to make the right decision, based on the data they have. That’s why we hire smart people.”

This is not good.

Recalling my twenty minutes observing Brent before the project freeze, I ask, “And on what data do all our smart people base their prioritization decisions?”

Wes says defensively, “We all try to juggle the competing priorities as best as we can. That’s life, right? Priorities change.”

“Let’s be honest,” Patty says. “Priority 1 is whoever is yelling the loudest, with the tie-breaker being who can escalate to the most senior executive. Except when they’re more subtle. I’ve seen a bunch of my staff always prioritizing a certain manager’s requests, because he takes them out to lunch once a month.”

Oh, great. In addition to some engineers being bullied, I have other engineers who are like Corporal Max Klinger from M*A*S*H, running their own black market of IT work.

“If this is true, there’s no way we can lift the project freeze. Don’t you see that we don’t have any way of releasing work into IT and be able to trust that it will get worked on?”

Trying to keep the resignation out of my voice, I say, “Patty is right. We have a lot to figure out before the project freeze ends. Which is in exactly one week.”

I decide to take a quick walk outside. I have thirty minutes before my next meeting, and I need to think.

I’m more unsettled than ever. When we have more than one project in the system at the same time, how do we protect the work from being interrupted or having its priority trumped by almost anyone in the business or someone else in IT?

The sun shines down on me. It’s 11 a.m., and the air smells like autumn. The leaves on the trees are starting to turn orange and brown, and there are piles of them starting to form in the parking lot.

Despite my fretting, I realize how refreshing it is to be able to think about what work we need to be doing and how to prioritize and release it. For a moment, I marvel at the lack of constant firefighting that dominated so much of my career in IT.

The types of issues we’re having to solve lately are so…cerebral.

It’s what I thought management was all about when I got my MBA.

I’m convinced that if we do a good job thinking, we can make a real difference. In that moment, I decide to call Erik.

“Hello?” I hear him say.

“Hi, it’s Bill. Do you have a couple of minutes to talk? I have some questions about the project freeze.” I pause, and then add, “Or rather, what happens after we lift the project freeze.”

“Well, it’s about time. I was wondering when you’d figure out that you have a huge, new problem on your hands.”

I quickly fill him in on the good news from Kirsten. I outline the problems we’ve stumbled upon while we consider the monitoring project and how we protect work in the system.

“Not bad, junior!” Erik says. “You’ve obviously put our discussion about constraints into practice and are doing everything you can to protect that constraint from being hit by unplanned work. You’re asking some very important questions about the First Way and how you manage your flow of planned work. Until you can do that, you can’t really manage much of anything, can you?

“You’re confused because you’re realizing you don’t know how work is actually worked,” he continues.

I suppress an irritated sigh.

“I think it’s time for another trip to MRP-8. How soon can you get there?” he asks.

Surprised, I ask, “You’re in town?”

“Yep” he says. “There’s a meeting with the auditors and the finance guys this afternoon that I wouldn’t miss for the world. Make sure you’re there for it. We’re going to make John’s head fall off.”

I tell him that I can be at MRP-8 in fifteen minutes.

Erik’s in the middle of the lobby waiting for me.

I do a double take. He’s wearing a faded T-shirt and a zippered, hooded sweatshirt with a faded union logo. He already has a visitor badge and is tapping his foot impatiently.

“I came as fast as I could.” I say.

Erik merely grunts and gestures for me to follow him. Again, we climb the staircase and stand on the catwalk overlooking the plant floor.

“So tell me what you see,” he says, gesturing toward the plant floor.

I look down, confused, not knowing what he wants to hear. Starting with the obvious, I say, “Like last time, I see raw materials coming in from the loading docks on the left. And on the right, I see finished goods leaving the other set of loading docks.”

Surprisingly, Erik nods approvingly. “Good. And in between?”

I look down at the scene. Part of me feels foolish, afraid of looking like the Karate Kid being quizzed by Mr. Miyagi. But I asked for this meeting, so I just start talking. “I see materials and work in process, flowing from left to right—but, obviously, moving very slowly.”

Erik peers over the catwalk, and says, “Oh, really? Like some sort of river?”

He turns to me, shaking his head with disgust, “What do you think this is, some sort of poetry reading class? Suddenly, WIP is like water running over smooth stones? Get serious. How would a plant manager answer the question? From where to where does the work go, and why?”

Trying again, I say, “Okay, okay. WIP goes from work center to work center, as dictated by the bill of materials and routings. And all that is in the job order, which was released at that desk over there.”

“That’s better,” Erik says. “And can you find the work centers where the plant constraints are?”

I know that Erik had told me on that first odd trip to this plant.

“The heat treat ovens and paint curing booths,” I say suddenly.

“There,” I say, after scanning the plant floor and finally spotting a set of large machines by the far wall. “And there,” I say, pointing at the large rooms with signs saying, “Paint Booth #30-a” and “Paint Booth #30-b.”

“Good. Understanding the flow of work is key to achieving the First Way,” Erik says, nodding. More sternly, he asks, “So now, tell me again which work centers you’ve determined to be the constraints in your organization?”

I smile, answering easily, “Brent. We talked about that before.”

He scoffs, turning back to look at the plant floor.

“What?” I nearly shout. “How can it not be Brent? You even congratulated me when I told you it was Brent a couple of weeks ago!”

“Suddenly Brent is a robotic heat treat oven? You’re telling me your equivalent of that paint curing booth down there is Brent?” he says with mock disbelief. “You know, that might be the dumbest thing I’ve ever heard.”

He continues, “So, where would that leave your two managers, Chester and Penelope? Let me guess. Maybe they’re equivalent to that drill press station and that stamping machine over there? Or maybe it’s that metal grinder?”

Erik looks sternly at me, “Get serious. I asked you what work centers are your constraints. Think.”

Completely confused, I look back down at the plant floor.

I know that part of the answer is Brent. But when I blurt it out so confidently, Erik all but smacks me on the head. Again.

Erik seems aggravated that I named an actual person, suggesting that Brent was a piece of equipment.

I look again at the heat treat oven. And then I see them. There are two people wearing coveralls, hard hats, and goggles. One is in front of a computer screen, punching in something, while the other is inspecting a pile of parts on a loading pallet, scanning something with his handheld computer.

“Oh,” I say, thinking out loud. “The heat treat oven is a work center, which has workers associated with it. You asked what work centers are our constraints, and I told you that it was Brent, which can’t be right, because Brent isn’t a work center.

“Brent is a worker, not a work center,” I say again. “And I’m betting that Brent is probably a worker supporting way too many work centers. Which is why he’s a constraint.”

“Now we’re getting somewhere!” Erik says, smiling. Gesturing broadly at the plant floor below, he says, “Imagine if twenty-five percent of all the work centers down there could only be operated by one person named Brent. What would happen to the flow of work?”

I close my eyes to think.

“Work wouldn’t complete on time, because Brent can only be at one work center at a time,” I say. Enthusiastically, I continue, “That’s exactly what’s happening with us. I know that for a bunch of our planned changes, work can’t even start if Brent isn’t on hand. When that happens, we’ll escalate to Brent, telling him to drop whatever he’s doing, so some other work center can get going. We’ll be lucky if he can stay there long enough for the change to be completely implemented before he’s interrupted by someone else.”

“Exactly!” he says.

I’m slightly dismayed at the warm feeling of approval that I feel in response.

“Obviously,” he continues, “every work center is made up of four things: the machine, the man, the method, and the measures. Suppose for the machine, we select the heat treat oven. The men are the two people required to execute the predefined steps, and we obviously will need measures based on the outcomes of executing the steps in the method.”

I frown. These factory terms are vaguely familiar from my MBA years. But I never thought they’d be relevant in the IT domain.

Looking for some way to write this down, I realize I left my clipboard in my car. I pat my pockets and find a small crumpled index card in my back pocket.

I hurriedly write down, “Work center: machine, man, method, measure.”

Erik continues, “Of course, on this plant floor, you don’t have one quarter of the work centers dependent upon one person. That would be absurd. Unfortunately for you, you do. That’s why when Brent takes a vacation, all sorts of work will just grind to a halt, because only Brent knows how to complete certain steps—steps that probably only Brent even knew existed, right?”

I nod, unable to resist groaning. “You’re right. I’ve heard my managers complain that if Brent were hit by the proverbial bus, we’ d be completely up the creek. No one knows what’s in Brent’s head. Which is one of the reason I’ve created the level 3 escalation pool.”

I quickly explain what I did to prevent escalations to Brent during outages to keep him from being interrupted by unplanned work and how I’ve attempted to do the same thing for planned changes.

“Good,” he says. “You’re standardizing Brent’s work so that other people can execute it. And because you’re finally getting those steps documented, you’re able to enforce some level of consistency and quality, as well. You’re not only reducing the number of work centers where Brent is required, you’re generating documentation that will enable you to automate some of them.”

He continues, “Incidentally, until you do this, no matter how many more Brents you hire, Brent will always remain your constraint. Anyone you hire will just end up standing around.”

I nod in understanding. This is exactly as Wes described it. Even though he got the additional headcount to hire more Brents, we never were able to actually increase our throughput.

I feel a sudden sense of exhilaration as the pieces fall into place in my head. He’s confirming some of my deeply held intuitions and providing an underpinning theory for why I believe them.

My elation is short-lived. He looks me over disapprovingly, “You’re asking about how to lift the project freeze. Your problem is that you keep confusing two things. Until you can separate them in your head, you’ll just walk around in circles.”

He starts walking and I hurry after him. Soon, we’re standing over the middle of the plant floor.

“You see that work center over there, with the yellow blinking light?” he asks, pointing.

When I nod, he says, “Tell me what you see.”

Wondering what it would take to have a normal conversation with him, I resume my dumb trainee role. “Some piece of machinery is apparently down—that’s what I’m guessing the blinking light indicates. There are five people huddled off to the side, including what looks like two managers. They all look concerned. There are three more people crouched down, looking into what I’m guessing is the machine inspection panel. They have flashlights and—yeah—they’re also holding screwdrivers—definitely a machine down…”

“Good guess,” he says. “That’s probably a computerized grinder that is out of commission, and the maintenance team is working on getting it back online. What would happen if every piece of equipment down there needs Brent to fix it?”

I laugh. “Every outage escalated immediately to Brent.”

“Yes.” He continues, “Let’s start with your first question. Which projects are safe to release when the project freeze is lifted? Knowing how work flows through certain work centers and how some work centers require Brent and some do not, what do you think the answer is?”

I slowly repeat what Erik just recited, trying to piece together the answer

“I got it,” I say, smiling. “The candidate projects which are safe to release are those that don’t require Brent.”

I smile even wider when he says, “Bingo. Pretty simple, yes?”

My smile disappears as I think through the implications. “Wait, how do I know which projects don’t require Brent? We never think we actually need Brent until we’re halfway through the work!”

I immediately regret asking the question as Erik glares at me. “I’m supposed to give you the answer to everything that you’re too disorganized to be able to figure out for yourself?”

“Sorry. I’ll figure it out,” I say quickly. “You know, I’ll be so relieved when we finally know all the work that actually requires Brent.”

“Damn right,” he says. “What you’re building is the bill of materials for all the work that you do in IT Operations. But instead of a list of parts and subassemblies, like moldings, screws, and casters, you’re cataloging all the prerequisites of what you need before you can complete the work—like laptop model numbers, specifications of user information, the software and licenses needed, their configurations, version information, the security and capacity and continuity requirements, yada yada…”

He interrupts himself, saying, “Well, to be more accurate, you’re actually building a bill of resources. That’s the bill of materials along with the list of the required work centers and the routing. Once you have that, along with the work orders and your resources, you’ll finally be able to get a handle on what your capacity and demand is. This is what will enable you to finally know whether you can accept new work and then actually be able to schedule the work.”

Amazing. I think I almost get it.

I’m about ask some questions, but Erik says, “Your second question was whether it was safe to start your monitoring project. You already established it doesn’t require Brent. Furthermore, you say that the goal of this project is to prevent outages, which prevents Brent escalations. More than that, when outages do occur, you’ll need less of Brent’s time to troubleshoot and fix. You’ve already identified the constraint, exploited it to squeeze the most out of it, and then you’ve subordinated the flow of work to the constraint. So, how important is this monitoring project?”

I think for a moment. And then groan at the obvious answer.

I run my fingers through my hair. “You said that we always need to be looking for ways to elevate the constraint, which means I need to do whatever is required to get more cycles from Brent. That’s exactly what the monitoring project does!”

I say with some disbelief that I didn’t see this before, “The monitoring project is probably the most important improvement project we have—we need to start this project right away.”

“Precisely,” Erik says. “Properly elevating preventive work is at the heart of programs like Total Productive Maintenance, which has been embraced by the Lean Community. TPM insists that we do whatever it takes to assure machine availability by elevating maintenance. As one of my senseis would say, ‘Improving daily work is even more important than doing daily work.’ The Third Way is all about ensuring that we’re continually putting tension into the system, so that we’re continually reinforcing habits and improving something. Resilience engineering tells us that we should routinely inject faults into the system, doing them frequently, to make them less painful.

“Mike Rother says that it almost doesn’t matter what you improve, as long as you’re improving something. Why? Because if you are not improving, entropy guarantees that you are actually getting worse, which ensures that there is no path to zero errors, zero work-related accidents, and zero loss.”

Suddenly, it’s so obvious and evident. I feel like I need to call Patty right away to tell her to start the monitoring project immediately.

Erik continues, “Rother calls this the Improvement Kata,” he continues. “He used the word kata, because he understood that repetition creates habits, and habits are what enable mastery. Whether you’re talking about sports training, learning a musical instrument, or training in the Special Forces, nothing is more to mastery than practice and drills. Studies have shown that practicing five minutes daily is better than practicing once a week for three hours. And if you want to create a genuine culture of improvement, you must create those habits.”

Turning back to the plant floor, he continues, “Before we leave, turn your attention from the work centers to all the space between the work centers. Just as important as throttling the release of work is managing the handoffs. The wait time for a given resource is the percentage that resource is busy, divided by the percentage that resource is idle. So, if a resource is fifty percent utilized, the wait time is 50/50, or 1 unit. If the resource is ninety percent utilized, the wait time is 90/10, or nine times longer. And if the resource is ninety-nine percent utilized?”

Although I’m not quite understanding the relevance, I do the math in my head: 99/1. I say, “Ninety-nine.”

“Correct,” he says. “When a resource is ninety-nine percent utilized, you have to wait ninety-nine times as long as if that resource is fifty percent utilized.”

He gestures expansively, “A critical part of the Second Way is making wait times visible, so you know when your work spends days sitting in someone’s queue—or worse, when work has to go backward, because it doesn’t have all the parts or requires rework.

“Remember that our goal is to maximize flow. Here at MRP-8, we had a situation many years ago where certain components were never showing up at final assembly on time. Was it because we didn’t have enough resources or because certain tasks were taking too long?

“No! When we actually followed the parts around on the plant floor, we found that for the majority of time, the parts were just sitting in queues. In other words, the ‘touch time’ was a tiny fraction of ‘total process time.’ Our expediters had to search through mountains of work to find the parts and push them through the work center,” he says incredulously.

“That’s happening at your plant, too, so watch for it,” he says.

I nod and say, “Erik, I’m still stuck on releasing the monitoring project. People always insist that their special project is urgent, and needs to be worked at the expense of everything else. Where do all the urgent audit and security remediation projects that John is screaming for fit in?”

Erik looks intently at my face and finally says, “Have you heard a single word I’ve been saying in the last two weeks?”

He looks at his watch and says, “Gotta go.”

Startled, I watch him as he walks quickly to the catwalk exit. I have to run to catch him. He’s a big guy, probably a little over fifty years old. Despite the extra pounds he’s carrying, he moves fast.

When I catch up to him, I say, “Wait. Are you saying that audit issues aren’t important enough to fix?”

“I never said that,” he says, stopping in his tracks and turning to face me. “You screw up something that jeopardizes the business’ ability to maintain compliance with relevant laws and regulations? You better fix it—or you should be fired.”

He turns around and resumes his pace, saying over his shoulder, “Tell me. All those projects that Jimmy your CISO is pushing. Do they increase the flow of project work through the IT organization?”

“No,” I quickly answer, rushing to catch up again.

“Do they increase operational stability or decrease the time required to detect and recover from outages or security breaches?”

I think a bit longer. “Probably not. A lot of it is just more busywork, and in most cases, the work they’re asking for is risky and actually could cause outages.”

“Do these projects increase Brent’s capacity?”

I laugh humorlessly. “No, the opposite. The audit issues alone could tie up Brent for the next year.”

“And what would doing all of Jimmy’s projects do to WIP levels?” he asks, opening the door that takes us back into the stairwell.

Exasperated, I say as we descend the two sets of stairs, “It would go through the roof. Again.”

When we reach the bottom, Erik suddenly stops and asks, “Okay. These ‘security’ projects decrease your project throughput, which is the constraint for the entire business. And swamp the most constrained resource in your organization. And they don’t do squat for scalability, availability, survivability, sustainability, security, supportability, or the defensibility of the organization.”

He asks deadpan, “So, genius: Do Jimmy’s projects sound like a good use of time to you?”

As I start to answer, he just opens the exit door and walks through it. Apparently, it was a rhetorical question.