3.1 Introductory Questions

The introductory questions are intended to test your knowledge on certain project types and on the practices that can be beneficial or detrimental for them. They will all be discussed in this chapter, so if you do not understand a term or the concept with the term, come back when you finished reading the chapter and read the question again.

3.2 Best Practice Approaches vs. SitPM

On March 28, 2008, I had an interesting meeting at London Heathrow Airport. It was interesting in that it was the day after the “grand opening” of the new Terminal 5 (often just called T5) at Heathrow—a key moment for the two organizations, British Airways and British Airport Authorities, who ran the project jointly and also operated the terminal together. Except that the terminal was not operating by that time at all; instead, it was a huge disaster. Just as the operational opening had been started the day before, the systems in the terminal crashed, and the entire operations of British Airways fell apart. At one point in time, the company was unable to fly any aircraft to and from the terminal, and it took the company months to return to perfectly normal operations. I had a flight booked to Heathrow with British Airways the next morning. Late the evening before I was scheduled to depart, I found out that my departing flight, as well as the return flight scheduled for the same day, would not take place at all. I booked the last seat on a Lufthansa flight to Heathrow and back. I will discuss the lessons that I learned from this experience later in the chapter.

The meeting was appointed with a person who I will call Wendy in this case story. Wendy was a manager in a British training company that was interested in my support as a trainer for them. The topic was not project management, but bid and proposal management, something tightly linked with project management: During bid and proposal management, many decisions are made that can later make the lives of project managers easy or difficult. Proposal management is a discipline with specific professionalization and its own body of knowledge, a discipline in which the need for training is high, but the demand on the market is astonishingly low. I am a certified trainer for this discipline by the Association of Proposal Management Professionals (APMP), but I do not do much training business in this field. Most companies expect their bid and proposal managers to just learn by doing, and they are much more prepared to invest in their project managers. The British training company seemed capable to overcome this hurdle and turn the need for training into actual business. Commercial matters between the company and me were determined, and the meeting then was to discuss seminar materials, structure, and contents. I had studied the book that was mostly considered the body of knowledge of the discipline and would be part of the materials that students would receive. I had found some minor flaws, no big errors, but nevertheless statements that contradicted more recent research (such as, “serif fonts are more readable then non-serif fonts”) and should not be used. I told Wendy about them, her response was: “Oliver, don’t touch it. This material has been proven repetitively, and it works. It is ‘best practice’. Don’t alter anything”. I think I never heard the expression “best practice” more often than in the two and a half hours that we spent together in the meeting room at Heathrow Airport. It was a perfect argument to reject any criticism and kill all opportunities for improvement. A good practice may be rethought from time to time, or critically assessed if it actually is good practice in a given situation. And there is always the option open for a better practice. In contrast, as soon as a “best practice” has been identified, the search for the right approach to a given situation is finished. Period. The uniqueness of projects is then no longer considered, nor, in business development situations, is the uniqueness of the customer organization with its specific desires, needs, and requirements, possibly fear and concerns, which the bid or proposal needs to address in its contents and in its tone. Developing a complex business is a project in itself, and it is subject to the same dynamics of success and failure as any other project.

We had some great classes, after the meeting together, and I also took opportunities to help companies in a consulting role to win business. The little adjustment that I made in class was to ask students to consider the practices “good practices for many business development and proposal writing situations” and to deliberate for each situation first, whether it belongs to this group or not. This means that one first needs to know the prospect, and I believe that this should be the first rule for any business development project. The joint business was not as intensive as we hoped. As mentioned earlier, many companies invest a lot in their project managers, but regard bid/proposal management a common sense discipline that can be done by any person with the right templates and therefore needs no special instruction. I think the assumption is wrong and the impact on business is too high to leave this discipline to trial and error. A company should hire or develop professional experts for their bid/proposal development to make sure that they win the attractive customer projects and keep their competitors busy with poor business.

So, what is a best practice? According to Stuart Bretschneider, Frederick J. Marc-Aurele, Jr., and Jiannan Wu^*, to call a practice “best”, it must have three basic characteristics:

1. A comparative process (with other practices)

2. An action

3. A link between the action and some outcome or goal

There are many sources for “best practices” in project management that are considered universally applicable procedures and techniques for the discipline that a project manager can simply learn, adopt, and apply. An example is a project management methodology called PRojects IN Controlled Environments (PRINCE2), which is widely promoted to practitioners as a “proven best practice”^† and can be “used successfully for all types of projects”. Well-known and respected book author and speaker Harold Kerzner linked “management best practices” with “achieving global excellence”^‡. Tom Mochal promises “10 best practices for successful project management”^§. If one looks at the three criteria enlisted by Bretschneider and his colleagues, only the second is met by these promoters: The action. A comparative process, such as “We tried three practices in three perfectly identical projects, and found the first process to be the best” is nowhere described, and a clear link between the practice and the result is also not recognizable. Another open question is the dimension to which the superlative “best” refers. Is it monetary, strategic, social, or something else? A process that focuses on strategic elements may be detrimental on the monetary side and vice versa. Similar to a drug, each approach has its benefits and its unwanted side effects. Depending on the benefits that a person or an organization wants, and the side effects that it is prepared to accept, the definition of “good” may differ and with it the definition of the superlative “best”. While project objectives are different from project to project, so is the project environment, and practices must be assessed in the context of these objectives and the environment. With this situational viewpoint, one notices that a practice that has been found “good” in one moment may be detrimental in another one. This is the fundamental principle of what I call Situational Project Management, or in short SitPM. It seems obvious and self-evident to me, but what do others think?

The term “best practice” has gained high relevance in the world of project management practitioners; it is used to sell methodologies, books, services, training, software, and also conference tickets to project managers. Best practices are sold similarly to cooking recipes with the promise that a beginner only needs to learn the recipes and can then work at the same level with the most seasoned colleagues. They are also used to cajole customers. If a consultant writes a book on the “best practices” for his or her customers, the person stabilizes the business with these customers. The book will still be on the market place and tell the same story when the business environment of these customers has changed, and the former “best practices” are no longer appropriate. The book then may be a best-seller, because business people love success stories, assuming that they can easily copy successful organizations and be also successful^*. The fact that the same approaches that have been successful at one time, in one situation, may lead into disaster in another is commonly ignored. This can happen very quickly. Many readers will remember Nokia cellphones. Here are some data on them:

Share prices (New York Stock Exchange, Closing prices, Yahoo-Finance, n.d.^†):

• 6-11-2002: $17.53

• 6-11-2007: $41.10 (+134.4%)

• 6-11-2012: $2.77 (–93.3%)

Brand value:

• Millward Brown Optimor rated Nokia’s global brand value in 2008 among the top ten. In 2012, they no longer rated Nokia on their list of the global top-100 brands^‡.

• From 2007 to 2009, Interbrand ranked Nokia fifth in the world. They rated Nokia 19th place in 2012 and 57th place in 2013^§.

Market share^¶:

• 4^th quarter 2007: 50.9%

• 4^th quarter 2012: 2.9%

Profits before tax (million Euros)^**:

• 2002: 4,917

• 2007: 8,268

• 2012: -2,644 (loss)

In the five years from 2002 to 2007, the Finnish company more than doubled its shareholder value and was mentioned among the ten most valuable brands in 2007, a year in which every second they made a cellphone sold in the world. Nokia’s practices where highly successful during that time. Then, in the next five years, from 2007 to 2012, the share value dropped to under ten percent of the 2007 peak value; it not only became marginalized, its brand value had also dropped dramatically, and its profits had turned losses. The Nokia cellphone business was finally taken over by Microsoft in 2013. Nokia generally applied the same practices during 2002 to 2012, but the practices that led to success in the first five years caused failure in the second. What happened in 2007 that changed the business world so dramatically for Nokia? It was the emergence of two new competitive frontiers:

• Chipsets that allowed small manufacturers to quickly and cheaply develop new cell phone models and bring them to the market place. This business model was driven by the Taiwanese company MediaTek; it was a challenge to Nokia’s business at the inexpensive end of its product range.

• Smartphones: Apple’s iPhone and in its wake the Google-Android “ecosystem” with companies such as Samsung and some smaller companies mostly from Korea and Taiwan. These vendors assaulted Nokia at the high end.

In an article from 2006^*, two employees of Nokia’s network department described how the company wanted to use what they called “supply chain agility” to develop systems together with their suppliers that could respond quickly to changing demand situations and reduce procurement costs. Nokia had a major reorganization in 2007 and focused on improving production and distribution of its existing products. In 2007, Nokia also closed its operations in Bochum, Germany, and moved the production facilities to Cluj, Romania, where the company intended to develop a “Nokia Village” together with its component suppliers to profit from short delivery distances and just-in-time ordering. Nokia had an operating system and the basic software to control the electronic functions, called Symbian; using Symbian widely across its program was considered another way to reduce costs through scaling effects. These developments can be considered an appropriate response to the cost challenge that came from MediaTek. It was the kind of practice that Nokia had implemented over the last years and that made Nokia the market leader.

Nokia’s slogan was “connecting people”. I had some opportunities to talk with Nokia personnel in 2007, and they told me what they made out of the slogan: “disconnecting families”. This mainly referred to the many hours of overtime work that Nokia staff was expected to do, but also to the secrecy that was expected from them, which made it impossible for them to talk about their work at home. It further referred to the frequent re-organizations at the company that left it unclear for many employees where their place was inside the organization, something that caused workplace stress, an anger that many employees vented at home. Nokia’s business approach was always that of an introspective closed skill: If the company did its job better than others, it would be more competitive, and customers would prefer its products. As discussed in Chapter 1, Nokia as a company viewed itself as the figure-skater, and the market was the jury. The better its performance, the more acclaim and sales it would have. Nokia was not prepared for competitors such as Apple and Google, who did not try to make things better but different and in tight interaction with their business environments, which became an essential co-player in their performance. They understood business as an open-skilled discipline. In 2007, the first iPhone was launched, as well as Google’s Android operating system for smartphones; the first smartphones based on it followed in 2008. How did Nokia respond to the new competition? Their chief strategist Anssi Vanjoki, the company’s second-highest manager, told the German newspaper Handelsblatt in 2009: “Apple has originally also caused a lot of sensation with the Mac, but they remained nevertheless a niche vendor. This will be the same with mobile phones”. He also said, “In the past we have too much focused on the technical basics instead of optimizing the design of our phones. But I am trustful that we know now, what we need to do: Build phones that are easy to use and good looking”^*. He was still thinking in technical product dimensions not in user experience and in “ecosystems”. The big innovation was the capacitive screen, which allowed “swiping” gestures and a new user experience, while Nokia still used little touchpad keyboards. The change needed for Nokia was huge: Symbian was not developed for the new screen technology, but Nokia wanted to stick with it.

Apple and Google’s other innovation was to open their operating system for third-party software, small programs called “apps”, which turned the phone into a small pocket computer useful for a wide range of tasks. App developers became thus a part of the “ecosystems” that both companies planted, understanding their approach more comparable to the work of a gardener than of an engineer. While Nokia still engineered its products to be inexpensive and to connect people, an approach that was successful until 2007, Apple and Google were busy connecting themselves with the people, the users, and the developers, and then connecting these people with the world. Users were prepared to pay a high price for this connectivity while developers invested time to develop the apps that made the other part of the eco-systems.

The rollercoaster case story of Nokia shows how a practice that led to success in one moment may cause failure in another one. It shows how managers may think they have found the philosopher’s stone, so that they can do without the philosopher. In the case of Nokia, the story spans ten years: five years of growth followed by five years of decline. In our project management world, the rollercoasters may run much faster; we may experience such dramatic changes in our business settings in ten months, possibly less. Nevertheless, many people in project management believe in our version of the philosopher’s stone, the “best practice”, and expect it to turn inexpensive lead into gold.

I wanted to know how popular the term (and the promise that it communicates) actually is. Between April and August 2015, I invited project managers from a global LinkedIn community to respond to a small survey to find out how popular the concept of “best practices” is. The project managers were asked to select the statement that they considered the best from the following list:

• “There are proven ‘best practices’ in project management. Applying them ensures repeatable success in any given project and project situation.”

• “There are no ‘best practices’ in project management. The same practice that has been successful in one project or project situation may fail in another one, and vice versa.”

• “Based on my experience and observations, I cannot support either of the claims.”

• “Other (please specify)”, followed by a text field for comments.

The participants of the survey were asked to select the response based on their experience and observations as practitioners and/or experts in project management. The survey was answered by 189 individuals. The responses are shown in Figure 3-1.

The selection “Other” had a comment field, where alternative responses could be given. Most pointed in the direction of the first answer that “best practices” exist in project management, but questioned their repeatability and universality in statements such as:

• “There are best practices that increase the probability of repeatable success, but success cannot be ensured.”

• “There are proven best practices, but in countries like mine, with a lot of informality, it’s difficult to apply them, but not impossible. I think we should continue working on it.”

• “Best practices exist ... depends upon the ability and maturity of the PM.”

The participants were also asked to select their gender and their relation to project management with the options:

• I am a practitioner in project management (46.6%).

• I am a practicing expert in project management (19.0%).

• I am a non-practicing field-expert in project management (Trainer, Coach, Consultant, Auditor, etc., 8.6%).

• I am a non-practicing off-field expert in project management (Researcher, Academic instructor, Developer of PM Software, etc., 2.3%).

• I am a beginner and/or assistant in project management and do not have much experience (20.1%).

• Other (please specify, 3.5%).

Figure 3-2 shows how the different group responded to the question. There was no statistically relevant difference between male (70.9%) and female (29.1%) respondents. With growing expertise, the skepticism on best practices seem to grow, but one should be careful with the off-field experts, as a number of four respondents is too small to be statistically significant. It is also that beginners and project assistants seem to be more skeptical towards best practice concepts; they may learn to believe in them in their work with project managers.

The respondents came from 49 different countries. I also wondered if there is a cultural bias influencing the belief in “best practices”. For countries or regions with 10 respondents or more, I computed the percentages of positive answers as shown in Figure 3-3.

Interpret these numbers with care. There were between 10 respondents (Latin America including Mexico) and 54 (U.S. and Canada) who took part in the survey. These may not be enough to draw strong conclusions, and the method was not 100% scientific, using an online survey with self-selected participants. What the survey did show is that a major percentage of project managers believe in “best practices”, and the popularity of this belief is stronger in some cultures than in others. Additional education will be necessary to help project managers develop a more critical and situational understanding of their discipline, especially given the large number of new project managers who are thrown into projects without proper preparation, education, and authorization, ignoring the disastrous effects on their self-esteem and their resumes.

3.3 A Research Project

Project management is a difficult discipline. The interaction of projects with their organizational, social, economic, and environmental context is highly complex. While project managers are active agents of change by administering 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 a close. This is because business situations and interests, management strategies, standards, and laws may have changed during the project lifecycle. Another aspect of complexity is the continuous need for interaction with stakeholders: people, 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 who need attention and who can claim changes on the project and its outcomes, vested at times with good cause, not vested at other times. While project management is often considered an engineering discipline, managing stakeholder perceptions and engagement are typically not considered an engineer’s skill because of their generally non-quantitative nature. In 2014/2015, I did some research with the University of Liverpool, U.K., to address some specific questions that arise in this highly organic, dynamic, and discontinuous field^†. In this chapter and in Chapter 4, I would like to report the results of this research and draw conclusions for our practical work.

The most characterizing attribute for a project is “unique”, as discussed in Chapter 1. The uniqueness of projects sets them apart from operations, whose trademark is repeatability. Responding to this uniqueness is what sets SitPM apart from the “one size fits all” concepts that are often communicated in literature, but easily identifiable by their ignorance of the simple fact that the same practice that has been successful in one project situation can fail in another one. Applying situational intelligence is a more difficult task, because one has to replace book smartness with street smartness and simple, quick solutions with considerate awareness of the consequences that actions can effect, intended results as much as unintended ones.

Uniqueness is not that difficult to manage and to understand. A common way to help structure unique things is to classify their variability by using typification. Skin burns, for example, are each unique as well as the things that caused them. Different burns need different treatments; otherwise, the treatment may not be helpful and may even increase the damage of the skin. In medicine, a typology has been developed for burns with several degrees^*:

• First-degree burn: The outer layer of the skin (epidermis) is dry, red and painful.

• Second-degree burn, partial thickness: Affects the epidermis and upper parts of the dermis.

• Second-degree burn, full thickness: Affects the epidermis and most parts of the dermis.

• Third-degree burn: Destruction of all layers of the skin and subcutaneous tissues.

• There is even a fourth degree mentioned sometimes that involves muscles and bones.

For each degree, proper treatment is different. A first-degree treatment may be done at home (be careful with children!), and after a week, the burn should be healed. If one has a deep, second-degree or worse burn, one may need to seek clinical treatment. One can also classify burns according to their cause, for instance open fire or electricity, or measure the surface area affected. While each burn is unique, typification and classification helps determine the appropriate treatment. Classification can also help in the ongoing treatment of the burn. Specific research and development has been performed for the different degrees, and the findings of the research for a specific degree are not thoughtlessly carried over to treat burns of other degrees.

In the introduction of this chapter, I compared project management to Chemistry before the invention of the periodic table, its most fundamental classification system. Chemistry by that time was rather alchemy. Although project management is much less a science than it is a very practical task, we should require evidence for claims that are made and distrust promises of simple solutions when the task of project management is a difficult and complex one. Projects often must be navigated through unchartered and unmapped waters, of whose existence the promoters of the solutions were not aware.

3.4 Mark 1 Projects and Mark n Projects

We took these terms from engineering and British sports car manufacturing. A Mark 1 version of a machine is the first generation, highly innovative, but also far from being optimized. A famous historical example is the British Ferranti Mark 1, the first fully electronic, general-purpose, and commercially available computer. Two units were built. The first was delivered to the University of Manchester in February, 1951. Interestingly, the next version was not called Mark 2 but Mark 1 Star, probably to further signal the still highly innovative character of its design; Ferranti sold nine computers of both versions. The designation Mark 1 is mostly avoided in order to not communicate the potential immaturity of a development to a market place. Between 1962 and 1991, U.S. auto maker Chevrolet numbered the follow-up generations of its first V8 (Big Block) engines used for powerful passenger cars and medium duty trucks Mark II to Mark IV. Japanese camera maker Canon did the same with its top-notch camera body EOS-1D, whose follow-up versions were called EOS-1D Mark II through Mark IV between 2004 and 2011. This allowed Canon to further use the established name but, at the same time, to communicate to the customer: We have an improved generation available. You should consider buying this product now, if you still have the old one. Mark 1 communicates revolution; Mark n signals evolution.

When I asked practitioners from a total group of 517 respondents, a majority said that their projects are of the Mark n type, but Mark 1 projects were not rare at all^* (see Figure 3-4).

A Mark 1 project is new. It may be some great, major innovation, similar to the Ferranti Mark 1, whose development and manufacturing could build on the experience of its team to build experimental computers, but making a commercial computer was something new. Ferranti had to give customers the assurance that it would work without the flaws and safety hazards for users that people would accept in an experiment. The project must have been a challenging task for the developers. In other Mark 1 projects, the task as such may not be new at all but is new to the team. The novelty may then lie in the use of unknown technology for a known task in an environment that is yet unchartered, at least for the team or in anything else that distinguishes the new project from past projects to a very fundamental degree. I remember, for instance, the first one-day congress that the PMI Münich Chapter held in 2000. The chapter is a regional, not-for-profit organization incorporated under German law and works based on a charter agreement with the U.S. Project Management Institute (PMI^®). The congress was organized by approximately 30 volunteers, two of whom acted as project managers for the event. All volunteers were seasoned project managers, but none of them had ever organized a congress. The original intention was to allow 10 months for planning and preparation. During initiation, members of the chapter board did a Novelty, Technology, Complexity, and Pace (NTCP) analysis as proposed in 2007 by Aaron Shenhar and Dov Dvir^*. As mentioned, NTCP can be interpreted as four typological dimensions. The project was rated in each of the dimensions along scales with three to four steps from low to high. The underlying assumption is that each dimension contributes to risk—the higher the project scores on it, the higher the overall risk is deemed. Figure 3-5 shows what the project looked like in the analysis.

• Novelty. A one-day congress is of course nothing fundamentally new. It was new to the participants, who were experienced in managing projects in IT, electronics, engineering, and other industries. None of the volunteers who performed the project for the chapter had any experience in conference planning and management. This lack of experience had several consequences: Decisions that an experienced event manager would do quickly took them more time for discussion and deliberation, and they also needed time to fix errors that they made, once they became obvious. The novelty also came with a disbelief in the group’s ability to run the project. The manager of a company that I approached to support the project as a sponsor clearly told me that he had experiences with such events in the past and did not believe that the team will succeed with the task. He would not want his company logo linked with a failed event. Novelty was set at maximum: Breakthrough.

• Technology. Some technology was needed before the congress for a call for papers and for a system to register attendees. Some more technology would be needed during the congress for sound and presentations, etc. This was easily available, so that we gave technology a medium-tech rating.

• Complexity. This referred more to organizational and interpersonal complexity than technological. The chapter’s economic opportunities were limited by the time, and a failed congress could derail the chapter financially^*. A congress needs many investments upfront, but most of the income for congress sponsors and tickets comes relatively late. Liquidity could become a problem. In addition, we had to take care of the interests of hundreds of stakeholders including our members, the long-term sponsors of the chapter, PMI as the chartering organization, and of course of our volunteers, who spent hundreds of hours of private and unpaid time for the project. Further complexity was on the marketplace where another association and some commercial providers run similar congresses, organized by experienced professionals, tapping the same budgets of potential attendants that we would need for our congress. We rated the project as “Array”, the highest grade on the complexity scale.

• Pace. The original time frame from the initiation of the project to the date of the event was planned with 10 months, which would have been “time-critical” in NTCP language.

Discussions in the board and with the volunteers came out with an assessment that this approach would be too risky for the chapter. One solution would have been to hire a professional event manager, who would reduce the rating for novelty. This was something we did not want to do since it is part of the mission of the chapter to open opportunities to volunteers. The alternative solution was to give the team more time. The event date was postponed by nine months. Allowing the team almost twice the time made it easier for the volunteers to discuss open issues and make difficult decisions and allowed for more time to fix problems. Another interesting aspect was that it took pressure from the cash-flow side. It allowed for more time to find event sponsors and have income before early investments needed to be made, and sponsors would have the benefit from a longer period, during which they were visible on the congress website, so they could expect a higher return on their investment. As soon as the first two congress sponsors were on the website and showed their trust in us, it was much easier to find more sponsors to support our event.

When the date had been postponed, the NTCP diagram looked as shown in Figure 3-6.

The example shows how novelty can impact a project. In the chapter project, this impact could be made more manageable by allowing the team more time. In other projects that need to meet contractual or legal deadlines or have to deliver before a market window closes, such a solution may not be possible, and other solutions need to be found.

The development of the project terminology discussed in this chapter was based on experiences and observations of field experts, in which the various types occurred, and the topic, novelty, appeared seven times. It was in this research that we discovered that novelty was the most important factor that made the experts see practices fail that have been successful before and vice versa. This confirmed the novelty dimension of the work of Shenhar and Dvir. But there was also a surprising observation: Of the seven projects named by the experts, where novelty was the greatest problem, high novelty was only the problem in two of them. Five of them suffered from low novelty. The Mark n projects have risks that are greater than the risks that come from navigating in uncharted waters: routine, complacency, and ignorance of risk. With repetition, the aspect of uniqueness, the most characterizing aspect of projects, is more and more ignored, and a dulling feeling of routine creeps in, which was not expected. When such an attitude develops, one often hears statements such as “we have done this before”, “we know how to do this”, “we have a proven formula”, and “we have developed excellence in this field”. Then, projects are not regarded as new challenging endeavors in which stakeholders must remain alert for the unexpected, but as simple derivations from former projects. Repetition saves cost and time, as long as the project follows the plan. But then, seemingly marginal and negligible influence factors, which no one takes care of, can grow, cause major problems, and finally derail the project in an unanticipated way. I observed such problems frequently in software integration projects. The teams assumed that existing software in an organization was documented in a way that its process flows, data structures, and interfaces are easy to understand, and that interconnections between different software solutions can be built without difficulty. When the team then tried to connect its new solution with the existing ones, problems arose from incomplete, often false, documentation and from the many workarounds that were implemented in the old software solutions without any documentation, as hotfixes during implementation and operations, possibly years ago. For a small contractor working for a customer under fixed-price contract, such a situation can destroy the entire existence of the firm.

Another example that I came across was an international software rollout for a multi-national corporation in 28 countries, which went well in the first 27 countries, but stakeholders in the last country wreaked havoc on it. They had made themselves comfortable with special software that was developed specifically for them, and the fear of losing autonomy and independence was greater than the joy of getting a new and more modern solution. Part of the problem was probably that their old software had some functional deficiencies that allowed them to conceal operational inefficiencies and, as a consequence, to keep the work-force higher by numbers than what was necessary. Had this country been the first to implement the new solution, the project team would probably have been aware of the risks and would have addressed them in their approach; however, after 27 comparably easy implementations, the team just wanted to follow the so far efficacious formula and finish the project on time. Its members were not prepared for a new kind of problems with people. In the end, the corporation’s upper management had to interfere, managers in the country operations got replaced, and branches lost autonomy in more fields than just software. For the project, it was this country that caused the team to miss schedule targets and to exceed a budget, which was originally based on realistic assumptions.

3.5 Greenfield Projects and Brownfield Projects

An interesting example is a comparison of two recent main-station mega projects in Germany: Berlin’s Hauptbahnhof, after its completion in the year 2006, was mostly considered a major success, and Stuttgart Hauptbahnhof, whose renewal project ran into a state of deep crisis in 2010. It is interesting to compare the two projects (see Table 3-2).

A further commonality is that both projects were managed by the same project manager who generally applied the same practices using a highly detailed plan with a long planning horizon, which he rigorously protected from change requests in any form. What was the difference?

Berlin Hauptbahnhof was a Greenfield project in the literal meaning of the word. The fall of the Berlin Wall in 1989 and the reunification of the city of Berlin left a spacious but thinly occupied and mostly unused strip of fallow land crossing the entire city in the North-South direction. The wall was effectively a system of two walls with cleared land between them. It was often referred to as the “Todesstreifen” (Death Strip) because it was a complex fortification built to prevent the people from East Germany from fleeing to the West. Its demolition left a 43.7 km (27.3 miles) long and up to 500 m (550 yards) wide band of unused land, which gave city planners the rare freedom to develop a new town center without having to pay attention to people living nearby and for legacies. There, they could build the station and other infrastructure following the vision of the architect and the technical and organizational requirements of a 21^st century traffic hub.

Stuttgart Hauptbahnhof was different. The existing central station was constructed as a terminus, a dead-end station, where trains have to reverse directions. Termini are stations that must occupy much more space than through platforms, as the trains use the same track area to arrive at the station and to depart again. It is logistically more difficult to manage, and the travelling time lost for a train that needs to stop in the station on its way is much higher. Stuttgart is a major station on a currently developed high-speed railway connection from Paris, France, to Bratislava in Slovakia called “Magistrale for Europe”, a program that is intended to cut the total travelling time over the full distance from currently about 11½ hours to eight hours. The railway construction in the Stuttgart area includes the partial demolition of the current historic (and iconic!) station building, building a new underground through platform station with eight tracks (replacing the 16 dead-end tracks) and 33 km (20 miles) of new tunnels built for speeds up to 250 km/h (156 mph). The problems began with citizens (stakeholders in the modern understanding of the word) questioning the consequences of the tunnel drilling for their homes on top of the underground construction site. The tunnels had to penetrate layers of anhydrite, which swells by 60% when in contact with water, and a lot of water is used for tunnel boring.

When geological layers swell, they pose a threat to buildings on top, and such a case had just happened not far from Stuttgart in a small town called Staufen im Breisgau, which had invested in a geothermal heating system for its town hall, for which engineers pressed water into layers of anhydrite under the historic town center. The swelling anhydrite affected cracks in foundations and walls of the houses above and threatened to damage gas pipes and other underground infrastructure^*. The alarmed home owners in Stuttgart tried to contact the project manager to discuss their concerns, but he reportedly refused to speak with them. The plans had been open for public review some time ago, following applicable law, and the appeal period was over.

The ignored stakeholders then did what stakeholders commonly do in such a situation: they called friends and lawyers for support and looked together for vulnerabilities of the project, from hazards for endangered species to dangers for the ground water; major demonstrations followed, and the construction was massively disrupted. The following upheaval in Stuttgart and the state of Baden-Württemberg went far: The project manager resigned from the project, and the political party governing the state lost the next election. There were two periods of construction freeze until the work could be resumed. The estimated project costs increased during this time from 4.4 million Euros to 6.5 million, partially because of the freeze and changes to the plan that were necessary with the protests in Stuttgart. The project has started again and is expected to be finished in 2021.

The approach of the managers responsible for the project has changed dramatically since the time of crisis. Before 2010, there was a small Citizen Information Center with models and animation movies shown, and a simple website with some basic facts and news was offered for an interested audience. Since 2011, these media improved greatly. As a new medium, a public discussion platform was introduced called “Bürgerforum” (citizen forum), which allows citizens to raise their concerns during the project and discuss them with experts and representatives of the project shareholders. The objective is to ensure public support for the project and reduce damages and disruptions for the city to the minimum that is unavoidable.

The shareholders of the project learned the hard and expensive way what it means to run a Brownfield project such as Stuttgart 21: the project team has to consider the influence of a large number of stakeholders, who cannot simply be ignored, as they (and their friends) often have options at hand to cause significant damage to the project. One has to manage legacies that can impact project success and has to limit the damages and operational disruptions that the project causes. In this type of project, the leeway for project activities is significantly reduced, and the need for intensive communications and rapport building are an additional challenge for the team.

I believe that the project team in Stuttgart is capable of constructing the tunnels without jeopardizing buildings on top. Stuttgart is surrounded by hills, and many tunnels have successfully been drilled there, so a lot of experience in tunneling through anhydrite layers is available. What the team was not able to do in 2010 was to build trust in this capability by people possibly impacted and engage them as supporting stakeholders.

Practices favorable for Greenfield projects may not be appropriate for Brownfield projects and vice versa. Does this principle also apply in other industries and application areas? A few year ago, I did training and workplace coaching for a number of project managers from a major U.S. company that implemented human resource management software in customer organizations. They had some successful projects in smaller companies that had no clear HR processes implemented, and the software projects were also business re-engineering for these customers: replacing existing ad hoc approaches with clearly described processes that were step-by-step supported by the software. These customer companies were comparable to Greenfields for the project teams and the software and could be performed with a focus on technical questions. Three of my students were then assigned to a project for a major government agency that had HR processes defined and in place, and the software was expected to support the existing processes rather than modifying the organizational processes to go with the software. My students were not prepared for the problems that came with this requirement. For them, it was just another Mark n project, repeating the well understood tasks of the previous projects. It is much easier to adjust an organization to a software program than vice versa.

The greatest resistance came from employees in the customer organization. They had been given formal job guarantees, so they did not have to fear unemployment or demotion; but they were not given guarantees that after the software implementation, they would still do the same job, remain in charge for the same tasks, and remain in their same offices, where many of them had been for years. As mentioned in Chapter 1, people personalize their offices and become attached to their environments. These people also felt they would lose the familiar job environment and were frightened of the unknown future for them. The project depended on their cooperation and support, but it did not happen. The agency employees had to describe to the team how their processes functioned, so that the team could mirror them in software, but these descriptions were not given, or if they were given, they were late and incomplete. The implementation of the software was delayed by months, and the company lost money because of many hours that the team worked for the customer that could not be billed and damage claims from the customer based on the contractual conditions for late deliveries.

When I was asked to help, the manager of the project managers privately let me know that he considered his people too soft. Given the situation, I would disagree: a tougher approach toward the customer’s employees would have increased the resistance by the people, whose support the project needed and who were in a position to damage the project in a way that the blame would have fallen on the contractor, not on them. Spending time, energy, and empathy on building rapport and engaging the employees in an early stage would probably have been more successful. They were project engineers who focused on technical aspects, more than project managers who would do stakeholder management and engagement. Project engineers are the right people for Greenfield projects. For a Brownfield project, one needs project managers.

How literal should one regard the terms “Greenfield” and “Brownfield”? When Nokia (see the previous case story) decided to leave Bochum and move their production to Cluj in Romania, their basic aspiration was to build a “Nokia Village” there, with outlets of their major suppliers in the direct neighborhood, to be able to ramp production up and down to follow the fluctuations of the market demand for their handsets. Bochum, densely inhabited and more expensive, would not have allowed this operational strategy. The area selected for the Nokia Village in Cluj was a literal green field. What they missed was that Apple, and in their wake also Google, developed new business on much wider and, as we know meanwhile, greener fields. They called them “eco-systems”, and there, they developed an unknown interconnectivity between hardware manufacturers, app developers, service providers, and customers; and with powerful processors and capacitive display technology that allowed “swiping” and other simple gestures, they revolutionized the perception by users that a smartphone is something “natural”. If Nokia in 2007 had understood the metaphorical and emblematic interpretation of “Greenfield” and reacted accordingly, they might still dominate the mobile market today.

3.6 Siloed Projects and Solid Projects

Who loves telephone or video conferences? Without the perception of local proximity and physical presence, the ability to fully use body language and facial expressions and with common disruptions that are often due to unreliable line quality, the meeting experience is more uncomfortable than pleasant for most people—at least those coming from business. A common observation is that people hope to replace the development of true team spirit with technology, because the first is expensive, the latter is not. This meeting experience can be further deteriorated when the team is internationally dispersed. The project manager wants the project to move forward quickly, but instead it wobbles and the team spirit deteriorates over time. In addition, virtual projects are more likely to run into difficulty because of misunderstandings.

Here is another interesting case story: On December 11, 1998, the U.S. space agency National Aeronautics and Space Administration (NASA) launched a probe, called Mars Climate Orbiter, to the planet Mars. It was intended to study the atmosphere of the planet from a circular orbit around the planet and also to be used for the transmission of communications with another probe, called the Mars Polar Lander. That project began three weeks later. After a bit more than nine months, on September 23, 1999, NASA lost the Mars Climate Orbiter shortly before it arrived at its final location. As part of the final navigation, the probe was planned to “skim” temporarily through the upper layers of the Martian atmosphere twice at the height of 226 and 210 km (140 and 130 miles) over the Martian ground and use the drag of the very thin atmosphere there as “airbrakes”. The probe instead dove deeply into the Martian atmosphere, down to an estimated 57 km (35 miles) distance from Mars’s surface. The Mars Climate Orbiter was designed to withstand the drag from Martian atmosphere down to a minimum height of 80 km (50 miles); at the 57 km height, the probe got destroyed or, if it survived, was then pitched into open space.

After the loss, NASA immediately created a “Mission Failure Mishap Investigation Board”, which published a 35-page report on November 10, 1999, seven weeks after the incident^*. The report said:

Root Cause: Failure to use metric units in the coding of a ground software file, [called] “Small Forces”, used in trajectory models.

The statement referred to a software program used to calculate the combined effect of airbrake force and brake rocket thrust. It passed its data to another software system, but numbers were false by a factor of 4.45, using lb-sec instead of the required and expected Newton-sec (1 pound = 4.45 Newton). Therefore, the rocket thrust was insufficient to navigate the probe into orbit as desired. The problem had existed over the entire course of the probe, and little errors in rocket firing added up to others, but remained unnoticed until the probe was lost. If it had been identified and communicated early, the problem would have been easy to fix.

The use of the term “root cause” at this point is probably not accurate. The next question in a “five whys” analysis would ask: “Confusion of metrics is a significant problem; what is its cause?” A simple answer would be that someone, possibly a subcontractor, did not adhere to a contractual specification, which required the use of the metric system. This answer would be a classic case of finger-pointing and may be useful in court, but would not help fix the problem and avoid repetition in the future, especially given the complexity of modern supply networks that require cooperative solutions. Another root cause could be identified in the concurrent use of imperial and metric units at NASA, following the Metric Conversion Act of 1975, which made it a policy to “coordinate and plan the increasing use of the metric system in the United States”. Having two competing standards at a time inside an organization is a common cause for confusion and errors.

The report states some “contributing causes”, which are also interesting:

• Navigation team was unfamiliar with the spacecraft.

• System engineering process did not adequately address transition from development to operations.

• Inadequate communications existed between project elements.

One may see these statements from an engineering viewpoint and implement processes to avoid them. This approach is what NASA obviously did. The result, however, was the development of a complex rule-book, too large and complicated to be fully read, understood, and implemented and leading to the opposite of its intentions. Also, it is not implausible that the requirement of using the metric system in the project was overlooked by people, because of the large number of requirements and rules that they have to remember and apply. Someone may have simply lost track of them.

I already mentioned Conway’s law, stating that systems mirror their design teams. A communication slip-up between the components of a system has likely its root cause in a communication problem inside the design team. There were many organizations involved, including:

• NASA, Washington D.C.

• Jet Propulsion Laboratory (JPL), Pasadena, California, a division of the Caltech (California Institute of Technology)

• Lockheed Martin Astronautics, Denver, Colorado, prime contractor

• Subcontractors over several tiers

The different players in the multi-player game had different interests. NASA as a government agency was accountable to politicians and finally to the public for accountable and successful use of tax money. Caltech was interested in the engineering and science aspects of the project (and probably also in the monetary income from it) to stabilize and further develop the position of the institute as a leading academic establishment. Lockheed Martin was interested in good news for its shareholders with profits and securing future business. Fragmentation had a geographical dimension but also a business aspect. While the silo structure of the project was probably unavoidable, the project needed to be managed in a way that addressed the issues that arose.

NASA by that time followed an approach called “faster, better, cheaper”, which also had a negative influence on inter-team communications. Communications are costly and time-consuming, especially among geographically dispersed teams. An obvious and quick way to reduce costs and speed up an underfunded and understaffed project is to reduce the number and intensity of meetings and use team building, training, and other means of active networking. A basic problem of networking is that there is no business case for it. One cannot compute its expected monetary benefits against its costs and project a return on investment. The value of networking is only assessable from hindsight, when errors are made that are due to a lack of team communications and also a lack of visible team spirit. However, well-developed networks can help in coping with unexpected problems in an effective and efficient manner. I am certain that for Mars Climate Orbiter, the communication error of the software systems was preceded by a communication problem of the teams involved. In “faster, better, cheaper”, the most urgently missing element is “people”.

An objective of the investigation report of November 10, 1999 was to protect the concurrent and tightly related project Mars Polar Lander from similar mishaps. This probe was planned for landing on December 3, 1999, and it also got lost, together with two probes called “Deep Space 2” that were launched with the same rocket and accompanied the lander on its journey to the Martian surface, where they should have impacted in a distance of 60 km. A “Report on the Loss of the Mars Polar Lander and Deep Space 2 Missions” from March 2000 stated the most likely cause of the loss of the lander was a touchdown sensor in a landing leg that was spuriously activated, and based on this reading, the lander controls prematurely cut off the landing engine, assuming that it had already touched down, while it was still 40 m above ground. The impact of the lander in this case had a velocity of 22 m/sec instead of the 2.4 m/sec for which it was designed^*. If this explanation is correct, Mars Polar Lander was also lost due to a communication problem between system components. One component caused vibrations or similar tremors that another component misinterpreted as a valid signal, which then lead to a chain of programmed responses. The impression is that the teams involved in the development should have talked more with each other to identify the risks and find solutions to avoid them and make the system failsafe.

Solid teams are much easier to manage. Colocation, placing a project team at one place, is considered a good practice for project team success. Famous examples are the Lockheed Martin Advanced Development Center, the Skunk Works, near Los Angeles, USA, for military aircraft (since 1943), Porsche’s Development Center in Weissach, near Stuttgart, Germany, for sports cars (since 1971), or the Gotenyama facilities in Japan from 1946, where Sony developed the first commercially successful transistor radio, launched in 1955, and laid the groundwork for the modern consumer electronics industry. Colocation shortens the way between team members to coordinate their work and build team spirit, eases communications, reduces bureaucratic overhead and the need for formal meetings, and simplifies the identification and resolution of misunderstandings.

There are also many examples of development teams distributed around the world. Their managers like to show off with the 24-hour development they do, as at any time someone in the world is working on the project. They use phone conferences and other technologies a lot, but the communications do not occur as often as in colocation. With time zone differences, someone has to get out of bed to attend. Face-to-face meetings when technological solutions prove insufficient require travelling, which is expensive, and the time needed is mostly unproductive for key staff. When companies see the need to cover costs, reducing travel is often among the first decisions, irrespective of the effects that this will have on their distributed project teams.

Culture is another issue. In a face-to-face setting, cultural issues are easier to avoid and to fix if someone puts “a foot in it”. In a collocated environment, it is also easier to forge a team from members from different organizational units, or even different organizations, to enhance team spirit. Protection of classified data, by the way, is also easier in solid teams; employees of contractors, possibly in remote locations, can take away information much easier than people from the performing organization located together.

Is every virtual team a siloed team? Not necessarily. Sometimes the members of a project team have worked together in the past and are now dispersed across units, organizations, or locations. The strong rapport that these “old boy networks” (that may well include girls) have developed in the past may then be sufficient to keep up the solid spirit even over organizational or physical distances. Collocated teams in turn may be quite siloed: Staff members from different organizations or units have been brought together, but while the physical proximity is high, the organization is not, when the team members are instructed to follow different business objectives and have their own, often hidden, agendas.

Is colocation a “best practice”? Sometimes not. In some projects, proximity to local markets may be more important than among the team members. Facebook, for example, does most of its development work in Menlo Park, California, USA, but has worldwide teams distributed over 53 other locations to run projects together with their multinational clients. These offices are dedicated to customers, but also to lobbying and other forms of political influences that also require closeness to a target audience more than among the team members. Another reason for the preference of distributed teams may be the desire to tap hot spots of skills near to Universities or to companies that can make valuable staff redundant, or simply to places where certain resources are easier and less expensive to acquire.

Siloed teams should be managed with care. The cost benefit from distributed development has often turned into a monetary nightmare, when the costs of managing the teams exceeded the expected savings. The benefit from contracting work that an organization does not want to do with its own staff may vanish when the contractor causes new problems, for instance, because the company has financial problems. Technology may help to “solidify” teams, but the dangers are high of replacing human interaction with digital solutions.

The problem of team integration at NASA has been addressed in a second report by the Mars Climate Orbiter Mishap Investigation Board. While the first report had its focus on inadequate processes, the second focused on people. The report recommends to support (or replace) the “faster, cheaper, better” approach with a new one called “Mission Success First”. It recommends to put the common interest of a project team over the particular interests of its team members^*. In 2015, NASA had multiple success stories. Its Mars missions sent data and images from the planet with an impressive level of detail. NASA published images of the micro-planet Ceres and also of Pluto and its moon Charon that showed incredible detail, celestial bodies that before had only been blurred spots on images from observatories, and the scientific revenue was immense. With these successes, claims that money invested in their space programs would be wasted have become much rarer. Good project management is a great tool to ensure project support by stakeholders, and solidifying teams is a good way to achieve this goal.

The dynamics of success and failure dictate that we will often not have the time and budget, but possibly also not the strategic support of upper management to solidify the teams involved. Some organizations have developed solutions for such situations; the most radical was probably Volkswagen with their Modularer Querbaukasten (MQB), a modular kit for lateral engine placement, and Modularer Längsbaukasten (MLB), a modular kit for longitudinal engine placement design approaches. In essence, each is a collection of building blocks that have been developed independently and asynchronously. Volkswagen developers can take and swiftly re-assemble them to design a new car, in contrast to platform approaches that build one model based on modifications made to another one. The building block approach is used across its different brands (VW, Audi, Porsche, Seat, etc.) and has helped Volkswagen become the global market leader in passenger cars by numbers in 2014^† and number 2 on the automotive world market by revenue^‡ after Toyota.

Volkswagen is also a good example of the risks that come with the approach: In September 2015, it became known that software used to control engine functions during testbed simulations was illegally altered to reduce the NO_x contents of Diesel motors in laboratory emissions testing, but reduced the effectiveness of the NO_x cleaning mechanisms during normal driving. The motor, an essential element of both the MQB and MLB design approaches, drives an estimated number of 11 million cars worldwide, built between 2007 and 2015. In combination with a result-driven management approach (“I do not care how you achieve the goal as long as you achieve it, and no, there is not more budget than what has already been allocated!”), a small group of engineers in highly siloed development projects was obviously able to secretly jeopardize the future of the corporation and its almost 600,000 employees by seemingly meeting emission goals, while no one seems to have asked how they met them. They placed a time bomb in the motor that went off in September 2015. For decades, Volkswagen staff repeated in conversations an aphorism, “If the company knew what the company knows”, and the events of September 2015 showed how much truth the statement holds. When a modular system, which needs trust in the functioning of each element, collides with a high-pressure environment, which nurtures a culture of distrust, hidden agendas and finger pointing occur almost naturally, and concealed time bombs threaten the long-term success of project deliverables and their owners.

A positive observation at Volkswagen is that the company quickly identified the root cause of the problem and took immediate measures to change this culture. Whether they will succeed in changing a behavior that has spanned decades, with a sustainable effect, will be an interesting observation in the following years.

As project managers, our responsibility is limited to temporary endeavors, not to entire organizations that are expected to last for decades. The problems that we face in Siloed projects can be similar, however. Siloed projects can be successfully managed by carefully designing the interfaces between the different teams and their modules, but one has to take care that one unsound module may damage the entire system.

3.7 Blurred Projects and Focused Projects

There is a common conception of projects as endeavors with a defined moment of beginning and another as its end. They focus on achieving defined objectives, that are clarified and agreed upon, and management attention ensures that resources are available for the project as needed. There is, of course, a maximum number of resources that the performing organization is able to provide; nevertheless, project managers know which resources will be available to them and which will not. Start and end dates may need revision before their occurrence, and the project budget and the requirements that the project must meet may also be reconsidered and changed from time to time, but between these changes, the key data are well-defined and stable. In this type of project, the same clarity is assumed for the key players in these projects: There is no ambiguity about who is part of the project team, either as a worker, a decision maker in charge, or both, or each person’s area of responsibility. In construction projects of this type, workers and other team members are allowed to enter the site; others are not. Developers and other team members in a focused software project get access to data, code, and design that others will not get. The people involved in the development of a new car model will know what it will look like, how fast it will run, how much space it will have, and so on; others in the company will not. The clear designation of people and things that belong to the project, of objectives that the project is dedicated to meet, and of the other key data about the project is an important concept in project management, and it is applied in many projects where this clarity supports the success of the project, if it is upheld to the end of the project.

There are other projects, which the experts described as “blurred”. The reason for the blurring of the project may be ineffective project management, but the difficulties to separate the project from its environments and to produce clarity regarding objectives, people, start and end dates, etc. may also be inherent in the nature of the project. It may also be decided by senior managers. Clarity comes naturally with commitments, and organizational leaders often have difficulties committing to the projects they are performing in a reliable fashion and to the project managers who they in turn hold accountable for the results of these projects. Project managers then often have difficulties finding the balance between claiming too much clarity or not enough, between accepting the uncertainty they find themselves in or fighting a battle for clarity that the organization possibly cannot give them. Often, it is a problem in a weak matrix environment, where a functional organization uses its own resources for continuous production, services and other operational activities, and the demand for resources is hard to predict. If the market demands a large volume of the products or services, operational staff will have less time to work on the project. At other times, people may want to join the project team and influence its outcomes even though they were not originally part of the plan. This common unpredictability of demand can make it hard for organizational leaders to reliably assign functional resources to project work.

Many project teams have to multitask their work. From a manager’s view, multitasking has the benefit of higher resource usage. For example, if a person is idle in one task because the task depends on yet undelivered input from another task, the person may be allocated to another task and stay productive. Multitasking also comes with the expectation that the organization can meet a variety of concurrent requirements with a limited number of highly flexible employees and contractors timely. In multitasking situations, one can often see resource assignments using percentages. Assigning generic resources early in a project by percentages can be helpful as a tool of progressive elaboration of a project plan. A statement such as: “We will need a developer for the project in March or April next year, and the person will have to dedicate 50% of their working time to the project” can be helpful when the actual assignment is still far away. Later in the project, when more information is available and progressive elaboration is applied to clarify the assignment, the generic resource would be replaced by a specific one, and the plan would be refined, as shown in Figure 3-7.

This process can be considered normal. Problems commonly occur when the percentagebased assignments are still used for the refined plan and during execution. When one asks what the 50% assignment means in reality, one rarely receives a clear answer. The agreement for the availability of the team member remains blurred. If a team member has been assigned for a 40 person-hour activity to work over four weeks (160 h) two hours per day, the project manager can expect that the person will be available for that time, and any changes in the availability would need to be agreed upon with the project manager. The project manager can also track the progress and identify early if the 40 work-hours estimate turns out to be sufficient or not. If a team member is assigned for 25%, no agreement has been made when the work will actually be done, and if the team member has not done anything for the project in the first two weeks, there are still two weeks left for the activity, so the project manager cannot complain. We discussed in the second chapter the learning curve for the project manager and how important it is to know things early and to be able to make decisions, when there are still many options available at a relatively low cost. A common sign of a blurred project is that knowledge becomes available later, and decisions are therefore also made later, at times when project managers have to choose among a small number of options that have become expensive.

A company, known as Weasel Ltd. for this case story, taught me another interesting lesson some years ago on focused versus blurred team assignments. Often overlooked is the uneasiness for team members in unclear chains of commands when they have to work for the project (or several projects) and the functional organization at the same time. A team member complained about contradictory instructions from the project manager and from the person’s functional manager. The problem was not caused by macro decisions such as business travel or major purchases the person had to make, but instead the cause was micro decisions that came several times per day—e.g., requests for urgent reports. The person complained that it was difficult to be a servant of two masters, but the blurred assignments made things worse, because the instructions from the two “masters” too often came at the same time and competed for execution.

The resolution was quite simple, implementing Figure 3-7: It was decided that the person worked for the project manager daily four hours before lunch and for the functional manager in the afternoon. The person knew at any moment for whom execution was expected, and the project manager could rely on the agreement and that the team member spent four hours of time working for the project^*. The functional manager first rejected the agreement, probably fearing that it came with a loss of influence, but turned to a positive attitude after a while, when the benefit became obvious that the project would not disrupt the team member’s work in the afternoon. It turned out, of course, that sometimes the agreement became too stringent when certain tasks demanded the team member’s uninterrupted work for more than four hours a day. As the agreement was clear and simple, changing it was also easy, in most cases, it just took a phone call to make quick changes to the agreement. The most interesting observation was that un-blurring the assignment reduced stress for the team member.

At Weasel Ltd., it was also interesting to see that the common over-assignment of team members ended. Percentages are something abstract, and organizational leaders that allocate their human resources using percentages commonly over-allocate them by over 100% across functional tasks and projects. While this effect is not rare at all, companies often ignore the logical effect: phantom resources that are used in plans but will not be available for the projects. Phantom resources are a common cause for the inability of projects to adhere to schedules and meet their deadlines.

Percentage assignments of human and other resources are not always a poor practice. Early in the planning process, or later in the process in situations when information on resources availability is still uncertain and vague, they can be helpful. Eventually, during progressive elaboration of the plans, they should be replaced by more accurate and robust information to allow for planning and progress tracking and for predictions on the remaining work.

Weasel Ltd. provided another example of how projects can get blurred. The company was a family run, mail-order company established many decades earlier and well established in its home market. Over the years, it optimized its business processes around a guiding principle that they called the “Catalogue Regime”. The company traditionally published and distributed two thick catalogues a year, one for summer and the other for winter business, plus a number of small catalogues over the year with special offers to allow clearing stock at the end of a season and intermediate responses to competing offerings and also some smaller market-specific catalogues, such as for gardening items or sports articles. The main catalogue had a thickness of over 1,200 pages, was over 1.5 kg (3.9 lbs), and contained between 15,000 and 20,000 offerings. The catalogue regime was developed in adaptation to the cycles of the clothing industry with its summer and winter collections and dominated all key business processes in the organization. Supporting it was a dominant requirement for the software in use, which was a commercial off-the-shelf enterprise resource planning (ERP) solution, tailored with a considerable amount of individual customization with a lot of home-made software added to it. By the turn of the century, the whole company had become a massive and heavyweight player in its market, trusted by customers and shareholders and a well-known name for its buyers for all kinds of goods that one could buy.

The catalogue regime was the center of gravity of the company; almost the entire business of Weasel Ltd. was orbiting around it. Contracts with suppliers were made to ensure reliable delivery at fixed prices during the six months that a catalogue was valid. Product innovation also had a six-month rhythm, a successor product could only replace an older one when the new catalog was published; if a new product was launched on the market just after the editorial deadline of the catalogue, it would have taken Weasel Ltd. half a year to offer it to the market. This was not a problem in decades when the business world was less complex, and many manufacturers geared their product renewal cycles to the catalog dates. The company was ahead on another dimension since it had its warehouse and road logistics processes accelerated that it typically did not send customers acknowledgements for incoming orders, they were just dispatching the goods three to four days after order receipt; order confirmation letters would not have been faster^*. Mail order by the turn of the century was one of the industries that was successfully built on a strong foundation of automation and optimization.

Then came Amazon.com. It started in 1995, as a small online bookstore during a time of Internet hype that ended in the burst of the dot.com bubble in the year 2000. Amazon’s business model allowed them not only to survive the burst, but also to diversify into a full-fledged digital warehouse and provider of digital services. Similar to Amazon, a large number of small and medium online shops grew as well, and some of them began selling their products on Amazon.com as an online platform, while others did it independently. Together, these companies changed the rules of retail business and accelerated the pace of change and innovation dramatically, and the mail-order business became true e-commerce.

The entire vending process from product selection through tracking the delivery and payment is now done online, the only activity not done online is the physical dispatch process. The speed of the new business outpaced Weasel Ltd. and similar companies, who seemed prompt and speedy before that time but now created the impression of being rather contemplative and inert. Online customers order over the web and expect dispatch on the next working day, sometimes even on the same day. The online business is much more driven by frequently changing prices, sometimes several times a day. For many products, especially electronics, prices have a tendency to fall over months until a better successor product is launched at a higher price, which is then also bound for decline over the next months. For many products, a distinction is made today between a “catalogue price” and a “street price”, which is not the price on the street but on the Internet. Also the information available to the customer has increased dramatically. Buying with a catalogue saved the customer from having to spend time and money walking through shops to compare prices, but on the Internet, price comparisons have become easy and simple, and of course, there are special websites that further speed up the process. Customers also rate products to give other customers hints on the perceived quality and usefulness of products, something a paper catalogue could never do. The catalogue regime with its six-month freeze cannot compete with the small intermediate catalogue,

Another ace up Amazon’s sleeve is its partnership program with independent, mostly small vendors who can sell their goods using Amazon’s infrastructure, often directly competing with Amazon’s offerings. Amazon offers them its services for logistics, billing, and payment. It seems counterintuitive at first that Amazon supports competing sellers, but the benefits they gain are worth the cost. Amazon earns a percent of the sales of the partners, and also gets information on how new products are selling and at what price. Amazon adds products to its own product portfolio that are already successful, and rejects those that are not. Amazon also gets information on its customers’ purchases from other vendors and can target its advertisements to specific customer requirements. The only way a traditional catalogue company can learn how well a new product is selling is by adding it to the catalogue. Sometimes, Weasel Ltd. rejected a product that became a bestseller with other vendors; at other times, it filled its warehouses with shelf warmers, items that no one wanted to buy. Weasel Ltd. could not compete with Amazon’s speed or with the information on products and consumers that Amazon had. Peter F. Drucker once wrote that if a company has a 30% market share, it is a giant in its market; however, this means that it has no knowledge of the other 70%, the share of those who are not the company’s customers^*. A point not addressed by Drucker was that these other 70% have no knowledge of what the company can do for them. Through their partnership program, Amazon gets information on these 70% as well, and these buyers also know Amazon. From time to time, Amazon will lose business to sellers in their partnership program, but as the customers do business inside Amazon’s bailiwick, the customers are not lost for the company in such a moment. Being a closed warehouse and an open marketplace at the same time is a highly powerful business model^†.

So why not simply drop the catalogue regime and move the business to an online platform as well? Weasel Ltd. had too many legacies to easily do so. First, this approach would have meant risking the traditional customer base. Not all clients were happy to order over the Internet, many still loved the catalogue and still do. Among them were many older and disabled people, who had difficulties leaving home and were happy to have an alternative. Many of them would not want to use Internet services. While this group of customers declined over the years, they were still important for the mail-order company’s business. These people were much less interested in daily price changes and in the rapid delivery that e-commerce promised, but they would also not have wanted to buy a product from the catalogue at twice the price for which it was meanwhile sold online. Customers in such a situation could also have taken Weasel Ltd. to court for discrimination; an allegation that the company would want to avoid by all means. It preferred to stand for the vendor who made customers happy, not angry.

Another obstacle for a quick change were the internal processes of the company and the software that supported them. They were highly optimized and had a lot of customization. IT experts know the basic problem with customization: it makes it difficult to make changes to systems. The vendor of standard software can offer customary routines that manage upgrades and changes to the standard components of this software, but for customized components, the owners of the software must manage changes by themselves. In order to change the systems, Weasel Ltd. had to rely on the availability of the people who originally developed the customization, often years ago, on their ability to remember what they actually did when they developed the customization, and on the completeness and correctness of documentation, which is rarely a priority in customization projects with tough deadlines and budgets.

One should also not underestimate how much these processes influenced the culture of the organization that was not open for a revolution. To implement change, Weasel Ltd. needed younger staff members, who often were not welcomed by existing employees. The corporation had started an online presence in 1995, not as an e-commerce platform but for promotion and to win new subscribers to its catalogue. The website was a fringe activity that did not touch the core business at all. But developing a new core business without damaging the old one was difficult. One of its major competitors tried to avoid the change, adhere with the old business model, and went bankrupt in 2009. Another competitor, much more enthusiastic about the opportunities that came from online business, changed its core business rapidly; too rapidly perhaps, moving all market activities to the Internet in only a few years’ time, and then went bankrupt as well.

Weasel Ltd. had some projects launched to carefully add online business to its traditional sales model. These projects could not simply focus on their own deliverables and be on time, budget, and scope and “put mission success first”, but got blurred by the need to continuously balance their contents and their pace to the changes that happened on the market and inside the organization. Weasel could learn some lessons from Anazon.com, such as developing a storefront for partner companies, but also needed to take care of its legacy business. In addition to operational effectiveness it had to develop business agility and adaptiveness to a fast-changing market with contradicting demands. The company hired external consultants and developers, who first had to develop a deep understanding in the way Weasel ran its business with the purpose to find new solutions without impacting existing ones. It seems Weasel Ltd. was finally successful in managing the split business. In 2013, roughly two-thirds of the business was done using the online channel, and the trend is clear that its future is in the online business, as a competitor of Amazon, which is business-wise more than 10 times larger and with faster growth, much less restricted by consideration for legacies.

A blurred project may not necessarily be a bad thing. It may also be a project that is mindful about the consequences of its performance and its deliverables and that coordinates its scope and pace with the organization for which it is performed to avoid damages to the organization and ensure business benefits.

3.8 High-Impact Projects and Low-Impact Projects

In the introduction to this chapter, I discussed the project called Heathrow T5, the terminal building for British Airways at London Heathrow, which opened in March 2008, and how its operation collapsed immediately after opening, and with it, practically the operation of British Airways. As a passenger of British Airways flight on the next day, I could see the disaster there with my own eyes, which was extremely unpleasant from the viewpoint of a traveler, but highly interesting from that of an observer interested in the subject matter of troubled projects.

Many project managers rely on their many years of experience, which are of course an important element of their professionalism, but two other important elements are education and observations. The interesting thing about observing other projects is that one does not have to make all mistakes by oneself. When others learn a lesson the hard way, one can learn the lesson as well without having to make the same mistake. Heathrow T5 is a definite example. What lessons can we learn from the case?

There were many analyses written on this major disaster; most of them focused on technical issues. A major problem area was obviously the luggage transportation systems that did not function as planned. The glitches were on hardware and software side, and the breakdown resulted in 42,000 pieces of baggage that weren’t returned to their owners until weeks later. It took British Airways two weeks to get back to a normal schedule, during which it had to cancel over 500 flights. The financial damage was enormous. It had to pay back fees to holders of tickets on canceled flights and cover the extra costs of tickets bought by passengers on other airlines in the short term, which were very expensive (like mine). It lost business from travelers whose trust in the airline was destroyed, and it had to cover the costs necessary to rework and repair the faulty systems. Still months later, it was reported that about 8% of the bags of travelers changing flights at T5 were lost.

There was a multitude of technical glitches and human errors that in combination caused the disaster, but there seems to be a main story line of events where the most calamitous mistakes came together.

The story begins during the planning and the construction of T5, which was actually two projects: First, a construction and infrastructure development project performed by British Airport Authorities (BAA), which, despite its name, was not a government agency but a privately held company as of 1986. In 2012, the company’s name was changed to “Heathrow Airport Holding”, and it functioned as a landlord at the airport.

The other project was performed by the tenant, British Airways (BA), also a privately-held company, and had the objective to enable the services necessary to operate the terminal. This project was mainly concerned with recruiting, organizing, and training people and arranging their working environments. The two projects were tightly linked, and it may have been helpful to put a program manager on top of both projects to integrate them.

This approach could have prevented the fragmentation of the joint program and competitive behavior between the projects, but such a position was obviously not implemented. Establishing a position on top would have meant BAA and BA giving up a degree of independence and sovereignty. The egos of executives at both companies may have been too big to follow such a program approach.

Measured in classical metrics of scope, time, and cost^*, the construction project was successful, delivering a large airport terminal on time and budget (£4.3 bln., U.S. $8.7 bln. in 2008). The formal risk management activities applied before the hand-over were enormous, and they were a popular subject for articles in special-interest magazines and for speakers in project management association events, but some risks were overlooked. One was the risk of game-theoretical dilemmas that are typical for situations where two organizationally independent, but subject-wise related projects are performed at the same location and call for conflicts on the technical, organizational, and inter-personal levels. Another group of risks was ignored because they lay beyond the event horizons of quality and risk management of the project managers.

Event horizons for quality and risk management mainly stem from the fact that one cannot consider all possible factors of uncertainty. The consideration of uncertainties is often restricted to those that are known from experience or mandatory by law or contract. Some people are better in planning ahead and considering a large number of uncertainty factors than others, but all humans have limitations in this competency.

Quality and risk management are mainly constrained by two elements: lack of time and budget, and domain restrictions. As an example of the first, testing and inspections are habitually regarded as disposable reserves in many projects, especially in those that are running out of time and budget. Both come late in most project workflows and are expensive as the time and money left may not be sufficient to do them as necessary. To make things worse, both may lead to rework that will cost additional time and money. So, they are often reduced or completely abandoned when deadlines and monetary limitations restrain the project. Domain restrictions refer to local or organizational distance, when certain activities that are relevant for the project are made by another organization and at a location that is too far away or hidden behind walls.

Lack of quality and risk management is easily discernable, when managers act based on trust in the immediate functioning of a complex system. Has it not been thoroughly designed and built by expensive professionals? This trust then replaces time to prepare for errors in the system. Instead of an attitude that assumes that the deliverables most likely have faults that must be found and fixed, with the possibility of a positive surprise when things work correctly from the start, a “Frog King”^† attitude is then taken that things have to work correctly from the start, of course, with the prospect of painful and embarrassing surprises, when they do not.

At the Heathrow T5 project, the parking zones for the staff were a technical root cause of the problems in March 2008^‡. The construction of the parking areas was a separate project and while there was a lot of testing done during the project for the terminal operations, the parking space was obviously neglected. According to reports, there was a lot of confusion in the parking lots on the morning of March 27. Drivers in search of free spaces blocked others, who had the same intention, which resulted in a massive traffic jam inside and outside of the lot. Once a staff member had parked the car, the person had to pass the security checkpoints, where other staff members meanwhile stood in long waiting lines. The security checks were also slow, and, to make things even worse, many security staff members were still outside the building in the traffic jam, trying to find a parking place. One can imagine the conflict between BA’s luggage workers who knew that BAA would soon start the belts and the understaffed security adhering to their rules and trying to keep things under control at their checkpoints. And then, the belts started and brought an avalanche of luggage to a small number of persons. The luggage system did not work perfectly on its first day of operations, so some free staff would have been needed to work around and fix the errors manually, but there was not even enough staff there to handle normal operations.

What would have been a better approach to making the start of operations safer at Heathrow T5? Of course, it is always easy to make recommendations from hindsight, but in production and service industries, a handover of a readily commissioned complex system is normally followed by a ramp-up phase of several months. A ramp-up phase is a period beginning with low productivity, which is carefully increased over time until it reaches its intended maximum. Ramp-up phases have two benefits since they avoid a situation where the organization is flooded with many erroneous parts, and they leave some resources free to fix errors or exploit opportunities for improvement that become visible during early operation. Figure 3-8 shows how a ramp-up phase is an overlapping of the project life cycle with the operations life cycle.

In Heathrow T5, it may have been helpful to start with a relatively small number of flights on the first day, leaving capacity free to deal with any possible technical problems as they occur, and then carefully ramp-up the number of flights over the next few weeks, until all flights had been relocated from the old terminals to the brand new one. Such a solution had been chosen in 2006 in Bangkok for the new Suvarnabhumi Airport, which began its operations with only a small number of flights on September 15, 2006. Problems materialized with the baggage system that could soon be fixed, and over the next two weeks, other airlines moved from Bangkok’s old Dun Mueang Airport one after the other. On September 28, the airport seemed to be working effectively and was officially opened to run at full capacity from that time. In the next weeks, a number of new problems emerged, so a decision was made in February 2007 to reopen the old Don Mueang Airport for domestic flights. A ramp-up phase for an airport includes keeping an old facility functional as a fallback solution in case of problems and being careful and watchful with the new system to identify how much load it can bear. With the reduced number of flights, Suvarnabhumi Airport seems to be working well today.

Why did the managers responsible at Heathrow decide to not choose the option to slowly ramp up the traffic in Terminal 5 by moving flights in small portions from their old Terminal 1 to the new terminal? Instead, they even planned to relocate a number of flights from Gatwick Airport, their other hub near London, to Heathrow T5 only three days after the terminal opened, and as a last step to move almost all long-haul flights to T5 by end of April the same year. The answer seems to come down to three things: necessities, cost, and egos. The necessities have their origin in the function of Heathrow as the central hub for British Airways, which runs a business model to bring travelers with smaller, short-distance aircraft to Heathrow and have them change there to the large intercontinental flights and vice versa. Having operations distributed over various terminals, one of them, in Gatwick, 58 km (36 miles) away, is more difficult, causes delays and dissatisfaction for travelers changing flights and increases costs for the transportation of these people and their luggage. The desire of BA management was strong to collocate the traffic in just one terminal. But there is another reason: During the night of May 15 to 16 in 1992, the entire Münich Airport was moved 40 km (24 miles). The transition of the conclusion of operations at the old location and the start of operations early next morning at the new location went smoothly. Hong Kong also moved an entire airport 30 km (19 miles) overnight from July 5 to 6, 1998. Concurrent operations of both airports for ramp up and as a fallback solution did not seem feasible at these places, as expensive airport inventory would have been needed twice at the old and the new location, and tight flight schedules of travelers with connecting flights departing from the other airport would have failed. In Münich and Hong Kong, moving overnight and starting operations at the new airport was just a bare necessity.

This necessity did not exist in Heathrow, where all terminals shared the same airport infrastructure. The infrastructure of Terminal 5 was new, including the baggage handling system; the old terminal remained in operation until June 2015, so its infrastructure had to remain in place. The distance between the terminals is only 2.7 km (1.7 miles) and takes just nine minutes by Tube train (London Underground), which runs every 10 minutes. An additional temporary shuttle service for travelers and their luggage would have been another feasible option to overcome the difficult first weeks of operations of T5, and as much as BA had disliked the old terminal, it would have been a perfect fallback solution when problems occurred. Managers at Heathrow obviously made a decision that if Münich can move an entire airport overnight and restart at the new location without a ramp-up phase, BA and BAA would also be able to do this with “only” a terminal. It seems, egos stood in the way of making such a decision, probably the true root cause of the problem. Egos can be especially difficult in chicken race situations: One of the two projects (or their project managers) at BA and BAA should have made the proposal to start the terminal operations slowly and ramp it up watchfully. I spoke with some people involved in the project, and it seems plausible to me that the managers of both projects saw themselves racing to the edge, but no one wanted to be the chicken and jump out of the car by talking about the concerns. Still, today, when one talks with BAA managers, the root cause of the disaster, in their opinion, was the unprepared and undertrained BA staff. BA’s people instead put the blame on the faulty infrastructure and point at the resignation of BAA’s Airport Chief less than seven weeks after the event as a confirmation of their position.

Terminal 5 had huge impact on the businesses of both BAA and BA. Its success, when the crisis was finally mastered, helped to streamline and improve the businesses of both companies, but the weeks of crisis in 2008 also had a dramatic impact on both organizations. The United Kingdom felt ashamed as well; British Airways is its “flag carrier”, the airline that is allowed to present the Union Jack on the fins of its aircraft, and Heathrow is Britain’s largest and busiest airport. High-impact projects require more care when basic decisions are made, and risk management does not only require certain formalisms, but also watchfulness, and contingency and fallback plans in place when expected or unexpected risks occur. High impact means high stakes.

3.9 Customer Projects and Internal Projects

I discussed the difference between customer projects and internal projects in Chapter 2. A field expert observed that a practice had worked well in one project but failed in another one, related to this distinction. It seems the most obvious, even most trivial distinction in project management; nevertheless, the differences between the two types of projects are often overlooked or, if they are mentioned, they are not elaborated with all their fundamental details. Customer projects are mostly performed as profit centers under contract with a customer, which are two influence factors that move them toward a strong matrix organization. Internal projects, in contrast, are more likely to be performed in a weak matrix, as they are cost centers that do not directly create income (their deliverables may do so later) and as they compete for resources with the profit centers inside the performing organizations, which are in most cases the functional business units that carry out the money-making operations.

I wondered about the percent of project managers assigned to customer projects versus internal projects and again designed a small survey for project professionals. Over 11 days, from August 30 to September 10, 2015, I received 246 responses that were distributed as shown in Figure 3-9.

The survey showed that the assignments of project managers are almost evenly distributed over the two types, at least among the respondents of the survey, which generally confirms the observation that I make in my classes. The option for other project setups allowed comments by survey participants, who responded with statements like “both internal and external” and “I’m kind of a sponsor for an internal project as well as responsible for several customer projects”.

Another difference in managing a customer project depends greatly on the contract type. To make things more complicated, there are two different kinds of legal definitions of contract types and understanding both helps better manage the customer project. There are different definitions used in Common law countries, where the Anglo-American legal system applies, and in Civil law countries, including Continental Europe, most parts of Latin America, Africa, and parts of Asia. In Common law, the distinction is made based on the obligation of the customer to pay:

• Fixed price contract

• Cost reimbursable and time & material (T&M) contract

Both types can come with or without conditional bonuses (incentives) or price deductions in form of liquidated damages (LDs) or penalties.

In Civil law environments, contract types are based on the obligation of the vendor:

• Result contract (French: Contrat d’entreprise, German: Werkvertrag)

• Service contract (French: Contrat de moyen, German: Dienstvertrag)

Bonuses are much rarer in Civil law countries, but price deductions in the form of contractual penalties are common.

A result may be defined as a tangible product or an intangible deliverable. It is specified in a result contract that the contractor must supply the deliverables to have a breach of contract situation. In a service contract, the contractor must provide certain resources that help the customer to create the result or attempt to create the result for the customer, but it is not in breach of contract if this attempt does not succeed. There is a common opinion that fixed price and result contracts are the same, and also service and cost-reimbursable/T&M are identical, but the contract definitions can be mixed as shown in Figure 3-10. Software licenses, for example, are commonly bought for a fixed price but do not give the customer the ownership over the software, just the privilege to use it^*.

The lowest risk for the contractor is in a cost-reimbursable contract for a service. The contractor must ensure the availability of the resources that are necessary to provide the services, and the customer pays the costs of these resources, plus a type of fee. Incentive fees may add some risk to the contract, but at least the resources are paid by the customer. T&M contracts have higher risk for contractor since the customer pays defined rates for the resources that may not actually cover the rates that the contractor has to pay for them. Risks increase with the fixed price that was defined based on early assumptions that may not be true when the project is being performed. On the other risk dimension, jeopardy goes up for the contractor when the obligation is to deliver the result, not only to provide the resources.

Project managers in internal projects do not have to be concerned about these questions, except when they procure project work or work results from outside the organization, in which they sit on the other side of the negotiation table. As contractors also procure work to subcontractors, this is then a common area of interest. But as internal projects are not run under contract, contractual questions seen from a vendor side are not an issue that an internal project manager has to consider.

The contractual aspect of a customer has generally another corollary since customer projects are harder to terminate than internal projects. In internal projects, terminating a project is a business decision, and after the decision has been made, one may see some people depressed and demoralized, while others celebrate. Customer projects are performed under contract, typically with written contracts in most cases that protect the interests of both parties. For instance, the customer expects a set of deliverables available for use after some time, and the contractor has blocked resources for the project and ordered items, often long term in advance, and the subcontractor or vendor also wants to be paid. The contract is therefore negotiated for most projects in a way to bind both parties to meet their obligations^*. In some jurisdictions, termination clauses “for convenience” are common practice. I know them mainly from public projects in the U.S.; they allow a customer to terminate the contract even in the absence of fault or breach by the contractor and without giving a reason. At times, the contractor can request a termination for convenience. It is unusual to have such clauses for the contractor, and they can be invalidated by a court if it finds that the termination was done by the customer or the contractor in bad faith.

I observed an example of the binding nature of a contract in 2012, when the training company Vole, Inc.^† put in a bid for a major industrial customer, Shrew Corp., to perform a staff development project. The project included methodology training for several hundred project managers and members of project management teams over a period of two years and included classes on two subjects, the proprietary “Shrew” methodology and Scrum, an agile methodology discussed briefly later in this book. As I knew both companies and the proposal management as a discipline quite well, I was asked to support the proposal manager of Vole Inc. in developing a capture strategy as a consultant. The proposal process went well, and Vole finally got the contract against aggressive competition on a T&M basis.

One problem that I saw during the bidding processes was that the rates Vole offered to Shrew Corp. were ones that I considered too low. Vole Inc. assumed that it would perform the project with its own staff and could run the project as a small-margin business without making a loss but as a way to open the door to Shrew, providing the opportunity to generate future business. I considered this “low-balling” approach dangerous. Shrew’s requirements for the trainers were quite challenging, especially regarding formal education and the command of foreign languages on the level needed for seminars, and the risk that Vole’s staff would not be accepted was quite high. My recommendation was to offer higher rates and, if the customer would not accept them, consider it to be a business that one should happily give to competitors to keep them busy and focus instead on developing more attractive business with other customers. This was not the decision that the company made; Vole offered at a low price. This is an observation that I have made repeatedly in customer project business during business development with new customers. Once a lot of time, effort, and energy has been put into winning the contract, fear increases of losing the competition and then having to explain to management why one has invested so much in the customer.

Vole Inc. finally won the contract, and the proposal manager became the project manager, because the company had no other person free for the job. My warning came true, the customer did not accept the employed trainers, and Vole had to find self-employed trainers on the market to replace them. These trainers’ daily rates were about 50% over the rates that Shrew Corp. paid to Vole Ltd. After about nine months, Vole Ltd. found out that no follow-up business was to be expected. It then tried to get released from the contract, but it took another nine months to convince the customer to terminate the contract. I talked with customer representatives after this time, and Vole’s reputation was then not positive for any future business. If a contractor needs to perform a project for a customer with too scarce resources, the customer will at the end of the project not remember the great service received for an inexpensive price, but it will remember a company that rushed from one problem to the next.

The lesson from this example: The project manager in a customer project is also a manager of a business relationship that the parties entered for mutual benefits. The tasks of paying attention to these benefits and balancing the often competing expectations and requirements of both parties is another difficult responsibility in this position. It requires specific practices and separates it from the position of a project manager in an internal project.

3.10 Stand-Alone Projects and Satellite Projects

Virtually all literature on project management assumes that a project stands alone. Of course, it has some dependencies to the project environment, which may come in the form of a matrix organization, an overlay of a more static functional hierarchy built for operations, and the dynamic team structures that we develop to achieve our project goals. Dependencies among projects may also occur when using a program structure. Because the project is part of the program, program deliverables and benefits must be created together with the other projects in the program. The project may also be performed inside a portfolio of projects, which may have independent goals, but share the same resources, including people, space, tools, materials, and the most important of all resources, management attention.

Projects may be linked in a different way. When NASA, for example, lost the already discussed Mars Climate Orbiter probe in September 1999, it also meant failure for two scientific projects:

• Mars Color Imager (MARCI) was planned to use two cameras mounted under the probe to observe the Martian atmospheric processes, study the interaction of the atmosphere with the surface, and examine surface features that conserved information on the Martian climate in the past.

• Pressure Modulated Infrared Radiometer (PMIRR) used an instrument to measure the thermal structure of the atmosphere, its dust and vapor loading, and more aspects of the Martian atmosphere to help understand its dynamics.

The Mars Polar Lander that was flying concurrently with the Mars Climate Orbiter and got lost during landing had five scientific projects on board, and the two Deep Space 2 probes that flew with it, and also got lost, had another four. Behind each of these 11 projects was a team that had spent years preparing and had expectations on the results that they could present to the global scientific community.

MARCI got a second chance with the Mars Reconnaissance Orbiter probe, which started in August 2005, and successfully went into orbit seven months later. MARCI has since sent data to Earth. This probe carried also a successor instrument for PMIRR, called Mars Climate Sounder (MCS). For PMIRR, the loss of Mars Climate Orbiter was already the second failure; the first was the Mars Observer probe that carried it also and had been lost in August 1993. It took the project team involved in MARCI two attempts, the PMIRR/MCS team even three attempts, the latter over 14 years, to bring their instruments into operations in orbit around Mars. The delays had nothing to do with problems in their own projects but with failures in projects with dependencies. One of the field experts in the research suggested calling these dependent projects “satellite projects”, and later thought to call the projects they depend upon “principal projects”.

I have not seen the concept of Satellite projects discussed in literature, neither in scientific literature nor in text books, but in cinema. Once Upon a Time in the West was an Italian “Spaghetti Western” from 1968, directed by Sergio Leone, and starring Charles Bronson, Henry Fonda, and Claudia Cardinale. It told the fictitious story of its protagonists dealing with two projects in the 19^th century American Wild West near an also fictitious town called Flagstone. The first project was building a railway line coast to coast, and it was the principal project; the second, depending on the first, was building a railway station in an empty place called Sweetwater, 50 miles west of Flagstone, where the engineers could fill the water tanks of the steam engines, and where the station owner could make a fortune developing a city from nothing that derives income from the passengers of the trains that stopped in the city. The owner of Sweetwater bought the place years before and was waiting for the track construction to arrive at his location when the story begins.

Satellite projects like this one are not rare at all. I have already mentioned projects performed by corporations listed in U.S. stock exchanges in 2002 to 2005 to become compliant with the Sarbanes-Oxley Act of 2002 (SOX), which mandated that these corporations report data to shareholders—data that could affect the financial and business fitness of the corporation and the value of its shares. Under the law, these communications have to be true, the data have to be audited, and it has to be communicated quickly. Corporations spent billions of dollars on their SOX compliance projects. The projects were not discretionary—managers were threatened with being put in jail if the organization did not comply. The SOX compliance projects touched internal processes and software that had not been changed over years and brought workarounds back to mind that had been developed long ago as ad hoc fixes to cope with problems in these processes and software. Often, the process gaps were not a problem of the solutions in place but were inadequacies of the interfaces between them. As all the ad hoc workarounds somehow worked, they never were fixed in a controlled manner. These work-arounds were often costly and time-consuming, but they worked somehow and allowed the corporations to shift resources to other things. Automation without optimization often leads to inefficiencies, which are hard to eliminate once they are in place. The SOX compliance projects forced organizations to have a closer look at these inefficiencies, and many corporations then ran satellite projects that used the insight from the SOX compliance projects to overhaul businesses and software and establish more efficient services. The SOX compliance projects as the principal projects had no business case, they were mandated by U.S. law, but the satellite projects had the business case to improve operational efficiency. Satellite projects may be able to add benefit to a principal project.

Similar effects could be observed in Europe with Single Euro Payments Area (SEPA), which forced businesses to modify their business software to cope with a system with unified bank account numbers across the entire Euro zone, very long ones, by the way, with 22 digits. Companies were not free in their decision if they wanted to change their systems to the terms of SEPA, it was required by law. In addition, not being able to pay or get paid would have been a prospect no company would accept, so they had to do the mandatory SEPA projects, but in their wake, many other system improvements were made, often in separate satellite projects.

Again, I wondered how frequent satellite projects are and asked practitioners in a survey whether they were managing a satellite or a standalone project. The results are shown in Figure 3-11. Satellite projects are less frequent than standalone projects but are not rare. When managing a satellite project, one must always have an eye on the principal project, because the success of the satellite project relies to a certain degree on it. Troubles, failures, and changes in the principal project must not remain unnoticed because they can have a major impact on the satellite. Risk management must also include consideration of the things that can go wrong in the principal project in addition to those on the satellite.

3.11 Predictable Projects and Exploratory Projects

In June/July 2012, I started discovering the diverse, situational nature of project management. The starting point was some deeply felt uneasiness on certain reports on project success and failure that postulated a measurable success criterion: “Project met its original requirements regarding budget, deadlines, functions, etc.”^* The assertion was that a project that meets its original requirements is successful; a project that does not is regarded as a failure^†. Based on this metric, surveys were published that communicated incredibly high percentages of failed projects. My simple question was: What if the requirements have been changed during the life cycle of the project? When a project met the original requirements, should it not be seen as a failure then, because it missed adapting to the later ones that would be valid at the end? And a project that met the requirements that were valid at its end, would it not be regarded as a failure following the logic of these reports? In my past assignments as a practicing project manager, before I became a trainer, I had several projects that had to be performed against changing requirements, and the projects met these in the end. Being asked about one of these projects in such a survey, I would answer the question, “Did the project meet its original requirements?” with “No”, and the reports would consider it a failure, which it obviously was not.

A second question was: What if the project requirements cannot be specified at the beginning of the project? An internal requester or a paying customer may not have enough special knowledge to formulate the requirements; the internal team or the contractor, on the other hand, may not have enough knowledge of the requester’s or the customer’s needs to formulate the requirements for them. In such a project where requirements need to be discovered while the project is performed, how would one apply this metric? These projects do not have original requirements at all.

I wondered how often these situations occur. Could it be that my criticism related only to a negligible minority of projects? I decided to make a little ad hoc survey on the question, using a function in the social network LinkedIn, which was available by that time (June 2012) but has been unfortunately discontinued. I saved the data before they were made inaccessible, and the interesting results are show in Figure 3-12.

One should point out that this survey, as some more that I am using here, would not meet strict scientific requirements. It is rather a momentary illustration of the responses of a limited and self-selected group of people. The project managers involved may not truly represent all project managers and project situations. On the other hand, the participants came from the project management discipline, and the responses confirm my everyday observations as a trainer and volunteer in a global association, who is in professional contact with many project managers. It may not be a scientific approach, but it is an approach by a trainer who asks people when he wants to know something about them.

Projects with static requirements came out in the survey as a comparatively small group. The survey had 140 respondents, and over 50% selected that they had to deal with changes relating to the requirements during the project. The second largest group, almost a third, responded that they have to identify the requirements by themselves. A small group said that in their projects, requirements are mostly static. The small percentages for the answers, “I do not have much experience” and “I do not know” can be taken as a signal that the respondents of the survey came from the discipline and had enough knowledge and experience to make a valid selection.

For almost 90% of the respondents, “Meeting original goals” would not have been a valid success metric, as the requirements, which include these goals, were either changing during the project or did not even exist at the onset of the project. Success and failure seem simple when one takes a superficial glance at them, but once one starts digging deeper, one will notice that they are rather difficult to understand and are subject to complex dynamics.

The topic occurred in my research once in the form that a set of practices that was appropriate for a predictable project was detrimental for another one, which was much less predictable. We decided to call this other type of project “exploratory”. In my research, the relevance of the topic was probably not fully shown, but I consider it highly important. We are again forced to “navigate between two monsters”: predicable and exploratory projects.

3.12 Composed Projects and Decomposed Projects

Most literature describes project management based on decomposition: The project manager or project management team develops a Work Breakdown Structure (WBS) top-down to break down a large endeavor that is so hard to plan and manage into smaller, more manageable components. The basic process follows the description shown in Figure 3-13.

The schematic illustration in Figure 3-13 shows the breakdown process, which creates a kind of upside-down tree. Decomposition often follows chronology, the first-level components may then be phases. One can also build the WBS based on organizational allocations, and with this approach, the first-level components would then designate business units involved, or based on function groups of the final deliverables. One can also mix the different breakdown criteria, but my recommendation is to restrict each outline level to one criterion, and then if desired, use another criterion for the next level. The components at the lowest level are called “work packages”, and they consist of activities, the individual actions that are performed by team members individually or in small groups^*. The diagram also shows that work packages may be allocated to internal business units of the performing organization, may be outsourced to external vendors, or may be done by the project team. In the latter case, the project manager and the project management team will have to plan and track the activities that are part of the work package by themselves, while work packages that have been assigned to units or contractors are generally managed by these units or companies. This is the process that is traditionally used to give the project an architecture and ensure complete assignment of work. A WBS is often also used to communicate cost information, following the simple principle that the total cost of the project is the sum of all individual costs; hence the “100% principle” of the WBS. Work items not mentioned in the WBS will not be done, while items that are in the WBS are part of the project. This approach can be used in internal project context to ensure a common understanding, or in a customer project, where a WBS may be part of a contract.

There are projects that are created using a bottom-up approach. Individuals, units, or organizational leaders voluntarily come together to jointly contribute to a project that they all believe should be pursued. Their interest may be driven by the emergence of a business opportunity, and they prepare a business case that they can better exploit by acting together. They may also have some shared ethical or political ambitions or expect a greater advance in technology and want to be actively involved. Work packages, activities, and other kinds of tasks in a composed project are not assigned; instead, they are rather self-selected. The typological dimension came up once in the research, when a field expert considered it a root cause for failure of certain practices that were successful in other projects. In this case, a project manager had assumed that he could manage a composed project with the same tools and behaviors that he had used before to manage decomposed projects, and he failed. It was his understanding that he could assign work when the team members understood themselves as volunteers that led to avoidable difficulties with the consequence of massive team attrition.

When I talked with other experts about this type of project, a common reaction was that they may exist but are rare. As I believe in such cases that it may be better to talk with people than about them, I asked practitioners from project management in an ad hoc survey; Figure 3-14 shows the results.

The respondents reported that decomposed projects are more abundant, but a ratio of 30% of all reported projects is far from being rare. The number may grow over time. Agile methods, described in more detail in the next chapter, generally prefer to compose projects from individual contributions. There are some companies today that follow a principle called “Leaderless Organizations”. The basic ideas were laid out in a 2006 book by Ori Brafman and Rod A. Beckstrom titled The Starfish and the Spider^*. The metaphor compares the spider, whose neuronal system is centralized, which is crippled if it loses a leg and dies if someone cuts off the head, and the decentralized starfish, which can stay alive and even regrow a lost leg, and the lost leg can grow to become a new starfish. Some leaderless organizations are highly successful, such as the U.S.-based manufacturer of special textiles WL Gore (catchphrase: “No Ranks, No Titles”), or Valve Corporation, the makers of video games and supporting services and systems. Setting up a leaderless organization can be difficult, as the shoe distributor Zappos had learned in 2015, when about 14% of their employees left the company rather than support the change^†, and a customer of mine who made such a change some years ago also had a similar experience. What I observed is that there were problems with certain employees who felt deprived of a boss telling them what to do and saying “well done” when they were finished. Striving for higher goods for their communities, many not-for-profit organizations are actually leaderless organizations, but so are the sleeper networks of Al Qaida, the Ku Klux Klan, and other establishments of organized crime.

Composed projects are temporary leaderless organizations and cannot be managed in a top-down way. Sometimes, they are performed without any formal project managers at all. If they have project managers, they commonly form a small team rather than letting a single person do the job, and their task is more coordinating, moderating, and facilitating than leading in a sense of command and control. Tasks are rarely assigned to team members, business units, or contractors; they are instead voluntarily selected by those contributors, who like to do them, with the risk that unattractive tasks may not be completed for some time, while others may be done concurrently by teams duplicating the same work. Contributors delivering poor work are often another dilemma. Telling them the truth about their products may destroy their intrinsic motivation as contributors, but not telling them may lead to quality problems.

A composed project can be perceived as a kind of common property by its contributors (see Chapter 2) and suffer from the “Tragedy of the Commons”, when resources are exploited that should be treated with care and preserved. It can also suffer from sensitivities. The volunteers in composed projects contribute with a lot of passion and positive emotion—they would not contribute if these did not exist. This also makes them vulnerable to perceptions of being disregarded or even bullied, feelings that may be unfounded or have grown from misunderstandings, but they can nevertheless be strong and highly damaging to the project. A good rule in a composed project is therefore to praise high-performing team members loudly but criticize poor performance in private.

The next case story shows another risk, which comes with voluntary investments that contributors need to make. Desertec was a composed project (rather a program) started by the Desertec Foundation and the DII industrial consortium in 2009. It was started to support the development of renewable energy production, mainly solar and wind, in arid countries as well as to transport solutions to developed countries by a grid of high-voltage direct current (DC, like from a battery but at much higher voltages) lines. The focus was North Africa as a producing country and Europe as the consuming one, but this focus blurred, and Desertec is also active in Latin America and China. While Desertec was effective in supporting technological progress in the field, it lost important contributors over time, especially the German corporations Bosch and Siemens, which capitulated to global competition and abandoned their solar energy business. At the same time, North African states reconsidered their business case and concluded they would rather use the ample energy that can be produced in the Sahara desert to develop their own industry. Changes in business strategies of contributors may impact composed projects as much as the feeling by some contributors that there is an imbalance between their investments and the returns that they receive on them. A local loss of limbs can be overcome by the self-healing abilities of composed projects, as the starfish metaphor vividly describes, but a massive loss of contributors will leave the project without resources. As much as the formation of the project can be a result of group enthusiasm and swarm intelligence, its dissolution may be due to group disappointment or swarm imbecility. Desertec is still alive, but much less focused, and instead is trying to find tasks it can perform using its resources rather than following a specific vision.

3.13 Further Types of Projects

The typology described above has some benefits. It was developed following a published process, which can be repeated by others possibly confirming the results, or adding new insights. It is considered an open typology, which means that it can be expanded when other types of projects are identified, just like Linnè’s classification system for species in biology is open for new species or the periodic table in chemistry for new elements. The nine dimensions described so far are not complete; they are the ones that emerged during the research, and there are others that wait for their detailed identification and description.

From my observations as a practitioner and as a trainer, the following come to mind, which I will describe in the following sections briefly.