Lesson Learned #40
Understanding true workload is one of the most common deficiencies we see in companies and organizations across industries.
It's very hard for people to assess their own workload, perhaps particularly for people with strong mathematics backgrounds, such as engineers and accountants. A key point is that "true workload" is not a picture of how many hours you actually put in at work; it's how many hours are actually required. We once tried asking some software engineers to assess their own workload. Without exception they came back with an answer of exactly 40 hours of work per week. The problem is that "true workload" is not a picture of how many hours you physically put in at work: it's how many hours are actually required. No one works at 100%. Everyone has operating problems of some kind or another (missing information, rework, etc). World-class productivity is generally considered to be about 85%, which means in a 40- hour workweek you have about 34 hours of work. And that's "world class." Many people work at productivity levels closer to 60% which means their true workload would be only about 24 hours. It's understandably hard for people to assess their own workload and come up with only 24 hours in a 40- hour week.
The reason, of course, is that people see workload analysis as an indictment of their work ethic. While understandable, this simply isn't true. People can work very hard and still be only about 60% productive. But if you are genuinely trying to improve the performance of a function, it's virtually impossible to do so without some kind of assessment of the work that needs to be done in order to achieve certain outcomes. If you intentionally, or unintentionally, inflate the current workload, all you’re really doing is hiding operating problems – exactly the things you are trying to uncover and eliminate.
One of the ways we've learned to assess workload is to depersonalize the analysis. You aren't actually interested in an individual's workload; you're interested in the work requirements of an entire process. Also, sometimes understanding workload is less important than understanding the effectiveness of the process. For example, you could increase the productivity of a salesperson by requiring them to go to more meetings, but it wouldn't be useful if the meetings were with the wrong type of company.
No one likes their workload being assessed, but to improve performance it is, unfortunately, a critical step.
Lesson Learned #39
We were invited to make a presentation at an industry conference. We arrived in advance and checked in. Then, we were instructed to see the host, who would be introducing us onstage. After a quick hello he started to complain bitterly about how the previous speaker had forced him to read and reread, his introduction before going onstage. He said to us, "Hey, I can appreciate professionalism, but it's not like I can't read." We commiserated, joked a little with him and handed him our own introduction.
An hour or so later we got up in front of the audience, and as the room settled he introduced us. He mispronounced our speaker's last name and massacred the company name. Our partner could live with the personal slight, but the mispronunciation of the company name was surprisingly unbalancing and gave the presentation a slightly amateurish feel. It also did little to build the brand, which was one of the key objectives of doing the presentation in the first place.
The obvious lesson we learned was: Don't overlook the introduction when you are doing a speech or presentation. It sets the stage for both the audience and the speakers. Better to have the host complain about you, rather than the audience.
Lesson Learned #38
We were working in the food and beverage area at a beautiful Ritz-Carlton resort. It was an important meeting: we were presenting method changes that had been developed with the help of the leaders of the stewarding and banquet areas. A number of the changes involved the movement of food to and from the kitchens, so the head chef was invited to the meeting. That was a good idea. Unfortunately, none of the method changes that had been presented to the chef in advance. That was a bad idea.
As is fairly common when someone is presented with a new way of doing things, the chef objected to most of the method changes that were presented, at least as far as they concerned the kitchens. The objections weren't overly critical, and many in fact had been already recognized and dealt with along the way. But objections are road blocks unless they are properly and effectively handled. They derailed the flow of the meeting, and with each objection the general manager became more uneasy with the level of buy-in of his management team. A herd mentality started to develop Suddenly objections led to more objections, which led to more discomfort around the room. The positive buy-in from the stewarding and banquets management started to dissipate.Three-quarters through the allotted meeting time, and less than hal way through the agenda, the GM politely asked us to do more work on selling the method changes and rescheduled the meeting for a later date.
This lesson learned here is similar to one of our company maxims ("Pre-present, pre-present, pre-present"). For any important meeting, the participants should be familiar with the material and not be presented with "new" ideas. This may seem a little odd, but it is in fact critical for managing change. By pre-presenting the information, you can handle objections on a one-to-one basis and either reach a resolution or modify the method change accordingly. Surprising people, even if the changes are relatively innocuous, is never effective.
Lesson Learned #37
One of our senior partners once had a sales meeting with an executive for a company headquartered in London, England. The executive had a beautiful office with a stunning view of Trafalgar Square. He ushered our partner into his office and asked him to grab a seat while he got some coffee for the two of them. The office had modern furnishings – a stark contrast to the historic building it was housed in. The desk was a simple glass table with a chair on either side. Our partner sat down and took the opportunity to absorb the magnificent view of the busy square.
The executive returned with the coffee. Our partner said, "I've been in many interesting offices, but this may be the best view I've ever seen."
The exec placed the coffee down on the table and replied, "Thanks. Now get out of my chair."
Like the part in a movie where the plot twist is revealed, all the missed clues suddenly became painfully apparent (particularly the placement of a note pad and family photograph). Our partner had made the simple assumption that the exec would have his back to the window. Precisely because of the view, this exec had chosen to face the window. The awkwardness that followed as the partner collected his things and moved to the other side of the desk probably wasn't the only reason the rest of the meeting went poorly, but it did register as one more lesson learned.
Lesson Learned #36
We were working for a company that made aircraft landing gear (actually the company legacy included making landing gear for Apollo space missions). One of our consultants was working in a part-finishing area and determined that quite a few of the area flow problems had to do with the way the equipment was laid out. The workers agreed with him but had not really considered it as an option, due to the perceived expense of moving heavy equipment around. We did the cost/benefit analysis and then discussed it with the general manager. He loved the idea.
Our consultant drew up new floor plans and created colorful flow diagrams and charts showing how the flow of material would improve. We presented them to the GM. He loved them too. But then he dealt our momentum a crushing (but in hindsight necessary) blow. He said, "Did the workers have any input into these plans?" We told him that they agreed with the original findings and we had reviewed the new design with the area supervisor. He pressed us on whether or not the actual workers had any input. Somewhat sheepishly we admitted that we had not asked for their input into the revised flow plan, because they were unionized workers and we weren't sure it would be appropriate for us to involve them. He said, "It’s possible that it isn't appropriate for you, but it's vital for us. Some of these guys have worked here for over 20 years. They know more about the flow of work than any of us and, most importantly, they play a critical role in our achieving any gains from the improved flow. If it was your work area, wouldn't you want to feel like you had some input into how it was rearranged?"
So we went back to the area supervisor and, working through him, involved the local workers in the new plan. They did come up with a better design and they were very appreciative of the involvement. We were appreciative of their insight.
Lesson Learned #35
When Six Sigma arrived on the management scene many years ago, it caused quite a lot of confusion for both us and our prospective clients. How is Carpedia different from Six Sigma?
One insightful client explained it to us in a way that eventually helped us improve our own methodology. He said, "You keep trying to define yourselves as an alternative to Six Sigma, but you're thinking about it wrong. Six Sigma provides a problem-solving methodology that you guys conveniently ignore. You have a good approach for giving managers tools to figure out what resources they need and then to schedule them appropriately. But what about when they don't meet their schedule? What does a manager do with a ‘variance’? It’s fine when you have a bunch of consultants running around with nothing to do but problem-solve, but what about when they leave? I need my managers to know how to fix problems."
It was an interesting observation, even if it was critical of our approach. Over the years we have learned that a key to sustaining results and continuous improvement is to have managers who are good at problem-solving. Well-designed management systems provide targets and identify variances, but other than that they are inert. Managers have to register the variance and then physically do something about it if anything is to change. Companies have long had variations of quality-based problem-solving methodology, but Six Sigma re-energized the approach with some useful analytical tools. So we shamelessly adopted what we thought were the best ideas and tools from Six Sigma, as we have from Lean, the theory of constraints, and various other thoughtful methodologies. The one caveat we would suggest is that often it’s not that managers lack tools or methods to problem-solve, it's that they lack time or necessity.
Lesson Learned #34
Several years ago we worked in a factory that produced cookies and crackers, along with various other sweet and salty treats. Production scrap was sold off to local farmers and used as pig feed. The good news was that the scrap was generating a little revenue and being used for a productive purpose, and the plant was kept very clean. The bad news was the plant produced too much scrap.
The problem was that the scrap issue was cloaked by the cleanliness and didn't appear to be a cause for concern. We had seen the same thing at a heavy-equipment manufacturer (floors were spotless) and at a high-tech french-fry processing plant (sanitation was so efficient it was costing them a small fortune).
At the cookie plant, we attempted to quantify the cost of the waste and determined it was a bigger issue than it seemed. The efficiency of the clean-up program had all but eliminated visual clues, which ironically had reduced the waste problem to a non-issue. That was until the decision was made to allow the bins and scrap piles to build up. The speed at which the scrap cluttered the respective work areas quickly signalled to everybody that this was a bigger issue than anyone realized. Now that the issue had people's attention, the problem-solving and resulting improvement could follow.
This lesson learned runs somewhat counter to one of our maxims (Fix "Broken Windows") and to some of the popular "5S" philosophy, both of which are more in line with cleaning up waste immediately. The true underlying problem may have been that the magnitude and cost of the waste hadn't been properly measured and communicated to management. Waste is never that simple to quantify, because the cost basis shifts as products flow through the process and value is added along the way (this is also true with data processing). In any case, the clean environment led to a general lack of awareness. What we've learned is that sometimes there is a lot of power in letting people visually determine for themselves that there is a problem, rather than trying to convince them with spreadsheets and charts.
Hopefully the pigs found something else to eat. (Editor's note: A couple of years later, we were working at a facility situated very near to the cookie plant. We were thrilled to see the pigs seemed as portly as ever).
Lesson Learned #33
Here's an example of what should be a "lesson learned" but can actually turn into a terrible habit: a client is talking to you. When she’s in the middle of asking a question, you cut her off and give an answer to what you think she was asking. In our business, there are few things more disquieting than cutting off your client mid-question and then seeing her look at you in disbelief as you rattle off the wrong answer.
So why do some of us do this? This seems to be a problem more for people who like to "tell" as opposed to people who like to "ask" (different social styles). For those of us in the former camp, one explanation is that we're upended by our experience and the way our brains function. The brain apparently likes to take shortcuts, which hampers our ability to listen. A client needs only to hint at a business problem and some of us will jump ahead to where we think the client is going and provide an answer. Only sometimes we haven't really understood the question, so we have to rapidly backtrack to repair the situation.
The problem with this habit is that when you guess right it irritates people, and when you guess wrong it damages your credibility. A client once offered us this tip no how to answer questions well:
"First, listen to the question." In its entirety.
"Understand the question." Understand the context and ask questions.
"Stop." A pause allows you to think about your response.
"Then, answer the question."
Of course we had to get him to write this down, because we missed half of it the first time.
Lesson Learned #32
After a successful project at a large regional hospital, the Carpedia team went out to celebrate at a local restaurant. As we sat down for dinner, one of the partners left to answer a phone call and missed the drinks order. A Heineken was ordered for him in his absence. When he returned to the table, the server asked him if the Heineken would be OK. The partner replied that if it wasn't any trouble he'd prefer a Stella. The server said, “No problem,” and left. This started a fairly heated debate about whether or not there was a taste difference between a Heineken and a Stella, and even if so would someone be able to tell which was which? Most of the team thought they could.The discussion zeroed in on whether perceptions can overpower facts. Unable to leave this unsolved enigma alone, a blind taste test was determined to be the only reasonable course of action.
Five beers were selected for their relative similarity: Heineken, Stella Artois, Alexander Keith’s, Moosehead and Beck’s. All five were poured into small unmarked glasses. Three people volunteered to take the taste test and were asked to list their beer choices in order from favorite to least favorite and to identify the brand of each unmarked beer. The results were surprising. Out of five possible correct selections, the first participant identified none correctly; the second participant one:, and the third participant none. In total there was only one correct answer in 15 attempts. Of particular note: the partner who sent back the Heineken for the Stella scored zero for five in matching the beer to the brand, and ironically chose Heineken as his favorite beer.
The lesson learned was that it’s easy to make decisions, or draw conclusions, based on our perceptions. This is generally OK, because the accuracy of the answer may not be that important. However, in many business situations the right answer is important. Faulty assumptions or perceptions can stop you from identifying the true facts of a situation. It's more difficult to create solutions based on actual facts and observations. And despite the facts, it's also very hard to get people to change their behavior. To this day, our partner chooses Stella over Heineken.
Lesson Learned #31
It is a lot easier to add cost when times are good than it is to reduce cost when times are bad. This may be one of the more obvious lessons, but nonetheless we relearned this one, as many companies did, during the most recent economic decline.
Adding cost, whether people, equipment or marketing, is generally all positive. Taking cost away, such as reducing staff, shutting down plants or offices – virtually every effort companies make to conserve cash – is almost always negative. Many discretionary costs that companies build into their infrastructure are originally intended to be perks, e.g., incentive trips, company events, even something as simple as office coffee. Perks become entitlements quite quickly, so even these costs are difficult to claw back.
The best companies we work for manage their costs against revenue very diligently in both good times and bad. They pay close attention to how overhead expenses (and other non-revenue-generating costs) move in relation to revenue, as these are usually the first tell-tale signs that something is out of alignment. They are also careful to only provide perks that have real value to people and meaningfully differentiate the company.
But even the best companies struggle to react in time to any prolonged downturn, often because of the tendency of managers to create "hockey stick" forecasts (an extended downward revenue trend suddenly goes upward). The expectation and hope that things will soon turn around can stop managers from making what in hindsight look like obvious decisions. When managers do react, they relearn how tough it is to take cost out of a system.