The Process Perspective of TBM

Abstract

It is time to leave our consideration of the background of TBM in order to discuss and evaluate the underlying topics and assumptions. Our focus will now shift to the following questions:

• What is TBM.

• What do I as a business manager have to know about TBM.

• How is TBM different from conventional management approaches to answer this question, it is necessary to understand, from a manager’s point of view, how problem-solving processes overall, and in the areas of Information Technology, Process, and Human Resources Management, are generically similar.

• What do I have to expect from templaters.

• What is a template.

• How can I develop one.

• What do I need to pay attention to when I do so.

• How do I have to change when I am applying TBM.

• What are the benefits of TBM for me as a manager.

All these questions will be answered! Especially for practitioners and managers, this section provides valuable information for dealing with their internal templaters.

In this section you will learn more about the new management approach, enabling you to sustainably optimize the entire operative work as basis for an efficient and impactful professional practice. This means that we are about to jump right into the nucleus of Template-based Management.

6.1 How to Define Template-based Management?

In the earlier chapters, I vaguely described what TBM is. I dispensed with a detailed definition so you could yourself develop an understanding of what TBM stands for. Moreover, I do not want TBM to be tightly defined. It is a new management approach and as such will and should be developed further. New contingency situations in the future will shed a different light on TBM. In this sense, I very much encourage this to be a definition open to discussion.

Definition:

TBM is a proactive management approach that draws on the use of templates to enable employees to deliver content-work in a self-directed way.

By using the TBM approach, the defined and trained templater, the team member driving the TBM project, moves out of purely operational tasks and additionally becomes a content-oriented coach.

This definition should help you to understand the following pages. In Chap. 7 I shall write more on templates. Chapter 8 will deal with the coaching aspect of TBM.

6.2 The Core Steps of Every Problem-Solving Process

An overview on one classical 7-step consulting process can be found on www.vanderbilt.edu/sos/7consulting%20Steps.htm. Another conventional cycle is at display on www.outplay.com/consulting/steps.htm.

Now I would like to show you how TBM is different from conventional consulting and project management approaches. Therefore, I shall first give you a brief overview of how the latter look and work.

6.2.1 Step 1: Problem Definition and Understanding

When a company first approaches a new topic it usually has a brief description of the problem that it is facing and wants to have solved.¹ This short introduction to the subject matter allows the templater to get a general idea about the problem and whether or not their firm can solve it.

In my time as a consultant I have received numerous such problem descriptions and I found them very helpful in spotting what the client perceives to be the core issues in his or her firm. They are useful as a starting point for gaining further awareness of the problem. Once the project manager has decided to take over and tackle the problem, he or she will start to dig further into the mud.

One crucial step, preceding all others, is to define the problem, because it could well be very different from the one the client sketched in his first description. The margin of error on the side of the internal client often ranges from an incorrect interpretation of causalities to an outright false perception. Moreover, knowing the problem is absolutely necessary to continue with one’s work.

To define the problem, to get the whole picture, and ultimately to understand the issues at hand, I try to talk to as many people as possible, also from departments, one would not think of as being connected with or affected by the original problems. Various projects at companies from very different backgrounds proved to me that especially those employees not directly related to the problem had the most intriguing clues to what could possibly be the source of the trouble. This is because they analyzed the problem from a distance and thus objectively.

Talking to the directly involved employees, though, is not it? If it were, the internal client would not need your help. Asking yourself the following questions is key to defining the problem:

• What has gone wrong? What is not working properly and what is.

• What should be happening that is not and what should not be happening that is.

• Where does the problem arise? Does it arise only there or also somewhere else.

• When does the problem arise?

• What and who is affected by the problem?

• What costs does the problem cause? Is it worth fixing the problem?

• How urgent is fixing the problem? Will it probably go away of its own accord? Can we wait? What will happen if we wait?

• What will happen if we do not do it right.

By asking these questions, you are not only describing the problem but also beginning to understand it—its causes, its nature, and its implications for the relevant organizational unit. For further clarification, though, it is necessary to apply analytical methods, depending on the type of problem.²

6.2.2 Step 2: Goal Definition

The second step of every problem-solving process is to specify the goal, the “solved state.” Ultimately, you need to ask yourself “Where do we want to be at the end of the day?” Defining the goal is necessary in order to later on devise a means for reaching it. There are two problems with defining an objective, though.

First, it often seems as if there were various objectives. Most of the time, however, there is just one core objective and the others are results of reaching the core goal. Spotting the central objective is important. To spot the central objective, some sort of framing has to be done. Framing “determines the viewpoint from which decision-makers look at the issue and sets parameters for which aspects of the situation they consider important and which they do not.”³

Second, businesses often define their goals in numbers, thus setting quantifiable objectives (i.e., “We would like to increase our customer retention rate by 30% as a result of this project.”). This is to some extent the result of the popularity of management by objectives (MbO), whereby objectives must be focused on a result, specific and measurable.⁴ The problem with these kinds of targets, however, is that they do not tell you anything about how to meet them. Moreover, an increase in the customer retention rate of 30% does not automatically indicate that the initial problem has been solved. There could be a variety of other reasons for this positive outcome. Therefore, one should supplement quantifiable targets with non-quantifiable ones (i.e., “We would like to make our customers more satisfied.”). Because then, the goal also comprises personal and emotional aspects, which in turn spur lateral and creative thinking.

The task of defining a goal very much resembles peeling an onion. One must remove all layers to get to the central point. Doing so may entail answering the following questions:

• What would the situation look like if things were going right?

• What would be happening that is not and what would not be happening that is?

• What are we trying to achieve?

• What are we trying to eliminate?

• What are we trying to avoid?

• What are we trying to preserve?

• How can we measure our success?

• Are there any indicators to show us that the problem is solved?

It is important to make sure that the objective supports the overall purpose. Of course, the goal definition step is not a unipersonal but rather a multipersonal process. This means that there are multiple people involved in specifying the goal. Personal as well as company expectations often clash. Coordinating and harmonizing these groups of people so as to define one single goal is one of the essential and most tedious tasks for a consultant, project manager or templater.

6.2.3 Step 3: Alternatives for Problem Solution

Once you have defined your goals it is time to find ways to solve the problems you are facing. And naturally, there are myriad paths you can follow.

6.2.3.1 Finding Alternatives

This phase is about finding as many ways as you can imagine reaching the intended objective. And “imagine” is the keyword. Finding alternatives for the problem solution is a very creative job. And it is very critical to keep it so. Only when people feel that they can engage in the problem-solving process actively and without limits will they put their whole energy into it, eventually producing astonishing results.

For me, this is the time when I am just listening, encouraging a free flow of ideas. It is important to respect one rule: In this phase, there is none. If you do not, you will learn the hard way that the participants soon lose their interest and, consequently, their willingness to help you in choosing the “right” path toward the set goals.

6.2.3.2 Evaluating Alternatives

Out of the pool of different alternatives, you will ultimately have to pick the ones you think will best lead to the goal. Therefore, you need to analyze the options—keeping in mind the original problem and the goal defined in the previous step. Additionally, you have to keep in mind who at the company will ultimately carry out the tasks you are devising. Your solution has to be tailor-made not only for the company but also for the people working for it. This is especially vital for TBM, where people are at the epicenter of the implementation process.

There is a large number of techniques for appraising alternatives.⁵ Calculating the expected value of the various alternatives’ outcomes or making a list of advantages and disadvantages are just two of the most prominent methods. I would like to dispense with a detailed discussion of them at this stage, though, for I shall return to some of them in the case studies.

What you are basically doing is peeling the onion—again and again testing the alternatives with different means to see whether or not the outcome is still favorable.

6.2.3.3 Choosing Alternative(s)

This is basically about choosing your weapon. Based on his or her evaluation, the templater and project manager finally decides which alternative(s) he or she will go for and sketches a plan for starting with his or her actual work.⁶

This, then, is the stage at which TBM parts ways with other, traditional project and problem-solving processes. For the moment, however, let us take a look at how the story continues when a conventional path is taken.

The next section deals with the last phases of a conventional, “classical” problem-solving process, which differs a lot from TBM.

6.2.4 Step 4: Problem-Solving (Delivery)

Traditionally way, the project manager goes straight to the actual task of solving the problem. This means that he or she sells the client a product or a procedure for operationally delivering a specified result that will unravel the defined problem. The manager delivers operational results.

Of course, there is nothing wrong with getting straight to the point without wasting time and money. However, the problem is that many projects usually focus only on the singular solution for the defined problem. In case another, related problem arises, they often have to rethink the former solution in addition to finding one for the new issue. This is particularly relevant for IT projects, during which you need to take some loops as the proposed solution does not meet the ex-ante defined requests. Today a commonly used term is agile project delivery. This is one mistake that TBM avoids by abstracting the problem. More about this later in this chapter as well as in Chap. 8, however.

Furthermore, the project manager often does work that the employees are capable of and sometimes even responsible for doing, but for whatever reasons do not do. This is something that directly and indirectly costs the company money and can be avoided. In the traditional form, the project manager and the dedicated team have now implemented the solution. Now comes the time to face reality. The question is: Has the job been done successfully?

6.2.5 Step 5: Evaluation

The task of evaluating the work that the project manager has done is usually performed together with management, the department(s) that is (are) affected by the changes, and the controlling department. All of them have hard facts and their personal opinions to test whether or not the results correspond with the set goals. If so, well, great! If not—and this is very likely, it is time for the “internal consultant” to rethink his or her work, starting very much at the beginning of the project cycle.

This is how I have experienced the general, classical problem-solving approach—through my work, by observing, and by chatting with people.

6.3 What Are the Four Organizational Threats?

Let us now turn an eye to the four main areas of problem areas and how it typically works out there.

6.3.1 Threat 1: Information Technology

For the IT area, it is essential to differentiate between whether conceptual or actual process work is done. Conceptual work refers to the design of an IT solution or architecture that best fits the respective company.⁷ Process work, on the other hand, involves storyboard development, testing, and implementation of an IT product or tool. Furthermore, it is important to distinguish whether a new product is to be introduced or an already existing one is to be reframed. Then, is it one process or many?

A couple of years ago I was approached by a French company producing perfume. It was a rather old firm. The management wanted to technically link the procurement with their production and marketing activities, because they were often short of supplies and thus had to halt production from time to time. The problem was that the input factors for the perfumes were bought by the procurement department on the basis of average figures from the production facilities. This meant that the people from procurement looked at the production plans for, say, the perfume “Sandrine” and then calculated how much of ingredient A, B, or C their colleagues would need to produce the planned units.

When the marketing department then found that more units of perfume “Sandrine” were required, production could not do the job quickly enough because procurement had to reorder. A system was needed that would keep track of market demand and production quantities and would then automatically order the needed ingredients. Basically, this was about inventory management.⁸

What I had to do was first analyze the process that the French company wanted to have optimized. Therefore, I broke the process down into its various components. This was indeed not anything spectacular, since the company used traditional procurement channels mainly within France and its only production facility was also located in France. Moreover, the perfumes were sold by one single chain in France, Belgium, and Luxembourg.

After the process analysis, I specifically defined the business requirements. This entailed shortening the time needed to get new data about market demand to the procurement department.

The business requirements were followed by a storyboard^9,10 and the actual product development.¹¹ The software was programmed in India, where it was also tested on the same hardware that the French perfume-maker used. And after some minor glitches had been removed, the software was installed at the company. The implementation was successful, and the new program brought the desired effects on inventory management.

This short story from my earlier times as a consultant shows how the IT-consulting process works. The stages are as follows:

• 1. Process analysis

• 2. Definition of business requirement

• 3. Creation of a storyboard

• 4. Product development

• 5. Testing

• 6. Implementation

• 7. Evaluation

6.3.2 Threat 2: Strategy

In strategy, the steps look rather different from those for IT.

Usually, giving advice on strategy to a company involves the following five phases—from a generic perspective:

• 1. Analysis¹²

  • a. Internal

  • b. External (benchmarking)

• 2. Scenario definition

  • a. Best-case scenario

  • b. Worst-case scenario

  • c. Neutral-case scenario

• 3. Prioritization

• 4. Strategy development

• 5. Action-plan definition

This is a process that one could best describe as an overlap of two of Henry Mintzberg’s ten strategic schools.¹³ These are the Design and the Planning School. Both see the formulation of strategy as a well thought out and deliberate process. This is contrary to some of the other “schools,” which see strategy formulation as a visionary process (Entrepreneurial School) or as a collective process (Cultural School). In operational practice, though, the strategy has to do to a large extent with conceptual, formal, and analytical work. Nevertheless, in phases (4) and (5) other factors come into play as well. They are, in particular, social responsibility and management values.

6.3.3 Threat 3: Operations

The operations dimensions pretty much start like the strategic-problem-solving procedure. The emphasis, though, is put on other aspects, and often the analysis goes into greater detail.

Not too long ago, I worked for a company in Boston, Massachusetts, that produced office furniture. They wanted to know whether their very production process—the transformation from input into output, could be made more efficient. This is because management wished to decrease time-to-market.

In production, there can be many reasons for inefficiency, as you, dear reader, might be aware. Consequently, I had to gather information on the numerous sub-processes, on the people and the machines used. I did this by using several collection methods (hard data from the controlling department, questionnaires, personal discussions, open, and concealed observation). This internal analysis uncovered a couple of possible sources of inefficiency. For instance, there was only one smoking room. Thus, a lot of workers had to walk all across the production hall and back just for a 5-minute smoke, which, in the end, turned out to last some 10–12 minutes. Moreover, the location of many machines was not optimal. A lot of component parts took a long time to get to the next machine where they were processed further.

Even though an internal analysis gives you some hints as to where the roots of problems might possibly lay, it does not provide the whole picture. Above all, one needs to compare the data to see whether or not there are major divergences from the industry norm. Therefore, I added an external analysis (benchmarking¹⁴) which showed that, on average, the company was within the industry norm. One of the biggest divergences was found in the latest stage of the production process, when the finished products were checked for quality. The fellows there spent most of their day chatting and smoking. Despite this fact, the number of claims on warranties was low. This led me to the conclusion that the people who actually produced the furniture were doing an excellent job.

Next, I did a quantitative and qualitative description of the processes involved. A quantitative description usually comprises the hard data on the processes such as the time needed to add the backrest to the chair or to sandpaper the wood. Moreover, it involves such facts as to when, where, how often, and by whom a specific task is done.

To visualize the quantitative aspect of a process I often use a matrix-template¹⁵ whose “interfaces” show which step of a process is done by whom, where, when, for how long, and how often. In the case of the Boston company, this allowed me to spot quite a lot of double work (inefficiencies) as well as where IT could improve the process.

The qualitative description, on the other hand, typically is the creative part of the second phase of the operations problem-solving process. This is when the owners of the process come together to openly discuss what is already working out well, what could be improved, and which process is not all right at all. At the furniture company in Boston, this was without doubt the most insightful phase.

This was because the people talked frankly but in a very respectful and appreciating way, so as to create a very productive atmosphere in which exceptionally powerful ideas were brought up. At this point, I was already applying the dual-coaching practice, although unconsciously. The approach had a very good impact on the outcome.

This combination of formal and analytical as well as personal (sometimes even emotional) work helps to provide a sound picture of what is happening in the company. From there on, one can conceptualize and, if required, implement the new, improved process.

So, let us summarize the various phases of an operations problem-solving process as I have experienced it thus far. Generically, they are as follows:

• 1. Analysis

  • a. Internal

  • b. External (benchmarking)

• 2. Documentation of the process

• 3. Process modulation

  • a. Quantitatively

  • b. Qualitatively

• 4. Process design

• 5. Implementation of the optimized process (if asked to do so)

• 6. Evaluation

6.3.4 Threat 4: Human Resources

For HR practice, it is crucial to understand that the term “HR system”¹⁶ is used in a wider as well as a narrower sense. Whereas the wider definition understands an HR system as a mixture of processes, IT systems, roles, and responsibilities,¹⁷ the narrower characterization is solely technical.

When an IT system¹⁸ for managing HR issues is the subject matter, then the problem-solving procedure very much resembles that of a standard IT project process. In the wider sense, when processes, software, and roles are involved, the process is a combination of the three preceding methods. This is because it involves IT, strategy—via strategic human resource management (SHRM)¹⁹ and processes. This latter understanding puts an HR system in light of change management, which is about cultural and structural change.²⁰ Management development and performance measurement programs are designed and implemented to strategically develop the human resources of a company.

The HR project process dealing with an HR system in the wider sense is very complex, because it looks at many different aspects within a company. It is therefore elusive to sketch the relevant approach step by step. Nevertheless, it might possibly look like my outline below.

For you as a business manager, it is important to realize that the process here is three-dimensional at every stage. This means that also the steps of problem definition and understanding, as well as goal definition and alternative evaluation and choice, have to be dealt with, keeping in mind that processes, IT, and roles and responsibilities are influencing factors.

From my perspective and experience, an HR-consulting process may look like this:

• 1. Analysis

  • a. Internal as-is analysis (processes, IT tools)

  • b. External analysis (benchmarking of processes and IT tools)

• 2. Definition of target HR systems (processes, IT tools, roles, and responsibilities)

• 3. Definition of business requirements

• 4. Development of an in-house solution or

• 5. Selection of a provider

  • a. Market research

  • b. First screening (long list)²¹

  • c. Second screening (short list)

  • d. Decision

• 6. Implementation

6.4 What to Learn from the Last Decades?

Within the past decades, one has been able to observe tremendous shifts in the consulting industry. I have already introduced you to some trends in Chap. 3. These entailed the tendency toward performance-related pay, the wave of consolidation, and the increasing power of clients to dictate the content of consulting services. Chapter 4 went into further detail about a couple of trends and the reasons behind them. Now I would like to elaborate on how the focus on consulting service lines has changed over the course of time also reflecting changes in their client organizations, the industry.

In the first half of the past century, companies often created positions for older, high-level employees who would otherwise have had to retire. These employees “advised” the company on strategic issues. They were, in some sense, consultants. The workload of these consultants, however, continued to increase year by year, as top management sought their advice on a regular basis. Consequently, they hired staff to assist them in their work and ultimately founded consulting businesses. This, in a nutshell, is how the first consultancies came to life.

Because the first consultants focused on strategy, this was the main service area for several decades. In addition, an increasingly global marketplace meant that companies had to rethink their strategic fit. First, this involved changing the organization structure from a centralized to a decentralized one. This was necessary for a couple of reasons:

• 1. As companies began to explore other markets, a centralized organization could not cope with the vast amount of data that was now pouring in from all around the world.

• 2. Production facilities were set up abroad in order to serve local markets more quickly or to produce more cheaply. Producing in another country meant being subjected to a different legal and cultural system. A centralized organization could not cope with these two challenges. Moreover, having factories abroad involved taking advantage of the different tax systems by creatively thinking about profitable transfer prices.

• 3. A decentralized organization structure also meant that companies could make products more suitable to different markets as their regional offices were given more autonomy.

In addition to a change in the organization structure, companies needed to devise plans on how to best penetrate and ultimately expand within the foreign markets.

Giving foreign subsidiaries more freedom, however, also meant that the headquarters had to ensure that the image of the company remained homogeneous around the world. A potential cannibalization of the brand had to be prevented. Products should be made taking into account regional tastes and preferences. However, they must not be transformed too deeply. There should still be a resemblance to the original “home product.”

Furthermore, companies had to train and develop their employees so that they could cope with a more demanding, more international work life. The term strategic human resource management (SHRM) came into existence.²²

The needs for companies to change their organization structure, to make products more customized, and to develop their intellectual capital in a strategic way ultimately necessitated the assistance of consultants.

In the late 1970s and early 1980s, the shift toward an emphasis on operational or process consulting took place. This development peaked in the mid-1990s, once Michael Hammer and James Champy had released their classic book Reengineering the Corporation.²³ What happened finally was that consulting turned out to be some “either-or” business. Either you were a strategy consultant or an operational consultant. Whereas the Boston Consulting Group (BCG) or McKinsey focused on strategy, the likes of PwC, Andersen or Deloitte Consulting set their foot in processes.

This clear-cut line between strategy and operational consulting started to become blurred in the second half of the 1990s. Consultancies now commenced to offer an integrated package of both strategy and process consulting. The reason for this was that companies had begun to realize that both issues were to some extent inseparable and key to being, as well as remaining, successful, and competitive. Moreover, consultancies gradually realized that conceptual consulting would not be enough in the long term, because IT-consulting was the area where growth could be realized.

This very picture—that of consultancies offering both consulting services—still prevails today and becomes even worse caused by the digitalization and big data, as already elaborated, developing toward an unrecognizable cocktail of indistinguishable consultancies.

This brief description of the paradigm shifts makes one point very clear: Even though consultants are often visionary, consulting itself has been a rather reactive business, with consultancies usually tending to respond to changes that have already happened, never really attempting to be visionary and proactive in the way they run their businesses. This is because, similar to an individual, companies usually feel the need for change just after some problem has occurred. Thus, consultancies have the air of being problem-fixers rather than companies that prevent problems from arising in the first place. And this is the one central point for criticism of the consulting industry.

Being aware of this deficiency, I have always tried to counsel my clients in a proactive way. Eventually, this consulting style led to the birth of Template-driven Consulting. All the factors described in Chaps. 3 and 4, emphasizing especially growing cost pressure, meant for me that, at the end of the day, companies would demand a more proactive and cost-conscious way of consulting—namely TBM. My goal with TBM, however, was and still is to make it possible for companies to avoid encountering severe troubles in the first place.

Now that we have taken a look on the framework of the four generic organizational dimensions of problem-solving, let us see how Template-based Management works.

6.5 Which Are the Four Steps of TBM?

I have already given you a brief overview of and an introduction to the steps that TBM follows. Here are the phases in more detail. At this point, let me remind you again what TBM is about. TBM is about a knowledge transfer from the templater to the templees or the employees of a firm with the purpose of the latter being able to deliver projects and problem-solving services autonomously. This is something that conventional consultancies have always claimed to be doing. In reality, though, this transfer has never taken place. This is about to change—with TBM!

6.5.1 TBM Step 1: Problem Definition and Understanding

This step of Template-based Management is identical to the procedure described at the beginning of this chapter. It also entails to the same extent the task of defining the goal and finding alternatives. In this sense, the first phase of TBM is not different from the classical consulting and project management procedure. Let me emphasize at this point that we are not reinventing the wheel. There are a lot of good tools and approaches within the classical problem solving approaches which we draw on. We have, however, developed another path that looks more promising in the new contingency situation.

In this phase, both the templater in the sense of a consultant as well as the templee as the internal client deliver content work. Content work in this phase refers to the gathering of ideas to come to a definition of the problem and ultimately the goal. Both parties work together to produce this result. Since the early stages are similar to existing consulting approaches, I will not discuss them at this point again and would like to refer you to the early pages of this chapter.

6.5.2 TBM Step 2: Process Evolvement and Abstraction

In the second phase of TBM we start to develop paths for possible solutions—different problem-solving processes evolve. This is not anything completely new either, as in all consulting projects, different ways of solving the existing problem are defined. These alternatives are then presented as part of the proposal during the acquisition phase. What happens next, though, is new and not part of current consulting projects.

What we do is to take the whole process apart, cutting it into small bits and pieces. Then we analyze each part thoroughly to see which types of templates could be used. However, this analysis is not conducted from an operational angle. Rather, we are abstracting the process, and consequently the problem-solving process, from its operational core. In contrast, consultants pursuing a conventional approach would again move back directly to the operational level. The study of the process/problem involves the following aspects (Fig. 6.1):

Fig. 6.1

Five core aspects for process evolvement and abstraction

In essence, we focus on the driving factors for each activity of the problem-solving process to guarantee success for the dual-level coaching activities provided later on throughout the operational work (see Chap. 8). For this study, for instance, one can use a matrix-template.²⁴ The use of the template allows us to have the relevant information in a condensed form and to compare the driving factors of one process with those of another.

What is important to understand is that we do not analyze with us but rather with the internal client in mind, for they will ultimately deal with the operational side of the problem-solving process. Therefore, we abstract these parts of the problem-solving procedure and entrust the employees with them. The employees consequently deliver operational tasks. This makes sense because they are the people who would finally be doing them anyway. Moreover, the owners of the various processes have an in-depth and sound knowledge of their work and can thus deliver the operational results more reliably and quickly.

The step of abstraction is the key to TBM, because what we do is leave the operational aspects of the process in the hands of the respective process owners. In this way, we save time and, ultimately, the client a lot of money, for we do not have to spend days and nights with the process owners, who would have to describe in great detail their workflow. We rather abstract the problem-solving process from the underlying operational aspects and then design tools, templates, that the employees can use to deliver the problem solving services themselves. This approach enables us to create templates that can ultimately be of use for other industries and problems as well, because the problem-solving process as such may be similar.

In this phase, the templater or project manager is the one who delivers content in the form of evolving the process and abstracting it. The client as such steps back from the content-scene and supports the consultant.

6.5.3 TBM Step 3: Template Generation

The step of generating the templates is a matching process, because we are looking both at the problem and its inherent nature as well as at the template with its underlying problem-solving functions and capabilities. You can imagine this step to be the creation of a profile, both of the problem and the templates. The profile itself is multifaceted. The different facets stem from the problem definition undertaken earlier. In the end, we are characterizing the problem and the problem-solving process.

Given any specific problem, we develop a problem-solving process. We cut it into pieces and analyze and characterize each part. Thus, we take one part and describe it, for instance, as being very demanding from a technical perspective but probably less so in cross-functionality. Then, we search our pool of templates, our database (Fig. 6.2). This template-database is arranged according to four aspects:

Fig. 6.2

Four aspects of TBM step 3

Once we have typed in the specifications, the database automatically searches the relevant templates. Not only does this function help us to spot the right template quickly; it also allows us to see where a template has deficiencies. In all probability, the template matches the technical requirements of the process just perfectly. However, it does not meet the cross-functionality standard. Moreover, it may not suit the person who will ultimately use the template because he or she is another learning or thinking type. So, we know that we have to enhance the template(s) in various dimensions to get the best out of it. Of course, sometimes the complexity and accuracy of a problem demands of us that we transform the templates altogether. But the matching process via our database always helps us—at least to have a starting base for the further development of a new template.

Whether you design and generate a template for the first time or evolve an existing one further, you must keep in mind that it is ultimately your internal client, the templee, who will have to deal with it. Therefore, we have always put great emphasis on preserving its key elements or features. As you will see in Chap. 7, these generally involve being practical from both a technical and a content perspective.

The most pressing issue when generating the templates is keeping the end-user in mind at all stages. Here, an understanding of the different learning as well as thinking types plays an important role, because the templates have to be tailor-made to the user’s needs and specifications in order to realize their full potential. This implies, for instance, that the optimal combination and mix of text and graphical elements have to be found.

The objective of this stage is to create a set of customized and inherently consistent templates—the framework within which the user is enabled to produce the set goals autonomously. In Chap. 7 I will elaborate more detailed on this phase. I will give you background information on how and where templates originated. Furthermore, I will show you how various templates are set up and produced.

6.5.4 TBM Step 4: Project Work Implementation and Facilitation

In Chap. 4 I have already given you the brief analogy of the woodworker who keeps returning to the doctor to have splinters removed. The doctor, happy to have a paying patient, removes the splinters again and again. TBM works exactly the opposite way. The splinters are not removed again and again. Rather, TBM is about telling the patient how to safely remove the splinter him- or herself. This, of course, requires that the doctor shows and explains to the patient how to do this. The templater or internal consultant thus becomes a content-oriented coach, a facilitator. Of course, the last part of TBM also involves the actual delivery of the templates. But the focus clearly is on the coaching activities. They are, ultimately, the essential part of TBM, because through this work the employees learn how to use and, in the future, how to align and adopt the templates for their own benefit.

Coaching the templee is, of course, a very difficult task for the templater. This is because he or she has to move back and forth from the content to the meta-level. I will elaborate on this ability later in Chap. 8. Moreover, the templater is dealing with individuals who may display very individualistic behavior. The templater thus may have to overcome personal as well as analytical barriers.

Coaching the templees has thus far not been part of the traditional problem-solving cycle. This is because external consultancies have until now seen teaching clients their tools—their “magic”—as a threat to future business. I see it differently. The new post-COVID situation in the “Remocal Economy” with massive restrictions on travel activities, including the need to significantly increase internal value creation, requires managers to introduce ways and means that enable employees to solve problems independently and sustainably without external support. The key to this is TBM.

We saw earlier that the “traditional” consultant would finish his or her work by evaluating the results. TBM shows the employees how to evaluate their and other persons’ results. Therefore, the consultant does not have to stay on board, eating up project funds.

6.6 What Is So Different About the TBM Process?

In this chapter, I discussed the conventional problem-solving process which is also applied in most consulting projects. Based on this overview I went through the modified process of the Template-based Management approach (Fig. 6.3). The difference lies in the fact that after step 1 normally the operational project and problem-solving process start. This means that a know-how owner, such as a consultant, gathers data, runs analysis and researches, consolidates and documents all, and finally then—more or less critically—evaluates and derives key findings. These are then presented to the client or project owner. Know-how transfer only takes place very limitedly through the handed-over final project work presentation.

Fig. 6.3

Process comparison of classical problem-solving and TBM-based process

Applying TBM, after the first step the operational problem-solving process is structured and pre-defined, similar to developing the structure of a book. The aim is, to understand the outcome of each further step and cross-check whether these outcomes are what you need for the next following step. All is about stringency and consistency. Based on this pre-defined abstracted problem-solving process then in step 3 the templates are designed which then shall guide and lead the project team members, the templees, through the process. From then on as part of step 4 the TBM-based operational project and problem-solving work can start.

This process realizes many different operational and strategic advantages and benefits which sustainably will positively impact the entire organizational learning and development. For a comprehensive overview of all these benefits please kindly see the “Benefits of TBM” chapter at the end of the book. By now you should understand what makes the difference of TBM in regard to the problem-solving process.

In the next chapter, I will try to enable you to develop a broad understanding of what templates are, which types of templates we define, and how to generate them.