MM: Brilliant! So then, that gave you an optimized workflow that you could visually depict—probably using pretty standard workflow diagrams. Right?

TM: Yes. Sometimes there would be a written step. Sometimes it would be a screenshot with the new data. Sometimes it would be a screenshot of a directory.

MM: So these are basically the artifacts that went into the user manuals.

TM: Correct. That’s exactly what they were. Yes.

MM: So now in the course of then developing this optimized workflow—creating it one screenshot at a time.

TM: Yes.

MM: In the course of developing these screenshots, you had the operator—the intended operator—come in and interact with you and ultimately say, “Yes. That’s what I want my screen to look like.”

TM: Partly. Remember that we really hadn’t chosen the vendor, yet at that point. There were basically mockups that were just done in Excel that showed a basic idea of what it would look like from a data standpoint. But not what it would look like visually in the application.

MM: Perfect! So you developed the wire frame or the exposed data model for that particular screen or activity?

TM: Yes.

MM: Then, how long did it take you to develop that idealized workflow model?

TM: I was trying to think about that—how we broke that down. It was nine months for the total. My guess is that it was like six months for the current workflow and three months for the optimized.

MM: The next thing I’d like you to talk to is the optimized workflow.

With these basic principles of accountability and no enabling bad behavior or sloppy work. Staying online. Getting it right upfront.

With that set of principles, your current-state process, as I recall from our conversation—entailed about 300 or so discrete steps. Is that right?

TM: That is correct. 300 individual steps.

MM: Then how did you start to develop the optimized future-state capability?

TM: Well, as you mentioned—the visual representation on the wall. We kind of created, after we had all of the artifacts out there, we either took pictures or put them into a document. We reduced them so that they could fit on half of that wall. Then we drew a line under that.

The top of the wall was the current. The “current,” being with a few modifications that we felt we could implement right away. Then we drew a line.

On the bottom, we started the new process. “What do we do now? What is the process that we should lead with? Look. You’re doing this on the backend, and we know that there’s pain back there. We want to move this up into the process.”

Subject Indexes in Two Hours vs 30 person-weeks

MM: So for example, there were two things that I want you to address. First, how your team builds the subject index in the back of the catalog and, second, how your ream conducted profit analysis of each page in the catalog.

Let’s talk about the index, first of all. In a 900-page catalog, creating an index can be quite the chore. It typically happens at the end of the production cycle.

So there was like a two-week period at the very end of the production cycle, where 15 to 20 people sequestered themselves into a room and basically called out names and told what page number those particular items were on. That’s now the index was built.

Again, you’re talking 10 to 15 people for 8 hours a day, for 2 weeks. That’s a lot of man-hours.

MM: Yes. That’s 30 man-weeks.

TM: It had to be done. So we recognized with database publishing how electronically that information is captured within the database, and—through a simple export—that same result can be more accurately and quickly exported within a matter of 2 hours.

But more importantly, we reduced the cycle time by two weeks.

MM: So when you looked at this visual depiction and then started to create an interim optimized workflow—at what point did you start applying activity-based costing to the workflow?

TM: Actually, the activity-based costing came after that. I’ll tell you why. It came when there was recognition of how much indeed the new process was going to be able to change the workflow.

MM: So let’s use this as an opportunity to shift into the optimized workflow.

TM: Sure.

MM: Over the course of nine months in this War Room, you developed a visual end-to-end depiction of the messy current-state operation.

TM: Yes.

MM: Out of this precipitated a number of interim changes that you could make, because they were easy, self-evident, and everyone said, “Let’s do it.”

TM: Yes.

MM: Then you developed a new workflow. An optimized workflow embracing some core principles—one of which you identified as, “Right upfront.” And enter data once and only once.

TM: Yes. Enter once, publish many times.

Getting the Right Job Done

MM: Yes. And “stay online.” So, as much as possible, keep the work online as opposed to going offline in an analogue or physical work activity. Is that right?

TM: Yes. Although I think you might cover accountability and enabling within the “right upfront,” the enabling thing was kind of a sticky point, there. It was important for people to do what we called, “Staying out of somebody else’s backyard.”

You can’t do their job for them. If they’re going to fail, they’re going to fail.

MM: So it’s kind of, “You’re accountable for your work, and you’re not your brother’s keeper.” Or—what’s the psychological term? “Enabler.” What do they call that when you enable somebody else’s addiction or bad behavior?”

TM: We call them “enablers.”

MM: Enablers. Okay. So, “Stand on your own two feet and get your job done,” is another core principle.

TM: Right. That doesn’t mean you can’t be helpful. But you can’t do somebody else’s job for them.

MM: Perfect. So that was your principle around enabling. No more enabling bad behavior or enabling shoddy work.

TM: Yes.

MM: You’re accountable for producing high-quality work now in this increasingly transparent self-evidently accountable workflow process.

TM: Right. Because people recognize that if nobody else is doing this…

MM: It ain’t gonna get done.

TM: Right. You can’t hide any more.

MM: So this has actually two dimensions to it. You just described the downside of it. That is fear of recrimination and ridicule and maybe some lost jobs.

But the upside of it is, I am now an acknowledged contributor. I’m needed. I make a difference. I contribute here in a very direct and now transparent and accountable way.

TM: Yes. We are dependent on you.

MM: Yes. And we are inter-dependent—that sense of being part of a team in and of itself provides a sustainable motivation for getting it right upfront.

TM: Yes.

MM: Having repeated the process elsewhere with my clients, I am sure that your Hubert colleagues were aghast about how the big mess on their hands. That was the first thing. Right?

TM: Yes. They couldn’t believe it.

MM: That then gave rise to a collective rocket of desire to make it better—whatever that was going to be. And supporting that desire, you had this visual, persistent object on the wall demonstrating in black-and-white or full-color factual details of the big mess. Argument over. We’ve got mess. And that led to more meaningful, cogent, and effective conversations with all the stakeholders about how to facilitate the change.

TM: Correct.

MM: I love it. In essence your physical wall-mounted map began to future-proof a change without actually having to make the change. It got everyone thinking about how to make a holistic change instead of a tactical change to one piece that might result in unintended consequences elsewhere in the business or, worse, among customers.

TM: Correct. Now, we took some interim steps. First, when we saw all the errors of in the current process, we took action on those things that did not require automation or a new system. We just said, “Okay. We’ve identified it. Let’s change these.”

MM: So you identified where in the process a change should optimally occur. For example, who in the process would now be accountable for data entry, and the quality assurance for what got entered.

TM: Yes.

Drucker’s Theory of Knowledge Work Productivity

MM: As a general principle, this validate Peter Drucker’s notion of Knowledge Worker Productivity. He defined it as, “How quickly can I ask for information from another person?” And/or, “How quickly can I provide information to another person,” with a specified time, place and format?

So, your work demonstrates another principle of innovation leadership: you optimize the productivity of individuals in the workflow by—first of all—identifying my upstream (value chain) providers of information, and my downstream recipients of good, high-quality information for which I am responsible.

TM: Yes.

MM: So, as you begin to understand who contributes what, this produced many conversations or arguments about specific deliverables, hand-offs, and who is responsible for what—and what continues to drives the Internet revolution: transaction costs or the costs of communicating or delivering a unit of work to your downstream “customers”.

TM: One of our biggest discoveries was the level distrust. That was probably the largest obstacle we had. For so long, people had dealt with other peoples’ mistakes that they didn’t trust the other people to get things done right upfront.

Going back to the accountability issue, when the process was optimized, it was drilled into the people that—”If this is your only chance to do this, then you have to do it right. Because nobody’s going to be checking your work any longer.”

That’s where we came into some obstacles. Because people would say, “No. I have to see that again. I don’t trust that these people are going to do their jobs correctly.”

MM: Your work validates one of the emerging principles of an innovation culture or an ingenuity culture: you must have in place a change-management process that you invoke whenever you need to accommodate an innovation.

TM: Yes. That would be an excellent model for any company.

MM: I believe that a lot of people consider innovation as a top-down thing. Yet, the real innovators with whom I have interviewed consider innovation as bottom-up activity, from the actual users – the stakeholders in the workflow. The reason? Because the actual users are the one’s closest to what actually has to get done, and, specifically, the nature and likely root causes of the pain.

TM: That’s absolutely true. However, upper management—even though it’s not their idea—must actively support an innovation or change for it to happen.

MM: However, most change processes run into trouble when it simply becomes a top-down mandate, as opposed to a bottom-up collaboration and discovery of, “What’s the best way of doing this one piece?” Effective change processes maintain the context of business priorities and individual needs.

TM: Absolutely.

Value Chain Analysis

MM: You also did something else at Hubert that I consider most extraordinary: you had developed this end-to-end visual depiction of the entire catalog development and publishing process—in part, what Michael Porter of Harvard Business School calls value chain analysis. In your telling me of this, you tied together several principles that others could apply in achieving similar results. Let’s start with, “Get it right upfront.”

TM: Yes. That was a theme that became our mantra.

It means making sure that you do things right the first time, and therefore you don’t have to worry about it later. That lives in several different areas. It can live as a whole—meaning if we hadn’t done the research and the white paper and all that stuff upfront, would we’ve been as successful.

But you can take it down to the minutia, too. That is, we identified during the current process that there was a maximum of 7 times where a price could be entered into the system. Now, that 7 times didn’t happen all the time—but it wasn’t unusual for a price to be entered at least 4 times into the system at some point.

MM: That means manual data entry of a pricing data 4 or 5 times against 50,000 SKUs?

TM: More than that. Yes.

So if you think about the opportunity for error there, and we’re talking about entering where it could be somebody writing it down on a sheet of paper. That’s “entry.” Right? Or putting it into a spreadsheet and not into a database. That’s entry. Putting it into one database and then another database. That’s two entries.

That’s what I’m talking about—how that is looked at. The idea was, “Let’s find the point where it should be entered—the right point—upfront. Let’s find out where it should be entered, who’s responsible for that entry, and—when you enter it—make sure you do it right.”

MM: Let me unpack it a little bit. First, you had this wonderful, messy, warts-and-all visual depiction of the entire end-to-end process—to which all the involved parties contributed. Then, you got everyone to physically signed off on the visual depiction. In effect, your got everyone to, “Yes. That’s my contract with reality.”

TM: Yes.

MM: Just in that process of getting them to put their signatures to the visual end-to-end process map, you dissolved all or most resistance to change.

TM: Right. When we came out of that, everybody in that room was eager for the next step. Not afraid.

MM: As you had developed the organizational strategy for how Hubert might benefit from database publishing, one of the major efforts that you undertook entailed developing an internal white paper. The preparation of the paper allowed you to put into cogent, logical order, an organizational change—an organizational transformation story.

As you began to circulate the white paper, it served as a persistent messaging object—a framework—for structuring and guiding internal conversations around how affected stakeholders could come up-to-speed with the new system.

TM: Absolutely.

MM: As I recall for our previous conversations, your process of bringing stakeholders up-to-speed revealed new adoption criteria and business requirements that subsequently you wove back into the next version of the white paper. So the white paper was a living document that continued not only the conversation, but also the coalescence of, “Yes. This makes sense for us a firm.”

With internal consensus, you built a nice platform by which to start engaging vendors in terms of what you need from them. I find absolutely fascinating. As I recall in ’98 or ’99—when all of this took place—your were in a lot conversations such as, “Maybe we ought to get a DAM.” But you came back with, “Let’s figure out exactly how we produce our big-book 900-page catalog, and understand if there are any other inefficiencies we should work out before we actually start looking at DAMs.” Would you take us through that process?

TM: Absolutely. That was the fun part, really.

What was intriguing was that it was apparent that all of the people involved in producing the catalog had probably never been in the same room at the same time, before. Therefore, there were lots of big revelations once we sat down together.

We got 15 stakeholders in a meeting—people from groups that touched the catalog to people who participated in the production of the catalog—everyone from merchandisers to graphic artists to IT people. Also, we had some fairly significant shareholders, like a VP of Marketing who was there for many of the meetings.

Basically we had 15 people that met twice a week for half a day over a 9-month period, Initially we defined the workflow that was currently in place. The direction of the meeting was very specific. We were not there to change anything at that point. We were only there to identify and to bring artifacts. To make sure that everyone understood exactly what was being done now. We met in what we called the ‘War Room.’ It was a fairly big conference room that had windows—over half of it that we actually covered up at one point, because we simply needed more room to put stuff on the walls.

Workflow Model in the War Room

MM: As I recall, you physically mocked up each step of the workflow associated with publishing a 1,000-page big-book catalog and a website. Is that right?

TM: Yes. Absolutely.

MM: If someone had the printouts from your mainframe—then you physically tacked a piece of green bar up on the wall which somebody then transcribed that into a spreadsheet.

TM: And if an artifact like that didn’t work well, then we took a picture of it. Remember when you were moving paper around, a lot of times it was, “Put something in a bin,” or, “Take it to this location.” If we felt it couldn’t be described very well, we’d take a picture of it and put the picture up on the wall, too.

MM: If “sneakerware” was involved, where someone had to physically move a file from one person to another, you had photographs of the individuals and a string connecting the two individuals?

TM: We had yarn. We had different types of colored tape that we would use. We had different colored starbursts that meant different things. We identified pain points, as well, during this process. And, a big red star meant, ‘Here’s an issue.’—a real Pain Point.

MM: How did you call out defects or mistakes?

TM: In much the same way: remember, we were not trying to solve any problems, yet. We were only identifying them.

MM: I can’t overstate the importance of what you just said. Many people make the mistake of going in to an organization with a change mindset: “Here’s how we’re going to change this. Here’s how we’re going to change that.” That naturally produces all kinds of pushback and resistance among stakeholders.

TM: And resentment.