CHAPTER 7

Planning When It Has to be Different

Projects have been around for a long time. You could argue that the Egyptian pyramid builders were involved in one. Before the 1950s, however, project management was not recognized as a distinct discipline. Between 1950 and the1980s project management came into its own. It, and particularly project planning, was seen as an exercise in a set of standard disciplined approaches, with good performance narrowly defined by compliance with a standard and a method. Since then things have changed.

Projects as Vehicles for Innovation

One of the most exciting changes is the growing involvement of project management with the delivery of innovation. It’s not that innovation within projects is new. Far from it! What is becoming more prevalent is the deliberate use of projects to create and manage innovation.

Kavanagh and Naughton (2016) looked at the correlation between how a country valued project management as a discipline with the level of innovation reported by that country.

Their results (Figure 7.1) suggest that there is good evidence that the higher the project management score (measured by project qualifications taken in the country), the higher the level of innovation. Only, however, up to a point, and then the innovation score falls while the in-country project capability continues to rise.

Figure 7.1 Innovation vs. project management score

Why would that be? The good initial correlation, followed by the separation may be a consequence of the surrogate measure used to determine project management capability. They based capability on the number of certifications gained in formal, method-based project management with its traditional approach to project planning. We believe projects are an ideal way to deliver innovation provided it is managed as an ­innovation project. Unless the planning, as well as other disciplines in project ­management, is appropriately modified, Figure 7.1 is precisely the curve we would expect.

Innovation is a slippery concept. It is clearly related to being new; sometimes it is confused with invention, and it definitely seems to imply creativity. All concepts that can, at least on the face of it, appear to be the very antithesis of the structured formalization of projects and their plans.

Fagerberg (2004) makes a helpful clarification. He argues that ­Invention is the first occurrence of an idea for a new product or process, while innovation is the first attempt to carry it out into practice. Using this idea, a project is a vehicle that transitions an invention into an innovation. This takes away the suggestion that innovation projects are responsible for creating the ‘divine spark,’ and leaves the sizable task as to how you structure the work of a team to allow, and even encourage out-of-the-box thinking.

Perhaps the first step is to consider a thought first mooted by ­Schumpeter (1961), one of the early theorists working on the management of innovation. He suggested that All innovation is [to be] understood as a recombination of existing knowledge. That’s definitely one justification for managing innovation via projects.

Project teams are often a combination of specialists from various ­backgrounds, each with a different knowledge base. This gives rise to the need for individuals to re-examine and re-explain to other team ­members the basis of their viewpoint, and this encourages cross-fertilization of ideas. Now, consider the case that innovation project teams are ­deliberately made up of people with diverse backgrounds; we have the beginning of how traditional project management can and is evolving to meet this interesting challenge.

What other things should be done? We know that applying ­constraints in the right circumstances promotes innovation. And we also know that inappropriate application of constraints kills it. So, what is the secret formula?

Kanter (2013) set out a series of factors that she claimed were promoters of innovation. These are set out in Table 7.1. The only one that would immediately attract the eye of an experienced project manager is item 3, creating ‘slack time’ for resources. A phrase schedulers are familiar with, but not precisely in this context!

Table 7.1 Factors that promote innovation

Source: Kanter (2013).

The argument is that the plan (and schedule) must feature a higher tolerance for slack resources and considerably greater levels of redundancy. In this way, calendar time, effort, and thinking ‘space’ are created for the experimentation associated with innovation. Where traditional project managers see ‘idle hands,’ planners of innovation projects see opportunities for failure without penalty.

Projects and Innovation

Innovation occurs in projects. Just reflect over some of the projects that have been discussed in this book so far:

• The four-hour house—the development of superheated concrete
• The cave-rescue—a new way to hold masks on faces
• Cape Town IRT—the implementation of new retirement packages for taxi drivers
• D-Day project—new ways to compliance legal documents

You may like to consider on your projects, in what circumstances innovation has happened. In the aforementioned examples, the development of creative solutions to complex problems was driven by the constraints and occasionally the CSFs. When standard processes or products cannot achieve the desired result in the constraint set, innovation is stimulated, necessary, and welcome. On the four-house house, the development of superheating of concrete would never have occurred without the requirement to stabilize the concrete floor in such a short time. By the way, this technique was later to be used to speed up the rebuilding of highways following earthquakes in California.

For innovation to occur, the constrained context of the project has to be coupled with the planned allocation of time to seek out new solutions. Think of the cave-rescue and the practicing and sandboxing of the new mask fixing in the swimming pool before extracting comatose survivors.

There are also situations in projects where innovation is unwelcome and discouraged. Projects that do not have innovation as their purpose are supposed to have clearly defined goals. Risk-taking is deliberately managed down. Established processes are used in preference to others. Introducing unnecessary innovative solutions in a well-defined, well-­constructed, and well-planned project is committing professional suicide.

This chapter is not about these kinds of projects: It’s not about projects where innovation occurs because it has to, nor is it about projects where innovation happens accidentally. It is about projects whose very purpose is innovation.

Accidental Innovation

Accidental innovation occurs when the outputs and occasionally the outcomes are not quite as expected by the sponsors and key stakeholders. A surprise, but in a good way!

Two situations give rise to projects like these.

Evolutionary Projects

The first type is where a trusted process is used on a variety of ill-defined inputs. Many pharmaceutical projects are like this. Tens of thousands of tests winnow out from failed leads the possible candidates for further exploration. This, on a somewhat smaller numerical scale, is very similar to deploying Barry Boehm’s (1988) spiral model used in software development projects. He recognized that it might be necessary to develop outputs evolutionarily and then preferentially develop those that look promising: Sometimes you don’t know what you want until you see it. ­Evolving to a final product, where you move away from what you have, is very different from the traditional incremental model, where the design is set, and bits are added a piece at a time until complete. His spiral model (Figure 7.2) which came out of the rapid prototyping school, encapsulates the idea of ‘design a little, code a little, test a little’ then repeat!

Figure 7.2 The spiral model of software development

Each repeated cycle is a closer approximation to some final product or to failure. At the close of each cycle, a decision is made as to whether to continue and invest more or to abandon the project. The approach is useful when the acceptance criteria (ACs)—what counts as a good ­solution—is unknown or poorly articulated, and the requirement givers want the opportunity to refine their needs and their wants.

The impact on the planning of these evolutionary approaches where the ACs have not been pre-established is considerable. Firstly, it is a risk-driven approach. The decision to proceed is based on the appetite for risk by the stakeholders and the degree of ‘promise’ in the evolving set of products. Keeping in close touch with the sponsor is also vital. Decisions to terminate a project may be based on the residual value of products, and the intelligence delivered so far.

Agile Projects

The other way accidental innovation occurs is when it is not the ACs that are poorly understood, but the problem. In these projects, the requirements are difficult to articulate, difficult to get agreement on, or are volatile.

In these circumstances, traditional planning is ineffectual and ­inappropriate; a fundamental piece is missing from the Project Mission ModelTM—what exactly is the problem?

Software development projects have been plagued over the years by poor requirements. In response, some approaches to reduce the likelihood of developing the wrong solution have been proposed. One that has a growing number of adherents is Agile, a software development framework. A particular strength of Agile, where its delivery is at its best, and traditional project management disciplines are distinctly less successful, is its use of techniques that allow requirements to emerge, and resources are then organized to find solutions.

There is no lack of clarity about what the ACs are that the solution must satisfy once the requirement is known. Neither is the objective vague. What can be difficult to determine in projects run using these techniques is how much of the problem will be addressed because the scope is finally determined by a time-constraint—as timeboxing is applied to the ­delivery of the solution.

As remarked on earlier in Chapter 2, when done well, timeboxing can be the cause of innovative solutions, but in the case of Agile this is not the primary purpose, and it would be wrong to think of Agile as an approach to manage innovation.

Intentional Innovation Projects

Keegan and Turner (2002) carried out an analysis of how innovation was being managed within projects. They concluded that (at that time) most companies were still more concerned with how to manage projects correctly, than how to manage innovation effectively. This they saw reflected in the planning processes used.

Companies that want innovation need to change what they value. Innovation projects can have loose and ambiguous goals; other projects don’t. They tolerate slack resources; other projects don’t, and they adopt high-risk options, use experimentation, and practice trial-and-error. ­Traditional projects discourage their use. To use projects to deliver innovation demands changes in planning practices and what clients and senior management expect from the planning process. This approach, and the need for project management to adapt to the need to ‘fail fast, fail smart,’ is highlighted by the extraordinary tale of the development of the Sidewinder air-to-air missile.

Innovation Despite Project Management?

Perhaps the single greatest modern innovation in military weapon development, certainly in terms of financial outcomes, is that of the development of the Sidewinder missile. Yet the project manager, McLean, who drove this project for 10 years, from inception to production, claims that if the project had been subjected to the project processes then required by the US Department of Defense, it could never have come to fruition. He argues that their procedures were overly bureaucratic, and particularly attacks the use of phasing and stage-gating, which, he says do not foster creativity during design. If the project had followed the standard, indeed the mandated, process, then in his mind the Sidewinder project would have been canceled in the first few years (Lenfle 2014).

The story of the development of the best-selling air-to-air missile ever built is a tale of project disciplines—end-date-based scheduling, clear sponsorship, scope management, and one-truth monitoring—all being sacrificed because the purpose of the project was to solve a problem to which no one knew the answer.

The problem was relatively simple to describe. There were two needs or requirements: a way to detect a distant very fast-moving, very maneuverable object, and a way of using that information to guide a missile to collide with the fast moving object. There was no technology available at the time that could satisfy the requirements, though the underlying science was known.

The approach adopted by the project was to set off multiple ­parallel design and development task forces. Successful candidates then competed in experiments run to test the performance of the prototypes. These ­multiple experimentations were used to refine and uncover what would ultimately be the ACs for the end product. This inverts the usual process, of shaping the solution by setting down the success criteria. As explained by McLean:

…military personnel needed a chance to test prototypes in ­operational situations and on the basis of this experience were in a position to write realistic requirements for the procurement of…

This runs counter to the dominant project approach used by the US Department of Defense, which demands clear and complete specifications as a necessary starting point. McLean’s position, which bears more than a passing resemblance to the Agile practices of today, was that that rigid adherence to initial (and possibly wrong and undoubtedly ­incomplete) requirements lead to project inflexibility and failure.

Innovation Challenges for Project Management

The approach adopted by the Sidewinder project is now regarded as a good model for projects where innovation is the purpose. It emphasizes the importance of exploratory project management and the use of techniques such as ‘skunkworks,’ where small groups are given time and space to test out ideas, to encourage creativity by experimentation.

It suggests that when planning a project initiated to solve a problem or address an opportunity to which there is no known acceptable solution, the project should adopt a plan-do-check-act (PDCA) experimentation model. Planning is used to ensure the co-location of the team to support creative interaction and trust. It structures work into the running of experiments rather than on pre-design. It sequences work packages as independent parallel streams and encourages ‘fast failure’—the rapid progression from concept to testing.

It is entirely wrong to say that in the case of innovative projects the requirements are vague or even unknown. In the case of the Sidewinder project, for example, there was no doubt what was needed, nor what the performance criteria of any proposed solution would have to meet. Innovation projects should be run when the solutions are unknown, and through their exploration, the understanding of the requirements evolves, which distinguishes them from projects run under evolutionary and Agile product development frameworks.

Known Problems, Unsatisfactory Solutions

Consider this example: the Navy has a requirement to be able to communicate effectively from shore to ship, from ship to shore, and from ship to ship. This need has existed for as long as there has been a navy. What has changed is what counts as acceptable solutions.

In 1840, 1920, and 1940, the Navy was content with days, minutes, and seconds as response times. Today’s solutions need to provide microsecond responses to be accepted. Changes in what is regarded as acceptable and desirable in the solutions drive product and process ­innovation. The challenge is not in unearthing new or emergent ­requirements but lies in how to choose between the myriad of possible solutions.

Selection of a solution in this situation is based on using two filters. The first is the set of constraints, both physical and those arising from the projects’ organizational environment. The second is the set of ACs that are derived at the time the requirements are analyzed. ACs differ from requirements as they do not belong in the problem space.

Take for example the first AC in the grey box. The problem is the need to reverse direction, what would count as a good solution is being able to do so in a short distance.

Constraints differ from ACs in a number of ways. We’ve already ­discussed the ownership of constraints. Most lie outside of and are independent of, the project’s problem space. Their project role is to help define the success criteria for the project. This tends to mean that the constraints are difficult to negotiate—sometimes their source is not even known by the project manager, or occasionally, by the project’s direct governance group.

Figure 7.3 Example of a project brief with acceptance criteria

Figure 7.4 Mapping solutions to requirements

ACs, on the other hand, are local to the project. They relate directly to the problem addressed by the project. Their ownership is by groups and individuals known to the project team—and each one of the ACs is negotiable. You can see in Figure 7.4 how the impact of the constraints and ACs focus, like two spotlights, reducing the solutions under consideration to a manageable number.

Some useful outcomes emerge from the use of this model. Of ­immediate value is that it may indicate that there are no known solutions, given the set of constraints (including technologies), or—more ­commonly—no acceptable solutions given the current set of ACs. The lack of an ­acceptable solution is often the driver for establishing an ­innovation ­project. Another useful outcome is it suggests that the ­complete specification of a requirement should include its set of ACs and associated constraints.

To successfully deliver innovation the project planning processes must address the following five challenges:

The Possibility of Failure

Success in exploratory projects can be measured in part by the rate with which potential failed routes are identified and discarded, much like the test-based approach to the ZENO project discussed in Chapter 5. With failure seen as an acceptable outcome, the need is to plan for ‘fail fast, fail smart’; to quickly identify when to move on to a more attractive option. Setting up processes for halting unproductive lines of inquiry is an essential part of the governance of the project. The spiral model explicitly builds these decision processes into the cycles. Agile goes one step further by not only building them in but also by keeping development cycles arbitrarily short.

Change Is Good

In innovation projects, the scope is an emergent property. The project manager and the sponsor need to be tolerant of this source of uncertainty. In these projects, planning should be seen as a frequent, even weekly, exercise, with much shorter time horizons and more reviews of the assumptions, risks, and dependencies. The logs are now as volatile as the schedule, and the need for a detailed tasking schedule is much reduced in significance. This is a natural consequence of working with knowledge workers, where positive planning is favored over procedural planning (See Worsley & Worsley (2019) for a discussion on the differences between these two types of planning.).

Taking a leaf from the Agile approach, change is not regarded as a failure; it is a signal that a new approach needs to be taken if the desired result is to be achieved. It would be wrong to interpret this propensity for change as an excuse not to plan. Planning matters in Agile projects too, because they have to give answers to questions like “What will be tackled first?” and “Can we release the test rig in April?”

A view by one of the Agile theorists who understands the need and value of plans captures the point perfectly when he comments that any plan is only one forecasted view of the future. There are others, and with the passage of time, they may be more relevant. This has to be factored into the ways planning is done, and plans are communicated.

Cohn (2005) describes planning in Agile projects as:

Planning is an attempt to find an optimal solution to the overall product development question: What should we build? To answer this question, the team considers features, resources, and schedule. The question cannot be answered all at once.

This insight is the reason for the governance difference between Agile and more traditionally conducted projects. Agile planning activity is spread across the life of the project, rather than primarily focused at the front end. That leads to the need for planning documents to be easy to amend. You should structure your plan to make the more volatile parts easier to change.

Planning should anticipate change, with change viewed as the positive consequence of having learned something and avoiding the mistake of doing something that is not wanted. As changes are discovered, plans are updated. In this sense, it follows the ideas expressed by McClean in the Sidewinder project. When managing exploratory projects, the planning is carried out, not in one go at the beginning of the project, but tranche by tranche, as positions clarify and options become available.

Maintaining Business Commitment

Without McClean, there probably would not have been a Sidewinder. There are some questionable governance issues raised in the conduct of the project. Should he have been allowed to occupy the roles of the project manager, champion, and requirements giver? Had the project not delivered such an emphatically positive result, it is likely different judgments would have been made. The idea that ultimately success is determined by history was discussed in Chapter 1. Sydney Opera House, the Scottish Parliament Building, and a number of the railway projects would suffer from censure if judged narrowly on in-flight performance but stand as examples of outstanding human achievement today.

Exploratory projects usually don’t produce results quickly. Consequently, these projects may need champions, defending the project against doubters and naysayers. Planning will need to incorporate engagement activities to promote positive branding. It may also need to stage-­manage news and releases of information about progress. Interestingly, when researching high-performance projects managers, we found that one of the more highly valued skills was the ability to market their project. The process has to be done paying due deference to the sensitivities of project members. More technical project managers struggle to accept that this is a skill they need to have.

Managing Creativity

When a constraint is seen as a hindrance to achieving an objective, it can have a negative impact on productivity and creativity. If, on the other hand, a constraint is regarded as a shaper and a criterion of good performance it can have a powerfully positive effect. We have cited in this book a number of cases where this occurred. The question then is, ‘How do you construct an environment in which the constraints are seen as constructive?’

Innovation projects depend on having co-workers with diverse skills and knowledge, as the diversity is the source of the innovative interactions. Motivation can be more complex in such groups, with value ­systems failing to coalesce. Invention may be a solo activity: individual genius unlocking new ways of thinking about things. Innovation is not. Innovation is a collaborative undertaking to socialize or monetarize a product or a process.

Techniques for forging a team for a transient endeavor are the basis of many projects. In innovation projects getting it right is a necessity and cannot be left to chance and chemistry. The planning has to include the time and the opportunity for trust and communication channels to be established. It’s not a matter of everybody feeling comfortable and being liked. Team members, however, must respect their colleagues enough to feel able to challenge and to accept challenges, knowing that it is safe and expected of them.

Whether founded on fact or not, there is a scene in Apollo 13, the film, that exemplifies this point well. To integrate a newly arrived individual into a closely-knit team, the leader fabricates a situation that clearly demonstrates to the rest of the team his faith and trust in the new person. It was a deliberate ploy to develop the necessary personal commitment to each other. That’s what project managers leading innovation teams need to ensure.

Funding Innovation

Perhaps of all the challenges, the hardest is the funding of innovation projects. They are not easy bedfellows with traditional projects that use some form of cost-benefit analysis. The cost-risks and the benefit-risks are in most cases not subject to any rational calculation. They have high and often indeterminate levels of uncertainty.

Those organizations that depend on innovation, including pharmaceuticals and high tech companies, have similar approaches. They almost always separate their budget for research from budgets for other investments, which includes traditional project portfolios.

In the end, it may be that the basis for providing funds for innovation will depend on a mixture of visionaries and the need to future-proof. What project management must offer is that when the money has been entrusted to its care, it will bring to bear the best techniques for translating the money into future assets that solve today’s problems using ­tomorrow’s solutions.

Reflections

The interactions between project life cycles and product development ­lifecycles need to be reflected in the planning approach adopted. ­Projects, where innovation is the purpose rather than a byproduct, are no ­exception. The principal issue with planning them is the influence the governance group may exert unwittingly as it expresses its unease about lack of clarity of scope.

From your own experience, consider:

1. Have you been in situations where you had to deliberately generate opportunities for team members to learn to trust each other? How did you (or would you) go about doing that?

2. How would you plan and manage deliberately scheduled slack time? Do you think it should be structured, semi-structured, or unstructured? What is your reasoning for thinking so?

3. Have you used timeboxing to encourage innovative thinking? How did you communicate its purpose to the team? Was their reaction constructive or non-responsive?

4. Have you worked on a project with a strong champion? Was the experience positive? Are there situations where having a champion is unhelpful to the execution of a project?