Tools for Project Management, Workshops and Consulting

A must-have compendium of essential tools and techniques

by Nicolai Andler

Third revised and considerably enlarged edition, 2016

ISBN 978-3-89578-723-2 (EPUB)

Complete EPUB edition of Nicolai Andler, Tools for Project Management, Workshops and Consulting

ISBN 978-3-89578-447-7 (Print edition)

Publicis Publishing, Erlangen, Germany

www.publicis-books.de

© 2016 Publicis Pixelpark Erlangen – eine Zweigniederlassung

der Publicis Pixelpark GmbH

1  Introduction to the concept and application of this book

1.1  Structure of this book

The book starts with a brief introduction (chapter 1) to the competence model on which this book is based, as well as the book’s particular focus: improving the methodical competence as part of an individual’s personal development. Chapter 2 explains the concept – categories of tools and techniques aligned to a problem solving process – followed by a description of how to use the book most effectively and efficiently. How to search, identify and select the appropriate tool is described in section 2.3 together with an example of a compilation of tools (‘shopping list’ to prepare a workshop). Additional scenarios of typical business situations and a suggested compilation of appropriate key activities, tools and techniques (‘shopping lists’) can be found in chapter 9. The section 2.3 ‘How to select the right tool’ also provides a selection tree (‘how to find a tool’) for further directions.

The subsequent four chapters represent the four problem solving process steps. The sub-chapters contain the relevant categories of tools and techniques. For example, ‘diagnosis’, the first problem solving process step in chapter 3 contains the three tool categories ‘define the situation’ (chapter 3.1), information gathering (chapter 3.2), and creativity (chapter 3.3) in the sub-chapters. This structure enforces process thinking along with the knowledge of which tool is most likely to be needed and used in which problem solving process step. Alternatively, the brief content section at the beginning of this book allows direct access to all categories of tools.

1.2  How to use the book

Either browse through. Look for what you know and what you still want to know more about. Several techniques might be familiar to you in some way or another. Build on this familiarity and combine old and new. If you are relatively new to this field, you might want to read it cover to cover to gain an overview of what is available. As a more experienced user, you might want to dive into those points that attract your interest – perhaps more complex techniques and new approaches. If you are looking for a specific tool, go to section 2.3 ‘How to select the right tool’.

Use this book as your toolbox. Every experienced user has his own well-developed toolbox of his personal favourite tools and techniques. This book is designed to provide you with valuable tools and information to create, develop and enhance your own toolbox over time. Be innovative, open and creative. You might find additional applications for some of the tools somewhere else or with a different objective. Take on new ideas and perspectives to enhance your portfolio of tools and please write to me (na@NicolaiAndler.com) with the new ideas and tools you have discovered so they can be included in future editions of this book.

Author’s note: I use ‘he/his’ for simplicity reasons only. Please substitute with ‘she/her’ wherever appropriate.

1.3  The target audience of this book

A large number of business people have made use of consulting work in recent years: they have either been exposed to consultants on the job, or were responsible for hiring them. At the very least, however, they would have heard of consulting work and results through somebody they know. Not often, though, is the consultant’s job really understood. We are currently in a business phase where people enquire about, even question and study at depth, the apparent ‘magic and secrets of consulting’ in order to demystify, better understand and be able to question what consultants are doing, in order to potentially do the job themselves.

A typical customer of this book is:

• A practising consultant who wants to find other tools and techniques to complement his portfolio and to have a source of reference
• An employee in an internal consulting department (the new trend!) who wants to study and learn the portfolio of tools
• A manager who wants to know more about the ‘secret consulting weapons’ and the consulting buzz-words and techniques
• An individual who wants to solve business problems himself without the use of an external consultant
• A business student who wants to learn some smart and effective tools for his (case) studies or who is interested in systems thinking or management consulting
• Hopefully lecturers and teachers who want to expand their knowledge beyond the ‘BCG matrix’ and include this approach in their lectures
• Not an absolute beginner

1.4  The scope of this book

This book is intended as a practical and simple collection of tools and techniques that are ‘ready-to-use’ without having to study for hours and plunge into the depths of theory and science.

The ‘IS – IS NOT’ tool (see figure 1 and chapter 3.1.17 for more details around the tool) defines ‘what is in and out of scope’ of this book. Most consulting books deal with the setting up and running of a consultancy – not this one! This book only deals with the tools and techniques you will need and could apply during (consulting) projects, problem solving situations, workshops, etc. Therefore, it is the toolbox for the job itself.

Figure 1  ‘In’ and ‘out of scope’ areas of this book

Two decades ago, Peter Block pointed out that ‘techniques are not enough’ in his famous book Handbook of Flawless Consulting. Although he is still right today, I am sure that knowing more of the right tools and techniques and being able to apply them does not harm either.

1.5  Skills and competencies for your personal development

The overall intention of this book is to help with your personal development, in particular enhancing your cognitive and methodical competence.

What makes up a competence? Three things influence and shape a competence:

• Talent – natural qualities, innate abilities or endowment in some field or activity or something you are born with.
• Skills – abilities you can learn, study, or acquire through training, e.g. accounting skills.
• Experience – the accumulation of knowledge or skill that results from direct participation in events or activities. It is the application of theory in the practical world and the resulting learning.

All three together – talent, skills and experience – build a competency. Human Resource and personal development professionals distinguish between four different types of competency (see figure 2).

• Functional competence – skill and knowledge in a certain subject or field, e.g. in marketing, finance, sales, engineering, combined with experience and industry related knowledge, e.g. automotive. This competency is tangible and measurable in terms of degrees and years and is normally documented on your CV.
• Interpersonal competence – typically ‘people’ skills or ‘soft’ skills, e.g. social interactions, team leadership or conflict resolution. The key concept in this area is ‘emotional intelligence’.
• Cognitive and methodological competence – the systemic knowledge and ability to apply rational analytical logic, tools, techniques, etc.
• Implementation competence – the ability to take responsibilities and implement tasks successfully.

Figure 2  Four competences of personal development – the focus is on the cognitive and methodical competency

This book focuses on the cognitive and methodological competency. In order to enhance your current repertoire, the book provides a comprehensive list of tools and techniques. Instead of just listing them in any kind of order, the approach combines a simple 4-step problem solving approach with relevant categories of tools. Each category lists the tools that are most likely to be required and needed while working through each specific process step. Figure 3 shows how the competency-model and the concept of this book relate to each other.

Figure 3  Competences and the concept of this book

1.6  Clarification on methodologies, models, tools and techniques

This book’s centres of attention are tools and techniques. I try to follow KISS (= Keep it simple, stupid). In order to free up the book of academic ballast, the underlying theories and models have not been scientifically proven. Terminology and abbreviations can sometimes be useful, but are often rather counter productive when it comes to explaining business and consulting terms to outsiders (figure 4). Consultants tend to use ‘TLA’s’ (three letter acronyms) to simplify, but also to avoid having to explain the content behind it. Ask them, if you don’t understand the business jargon! It is likely that you are not the only individual who should ask questions – even the speaker might not really know what he is talking about.

Figure 4  Underpinning for tools and techniques

I do not wish to engage in a discussion about the underpinnings of the selected tools and techniques. Theory came first and somehow, via a variety of models, structures, frameworks, etc., tools and techniques resulted. A tool or technique provides guidelines on how to apply and carry out certain tasks.

2  Problem solving approach and application

The basic concept on this book is to provide a compendium of tools and techniques typically used in a project management, consulting or workshop environment. A problem solving process is used as a framework around which all categories of tools and techniques are grouped, in order to be able to deal with all issues or problems in every domain of your business life. This book brings together tools and techniques to enhance your methodological competency while focusing on the interdisciplinary areas of strategy, organisational structure, information systems, and project management.

The underlying concept of this book is a universal problem solving process consisting of four steps (diagnosis, goal setting, analysis and decision making). This problem solving process is applicable to any type of problem and situation. Tools and techniques, which have a similar purpose, are grouped into the same category.

So, the overarching framework is the problem solving process, which is discussed in the next section (chapter 2.1). The tools and techniques ‘rank beneath’ the problem solving framework in nine different categories.

2.1  Problem solving

When solving a problem, we normally want to achieve more than just getting rid of some unacceptable situation. More often we are also trying to achieve some other more desirable state. Theoretically speaking, we’re trying to move from the problem state to the solved state (see figure 5). We do so by crossing what is called ‘the solution path’. It seems obvious that if we do not focus some of our attention on the solved state, the likelihood of attaining it is diminished. Unfortunately, the problem state is what often attracts most of our attention.

Figure 5  Problem solving and the solution path

This book enhances the ‘solution path’ by providing all the required tools for the job on hand, but this is only the preparation for the implementation. It is important to avoid falling into the analysis paralysis trap – the operational work starts with the implementation and not with the completion of the planning and analysis.

How do we typically address problems in organisations and management? We try to make them go away – quickly. But there are many options available, even though we rarely consider them. ‘There are three ways of dealing with problems: they can be resolved, solved and dissolved.

• To resolve a problem is to find a means that satisfies it well enough.
• To solve a problem is to find the optimal means.
• To dissolve a problem is to redesign the relevant system or its environment so that the problem is removed.

Dissolution requires more creativity than solution, and solution more than resolution.’ (Ziegenfuss 2002). This ‘dissolution’ refers to a more fundamental deep rooted (root cause) approach, which is in line with the approach being taken in this book and the reason for the tool category ‘creativity’.

Ultimately, the aim of problem solving is action, and solving problems requires action steps as well as investigation beforehand. That means to engage in problem solving is to search for a solution. To actually solve a problem is to implement the solution that has been found and to demonstrate that it works.

2.1.1  Different problem solving processes and approaches

Problems must be considered in terms of their linear or iterative nature. There is a certain level of linearity required in solving all problems. However, given the nature of modern science, business and society, problems are not necessarily solved in a linear fashion only. The complexity of the context in which a problem exists may require constant feedback and acknowledgement of a variety of influences simultaneously impacting on the problem. It may therefore be necessary to integrate an iterative approach or process, to maximise feedback from the environment.

There are probably hundreds of problem solving processes, but most of the approaches are very similar, regardless of the technical field of origination. Typically problem solving approaches or models vary in the number of steps and terminology, but the basic intention is mostly the one displayed in figure 6:

• What is wrong? Identify the problem.
• How should it be? Determine the ‘ideal’ situation.
• What can I do and how best to do it? Determine the preferred solution (and establish an action plan).

The picture on the right in figure 6 uses the metaphor of a journey to represent the basic problem solving approach following no. 1 to no. 4.

Figure 6  Fundamental problem solving approach

Comparison of different problem solving approaches (excursion)

The following excursion is intended to provide an overview of different problem solving approaches from different disciplines and areas although they all follow the same basic principal.

Figure 7 starts from the top with a systems engineering approach with its typical steps of problem solving followed by implementation (Haberfellner, Nagel et al, 1994). Depicted below are different approaches typically used by consulting companies. The three examples represent a combination of problem solving approaches together with project life cycle approaches. Further down are more humanistic and ‘people-orientated’ approaches typically used in psychology, therapy, counselling, change management and coaching.

2.1.2  The problem solving process used in this book

Multiple problem solving process approaches, including the typical tools from various disciplines, have been amalgamated into the one used in this book and highlighted by the grey shaded process step boxes in figure 7. This means the approach includes tools, e.g. from counselling, in the change management section and in the goal setting section; or coaching tools in the decision making sections; IT and business analysis tools in the systems analysis section, etc. In addition, elements of a humanistic problem solving approach were combined with a systems engineering approach and merged into the specific problem solving process used in this book.

Figure 7  Overview of different problem solving approaches

As displayed in figure 8, there are four basic problem solving process steps. It is important to understand the different purposes of each of the steps to become familiar with the underlying logic of why a certain category is associated with a specific process step. The following section defines the four problem solving process steps and their purposes.

Figure 8  The book’s problem solving process that displays the iterative aspect of the process

1. Diagnosis – Understand the problem

Has the problem been formulated, defined and properly understood? At the outset of the problem solving process it is important to define or formulate the problem. The problem may be complex and vague. Thus, the specific problem to be addressed must be clearly understood.

During the first process step (diagnosis), the objective is to identify the problem clearly to avoid generating solutions to issues peripheral to the real problem. Considerable time and effort can otherwise be spent in addressing a particular symptom of a problem rather than the problem (root cause) itself. Thus, in the critical first step of the problem solving process, it is necessary for the problem to be properly defined and clearly understood in terms of boundaries, characteristics, functions, and limitations. The tool categories ‘information gathering’, ‘creativity’ and ‘define the situation’ empower you to do exactly that. See the introduction to chapter 3 for more details.

2. Goal setting – Determine the ideal outcome and set goals

Once the problem has been understood, diagnosed and defined, the second step (goal setting) of the problem solving process can start, during which the intended outcome is outlined and described. It is not necessary to stick to this sequence, although the quality of the goal setting will improve due to more insight derived from the previous process step. Different terms, e.g. ‘To-Be, target, blue-sky, objectives, desired state, goals, etc.’ are used to describe basically ‘where we want to go and how it should look’.

3. Analysis – Understand and analyse the situation, generate options and develop solutions

Once goals have been defined, the third step of the problem solving process can start, during which alternative solutions to the problem are generated. This stage is complete once you have generated and developed appropriate solutions and recommendations that resolve the problem and meet the expectation regarding the goals that have been set.

4. Decision making – Evaluate, prioritise and make a decision

The purpose of the fourth step of the problem solving process is to help you with all aspects of evaluating, ranking, rating, prioritising, risk evaluating and comparing in order to make a decision and to implement the best solution. The stage is complete when an appropriate solution has been selected and agreed upon.

Implementation – Establish an action plan and do it

This aspect, which seldom receives sufficient attention, consists of the implementation plan and the action steps needed to achieve the selected solution. This is a very important part of the process, often requiring a return to a previous stage and a revision of initial ideas and intentions. In completing the problem solving process it is necessary to ensure that aspects covered during the previous stages are addressed in the implementation plan. Tools associated with the preparation of recommendations, action plans, Gantt charts, and other implementation preparation are mostly covered in the project management/project governance tools section.

Although the process in figure 6 may appear to be somehow linear and sequential, any of the four steps can – or even should be – returned to and readdressed if new information or opportunities become available during a later stage, as is shown in figure 8.

Another important aspect to consider during the course of a problem solving exercise is the type of thinking that should be applied depending on the problem solving phase (see table 1). The analysis phase requires a divergent type of thinking: explore different directions for many (im)possible solutions, accept all ideas and alternatives, defer judgement or evaluation, then discuss, combine, and improve ideas, and when exhausted move to a convergent thinking style. With convergent thinking, you establish categories of alternatives, develop evaluation criteria and, avoid premature closure and keep your eyes on the objective, list strengths and weaknesses and select the best alternative or idea (this sums up the decision making process).

Table 1  Be aware of the required 'type of thinking' for the current problem solving phase (Glass, 1996, Management Masterclass, amended by author)

Problem solving process step	Type of thinking		Warning – Most common pitfalls  ☹
Diagnosis	Integrative		Taking a narrow, functional view or being too broad to generate effective responses.
Goal setting	Visionary and pragmatic		Only top-down or bottom-up thinking – no coordination and agreement between top-management and operational level on realistic objectives.
Analysis	Divergent		Starting out looking for the ONE correct answer/solution. Shooting down solutions that appear logical.
Decision making	Convergent		Allowing politics, ego and emotions rather than logic to decide the outcome. Continuing to be creative, without applying sufficient analysis and judgement.

This book is about tools and techniques. Why spend all this time on problem solving? The problem solving process is the overall framework or skeleton. Each stage of the problem solving process usually requires specific types of tools or techniques. Therefore similar tools are grouped into the same category. This category is assigned to the problem solving process step where its tools are usually required.

To provide further clarity, a symbol (figure 9) is used to indicate during which process step the tool is usually required or recommended. In the example below, the dark shade of the first box represents the first process step ‘diagnosis’.

Figure 9  Symbol for categories, this one is for the first step ‘diagnosis’

2.1.3  Mental thinking levels during problem solving

You should consider the following three (3) thinking levels and two (2) time dimensions when you are busy with problem solving. See figure 10 for the logic and sequence.

• Instrumental level – How? – What are the means?
• Functional level – What? – What is the function and task?
• Meaning/purpose level – Why? – For what purpose?

The two time dimensions are the present tense (=As-Is) and the future with the desired future state (=To-Be). Figure 10 depicts the combination of the above-listed thinking levels and time dimension as the problem solving, thinking-level model, which supports and is aligned with this book’s problem solving process. This model suggests that you and your thinking should be ‘on the right/relevant level and time dimension’ in every phase of your problem solving activities in order to apply the tools with the right mindset, attitude and understanding.

Figure 10  The problem solving thinking levels overlap with the problem solving process steps (Source: Haberfellner)

Figure 10 shows three of the four problem solving steps in the three different shades of grey. During problem solving, you would typically run through the depicted six process steps spread over the three levels and two time dimensions.

This concept is similar to the tool See Logical and functional system modelling, which is based on a very similar logic and is typically used for system modelling and as a creativity technique.

2.1.4  Problem solving process and consulting process

We cannot discuss the problem solving process without also exploring the consulting process and its relevance. After all, the book was originally intended as a toolbox for consultants, however I never talked about a consulting process. To keep it generic, the whole concept is focused on the problem solving process. This results in the logic question: ‘Is there a difference between problem solving and consulting process – what is different?’

The answer is ‘yes’, whilst the biggest difference is probably in the terminology and naming and not the purpose behind the processes. And I am sure there a consultants who beg to differ. Figure 11 provides an overview and shows the differences of the two processes.

Figure 11  Problem solving and consulting process – while the consulting process is linear, the problem solving process works with iterations

Consulting process

The consulting process is divided into two parts: a selling and a core consulting delivery part. The first three steps are about selling. The remaining steps comprise of the core value adding parts of the consulting delivery. In the problem solving process, there are no sales activities defined as such. Most consulting companies have a consulting approach that does not explicitly show the selling steps, but mostly the core delivery, which is often based on the following three steps. Note that different companies use different names for these steps.

1. Investigate the current state (As-Is) – also called As-Is analysis or situation assessment.
2. Analyse possible solutions options and develop a To-Be design – typical jargon used for these steps is gap analysis, To-Be, concept phase, analysis & design, solution design, solution development, analysis & development.
3. Implementation – plan and implement the solution. Also called implementation plan and realisation, delivery, execution.

Some consultancies use a logic that is close to the problem solving process and apply the distinction of ‘diagnose the present’ and ‘analyse for the future’ to their consulting approach. They call it: ‘As-Is and the To-Be concept’. Have a look at Figure 17 for more on this topic. Keep in mind that the industry typical terminology – influenced by the macro project management phases – often prescribes the naming and dictates the consulting approach. For example in the IT consulting and software development sector. The classic waterfall or system development life cycle (SDLC) merges the project management together with the ‘problem solving/consulting process’. This results in the order: analysis, design, development, test, implementation. You can see that the underpinning logic is not very different – just amended through the industry jargon, which makes it difficult to compare concepts. You can find more about that in the chapter on macro logic and micro logic cycles (chapter 2.1.6).

Application of the problem solving process within the consulting process

I see the four problem solving steps (diagnosis, goal setting, analysis, decision making) as an iteration with an increasing level of understanding for the problem and its solution – with each iteration cycle. The first ‘mini problem solving cycle’ should happen during the proposal process – as part of the consulting ‘selling’ process. A brief diagnosis and assessment of the current As-Is together with some goal clarifications helps to adjust the proposal to the clients needs. The analysis to create a To-Be concept is probably less relevant during the initial proposal step. The decision making step and its tools can however be applicable during the proposal discussions with the client, even though the solution design is still rudimentary.

It is during the following phases of the consulting process that the problem solving process is fully – and repeatedly – applied, whilst there is only one cycle run of the consulting process per project.

Note that the problem solving process does not have to be repeated. If there is an iteration, then probably with varying focus and intensity of each step.

Figure 12 shows where the problem solving and consulting process overlap in terms of wording and where they differ.

Figure 12  Problem solving versus consulting process – compare the differences and similarities

2.1.5  The author’s assumptions

Before I elaborate further on the problem solving process on which this book is based, I suggest that you explore and understand my intellectual, mental and economic approach, point of view and my resulting assumptions.

Let’s use the example of an artist and his art to illustrate the point. It is essential to understand the context, situation, epoch and socio-economic conditions of an artist to truly understand and interpret his art. Similarly, I share my intellectual, mental and economic underpinning so that you can understand my rationale for selecting specific tools and perhaps make better choices when you need to do so.

As a more business and tools-related topic, let’s use an organisation as an example to demonstrate my approach and viewpoints. What assumptions do you have regarding an organisation’s function? Simply speaking: How do you think an organisation works? You could, for example, assume the following:

• A company is like a machine: As long as the input is right, and every cog is well oiled and aligned, the right output will be created ‘automatically’ through proper planning.
• This would be a systemic approach.
• A company is like an organism: The situation, context, circumstances and needs are permanently adjusting, adapting and responding to external change. Change is the (resulting) response reaction to an externally triggered event; hence, change is not an internal pro-active initiation. Change therefore balances the external circumstances and the internal needs of groups and individuals. Measures are re-active, situational and difficult to foresee, plan and standardise. There is no one best way.
• This would be a responsive, interconnected approach.
• A company is like a political system: The politics and powers of the various interest groups dictate what happens, how the organisation is run and in which direction. Besides the formal structure, there are informal networks of interest groups and informal collaboration between groups and individuals. These connections are not congruent with the organisation’s existing structure. Decisions regarding the limited resources in an organisation are made by negotiating and bargaining, using all possible political means and measures.
• (Source: Gareth Morgan (1986) Organizational Metaphors. In: Cameron/ Green. Morgan defined a total of 8 metaphors for an organisation.)
• Normally, an individual will choose an approach and a set of tools based on his personal assumptions, understanding of his environment, and context in order to find the best match. Following the same logic, I reveal my assumptions that led to the selection of tools in this book:
• Assumptions regarding the systems engineering approach: A structured and standardised course of action (approach) helps better define and resolve any given problem. You can evoke successful results, or at least significantly increase the likelihood of such results, through proper preparation and a structured approach. This viewpoint/assumption underpins the selection of tools in the tool category ‘situation definition’. There are two sub-aspects for the systems engineering approach:
• The rational systems engineering approach: A structured mental model can reduce complexity and increase understanding with the help of tools that divide, structure, connect, group, etc. The rational systems engineering approach asks: What is the issue? What are the objectives? How can this be achieved?
• The psychological systems engineering approach: The focus is not (only) on the technical solution, but rather on the human aspect. The moment human beings are part of a system, they influence the system, the incorporated problem and solution. A momentum develops that influences the solution. The psychological systems engineering approach asks: Who has a problem? What does he want? What are his reasons for wanting this?
• The methodical approach: This approach primarily asks about the As-Is, the To-Be and the solution path. Tools and models are not the solution, but the skilled use of methods and tools can increase the quality of the resulting solution. The solution still lies with the person and not with the chosen tool. Regard this as a warning from me and not as an assumption or mental approach. You should avoid glorifying tools as the solution – they are just the means to an end.
• The critical/sceptical humanistic approach: A solution’s success never really depends on finding a brilliant technical solution, but rather depends on the ability to overcome political power struggles, personality clashes and vendettas. Hence, there is a need for tools that reveal the hidden, informal elements of an organisation so that those personal emotional expectations and obstacles can be addressed.
• Homo politicus approach: Human beings use informal networks, connections and alliances to advance their personal interests and for their own benefit, even if this is to the detriment of a project or others. Hence, there is a need for tools that identify and address such alliances and forces.

(Source: Haberfellner et al. 1994)

2.1.6  Macro logic project cycle – micro logic problem solving cycle

How is the problem solving cycle related to the project cycle?

You should always be aware that several simultaneous processes and activities are running within a project at any given time, and that each of them belongs to one of the three streams:

• Project cycle – on a macro level, the project cycle serves as a phased approach and a framework to develop, deliver and implement a solution.
• Problem solving cycle – serves to resolve the problem and find a solution.
• Technical activity cycle – contains and describes the core technical activities and tasks that shape the project and give it its characteristics, for example, a housing development project’s construction tasks, the lab research tasks in an R&D project, and the assembly tasks of an aircraft prototype project.

The technical activities define the nature of the project, whilst the two other cycle activities could be similar in the above-mentioned examples. For example, the basic tasks in a kick-off meeting (project cycle task) would be similar in all three of the examples.

Macro logic project cycle

The number of project cycle phases comprising a project is largely dependent on the type of project, its complexity and its business significance. The name of each project cycle phase is of secondary importance; these names are often dependant on the industry, company, the nature of the project, and the chosen project management methodology (e.g. PMBOK, PMI, Prince2, etc.). The default results-orientated macro project cycle phases – based on the classic waterfall logic – are:

1. Pre-study
2. Main study/specification
3. Detailed study/design
4. Build/development
5. Implementation and hand-over
6. Project closure

Alternative and more recent macro project cycle models are based on a logic according to which several cycle phases are either combined and merged, or extended through an additional phase (e.g. a pre-feasibility study), or several phases overlap – meaning they run in parallel. Another aspect to consider is the iteration of project cycle phases, often in combination with the overlapping of phases, which are iteratively repeated (e.g. Agile PM).

Micro logic project cycle

Within each project cycle, there is a set of typical re-occurring project management activities. This means that each macro project cycle contains – amongst other activities – those four micro project cycle steps. These steps are process orientated:

1. Initiation
2. Planning
3. Implementation and monitoring (incl. steering, control, communication and documentation)
4. Closure

Figure 13 shows where the micro project cycle steps partly overlap.

Figure 13  Micro logic project cycle

Source: Hagen Management GmbH, www.pm-handbuch.com

Micro logic problem solving cycle – results-orientated thinking llogic for the problem solving cycle

The micro problem solving cycle addresses the problem resolution – often as part of a bigger project. The problem solving cycle is most important and relevant during the first two or three macro project cycle phases when most problems are resolved by a standardised problem solving approach. Figure 14 gives an overview how the three cycles fit together.

Figure 14  Overview of the above-discussed micro and macro cycle

So why and how are the cycles related and relevant?