Thursday, September 11 - 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 11

• Thursday, September 11

Later that day during lunch, I curse loudly. I was trying to use my precious few unscheduled minutes during my break to get caught up on e-mails but forgot that my crappy laptop crashes if I turn it on while it’s in the docking station. It’s the third time I’ve done it this week.

I’m already eating late and half my lunch break will be gone by the time I can log on.

Looking around, I find a blank Post-it note on my desk and write in large letters, “DO NOT INSERT LAPTOP UNTIL POWERED ON!!!” and put it on the docking station to avert my next act of time-wasting stupidity.

I’m smiling at my countermeasure when Patty calls me on my cell phone. “You have a minute to talk? I’m seeing something very odd on the change calendar. You need to see this.”

When I walk into the conference room, I see the now familiar change cards hanging on the wall. The inbox basket is full of cards and more are neatly stacked in piles on the table. Patty is scrutinizing something on her laptop, chewing a fingernail.

Looking exhausted, she says, “I’m starting to think this entire change process is a total waste of time. Organizing all these changes and managing all the stakeholder communication is taking up three people full-time. Based on what I’m seeing now, it may be useless.”

To see her suddenly disparaging the processes she has championed for years is genuinely alarming.

“Whoa,” I say, waving both my hands in front of her. “Catch me up, because I think you’ve done a fantastic job, and I don’t want us to go back to the old ways. What has you so concerned?”

She points to the Monday and Tuesday change boxes. “At the end of each day, my people start closing out the scheduled changes. We wanted to make sure that any changes that weren’t completed were flagged so they can be rescheduled and to make sure that our change calendar was tracking what was happening in reality.”

She points to the corner of one card. “We put a check on the change cards that have been verified as completed and then indicate whether it caused a service incident or outage. Since last Friday, sixty percent of the scheduled changes didn’t get implemented! Which means we’re doing all this work to authorize and schedule these changes, only to find that they’re not even getting done!”

I can see why Patty is alarmed.

“Why aren’t they being completed? And what do you do with the incomplete change cards?” I ask.

She scratches her head. “I’ve called a bunch of the change requesters, and their reasons are all over the board. A couple people said that they couldn’t get all the people they needed to start their change. Someone else discovered halfway through his change that the storage guys didn’t finish expanding the SAN like they had promised, so he had to back out his change, two hours into the procedure.”

I groan, thinking about the wasted time and effort. I keep listening as Patty continues, “Someone else said that she couldn’t implement her change because there was an outage in progress. And a bunch of other people said, um…”

She looks uncomfortable, so I prompt her to continue. “Well, they said they needed Brent for a portion of their changes, and he wasn’t available,” she says reluctantly. “In some cases, Brent’s involvement was planned. But in other cases, they discovered they needed his help only after they started implementing and had to abort when Brent wasn’t available.”

Before Patty is even finished speaking, I’m seeing red.

What? Brent again? What is going on? Just how has Brent managed to wedge himself into everyone’s path?

“Oh, shit!” I exclaim when it hits me what’s happening. “Did we create this problem by focusing Brent solely on Phoenix? Is this new policy a mistake?”

She says after a moment, “You know, that’s an interesting question. If you genuinely believe that Brent should only be working on the most important projects, then I think the new policy is correct, and we shouldn’t change it back.

“I think it’s also important to note that until recently, Brent was helping people implement their changes, without that dependency recorded anywhere. Or rather, he’d try to. But he’d invariably be too busy to help everyone, so many of these changes wouldn’t have been completed, even in the old way.”

I pick up my phone and speed-dial Wes, telling him to join us.

When he arrives a couple of moments later, he takes a seat and then looks at my old laptop, saying, “Jeez. You still carrying that thing around? I’m sure we have a couple of newer eight-year-old laptops that you could use.”

Ignoring his comment, Patty quickly brings him up to speed. His reaction to her revelation isn’t much different than mine.

“You’ve got to be kidding me!” he says angrily, slapping his palm on his forehead. “Maybe we should allow Brent to help people make changes?”

I quickly say, “No, that can’t be the answer. I suggested that, too. But Patty pointed out that this would imply that the blocked changes are more important than Phoenix. Which they aren’t.”

I think aloud, “Somehow, just like we’re breaking the habits of people asking Brent to help with break-fix work, we need to do the same with change implementation. We’ve got to get all this knowledge into the hands of people actually doing the work. If they can’t grok it, then maybe we have a skills problem in those teams.”

When no one says anything, I tentatively add, “How about we take those same level 3 engineers that are dedicated to protect Brent from break-fix to help with these change issues?”

Wes quickly responds, “Maybe. But it’s not a long-term fix. We need the people doing the work to know what the hell they’re doing, not enable more people to hoard knowledge.”

I listen to Wes and Patty brainstorm ideas to reduce yet another dependency on Brent when something starts to bother me. Erik called WIP, or work in process, the “silent killer,” and that inability to control WIP on the plant floor was one of the root causes for chronic due-date problems and quality issues.

We just discovered that sixty percent of our changes didn’t complete as scheduled.

Erik had pointed to the ever-growing mountain of work on the plant floor as an indication that the plant floor managers had failed to control their work in process.

I look at the mountain of change cards piled up on today’s date on the calendar, as if a giant snowplow had pushed them all forward. Suddenly, it’s starting to seem like the picture Erik painted on the plant floor eerily describes the state of my organization.

Can IT work really be compared to work on a plant floor?

Patty interrupts my deep contemplation as she asks, “What do you think?”

I look back up at her. “For the last couple of days, only forty percent of the scheduled changes were completed. The rest are being carried forward. Let’s assume that this continues for a bit longer, while we figure out how to disseminate all the Brent knowledge.

“We have 240 incomplete changes this week. If we have four hundred new changes coming in next week, we’ll have 640 changes on the schedule next week!

“We’re like the Bates Motel of changes,” I say in disbelief. “Changes go in but never come out. Within a month, we’ll have thousands of changes that we’ll be carrying around, all competing to get implemented.”

Patty nods, “That’s exactly what’s bothering me. We don’t have to wait a month to see thousands of changes—we’re already tracking 942 changes. We’ll cross over one thousand pending changes sometime next week. We’re running short of space to post and store these change cards. So why are we going through all this trouble if the changes aren’t even going to get implemented!”

I stare at all the cards, willing them into giving me an answer.

An ever-growing pile of inventory trapped on the plant floor, as high as the forklifts could stack it.

An ever-growing pile of changes trapped inside of IT Operations, with us running out of space to post the change cards.

Work piling up in front of the heat treat oven, because of Mark sitting at the job release desk releasing work.

Work piling up in front of Brent, because of…

Because of what?

Okay, if Brent is our heat treat oven, then who is our Mark? Who authorized all this work to be put in the system?

Well, we did. Or rather, the CAB did.

Crap. Does that mean we did this to ourselves?

But changes need to get done, right? That’s why they’re changes. Besides, how do you say no to the onslaught of incoming work?

Looking at the cards piling up, can we afford not to?

But when was the question ever asked whether we should accept the work? And on what basis did we ever make that decision?

Again, I don’t know the answer. But, worse, I have a feeling that Erik may not be a raving madman. Maybe he’s right. Maybe there is some sort of link between plant floor management and IT Operations. Maybe plant floor management and IT Operations actually have similar challenges and problems.

I stand up and walk to the change board. I start thinking aloud, “Patty is alarmed that more than half our changes aren’t completing as scheduled, to the extent that she’s wondering whether this whole change process is worth the time we’re investing in it.

“Furthermore,” I continue, “she points out that a significant portion of the changes can’t complete because Brent is somehow in the way, which is partially because we’ve directed Brent to reject all non-Phoenix work. We think that reversing this policy is the wrong thing to do.”

I take a mental leap, following my intuition. “And I’d bet a million dollars that this is the exact wrong thing to do. It’s because of this process that, for the first time, we’re even aware of how much scheduled work isn’t getting done! Getting rid of the process would just kill our situational awareness.”

Feeling like I’m getting on a roll, I say adamantly, “Patty, we need a better understanding of what work is going to be heading Brent’s way. We need to know which change cards involve Brent—maybe we even make that another piece of information required when people submit their cards. Or use a different color card—you figure it out. You need to inventory what changes need anything from Brent, and try to satisfy it instead with the level 3 engineers. Failing that, try to get them prioritized so we can triage them with Brent.”

As I’m talking, I’m more confident that we’re heading down the right path. At this point, we might not be fixing the problem, but at least we’ll be getting some data.

Patty nods, her expression of concern and despair now gone. “You want me to get my arms around the changes that are heading to Brent, indicating them on the change cards and maybe even requiring this information on all new cards. And to get back to you when we know how many changes are Brent-bound, what the changes are, and so forth, along with a sense of what the priorities are. Did I get that right?”

I nod and smile.

She types away on her laptop. “Okay, I’ve got it. I’m not sure what we’ll find out, but it’s better than anything I came up with by a long shot.”

I look over at Wes, “You look concerned—anything you want to share?”

“Uh…” Wes says eventually. “There’s not much to share, really. Except that this is a very different way of working than anything I’ve seen in IT. No offense, but did you switch medication recently?”

I smile wanly, “No, but I did have a conversation with a raving madman on a catwalk overlooking the manufacturing plant floor.”

But if Erik was right about WIP in IT Operations, what else was he right about?