The complete project manager E-Book

Roel Wessels

• Herausgeber: Van Haren Publishing
• Kategorie: Bildung
• Sprache: Englisch
• Veröffentlichungsjahr: 2019

Seitenzahl: 478

Beschreibung

This book is about the how of project management and about how you as a project manager can use a proactive attitude to stay in control, even during difficult situations. It shows you how to become an influencer of the path to the end result, of your environment, of your team and of your effectiveness. Today’s project managers have to meet high expectations. Challenging goals, a strong focus on cost management and lead times, serving the interests of different stakeholders and many dependencies between subprojects make project management an increasingly complex affair – especially in an environment where change and uncertainty have become the new norm. In addition, the creative abilities of knowledge workers have to be optimally utilised, which requires less hierarchical organisational structures and more multidisciplinary collaboration. Having the right project management skills is therefore essential at virtually every level of an organisation. As a result of these challenges, there is a growing demand for comprehensive methods and the popularity of Agile is on the rise. On the other hand, the increased complexity also results in a need for simplicity. That is what this book is about: going back to the basics, being able to combine useful elements from different methods and focusing on the most important aspect of all: the person behind the project manager! This book contains a wealth of practical descriptions with useful examples and anecdotes. Readers are constantly stimulated to internalise the essence and put it into practice in a manner that suits their own style and personality. That is the only way to keep at it, be successful and make others believe in you! The book consists of three parts. Part 1 (chapters 1 to 4) describes how to set up and manage a project. The focus is on the basic principles, the essence of taking control, creating structure and using Agile behavior. Part 2 (chapters 5 and 6) explains how to draw up a plan and schedule in small steps, which results in improved completeness, coordination and support. Finally, part 3 (chapters 7 to 10) covers how to manage the project execution: how to realize the path to the final goal with a strict PDCA rhythm, how to evaluate the quality of interim results and how to keep your team and environment motivated.

Leseprobe

THE COMPLETE PROJECT MANAGER

Other publications by Van Haren Publishing

Van Haren Publishing (VHP) specializes in titles on Best Practices, methods and standards within four domains:

- IT and IT Management

- Architecture (Enterprise and IT)

- Business Management and

- Project Management

Van Haren Publishing is also publishing on behalf of leading organizations and companies: ASLBiSL Foundation, BRMI, CA, Centre Henri Tudor, Gaming Works, IACCM, IAOP, IFDC, Innovation Value Institute, IPMA-NL, ITSqc, NAF, KNVI, PMI-NL, PON, The Open Group, The SOX Institute.

Topics are (per domain):

IT and IT Management

ABC of ICT

ASL®

CATS CM®

CMMI®

COBIT®

e-CF

ISO/IEC 20000

ISO/IEC 27001/27002

ISPL

IT4IT®

IT-CMFTM

IT Service CMM

ITIL®

MOF

MSF

SABSA

SAF

SIAMTM

TRIM

VeriSMTM

Enterprise Architecture

ArchiMate®

GEA®

Novius Architectuur

Methode

TOGAF®

Business Management

BABOK®Guide

BiSL® and BiSL® Next

BRMBOKTM

BTF

EFQM

eSCM

IACCM

ISA-95

ISO 9000/9001

OPBOK

SixSigma

SOX

SqEME®

Project Management

A4-Projectmanagement

DSDM/Atern

ICB / NCB

ISO 21500

MINCE®

M_o_R®

MSP®

P3O®

PMBOK®Guide

Praxis®

PRINCE2®

For the latest information on VHP publications, visit our website: www.vanharen.net.

The completeproject manager

The essence and application ofproject management andAgile leadership

Roel Wessels

Colophon

Title:

The complete project manager

Subtitle:

The essence and application of project management and Agile leadership

Author:

Roel Wessels

English translation:

Luc Munnekom (WordVision)

Reviewers:

Ben Bolland (BEVON Gilde)Alexander Celie (Traction10)Hans Fredriksz (IPMA-NL, Haax)Bas Könemann (You Improve)Ben van de Laar (Randstad Groep IT)Ruud Merks (ASML)Henny Portman (Hedeman Consulting)Dieter van der Put (DAF Trucks)Ron Schipper (Van Aetsveld)John Verstrepen (former director of IPMA-NL)

Text editor:

Dutch edition: Nienke van Oeveren (Boekredactie)English translation: Steve Newton

Publisher:

Van Haren Publishing, ’s-Hertogenbosch, www.vanharen.net

ISBN Hard copy:

978 94 018 0400 4

ISBN eBook pdf:

978 94 018 0401 1

ISBN eBook EPUB:

978 94 018 0402 8

Editions:

Dutch edition: First edition, first impression, August 2016English translation: First edition, first impression, July 2019

Layout and DTP:

Coco Bookmedia, Amersfoort – NL

Copyright:

© Van Haren Publishing, 2016, 2019

PRINCE2® is a registered trademark of AXELOS Limited.

Nothing from this publication may be reproduced, recorded in an automated database or published on or via any medium, either electronically, mechanically, through photocopying or any other method, without prior written permission from the publisher.

This publication was produced with the utmost care and attention. Nevertheless, the text may contain errors. The publisher and the authors are not liable for any errors and/or inaccuracies in this text.

Preface

The only thing I know is that I know nothing.

Socrates

What is a complete project manager? I cannot answer that question; only you can.

This book covers the enormous playing field of the project manager. The emphasis is on the how of project management and how adopting a proactive attitude allows you to stay in control, even during difficult situations. The book covers several themes that are made as explicit and clear as possible with the help of examples and anecdotes. These do not illustrate the only correct method; instead, they are intended to touch and inspire you. I am not for or against anything. Rather, I want you to think and make your own choices!

Even though I am interested in anything to do with project management and leadership, I have a background in product development and manufacturing. That is a world of product and service development, multidisciplinary teams, a strong emphasis on lead times, quality and costs, a focus on innovation, and collaboration with a global network of suppliers and clients. Nevertheless, this book was written first and foremost for general project managers. I received support from a group of reviewers from various fields.

Complete project managers are best characterized by the fact that they do not know everything, yet they are curious and eager to develop themselves further. The reading guide on the next page can help with that. The chapters of this book form a coherent story, yet they can also be read on their own. You can even jump straight to the section on project execution in chapter 10, because that chapter begins with a summary of the preceding chapters.

Choose your theme, dare to go your own way and become an even more complete project manager!

Contents

Introduction

1 The &-&-&-paradox

1.1 More with less

1.2 Monitoring things closely and giving plenty of space

1.3 Recognizing uncertainty and making a commitment

1.4 A project model as a support tool

1.5 Agile thinking and working

1.6 What does the &-&-&-paradox mean for project managers?

2 Your Agile inspirator, the TomTom

2.1 What you can learn from your TomTom GPS navigation system

2.2 The TomTom and Agile leadership

2.3 The TomTom and stakeholder management

2.4 Scenario creator

3 First time right: The V-model and the critical parameter

3.1 Introduction to the V-model: design, realization, verification

3.2 Understanding the impact of issues

3.3 Early feedback with Design for X

3.4 Early feedback with Agile development

3.5 The V-model and your own behavior

4 The factor 10

4.1 Smart leadership and behavior is the factor 10

4.2 Flip-thinking and the power of action

4.3 Stephen Covey’s treasury

4.4 Situational leadership

4.5 The project manager’s factor 10

5 The plan part I: project breakdown

5.1 The ten steps of making a plan

5.2 Step 1: Project charter

5.3 Step 2: Project strategy and phasing

5.4 Steps 3.1 and 3.2: Product breakdown structure

5.5 Building a roller coaster

5.6 Steps 3.3 to 3.5: Product Flow Diagram and DfX

5.7 Step 3.6: Work breakdown structure

6 The plan part II: sketch with the team and detailed plan

6.1 Step 4: Size & effort estimation

6.2 The rational and psychological sides of hour estimates

6.3 Steps 5 to 8: Drawing up the sketch with the team

6.4 Step 9: Tips & tricks for the detailed plan

6.5 Step 10: Project management plan and go

7 The project motivator

7.1 Deci and Ryan’s self-determination theory

7.2 You reap what you sow

7.3 The (temporary) project organization and the project board

7.4 Why the start requires perseverance

7.5 Directing creativity

8 Heartbeat

8.1 Progress through rhythm, cadence and trance

8.2 Projecting your plan onto the heartbeat

8.3 Heartbeat at different levels

8.4 EOS and OKR

9 The blind check

9.1 Beware of the blind check

9.2 Tackling the blind check with review and inspection techniques

9.3 Tackling the blind check with DfX and Agile project management

9.4 Testing on the right side of the V-model

10 The Final Countdown

10.1 Summarizing the path to the execution phase

10.2 Heartbeat in practice

10.3 Change management

10.4 Providing insight into status and remaining path

10.5 Making uncertainties plannable

Afterword

Acknowledgements

Appendix 1: Examples of the application of the project model

Appendix 2: The complete project manager toolkit

Bibliography

About Roel Wessels

Index

Introduction

The title of this book, The complete project manager, might appear a bit pretentious. Nevertheless, it comes straight from my heart. This book is for you. An enormous amount has been written about project management, yet most texts do not focus on the experiences and perception of the project manager: you.

There are countless books that tell you exactly what to do to successfully execute projects. They cover the ins and outs of stakeholder analysis, risk management, the importance of plan-do-check-act and what is expected of you when managing your team. However, most people are still left to find out for themselves how to apply these techniques in practice, how to be successful even in less-than-perfect conditions, how to integrate the methods in their own work processes and how to make sure they actually do so.

In this book I cover everything I have learned in the past two decades about project management and leadership in as comprehensive and practical a manner as possible. I looked for the essence, because understanding that will help you apply and integrate the methods in your own behavior. In other words, this book can teach you how to abandon your reactive behavior and become proactive and influential instead and, in particular, how to make project management fun (again) for yourself, your team and your environment.

The project manager of the 21st century

Over the past decades a lot has changed in the world of project management. The environment has become more dynamic and the expectations made of project managers have grown. They are expected to deliver results regardless of the circumstances, offer commitment despite major uncertainties, manage highly educated knowledge workers while also coaching them to act more autonomously, deal with stakeholders with different interests and encourage creative breakthroughs without taking excessive risks. In other words: project management can sometimes be a balancing act of Herculean proportions!

Managing all of this requires expertise and the ability to stay in control in any situation. It is like sailing a boat during a storm: there is no time to think and try different approaches to see what works best. You have to manage your project with conviction and decisiveness, and be optimally effective and efficient. How can you do all that?

On top of that, you will probably have noticed that the problems you struggle with and the obstacles that seem insurmountable to you are sometimes dealt with by others without them breaking a sweat. The reverse is also true. It would appear that how you manage a project is an all-important factor: applying the right methods in the right situations and demonstrating the right behavior. How can you learn to do that? Where can you find examples to follow? There are countless inspirational management and motivation techniques, but what is the best way to combine them all?

Can you still see the wood for the trees or are you caught up in the theory and do you keep promising yourself over and over again that you will do better next time?

Physicist and musician

To answer the aforementioned questions, I went in search of the essence of successful project management. I was able to make use of my years of experience as a project manager, program manager and director of product development, as well as my experience as both a physicist and a musician. The physicist in me is reflected in the focus on structuring projects, the urge to uncover the similarities between methods and the desire to simplify complicated matters. In other words, managing complexity. The musician is felt when I talk about combining constant high-level performance with letting go to facilitate the creative process, the belief that project managers should always take the initiative and therefore need to bring out the performer in themselves, and the emphasis on the importance of rhythm in projects and change processes.

I am passionate about bringing people, methods and philosophies together. The whole is greater than the sum of its parts. As you will see, the aim of this book is not to refute other methods and promise the umpteenth new path to success. Instead, I want to illustrate how methods such as PRINCE2, Agile, DSDM Atern, PMBOK Guide, PRINCE2 Agile, the ICB competence framework by IPMA and a multitude of leadership techniques can be effectively deployed together. True experts are not limited by their tools; instead, the tools enrich them. I love to combine modern Agile techniques with more traditional methods. After all, this combination of dynamics is quite common in the real world as well. That is why I prefer to talk about Agile leadership: the Agile attitude is more important than the Agile processes.

Over the past seven years, in addition to applying the methods myself, I have taught the contents of this book to more than six hundred professionals during four-day master classes. These people came from a variety of backgrounds: the high-tech sector, the public sector, the medical world, education, construction, IT and other fields. In short, this book was written for anyone who wants to hone their project management skills.

What will this book bring you?

This book contains a complete overview of how to apply project management and Agile leadership to product, service and organizational development. It is accessible for someone who wants to gain an initial understanding of the ins and outs of project management, yet its primary audience consists of advanced project leaders who are eager to take their knowledge and skills to the next level. An in-depth understanding of project management is not required, because this book covers all you need to know. Nevertheless, your existing knowledge and experience will definitely come in handy as you work through it. The book offers plenty of substantive depth, but its focus is on the interaction between the theory and your own behavior and methods. After all, it is all about the how and about actually doing it, even under less-than-perfect conditions. You will, therefore, also learn how to successfully implement the knowledge found in this book in your day-to-day work processes.

The book consists of three parts. Part 1 (chapters 1 to 4) describes how to set up and manage a project. The focus is on the basic principles, the essence of taking control, creating structure and using Agile behavior. Part 2 (chapters 5 and 6) explains how to draw up a plan and schedule in small steps, which results in improved completeness, coordination and support. Finally, part 3 (chapters 7 to 10) covers how to manage the project execution: how to realize the path to the final goal with a strict PDCA rhythm, how to evaluate the quality of interim results and how to keep your team and environment motivated.

I have sought to make this book as practical as possible by combining theory with practical application and anecdotes. Let this be a source of inspiration to you. It is important to combine the essence of what you learn with your own style and personality. Do things your way, otherwise, your chances of success will be slim and, more importantly, people will not believe you!

I hope you enjoy reading this book and putting what you learn into practice.

Project management is a lot of fun!

Roel Wessels

1The &-&-&-paradox1

How the growing demand for and-and-and turns a project manager’s life on its head.

Why focusing on control and focusing on results and processes are two different things.

The importance of being able to deal with uncertainty.

Explaining what Agile is and how it ties into traditional methods.

The central theme of this book: from reactive to proactive to influencing.

The first time I went skiing I was nearly thirty. I was the only novice in our group of friends, which meant that I was taught the basic principles together with the other rookies, while the rest of my buddies were still eating breakfast. The class was scheduled in the morning and I did not leave the beginner’s slope at all that first day. However, I caved to peer pressure on the second day and joined my friends on their run in the afternoon. They had promised to keep my lack of experience in mind.

It all went quite well at first and although I felt a bit awkward about always being the last one to come down, my positive attitude showed me that the others seemed to appreciate the little breaks I afforded them, because it gave them a chance to enjoy a smoke. However, after an hour, the group paused and some people started grumbling a bit. We had missed a turn and ended up at an expert slope. In my naivety, I looked for a way back. There wasn’t one; the only way forward was down...

My friends told me that, although the slope was steep, the snow was excellent and that I could get down the steepest sections by sliding sideways. After some hesitation, I started my descent and I did quite well, despite sweating like a pig the entire time. I slowly grew more confident and after I got past the steepest section, I actually started to feel a bit elated.

Before I knew it, I had reached the bottom. I often think back on the things I do and reflect that it wasn’t that hard after all. Looking up from below, however, a slope looks even steeper than it actually is. I felt like a king after coming down that mountain unscathed – until a far more experienced skier came racing down as if it were nothing. It made me realize that, despite everything, I still had plenty left to learn.

I often begin my lectures with this anecdote, before asking the audience the following question: “Who among you has received feedback from a professional during or after a difficult project about how to improve the project execution?” More often than not, people do not raise their hand. Instead, most people are used to hearing something along the lines of “Projects are always difficult here, better get used to it” or “Our environment is so complex that standard project management methods are no use.”

Do you receive feedback during or after a project about how to improve things?

Project managers and their environment have apparently accepted that projects do not go the way they want. They lack experts in the organization to analyze the problem and show them how to improve the situation. Worse, they may not even realize that there is room for improvement; they fail to realize that experienced skiers actually enjoy going down the expert slope and that difficult projects, e.g. those with a lot of uncertain factors or difficult stakeholders, can actually be undertaken successfully. If people have accepted that there is no need to improve matters, they often also lack the ability to learn how to improve. This in turn leads to a lack of project managers in the organization who actively look for difficult projects because they enjoy the challenge and are eager to develop themselves further.

I call these apparent contradictions that have to be overcome the &-&-&-paradox: allowing for uncertainty and being flexible and completing the project successfully and enjoying the process! Project managers who strive to improve themselves in order to tackle more and more difficult circumstances are professionals who want to break through the &-&-&-paradox.

1.1 More with less

After this anecdote, you may recognize other forms of the &-&-&-paradox in project management. I describe three of them in this chapter. Note that for now I will only focus on the challenges that they present; the solutions are covered later on in this book.

1.More with less: the project must be completed as soon as possible and it must be possible to make changes along the way and the costs have to be reduced and the functionality has to improve and…

2.Monitoring things closelyand giving your team plenty of space.

3.Recognizing uncertaintyandmaking a commitment with regards to the project’s completion date and costs.

I will cover the first challenge, more with less, in this section. The other two are covered in sections 1.2 and 1.3. By looking at more than just the project manager, it is possible to gain an insight into the environment in which the modern project manager operates. This illustrates the ways in which a project manager has to develop in order to stay successful.

Goodbye to trade-offs

The &-&-&-paradox describes situations in which choosing is not good enough. To illustrate this, I will use the example of three well-known car brands, Alfa Romeo, Volvo and Mercedes, and compare the situation of thirty years ago with that of today. A Volvo was a safe car and drivers took the boring design for granted. If you wanted design, you had to get an Alfa Romeo, although that design came at the cost of reliability. Mercedes, meanwhile, produced high-quality cars that combined reliability and design, yet customers had to pay a premium price to get one.

These days, this classic or-or-or trade-off is accepted less and less. As a result of technological developments, increased competition, globalization and collaboration between corporations, the bar is raised higher and higher. A lot of product characteristics have become standard. We are no longer willing to pay extra for quality. The same goes for extra features, safety, service level, etc. Similarly, the lead times for product development are becoming shorter and development costs have to be reduced. In other words, we have to do more with less. If you cannot meet these demands, you will fall behind: we want it all.

Do you recognize this growing demand for and-and-and?

Expertise and creativity in leadership

We also want and-and-and in projects. One might say that, in this modern day and age, a project has to overcome the devil’s triangle, which states that money, quality and time are all interconnected. Technologically speaking, that is certainly possible. Raymond Kurzweil, for example, describes an exponential pattern of technological progress that is changing our world at a breakneck pace. Ultimately, this will lead to singularity (figure 1.1). Singularity refers to the moment when technology exceeds the capacities of the human brain (Kurzweil, 1999). Focusing on the present, we see that projects and organizations have become more complex as a result of the growing demands, but also due to inherent complexity. The &-&-&-paradox therefore creates challenges for, and imposes limitations on, the project team. Is that a bad thing? A football player who manages to score despite being marked by several other players is considered a hero. Cyclists want their races to be difficult, so only the best remain at the head of the pack during the final stages of the race. When you realize that everyone faces the limitations of the &-&-&-paradox, you could also say that the person who possesses the most expertise has the highest chance of success. Expertise pays off.

Imposing limitations stimulates one’s creativity. Resolving the &-&-&-paradox calls for creative conceptual breakthroughs, because normal design improvements during product development result in a proportional increase in costs, components, etc. Smart solutions are needed, such as setting up faster systems by leaving certain aspects out, or making organizations more efficient by simplifying their structure.

Figure 1.1 The exponential growth of technological progress according to Raymond Kurzweil

Expertise has to be combined with plenty of creativity. This imposes certain requirements on employees and the (project) manager’s leadership style. The latter will have to let things go and still meet the deadlines, create structure and give the team plenty of space, and challenge employees substantively without prescribing every single detail. To do all that at the same time, the project manager has to exercise plenty of leadership.

1.2 Monitoring things closely and giving plenty of space

At the start of the financial crisis in 2007, I was leading projects as a program director at Assembléon, a high-tech company with a development department comprising more than 200 full time equivalent (FTE) employees. The financial crisis had a major impact on our sales, reducing them by more than 50%.

The company’s CEO faced the challenge of saving money however he could. This process is all about micromanagement. The CFO and he had to sign off on all expenses, regardless of the authorization rules – even those under 100 euros. The company stopped hiring new employees and every contract renewal was also vetted by him first. As a result, the company quickly got its financial situation largely under control. This was because not a single step was taken without the CEO’s knowledge, he knew exactly what was going on at all times. A real crisis calls for real measures. Even though they may impede many processes, most employees will actually want and expect such measures during difficult times.

What I remember most is that the CEO made it abundantly clear that this was a temporary state of affairs. He excelled at dealing with the second example of the &-&-&-paradox: monitoring things closely while also giving the team plenty of space. That made it easier for employees to participate and hang in there. The CEO was not micromanaging because he was a control freak; he had a clear message and wanted his staff to follow his example of critically evaluating all expenses. His motto was: “We are a mom-and-pop store once again,” which was his way of saying that everyone had to treat every source of income and every expense as if their own money was at stake. The old philosophy of “that is how we have always done things” was no longer good enough. You could only spend money you actually had and you had to know what value it would bring for the company. This measure was applied at every level of the organization.

This demonstrates the power of having a clear message, repeating it often and setting the right example yourself. As the American politician Benjamin Franklin once said: “Tell me and I forget, teach me and I may remember, involve me and I learn.”

During a real crisis, temporary measures are needed to increase control. This is a deliberate choice. Every project manager should be able to carry out crisis management. However, things go wrong if crisis management is applied when there is no actual crisis. In that case, it becomes a self-fulfilling prophesy. The crisis is caused by an excessive focus on control and accountability, in other words micromanagement.

You might say that the &-&-&-paradox of “monitoring things closely and giving plenty of space” is handled incorrectly in those situations. The focus on maintaining control becomes too strong and monitoring employees and understanding every detail becomes an obsession. This is often driven by a lack of faith in the intentions or abilities of others, or a lack of self-confidence.

Is attention to detail necessarily a bad thing? No! On the contrary, it is essential to maintain control over your project. The devil is in the detail. However, things can go wrong when it becomes an obsession and management claims an important role in all of the everyday processes. When that happens, decisions cannot be made until the (micro)manager has approved them and, if that were not enough, the manager also tends to prescribe every detail of the project execution. In other words, focusing on details is not the problem, but the micromanager who decides which details to focus on is.

The result is that employees stop taking the initiative and start performing at an average level, instead of at the top of their game. After all, they are monitored and instructed to do just that. Additionally, this obsession causes the micromanager to lose sight of the real goal, actualy achieving the project result! It is no wonder that the term “management” often has negative connotations in our society; we are simply talking about the wrong kind of management.

Focusing on control

We see evidence of the excessive focus on control and the lack of focus on results and processes in our society as well. Recent problems, such as the financial crisis and the misuse of power within major organizations, have impacted our faith and trigger our neurotic reflex to add more control measures. New Key Performance Indicators (KPIs) are being introduced left and right. We should ask ourselves whether these are intended to improve the process or monitor the executors. KPIs are indicators, yet they are often misused as targets. As a result, employees chase after KPIs instead of doing what needs to be done. In doing so, the solution actually becomes worse than the problem itself.

Here is an example from the Dutch healthcare sector. After healthcare insurance providers were criticized for a lack of benchmarking regarding the quality of healthcare organizations, they got to work to improve their processes. They opted to use a system of “practice variation,” for which the declarations of GPs and other healthcare providers is statistically compared to data from similar providers. The goal is to filter out outliers without having to consult patients’ medical information (which is prohibited under the General Data Protection Regulation). It is only after this initial filter process that healthcare providers with outliers are subjected to a more detailed study and asked to explain these deviations.

Used in that manner, this method is a means of control. Although it is possible to conduct all kinds of additional analyses with the help of data mining, it does not appear to result in better healthcare for patients. Healthcare providers are not thrilled about the measure either. They feel accused and their professional pride is hurt when they are asked to explain deviations regarding the practice variation KPI. Who can blame them? After all, there are many logical explanations other than fraud for a medical practice’s deviations from the average. In other words, it creates mistrust among the parties involved. In addition, the use of this method unsurprisingly causes healthcare providers to adapt to the monitoring method. This means the party being monitored will also focus on control instead of results, for example by planning patient care in such a way that it falls neatly within the averages. It would be better to tailor the process to the patients’ wishes in order to maximize patient satisfaction. This all but eliminates healthcare providers’ ability to innovate.

A focus on control instead of on results and processes is quite common in the public sector. It is often driven by the desire to focus on accountability. Of course, public sector organizations should be able to prove that they are spending their budget wisely, since they are using taxpayers’ money. Nevertheless, this is still a backwards perspective. It would be better to focus on finding the optimal path to the goal. That would truly be in the taxpayers’ best interest.

Defining KPIs is therefore a job that calls for systematic thinking. The creators of the Business Balanced Scorecard (BBSC), Robert Kaplan and David Norton, already warned us that choosing KPIs requires care and attention with their use of the word “balanced” (Kaplan and Norton, 1996). First, a connection has to be established between the indicators of the various perspectives (for the BBSC, those are the financial, customer, internal business processes and learning & growth perspectives) to make sure that individual KPIs actually lead to results that benefit the organization. Furthermore, KPIs must be accompanied by a complementary KPI to prevent the process from shifting too far to one side. A well-known example is the call center, for which the “first call resolution rate” is a major KPI. It indicates what percentage of incoming questions are resolved right away. However, measuring just this KPI tells you nothing about how efficiently the organization resolves its customers’ questions. Adding a complementary KPI, e.g. “call duration,” will provide valuable insight into the company’s efficiency.

Defining balanced KPIs, combined with the fact that the substantiation of KPIs can make or break people’s confidence, makes clear that compiling a good set of measuring instruments is not easy and calls for the right kind of expertise!

Diminishers and multipliers

Many people spend their entire professional life trying to find the right balance between monitoring things closely and giving the team plenty of space. There is no shame in that. The American growth guru Verne Harnish has been studying the basic principles of organizational growth for years. In his book The Rockefeller strategy (Harnish, 2002), he explains – and this should not come as a surprise – that the only way to scale up is by delegating. He adds that 96% of all businesses have fewer than ten employees, with the vast majority of these having fewer than three. The reason for this, he claims, is the fact that most entrepreneurs fail to start delegating responsibilities.

The American leadership expert Liz Wiseman presents a different perspective on this &-&-&-paradox in her book Multipliers - How the best leaders make everyone smarter (Wiseman, 2010). She describes how to bring out the genius in others and get more than twice the results. Although we will strive for a factor 10 in chapter 4, this is a great start. Based on her analysis of 150 managers, Wiseman states that organizations do not necessarily have a shortage of employees or other assets, but rather the inability to properly utilize the most valuable assets they already possess. In practice, most managers, whom she refers to as diminishers, fail to bring out the best in their employees. They exhibit behavior that curbs rather than stimulates their employees’ intelligence and creativity. On the other hand, multipliers manage to get more out of their people. Employees are willing to go to great lengths for this type of manager. Multipliers are able to uncover their employees’ hidden talents and have faith in their staff.

Even if you believe you are doing the right thing, everyone will – consciously or subconsciously – display diminisher behavior from time to time. For example, managers who have a strong drive to achieve results together might unintentionally keep others from taking charge because of their own abundant energy and enthusiasm. Wiseman calls these people accidental diminishers. Even though you may not consider her insights to be particularly ground-breaking, the five disciplines with which multipliers distinguish themselves from diminishers can certainly help you discover blind spots in your own behavior (figure 1.2). Furthermore, Wiseman states that everyone can learn to adopt multiplier behavior. There is still hope.

Figure 1.2 The five distinguishing disciplines of multiplier and diminisher behavior

1.3 Recognizing uncertainty and making a commitment

Who has ever turned down an assignment because it was too unclear? Whenever I pose this question to project managers, I get a range of different responses. Some are quite firm and claim that an unclear assignment is a poor foundation for a successful project. Others shrug and say that an unclear scope at the start of a project is to be expected in their organization. They have accepted this fact and are used to it. The third &-&-&-paradox of recognizing uncertainty and making a commitment affects many project managers. Commitment is about moving forward despite any uncertainties (while risking your personal integrity) and creating the right expectations by doing so.

Have you ever returned a project to a client?

An organization’s culture appears to be an important factor when answering this question. The response that “returning an assignment would not be appreciated” is quite common. For many organizations, returning projects is not considered to be a good thing. Nevertheless, I wonder if this is truly the case, or if people simply assume it is and therefore never try. Later in this book, we will see that nothing is ever black and white and there are ways to control these situations and exert your influence. It is all about how you return an assignment. The results are often surprising. Regardless of your own approach, it also depends on whether your client is a diminisher or a multiplier. A diminisher will view the returning of the assignment as a refusal to do the work, while a multiplier will appreciate your honesty. Know your audience!

I recall that, to me, the option to return an assignment was a true revelation. I was about to start a new project for one of my first employers. At the time, they were working hard to improve their organization’s project and quality management. One of the company’s Quality Assurance Officers, tasked with supporting project leaders with regards to quality, said: “If the client did not send you a User Requirements Specification, it makes sense to return the assignment, because you have no idea what you are supposed to do!” Although I did not return the assignment that time, I did work with the client to clearly define the project scope. Fortunately, that client responded well to my request and helped me make the assignment sufficiently concrete. Being critical and firm and not simply starting my work with an unclear project description paid off in the end. I am still thankful to that Quality Officer for the valuable life lesson he taught me.

I should note that I did eventually return a different assignment at that same company. Instead of making any changes, they simply assigned the project to someone else who accepted it without hesitation. Although this project manager showed guts, he ended up having to work very hard to keep the unfocused project execution on track. Another valuable lesson: there is no optimal way to deal with the paradox of “recognizing uncertainty and making a commitment.”

Expectations are created immediately

I believe that most project management methods have more similarities than differences. Depending on the specific field and vision, they may emphasize different aspects, but, with a little effort, they can fit together quite well. That is good, because although organizations often use different project management methodologies, this should not impede their collaboration and the management of the project as a whole.

Most project management guidelines also agree about the moment at which a project manager officially makes a commitment with regards to the required time, budget, resources, etc. Although IPMA’s International Competence Baseline is not that explicit, the global ICB4 standard states, under the plan and control competence, that this moment occurs at the conclusion of the project initiation phase, as part of the decision to fund milestone. When using PRINCE2, you make a formal commitment upon delivery of the Project Initiation Documentation at the conclusion of the initiation stage. At that moment, the project management plan is delivered and approved as if it were a contract of sorts, the project definition phase is completed and the execution phase can begin. The client and the contractor formally accept their respective obligations and responsibilities.

Traditional project management methods therefore assume that, as a result of the activities conducted during the definition phase, any uncertainties have been cleared up to such an extent that there is no more confusion about the project’s budget, lead time, etc. The project management plan has been finalized and stabilized, and it is now time to stop thinking and start doing. However, we all know that things are never that simple in practice. At the conclusion of the definition phase, there are often still significant uncertainties. These may be caused by, for example:

■ The project goal is unclear or it changes during the project.

■ There is not enough knowledge about the desired solution to plan ahead. People learn as they go during the execution phase.

■ The organization does not take the time to go through the definition process and jumps directly to the execution phase instead.

■ There is a lack of decisiveness to make choices regarding the project scope, the desired solution or the use of resources.

A project manager often has to make a commitment when it is really too early to do so. It can help to extend the definition phase, but it is likely there will still be some uncertainties left – if the client is even willing to give you this extra time to begin with. There could be a practical reason for this: the project’s end date is set, so extending the definition phase will automatically leave less time for the execution phase. If that is the case, waiting to make a commitment can seriously test the client’s patience. There may also be a political reason, for example the clients know that what they want is impossible, yet they are unwilling to admit it. That presents you with an even greater dilemma - do you play along or not?

Perhaps the importance of when you make your commitment is relative anyway; you may be able to time your commitment, but not the expectations you raise. I often talk to project managers who are upset about the fact that their client starts drawing conclusions about lead times and budgets during the definition phase, before any formal communication has taken place. That makes sense and they are technically right to feel this way. However, even though an official commitment has not been made yet, expectations are raised – consciously or subconsciously – from the very start. Although these expectations are informal, clients are not likely to care about or even realize this. If their expectations are not met, they are disappointed. Disappointed clients are less flexible and cooperative, which results in a downward spiral before the project is even underway. Surely, that is not what you want as a project manager?

A project manager, therefore, has to start managing expectations from the get-go. By definition, there will still be many uncertainties at that stage. For that reason it is crucial that project managers are able to clarify the project scope and the expected delivery moments despite all the uncertainties that still exist, regardless of whether they are formally making a commitment or informally raising expectations.

Figure 1.3 Expectations are raised long before a commitment is made

Cynefin

Uncertainties concerning your project make it difficult to make a commitment. You probably know this to be true, even though it can be quite subjective. How complex is your project, really? Is the degree of uncertainty truly so great that it is impossible to make a stable plan, or is that simply due to your own inability? How do you keep the client satisfied in the meantime? What approach is best, taking into account the complexity of your project?

You can use the Cynefin framework (Snowden, 2007) to define how complex your project is. This framework was developed by Professor Dave Snowden. Cynefin (phonetically: kih-neh-vin) is a Welsh word that means something like “multiple factors in our environment and in our experiences affect us in a way we can never fully understand.” The Cynefin framework helps to determine the degree of complexity and uncertainty of the project. Furthermore, it answers the question of which actions and types of solutions are appropriate and which are not. It is therefore also a decision-making instrument that helps you choose the optimal project approach.

Snowden divides situations and problems into four quadrants (figure 1.4). Each quadrant has its own specific steps:

1.Simple (sensecategorizerespond): the solution is known in advance and easy to plan for.

2.Complicated (senseanalyzerespond): an expert is needed to determine the right solution.

3.Complex (probesenserespond): earlier solutions are not applicable. The solution and the plan are drawn up after conducting experiments.

4.Chaotic (actsenserespond): drawing up a plan is not a top priority. First, it is important to take action and get the crisis under control. Only then will it be possible to identify the solution and make a plan.

It is interesting that Dave Snowden distinguishes between simple and complicated situations on the one hand and complex and chaotic situations on the other. For simple and complicated situations, the solution is known in advance – although simple situations can be resolved by anyone and complicated problems require an expert. In other words, the situation is predictable enough to draw up a plan and start the project execution.

This is not the case for complex and chaotic situations, because too many factors are unpredictable or changeable. Complex situations call for experiments that you can learn from; routine actions and standard solutions will not work. Rather, these situations require innovative and creative methods: try first, plan later. Chaotic situations, on the other hand, demand immediate action. There is an ongoing crisis that must be dealt with as soon as possible to restore order. Only then can work begin to determine the correct follow-up measures. Act first, before starting the definition phase.

Figure 1.4 Dave Snowden’s Cynefin framework

Personally, what I love about Snowden’s model is that it ties in seamlessly with my common sense as I make choices concerning the project approach. Simple and complicated projects are predictable and therefore plannable from the start. You should, therefore, focus on gathering the right information or the right experts, rather than on brainstorming, experimentation or other needless distractions. It is also important to develop a unified vision with the rest of the team. There are as many suppositions as there are persons involved, even for predictable projects. The definition phase is about moving ahead, communicating, making choices and not allowing yourself to be distracted until a plan has been drawn up. Just do it!

This is not the case for complex projects. As you have probably guessed, most projects that involve the development of new products or services fall into this category, as do projects that involve many people and interests, such as reorganizations and work process improvements. At the start of these projects, not enough is yet known about the right approach and solution. Depending on the degree of complexity, it may be possible to resolve some of these uncertainties during the definition phase. If the amount of uncertainty is limited and if a feasibility study (using the principle of probe, sense, respond) can provide more clarity quickly, you can bring the project down from complex to complicated before making a commitment. In other words, you make a commitment with a plan for the execution phase based on a predictable project course. However, this is not possible for projects with a higher degree of uncertainty or changeability. For these projects, the execution phase begins when a significant amount of uncertainty and changeability is still to be expected. Complex projects require more expertise and creativity from project managers, who have to deal with the &-&-&-paradox of recognizing uncertainty and making a commitment. It goes without saying that all this is especially true for projects that fall into the chaotic category.

What types of projects from the Cynefin framework have you managed in the past?

To conclude, I want to address two special circumstances that Dave Snowden touches upon with his model. Firstly, the model actually features a fifth domain: disorder. A situation is classified as disorderly when it is unclear to which of the aforementioned four quadrants it belongs. This makes for an exceptionally dangerous situation. It may be caused by, for example, a project manager who fails to seize enough control over the project. The project members will revert to their personal comfort zones and make wrong decisions because they do not tailor their methods to the problem at hand. Disorder can be recognized by remarks such as “this is how we always do things.” In this type of situation, it is important to take action immediately and leave the domain as soon as possible.

The other element is the remarkable transition from simple to chaotic. Organizations that systematically underestimate situations or changes (i.e. simplify them when they really shouldn’t) can fall into chaos. This is known as a catastrophic failure. As Snowden says: “complacency leads to failure.”

1.4 A project model as a support tool

In this and the subsequent section, I will focus on two topics that are important for what comes next in this book: a model of the project and Agile project management. The model of the project will serve as an orientation tool and mnemonic device as we introduce new concepts. Agile project management is an iterative project management approach that helps with the execution of projects that contain many uncertainties and changing objectives. I will not present Agile as the counterpart of traditional project management; instead – you’ve guessed it! – we will go for the and-and approach: Agile thinking and acting combined with traditional project management methods. You will also encounter this combination in multidisciplinary projects when mechanical (waterfall) development is combined with (Agile) software development.

The phasing of the project model

Figure 1.5 shows the project management elements that can be used to model most projects. This model is primarily intended to support the IPMA Individual Competence Baseline, but it can also be used for PRINCE2 and PMI’s PMBOK Guide. The basic goal is to provide support for understanding, rather than impose choices and push for a certain method. The model focuses on the definition phase and the execution phase. Together, these phases are often seen as “the project.” Of course, it is possible to split these phases into subphases for your own project. Because this book is mainly focused on the development of new products and services, I have coined three subphases for the execution phase: the design phase, the realization phase and the test phase.

The project model consists of two additional phases, which are usually not viewed as formal parts of the project. Firstly, there is the exploitation phase, during which the client uses the project results. This phase is generally not part of the project itself, because the project is commonly closed after the execution phase. Nevertheless, project managers should not forget about this phase, because this is the time when the client starts to use the project results and expects to realize the project goals. Furthermore, it is good to remember that most projects only become profitable from the exploitation phase onwards. The second additional phase is the preparation phase (known as the Starting Up process in PRINCE2), which we will be coming back to often in this book. The preparation phase has been deliberately separated from the definition phase. This was done because the transition to the definition phase is so important and because the activities from the preparation phase are often overlooked – even though a successful project manager can make all the difference during this important time!

The definition and execution phases, together with the preparation and exploitation phases, are known as “the project in the broadest sense.” Note that many of the parties involved will only experience the “project in the strictest sense” (the execution phase), because they are only part of the project execution or experience the effects of this phase. The project model includes three major decision-making moments:

■Decision to justify: decide whether an idea or application can be turned into a project.

■Decision to fund: decide whether the execution phase can begin. This marks an important go/no-go moment in any project.

■Acceptance: accept the project results, decide whether the project can be closed and the project team dissolved.

For your own project, you may of course add additional milestones and decision-making moments to your plan and leave out certain other elements. The project model is not a strict guideline, but rather a useful tool and frame of reference for your project.

Figure 1.5 A model of a project with phases and key decision points

The deliverables of the project model

The project model also features a number of elementary project management deliverables or (interim) results. These deliverables have been added to their respective phases in figure 1.6. A downward-facing arrow means a deliverable serves as input for its phase, while an upward-facing arrow indicates a phase’s delivered results. We will return to the deliverables many times throughout this book; for now, I will only cover the essentials needed to understand the model and the cohesion.

Figure 1.6 The project management deliverables of the project model

Preparation phase

Let’s begin with the start of the project; the moment at which the client has an idea for a project and submits a project application in order to realize the associated goals. Part of the intention of starting a project is appointing a project manager and giving him or her the appropriate mandate. Of course, the reality is not always that simple, but we will come back to that later.

Project managers in this situation could immediately start working on the project management plan, although they would miss out on an important opportunity by doing so, namely the (one-time) chance to critically evaluate the project assignment and go over it with the client. In other words, this is their chance to affect the course of the project. We will reveal how to do this in chapter 4. For now, it is important to understand that, despite its usual brevity, the project preparation phase is the perfect time to build a solid foundation for future success.

Project managers translate the project application into a project assignment (which records the initial scope) and draw up a plan of action for the definition phase. Furthermore, they critically examine the business case (which the client has often drawn up during an earlier stage) and present any improvement suggestions they may have. The project preparation phase results in a conscious decision regarding whether it is useful to turn the idea into a real project: the decision to justify. In a sales process, this moment is known as the bid/no-bid moment - will we submit an offer to the client or not? The initiation phase will begin following a positive decision.

Initiation phase

The goal of the initiation phase is to draw up a realistic project management plan that the organization supports, based on which obligations can be accepted and a commitment can be made. The information needed for this plan (e.g. specifications and feasibility studies) falls under the umbrella term of “Definition documents” in the model. We will come back to these documents in chapter 3, the V-model. The process of drawing up the plan is covered in chapters 5 and 6. The initiation phase ends with the decision to fund, which marks the start of the execution phase. We have already mentioned that the initiation phase also includes the creation of the project management plan. This means we deliberately make no distinction between an initiation phase and a planning phase as, for instance, PMI’s PMBOK Guide does. The planning activities take place during the entire initiation phase and possibly even in the execution phase, as we will learn later in this book. By not talking about a separate planning phase, integration with the Agile approach will also become more logical.

Execution phase

For the execution phase, the project model only lists generic project management deliverables for the start and completion of the phase, namely the mobilization of the team, the delivery of the project results, the client’s acceptance of the results and the project evaluation. As you know, most deliverables of the project execution phase are specific to each project. They are not part of the project model, rather they are identified when drawing up the project management plan.

Figure 1.7 Summary of the project model’s deliverables

Although this book focuses primarily on projects that result in new products or services, the project model is universally applicable – even for personal projects such as remodeling your home or hosting a party. The model shows you which type of questions you need to answer during which phase of the project, as well as what needs to be done before you take on any obligations (decision to fund). Appendix 1 contains applications of the project model for the following examples:

■ Project “developing a new website” (Cynefin complicated);

■ Project “raising the productivity of an operational process up to a predefined performance level” (Cynefin complex);

■ Project “merger of two organizations” (Cynefin complex);

■ Project “increasing employee satisfaction” (Cynefin complicated).

Finally, figure 1.7 presents a summary of all deliverables included in the project model and lists whether ownership lies mainly with the project manager or the client. Note that the owner and the executor are not necessarily the same. For example, a project manager may choose to draw up the business case for the client. In fact, doing so often presents useful opportunities to influence the project scope. However, it is important to ensure that the client feels ownership over the final business case, otherwise the project manager will be on thin ice.

1.5 Agile thinking and working

Will the project model also work in situations that are rife with uncertainties (Cynefin complex)? Yes and no. Yes, because at the client level the commonly used pattern follows the structure of the project model:

requestplan/offercontractexecutionacceptance

This more or less forces you to think and communicate in a similar manner yourself.

No, because the project model is based primarily on the waterfall model. This means that the phases are tackled one at a time, a new phase can only begin once the preceding phase has been completed entirely, and it is not encouraged to go back to a previous phase later on. That is why we will expand the project model using Agile in this section. Instead of focusing on either the waterfall model or the Agile approach, I will show you how to combine the two (Agile for one part of the project, the waterfall model for the other). After all, that is what most projects are like in practice.

The waterfall model

When following the waterfall model, you do not start working on the design until all requirements are known and you only move on to the test phase once the design has been fully realized. If you discover an error or want to make a change, you revert to the phase in question and go through the processes all over again from there. That can be troublesome in situations with a lot of uncertainties where nothing is 100% clear. Furthermore, there is a significant chance that some aspect of the specifications will change anyway, even though you have already moved on to the design phase. Waterfall in Cynefin complex projects is about waiting for clarity while you know that changes still have to be made later on…

Figure 1.8 The waterfall model

Concurrent engineering

To ease the pain, you can make use of concurrent engineering or parallel development. Concurrent engineering allows different project phases to be carried out at the same time. That means it is possible, for example, to work on the design, even though the specifications have not yet been finalized. It gives a project team the ability to make progress even in the face of uncertainties.

Truth be told, the real reason to use concurrent engineering is often to shorten the project’s lead time. The project is compressed, as it were. Although there is nothing wrong with this method, it does make the project execution more complex. After all, concurrently working on activities that should really take place one after the other requires a lot of expertise from the team members, as well as insight into each other’s activities and excellent communication.

Figure 1.9 Concurrent engineering

Agile: uncertainties are a given