2.1 Introductory Questions

2.2 A Major Distinction

Chapter 3 covers project typology that emerged in research, but is also based on personal experiences and observations. The type of project or project situation should influence the practices (approaches, tools, techniques, and behaviors) that a project manager applies to run the project. I will try to give some indication of what practice is favorable or detrimental in certain project types in this chapter.

One project distinction, however, is obvious, and its implications are fundamental enough to discuss it here upfront: the distinction between internal projects and customer projects. This differentiation is mentioned from time to time in literature, but we have not yet seen it discussed and elaborated in detail anywhere. The most basic difference is that project managers in internal projects administer cost centers, whereas the majority of their colleagues in customer projects manage profit centers in the truest meaning of the expression. In internal projects, costs occur during the course of the project, but benefits are expected to emerge after handovers, and most of the benefits, or even all of them, after the end of the project. The benefits for the contractor from a customer project come in the form of payments from the customer. It depends on the contract terms and how early payments are agreed upon and expected against the progress of the project, but they should not be too distant in the future, as the liquidity of many project vendors would not allow for them to lay out too much money. It is not uncommon for the customer to pay partially or fully in advance to ensure timely funding for the project that the contractor may not be able to complete without these funds on his or her own. In simple words: project managers in customer projects bring money home.

An internal project may be undertaken to develop a new product or service that can be launched on the marketplace as soon as it is considered sufficiently complete and mature. An internal project may also strive to reduce operational costs, and its business case calculation will consider the savings as if they were revenues. These monetary benefits for the organization will nevertheless not be earned by the project but by the business unit for which the project occurs. Many internal projects are performed without monetary considerations at all; they have to improve the organization internally or help it position itself better on the various markets. Other internal projects have no business case and no financial, organizational or strategic goal at all but must help the organization meet legal or contractual requirements. In all these cases, internal projects do not create an inflow of money into the organization but generate long-term benefits or compliance for organizational units outside the project; at least this is the expectation of the performing organization.

There are situations when the distinction seems to get blurred: Organizations define “internal customers”, who may simply be other departments, possibly located three doors down the corridor. Sometimes, the “internal vendor” and the “internal customer” even have an agreement called an “internal contract”. Similar to external customers and vendors who have a flow of goods and services to the customer and a flow of billed money back, internal customers get deliveries from internal vendors and often pay for them implementing an internal charging system. Often in such organizations, one hears statements that internal charges are costs just as external, invoiced costs are; but they are not, as Figure 2-1 shows.

In some other projects environments, when there may be a group of companies, subsidiaries under the control umbrella of a holding corporation, and one of these companies works as a contractor for another one, things can be more complicated. A common example can be found in corporations with internal IT providers and consultancies that manage projects exclusively for other member companies of the same groups to which they belong. These companies are registered as their own legal entities, and their projects formally are run under contracts; so their projects are generally considered customer projects too, but what are they really?

The core principle of a contract and the litmus test to separate it from other types of agreements is the legally binding nature of the contract: it is enforceable at court. If a customer project performed under contract is deeply troubled and in crisis, either party may seek remedy by taking legal action against the other one. Problems in internal projects, in contrast, are commonly remedied at management level; often, they are actually swept under the carpet of managers who prefer that competitors, customers, shareholders, and other stakeholders are not made aware of the failures that have happened under their supervision. Departments inside an organization cannot sue each other in court. Sometimes, departments even wage personal wars against other departments, possibly really fierce wars, but they cannot sue each other, because they are not legal entities. Then, the term “internal contract” for such settings is inaccurate, as an internal agreement cannot be enforced by legal action; it can only be escalated to higher management levels for resolution.

What about the companies under a corporate umbrella running projects for customers that are also member companies of the same corporate group of companies? They can have formal contracts with their customers, of course, but normally, a holding company will not allow them to sue each other; this would foil the strategic supremacy of the holding company over its subsidiaries. From their own company perspective, these companies will have a customer project. From a corporate view, these projects will be considered internal, because they are run under the umbrella of the corporate group. As one would expect, the group view is the dominant one; you should regard these projects as de facto internal projects. This may change when the holding corporation decides to sell one of the member companies to a new owner, who is not part of the group, but unless this happens, the projects are factually internal. Figure 2-2 explains such a situation.

Another factor that may add to confusion is the existence of customer-side project sponsors in customer projects that are managed by contractor-side project managers. The project sponsor is the person, who mandates the project manager to run a project inside the organization. If the contractor runs the project for the customer, how can the project sponsor be located on the customer side? The explanation is straightforward: in projects performed under contract, there are actually at least two projects: a customer project on the side of the contractor and an internal project on the customer side. Each of the two projects may have its own project manager and project sponsor. The document in which the mandate for a project manager is explained is called the project charter. It is the foundation document for the project and the authorization for the project manager to use organizational resources for the project^*. See Figure 2-3 for an illustration of the difference between internal projects and customer projects.

The last confusing element for the discussion here is the label “customer project” by external project managers in internal projects. These are still internal projects, as the performing organization, the organization that provides and manages the resources for the project, is identical to the organization that will use the project’s deliverables. The project manager is just among the resources that the organization procures from external sources for its internal project.

What are the differences for project managers and their teams between running internal projects and customer projects, cost centers and profit centers? There are many, as follows, and they are significant.

2.3 What Is the Matrix?

This topic is tightly linked with the previous one: Most projects today are not performed in isolation in a desert oasis or on a remote island but are done inside existing organizations—corporations, government agencies, associations, or other forms of incorporations. Most of these organizations are not optimized for managing projects but for ongoing operations, such as manufacturing, services, trade, and other forms of repetitive activities that can be standardized, cost-optimized, and sold to customers with inexpensive pricing. These organizations tend to “operationalize” every activity they do, which allows them to get cheaper, faster, and better over time. Operational repetition comes with many benefits, including predictability and order. It also allows for optimization when organizations and their personnel go through learning curves and helps them improve cost efficiency and quality. Operations can be very effective in using scaling effects, reducing costs of productions and services by increasing throughput numbers. For example, if it costs a manufacturer $1,000 to produce a certain widget, and each widget will cost in addition $1 for raw materials, making 1,000 widgets will cost the company $2,000 or $2 per item. Making 10,000 widgets instead will cost $11,000 or $1.10 per item; a cost advantage from scaling of 45%.

Many famous thinkers, consultants, and practitioners in engineering and business sciences have focused on repetitive processes in the past. Frederic Winslow Taylor showed in the early 20^th century how work can be made cheaper and more predictive when it is broken down into smaller portions, each of them repetitive again but easier to understand and to optimize^*. Influenced by his work, the Reichsausschuß für Arbeitszeitermittlung (REFA) was founded in Germany in 1924^†, an association that sent trained experts as “Zeitnehmer” (time assessors) into production facilities and later also into administrative environments where they used stopwatches and workflow report sheets to identify and eliminate time waste. It has been reported that in 1943, when German production in the Second World War was at a peak level, their number was at 12,000^‡. An essential element of the Toyota Production System (TPS) developed in the decades following the Second World War is the principle that a process must be optimized before it gets automated; otherwise, in conjunction with efficient ones, inefficient processes will be also automated and will then be much harder to identify and improve^§. Software consultants know the principle that business process engineering must precede business software implementation to make the best use of the software—or, in other words, that it is easier to adjust an organization to the specifics of a software product implemented than vice-versa. This may be the most basic principle of operations management: Organizational structures mirror those of the business processes.

Frenchman Henri Fayol is another example how business thinkers of the early 20^th century understood organizations as mainly functional, dedicated to operations with their ongoing and repetitive tasks, and his work is highly influential still today. In his “Administrative Theory”, he focused on the influence of administration on the separation of work and the predictability of its results. Workers should have a clear and unambiguous line of command, should know their place inside the organization and should be allowed to rely on the stability of their position and work environment^*. Some of Fayol’s principles are applicable to project management, but the majority are not valid for our field, where most work is inevitably dominated by frequent organizational change, temporary assignments, and overlapping chains of commands.

Operations have another opportunity for optimization, and it is commonly overlooked that projects basically do not have this: the ability to utilize resources close to 100%. This opportunity is generally impacted by the non-repetitiveness of the workflow logic. For example: A worker, Jill, has been solicited from an outside vendor, and the vendor will bill 10 days for her. She works on an item that she must first process along three activities A, C, and E, with three days’ duration each. Between these activities, another person, Jack, must do some work on these items along activities B and D. Jack may for example be her internal liaison, and it is his job to review whether Jill is on the right track with her work by auditing her processes and inspecting the results. It is not quite clear how long it will take Jack to do his reviews but the plan gives him two days for each of the reviews, so if each of Jill’s activities will take two days as well, a simple workflow is created and shown in the swim-lane diagram^† in Figure 2-4.

In the example, Jill has been booked for the entire duration; sending her away during her idle times between her activities bears the risk that she will not be back in time when Jack has completed his activities. Leaving her assigned to the project bears the risk that she will be billed for ten days but will only work for six. In operations environments, where situations are repeatable and predictable long-term in advance, solutions can be found and applied over time to keep resources busy with other tasks. In the example, Jill could do some unrelated work and be kept productive outside the work flow described in Figure 2-4.

Figure 2-5 shows how operations can smooth resource usage to reduce billable or chargeable resource idle times—“billable” for external resources, “chargeable” for internal. Operations can plan work and book resources to keep idle times at an unavoidable minimum. Billable or chargeable resource idle times are considered waste, and operation managers are in comparatively a good position to eliminate waste over repetition.

The point at which no resource is idle is sometimes referred to as the “Pareto optimum”. At this point, whenever one wishes to dedicate some resources to a new task, one has to take them away from another one, because the system has no free resources that can be used as a bench reserve for unforeseen needs for resources. Projects are rarely in a Pareto optimum. One of the reasons is uniqueness; the typical lack of repetitiveness in projects. Uniqueness may not be a characteristic of every single project task; some tasks may indeed be highly repetitive, but uniqueness is the characteristic of the project in its entirety. A second reason is the need for reserves to cope with the uncertainties that come with this uniqueness. If a resource, a person, or a piece of equipment or another kind of temporary resource is expected to work four weeks on a task to finish it, the resource will be most likely booked for a longer period, in case it should take the person or equipment longer to finish the task. Often enough, project work is similar to a journey that was planned by a person who intended to take the sprinter train which is travelling the direct way from A to B, but finds himself or herself later in a slow train, which is travelling along the winding and scenic river valley, slow enough to allow people make pictures of landmarks on the way, but not what was originally intended.

Reserves are generally like fire extinguishers: They must be bought and need to be inspected and maintained in fixed intervals, all costly activities for items that spend most of the time idle mounted at walls. In case of fire, people are happy to have them, but burning houses are not that frequent. Reserve booking times may also sometimes not be needed, but the booking periods are often fixed, and if in such cases resource run out of work, charging or billing will nevertheless continue. By the way: Burning houses may not be that frequent, but work finished late definitively is. Managing booking reserves is a core competency of a project manager, necessary to handle the uncertain elements of a project, and so is defending them against organizational requests to free them for other tasks. Having booking reserves will lead to idle times of resources and increase project costs; not having them will make the project flammable in case of difficult situations. A project manager without reserves is a feeble observer of great events.

In classes, I often have discussions with cost engineers^* about whether billable and chargeable idle times exist at all. They fundamentally contradict costing principles they consider sacred, and one of them is that resources should be paid for work, not for availability. To take a simple example, think of rental cars: If someone rents a car for five days, but uses it only on two days, and the person approaches the rental company and wants to pay only for two days, the most likely answer of the company will be something like: “You had the car booked and available for five days, and this is what you must pay for”. The company could not rent out the car to someone else during the five days and could not earn money from it during that time and bills the customer for the full five days. The company may be accommodating and may not charge the customer for the three idle days, but there is no obligation for them to do so.

In projects, idle times often come as a surprise. Rarely, another piece of work is due by such a time that the free person is qualified to do. So, smoothing the lag in the resource usage may not be possible, and sending the resource to another assignment may be risky. When will the resource come back? Another problem is that trying to fill billable or chargeable idle times in projects with unrelated work often leads to a disrupted work flow, which leads to delays and missed deadlines. Adhering to the correct order of work is an essential prerequisite for not failing, and ignoring it leads to a multitude of problems, and possibly crisis.

The way for operations managers to achieve the goal of optimization is by separating themselves from the uncertainties of the surrounding environment to the maximum possible. At the beginning of the industrial revolution, they erected big walls that surrounded factory buildings to isolate them from the uncertainties of weather as well as social impacts. Later, those walls were supported by the steam engine that isolated productions from the capriciousness of wind, water currents, and exhaustible human or animal muscle strength that had commonly impacted operations at earlier times. An interesting anecdote in this context: When Lewis Wickes Hine, an American sociologist and photographer, published his first photographs of child labor in US factories around the year 1910, the public was shocked at the practices hidden from it, and he was repeatedly threatened for making these practices visible^†. The isolation also had a social aspect; the public outside the factory walls should not know and discuss the industrial practices inside them.

Still today, we see many attempts to isolate operational processes from the environment in which they are performed. An example are call centers whose secondary job is to satisfy customers when they have questions and complaints, but whose primary function is to keep operations undisrupted by questions, concerns, and complaints from customers. The isolation of operations allows for optimization of processes and helps improve predictability and order, but it separates the internal processes from their markets. In essence, isolation was and still is a means to make operations a closed-skill discipline (discussed in Chapter 1).

Isolation also has an inner-organizational aspect: Functional units—for example divisions, departments, or branch offices—tend to erect walls separating them from other units inside the organization and from their managers, as the perceived interest of the unit is often more important than the interests and the strategy of the organization as a whole. These walls are often intended to separate a business unit from the uncertainties in other business units to a maximum degree and to prevent a “weak spot” in one part of the organization from impacting the other parts. A major leader of the quality management discipline, W. Edwards Deming, demanded in his famous 14 points that organizations should “Break down barriers between departments”^*.

Now, let us see how such a functional organization may prepare itself to perform a project with its own resources. Figure 2-6 shows a division as a sub-organization inside a functional organization, which may be a firm, a government agency, an association, or something similar. The division is broken down into departments of different sizes.

There is an interesting aspect about the functional organization: In the example, it is very likely that Department Manager #4 is the most influential one among the department managers since this person has the largest department. Depending on the corporate culture and the people involved, there may be other influencing factors, such as who earns the money for the organization, whose role is the most business-critical one, who has most management attention, the largest office chair, or the fastest company car. There may be many other factors that positively influence the power of a unit manager, but head-count is generally a strong one. With more span of control, functional managers are able to obtain more budget responsibility. They have the potential to be more productive and business critical, and as stakeholders in business decisions, their business interests are regarded as stronger, and their arguments are more convincing. One should also not underestimate off-the-record influences: They have more ears and eyes to know what is chattered on the “grapevine radio”—the informal information channels in an organization—and they also have more voices to spread rumors. Gossip is generally most successful when many people repeat and confirm the same statement, even when this is false—an effect for which Norman Mailer once coined the term, “factoid”^†. In factoids, evidence is replaced by consensus, and a larger department can create the impression of wide consensus much easier than a smaller one.

When a project manager applies for a new job, the first questions by the recruiter relates to project experience and formal qualifications. The first question to a functional manager relates to the person’s span of control and the budget managed in the current or previous job, and the numbers answered are regarded as an essential element of the person’s overall qualifications. Functional managers commonly dislike having to give away resources, because their subordinates give them self-esteem, reputation, and power.

Figure 2-7 shows how such a functional organization would staff a project with its own human resources.

This overlay of lines of command is commonly referred to as a matrix organization. A matrix organization may be planned and “engineered”; more often, it just emerges. Matrix organizations in essence are not limited to the project/operations overlay; many other management domains are effectively cross-functional as well, such as cost engineering, quality management, data and privacy protection, work-place safety, and more. As these are generally operational by nature, i.e., repetitive and ongoing, the organization has time to arrange the multitude of power balances between the different management domains. The overlaps with the functional organization seem similar to that of project management at first glance, but these cross-functional management disciplines and project management could not be more different. Projects are temporary by nature, which means that time may be too tight to avoid, mediate, or reconcile potential conflicts. How project managers manage these conflicts effectively and engage functional stakeholders in their projects is often the decisive factor between project success and failure.

There is a corollary of the link between unit head count and perception of power and influence that can often be observed, especially in older and more rigid organizations: When the department manager in Figure 2-6/Figure 2-7 is the most powerful with the largest head-count, it is easy to understand what the person’s first feeling will be, when he or she learns that a subordinate will be taken from the department temporarily to support a new project as a team member. The first emotion will likely be a perceived loss of power and importance. There are ways to overcome this perception, such as internal charge systems that give department managers budgetary compensation for the sacrificed workers. Increased influence of the business unit on the execution of the project and its outcomes is also a well-working justification for the temporary transfer of unit resources to the project. Participation in the success of the project may be a third kind of compensation, but these benefits are secondary perceptions; the primary one is the loss of power and influence from the temporarily absent resource.

So, for the sake of the example, we have Jane, employee 1.2 in Department #1, who is also assigned to the project as the project manager. She has a team member, #2, Jill, who is also employee 2.1 supervised by Jack, Department Manager #2, and has just been recommended to go to Hawaii for five days and perform an important project task. Jane speaks with Jill and explains to her how important the task is for project success, asking her to book a flight, a hotel, and a rental car for five days. Hawaii is a place where Jill has never been before, and she would love to go there, even if it is just for work. She informs Jack, her department manager, who is not positively impressed; instead, he becomes angry. In the end, she is his employee and cannot be assigned for a task without his approval. He needs her at her work place and explains that there is a continuous demand by customers to talk with her. Given the time she will spend travelling there and back, and the time zone difference, she will not be able to meet her duties to the department during her absence, says Jack. His department provides an income stream for the organization, and he must therefore reject Jill’s assignment. So Jill has to make a tough decision between her functional job and her project team assignment. Will she buy a ticket, book a hotel room and a rental car? Or will she follow the functional manager’s strict “No”?

Jill is in a classical “Servant of Two Masters” dilemma^*, and as she cannot make herself available to both the functional manager and the project manager at the same time; she has to make a decision. In many organizations, it seems more likely that she will stay. Jack, the functional manager, has “disciplinary power” over her. He decides on promotion and incentives, conducts her performance reviews, and is in a position to fire her. Time is also an issue. When the project assignment is over, Jill will have to return to Jack’s department and will have to work with him, her functional manager, again. It is also interesting to look into the past. Jill has known the functional manager for quite some time and knows what to expect from him, while Jane, the project manager, is a fairly new contact for her, and Jill has not developed any rapport with Jane so far. The result will be that Jane will not be able to send Jill to Hawaii, and the same will happen with everyone else she approaches. The project will be delayed, and it will be difficult to deliver all functions expected from it.

The situation described in this little case-story has a name in project management: we call it a “weak matrix”—weak of course as seen from the perspective of the project manager, whose power and influence are limited. Figure 2-8 explains the position of the weak matrix in a continuum of organizational matrix layouts between functional only and project only.

Is it then also possible that a project is performed in a strong matrix environment? Most customer projects are run in strong matrix settings. As it was discussed before, project managers in customer projects provide the income for the contractor organization, and if—in the example—no one flies to Hawaii, the contractor may not be able to send the next invoice to the customer. In addition, the contractor will possibly run into a breach-of-contract situation. Most organizations do not want to be in breach of contract, and part of the project manager responsibility is to ensure that it will not happen. There are other situations in which one can find strong matrices. High-ranked project sponsors can strengthen project managers—unless they lose interest in the project, because they have found a new pet project—and projects that are performed to meet legal requirements. An example was April 15, 2004, when large publicly traded United States corporations had to become Sarbanes-Oxley Act (SOX) compliant, a set of rulings as to how corporations had to certify the completeness, correctness, and timeliness of information communicated to shareholders. (Smaller firms and foreign companies listed at United States stock exchanges had been given time until the end of the first business year that ended after June 15, 2005.) A staged set of provisions was implemented with the Act, which culminated in a ten-year prison provision for CEOs and CFOs for knowingly or willfully providing false certifications^*. Most managers do not want to go to jail, so pressure was high on the organizations to finish their SOX projects on time and meet all legal requirements. Project managers in these mostly internal projects were generally powerful, because they had maximum management attention that could not deteriorate and had to work against hard deadlines imposed by law.

Between strong and weak matrices are balanced matrices, something that one can observe rarely. Even organizations that claimed to have implemented a balanced matrix, at a closer glance, had a dominance of either projects or operations, in most cases the latter. Balanced matrices do of course exist, and they seem the best solution for companies that run a major portfolio of customer projects. In practice, they are hard to sustain because even the most willing organizations will feel the disintegrating forces of power-games and politics from time to time.

There are two more environments for projects: purely functional and projectized. The purely functional organization is made of departments that run projects without project managers, just with their own management resources, often in the form of “over-the-fence” projects, where departments work on a project, each of them with its own phase, and when the phase is considered finished, the project is thrown “over the fence” to the next department, which will be responsible for the next phase. I saw the approach some years ago used by a manufacturer of custom printing machines, a company that went into insolvency in 2011; and I am sure that the “over-the-fence” approach was a significant contributor to its bankruptcy, possibly the root cause. While it would have been desperately necessary for the company to have project managers that could overlook a project from the beginning to the end, the department managers did not accept the perception of demotion that came with such a role, and instead allowed the projects to be fragmented on a massive scale. The company made great machines and was profitable over decades, but when the market changed after the year 2000 and the demand for printed newspapers, magazines, etc. shrank due to the success of online magazines, the company was no longer able to adapt. One can hide organizational deficiencies under high profits, but when the profits evaporate, the faults become visible.

On the other end of the continuum is the purely projectized organization. These organizations are found in large-scale construction and infrastructure projects, but also in R&D, when an organization is just founded for the purpose of a specific research project. The organization may be a consortium, a joint venture of contractors on time in which each venturer provides resources for the project, or a special purpose vehicle (SPV), which concentrates more on the aspects of project management and project finances, and procures project work and deliverables from outside the organization. The discussions in this book assume that most projects are run inside matrix organizations, the extremes described here are highly interesting but will not be discussed in further detail.

Figure 2-8 above also includes mixed type of matrix organization described, called the “composite organization”. This is a type of organization where several projects may be run concurrently in different matrix situations. An example may be a development division in a company, which is performing projects for its own purposes and others for external customers. In such settings, it is often observed that project managers in customer projects have a stronger standing since they create income from which a budget can be calculated, and they have to ensure compliance with contractual obligations. Another aspect of a composite organization may be that the prioritization and management attention of projects changes over time. Another type of manager is what I like to call an HBR manager: This person reads the Harvard Business Review, Fast Company, or another great management periodical. Every other month, they surprise the organization with a new idea and a new project that needs to be performed; and all ideas are good ideas, but the organization is not capable of coping with both the speed and the scale of change, and worst of all, these managers cannot dedicate enough attention and support to all the projects at the same time. HBR managers can be found in many organizations today, and with all their good intentions and ideas, they can cause true havoc. When the projects that have been started with high expectations and the promise of strong management attention, and active support to the project manager lose the attention of senior managers, those projects may experience unexpected delays and cost overruns. Then the corporate project traffic lights are all set to “red”, and the project gets back the attention and prioritization it lost, possibly in conjunction with a new project manager.

2.4 The Economics of Attention

Attention is rarely described as a resource in literature, but looking at common definitions of the term resource, attention definitively is one. It may be the key resource of all. Management attention is not necessarily a guarantee for the availability of other resources, including people, equipment, material, funding, etc., but without management attention these other resources will be difficult or even impossible to obtain. The attention of other stakeholders may be important too. It can lead to support and positive engagement but also to resistance and conflicts. Managing attention is based on the way the project manager and the team communicate with stakeholders, and this is another example of “navigating between two monsters”. On one side is the insufficient communication, when stakeholders are left unclear on the project, on the costs, and other kinds of burdens that it will impose on the organization, its progress, its risks and problems, and the other things that the stakeholders should know. One may instead communicate too much, and stakeholders then may feel that their time is being wasted in meetings and with long reports that they are expected to study and comment on. Over- and under-communications are threats that can both lead to a loss of attention by management and other stakeholders.

Another risk is poor communication, ignoring the diverse interaction and behavioral needs of people from different cultures, which may lead to misunderstandings and wrong expectations. One more menace for projects may be the chemistry between the people involved; since communications between people with poor rapport is rarely effective, the contents of the communications may be corrected but the emotions that overlay them can not be. The chosen style of communications can also become a problem. James Pennebaker^* described three different styles called formal, analytical, and narrative. The formal style may feel dry, stiff, and demanding and relates to status and position as much as to the contents of the communications. Used as evidence at court, formal communication may be strong, as this documentation tends to be briefer and “crisper” than other styles. The analytical style communicates honesty and the preparation and ability to deal with complexity. Frequent distinctions are another common element of analytic communications that their backers often show by pigeonholing and classifying people and things. Texts are often longer to account for explanations and clarifications. For users of the narrative style, the favorite method is story-telling. They show a lot of social competency and awake empathy in others as much as they have it by themselves. Some people are good in all three styles, others strongly prefer one or two styles, which tend to be those they master most successfully.

A project progress report, written for managers, a customer, or for an internal requester in a narrative style may be entertaining and successful, or appear to the readers as a waste of their time. A request for the allocation of resources written in highly formal style may be successful when it makes the impression that standing processes are followed, or fail when a functional manager feels the basic lack of empathy that is typical for the style and responds that apparently his or her needs are being ignored. With a strong analytic style, a project manager can help stakeholders better understand problems and their underlying causes or appear as a know-it-all to these others. When project managers wish to ensure the attention of managers, heavy-handed best-practice approaches will not work; project managers need susceptibility for the dynamics of success and failure and for the sensitivities and preferences of the stakeholders involved.

As a trainer, I get asked frequently what I consider a good frequency for meetings and how long they should take. I cannot honestly answer this question as it depends too much on the specific situation. There are project situations where it is beneficial to have a short meeting a day, maybe in the form of a stand-up meeting in the morning, as a basic briefing for coordination and discussion of issues and concerns. In other situations, it may be necessary to have sufficient session time to discuss various aspects of a matter and resolve disputes without rushing, something one would not want to do too often to leave team members and other stakeholders sufficient time to do their work.

2.5 How Project Managers Learn

A student of mine recently told me how he learned of his assignment to his current project. A manager of the organization met him unintentionally—or so it seemed—in the company restaurant and told him, “Good that I am meeting you here. Have you heard that you have been selected for the new project xyz? A great project with massive impact. The future of the entire company depends on it—it will have top priority. To not create false expectations on your side, there will also be a shortage of resources in the coming months, as we have other top-priority projects concurrently, some are approaching their hot phases, and budget and funding may also be insufficient, but we both know that you are able to successfully run such a key project even under these difficult circumstances and deliver it in time against a . . . well . . . challenging deadline. The project is highly important, and to some degree, the future of the entire company depends on it; have I said that already? I will arrange that you get the details of the project ASAP so that you can start immediately creating the first results. By the way, the project is extremely important, as I said, but please, do not let your daily work suffer from it. We do not want competitors to laugh up their sleeves when we are not prepared to tackle them on the market place. I am aware that at this moment, I should ask you whether you are prepared to take over the project, but I think we can agree to skip this formalism. The project must be done, and you are the best person to whom I can entrust it. So, let me explain the details . . .”. It is probably needless to say that the manager did not have any details, just some basic information he could communicate.

When taking over the assignment for a project, the project manager’s knowledge about it is typically near to zero. The project may be an internal project, and managers have made a decision to add the new project to the portfolio, actually a classical investment decision. In some organizations, there is a formal process with a project request and approval procedure, which includes an impact analysis and an assessment of resources needed versus those available. The majority of internal project decisions are probably rather made spontaneously and ad hoc, and cases such as the previous example, where the project manager is informed in a more private setting, are not rare at all. In 2012, I was asked by the PMO of an engineering company to help them set up a project selection and prioritization process for their internal project portfolio. We had the full backing of the organization’s CEO for the development of a process intended to make sure that the company did not have too many projects at a time, that the projects were better coordinated, that load balancing assigned projects to units that had availability and not to those that were already overstrained, and to also make sure that the future project managers would benefit from a documented project evaluation process. This documented process would provide them with records that would give them a better understanding of the original goals and requirements of the project and serve as a basis for initial decision making. Then the CEO found out that as a consequence, he would have to adhere to the formal process in the future. The development was then stopped, and project managers in the company still had to take up assignments with almost no documentation from the selection process as a first source of information.

Documentation in internal projects from project selection may be near to zero; in customer projects instead, its quantity may be overwhelming. If the project is a customer project, there may have been a process beginning with a request for proposal (RFP) or an invitation for bid (IFB) delivered by the customer at the beginning. In most cases, a response would have been sent to the customer in the form of a bid, proposal, or another kind of quotation, and after some clarifications, negotiations, and discussions, the customer would award the contract to the contractor. Then a project manager was assigned, who often has not been part of the business development process and now has to scan through all the paperwork to find the information that helps to quickly make the first decisions.

In both cases, it is common to call the project manager into the project only after the decision has been made. The recommendation is strong to include project managers in the internal decision process whether to start a project, or in the business development process in customer projects to validate decisions made for soundness and realism, but this is rarely done in practice. Project managers are more often expected to focus on the delivery side and many are not free and available to also support the project selection processes with practitioners’ experience and expertise. Even if they were part of the internal project selection process or supported the development of the business with the customer, it is likely that the knowledge that they could gain is limited. They were not in the formal position of the project manager and had access only to information that was easily accessible, possibly to no information at all. Even asking people from the customer organization or internally for details on the current situation, something that is relevant to understanding what is needed for the change or the development that the project needs to bring about for the future, they may not have been able to obtain in-depth information, because they are not yet project managers at all. These and other causes make taking over a project a true adventure with a large amount of uncertainty about the issues that lie ahead. If there is a moment at all that the project manager will have full knowledge, it will be at the end of the project. The unique nature of the project makes it a major learning experience, and every new project will add new knowledge in technical dimensions, as well as in social, interpersonal, organizational, and even political dimensions.

The ability and preparedness for lifelong learning is therefore a trait that effective project managers have in common—they never consider their understanding complete. This ability goes together with situational intelligence, which consists of three elements: (1) the understanding that the same practice that was successful in a given situation in the past may fail in a different situation, or vice versa; (2) the ability to adjust practices to the specific needs of the project and the current situation; and (3) the care that this adaptiveness is not perceived by others as signals of lack of authenticity or reliability. See Figure 2-9 on this learning process.

The following are other developments that occur naturally while the project proceeds along its lifecycle:

• The number of feasible options for decision making decreases. Decisions and work made in the past limit decision options for the future. Late in the project, there may not be enough remaining budget, time until the next deadline, and resources available short-term to implement certain decisions.

• The costs of implementing decisions increase. With sufficient time, you can choose a cost-effective solution. Under time pressure, the only options available may be expensive ones. Simply think of a package that you need to send to somewhere. Consider the cost when the there is no rush in the delivery and the cost when the package needs to be there the next morning.

The time to assess the impacts of decisions on the project and to accurately document the decisions to better manage these impacts gets shorter and shorter. The risk of unintended consequences of decisions is highest when they must be made as “field decisions” during implementations.

The project manager is not alone with this learning process, which is shown in Figure 2-10. Virtually all stakeholders go through such a learning and development process, during which they realize what the project is about, what its results will look like, how the team members and contractors cooperate, and many other factors. Uniqueness comes with novelty, and novelty comes with learning. It is interesting to take a closer look at the dynamics of this learning process.

The American psychologists Chris Argyris and Donald Schön discussed two types of learning^*, which they called “single-loop learning” and “double-loop learning”. Their model refers to organizational learning and interpersonal behavior, and I wondered if it can give insights into project management learning processes and behaviors. I think it does.

They look at three elements of decision making and actions in situations that are influenced by uncertainty and therefore by learning processes. They researched how people, groups, and organizations reflect their decisions and actions and assessed which were good and which were, judged with the advantage of hindsight, rather poor. They then assessed what measures they should take to respond to the deviations between the intended outcomes and the actual ones. In their theories of action, they described three elements of this process: governing variables, action strategies, and consequences. Translated into project management, one can describe these three elements of a learning and decision-making process as follows:

1. Management conjectures. The governing variables—factors that influence the way project managers, their supervisors, and their teams want the project be performed as a whole, as well as the individual activities, that combine to become a major endeavor. The most obvious of these factors are plans and also the strategies that underlie these plans. Very religious or ideological persons may have dogmas that drive their behavior, while for scientists, paradigms can serve a similar purpose. Management conjectures are based on the past or on the current, but they relate to the future, which has the uncomfortable characteristic that it has an element of uncertainty. So, these conjectures are a combination of guesses, assumptions, forecasts, and objectives, as well as of expectations and agreements. Even contracts are conjectures as they guide actions based on the expectation that others—monitored or not—will adhere with their obligations, and on the fact that most people and organizations do not want to run into a breach of contract situation. There is no complete contract, a contract can therefore not remove all uncertainties, instead contracts must leave many details open for later clarification, just like plans do^*.

2. Implementations. The conjectures are then implemented in the form of managed project activities, which are kinds of action strategies in Argyris and Schön’s words. The implementation may refer to actions of the project manager, the project management team, or the project team as a whole. This step relates to the present day, and while some plans are more accurately implemented than other plans, the results will mostly contradict the conjectures to a smaller or major degree. The future cannot be predicted with 100% accuracy.

3. Outcomes. In project management, it is unlikely that outcomes will be precisely as expected. Deviations from the conjectures will occur relating to the deliverables created, delivery dates, costs, and stakeholders will learn from these deviations.

To give a simple example: A team member Jack, a developer, has estimated that he will realistically be able to finish some development work after three weeks for a project A. Based on the estimate and a five days schedule contingency, Jack’s activity has been scheduled for four weeks’ duration, and this duration has been included in the project schedule. Based on the schedule, Jack got booked, and the costs for the booking were added to the cost plan. Information on Jack was added to the project’s human resource plan, and his communication needs and those of Jill, his manager, were documented in a communications plan. Before Jack can start the work for project A, he will be assigned to another task in a project B, and delays there may influence his availability for project A. Delays may also come from dependencies of his task with other tasks that must have been finished and provide input to his work before he can start. While the schedule has been based on the assumption that these delays will not occur, the uncertainty that the assumption may be wrong has been added to the risk register. Once Jack has finished the activity, he will work over a month for project C and then come back and do other work on project A. Everything has been well planned, management conjectures have been made clear and documented. Two weeks after Jack starts working on the activity, he identifies some unexpected difficulties in the task that will lead to a required working time of eight weeks instead of the originally estimated three weeks. At the end of the four weeks booking time, he will be assigned to another project for four weeks, and only after that will he be able to return to the activity and finish it. As Jack cannot be easily replaced by another developer once the work has been progressed so far, and as no other developer would be available that quickly as a substitute for him, the activity finish will be delayed by two months and Jack will be blocked from doing other work that he was scheduled to do after his return from project C. One should also note that the additional work on the activity creates additional costs for the project that lead to a certain budget overrun.

There are two kinds of lessons for the project manager from the situation:

• Single-loop learning. The project manager puts the blame on Jack. Jack had promised to finish the activity after three weeks, and the project manager had even given him an extra week as a schedule contingency, and this is still not enough. The project manager requires Jack to take appropriate measures to finish the activity in a timely manner before he leaves the team to help project C and to protect the budget from the overrun.

• Double-loop learning. The project manager seeks the error in his or her own plan. Maybe the uncertainty of the activity duration was underestimated. Maybe the activity was not described in sufficient detail, or not enough effort was spent to ensure the quality of the results of the predecessor activities, so that Jack could do his work based on them without difficulties that take him time to resolve. This approach may also include looking at Jack’s future assignments, and those of other team members as well, and adjusting the plan to avoid repeating errors such as this one, and it will lead to discussions with some key stakeholders if the budget is still sufficient to finish the project successfully.

Outcomes in projects are generally not 100% as expected, and while a deviation may be a problem for the project, it is also a new lesson for the project manager and other stakeholders that reality provides to them. There are projects that follow mostly the planned stream of actions and results. There are also rollercoaster projects with breath-taking ups and downs, making plans obsolete in just moments. Both kinds of projects entail requirements for project managers and other stakeholders for learning, which is challenging, but also an opportunity to grow. Figure 2-11 shows the two learning loops for project management that are applied in the example.

Management conjectures include everything that influences the way project managers and involved stakeholders want the project performed. They may include not only values and mental representations of the world around, but also systems of rules and recipes that these people have adopted. Some people even ask astrologers and augurs for advice on the decisions and actions. Guiding presumptions relate to the future, but they are based on extrapolating things that are considered true for the present or the past. As mentioned earlier, highly religious or ideological people often have dogmas to which they adhere closely. In sciences, paradigms can serve a similar purpose. In businesses “best practices” and strategies often serve this purpose. In project management, all these may play a role, but the foremost guiding set of guiding presumptions is found in plans. Project managers model their projects in the form of scope statements and work breakdown structures, time by using schedules, costs in the form of budgets and cost baselines, and so on—all kinds of plans they make to give the future of the project a degree of predictability and order and to be able to communicate this future to the stakeholders involved. Once the project has been initiated—i.e., it has been founded and the project manager authorized—these plans are the starting point of further development.

Figure 2-12 illustrates how the well-known Plan-Do-Check-Act (PDCA) cycle is generally implemented in project management. It was originally developed by Walter Shewhart and popularized by Deming^* for usage in operations, especially in manufacturing environments. For project management, two more elements are generally added to PDCA: initiating and closing. These elements adapt the model to the fundamentally temporary nature of project^†.

Combining Argyris and Schön’s model with the PDCA cycle gives two options how project managers can learn from the differences between their plans and what is happening in project reality, as shown Figure 2-13.

Another example for the model shown in Figure 2-13 is a statement that a manager of project managers made to me some years ago when we discussed a change request management section that should be part of a project management seminar, and that he wanted to see removed: “I cannot expect from my project managers that they modify their plans again and again”. His company ran projects implementing metal machining equipment, and I asked him what his project managers should do if a project was late and on the way to miss a deadline. He was very firm that the project managers should accelerate the project by adding further resources (“Crashing”^‡), by de-scoping, or by using other means. All these approaches have limitations: more resources may not necessarily accelerate the project, but will definitively increase costs, and de-scoping is constrained by the contract. In addition, replacing an expensive “Item A” with a cheaper “Item B” without documenting it, possibly even without informing the customer, leads to scope creep and to discrepancies between the documentation, which describes the original intentions, and the actual implementation. In the example, single-loop learning describes attempts to accelerate the project and bring it back to schedule. Double-loop learning—in project management—means rethinking and reworking the plan. It may include talking with the requester, customer, or any other stakeholder who defined the deadline and discuss re-scheduling. Depending on the specific project situation, each approach may be appropriate—or wrong.

The example confirms another statement of Chris Argyris, who once noted that double-loop learning is far more difficult than single-loop learning^*. A project manager applying single-loop learning puts the blame on someone else: workers, contractors, bad luck, etc. The plan was good, but people, business partners, and the reality of an unsupportive environment made it impossible to implement it. Double-loop learning in project management means seeking the error in oneself. The project manager is responsible for the plan, and if the plan doesn’t work, the project manager has to assume this responsibility. Generally blaming others is arrogant. Generally seeking the fault in oneself is depressive. Project managers should avoid arrogance as well as depression and seek the truth somewhere in between, basing their learning style—single- or double-loop—on the available information and on the possibility that they have made a mistake or someone else has. The basic lesson from Argyris and Schön’s model is how learning is linked with mistakes, and how a learning culture essentially stems from a culture of accepting mistakes as human.

So, each project is a sequence of new lessons to be learned, which contribute to a learning process that spans over the entire project, and during the different projects that project managers perform in their life, they collect further knowledge. Lifelong learning—probably more from the mistakes that we have made, and also those that we have observed by others, than from successes—is an essential element of a project manager’s professional development process. The dynamics of success and failure are dictating that this process will never end as long as we are members of the discipline.

Project managers have a third option, in addition to corrective action and plan updates: Disregard the plan. In my classes, I occasionally hear statements like: “In my current project, I found out that the plan did not work anyway, so I decided to ignore it and told my team members to simply do their job. In the end, it does not matter if a cat is black or white, as long as it catches mice. Once the result is there, no one will ask how it was attained”. One could call this zero-loop learning, and in most cases, it is bad practice. If the project does not need a plan, the project manager should not have wasted resources developing one right from the start. If the project needs a plan, because it may not be enough that everyone simply does his or her job, the team may do the wrong things and the project may fail. This statement describes the worst learning cycle. One may of course correctly raise the objection that the learning process results in the finding that a plan, which the project manager originally considered necessary, is later found dispensable because the project is much simpler than originally thought, but this is not the situation communicated in the statement above. It is rather a message from a person, who could not cope with the management tasks assigned, and who rejected the learning process, which comes with every new project, as too strenuous. Project managers that prefer this style often assign themselves attributes like “goal-oriented” or “result-driven”. I recommend to be careful with them. Rats also chase mice, and if the mouse in the house is caught by a rat, this may not be good news at all, because the small problem has been replaced by a larger one. Project managers who are not prepared to go through any learning cycle may cause more problems than they resolve; they do not grow in their professionalism from project to project, and on the way to obtaining their results, they may cause havoc to the performing organization and the customer.

2.6 Game Theory for Project Managers—A Brief Introduction

A case-story: Around the year 1990, I managed a project, which was part of a major program performed by an automotive company. A new production line was to be implemented, and 124 projects needed to be finished on time to meet a start of production (SOP) deadline of the principal program and its deliverable, the production line. The SOP was the most critical moment of the entire program, and all project activities in the program were managed to make this event happen on time. The program included projects for the construction of factory buildings, delivery and installation of infrastructure and machines, development and implementation of electronic hardware and software systems to control the production, recruitment and organization of workers and administrative staff, and development and implementation of environmental protection arrangements. One project was mandated for the integration of all these components to become functioning as a highly complex system. Most projects were run by contractors, only a small percentage were performed as internal projects by the automotive company. The good news was that out of these 124 projects, 121 were able to meet their delivery dates, which computes to a success rate of 97.6%, something one may consider quite impressive. Three projects were late: two performed by contractors and one internal project. Actually, those three projects were truly a problem, and they jeopardized the start of production. In a situation as described here, there may be a small number of rather uncritical projects, where the program does not get delayed too much by a delayed contributing project; but the vast majority of projects are time-critical, potential show-stoppers, for the program, and so were the three late projects here. They were critical enough to delay the SOP, which meant a fiasco for the program. The output from the production line was already envisaged in the company’s production plan, staff had been hired and trained to work on the new line, and shareholders expected that the increasing production would also increase the value of their stakes. The three late projects were not a 97.6% success rate, they meant a 100% failure to meet the deadline and the business case of the program.

It would have been beneficial for the program manager to have the full knowledge of the expected problems early to be able to make decisions at a time, when there were still many feasible options left and when these options were cost-effective to implement^*. The program manager may have been able to inform senior managers early and find solutions to limit the damage to the program. But will the project managers of the late projects tell him that their projects will deliver late? In reality, this is more unlikely than likely. I had later opportunities to speak with them and they told me in detail how they perceived the situation.

First, it took all three project managers quite long to understand how late their projects actually were. They did not use methods such as network diagramming that would have enabled them to develop useful forecasts as a basis for scheduling and early booking and would have allowed them to validate the contractual delivery dates. Most of the time on their projects, all they could do was guess when certain events would take place, and at what time what work will be done, based on experience (they were very proud of their experience). For progress assessments and decision making, they had to rely on statements from team members and subcontractors. This may have been sufficient in other projects, but not for this program, which was dependent on reliable deliveries of built-to-order products and timely performance of related services. Additional pressure came from managers in the contractor organizations, the internal sponsors of the two customer projects. They asked so often, “Will you deliver on time?” and the project managers answered so often, “Yes, of course!”, that they finally believed it themselves. Without a plan to measure project progress against, the project managers asked their team members and subcontractors, “Will we deliver on time?” and the answer they got was generally, “Of course we will. Why not?” Many organizations use traffic light symbols to communicate project status: Green if the project is on plan, red if it is not. In the example, the projects became classical melon projects: green on the outside, but the deeper one drills, the redder they get. As soon as the project managers became aware that they did not have options at hand to deliver on time, they should have informed their managers, and it would have been the contractual and moral obligation of the contractor organizations for whom these project managers worked to inform the customer.

There was also an internal project that was late, which was performed by another department, and basically the same happened with the internal project. This is not just a contractual issue, but a common problem of project managers who focus on technical matters and ignore organizational concerns.

When they finally became aware of the lateness of their projects, they found solace in the insight that it was unlikely that they were the only ones with late projects. Part of their experience was that a complex program like this one had never adhered to schedule, and at least one late project has always led to a missed program deadline. All they needed to do was wait for someone else to raise the finger and tell the program manager that their project was late. Then, this other project manager would have all the problems. The person’s employer would possibly have to pay damages or penalties to the customer and suffer from the loss of reputation that such a case brings, and the customer would tell all other contractors that they no longer have to deliver on time. This is how to let a problem resolve itself by just waiting. One cannot be a good project manager without experience, but experience is a teacher who sometimes teaches the wrong lessons.

At one point in time, not long before the SOP date, one of the project managers indeed had to give in as he could no longer hide the truth that his project would not be able to meet the deadline. Facts became obvious and the program manager realized that the program results would not be delivered on time. The SOP got delayed by three months. Next, the program manager informed the project managers of all other projects involved that the program had been rescheduled and that their deliveries were now expected 13 weeks later. For the other two of the three late projects, this message was a blessing. All their concerns and worries vanished in a moment, and they had no difficulties meeting the new date. They were the secret, but nevertheless happy, winners in the game.

Experts in game theory call such a situation a “chicken race”. The term goes back to the 1955 movie Rebel Without a Cause, in which two young men, Jim (James Dean) and Buzz (Corey Allen), drive stolen cars over the edge of a sea-side cliff with a simple rule: They have to jump out of the moving car shortly before it races over the cliff, and the first who jumps out of his car is the chicken, the coward.

Races like that actually exist in real life. When the young lads do not have a cliff available, they may instead race on a road toward each other, and the first driver who veers off is the chicken. If no roads and no cars are available, the daredevils may wait on railroad tracks—preferably high-speed rail tracks in Europe or Asia, where trains can run 300 km/h (187 mph) or more—and jump off the tracks in the very last moment. Again, the one who jumps first is the chicken. Some jump late.

The term “game theory” may sound somewhat cozy, playful, and amusing; however, it is a serious mathematical discipline that has strong implications for other sciences, including biology and sociology, and also in political, economic, and business sciences. The situations that it helps us understand are generally not cozy at all. Game theory is often described in highly cryptic notations, but the situations that it depicts are pretty normal experiences that people make in everyday life. They are often driven by limitation of resources and time and by people who can choose between cooperative and noncooperative—competitive^*—behavior in situations, when cooperation would serve the interests of the community of players, but the competitiveness would serve the individual interest. Limitation of resources and of time are two typical aspects of project managers, so project managers should understand how it is applicable for their discipline as well. I will try to avoid cryptic notations and build on the common sense element that underlies game theory so deeply, and will also provide practical advice from it to help you avoid or deal with some of the conflicts that almost inevitably come with managing projects.

A core term of game theory is the “Nash Equilibrium”. It describes a malevolent kind of “invisible hand”, a stable balance of forces that does not automatically lead to an optimum for a group of players, but instead makes it impossible to achieve this optimum because players follow their perceived particular interests that conflict with group interests^†.

An example of a Nash Equilibrium is the massive over-fishing of the seas that is currently done on a global scale. Major fishing companies today rapidly destroy not only the property of all mankind and the economic basis for coastal communities, but also the resources for their own businesses, to their own long-term detriment^‡. The owners of the fleets of fishing boats are well aware that their over-exploitation of fish stocks is not sustainable, but they are nevertheless in a race to be faster in this exploitation than others. The awareness of the limitations of sea life, the basic resource their operations require to survive, does not make them more careful about its conservation, but more exploitative and competitive in applying highly effective technologies, and while they are increasingly investing in larger and more powerful vessels and equipment such as sonar and trawls (fishing nets), they accelerate the process that will finally lead to the break-down of their own businesses. Their dilemma is that if any of these organizations would change its mind and turn to more collaborative and sustainable practices, others may not do that, and this organization would fear becoming the loser in the business competition. This is the essence of a Nash Equilibrium: “It will not do any good if only I change my behavior as long as others are not changing their behaviors with me, so why should I do that?” Scientists and politicians tried repeatedly to manage the situation by limiting the amount of fish the fleets may take home and ban the most destructive practices like bottom trawling, but mostly to no avail. The fishing quota decided by politicians from time to time are much higher than what scientists consider sustainable^*, and with the lack of accurate real-time monitoring and enforcing mechanisms, one may doubt that fleet owners will adhere with them anyway—the financial incentive of not following rules is another Nash Equilibrium.

A further example of a Nash Equilibrium is the arms race during cold-war time in the 20^th century. It was expensive and risky for both parties, USA and USSR, and while most people considered the nuclear balance a guarantor of peace, reality was that in the year 1983 alone, the world evaded an almost certain nuclear catastrophe twice, more by luck and insubordination and heroism of individuals, than by the mechanics of deterrence that many people at that time considered infallible^†. The fear of losing the arms race was stronger on both sides than the understanding that common interest of both nations would have dictated to negotiate an end to it, focus public money on investments that are beneficial for both societies, and save both countries (and the rest of the world) from the abyss of mutual nuclear annihilation. An equilibrium of commonality would have been to meet and find ways to avoid the arms race, but the Nash Equilibrium, dictated by particular interests over joint interests and also by serious paranoia on both sides, was stronger, until the 1983 incidents showed that both countries were following the wrong way. After these incidents, common sense politics returned, and agreements on disarmament were made during a slow process, which was mostly driven by the need to build mutual trust strengthened by mutual monitoring systems. We have since perceived how hard it is to avoid the return of mutual distrust and with it the Nash Equilibrium, which can lead to a new cold war at any time.

The core topic of game theory is the conflict between the particular interests of persons, organizations, possibly even countries involved in a “game”, and the common interests of these game players. There are also applications for animals and even plants, as they share commonality in the dynamics that lead players into dilemma situations. Game theory gives strong clues on how to identify these dynamics and respond to them early. Sometimes, it helps find resolutions when these dilemmas occur, but often, it does not. In the discussion of the learning process during a project earlier in the section and how this process correlates with the loss of feasible options and the increasing costs of the remaining options, the loss was described as steady over time. In game-theoretical dilemmas, all options often get lost just in a moment. We may be able to avoid dilemma situations in projects and elsewhere if we identify their emergence early; if we do not, we may no longer be able to rectify the problems that may arise. Game-theoretical dilemmas are often gridlocks that make it difficult or even impossible to get out, once they have developed.

The “chicken run” in the movie Rebel Without a Cause is a fictitious story, of course, but it is based on real events, and it also gives an example for this rapid loss of options: Buzz, one of the two young men driving the cars over the cliff, finds just before the edge that a strap on the left sleeve of his leather jacket is stuck in the door handle. He cannot open the car door to jump out. There is not enough time left for him to free the strap or stop the car, and he crashes with the car into the ground at the bottom of the cliff.

If in 1983, either nation during the Cold War had fired the first missile, no country would have had an option left except to go for mutual annihilation. When a final rush for the last fish will be over because all fish have been taken from the oceans, the last option for the big fisheries will be formal insolvency. When people in projects or programs run into Nash Equilibria, they may no longer have the options left to make decisions that could lead them out of the dilemma and bring the project back on the tracks that lead to success. In the example, the project manager worst off will be the one who did his or her job and communicated the delay first, not those who did not communicate it at all.

The original concepts of game theory were developed in the late 1940s by Oskar Morgenstern and John von Neumann and further developed in the 1950s by John Nash^*. Many others have contributed to the field since then, and the theoretical concepts have been tested repeatedly in labs and observed in reality by scientists. Experts in game theory were hired for high-value auctions to increase the chance of success for bidders—generally without much success. As one should note, game theory is neither alchemy nor an ideology, but experts in game theory are nevertheless often well paid as consultants in highly competitive situations. Game theory can help make dilemmas avoidable, but it does not provide a magic potion when the dilemmas and gridlocks have evolved or will inevitably occur, as in auctions^†.

The focus of this discussion is not game theory as a theoretical and scientific discipline, but its situational application in project management, so the following case stories may help you understand the dilemma situations we often face as project managers. Most are straightforward and understandable; game theory is not rocket science. It is therefore astonishing how often project managers and other stakeholders repeat the same mistakes and run into the same troubles again and again, and how little attention is given to steering clear of Nash Equilibria, when basic project decisions are made.