4.1 Introductory Questions

This chapter discusses some more topics that may be new to most readers. Some of the following introductory questions relate to these topics and may therefore be hard to answer. They require knowledge that readers will first need to obtain by reading and probably also by reflecting on their own behaviors and those of people they work with and have worked with. It may also be interesting to research your own experience and consider observations relating to the performance of others to try to find both confirmations and contradictions.

You may try the questions now, or read the chapter and then answer them.

4.2 Lifecycle Approaches

Several sources describe so-called project lifecycles. They actually mean approaches to project management; it may well be that these approaches need to be adjusted during the course of the project to different tasks and situations. A project to build a bridge near to a cultural heritage location may have an early creative phase that is dedicated to developing a design that avoids disruption of the historic view. Creative phases are commonly better managed with Agile approaches, as creativity is generally hard to predict. Later in the same project, when the bridge is physically built, a predictive approach will be necessary. Resources must be booked early, work must be procured beforehand to ensure that the results will be available on time, and the project cannot have many changes that would necessitate the renewal of existing approvals by government agencies and other stakeholders.

In this book, I use the term “lifecycle approaches” to reconcile the two definitions. This should not be misinterpreted that they are necessarily used identically from the beginning to the end of a project.

4.3 Agile Approaches

In a discussion with the head of the Project Management Office (PMO) of a company from the electronics business, I was told in 2014 that the company was switching all projects to “Agile methods”. Agile methods were popular between 2000 and 2010 and are often considered another form of “best practices” by some companies and consultants. Others made the change to Agile methods for their projects with high hopes and were disappointed to some degree. Talking with experts in Agile methods, their common response is that the methods have been applied incompletely, and that too many projects have the term Agile as a label but are still “Waterfall” and “command and control” projects. For some people, agility has become an ideology or a dogma, something that I call “Agilism”. I think that it is time to explain the terms, as not all readers may be familiar with all of them.

Agile methods expect that change requests will come quickly and frequently, and they should be generally accepted. As each of these changes will come unexpectedly, there is no firm long-term planning; instead, planning is limited to one to four weeks’ development cycles, often referred to as “sprints”. It is a misconception that there is no planning in Agile methods since they require frequent planning at the beginning of each sprint. Sprint durations are fixed—an approach also called “time boxing”. During a sprint, no changes are implemented; they are collected and then discussed and decided upon between the sprints. At the end of a sprint, the team also discusses what it has achieved so far and bases decisions for the next sprint on the results (see Figure 4-2).

Agile approaches are commonly based on a document called the “Manifesto for Agile Software Development”, often just referred to as the “Agile Manifesto”^*. Starting in software development, the concepts were transferred to other applications for projects. There is, for instance, an “Agile organization development manifesto” for projects dealing with organizational development. The principles have been formalized in several methodological approaches, of which a method called “Scrum” has become the most popular. The basic assumption in Agile methods is that internal requestors of projects, customers, users of deliverables, and so on are generally unable to describe their requirements against these deliverables with sufficient accuracy and completeness for a team to just develop them. This assumption leads to constant change that is not manageable by a project team. For this reason, Scrum uses so-called sprints (periods with fixed durations commonly between one and four weeks), during which no change requests are brought up to the team. Change requests are instead collected by a role called the “product owner”. Between two sprints, there is some time to review and discuss the results of the sprints, and during this time, the change requests can be brought to the team for implementation in one of the next sprints, unless they are rejected. Scrum has another role, called the “Scrum master”, who ensures that the team adheres to Scrum principles but is not a project manager; the Scrum master is more of a moderator position. This interplay of periods with static requirements and moments when changes are implemented has some benefits. One is that the team develops a working rhythm, which can make it quite productive. Another is the desire to have a “potentially shippable product” at the end of each sprint, which means that it has the maturity and quality to form a product on its own, something that would be called a “quick win” in other methods. It has some similarity to the work breakdown structure (WBS) used in other methods that has been traditionally structured by deliverables^*. Most Scrum teams would nevertheless reject a WBS as too predictive and “command and control” oriented but would follow the principle that their sprints should have a product at the end. I will describe Scrum in more detail in Chapter 5.

Agile methods have a major disadvantage, which is the negligence of work flow and the logical relationships of work items like work packages or activities with the possible consequence of rework. I recommend a definition of rework in project management as laying hands again on a deliverable that was considered finished previously in order to repair or alter it. Agile methods mostly reject defining work flows in network diagrams and similar tools as too predictive, restrictive, and command-and-control oriented. They prefer that team members self-organize and also self-select their tasks instead of having them assigned by a project manager. Many Agile methods, therefore, even reject having a project manager. This reliance on self-organization can work well, but it can also lead to a kind of “biscuit plate” project management, which allows team members to select the specific tasks that they like to work on at the moment, similar to how children select biscuits from a dish: “I want the one with chocolate”. Tasks performed in the wrong order inevitably lead to rework and are among the top reasons that projects miss deadlines and budgets. The hours it takes to rework a project is a great metric to measure the efficiency and quality of work done by a project team. A solution in Agile teams is to never consider a deliverable finished, but this solution collides with the concept of “potentially shippable products”, and with the simple fact that at one point in time, the entire project with all its deliverables should be considered finished.

Another problem in practice is that Agile methods work best in solid, well-rehearsed, and dedicated teams comprising subject-matter experts with strong mutual respect. This builds that “bands of brothers and sisters” and actively avoids the emergence of game-theoretical dilemma situations. Colocation, placing the team in one location, is definitively helpful, but distributing a team that has been collocated in the past and successfully went through the often difficult phases of team development can also be a successful approach, as discussed previously. A survey conducted by the Scrum Alliance from 2015 stated that the average team size is seven people, which complies with recommendations made by Scrum experts that a team size of four to nine people provides the best results and is therefore recommended. Many organizations expect their teams to do a lot of multitasking, and they construct teams from individuals who have not gone through the phases of team building and do not have time and physical proximity to do this during the project. The team size is also not feasible for all projects, at least not without the risk of team fragmentation. Agile methods seem to work much worse in such environments. On the other hand, having a small team without fragmentation that is well-rehearsed and competent in the subject matter, located in physical proximity, and protected from disruptions from the need to meet other business demands is a good recipe for a successful project anyway, regardless of the practice in use.

Agile methods are highly disciplined; however, they are often abused as cheap excuses: “We do not have a plan. We are Agile, you know”.

I already mentioned Agilism. Some promoters of Agile methods developed some kind of ideology around these methods. They consider Agile approaches and methods generally superior, independent of the specific project situation, and insist on the implementation of aspects of Agile methods (such as self-organization and self-assignment of team members to tasks) with an almost religious zeal. For them, the world of project management consists only of two approaches: Waterfall and Agile. The perseverance for Agile methods comes with a fundamental rejection of the waterfall. Grey-shades between the extremes are not considered. If a person’s only tool to earn a living is a hammer, the person must convince people that the world is made of nails.

4.4 Waterfall Approaches

In a waterfall, water can move only in one direction: down. This metaphor is used to describe predictive models with long planning horizon, as shown in Figure 4-3.

Predictive methods are a response to the dilemma situation of the learning process discussed in the second chapter. Early in the project, project managers have many options for decision making, and most are inexpensive, but the knowledge is still not created to see the need for the decisions and to make them. Later in the project, there is much more knowledge, and the need and the options for decision making are much clearer, but the number of these options goes down and becomes more and more expensive. Chapter 2 described how project managers try to bend the learning curve to recognize the needs for decisions and the available options earlier, at a time when these options are more numerous and less expensive. Predictive methods are used as tools that project managers can use to accelerate their learning processes. At their core is network diagramming.

Predictive approaches were used when modern project management began in the late 1950s. Some major endeavors made it necessary to improve planning on top of bar charts and WBS that already existed^*. It is interesting that several developments were made at roughly the same time and independent of each other:

• The Polaris/Fleet Ballistic Missiles program to develop and build submarines and nuclear missiles to be launched from these submarines, programs with unprecedented complexity, on a technical level as much as on organizational level and risk. A small mistake could have sent the world into a third World War. The U.S. Navy had two development mandates for network diagramming given to teams. One was headed by Willard Fazar, which resulted in a method for use with computers named Program Evaluation and Review Technique (PERT)^*. The other one was led by John Fondahl for manual application, and it led to a method called Precedence Diagramming Method (PDM)^†.

• Developments by Du Pont and Remington Rand Univac, performed by James Kelley and Morgan Walker, which led to the development of a third method called Critical Path Method (CPM)^‡.

• A fourth method was developed in France by Bernard Roy at about the same time, called Metra Potential Method (MPM), for the development and manufacture of the cruise liner, France, whose keel was laid down in 1957. When the ship was taken into service in 1962, the France was the longest passenger ship ever built, with a length of 315 m (1,035 ft). It incorporated new, component-based production methods that made more sophisticated planning methods necessary to coordinate contractors with long-term assignments. MPM had basic similarities with PDM but used different types of dependencies between activities, which made the diagrams more flexible and meaningful but harder to understand.

In about 1960, PDM was merged with elements of CPM, and in the following years, the flexibility of dependencies between activities that MPM had developed was introduced to PDM. This laid the foundation for the subsequent success of network diagramming to make projects more predictive and help identify problems early, especially deadlines that the project is going to miss, and as a tool to visualize project work flows, simulation, and optimization. A brief introduction on this enhanced PDM network diagramming is provided in Chapter 5.

There are several factors that make long predictions necessary, among them early booking of resources and early awards of contracts to subcontractors who need to have their work results finished on time. Another factor not yet discussed is the need in matrix organizations to coordinate the functional organization and the various projects. Most functional organizations are set up for operations and take from this direction the benefit of better predictability of their work that is due to its repetitiveness. In matrix organizations, there are many points of intersection between the functional business and the projects: They share and exchange resources and deliverables and compete for management attention. When a project makes a major mistake, this impacts the functional organization and vice versa. At these points of intersection a kind of domino effect can take place, when the delay of a project causes delays in the functional organization, and risks, problems, and conflicts are also transferred over the domain border between projects and the line organization. As said before, in most organizations, it is the job of these line organizations with their operations to earn income for the entire organization. Many organizations, therefore, try to force projects into the same predictability that has been so successful in operations since the beginning of the industrial revolution and even possibly much longer. In such cases, the functional organization does not understand the specific element of uncertainties in projects, and often enough, its managers do not want to know it.

The key to predictions are the various network diagramming methods. The PDM method is used by most modern desktop software programs. So-called “Gantt chart” views look quite different, but the underlying logics and mathematics are the same. Further enhancements came later with methods like Graphical Evaluation and Review Technique (GERT), System dynamics modeling^*, and the Critical Chain Project Management (CCPM)^†. The last one is interesting as it changed some paradigms in network diagramming. Traditionally, the concept was to do work as early as possible, but CCPM recommends to do work just in time by adding dedicated time buffers when critical activities pick up deliverables from uncritical ones and must be protected from delays in them by adding time buffers, which in turn make the plan robust against deviations from duration estimates. The approach supposedly leads to a reduction in rework and, therefore, of overall work and helps speed up a project quite dramatically. There are two caveats. Just like Agile methods, CCPM recommends dedicated teams, free from fragmentation and multitasking, that can focus on the project. I identified another caveat in classes. Developing a CCPM plan takes roughly twice the time compared that needed for a traditional PDM plan. CCPM promoters correctly say that this investment will be paid back when duration variation occurs. That generally leads to rewriting plans in PDM but is mostly captured in the time buffers of CCPM plans that can remain unchanged. The problems come when a plan needs alteration because a change request has been approved for the project, or because a plan was found unrealistic. The time and effort needed to change the plan increases.

Today, network diagramming is aided by computers with relatively inexpensive software, at least compared with the prices of the systems in use during the 1950s and 1960s, and even free solutions are available today (which have restrictions in functionality and comfort). They all simplify and accelerate the tasks of developing network diagrams, drawing them and doing calculations in them, tasks that are arduous when done manually. The free tools have the benefit of simplicity; you can learn them simply by using them. Advanced tools with their complexity help solve more challenging planning tasks and are faster to use in the hands of experts but need dedicated training^‡. With all of these improvements from the past and the help of software, it is surprising that network diagramming is not used more frequently. In 2012, I tried another ad hoc survey on the question, “Are you using network diagramming?” in a LinkedIn group with project managers. At one point, I had to stop it. I had to accept its failure, because too many respondents had no idea what network diagramming was, and, therefore, did not understand the question, as I could see from the comments that they gave in addition to their answers. Their answers “polluted” the results and made them useless.

To make this clear: Network diagramming should be in the toolbox of every situational project manager to master projects and project situations that clearly require workflow definition and long-term prediction. It is a good practice and one of the most important tools, when “. . . it is necessary to take a strategic look at the entire job when planning, and to firm this strategy, in order to establish practical work sequences”^*. My observation is that it is widely in use in construction, infrastructure, engineering, and to a lesser degree, in aerospace and defense. I found that it is not typically used in software development and implementation projects, organizational development, or marketing. Until some years ago, it was also not used in automotive product and production development. This seemed somewhat surprising, and I asked automotive project managers why they did not use network diagramming. The response was: “Mr. Lehmann, you seem to know nothing about our industry: We use different project management software than other industries, a product called RPlan, and this software does not support network diagramming”. I met the principal founder of the vendor company of RPlan, a Munich-based company called Actano, years ago, and I asked him why the software does not support network diagramming. The answer was, “Why should it do that, network diagramming is not used anyway”. Major changes have happened to the company since that time, and the software has been expanded to fully support network diagramming. Automotive development projects need a lot of prediction, and network diagramming has found its way into the offices of their project managers. It helps them perform better projects with better predictions and less rework.

Waterfall methods are generally implemented to meet stakeholder expectations; however, they sometimes serve as inexpensive excuses: “No, we will not implement the change that you desire. It is not in the plan, you know”.

Some promoters of Waterfall methods also developed some kind of ideology around them, something I call “predictionism”. They consider Waterfall approaches and methods generally superior, independent of the specific project situation, and insist on the implementation of aspects of predictive methods, such as long-term planning, top-down command-and-control structures, and rejection of stakeholder influence that may lead to change requests and to the need to re-plan major parts of the project. In their insistence on long-term predictability, they also develop an almost religious zeal (similar to the folks I referred to with Agilism). Again, they consider the world of project management a dichotomy with only two approaches: Waterfall and Agile. However, for these people the insistence on Waterfall methods comes with a fundamental rejection of Agile methods. Grey-shades between the extremes are not under discussion. If a person’s only tool to earn a living is a screw driver, the person must convince people that the world is made of screws.

There is another aspect of predictive methods that is commonly overlooked: The plan must be complete, and the planners must not miss any work item during planning. An overlooked but necessary activity somewhere in the network, identified late, can make the entire schedule that has been derived from the network not feasible. A common example is rework after tests. Many network diagrams include testing activities and plans to immediately go on with their productive work after the test has been finished. They ignore the fact that the result of the test may be an identified need to fix errors and to do rework, for which no time has been planned and no resources have been booked. The assumption that all tests can be passed on the first try or that errors found can be fixed without impacting the schedule shows the planners may have been too confident.

4.5 Rolling Wave Approaches

Many projects are performed inside an organization’s project portfolio. Small organizations may define all projects performed as just one portfolio, while larger ones may have more than one defined, each of them under control of another manager or management team. Portfolios can include internal projects, called for by an internal requestor and done for the organization’s purposes or for an external customer who is paying for the project. A portfolio may also be a mixture of both types.

A company called Marten Inc. had a portfolio defined with three customer projects (for textbook simplicity—most portfolios are much larger), each with one deadline (also to keep the exercise simple). We call them Project A, Project B, and Project C and the deadlines also A, B, and C. The company made an assessment on where the projects stood and came to the following results (see Figure 4-4).

Project A and C are on schedule and able to meet their deadlines, but B is late. To make things worse, Project B is the project with the nearest deadline, and its project team is the one in trouble. Missing the deadline can lead to damage claims or contractual penalties^*; it will make the customer angry and damage Marten’s reputation. Meeting the deadline is both urgent and important. Marten made a decision to accelerate the project. De-scoping is not possible since Marten is working for a customer under contract, and other opportunities to increase the speed of the project have all been used to the maximum extent possible. The last option is to add more people, equipment, money, and so on to the project, something we commonly call “crashing”. It is indeed possible for Marten to meet the deadline of Project B, and a sigh can be heard across the entire organization when the project is over. It was over budget, of course, consuming more employee working time than originally expected, but it was finished on time, and the customer could not reject the last payment.

Where did Marten find the additional resources? Marten’s managers made a prioritization decision to focus on Project B, the crisis project, and took team members from Projects A and C, as shown in Figure 4-5.

The prioritization goes on: Project A is the next one that needs to meet a deadline, and resources are shifted there as well. When it is finished, Project C is crashed. Figure 4-6 shows the final situation of work and cost levels over the portfolios.

One may believe that with the end of Project C, the problems have been resolved. Marten may now be able to press a virtual reset button for its business and start being profitable. Unfortunately, the bids for Projects D and E have been won during that time, which helped the company secure future income but increased the already high stress level of those employees, who are active in projects.

The project managers finished their projects with a mixed perception of success and failure. They met the deadlines and avoided complaints for late deliveries, but the projects did not make the expected profits. For the entire organization, the overall results were even more detrimental for the following reasons:

• The “Law of Diminishing Returns” or “Law of Diminishing Marginal Utility” (also called Gossen’s second law) says that when resources are added to existing resources, each of these new resources will add less value. A person thirsty in the desert may be prepared to pay a fortune for a glass of water. The fortune the person would be prepared to pay for the second glass would probably be much smaller, and so on. At one point in time, the person’s thirst will be quenched, and the person will not need to pay anything for a glass of water. In the Marten example the productivity of a team will not grow proportionally with the increasing team size; instead, the team efficiency will go down. Members who are new to a team will take some time to become productive for various reasons, one being that they have to become familiar with their tasks, and while the incumbent team members have to train them, their productivity decreases as well.

• The “Law of the Minimum” (Liebig’s law) says that once a bottleneck has been removed, there will be a new one. It may be office space, computer network bandwidth, shortage of tools, or another shortage of a resource that limits productivity and decreases the combined productivity of the team members.

• If a small number of people perform a large number of work items, it is easier to utilize these people. A greater number of people with the same number of work items will have more idle time while one person has to wait for someone else to have work completed that delivers input for the work of others on the team.

• Team members’ motivation will suffer when they feel they are moved continually from one project to another one. The constancy of team situations that makes groups of people become “bands of brothers and sisters” vanishes; frustration and aggravation hold sway instead. Some will look for a more satisfying work place, and attrition of employees will worsen the situation, which is not sustainable.

While the crisis of one project is exported to another one in this portfolio domino effect, the efficiency of the entire organization suffers heavily. The result is a typical “Nash Equilibrium” (see Chapter 2), where the interests of the individual projects and the overall portfolio collide.

The case story shows how project managers have to expect changes from many dimensions. Continually changing requirements and new ideas from various stakeholders as to what they consider necessary and what is not required, volatile availability of resources, changing business situations of the organizations involved, and many more factors can make major parts of a project’s predictions null and void after short periods of time. Project managers in these projects should be prepared. The changes may also come from inside the project. It may be impossible to perform some activities, and the project team has to find different solutions or workarounds. The team may have identified opportunities for simplification or improvement that they want to exploit for the project. The team may try to use benefit engineering (discussed in Chapter 5) to make budget or schedule overruns or other burdens acceptable for stakeholders by weighing them against additional benefits.

I mentioned John Fondahl, who was one of the original developers of network diagramming in the 1950s and 1960s. The focus of his Precedence Diagramming Method (PDM) was on manual application. The walls of “war rooms” in the following decades—when the method found worldwide acceptance—were often filled with diagrams, including WBSs and network diagrams. Fondahl described a problem that emerged early with these plans: a lot of time and effort to develop, manually draw, and calculate were invested in the plans, and whenever a change occurred, major sections of the plan had to be re-developed, re-calculated, and redrawn. The more energy and determination people put into making the plans originally, the more time and effort were needed when it became necessary to alter them. The effort and time needed for these changes grew with the length of the planning horizon and with the granularity and details covered in the plans, as both added to the size of the plan. One could ease the drawing work by using blackboards and chalk instead of room walls and India ink, which also made faster changes since the move replaced the razor blade used for scratching off the ink and a sponge to wipe the chalk drawings off. But this helped only partially. The fundamental problem remained that with growing predictiveness, the difficulty of keeping plans flexible grew. There are basically three solutions to the task:

1. Use Computers. In the early times of network diagramming, this was difficult. Computer time was expensive and so was developing the plans. The plans were not files used by a program, they were the programs, and each project plan needed to be programmed by a programmer. Data were mostly stored on punch cards, and a discipline needed to be developed to ensure that a deck of punch cards could not be damaged by negligence or accident; such a deck could lead to a crash of the computer, which was running several jobs at a time. If a crash occurred, the data would have to be recovered in a tedious and costly process. Today, software is much less expensive, and the risks have moved from damaged punch cards to untrained users. As in any discipline, mastership includes tool mastership, and project managers should be given the opportunity to learn their tools from competent instructors.

2. Use “Rolling Wave” Approaches. Picture a ship cruising across an ocean. Ahead of the ship is its bow wave, and while the ship is moving through the water, so is the bow wave some distance ahead of it. Rolling wave project management accepts the event horizons, the limitations of prediction and planning, without ignoring or rejecting the fundamental necessity of making projections. The event horizons of predictability may relate to time: the future is reliably predictable and can be planned only to a certain point in time, beyond which projecting would be turned into pure speculating. It may refer to granularity: The level of manageable detail in plans and forecasts is limited. The more detail one includes in plans, the more the plans will need to be based on assumptions that may later be proven wrong. It may be organizational because the project shares scarce resources with other projects inside a portfolio, depends on deliverables from other projects inside a program, or is a satellite project of a principal project (as discussed in Chapter 3), and the other project managers reject or neglect to inform others as to what is happening with their projects. An event horizon may relate to people, who have their own private agendas, desires, angsts, and other driving forces, to locations that are inaccessible, to technological advances, changing economic environments, and more. In the following discussion, I will focus on the time aspect, but the issue is much greater than just that. Effective rolling wave project management accepts these limitations and bases the decision on the planning horizons on two questions (see Figure 4-7):

   • 1st question: How much predictiveness does the project need?

   • 2nd question: How much prediction does the project allow?

     

     Figure 4-7 Rolling wave between Waterfall and Agile.

3. Combine These Solutions. Using modern project management software with rolling wave planning, it is possible to navigate a project between the two monsters of lack of predictability on one side and the inertness and debilitation that a project can have when a predictive approach has been taken too far, and when fear of having to change plans exceeds the desire to implement necessary or value-adding changes to the project. Applying rolling wave planning, the project manager reiterates the Plan-Do-Check-Act cycle along his or her own learning process and that of the team, adding increments of predictions when they are needed and possible. Software takes the burden from the project manager of having to do all the calculations and drawing work manually and also supports communication of revisions to the plan to the appropriate stakeholders.

There are, in essence, three forms of rolling wave project planning, as shown in Figure 4-8.

1. Rolling wave in strict, sequential phase-gate projects. In this approach, the project manager and the team take phase ends as planning horizons. This means that a current phase has been initiated and is planned until its end. Future phases may be roughly described but are not yet planned. It is quite common that at the end of a phase, a gate review looks at the previous phase to assess if all the work has been finished successfully by the right people, in the right order, at the right place, etc., and has been appropriately documented. This is the first part of the gate review, which focuses on formal phase exit criteria. If the reviewers are confident with the results of this part of the review, a second part will be conducted, which focuses on the question, “Can the risks be taken to move to the next phase?” Only when the answer to this question is “yes” will the project manager get authorization to enter the next phase, which may then be initiated and planned. The benefit of this approach is the protection that gate keepers can provide. In pharmaceutical development, the gate keepers come from government agencies and protect the health and lives of people who participate in clinical trials by ensuring that only drugs that have been found effective and safe enough in the previous phase arrive at the next trial stage. In large capital projects, gates are often in place to protect the investors from monetary losses by asking if it is financially promising enough to continue the project and risk more money, or whether it would be better to stop the project at this point and accept the loss of money already invested. The price paid for the increased safety from strict phase-gate projects is that it slows down projects. Another price is that the project manager can rarely plan a future phase without the approval from the gate reviewers.

   

   Figure 4-8 Rolling wave planning in a project with (1) strict, sequential phases with gates, (2) overlapping phases, and (3) no phases.

2. In overlapping phases, the risks are increased compared to the sequential phases, but the projects are completed more quickly if executed correctly. Rolling wave planning may still be linked with phase ends such in a way that currently performed phases are planned to their end, but future phases that have not yet been begun will be initiated and started after their start.

3. Many project managers feel restrained by phase models and run projects without phases. They will plan the horizon of rolling wave planning not according to a phase definition, but instead will ask which prediction horizon is possible and beneficial for the project.

These three types of rolling wave planning are not strictly separate. One may, for instance, use the third approach in a strict phase-gate model and plan for the next weeks in a phase that may last for several months.

Some advice on the use of software: Several of my customers have trained and dedicated experts for the software who act as assistants to the project managers. One such expert may be able to support three to seven project managers, depending on the complexity of the projects. Project managers in these environments do not waste their time trying to make the software do what they want, often a difficult task, and focus instead on their core tasks of coordinating, directing, and leading. The experts have a professional understanding of the software in use with its features, as well as with its limitations and weaknesses and a lot of experience in its application. Over time, they may learn several software products and are then able to select the software that best meets the needs of a specific project or has been mandated by a customer to better communicate with the contractor—and of course keep the outsourced work better under control. They also help PMOs develop unified approaches to project management across the organizational project portfolio that support project success, not impact it, as they are in continuous interaction with both the PMO and the project managers. The investment in these people pays back quickly to the employer by better cost-efficiency and reliability of the projects they support.

Prediction horizons may not be the same for all work items in a project. I mentioned earlier Wysocki’s ACPF life cycle recommendation that moves from an Agile ideation phase to a much more predictive execution phase during the course of a project, which sounds like a reasonable approach for many projects. Another application of situational rolling wave could be to have different prediction horizons for different work streams. One stream, for example, may require highly skilled experts in a technical field that are hard to find and can be booked only for the long term in advance. Another work stream utilizes a workforce that can be obtained quickly and trained for the job. It may also be that there are several planning horizons defined for the entire project or its work streams. This approach implies a horizon for fine and detailed planning for the near future, and a high-level one that looks further into the future. On the move forward, the high-level ones will be refined, and sometimes may need to be changed, a process that is called “progressive elaboration” and reflects our learning curve along the project as shown in Figure 4-9.

A work stream is a collection of activities that together generate a set of connected deliverables. To give an example in an engineering project, one work stream may be to develop a piece of equipment, a second focuses on documentation and approvals, and a third may relate to developing environmental aspects such as making spares available in the warehouse.

How do event horizons of the project and planning horizons relate to one another? The first should be assessed by asking, “To what point in time can we effectively develop somewhat realistic and reliable plans?” One may ask the question repeatedly for different plans—for example, once for a fine plan and a second time for a high-level plan, and may ask the question also separately for the different work streams.

Two core elements of effective rolling wave planning are active refinement management and change request management. Table 4-1 shows the difference between the two forms of progressive elaboration.

A CCB is a Change Control Board, also known as Steering Committee, which is a meeting of key stakeholders to make decisions (not only) on changes that the team, the project manager, or the project sponsor cannot make alone. In a customer project, it may be advisable to have two CCBs: an internal one in which changes are discussed that are not the customer’s business, and a joint CCB with the customer to discuss all change requests and other issues that need to be made together.

Change requests are two-faced, as they can rescue a project in a time of difficulty or even in a crisis, but poorly managed, they can also drive a project into crisis. For change request management or change control, one should have a process that has been formally agreed upon by the key stakeholders and that helps protect the project from harmful changes. Change requests can have unintended side effects and secondary risks that should be assessed by subject matter experts before the decision is made to implement them or not. The last chapter has a recommendation on a protective change request process that can be implemented to shield the project from damages.

4.6 Connective Leadership and Achieving Styles

4.7 Favorable and Detrimental Practices

I mentioned earlier my research project, which I did with a group of 17 seasoned experts in project management. The first part was to develop a typology of projects. In essence, the Lifecycle Approaches and Achieving Styles described in this chapter are also typologies of behavioral dimensions. The second part of the research therefore dealt with the question, “Are there are favorable and detrimental combinations of project types with these behaviors?”

The experts used a system with points ranging from –3 to +3 that led to evaluations as was shown in Figure 4-13; the following diagrams show the average results of their assessments.