1.1 Introductory Questions

The following questions are written in certification test style. They will provide you with an understanding of the contents of the following sections and the questions that are discussed within the text. Answer these questions before you read the section and then again once you have finished it to discover what you have learned. This Introductory Questions section appears at the beginning of each chapter of this book.

1.2 The Purpose of This Book

This book is intended to support project managers to meet one of the most difficult tasks that they may face: Coping with changing requirements on the practices they implement and the results that they need to create with their teams. The word “practice” is used here for the application of specific approaches, tools, techniques, behaviors, and procedures with the intention to guide action and bring about desired results. Results can include any types of deliverables, such as products, services, knowledge, or any kind of enablement that the project is required to deliver. Most project managers have experienced during their profession that the same practice that has led to success in one situation can cause failure in another. Many articles on project management, as well as books, papers, lectures, and other sources, nevertheless promote so-called “best practices”, a modern term for “cooking recipes” or “magic potions”, assuming that one practice has been found and tested, and selling it as proven to fit all situations. Organizations also often commonly implement “best practices” as an element of their internal methodologies. Project managers also commonly tell their colleagues that they should use a specific practice XYZ because it was so successful in their project and they feel certain that it will be successful in other situations as well. Even organizations communicate from time to time that they have converted all their projects to a certain method, ignoring that this method may be a great approach for one project but inappropriate for another one.

A basic problem for project managers and for the organizations that are sponsoring these projects is the lack of understanding of how project situations can be different and what practices can be expected to be beneficial or detrimental. This understanding will be the focus of this book.

Most project managers are aware that they have to adapt their practices to their specific projects, and even during the course of the project, they may have to adjust these practices from time to time to changing situations and conditions. Projects are rollercoasters rather than smooth rides, and when project managers believe that they are perfectly sorted out for managing a great undertaking, some surprising events will remind them of the basic uncertainty that comes with any project. The understanding that practices in project management must fit situational demands is not new, but no help has been given to project managers so far to assess situations and base the selection of practices on the results of these assessments. Giving such help consists of two aspects: increasing the understanding of project managers on what types of projects and project situations commonly occur and giving hints for the favorable or detrimental effects that can be expected from the application of certain practices in these situations.

A project is like an exploratory journey, where each step forward creates new knowledge for the travelers, replacing uncertainty with certainty, risks with problems, and forecasts with actuals. While the journey starts with the need to make assumptions and base decisions on them, it ends with the opportunity to make assessments of what the decisions yielded. Figure 1-1 shows the development from uncertainty to certainty.

The book is partially based on a small Situational Project Management (SitPM) research project conducted during 2014 and 2015 with a group of 17 field experts. It is further based on the experience and observations collected during over 12 years practicing project management and over 20 years working as a trainer, most of the time with a focus on preparation seminars for the Project Management Professional (PMP^®) certification in classroom environments. An interesting characteristic of these seminars, which deal with the diverse aspects of project management and the challenges to the organizations and people involved, is the cross-cutting view on the variability of project situations: the project managers who attend the classes come from different industries and business environments and have different personal experiences. A trainer may make a statement that is perfectly valid for one participant, but may not suit the professional setting of another one. When these differences become obvious, and when the trainer and students start digging deeper, the underlying differences become discernible and open for discussion. The statement “one size does not fit all” may sound banal and stereotyped, but it should nevertheless be a guiding principle for project managers and field experts.

How do experience and learned knowledge relate? Having actively practiced project management is important for any professional in the discipline—project management cannot simply be learned at a school and then applied. Practical experience helps one gain familiarity and awareness with the tools and techniques commonly used in project management and to understand their value. This personal contact with the discipline is important, but it can never be complete and will never suffice to understand and master all eventualities found in the complex environment in which project managers perform their jobs. For example, some projects are run as internal projects, which means that they are cost centers for the performing organizations that run them for their own purposes. Other projects are performed for paying customers under contract and constitute profit centers for the performing organization, the contractor. The experiences that project managers collect in either of these two types of projects are significantly different.

Most (not all) project managers in internal projects are in a weak position because their projects do not provide income. The projects’ deliverables may do this later, but the projects themselves do not, and they are not performed against contractual requirements with paying customers. The requirements are instead put in place by internal requesters, which may be functional departments or major programs to which several projects contribute. Most project managers in customer projects are more powerful inside their own organization and have a better reputation. They champion the survival of the organization by producing a stream of income and must, at the same time, ensure that the organization does not run into a breach of contract situation with the project customer. Project managers often have no personal experience in both types of projects; their professional history is dealing solely with either customer projects or internal ones. Project managers running internal projects mostly consider themselves agents of change in organizational, technical, or other areas. Project managers in customer projects manage an existing business relationship (at least an important element of this relationship) and have to consider the often conflicting business interests of two parties: customer and contractor.

Project managers who wish to develop a full and professional understanding of project management have to add observation, empathy, and insight to their own experiences for project situations that they have not gone through thus far. Project managers may benefit from such a widened understanding beyond the limitations of their own experience. Different situations may turn up in the future, and it can be helpful for project managers to be prepared for them. Another reason to look over the fence between the two types of projects is the common need for cooperation: Customer projects on the contractor side often work for internal projects organized on the customer side, and problems on either side of the fence may impact the project on the other side.

The example of the two types of projects, internal and customer projects, will be discussed in more detail in Chapters 2 and 3, along with other types of projects. This book will recommend a project typology that may help project managers better understand and implement the situational needs on the practices that they apply.

1.3 A Primer on Project Management

Project management is an organizational discipline. Its importance in business, scientific research, arts, and politics has significantly increased over the last couple of decades. It is a discipline that focuses on one-time endeavors of a generally temporary and unique nature, in contrast to the operations discipline, which—in this understanding—pays attention to ongoing and repetitive activities. Along with the uniqueness of projects as complex endeavors comes uniqueness of the results of each project, which may be products, services, or other kinds of results. As stated previously, this uniqueness differs from operational activities, which are the ongoing daily business of most organizations that produce a recurring stream of identical or similar deliverables by numbers, often vast numbers. This stream allows the organization to develop repetitive routines, automation, and optimization. Operations can exploit scaling effects—assuming that the more items of a product or service that are produced, the less expensive the individual item or service will be for the manufacturer or service provider. Operations also have different learning curves, following the common experience that things that have been done repeatedly will be done in a more effective and efficient mode compared with things that are done for the first time. Another benefit of operations is that they are much less susceptible to personal issues of the people involved. For example, a lovesick streetcar operator will probably still be able to transport people safely along the tracks because most routine tasks do not require as much reflection, planning, and attention.

Projects, by definition, create results that are to some degree new and unique, and optimization and scaling are rarely an option. Personal issues can damage projects heavily, and conflicts among individuals or teams can make it impossible to be successful. Because of the rapidly changing environment of technology, economy, and society, organizations need to rely on effective project management as much as on efficient operations. Efficient operations help them develop predictability and order, whereas projects help them develop and implement new ideas, technologies, and forms of organizations, transforming their structures in a way necessary to meet future requirements. Project management also helps organizations comply with ever-changing regulatory requirements and exploit new opportunities for income.

While some projects are business-case driven and are performed to meet goals and objectives of the organizations, others are necessary to comply with law and other mandatory requirements. For example, from 2003 to 2005, corporations listed on US stock exchanges had to become compliant with the US Sarbanes-Oxley (SOX) Act. This law was enacted in 2002 after a series of fraud scandals in public corporations. It was designed to protect shareholders of corporations and required substantial investments by organizations listed on US stock exchanges. New systems had to be put in place to ensure that information given to shareholders was accurate, audited, and up to date, and they had to meet tight deadlines. Corporations listed on US stock exchanges had no choice but to run their SOX projects to meet strict legal requirements. Some companies used this occasion to create additional value from the projects that they needed to run. Some teams utilized this opportunity to renew aging systems and fix errors that had been resolved with wasteful workarounds. They replaced provisional arrangements—considered temporary when they were set up—with up-to-date solutions, increasing effectiveness and efficiency. These teams added business value to their projects, but the original intention to run these projects was not business value but a legal requirement—in essence, the sheer need of the organization to survive and the understandable wish of top managers to not have to go to jail, which was the final threat used by the US legislation to enforce the measures.

Mandatory projects are not rare at all: Companies all around the world have to meet laws for environmental friendliness, protection of personal data, financial transparency, protection of workers and consumers, and more, and the costs of these mandatory projects are enormous, while they may not yield any financial benefit to the mandating organization.

Voluntary or mandatory, projects are investments, and project managers are the administrators of these investments. The investments may be made to fulfill the interests of the organization and its investors, which is mostly true for internal projects and capital projects, or for the interests of other organizations under contract, mostly for paying customers.

Projects are temporary by nature. This may mean that a project has a clear starting point and also a clear end, but in real life, these moments are often blurred. Operations are also temporary; nothing lasts forever, but they are rarely intended to be temporary. Operations will try to run a business as long as possible, and the moment to finish it is rarely linked with the achievement of certain goals, but rather with wear and decay of resources, outdating of deliverables, changing requirements in the environment, insolvency of the performing organization, and similar factors. A central task of operations managers is to make their tasks and themselves indispensable. Project managers, in contrast, are expected to achieve specific goals and objectives, disband their team(s), finish the project, and thus make themselves redundant and free for the next project. Another major difference between project management and operations management is budgeting. Most operations managers have fiscal budgets that span the duration of a business year of the organization, and a short time before the end of a business year (or sometimes after it), the budget for the next business year is agreed upon between the manager and the organization. A small number of project managers also have to run their projects based on fiscal budgets. This can be a major problem because most projects must book resources early in advance, vendors must be taken under long-term contracts, and internal work packages must be assigned to business units of the organization. These assignments constitute longstanding commitments with financial impacts, and budgets are necessary in order to make these commitments. Projects rarely adhere to business or fiscal years; they may span two or more business years, and even a short project may be started in one fiscal year and finished in the next. A project manager who has to work based on a fiscal year budget would have difficulties entering commitments beyond the limitations of the current budget. The person would have to wait for the next fiscal year budget before resources could be booked and work ordered. While the person is still waiting for the budget to be approved, the resources may have been booked by someone else and the contractor or internal provider may have agreed to other assignments. Project managers often do not have a budget to manage at all; if they have one, it is a lifecycle budget that spans the intended duration of the project. Whereas project managers have no budget responsibility, the project budget will be managed by a functional manager, who mandates, supervises, and finances the project, a role often called the “Project Sponsor”.

The interaction of projects with their organizational, social, economic, and environmental context is highly complex. While project managers are active agents of change and administer investments that increase the adaptability of organizations and their ability to innovate, at the same time, projects and the environments in which they are performed are also subject to change. Many requirements, objectives, and constraints that were valid at the onset of the project may not be valid when the project comes to an end, while others may have emerged during the course of the project, as business situations, intentions, and interests may have changed and as management strategies and approaches may have been adjusted. Other drivers of change during project lifecycles may be alterations of standards and laws as well as technical interfaces of items to which the project and its deliverables need to connect. Structures of organizations and people involved may also undergo changes while the project is run, often in an unpredictable way, sometimes benefiting the project, sometimes not. Another aspect of complexity is the ongoing interaction with so-called “stakeholders”, persons, groups of people, and organizations who are potentially influenced by the project, intentionally or not, and may in turn influence the project. Stakeholders are those persons, groups, organizations, or entire states who need attention and who can demand implementation of certain changes on the project and its outcomes. While project management has long been considered an engineering discipline, skills such as identifying stakeholders and their needs, aligning the project to these needs, and engaging stakeholders (as far as this is possible) to actively support the project are commonly not considered technical. They are non-quantitative by nature and require interpersonal and organizational competencies. Looking at the interest that project managers take in stakeholder orientation, one can identify two types of project managers (in a wider sense):

Project engineers, who focus on the technical and functional aspects of a project, the “whats” and “hows” of the project; and project managers (in a more narrow sense) who also consider questions such as “With whom” and “For whom”. The latter apply active stakeholder orientation in their projects.

Another facet of project management is that each project is a new learning process. The learning may include technical and economic aspects, as well as organizational and interpersonal ones. The learning process can include all stakeholders involved, including, of course, the project manager and a project management team, and good project managers stay prepared for lifelong learning. They build their professionalism on observations, knowledge, and experience that they have obtained in the past, but are prepared for the yet unchartered waters of future experiences, whose cruising still lies ahead of them.

1.4 Project Management Today

Project management is undergoing dramatic change, and while we are experiencing the process, no one can say for sure where it will lead the profession. Some examples of what can be observed are discussed in the following sections.

1.5 How We Are Seen by Others

Most know the following situation quite well. A project manager is driving in the car on a freeway headed for an important meeting, important enough that the person must be there on time, and there is not much time left. The person is driving fast, possibly a bit too fast, then he or she notices a sign for a road construction site ahead and a traffic jam before the site. While the person is slowing down, what will go through his or her mind? Will the person think, “Hey great, they are making best use of tax payers’ money” or, “They are removing last winter’s pot holes; the freeway will become wider, faster, safer, and more comfortable to drive. I am looking forward to the time when they will be finished, and I can drive here again!”? Rather unlikely, and it is probably appropriate to avoid using the words that most people would use in such a situation. Road construction workers often see people who are angry and are making inappropriate gestures, and some even report that they have seen drivers pointing a gun at them.

As a motorist on a freeway, or any other road, a project manager becomes part of operations just like any other driver; road operations, of course. Supporting vehicles to travel from one place to another is an ongoing and repetitive business. Road constructions are temporary and unique endeavors, or projects. Even the most passionate project managers often forget that the people managing the sites are essentially their colleagues. Road construction may be a Greenfield project, building a new road in a virgin area, and most will love to see it progress and will look forward to the opening. Most road constructions, however, are Brownfield projects; they are largely put up inside existing infrastructure and will disrupt existing road operations. The number of lanes is reduced and the remaining ones are narrowed. Drivers have to reduce speed and may even have to stop from time to time. If a car breaks down or an accident occurs in a road work area, there will be no shoulders and no emergency lane to park the car out of the traffic. The bottleneck character of a construction site on traffic commonly creates jams, and the proximity to big trucks in neighboring lanes may even terrify some drivers. In addition, road constructions are preferred locations for speed traps. A road construction site is a typical example of an operational disruption caused by a project.

Most organizations are not set up for projects since their business focus is operational. This applies to some degree even to project managers on customer projects: Their own organization may have a business focus on projects, but the customer does not. Maybe it is the customer of the customer who is operational, if you work at a subcontractor organization, for example (see Figure 1-7). This may be the location where the subcontractor has to do the majority of the work. Internal projects, as much as those done by a supply network, are perceived by the operational requester or customer as much as disruptions of their business as motorists feel troubled by construction sites.

Most organizations are highly optimized for operations; they are doing the same business over and over again and generate income with ongoing productions and services. At first glance, the repetitive character of their business may not be observable because modern configuration management has made these repetitive undertakings highly adaptive and personalized to the needs of customers, but once one looks at the core activities of these activities, they are basically repetitive. Managers of modern automotive companies often proudly state that their company does not make two identical cars on any given day. While this statement may be true, it does not say that each car is unique; only the configuration of a standard car that is unique. The basic car remains a standard car, a mass product made by numbers.

The practitioners and pundits in project management are rather considered disruptive aliens in this world, comparable to those people working on road constructions on freeways. In these organizations, operational managers bring money home, not project managers, and while operations creates an environment of predictability and order, projects generally bring uncertainty, restrictions, and disruption—this is at least the perception of most operational people. Many project managers regard themselves as heroes, but in the opinion of operations managers, their reputation may be much less valued. A production manager at a major German automotive company described this perception to me some time ago by saying: “If our production people would do as badly in meeting deadlines as our project managers, the company would have run out of business long ago”.

This reputation problem may get even worse. Some years ago, I was confronted with a crisis that some of my training students had. Their project needed the support of employees of a customer organization—a major government agency—to implement human resource management (HRM) software in the agency. The project people, employed by the contractor, needed to understand the processes applied by the customer in order to customize the standard software that should be implemented and adapt it to the peculiarities of the agency. By that time, they were facing a lot of resistance inside the organization. Employees did not have to fear losing their jobs, as they were guaranteed that the software implementation would not lead to layoffs. However, their domains of influence would change and, to some degree, possibly their working environment. Some of them would possibly be transferred to other departments or assigned to other tasks, but the employer had ensured them in writing that no one would be demoted or paid less in the new position. Employees were nevertheless afraid of the changes. Many had developed their offices to their own little paradises over the years, decorated with ceiling-high plants and orderly framed children’s paintings, and they felt so familiar in their intimate spheres of influence, they perceived any change as a threat to their comfort zone. The more they gave away their knowledge to the project team, they felt, the more they risked losing their homely and cozy environment. Resistance to the project was not open, it consisted of little disruptions here and there, and it was often difficult to impossible to identify the sources of these disruptions. As a result, the project could not continue for a long time, and even managers of the agency were not able to help. They felt that they could not make decisions against their employees, since their success was based on the employees’ work. Another frontier of resistance was complaints. The project managers were accused of not being respectful and considerate enough toward the agency’s employees and their lifetime achievements. The project finally succeeded, but it took much more time and money than originally expected. Major parts of the project were run under fixed-price contract; therefore, the contractor finished the project at a financial loss and with resources tied up for months that could have been more profitably used in other projects.

The example shows how, on top of the operational perception of disruptions, another reputation marauder may make life difficult for project managers: resistance of stakeholders to change, even if they will not suffer any kind of objective loss.

Project managers are aware of their contribution to organizations and to society in general: Without modern road construction, for example, roads would generally still have one narrow lane in each direction and would be winding around hills and pass through neighborhoods that they quickly bypass today. They would have more holes than a piece of Swiss Emmental cheese, and they would be unable to cope with the numbers of cars using them today. If there are notorious traffic problems at many places, this is rarely due to road construction, but to a lack of it, such as when sufficient public money and political will are not available and are needed to keep road systems in shape and capable of accommodating growing traffic. In the previous example of the government agency, many employees learned at the end that their new offices were much nicer and their new areas of influence were more satisfying than the old ones, and it led to an unexpected bit of additional quality of life. But this could not reduce the financial loss made by the contractor.

Project managers should be aware of their contribution to organizations and society: Without a constant stream of results from research and development projects, without the improvements that our projects bring to organizations, but also without our efforts in demolition and renaturation of facilities that have become obsolete, most of the organizations that rely so heavily on the effectiveness and efficiency of their operations would no longer exist.

1.6 The Complex Dynamics of Success and Failure

San Francisco has three major bridges: the Golden Gate Bridge leading from San Francisco to the North and the Bay Bridge (or, officially: the San Francisco-Oakland Bay Bridge), which is actually two bridges to the East: The first stretches from the city to Yerba Buena Island and the second from the island farther on to Oakland. The three bridges were all built between 1933 and 1937 and have a similar length (2,700 meters or 9,000 feet for the Golden Gate Bridge, 3,000 meters or 10,000 feet for each section of the Bay Bridge). They also had a similar price tag ($35 million for the Golden Gate Bridge, $77 million for the two Bay Bridge sections combined). In September 2013, a modern replacement for the Eastern section of the Bay Bridge was finished, and traffic was diverted to the new bridge. The replacement was necessary because of provisionally repaired damages by a 1989 earthquake and because of fears that a much stronger future earthquake might completely destroy the bridge. New construction was chosen as an economically more viable solution than reinforcing the bridge and substituting weak components with stronger ones, and the old bridge was simply considered “ugly” by too many people.

It would be an unthinkable sacrilege to replace the Golden Gate Bridge. It is regarded as an engineering icon of the United States and was labeled as the most frequently photographed bridge in the world. The American Society of Civil Engineers listed it among the Seven Wonders of the Modern World^*, and 10 million visitors every year will probably agree with this statement. With only minor damages, it resisted the earthquake of 1989, the one that had heavily damaged the Bay Bridge, but in order to make it also withstand a more disastrous earthquake, a retrofitting project was initiated in 1997, which was expected to take more than 20 years to finish. Care was taken that the shape and beauty of the bridge were not impacted by the reinforcements. This retrofitting project was a clear case of a project success in the classical architectural values of durability, convenience, and beauty^†; in addition, it was finished under (final) budget and ahead of schedule. It is hard to deny that the bridge project was a success, something one may call a “Wow project”.

There is one exception, however. Joseph Baerman Strauss, the project manager of the bridge, had a project objective which was innovative at that time: “Zero workers killed”. The rule in the 1930s for high steel construction projects was one fatality for each million dollars spent. Strauss made sure that site workers wore hard hats and followed the safety regulations he imposed. In addition, he strung a safety net under the construction site, an invention that saved 19 workers’ lives; those workers later established a club called “Halfway to Hell”. In two accidents, however, the net did not help: One worker was killed by a falling derrick arm, and 10 were killed when a travelling platform, on which they were working, fell down and ripped the net. A death toll of 11 people in a project worth $35 million was a very good record for the time of the bridge’s construction, but the project objective of zero fatalities during construction was not achieved.

Success and failure in projects seem easy to judge at first glance, but they are not. The problems begin with the definition of what makes a project successful and what is regarded as a failure. Different people may have diverse views, and over time, their opinions may change. There are of course projects that are just pure failures, sometimes called Zombie projects. They should never have been initiated because they had no chance to succeed from the start. Many other projects run into disaster unnecessarily; they would deliver their results if they were managed properly and if they had received the support and attention from the key stakeholders that they needed. Some projects fail because of poor project management or are impeded by team members with insufficient technical, organizational, or interpersonal skills. Projects may fail due to over-organization or under-organization. No doubt, some projects are 100% failures. Then, there are projects that are mixtures of successes and failures, which probably constitute a majority of projects. If the perception of success is stronger than the judgment of failure, one may then call the project successful. A difficulty here may be that different stakeholders may have different perceptions of success and failure. A close relative of one of the 11 dead workers of the Golden Gate Bridge project may have considered success and failure of the project differently from a person who just happily attended the opening celebrations or from the commuters who used it daily as part of their normal way to work.

Can there be projects that are nothing but successes? They are as unlikely as sports teams that win all their matches during a league season; even the best team will normally play a tie game or lose a match from time to time. Perfect seasons do exist. The Miami Dolphins had a “perfect season” in 1972. They finished 17-0-0, but this was unique in 95 years of US National Football League (NFL) history. A perfect project is probably as rare as that season. Success in this understanding is not the absence of failure, but the prevalence of successes over failures in the perception and judgment of a majority of relevant stakeholders. Projects without at least a grain of failure may not exist at all.

It may be a good idea to accept a certain degree of errors and failures as normal in project management, as long as no human life or other similarly valuable things are in danger, and as long as the center of gravity is on the success side. Such an approach reduces the pressure on the teams and allows stakeholders involved to learn positive lessons from them.

1.7 Standardization and Certification in Project Management

Standardization is a generally difficult topic in project management. An essential aspect of projects is their uniqueness. It is common in projects that teams do work that they have not done before and may possibly never do again when the task is finished. This aspect limits the portion of project management that is open for standardization. On the other hand, standards can help project managers and their working environments to better understand their tasks, be better prepared for recurring problems, and be able to avoid expensive misunderstandings. There are generally two types of standards in use for project management: prescriptive and descriptive. There are several prescriptive standards, one may also call them “cooking recipes”, for project management, such as:

• PRINCE2 from the United Kingdom

• V-Modell XT, a standard mostly used for public projects in Germany

• Hermes, which serves a similar purpose in Switzerland

Agile methods such as Scrum, the Crystal family of methods, or Six Sigma (a group of project management methods used in quality management), are prescriptive standards for project management. They allow for some freedom in the specific application, just like a cook who has run out of a certain ingredient may replace it with another, similar ingredient, but would still be considered in general observance with the original recipe. Prescriptive standards tell project managers and their teams what they have to do and in what order. This contrasts with non-prescriptive, but descriptive standards such as the Project Management Body of Knowledge (PMBOK^®) Guide, by PMI^®, the Project Management Institute; the British BS 6079 series of standards; and the German DIN 69901 series of standards. There is also a global ISO 21500 standard, which builds bridges between these three standards. To stay in the metaphor, descriptive standards are not cooking recipes, but instead describe what a professional project chef should be competent with and explain what equipment is needed or will at least be helpful in the project kitchen.

Why would a project manager want a standard for his or her work? The benefit is unification of terminology. (The traps that come with confused terminology are discussed in the following section.) Another benefit is that one has a widely accepted reference. If the project manager considers it appropriate to have a project charter^*, a written mandate for the project, there is a reference that describes what it is, which makes it easier to insist on such a document and to ensure that different people mean the same document or practice.

The most comprehensive and widely used of these standards is the PMBOK^® Guide^†, and as a project manager, one should become familiar with it. The PMBOK^® Guide gives a project manager a degree of firmness in terminology and eases communications and decision making. One should also consider getting certified by an organization or company that is associated with the standardization, such as the PMBOK^® Guide. Project managers sometimes state that they get treated with more respect in their organization since they obtained certification, but this does not actually make them better project managers. Project managers should consider learning a lifelong and continuous process, and the preparation for a certification can be a valuable part of this process, which should not finish once the exam has been passed. As a baseline, knowing a standard and being certified can be helpful, but one should not stop at this point.

1.8 Terminology Traps

The term “stakeholder” is a good example of a word that is commonly used but often leads to confusion, because people use different interpretations of who the stakeholders are in a project. I actually observed four different definitions:

1.9 Navigating between Monsters

Antique mythologies are a treasure full of pearls of wisdom that can help project managers improve their understanding of situations they are facing and develop situational approaches to mastering them. An example can be found in Homer’s Odyssey, where Odysseus, the hero, king of Ithaca Island, has to pass a narrow strait between two monsters called Scylla and Charybdis. Scylla is a flying monster with six heads that threatens to capture half a dozen of his men, one for each head, and eat them alive. On the other side of the strait is Charybdis, a maelstrom monster, which swallows huge amounts of water from the ocean three times a day and then spits it back into the sea. Avoiding one monster would bring Odysseus’s ship too near to the other. His crew had to row the ship along the strait between the monsters. But he followed the advice to keep this ship nearer to the side of Scylla than to that of Charybdis because Scylla threatened to take only six men while Charybdis would destroy the entire boat with all men. While the ship passed the strait, the crew had to row the ship as fast as they could, to not become victims of both monsters.

Similar maneuvers are common in project management. The stakes may not be as high as for old Odysseus, but the principle applies:

• Project managers must often choose between heroism and collaboration. There are tasks that are best done without too much consideration and possibly alone, getting things done while others are still discussing the objections. Other tasks require interpersonal and organizational skills, and active and patient listening may then be more favorable than getting things done quickly.

• Some projects necessitate long-term planning and booking of resources on a granular level. Others may suffer from the inflexibility and lack of adaptability and agility that comes with long planning horizons and high granularity. The project manager and the team have invested a lot of time and energy into the plan, and every approved change request becomes a major challenge for re-planning and re-booking. Both over- and under-planning are true monsters, and project managers have to find their way between them, and as in the myth, it may from time to time be better to do more planning or less.

• When project teams develop new products or services, they are often tempted to run fast and overlook important issues. Then they may not have enough time to thoroughly test their deliverables and fix errors found. In their high-speed approach they may also consider 95% finished deliverables completed, ignoring that the remaining five percent may drive the project and its stakeholders into crisis. Other teams may be highly diligent and drive their deliverables to absolute perfection, but miss deadlines with this approach or launch the product or service at a time when a market window has closed and customers are no longer interested. Too fast and too slow are both monsters between which most projects must navigate.

• A project manager may decide that for a given task a highly expensive solution is the most appropriate one, and that the investment in this solution will pay itself back during the project or after it has ended. If the project manager does this too often, the project may at one time run over budget and in the worst case may need to be terminated. Another project manager may instead choose the least expensive solutions available, thus protecting the project from overruns. This approach may lead to results that the customer or an internal requester will not accept, or to problems that may turn up much later and diminish the success of the project for its stakeholders. Project managers have to make many decisions considering the two risks of being “too expensive” and “not good enough”.

• Project managers should always stand for realism. Realism is a place between two extremes: easy and panic. Both standpoints have their justification in organizations, and most companies have experts for them. Salespeople are mostly optimists, and it is part of their profession to transfer the expectation of easiness and comfort to customers and also inside the organization. On the panic side are experts in worker protection, data security, quality management, fire prevention, and more. They must be perfect pessimists and picture worst-case scenarios for everything they assess. Project managers should place themselves between the two extremes. They should build their plans based on expectations and assumptions that they consider likely and realistic, being aware that things may be found later that are easier or more difficult, inexpensive or more expensive, faster or slower, and so on.

• Project managers are forced to find a balance between the two types of action: proaction and reaction. Proactive approaches are implemented through forecasts, plans, commitments, and agreements. Reactive approaches are characterized by responses to situations, improvisation, workarounds, error fixing, and decisions in states of emergencies. Proaction can reduce the costs of projects, improve the availability of qualified resources, and gain trust by stakeholders. It can also collide with the need for agility in changing environments and with the appropriate management of unpredicted events and conditions.

• While project managers are commonly expected to develop a performing chain of direction, they often have to report to their team and to lead their sponsors and other supervisors. This may sound counter-intuitive, but even project managers who have a good understanding of technical matters or other special knowledge in the application area of the project must rely on the skills of their team members to ensure informed decision making. A typical aspect of complex projects is their cross-functional, cross-organizational, and even cross-industrial setup, and projects stretching over countries and cultures are also common. Decisions made by individuals who are most knowledgeable in the various domains may trump traditional hierarchical command and control structures. It may, in turn, also be necessary for a project manager to teach the sponsor and other high-level managers, as they may lack an in-depth understanding of project management. Given the many egos that need to be considered, reconciliation of top-down and bottom-up decision chains are hard to achieve, but this ability may be a key factor for project success.

• Another fundamental conflict is whether we manage by emotions or by reason. Emotions include fear, anger, and moods. A statement in a discussion, “You are so emotional”, is rarely meant to be flattering. Emotions can also include passion, team spirit, loyalty, and other sentiments that are generally supportive to projects. Emotions are inevitable to projects, as the brain processes emotions first, and reason second. We often notice that angry or disappointed people are unable to develop empathy for the point of view of others. Empathy is probably the highest ability of human reason, but when emotions block higher brain functions, reason may not guide human behavior. Project managers have to balance both emotion and reason and try to steer them in a way that is protective for both the project and its stakeholders^*.

Navigating between two monsters is a difficult task, especially given the many stakeholders around, who paint the threats of one monster in vivid colors while ignoring the other one. Project management includes much balancing between extremes, and the situationally perfect balance may be different from project to project and even from one project situation to another during the course of the same project; therefore, it is difficult to define best practices that can be expected to be suitable for all of them. I will discuss best practices in the following chapter in more detail and provide recommendations for a link of favorable practices with project types. Coping with the dynamic nature of projects requires a high degree of situational intelligence and adaptiveness from all participants, but mostly from the project manager.

^* Numbers taken from statista.com.

* Some work has been done on the differences in how closed-skill and open-skill athletes prepare for their events (Highlen & Bennett, 1983).

* While these lines are written in September 2015, the project schedule has been delayed by one year to have the negotiations finished by the end of 2015 and the agreement ratified by all parties in 2017.

^† These lines are not intended as a contribution to a political discussion but as an assessment of the risks that projects run into when stakeholders are ignored or when project managers assume that they can decide who is a stakeholder and who is not.

* See (Gates, 2007).

* (ASCE—American Society of Civil Engineers, 1996).

^† The Vitruvian virtues of Utilitas, Firmitas, Venustas (Vitruvius, ~15 BC).

* This term is used in the PMBOK^® Guide and in ISO 21500. BS 6079 calls it “project brief”. DIN 69901 calls it “project order” (Projektauftrag).

^† PMBOK^® Guide: The Guide to the Project Management Body of Knowledge (PMI, 2013).

* To add a little reality check on this expectation: Making a big number of people lose their money during gambling is the primary business model of any casino or game hall. If one simply looks at the big facilities that these corporations hold in places such as Las Vegas, Macao, Monte Carlo, and others, and considers both the investment and the running costs that they incur, losses of gamblers must be a very effective source of income.

^† Please see the Glossary for the definition of terms used in this book.

^‡ (Boyle & Mayes, 2012).

* (BSI, 2000, p. 12).

* (PMI, 1996, pp. 15–17)

^† (PMI, 2013, pp. 30, 563)

^‡ (Calleam Consulting Ltd, 2008, p. 6).

* When I am leading teams, I generally have a rule that praise is communicated in public, but criticism in private, to broaden the emotions that drive the project and to limit the effect of those that restrain it.