Procedure in Project Work

Abstract

The success of a project is influenced by participants, their ideas, the will to implement as well as the available resources, and also significantly by a logically structured approach. Dividing the project into individual, self-contained project phasesnot only reduces complexity but also illustrates the common thread to all stakeholders. In addition, these form the basis for subsequent project control by comparing target and actual values with each other.

1 Project Phases and Models

As diverse as the type and number of logistics projects are in practice (see Chap. 1), the procedures and sequences between the individual project phases are also very different. IPMA defines a “project phase” in its guidelines as “A project phase is a discrete time period of project sequence, which is clearly separated from other periods. A project phase includes both major project deliverables and decisions which are the basis for the next phase. Phases have defined objectives and may have specified time limits. Different phase models may be used for different kinds of (sub)projects which increases the complexity of coordination. Milestones can be used to work toward specific targets or phase limits or intervals in between. In practice the project phases can overlap (e.g. concurrent stages, fast-tracking)” (IPMA, 2006, p. 60). This results in the following characteristics for a project phase:

• Time limitation

• Clear phase goals as intermediate steps to achieve the overall project goal

• If necessary, subdivision by milestones (for checking and evaluating results)

The subdivision of a project into project (management) phases not only serves to structure tasks, content, and goals but later also facilitates ongoing target/actual comparison and project control at the end of a project life cycle. In addition, it can be used as a standard for all projects in the company and avoids having to plan from scratch each time (for a comparison of the advantages and disadvantages of a division into project phases see, e.g., Gessler & Kaestner, 2010, p. 350 f.).

Project Phase or Project Management Phase?

Project phases define the individual course of a project, whereas project management phases do not refer to an individual project, but define the general, ideal-typical course in the project life cycle (e.g., How should logistics projects be handled in company xy?). In practice, however—as in this book—this linguistic differentiation is unusual. In both cases, we speak exclusively of “project phases.”

The project phases can be summarized in different phase models of project management. The best known of these are:

• Sequential phase model

• Parallel phase model

• Iterative phase model

• V-Model

Since the latter two are used more in product and software development projects, these will not be considered further. The sequential approach is characterized by the fact that the next project phase (e.g., the development of a target concept) can only begin when the previous one (conducting an as-is analysis) has been fully completed (see Fig. 2.1).

Fig. 2.1

Sequential phase model

The two advantages of simplicity and clarity are offset by the disadvantage of the rigidity of the system: The next phase can only start when the previous one has been completely finished, even if it is only marginal, e.g., if logistics costs are only available for the first three quarters and not for the entire last year for actual analysis under consideration. This approach can lead to unnecessary project delays, the simple phase model is recommended exclusively for simple to moderately complex projects of logistics project type I (“logistics optimization project”).

In the context of more complex logistics projects, parallel phase models tend to be used in order to avoid time delays in the project. These delays are caused by the fact that project contents that are of lower priority for the success of the project tend to be incomplete (or cannot be completed), which would increase the total duration and often the total cost of the project as a result of the rigid sequence of project phases.

By working on project phases in parallel, a project can be accelerated. However, the challenge is to determine in the course of project planning from which point in time (milestone?) of the previous phase the next one would start. In addition, there is a risk that certain tasks of the previous phase are never really completed because the project team is already 100% focused on the next phase. Typical examples from practice are lack of updating of data material as well as generally insufficient analysis of the initial situation, true to the motto: “Why should we deal with the past? After all, we know our problems and should devote all our energy to finding solutions!” However, the fact that a well-founded root cause analysis automatically leads to sensible suggestions for improvement is disregarded. Also, the documentation of project results from the previous phase is occasionally put on the back burner in order to continue quickly with the next phase. At a later point in time, the results of the previous phase may no longer be comprehensible, may be doubted by critical stakeholders, and must then be prepared again in a time-consuming manner. In summary, the following strengths and weaknesses can be presented in a balance of arguments (cf. Table 2.1).

Table 2.1 Strengths and weaknesses of the parallel phase model

2 Overview of the Project Phases

Irrespective of the question of a sequential or parallel approach, there are various methods of dividing a logistics project into individual phases. As a rule, such projects comprise at least three phases, but in the course of an outsourcing project in contract logistics these can comprise up to eight steps and more (Hartel, 2006). The lowest common denominator is the following project progression:

• Project preparation

• Project implementation

• Project follow-up

The abundance of possible classifications in project phases is to be reproduced in a rudimentary manner, whereby no claim is made to completeness and models outside of logistics issues are left out (cf. Table 2.2).

Table 2.2 Project phasing of selected authors

In addition to the different number of project phases, it is noticeable that the start and end points also diverge in the approaches of the individual authors. For example, some of the project phase classifications used by management consultancies are characterized by the fact that they begin with as-is analysis and not with project initiation. In these, project initiation and planning are seen as part of the as-is analysis phase or are completely excluded, since these phases may already have been completed before a consulting unit is integrated into the project.

Based on the approaches presented, a logistics project will be composed of six project phases in the following:

• Project initiation

• Project planning

• As-is analysis

• Target concept

• Project implementation planning and implementation

• Project completion

The model is characterized by the fact that preparatory activity is given greater importance and is therefore considered in the form of two phases (initiation and planning). In addition—in deviation from some authors—a separate phase “as-is analysis” is defined. Especially in logistics projects, at least according to the author’s experience from practical application, existing structures are generally used as the basis. Therefore, an intensive examination of the status quo, including the problem, causes, and cause–effect relationships, is recommended. A separate “project controlling” phase has been omitted, since this is an integral part of all six phases in the sense of planning, managing, and controlling project activities (see Chap. 4).

The individual phases will now be dealt with in an overview so that these can then be presented in detail and illustrated with examples in the following paras.

Project Initiation

During project initiation, the project requirements and the project scope derived from the project requirements are first tentatively defined. If the project involves complex issues where outcome and profitability are still unknown or uncertain, a preliminary study (=preliminary investigation; often supported by external expertise) may also be undertaken in this phase to determine chances of success or potential. At the end of this phase, there is a presentation to the management, to decide whether the project topic should be pursued further or not.

Project Planning

Project planning is used to structure the project in terms of structure and process organization on the basis of the project outline. Each project phase is subdivided into work packages. These, in turn, are structured in terms of (sub-)objectives, tasks, responsibilities, and deadlines and transferred to a work breakdown structure. The organizational structure includes the definition of the project organization including the staffing of the committees/teams.

As-is Analysis

During the as-is analysis, the initial situation is recorded and evaluated in detail, often in monetary terms in logistics projects. This concerns not only numerical data facts (logistics costs, inventory ranges, delivery reliability, degree of warehouse utilization, … .) in the status quo to be optimized but also their weak points and underlying causes. The scope of the as-is analysis depends on whether the logistics project is a genuine innovation, for which there is hardly any reliable numerical material, or whether an existing situation (structures, processes, infrastructure, etc.) is/are to be subjected to a redesign. At the end of the as-is analysis, it becomes necessary to reevaluate the project outline in order to validate the project potential.

Target Concept

Based on results of as-is analysis as well as ideas from outside (through involved consultants, benchmark partners, literature research, or other secondary sources), the target state is defined. To achieve this, guidelines for a target concept should be formulated. These represent both the cornerstones and initial evaluation benchmarks for the development and evaluation of alternative solution proposals. The preferred alternative is planned as a target concept for the time after the change has been completed (target structures, processes, resources, etc.).

Project Implementation Planning and Implementation

In some projects, a distinction is made between “implementation planning” and “implementation”. However, since both steps are closely linked in practice (in terms of content, personnel, time), no separation is made here. Analogous to the target concept, it is planned at this point how the target state is to be achieved in terms of implementation. The responsibility for implementation varies greatly and depends on the type/nature of the project: It ranges from a strong internally driven implementation (often in process and organizational projects) to a strong externally influenced implementation (often in infrastructure projects), in which contractors are responsible, for example, for the construction or conversion of logistics halls on schedule and in accordance with requirements.

Project Completion

The final phase involves the handover of the project from the project managers to the process owners in day-to-day business. By this time, not only all project documentation must be completed, but a project review should also take place in order to derive findings from comparison of plan to actual for future projects and project teams in the sense of “lessons learned.” In analogy to the project kick-off, a project closing meeting should take place to officially end the project internally and externally (see Fig. 2.2).

Fig. 2.2

Standard phase model in logistics projects

In the diagram, the sequence of phases is parallel with the exception of the first and last phases. Since a Go/No Go decision should be made at the end of project initiation, it would not be effective to start project planning before the final decision regarding project implementation has been made. The rationale for the sequential processing of the last phase (“project completion”) results from the short duration of the phase and the necessity that all preceding activities must have been carried out so that the project can be completed (cf. example in Fig. 2.3).

Fig. 2.3

Project phases of a production logistics project. (Project example)

3 Project Initiation

“No problem, no project”—project triggers of any kind represent situations that do not, sufficiently or no longer correspond to the desired target state. In terms of logistics, project triggers can be, for example:

• Specific customer requests

• Long lead time in the company or along the supply chain

• Establishment or relocation of sites (production, sales, procurement, distribution sites), e.g., fulfillment centers in online shopping or offshoring of production

• New product ramp-up or product phase-out, e.g., final stocking at the end of the product life cycle

• General cost pressures

• Creation of a USP through special delivery service, e.g., same-day delivery

• Changed legal framework conditions, e.g., obligation to take back old equipment

• …

The possible initiators of a project implementation appear to be similarly complex: As a rule, these are the logistics department or the management as the project decision-making body. Since logistics is a cross-sectional function, all departments can be considered as possible initiators. For example, if their own projects have an impact on logistics (such as a China sourcing project in purchasing with new requirements for procurement logistics in the company), Project initiation is usually the responsibility of the client (sponsor), the potential project manager, and a small core team of one to three team members.

If the project is new, the task is still very uncertain or quite complex, and there is still uncertainty about the potential benefits or divergent views within the company on the subject, it is advisable to carry out a preliminary study as part of this phase, which should answer following questions:

• What area of investigation should the project cover?

• Is the project considered feasible against the background of economic, technical, legal, and social aspects?

• Which stakeholders are directly or indirectly affected? Where is internal or external resistance to the project expected?

• Who should assume the project management function? What human resources are likely to be required and from which areas?

• How high are the costs that can be influenced?

• What costs and benefits can be roughly expected? What is the expected timeframe for the project and its amortization?

• Which alternative solutions can be considered in principle?

• What priority would the project have? What are the dependencies on other projects that are already underway or firmly scheduled?

• What consequences must be expected if the project is not initiated?

• Should the decision-making body be recommended to implement the project? If so, under what conditions?

Preliminary investigations pass the planned project in advance in a fast track. These last—depending on the presumed project scope—between 1 and 3 months and are summarized in a 10 to 20-page presentation document.

If the preliminary study gives a positive conclusion, which is also approved by management, the next step is to draw up a project outline. As a one page document, it provides an overview of the logistics project and, after official project approval, is also dubbed as the project order or project profile (see Fig. 2.4).

Fig. 2.4

Example of a project outline

Typical mistakes when filling a project outline can be noted:

• Missing information

• Project stretches for more than one page, deviation from the internal form template

• Forgetting to budget internal personnel resources

• Incorrect internal allocation rate for internal personnel resources

• Goals not formulated SMART

• Specific (concretely described)

• Measurable (improvement measurable)

• Reasonable (ambitious, but achievable with reasonable means)

• Realistic (realistically achievable)

• Scheduled (target achievement scheduled)

Especially in the formulation of project goals, deficiencies become apparent in practice. The definition must comply with the SMART princilpes. SMART stands for:

• Specific (concretely described)

• Measurable (improvement measurable)

• Reasonable (ambitious, but achievable with reasonable means)

• Realistic (realistically achievable)

• Scheduled (target achievement scheduled)

Against this background, the following examples, which are quite common project formulations do not meet the requirements of SMART:

• Reduce logistics costs by 15%” (By when? Which cost types? By whom? At which location? In which department? …)

• “Significant optimization of logistics processes” (Which? Process start and end? With which goal? Until when? What does “significant” mean, what “optimization”?…)

• “Analysis of the IT functionalities in the warehouse management system by 31.12.2021” (By whom? Is the “analysis” already the project goal? …)

Project Example: SMART Targets

Development and implementation of a C-parts management system by December 31, 2021, at the xyz site by the logistics department with the goals of reducing inventories by 15% and limiting the number of C-parts suppliers to 70 companies.

The definition of project goals is also roughly visualized at some companies in the form of a goal cross, which graphically relates the dimensions “goals,” “customers,” “results,” and “KPIs” to each other (cf. Fig. 2.5).

Fig. 2.5

Target cross using the example of a spare parts logistics project

At first glance, the exact formulation of goals may seem excessive, but it is essential for the following reasons:

• Creating a uniform understanding between the client and the project manager

• Goal transparency between project manager and project team

• Verifiability of project results at milestones and at the end of the project with regard to achievement of objectives (project successful: yes/no? or completely/partially/not at all?)

During the first project phase, so-called guard rails are also defined. These determine which goals and tasks of the project are within (“in scope”) and which are outside (“out of scope”). If there is a strong limitation as to which framework conditions are to be regarded as set by the project team and may not be questioned, this restricts the degree of freedom in search of suitable solutions.

Checklist: Results of the “Project Initiation Phase”

• Problem clearly describable and measurable in one sentence?

• Preliminary study (if applicable) completed and with recommendation for subsequent project implementation?

• Project outline prepared?

• Project goals SMARTly formulated?

• Project approved by decision-making body?

• Project order signed by client and project manager

4 Project Planning

4.1 Project Organization (Structural Project Planning)

A project organization divides the tasks and competencies between the participants. For larger projects, a three-tier project organization consisting of a steering committee, project management, and project team is recommended (see Fig. 2.6).

Fig. 2.6

Tripartite project organization. (project example “Logistics outsourcing to a service provider”)

Only in larger projects is it necessary to set up a steering committee. For smaller and medium-sized projects, this function is often assumed by the respective client. The steering committee determines the responsible department, sometimes even the name of the responsible project manager, who in turn appoints the project team. Under certain circumstances, the steering committee also makes recommendations on the composition of the project team. With regard to the division of tasks between the steering committee, project management, and team members, the following division has been recommended (cf. Fig. 2.7).

Fig. 2.7

Typical distribution of tasks within the project organization

With regard to logistics projects, the following selected special features should be taken into account when organizing the project:

Steering Committee

• In addition to the logistics manager, managers from upstream and downstream interfaces, e.g. Chief Procurement Officer (CPO)/Purchasing Manager or Chief Operations Officer (COO)/Production Manager.

• In the case of logistics project type IV: “Cross-company design project,” consideration of top management on the business partner side.

Project Manager

• In case of a planned logistics outsourcing, it may be problematic to staff the project management with the (previous?) logistics manager.

• Since the effects of logistics must be considered as a whole (at least in relation to the company, ideally in relation to the entire supply chain) expertise and experience beyond the boundaries of logistics becomes a considerable advantage.

Team Members

• Ability of teamwork

• Key figure orientation (“facts and figures” instead of “gut feeling”)

• Communicative skills (logistics as “people’s business”)

Conversely, this list does not mean that the above-mentioned aspects only apply to logistics projects. These may also apply to other types of projects, but from the author’s point of view, these are of particular relevance at least in logistics projects.

4.2 Project Kick-off

Although essential framework conditions have already been set in the project (on the basis of the adopted project mission and fixed project organization), the kick-off event with the project team (“kick-off”) represents the official starting point of the project. Here, too, the importance of first impressions applies: If the project kick-off is poorly prepared or if the participants are not motivated, this will possibly be applicable to the entire project. Therefore, it is of particular importance that the project manager carefully prepares the initial event not only on the technical level but also with regard to the emotional and organizational dimensions. An agenda for a kick-off workshop could be structured as in Table 2.3.

Table 2.3 Kick-off agenda (project example)

If it is a logistics project that is physically tangible, a joint walk-through takes place. This loosens up the working atmosphere and creates a uniform and mutual understanding, especially for the team members who are more affected administratively by the area under investigation (statement by a scheduler during one of the author’s projects: “Yes, now I can see exactly what they do on the shop floor all day”).

The project manager is responsible for the kick-off. In terms of content preparation, he or she should consider the following points in advance:

• Is the project background comprehensible?

• Is the project goal understood?

• Does the kick-off document have a common thread?

• Are the project contents presented (e.g., previous analysis results) correct and up-to-date?

• How could subtasks and work packages be structured?

• What information is needed for the subsequent as-is analysis?

• With which result should the workshop be concluded?

The last two points reveal a certain dilemma: On one hand, the project manager should have concrete ideas about the results of the individual agenda items even before the meeting (not least in order to provide incentives for discussion); on the other hand, he or she must not moderate the kick-off event as if it was simply a matter of getting his or her own preliminary considerations “signed off” by the project team.

Typical mistakes in technical preparation are, for example:

• The project manager acts as over-expert, the team members feel overwhelmed to comprehend the presented contents in the short presentation time.

• Project manager deliberately does not provide any technical input and sees himself exclusively in the role of a moderator.

• The project manager is not able to comprehend certain results of individual slides (“I can’t tell you the data source of the inventory analysis now either.” or “Why the transport costs at location x are higher than at location y, I’ll have to check again.”).

• Especially in logistics, there are few people who know the process from start to finish. Therefore, the scope of the investigation should be clearly and unambiguously delineated (Where does it start, where does it end?).

• The required project capacities of the team members are not coordinated with the line managers in advance.

The relationship level appears to be as important as the factual level, especially if the meeting participants do not know each other very well. Here, too, the project manager should answer questions in advance:

• Do the team members know each other? Does a round of introductions seem to make sense or is it more likely to be perceived as a nuisance?

• If the participants know each other: Was the previous cooperation rather neutral, positive or negative?

• Is the project goal not formulated too abstractly? How can I ensure that all participants identify with the project and its goal?

• What incentives can I create for cooperation?

The project kick-off provides a platform for finding the broadest possible base of comrades-in-arms who—beyond the project manager—will actively drive the project forward and communicate this to the organizational units beyond logistics. This is where the foundation is laid for turning a one-man show (project manager) into a generally accepted project. Similar to classic organizational projects, there is also a typical distribution of team member types in logistics projects (since these are strongly influenced by people and emotions) (see Fig. 2.8):

Fig. 2.8

Types of behavior in change projects. (Vahs, 2012, p. 357)

The third dimension concerns organizational preparation. Of relevance here are:

• Was the invitation with agenda sent out in good time?

• Is the room appropriately equipped (daylight, projector, flipchart, …) and is it the right size?

• Should the presented document be distributed in advance or only after the event along with the workshop results?

• Can it be ensured that a member of the steering committee will do the welcoming?

• Are there special rules of the game in the project or do the general ones of the company apply (usually posted in the meeting room)?

• Who is responsible for project reports, minutes as well as project documentation?

• How often should various teams meet and where? How is communication to be done in general? Is a new folder already set up in the project drive?

4.3 Project Environment Analysis by means of Stakeholder Analysis

Before planning the actual project, an environmental analysis should be carried out. It deals with the factual and social influencing variables that have a direct or indirect effect on the project over the course of time. In addition to a number of factual factors, the groups and individuals directly and indirectly affected as stakeholders play an important role in the planning and implementation of logistics projects. Depending on the scope and degree of influence, their willingness to cooperate or their resistance can accelerate or delay the project or even lead to its termination. To a considerable extent, the success of the project is largely determined by its acceptance in the project environment.

Within the framework of the stakeholder analysis, all stakeholders are considered with respect to their conflict potential and influence on the project. The aim is to identify various recommendations for action on how potential conflicts and resistance can be avoided or overcome and how high is the corresponding probability of occurrence of the risk. This can be presented as a matrix (cf. Fig. 2.9) or table.

Fig. 2.9

Stakeholder matrix. (Project example “Development of a cross-plant logistics strategy”)

4.4 Activity-Based Project Planning

Those who do not think about the future will soon have big worries (Confucius, Chinese Philosopher).

Project planning in the narrower sense refers to the planned activities and is divided into tentative planning (work breakdown structure) according to project phases, milestones, sub-projects/work packages and resource requirements on one hand and detailed planning with regard to the creation of activity lists and resource usage profiles on the other.

Tentative planning is primarily used to structure projects—depending on their size and degree of complexity—in such a way that these can be controlled during implementation. The Chinese philosopher Confucius already stated: “First, the project should be divided into project phases, each of which concludes with a milestone.”

At least at the end of each project phase, a milestone should be set; in larger projects, milestones can also be set in a project phase. Milestones serve to continuously monitor the progress of the project (cf. Table. 2.4). The milestones should answer the following questions as an example.

Table 2.4 Milestone plan with comparison plan to actual (project example)

• What results (in terms of time, content, quality) are to be achieved by the milestone?

• Are these results available in writing in an adequate form?

• What decisions are to be made by the project manager and/or the steering committee?

• What are the consequences of not reaching a milestone by the agreed date?

• Who determines whether a milestone has been reached or not?

As can be seen from Table 2.4, it has not been possible to keep to the schedule so far and the concept has not been built up on time for all areas. The time required was underestimated in this case.

A project review takes place simultaneously at particularly critical milestones. “Critical” in this context means that decisions have to be taken that will have a significant impact on the progress of the project and the project goal, for example in the selection of a solution path among various possible alternatives. As early as the rough planning stage, the project is not only broken into subprojects, which in turn is reflected in the project organization, but is further subdivided into a work breakdown structure (WBS). A WBS can be oriented to objects, functions or activities and defines activities and not objectives/results (cf. Fig. 2.10).

Fig. 2.10

Graphical and tabular representation form of a work breakdown structure (pm Handbuch online, 2014)

Notes on the WBS

The WBS is a central planning instrument. With this, the project planning synchronizes the areas of resources, content, and time. The following notes should be observed:

• Three levels of a WBS: project (PT)—subtasks (ST)—work packages (WP)

• Subtasks = sum of similar work packages, usually main tasks, main functions, sometimes also project phases (not ideal)

• “Project management” should always be managed as a separate subtask

• Work packages = sum of tasks with identical goal

• Numbering according to WBS code, ST with 1, 2, 3 etc.; WP with 1,1, 1,2, 1,3 etc.

• Guideline values for WBS: max. 8–10 subtasks per project, max. 8–10 work packages per subtask, max. 5 to 7 milestones per project

• Guidelines for WP: one responsible person per WP, team size max. 5–8 members, processing time max. 1 man-month (approx. 160 h) and duration max. 3 months

Key question at the end: Can the project goals be fully achieved after all work packages have been completed? Are all aspects covered in terms of content in the WBS?

A work package represents the total unit of activities that deliver a self-contained result. For this purpose, a work package description should be created with the following contents:

• Designation

• Prerequisites/completed work packages

• Activities included and activities not included

• Planned result (outcome)

• Effort (if necessary separated by internal/external)

• Work package responsibility

• Additions

The next step in project planning is to create detailed planning. For reasons of efficiency, it is recommended to use work breakdown structure for this. At this stage, work packages are broken into activities and supplemented with dependencies, resource requirements, and deadlines. In practice, the comparison of required resources (planning) and available capacities (actual) often results in the following problems:

• Detailed planning exceeds the available time budget of the tentative plan.

• The required resources are not available internally.

• The desired external resources (consultant days) exceed the agreed volume or project budget for external consulting services.

• In principle, there are multiple approaches to solving the problem:

• Acceleration of project activities through increased parallelization

• Shortening activity cycle times by reducing content, e.g., estimation or partial collection of figures instead of full collection from SAP

• Shifting activities (from day-to-day or project business) to colleagues or external parties (“outsourcing”), e.g., consultants or service providers in general

• Project prioritization compared to other projects, i.e., shifting of resources

• Ultima Ratio: Adjustment of the tentative plan (with respect to time, resources, and budget)

It should be noted that these approaches can also be used in combination, but the last two options should only be used in consultation with the steering committee or the client.

Checklist: Success Factors of the “Project Planning Phase”

• Close coordination of tentative planning between client and project management or project management and project managers of other projects (Are there overlaps? If so, how should they be handled?)

• Close coordination of detailed planning between project management and project team or between project management and line managers.

• Scheduling of time buffers (Have regularly recurring dates, e.g., trade fairs, been taken into account in resource planning?)

• Fixing of substitute arrangements (Is there a plan B if someone drops out?)

• Visualization of coordinated planning, e.g., by posting on project boards

• If possible, use a single IT tool that covers planning, management, and control of the project.

5 As-Is Analysis

5.1 Classic Versus Accelerated Approach

Knowing the problem is more important than finding the solution, because the exact representation of the problem automatically leads to the correct solution (Einstein, German physicist).

Time pressure in the project, (over-)motivated team members as well as actionism can lead to questions about the added value of an as-is analysis. Even in case that the task confronts the project team with a completely new project challenge, an as-is analysis should not be dispensed with in order to build on existing knowledge within and outside the company. In order to obtain a comprehensive picture of the initial situation as well as the adjacent interfaces, a logistics audit can be used, which consists of several components (see Fig. 2.11).

Fig. 2.11

Elements of a logistics audit

Depending on the task at hand, this modular structure allows certain modules to be dispensed with or the need for analysis to be reduced to a minimum at selected points. For example, it is often not necessary to subject the logistics strategy to a detailed analysis as part of every logistics project. Rather, in many cases, it should be sufficient to check the extent to which the project affects the (existing) logistics strategy or is consistent with it.

In the next step, a catalog of questions is developed for each building block within the responsible project team, which then has to be completed step by step, e.g., for “logistics organization and personnel” the following analysis points could be of importance (cf. Fig. 2.12).

Fig. 2.12

Excerpt from the questionnaire for the logistics personnel and organization module. (project example)

The classic procedure means that the responsible project team member collects, analyzes, and prepares the data in addition to his daily business until the project jour-fixe. Such a procedure can lead to time delays for a variety of reasons (lack of prioritization, contact person not available, …), but as a rule really looks to be time-consuming. Against this background, some companies have started accelerating the as-is analysis by temporarily releasing the project members from their line functions, at least for the as-is analysis phase. Instead, they devote almost 100% of their time to the project content, in particular to recording, evaluating, and interpreting the fixed analysis points of the logistics modules.

This approach is used more frequently, especially in logistics projects with external support. Some logistics consultancies have adapted to this and now offer, for example, “5-days’ audits,” “SCM audits,” or so-called “logistics check.” From the point of view of the parties involved (clients, consultancies), the advantage is that the project quickly gains momentum and results can be expected at an early stage (which in turn should have a motivational effect). The problem is delay in obtaining data is likely to have an immediate impact on the schedule and that in practice—especially for logistics specialists—there is often little time available to completely withdraw from day-to-day business for a longer period of time (several days to a week).

5.2 Notes on Recording and Interpreting Key Figures

The essential basis of an as-is analysis is working with key figures. Particularly in logistics, facts and circumstances can be recorded very well and thus the guiding principle of “If you can’t measure it, you can’t manage it” can be realized in a meaningful way. These are quantitative values that illustrate conditions and future developments in a condensed form and help to objectify and visualize results and facts and enable comparisons between complete companies and company divisions (e.g., logistics) or periods under consideration. In the case of internal comparisons, key figures can be used to compare different company divisions or periods. These are used for the representation of the actual state, observations over a certain period of time and for the preparation of forecasts as well as for the evaluation in the context of target-performance comparisons. Key figures are used to measure, grade, compare, prove, and analyze. Key figures not only take on the task of measuring the overall success of logistics, but these also serve as a decision-making tool. In this context, KPIs can be seen as a performance barometer of logistics strengths and weaknesses and form an important information and decision-making basis in many tasks of planning, managing, and controlling logistics projects.

In practice, however, it is not so much of a problem to achieve acceptance for working with key figures, but rather problems arise in correctly dealing with them. This will be discussed in more detail below using the classic key figure “logistics costs.” In numerous projects, it represents an essential variable for consideration, be it related to a business unit, a process, a product, a service, or even a cross-company logistics chain. The complexity of logistics costs is already evident in the necessary definition of the term (Weber & Wallenburg, 2010, pp. 180–189).

While the problem with this indicator may lie in its collection (keyword: confidentiality), indicators collected during the course of the project usually pose further challenges which should be clarified. For example, in projects to increase delivery service, it is often found that the seemingly self-explanatory key figure “number of complaints” already subsumes very different contents, which in turn can lead to misunderstandings in the project work. Uncertainties can arise, for example, with regard to:

• Does this key figure includes only complaints recorded in the Customer Care Center, or “all complaints”?

• Do internal complaints also count as “complaints” in the sense of the key figure?

• What is the objective of the key figure, the lowest possible values (=“high customer satisfaction”) or the highest possible values (=“suggestions for improvement”)?

• Are all complaints recorded or only those with a certain relevance?

• …

For this reason, it is crucial, especially when new key figures are developed as part of logistics projects, to define them clearly in order to avoid misunderstandings in the project team and to ensure that the key figures collected can also be used in the later course of the project (usually beyond the as-is analysis). The following five aspects should be considered when collecting key figures:

• 1. Content of the key figure: what facts are to be recorded?

• 2. Delimitation of the key figure: what does the key figure consider, what is not included?

• 3. Objective and benefit of the key figure: what is the purpose of collecting key figures? What is the added value for the logistics project?

• 4. Mode of key figure collection: who should collect the key figure, how often, and on the basis of which data sources?

• 5. Reporting and visualization of the key figure: to whom should the collected key figure values be communicated and visualized, how often, and in what form?

Figure 2.13 illustrates these dimensions of KPI collection using a concrete example (“truck utilization rate”).

Fig. 2.13

Dimensions of a key figure dimension. (example “truck utilization rate”)

5.2.1 Selected Analysis Tools

• (a) ABC-XYZ analysis for classification of goods.

Already 1951 the ABC analysis was presented in the context of a contribution of H. Ford Dickie and used in General Electric. With reference to the Pareto principle (so-called “80/20 rule”) it serves for the classification of large data sets and is used not only in logistics but other functional areas also. In terms of logistics, it involves differentiating goods (procurement, production, or sales objects) into three classes. A goal is it to separate the substantial from the non-essential, to direct the activities with emphasis on the range of high economic importance elements (e.g., A Category-parts) and at the same time to lower the expenditure in the remaining ranges by simplification of measures (e.g., by an automated replenishment control). The ABC analysis can be represented in a tabulated or graphic with the help of the Lorenz curve (see Fig. 2.14). A relatively flat Lorenz curve is present, e.g., with the wholesale and retail trade, while a steep Lorenz curve is present with technical products and/or the manufacturing industry. The more the Lorenz curve is bent upwards, the more sensible it is to treat the parts differently.

Fig. 2.14

Forms of presentation of the ABC analysis

Depending on the classification, the following recommendations for action are made on the procurement side:

• A. Category goods

  • Accurate determination of demand

  • Accurate inventory management and monitoring

  • Intensive market observation

  • Conclusion of framework agreements

  • Intensive supplier management

• B. Category goods

  • Differentiated approach

• C. Category goods

  • Generally past-oriented determination of requirements

  • Yield eater” due to relatively high fixed order costs

  • Automation of replenishment

  • Desktop Purchasing

Even though the ABC analysis is widely used in practice, its graphical results regularly highlight a need for action. For example, it is determined in procurement logistics that many of the suppliers supply items but each supplier only accounts for an order volume of less than €1000 per year. For example, the former Corporate Vice President for Purchasing and Sustainability at Siemens, Barbara Kux, stated in an interview: “There are many suppliers, some of whom make less than €100 in sales with us per year. But that’s not the way we can go into the future as a group with sales of well over €70 billion. We want to work with fewer partners, which gives advantage for both sides: The supplier gets more orders, and we can purchase larger quantities more cost-effectively” (Welt online, 2009).

Another added value in logistics results from the combination of ABC analysis and XYZ analysis. In the context of the XYZ analysis the consumption steadiness of objects of consideration is determined (X—regular consumption, Y—fluctuating consumption, Z—sporadic consumption). The basis of the classification is the coefficient of variation V, which is calculated from the standard deviation and the mean value:

$$ \left[\begin{array}{l}V=\frac{S}{\mu}\\ {}\mu =\frac{1}{T}{\sum}_{t=1}^T{y}_t\\ {}S=\sqrt{\frac{1}{T}{\sum}_{t=1}^T{\left({y}_t-\mu \right)}^2}\end{array}\right] $$

If the results of the ABC analysis are combined with those of the XYZ analysis, recommendations for action for logistics can be derived on the basis of a 9-field matrix with regard to planning procedures, degree of automation, safety stock, order quantities, and procurement strategies (for exercises, see Hartel, 2012). In particular the derivative of procurement strategies (production-synchronous procurement, single procurement, stock procurement) takes place frequently on this basis (see Fig. 2.15):

Fig. 2.15

Derivation of supply strategies according to ABC-/XYZ-positioning

The differentiation of procurement strategies with the help of an ABC/XYZ analysis appears to be meaningful as an analytical instrument, especially since it holds against the partially spread error belief that Just in Time/Just in Sequence represents the most effective form of procurement. This statement is only tenable for AX and AY goods. In the other cases, the use (fewer existence, lower process costs) stands against too high additional expenditure (planning, controlling, and coordination).

• (b) Dead stock analysis

Similar to the ABC/XYZ analysis, the dead stock analysis also aims at optimizing the inventory level, primarily to avoid unnecessary capital commitment. It is used to check the actuality of the defined safety stock. In the method, the stock of an item is considered over a certain period of time and this is then compared with the safety stock (cf. Fig. 2.16).

Fig. 2.16

Dead-stock analysis

The dead-stock represents the lowest actual stock level (minimum stock) during the period under consideration (usually at least 1 year). Three optimization gaps can be identified from the comparison between actual stock, safety stock, and average stock:

• Gap 1: Difference between minimum stock in period t and fixed safety stock

• Gap 2: Difference between average inventory in time period t and fixed safety stock level

• Gap 3: Difference between actual stock level (“today”) and fixed safety stock level

Multiplying the respective gap by the part price per unit results in the savings potential in terms of inventory value. Gap 1 does not lead to any restriction in terms of delivery capability due to the adjustment of the inventory level to the safety stock. If, on the other hand, Gap 1 is negative, the cause must be analyzed and, if necessary, the safety stock level adjusted upwards.

The sediment analysis is an instrument for reducing excessive inventories in the short term. It supports the analysis but does not in itself provide any information about the underlying causes for the possibly excessive inventory level (inventories are an indicator, not the cause of problems).

• (c) Sankey diagram and quantity-path diagram for visualization of material flows

The Sankey diagram (named after the Irishman Matthew Henry Phineas Riall Sankey) is a simple and clear representation for visualizing material flow relationships. It takes into account the sequence of logistics units, regardless of their actual spatial arrangement. It provides an overall view of complex material flow relationships in the production flow, and maps the main material flow streams, and shows the material flow strengths (frequencies) by the width of the connecting lines (see Fig. 2.17). The disadvantages of the Sankey diagram, are not being able to represent a spatial arrangement and not being able to show a distance. In the case of numerous and possibly intersecting material flows, this representation quickly becomes confusing; this confusion can also be an expression of inefficient material flows.

Fig. 2.17

Sankey diagram. (Sankey Diagrams, 2008)

• (d) Process flow diagram for visualization of information flows

Various forms of visualization can be used as a basis for process analysis. In addition to value stream mapping (see Sect. 3.2.2.3), flow charts and process flow diagrams are most commonly used (see Fig. 2.18). The process flow diagram (also called the Swimlane model) is based on the flow diagram. The flow chart is extended by the involved parties in a chronological sequence. Departments, persons, IT systems, customers, or suppliers can be represented as process participants. The process flow diagram can be used to represent parallel tasks in processes. It describes which task is carried out by whom and when. It also describes the dependencies between the tasks. The advantage in the process flow diagram is better documentation of typical complex, interdepartmental business processes. These are based on the generally accepted standard symbols and, in contrast to flowcharts, additionally represent a distribution of roles (Becker, 2018, p. 146 f.).

Fig. 2.18

Process flow diagram. (Becker, 2018, p. 146)

In order to illustrate the effects of complexity in information flows, a spaghetti diagram can also be used instead of the process flow diagram, which graphically depicts the information flows along the organizational structure in a manner analogous to the quantity path diagram (cf. Fig. 2.19).

Fig. 2.19

Process flow (“spaghetti plot”) through the organizational plan. (project example)

Both the process flow diagram and the spaghetti diagram are intended to highlight the problem of interfaces; as these occur frequently within logistics as it is a cross-sectional function.

• (e) SWOT analysis

The SWOT analysis is more than a simple analysis, as it usually combines several analysis results. SWOT stands for Strengths (S), Weaknesses (W), Opportunities (O), and Threats (T). SWOT analysis can be used to determine whether a company’s strengths and weaknesses are suitable for dealing with the opportunities and threats of the corporate environment.

While portfolio analysis is not necessarily composed of an internal and an external component, the SWOT analysis aims precisely at contrasting the company’s internal view (S and W) with the -external view (O and T) in order to identify whether the current corporate strategy matches the market-driven environmental factors. The (internal) strengths and weaknesses are to be considered here as relative variables, namely in relation to the respective competitors.

Along with the BCG matrix (Boston Consulting Group), the SWOT analysis represents one of the most popular strategic analytical tools, as it attempts to relate internal and external factors in a manner that meets company-specific needs. Its use is appropriate not only for questions of corporate planning or strategy but also for the question of the right positioning of logistics and logistics services. The SWOT analysis differentiates between strengths, weaknesses, opportunities, and threats:

Strengths: Strengths are relative factors that lead to competitive advantages over the competition. These include resources, capabilities, or potential. Typical questions are:

• What are we good at?

• What are we better at than the competition?

• Why are we better than the competition?

• Why do customers choose our services and products?

• Do we have something unique (USP)?

Weaknesses: These are the counterpart to strengths. Weakness means that one has deficits internally and externally compared to the competition. The issues correspond to those of the strengths, but with the signs reversed.

Opportunities: This refers to current or emerging market conditions that promote demand for a product or service. Typical questions are, for example:

• Are there trends in the market that are emerging positively?

• What is the market potential today?

• Which new target groups are emerging?

Risks: Risks not only affect logistics in one’s own company but also industry-specific factors or general, negative framework conditions. Examples in logistics can be: Lack of perception of the importance of logistics, low willingness to pay for logistics value-added services, weaknesses in the logistics image in society, shortage of skilled workers in logistics, …

In this context, it is important to clearly differentiate between strengths/weaknesses on one hand and opportunities/risks on the other. Figure 2.20 shows the matrix at the beginning of a project from which strategic recommendations for action can be developed and subsequently evaluated.

Fig. 2.20

SWOT analysis. (project example “Introduction lean”)

However, the SWOT analysis does not end with the comparison of results of the company analysis (or project in the narrower sense) with those of the environmental analysis (also: internal project environment). In the next step, suitable strategies should be derived for the four possible cases (SO, ST, WO, WT) and stored in the target concept with packages of measures.

6 Target Concept

At the heart of a logistics project is the development of a target concept that is either intended to improve or completely replace the existing situation or involves the creation of something new (“greenfield”). In both cases, there is a “problem” to be solved, this is the reason this project phase exerts a strong influence on the achievement of the project objective. The target concept is essentially determined by three parameters:

• Level of the initial situation in one’s own company (location).

• Gathering and evaluation of knowledge from logistics projects outside own company (location)

• Experience and creativity of the project manager and his team

Analogous to the explanations in the chapter “As-is analysis,” starting points of a target concept design will be presented in the following. Following a presentation of selected principles of optimization (Sect. 2.6.1), WO methods of selecting alternative solutions (Sect. 2.6.2) and possibilities of organizational design within this phase (Sect. 2.6.3) are explained.

6.1 Principles of Redesign

In numerous projects, the Toyota Production System (TPS) and the lean management approach on which it is based can be used as a guiding principle for optimization (Ohno, 1988). The TPS was developed and applied in the automotive industry (originally at Toyota, in Europe at the beginning of the 1990s initially at Porsche), but has now also been implemented in other industries (e.g., Siemens Production System, SYNCHRO at Trumpf Werkzeugmaschinen, Lean-House at Schnellecke Logistics, Kühne+Nagel Production System). At the end of the 1940s, Toyota was in crisis: American competition was dominant, domestic demand in Japan was too low, and there were not enough units for efficient mass production. With limited financial resources, 15% of the workforce laid off but the remaining 85% given lifetime job guarantees, there was no investment for a second press line. In search of new solutions, plant manager Ohno and the later Toyota president Elji Toyoda visited American plants in 1956, where they discovered that the Taylorist principle of division of labor seemed suitable for American mass production, but was not very suitable for Japanese high-variant series production.

On one hand, the TPS aims toward “operational excellence” in that committed employees and lean processes lead to highest quality and customer satisfaction; on the other hand, it is intended to help avoid any kind of waste. Seven types of waste can be identified, with “overproduction” being considered the biggest problem, as it generally results in the six other types of waste (see Fig. 2.21).

Fig. 2.21

Seven types of waste

These types of waste (“muda”) can be used as anchors in the identification of optimization potential, as these can be directly or at least indirectly transferred to logistics:

Transfer of the Seven Types of Waste to Logistics

• Overproduction → Overdelivery

• Waiting time → Waiting time

• Process overfulfillment → Process overfulfillment, e.g., too early delivery, unnecessary additional services

• Transport → (internal) transports, e.g., detours or empty runs

• Rework → process errors

• Inventory → stock

• Movement → handling steps, e.g., repackaging

Lean means that you are never really finished because you are never really lean. Nevertheless, an ideal state (the “True North Dream Castle”) should be aimed for in the project, but this is never achieved:

• 100% value creation

• 100% delivery fulfillment

• Zero decfects

• One Piece Flow

Since logistics is characterized by its process orientation in accordance with its orientation to value chains, it makes sense to fall back on the principles of process optimization as part of the target concept design. As a component of the so-called magic triangle of time, costs, and quality, time plays a significant role as a success factor in logistics and should therefore be improved. The ten optimization approaches of process design according to Thonemann can be used as a preliminary consideration in the development and evaluation of a target concept (cf. Fig. 2.22).

Fig. 2.22

Principles of lead-time reduction. (Thonemann, 2010, p. 149)

Although Thonemann’s presentation originates from the field of operations management, it in many cases can be suitably used for the development of solution approaches in logistics projects, despite or even because of its general validity.

6.2 Selection of Alternatives

It is not always possible for all ideas that have been developed into concrete proposals for solutions to be implemented as part of the project work. There could be various reasons, such as:

• Logically mutually exclusive alternatives, e.g.: Should the warehouse management software be implemented by vendor A or vendor B?

• Limited budget, e.g.: Should investment first be made in the development of special load carriers for products A or B?

• Time pressure for realization, which prevents the implementation of several solutions, e.g.: Should the picking paths in the warehouse be redesigned or should a new racking system be purchased instead?

In the following, therefore, two methods frequently used in practice are presented, with the help of which an evaluation and selection of alternative solution paths is made.

• (a) Calculation of business cases

The question of whether it makes sense to initiate a logistics project is already answered in the course of the project charter or, in the case of larger projects, with the help of a preliminary study. Even at this early stage, a business case should examine whether it makes business sense to pursue a logistics project or not; after all, a project also represents an investment, even if no external costs are to be incurred. However, the methodology is also useful in the context of target conceptualization, in which various solution concepts are available for decision. With its help, the evaluated benefits, costs and, in some cases, risks are compared for one (as a basis for comparison with the actual situation) or more scenarios in such a way that the observer (project team or steering committee) can make a decision (for information on creating a business case in text form, see for example Schmidt and Ritter 2010 a, b, c, d. Since these are usually strategic issues, the alternatives are often presented using a timeline, especially if the payback is greater than 1 year. Conceptually, business cases do not say anything about the basis on which the benefits are calculated in a project (e.g., introduction of new warehouse management software): Business cases can be determined using cost comparison, profit comparison, or amortization calculation methods. Qualitative aspects (impact on employee satisfaction, attitude of the works council, etc.) are usually addressed in the business case, but play only a secondary role in the assessment. When developing business case, the following components should be taken into account:

• Task, Objectives, and Management Summary

• Scope of investigation

• Affected cost, revenue, and earnings items

• Monetary effects

• Non-monetary effects, e.g., risks, image, etc.

• Comparison of the effects, also in comparison to alternatives

• Recommendations for action and presentation to decision-makers

In a narrower sense, and in order to avoid redundancies with other aspects of project management, only the aspect of monetary effects (profitability analysis) will be discussed here. Figure 2.23 presents business case for the evaluation of a CRM software implementation.

Fig. 2.23

Profitability calculation as part of a business case. (project example “CRM implementation”)

Tips for Effective Business Case Consideration

• Record and document framework conditions, assumptions made, and data sources.

• Clearly describe alternatives (do not rely on the fact that everyone understands the same aspect by the option).

• As a guideline, also present the alternative “continuation of the current state.”

• Discount values for the future

• Clearly differentiate between internal and external costs

• Present best cases and worst cases in terms of sensitivity

• (b) Utility analysis

If qualitative criteria are of major importance in the evaluation of a scenario, or if it is not possible to assess its benefits solely on the basis of quantifiable criteria, utility analysis (synonym: scoring model, utility analysis,) can be used. In contrast to one-dimensional methods such as cost or profit comparison, utility analysis is able to take into account both quantitative (e.g., labor costs per employee hour) and qualitative assessment criteria (e.g., interfaces). The origin of utility value analysis is not clearly known, but since the end of the 1960s, utility value analysis became known through various studies, especially from the USA. In Germany, it was taken up in the early 1970s. The objective of the utility value analysis is selection of a solution alternative based on the fulfillment of certain requirements with the highest overall utility value, since it assumes an intended maximization of the benefits of the parties concerned.

Utility analysis is intended to systematically support the selection of “right” solutions during the target concept phase. It is apparently an objective procedure but is actually based on subjective individual or group opinions, which are cumulated and thus objectified. Its use appears to be appropriate only if, on one hand, the possible alternatives are mutually exclusive and, on the other hand, non-quantifiable selection criteria have to be taken into account.

Among other things, the allocation of partial benefits for qualitative evaluation criteria such as “infrastructure” or “subsidy opportunities” proves to be a problem. Here, an attempt should be made to create auxiliary key figures for these criteria, such as “distance kilometers to the nearest freeway,” “number of airports within a radius of 150 km,” etc. for the infrastructure factor. Subsequently, individual partial benefits can be directly assigned to these auxiliary criteria. If, however, there are no quantifiable auxiliary criteria, 10 points are to be assigned (for a possible part worth between one and five points) for “very good fulfillment of requirements” to 1 point for “insufficient fulfillment of requirements.” In the final step, the part worth per alternative is multiplied by the criteria weights, the weighted part worth is added up and then the alternative with the greatest overall benefit is selected as the preferred solution (cf. Fig. 2.24).

Fig. 2.24

Conducting a utility analysis for the selection of a logistics software provider

These two tools can be used to increase the significance of total utility values: First, the values for the summed criteria weights and the maximum individual assessments per alternative should be selected so that theoretically possible total benefit is five, for example by summing the criteria weights equal to one (100%) and maximum individual assessment value five and minimum individual assessment value one. In the present example, therefore, it is possible to determine a relative result, but also to make the statement that first alternative meets the team’s requirements with 23 out of 25 points. This information, in turn, partially increases the significance of results but does not fully answer the question of whether the alternatives are really “good,” i.e., “already relatively close” to an optimal solution.

6.3 Organizational Execution

As in other project phases, an accelerated approach can be used in addition to conventional project work. The former is characterized by project team meetings and individual discussions in order to jointly find consensual solutions on this basis. The advantages of continuity, general acceptance, and low time requirements per meeting are offset by the disadvantages of this approach: increased mental set-up times per meeting, lack of efficiency, insufficient time budget for intensive discussion. For this reason, short workshops are increasingly used for concept design and implementation. These cover a period of ½ day up to a maximum of 4 days and serve the joint implementation of a problem-solving process. The workshop methodology is intended to accelerate the concept design and ensure a high identification potential among the participants.

Based on this consideration, the GENESIS methodology (Fundamental Effectiveness Improvement after Training in Lean Production, Organization and Procurement) was developed in the 1980s and has already been successfully applied by Wildemann in over 800 workshops at 148 companies (Wildemann, 1997). GENESIS is based on a tried and tested method in which solution approaches, methods and standardized procedures are offered for the short-term creation of effective and efficient structures for a defined area of investigation. The focus is on achieving a short-term increase in productivity, a sustainable reduction in throughput times and inventories, freeing up floor space, and improving quality levels. The implementation of a GENESIS workshop extends over 4 days and runs through all phases of the problem-solving process from problem identification to implementation of the measures (cf. Fig. 2.25).

Fig. 2.25

Procedure of GENESIS workshops. (Wildemann, 2002, p. 51)

7 Projektumsetzungsplanung und -umsetzung (Project Implementation)

After analysis and selection of a target concept and the consideration of possible risks, the next step is implementation planning of the project. The more detailed the implementation plan, the higher the probability that the project can be implemented successfully. The goal of implementation plan is to divide the overall task of the project into sub-tasks and work packages that are as small as possible and can be planned and controlled. One way of presenting these sub-projects is to use a work breakdown structure (WBS), as already presented in the context of project planning (Sect. 2.4.4). In logistics projects in particular, there are two challenges that must be overcome: First, a challenge often lies not only in the precise planning of implementation but also in the consideration of projects running in parallel, such as the conversion of manufacturing processes as a significant influencing factor in production logistics projects. Secondly, logistics projects often have to be implemented “under the rolling wheel,” i.e., during ongoing operations. For example, the author accompanied a project in just-in-sequence processing, in which implementation measures could only be realized at the weekend (cf. Fig. 2.26).

Fig. 2.26

Implementation planning. (project example “weekend relocation”)

Since implementation planning should be based essentially on work breakdown structure of the project planning phase in terms of methodology and is strongly influenced by the respective project assignment in terms of content, key success factors of this phase are briefly discussed here.

Success Factors of Implementation Planning and Implementation

• Early involvement of future process owners

• Think about substitute arrangements.

• Schedule external service providers (e.g., tradesmen, shelf builders) in good time to avoid delays.

• It is best to standardize implementation steps and provide those involved with simple tools (e.g., “remodeling booklets” for each activity).

• No matter how good the implementation planning is, it is not a substitute for the presence of the project manager on site during implementation.

• Do not regard training measures as a “necessary evil” but as an elementary component of successful implementation.

• Allow a time buffer for acceptance tests.

In addition to the step-by-step introduction (“ramp-up”) of a new situation described above, digital implementation can also be used as an alternative by switching directly and without delay from the actual to the target state. Examples from practice are the outsourcing of logistics processes on a fixed date or even opening of an airport or terminal on a fixed date. Although such “big bang solutions” are characterized by avoidance of redundancies, these require not only sound planning including contingency concepts but also the performance of stress tests in advance (“working under full load—Run@Rate”), both internally and at the supplier and customer interfaces.

8 Project Closure

The last phase is often neglected in logistics projects, although its importance is no less than that of the other phases. There are various reasons in practice for the shortfall of a clear project end, here count for example:

• Technical and/or personal differences between team members that could not (yet) be resolved

• Lack of capacity on the part of the project manager and/or team, as the next logistics project is already in the ramp-up phase

• Lack of interest, as one does not want an official project conclusion for less successful projects

Despite these arguments, a project also includes the implementation of a project closure in order to achieve the following results:

• Clarification of outstanding points from the project work, e.g. with regard to the adaptation of a solution to other areas, locations, business partners, in order not to delay the end of project unnecessarily

• Checking the achievement of objectives and relieving the project manager of the responsibility

• Official information about project end internally and externally

• Permanent handover of project activities from the project organization to the line organization or the future process owners

• Recording and documentation of project findings for the project participants (project manager, steering committee, project team) and for future logistics projects as well as for systematic evaluation of projects

• Release or reallocation of resources for the following logistics projects

Practical Example Contract Logistics Service Provider

Celebrating logistics project completions is rather unusual in Europe, not because logistics often involves intangible tasks that are not tangible. Infrastructure projects are the ones most likely to celebrate a successful completion, as their outcome is of tangible nature (e.g., a new warehouse). A logistics service provider plans a (smaller) budget for a completion celebration in case of new real estate construction or significant expansion, namely for the following milestones: groundbreaking, handover of keys by the investor and commissioning. While the first two milestones are of a more formal nature, the last step is celebrated in a more informal way, but usually outside regular working hours on Saturdays.

In the following, two selected project closure activities will be discussed in more detail, namely “Handover to the process owner” and “Project closure report.”

• (a) Handover to the process owner

The content of the handover of the project to the process owner usually takes the form of training and instruction, and the formal handover often takes the form of the joint completion of a handover protocol. Process owners in logistics can be specialist departments (e.g., from logistics planning to shipping or from a cross-plant startup team to production logistics employees) or business partners (e.g., in the course of outsourcing on a certain key date). The handover protocol represents the formal act of transferring responsibility. Similar to acceptance protocols in IT or construction projects, these serve to hand over the responsibility. In contrast to these, the focus is not on defects, necessary improvements or agreed reductions, but on the smooth transition to everyday operations.

Typical Components of Handover Protocols in Logistics Projects

• Brief description of the order/project

• Status of the project at handover

• List of handover documents

• Project results (layout, documentation of target processes, e.g. in the form of process instructions, training documents, …)

• Handover to the line organization (tasks-competencies-responsibilities)

• Evidence of the scope of training carried out (“Who was trained in the target concept and to what extent?”)

• If applicable, documents on changes to the organizational structure

• Open points list

• Signature fields

• (b) Project closure report and final presentation

The final report represents the project balance sheet and thus the formal conclusion of the project. It is prepared by the project team under the leadership of the project manager and presented “internally” to the project team at the end; only in rare cases in logistics are these actually formulated text documents. Since in larger projects, in addition to the steering committee, interested members of the corporate public or even external parties participate (for example, at the inauguration of a new logistics site), the report also serves to position the project positively (“project marketing”) to the outside world.

The project completion report can take the form of a (continued) one-page document, but generally also includes comprehensive information, which can be summarized in the form of a management summary (for the hurried reader).

• Project description

• Tentative and detailed project planning

• Project implementation (incl. critical reflection)

• Achievement of project objectives

• Comparison of SMART target formulation with the achieved project results (comparison of project objectives and project status)

• Deviations in time, costs, and quality in the course of the project (comparison of project planning and project implementation)

• Open points/ideas for follow-up projects

• If necessary, proposal for further procedure

Depending on the group of participants (confidentiality, involvement, previous knowledge), the final report is presented in full or only in excerpts. In its written form, it serves on one hand as a basis for an end-of-project discussion between client and project manager or project manager and team, and on the other hand as a document basis for filling a project database. In projects with external support it is common, in purely internally implemented projects rather rare, to conduct a satisfaction survey in the sense of a quality management. Here, independent third parties, e.g., quality managers of a consulting firm, ask how satisfied their client was with the project and the consultant or consulting team.