The "hockey-stick forecast" is a fairly common concept for people who deal regularly with future plans of one type or another. This is the trend graph that shows a general downward trend in performance in the past few periods' actual results, and then a sudden and dramatic upturn in forecast results. It looks like a hockey stick. The business world is full of strategic plans littered with charts like these.
When we review a business to understand where it is coming from or headed, one of the things we pay close attention to is if there are any "hockey-stick forecasts" in its budgets. They are often buried within the numbers, so we often need to do some digging.
We find "hockey-stick forecasts” where performance in an area is expected to improve dramatically year over year. The fact that performance is expected to improve is not as much the issue as trying to understand the underlying logic as to why it will improve. What you have to decipher is if the improvement is related to changes in the product or service mix, margins or productivity.
Sales forecasts are a common "hockey-stick". If sales are expected to increase by any amount greater than what has been demonstrated over the past few years, you need to understand the underlying drivers of that improvement. Sales forecasts are often driven by the optimism of salespeople and their customers, but implicit in sales growth is a myriad of sub-drivers and corresponding activities. Here are just a few questions that can be helpful when trying to understand where sales growth is expected to come from:
- Will the growth come from existing or new customers? If new, what marketing or sale activities will increase or improve?
- Is the growth from existing or new products or services? Existing or new markets served? Larger order sizes?
- Is the market growing or is business being taken away from competitors? How will this impact pricing and margins?
Hockey-stick forecasts can be very useful analytical flags to help you better understand underlying operating assumptions. You can also check to see if management has the necessary tools to measure and track those assumptions. When companies struggle to hit their budgets, you'll often find a few gaps between what was planned and what was actually managed.
There's quite a lot of internal debate about where the catchy expression, "in the day, for the day," originated. Some claim it was a past client; others say it was one of our own project directors: still others claim it is a common expression that’s been around for a while. Whatever its origin, it’s becoming a very popular way to describe how front line managers should think and act.
It is a useful analytical device that we use to help find opportunity to improve. “In the day, for the day" refers to information about what is happening on the current day -- not yesterday or last week. The closer to real time that you give managers feedback and information on what’s happening, the quicker they can help influence the performance of their staff. This seems fairly obvious, but it's not common in many industries. Managers often get performance feedback sometime after an event has occurred, which naturally limits its usefulness. Information that arrives “in the day, for the day” is therefore helpful: managers can address issues while they are relevant and impacting work flow. There are many benefits, e.g., identifying quality issues before too many products or services have been delivered. The other subtle benefit of tools that provide information “in the day, for the day" is that for them to be effective, managers must engage with their employees on a regular basis to help correct off-schedule conditions. This has long-term benefits for both managers and employees and, of course, the productivity of the company.
To make an assessment in most functional areas, you simply compile all the reports that a front line manager reviews and determine how many actually provide information “in the day, for the day.” It's often surprising how rare these reports are. If you don't have them, you probably need them. If you're like us, you will start overusing the expression "in the day, for the day" to the point that it shifts from being catchy to irritating -- but it's still useful.
We spend countless hours in many different industry sectors observing and analyzing how work gets processed. We watch employees, managers and the tools they use in order to determine how much of their day is truly productive. Unless we are observing a highly automated process, there is a good chance a typical observation will reveal that somewhere between 35% to 50% of their workday is not truly "productive." This seems remarkable at face value. It means that roughly three to four hours of an average person's workday is not productive. As we've discussed before, this doesn’t mean that a person isn't working; it just means that what they're doing may not be adding any real value. When we share these observations with our clients, the fact that there are some operating problems buried within most processes never surprises anyone, but the magnitude of that loss almost always does.
What’s also surprising is that this hasn't changed significantly over the last 20 years, despite all the advancements in technology and management training.
So, how can all this waste still exist? The simple answer is that the magnitude is often not obvious or measured by anyone, so it goes largely unchallenged and unmanaged. Work standards, when they exist, are often based on last year's actuals, which only serves to hide last year's problems within the standard. When attempts are made to "zero base" standards, they are often softened by too many buffers so they better match the current process.
Sometimes there is also a psychological game at play; no one likes to think they regularly operate at 60% of a standard. In truth, it really doesn't matter, as the standard is only designed to help a manager identify performance gaps, but in practice managers often find it too demoralizing and believe it demotivates their employees. We find many environments where managers prefer to better their own standards ("We were 105% of standard last month!"), but this is not overly helpful for continuous improvement.
The most effectively managed environments we see go to great lengths to measure and identify all the problems they can. They don't see this as an indictment; they see it as a baseline. And the only thing that matters is whether or not the problems are lessening over time.
Editor's Note: In the previous Observation, we discussed why it's hard to eliminate backlogs, --a task that’s often brought forth if you are trying to improve the productivity of an area that uses some kind of backlog-management system (e.g., engineering work orders). We suggested that one reason it's tough is that backlogs are a form of security for many people. Sean Brown, president of Egan Visual (manufacturer of visual communication systems and business furniture) and former Carpedia partner, offers some additional thoughts on the topic:
A key to overcoming this objection is communicating that a large backlog is not the job security people think it is. Certainly there are operational efficiencies that you might be able to leverage when there is a backlog, but there are potentially hidden, but very real risks and costs lurking. Rather than being viewed as a "healthy amount of work ahead of us," employees should recognize that a backlog often represents two things: customer dissatisfaction and a competitive threat.
The larger the backlog, the longer your lead times are (from order to cash). Unless you are in an environment where customers nail down their orders months before they need something, this backlog reflects an unfilled need in their organization. This means they are dissatisfied on some level. Before they order, they own the dissatisfaction. Now that the order is in your backlog, your name is on it. Enter the competitive threat: many companies have won share and dominated industries by competing on lead times: "Order from us and get your stuff right away."
Identifying and communicating the source of the backlog and its burning platform will help build understanding and momentum in backlog elimination. This will in turn help generate some (one-time) cash early in the improvement initiative, directly contributing to the project's ROI.
In the previous Observation, we discussed Parkinson's Law, which states that work expands to fill the time available for its completion. There is a similar phenomenon, which we call the “Backlog Effect: Work expands because there is no additional work available.” If people are aware that no work awaits them after they complete their current tasks, they will naturally start slowing the rate of completion to avoid running out of work. This is very common in project-based work environments.
A healthy and visible backlog is therefore helpful for maximizing the productivity of your people. Taking that backlog away may cause employees to be concerned about their job security. This perceived “threat” may cause (consciously or not) a slowed pace of work or assignments being stretched out in one way or another.
When we work in project-based or work-order based environments (such as software design, engineering or maintenance), we often find that people are not as productive as they could be for various reasons. The basic equation for productivity is output/input, so logically to improve these areas, you need to increase output (tasks or work orders completed) or reduce resource hours, or both. Inevitably, a request to reduce resource hours is met with: "Before we can reduce any hours, there is a large backlog of work that needs to be brought under control." This is difficult to achieve, however, because you run directly into the Backlog Effect. If people sense that eliminating backlogs will eventually lead to eliminating them, you can understand why they may be tempted to manage their pace.
In 1958, Cyril Parkinson published Parkinson's Law arguing that "work expands to fill the time available for its completion." It's a slightly cynical observation that suggests that people will change their pace of work based on how much time they have or are given to complete it. We see this all the time across different industries and functions. If people are close to completing a task near the end of their day or shift and run the risk of having to either start or be assigned another task, they have a tendency to ease off the throttle. It's a relatively benign human reaction to a situation -- and it’s rarely a deliberate attempt to somehow short-change or undermine the organization. But it reduces or limits productivity none the less.
The fault is not the individual's responsibility, however. Stretching work to fill the time allotted has everything to do with assignment and expectations -- something a manager controls. Parkinson's Law rings true more frequently than it should because many managers do not assign work with time-based expectations. This is perhaps most common in office environments, where assignments and expectations are often mistakenly associated with the notion of "micromanagement." It is very common to observe employees choosing which project to work on, in what priority, and determining for themselves how long the task should take. Work standards that attempt to relate task to time are normal in plant production environments, but are very rare in office environments, despite the fact that many office work areas share much commonality with production environments. It's also rare to see a manager in an office environment schedule staff with anywhere near the specificity, in terms of output and timing, that a shop supervisor would.
Parkinson's Law exists and thrives in environments where expectations and deadlines are not clear.
Monday, May 13, 2013 will go down in sports folklore as one of the all-time incomprehensible chokes, if you're a Toronto Maple Leafs fan -- or as one of the all-time greatest team comebacks, if you're a Boston Bruins fan. (For non-hockey fans, the Maple Leafs blew a 4-1 lead in the final period of the seventh and deciding playoff game. After scoring halfway through the third period to make the score 4-2, the Bruins pulled their goalie with two minutes remaining and scored two more goals to tie the game. The Bruins went on to win the game in overtime.)
Pat Quinn, a former Toronto Maple Leafs coach, described it as the terrifying moment that most athletes experience at some point in their careers: when momentum shifts to the other team at such a fierce rate that the impending collapse actually becomes predictable -- the awful moment when a coach looks at his team’s bench and only sees players fearful that they’ll be selected to go onto the ice. Most people who watched this game shared this sense of impending doom (or elation, again depending on your perspective), well before the outcome of the game was actually determined.
Change-management projects can also be affected by shifts in positive and negative momentum. It’s the reason that most change efforts stress the need to demonstrate some "quick wins" early in the engagement. The deliberate and careful staging of prototypes serves a similar purpose. These quick wins or successful trials give people the strength to believe that things might actually get better. The magnitude of the early results is much less important than the decisiveness and clarity of the improvement. Success can become an expectation, which can be very powerful in building a broad base of support for change. Conversely, miscues and mistakes early in a change-management project (e.g., poor communication, errors, conflicts between people) can do lasting harm. Doubt and pessimism can be just as powerful forces at changing momentum as belief and optimism.
Momentum shifts can happen at all organizational levels (company, department, team, individual). The advantage of a change-management initiative over many other circumstances is that it is a fresh start. Most people are willing to enter into a project -- provided it is introduced well and seems reasonable -- with a slightly optimistic sense that it could work. From this point on, however, the process is something that needs to be carefully orchestrated and managed.
A number of years ago, we started an interesting study called the "whereabouts" study. The idea behind the study was to try to illustrate where a front-line manager spends most of his or her time during the course of the day; correlate it to what is actually happening in the business at the same time; and determine if it would be more useful for the organization to have the manager's day look differently.
What we found is that managers spend a great deal of their time behind closed doors, either in their office or in meetings of one kind or another. Generally they are the most technically skilled in their function, so their absence from the front-line raises a number of interesting questions. It also has some bearing on another observation, which is that 90% of the problems that impede someone's daily productivity have nothing to do with how hard that person works. The front-line manager has the most important role in the organization as far as managing the point of execution: the point at which things actually get accomplished.
This raises a number of questions. Should a sales manager spend more time in the field with sales reps? Should a managing engineer spend more time following up with designers or coders? Should a maintenance manager follow up more frequently with mechanics?
Hotel kitchen chefs, on the other hand, spend the bulk of their time directing, coaching and marching up and down the culinary aisles. Clearly they should be a role model, rather than the exception.
In the end, every organization and each individual function needs to tailor its own management profile, but it is often eye-opening to determine where front-line managers spend their time.
Properly integrated management systems are the most important tool that a CEO has for aligning an organization and creating a culture of accountability and continuous improvement. Management systems help all management levels plan, execute, report and improve their area of responsibility in accordance with the CEO's strategic direction. Unfortunately, almost all management systems suffer from one or more of the following fundamental problems:
1. Planning doesn't directly integrate with execution.
Key planning tools include budgets, forecasts, production plans and work schedules. For them to be effectively integrated, you need good work-to-time planning standards and reasonable mathematical relationships between revenue dollars, functional volumes and activities. Links between these elements are often weak or nonexistent.
2. Execution tools are missing.
Execution tools are "in the day, for the day" elements that help a manager know whether the individual or department is on schedule or not. Production areas are better than office environments for this, but both areas often lack accurate schedules, which makes follow-up activity less meaningful. Manager follow-up on the plan and real-time performance feedback during the day is noticeably absent in many work areas.
3. Reports are disconnected from front-line activity.
There is never a shortage of reports, but it's often hard to find reports that are truly useful for front-line managers. Most reporting is too "after the fact" to be much good for day-to-day management.
4. There is no systematic way to improve performance.
To improve performance, managers need to be able to identify variances (off-schedule conditions), problem solve in order to figure out how to improve the process, and then make sure that the new methods and work-to-time relationships are built into future planning. Variance identification requires accurate planning parameters, which unfortunately are often inaccurate. Without a formal method and feedback loop for improvement, problem solving tends to become temporary firefighting -- and problems may simply become an accepted part of the process.
"Required Results" -- or "R2", as it's more commonly called by our clients -- is the tag name we use for objectives or goals or targets. It came about as a result of an observation we made in the first few years of the company. When we studied organizations and how management reacted to off-schedule conditions or variances from their plan, we noticed that results that came relatively close to an objective were generally considered "good enough." Coming in “pretty close” to the original goal meant they did not dwell on why they didn't actually hit it.
Jim Collins, the celebrated business author, was addressing this phenomenon when he wrote, "Good is the enemy of great."
The problem with rationalizing or even accepting results that are "good enough" is that it stops problem solving dead in its tracks and, over time, gradually erodes the performance of an organization. Companies have a way of embedding last year’s results in this year's plan, so if you accept “good enough” when you are close to plan, you can end up quietly lowering the bar every year. That is why we came up with the term "Required Results": it has a different meaning. Targets and goals tend to become ideals to strive for, whereas a requirement is a requirement. Managers respond better to the term and quickly come to understand that any result below the requirement is not OK. This helps to reinforce the discipline of problem solving for any and all variances -- a critical skill needed if organizations want to manage and drive their performance levels.