CHAPTER

2

DYNAMIC ENVIRONMENTS

What Is Dynamism?

The strict meaning of “dynamism” is rapid change (Oxford Reference Online, 2008). In this book, dynamism is taken to be the dimension of a project that represents the extent to which a project is necessarily influenced by changes in the environment in which it is conducted. It is acknowledged that dynamism is a dimension of both operational and project work. Projects challenged by dynamism may simply have a limited window of opportunity, such as rapid deployment projects for disaster response, or product commercialization, or the project may continue to be challenged by rapid change through all phases of the project and afterward. There is inevitably overlap between the management approaches required for each because they both require speed within limited windows of opportunity.

Dynamism is not a simple binary dimension where a project is either dynamic or not; rather, dynamism applies in varying degrees to all projects. Therefore, a given project is neither “dynamic” nor “not dynamic.” Dynamism is argued to be at least a linear dimension but may in some cases approach exponential, where a change in one area triggers multiple further changes and so on, as depicted in Figure 2.1, Work by amount of change. It can be argued that all projects are dynamic to a degree. Dynamism is not held to be a new dimension but rather one that is increasingly common.

Dynamism is only one of many dimensions of a project that may be taken into account when selecting the appropriate project management approach for a project. It is assumed that in any given project the practitioner decides the relative strengths of each dimension and adapts his or her approach accordingly. Because all projects are dynamic to an extent, the needs of other dimensions may outweigh those of dynamism. For the sake of simplicity, however, for the remainder of this book, it is worth defining a “dynamic project.” A dynamic project is taken to be one with sufficiently high levels of change—owing to the environment in which it is conducted—to warrant consideration of the management of this dimension. This change rate may mean there are many unknowns at the start of the project, but, more importantly, new unknowns introduced at a rapid rate as the project progresses. In the words of one of the study participants, “we have 40% uncertainty in planning [a mission] because what you have to do depends on what happens in orbit.”

Why Traditional Needs Tweaking?

Traditional prescriptive approaches, orientated around process control in static environments, are considered sub-optimal for dynamic environments (Sugden, 2001; Sachs & Meditz, 1979; Williams, 2004; Ashton, Johnson, & Cook, 1990; Koskela & Howell, 2002). Project management, as defined by the bodies of knowledge, is focused mostly on a “management-as-planning” view of control (Koskela & Howell, 2002; Williams, 2004; Johnston & Brennan, 1996; Cicmil, Williams, Thomas, & Hodgson, 2006), which is appropriate for projects with clear goals and methods in static environments (Turner & Cochrane, 1993). But, as Koskela and Howell argue, for speedy projects, “traditional project management is simply counterproductive; it creates self-inflicted problems that seriously undermine performance” (2002, p. 301). The problem is that events arise at a higher rate than it is practical to re-plan (Sugden, 2001; Sachs & Meditz, 1979; Williams, 2004; Ashton, Johnson, & Cook, 1990a).

As far back as 1985, Rothwell and Zegveld argued that we were in the midst of a technology explosion, with 90% of our technical knowledge being generated in the previous 55 years; they rightly predicted that technical knowledge would continue to increase exponentially. Later, Perrino and Tipping (1991, p. 87) reported “the pace of technology is accelerating, raising the stakes and risks for managing innovation, and requiring early warning and shorter response time.” Technology breaks down traditional barriers to entry, such as start-up costs and the need for economies of scale. Furthermore, globalization rapidly spreads change in one part of the world to many others. Consider how social media, mass marketing, international trade, and global travel now spread change very quickly. For example, the SARS (severe acute respiratory syndrome) epidemic had a rapid international effect on economies (Vicziany, 2008; Lee & Warner, 2006). Finally, political instability and erratic market fluctuations combine with the above to create an increasingly dynamic business environment.

The pace of change is also accelerating (Pascale, Millemann, & Gioja, 1997). According to Graetz et al. (2006), change itself is undergoing a metamorphosis from incremental change in the pre-to-mid-1970s to revolutionary change today, which is driven by deregulation, the information age, globalization, and technology. All industries are challenged by this problem, and some industries are challenged by it almost continuously (Callan, Latemore, & Paulsen, 2004; Pascale, Millemann, & Gioja, 2002). This book addresses the need for a specific set of project management techniques to cope with this new reality (Stace & Dunphy, 1996).

What Is Different About Dynamic Projects?

Operational management is about relatively static processes. As change builds up so do unknowns, and operational management is then augmented with projects to manage that change. For traditional projects in static environments, most of the unknowns are resolved in the planning phase, not during execution. Dynamic projects have so much change; most of them are resolved during execution, as outlined in Table 2.1.

Table 2.1 Project and operational work categories.

Work Type Description of Unknowns
Operational Work There are few unknowns.

It is guided by established management controls. There are “operational” processes in place.

Classic Project Project unknowns are largely resolved at the start.

It requires the creation of new and temporary management controls and processes (e.g., project plan) beyond what already exists or is possible operationally. It may have high levels of unknowns at the start but most are resolved early, and few new unknowns arise during execution.

Dynamic Project Project unknowns are mostly resolved during execution.

It requires the creation of new management controls that are changed regularly during execution. It has high levels of unknowns at the start and a high rate of new unknowns throughout. It must resolve the unknowns at a faster rate than they appear, and in time for a limited window of opportunity.

What's the Key Challenge for Dynamic Projects?

Dynamic projects require a significant and sometimes desperate effort to stay on top of the changes. To explain, operational work and project work can be placed on a spectrum such as Figure 2.1, to indicate how much change occurs during their lifespan. The amount of change determines where the project sits left to right in the spectrum. The role of project management is to resolve the change and push the work back toward operational. The balancing of forces requires varying degrees of effort depending on the project type. In the static project, most unknowns are resolved before execution with proportionally few unknowns emerging later. For the dynamic project, the two forces are only balanced with significant effort, and the use of non-traditional project management approaches.

images

Using progressive elaboration to fill knowledge gaps, the project manager attempts to move the project to the left in Figure 2.1, thereby achieving the objective in a more predictable fashion. However, rapid changes in the environment, including tools, methods, and attempts to innovate, act to push the project to the right, increasing unknowns. Throughout the project, the two forces of exploration and change continuously act against each other. The challenge is to explore and resolve at a greater rate than the emergence of environmental change. The resolution process also needs to take into account that a solution in one area may trigger multiple changes in other areas. Therefore, it is also important to ensure that the amount of change created by the exploration and implementation is not counterproductive overall. An example of Operational Work in Figure 2.1 might be a production line where the only unknown might be the color required, and this is quickly resolved at the start. A typical project might be a house construction where there are more unknowns at the start, but most are resolved in the planning process before execution. A dynamic project might be a software development project, or a military campaign, or a disaster-response project. In a dynamic project, changes occur at a rapid rate, and a change in one area creates change in other areas, yet there is a clear goal and a limited window of opportunity in which to achieve it.

Alternate High-Level Approaches

Gray and Larson (2003) argued that projects conducted in highly uncertain environments were a key unresolved issue in project management, and present the following challenges:

  • planning for uncertain outcomes;
  • balancing flexibility with reliability and accountability;
  • balancing decision quality against decision speed; and
  • difficulty freezing design or scope during rapid change.

Pich, Loch, and De Meyer (2002) describe a type of project that encounters unknown unknowns and how it is best suited to what they called a “learning” strategy, which involves scanning, problem solving, and flexibility. They argued that this is distinct from projects conducted in well-understood environments that are suited to “instructionism” and distinct from “selectionism,” where the most fruitful initiative is chosen after a pool of trials. Pich, Loch, and De Meyer (2002) described the key distinguishing feature of the learning project type as follows:

This evidently requires that the team be flexible. Unlike in contingency planning, where “flexible” actions are predetermined and then either “triggered” by signals or “used up” as design slack (Thomke 1998), here the exact changes required cannot, by definition, be anticipated. Thus, it involves a greater level of flexibility than that required by contingency planning. (p. 1014)

Turner and Cochrane (1993, p. 95) built the “goals and methods matrix” that described four different types of project according to how well defined the methods and goals are. Projects can have poorly defined goals (“fire”), or poorly defined methods (“water”), or both (“air”). Shenhar and Wideman (2000) described a type of project that involved high levels of uncertainty, using technologies together for the first time. They call these uncertain projects “high tech” (Shenhar & Wideman, 2000). They also described a type of project that actually creates new technologies, “super high tech.” Shenhar (2001a) described how “low technology” projects are typically performed in construction, production and utilities, and high technology projects in the computer, aerospace, and electronics industries (p. 252). He offered building and bridge construction as examples of low technology projects. The key difference for Shenhar is the level of development work involved, in that low technology projects have little, and high technology projects have considerable levels and usually require prototyping. Boehm and Seewaldt (1984) compared the effectiveness of planning (specifying) and prototyping and found that prototyping was nearly twice as efficient. Shenhar and Wideman (2000) argued that another key feature of high technology projects is the number of design cycles. They asserted that in low technology projects, there is typically only one cycle with a freeze before development, and with high technology there are at least two, typically three, cycles. In response to the above findings, I would assert (and Shenhar may agree) that, in many cases, construction projects can be very innovative and involve a large number of design cycles and be regarded as “high technology.”

Cioffi (2006) suggested projects be placed on a spectrum of “newness” from operational to project. This idea has been adapted in Figure 2.1, which shows the sliding scale of unknowns that applies to projects. The term “unknowns” in this sense refers to any aspect of the project, including the methods to achieve it, the objective, and the environment it has to operate in.

A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – Fifth Edition (PMI, 2013) defined “progressive elaboration” as planning that is developed in greater detail as a project progresses. Using progressive elaboration to fill knowledge gaps, it might be possible to move a project to the left in Figure 2.1, thereby achieving the objective in a more predictable fashion. However, rapid changes in the environment, including tools, methods, and attempts to innovate, act to push the project to the right, increasing unknowns. Throughout the project, the two forces of exploration and change continuously act against each other. The challenge is to explore and resolve at a greater rate than the emergence of environmental change. The resolution process also needs to take into account that a solution in one area may trigger multiple changes in other areas. Therefore, it is also important to ensure that the amount of change created by the exploration and implementation is not counterproductive overall. An example of Operational Work in Figure 2.1 might be a production line where the only unknown might be the color required, and this is quickly resolved at the start. Static Project might be a house construction where there are more unknowns at the start but most are resolved in the planning process before execution. Dynamic Project might be a software development project, or a military campaign, or a disaster-response project. In Dynamic Project, changes occur at a rapid rate and a change in one area creates change in other areas, yet there is a clear goal and a limited window of opportunity in which to achieve it.

Projects conducted in environments with higher levels of dynamism may be more likely to possess some of the attributes of Shenhar's (2001a) high technology or super high technology categories with uncertainty at the start, but also include even more challenging high levels of change along the way. In dynamic project environments, significant proportions of the methods and goals are changed by external forces out of the project's control. The effort to resolve unknowns at the start of the project is severely challenged by the introduction of additional unknowns along the way, because what is learned can become obsolete in less time than it takes to learn. Materials, methods, and goals are always moving, making projects more akin to stacking worms than stacking bricks. Table 2.1, Project and operational work categories, shows the differentiation between operational work, classic projects, and projects with a strong dynamic dimension.

Snowden (2005) laments how the dominant ideology in organizations holds there are reliable relationships between cause and effect that are “discoverable or approximated in such a way that the future can be planned on the basis of desired outcomes”(p. 47). He argued that human interactions are less ordered and structured, and described four environments, of which the two “un-ordered” ones required an explorative-experimental approach, verses exploitation for the ordered ones. The decision model recommended for the chaos environment was “act-sense-respond,” and for the complex environments it was “probe-sense-respond” (Snowden 2005, p. 51). In those environments, management had to be decisive-directive, and informational-consensual, respectively. Using the Cynefin model the rapid change of dynamism would likely push the state back from known to knowable, or chaos. For the knowable environment, which would seem a common place for a project manager to attempt to hold ground, Snowden's (2005) decision model is “sense-analyze-respond,” with an oligarchic-consensual management approach (p. 51).

Compatibility with the PMBOK® Guide

A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – Fifth Edition (PMI, 2013) is necessarily a generic guide, while this book is primarily focused on the issues related to a single but increasingly important dimension—rapid change. However, the ideas in this book fit within, and sometimes extend, the PMBOK® Guide framework. The PMBOK® Guide readily acknowledges the potential for rapid change, and that the project management plan is iterative and goes through progressive elaboration throughout the project's life cycle (PMI, 2013). Progressive elaboration is discussed, as is how one can continuously enhance the detail in a plan as more accurate information becomes available as the project evolves.

In discussing the project life cycle, the PMBOK® Guide talks about how rapidly changing environments, such as research, benefit from iterative approaches where the planning for the next phase is carried out as work progresses on the current phase (and deliverables) and the product is delivered in increments, and how long-term planning in these environments is difficult. In the various management plans (e.g., scope management and schedule management) the PMBOK® Guide acknowledges that the plan may be highly detailed, or broadly framed, according to the needs of the project. Risk response planning in the PMBOK® Guide does incorporate consideration of actions to enhance opportunities and to reduce threats (PMI, 2013).

Extending the PMBOK® Guide

The Monitoring & Controlling Process Group in the PMBOK® Guide describes control as being largely about actively measuring variances from the project management plan and the project performance baseline. In general, management literature that is known as process control (and this book) lists a range of other control approaches that dynamic environments might benefit from. There is acknowledgment in the PMBOK® Guide that the business case “may be periodically reviewed to ensure that the project is on track to deliver the business benefits.” In dynamic environments this is much more at the forefront of thinking, with much more weight being given to how business benefits and environmental changes drive the project as much as the level of detail in the plan. In dynamic environments, integrated change control (PMI, 2013) must be streamlined to allow much more rapid adaptation to environmental changes and opportunities. For instance, the PMBOK® Guide describes how outputs to plan changes include changed: schedule management plan, cost management plan, quality management plan, procurement management plan, human resources management plan, work breakdown structure, schedule baseline, and cost-performance baseline. In dynamic environments, a project manager encounters events that compromise the plan at a higher rate than it is practical to re-plan in the PMBOK® Guide way (Ashton, Johnson, & Cook, 1990).

Finally, the PMBOK® Guide acknowledges how an organization's culture, communication styles, leadership, and decision-making techniques can have a strong impact on a project's ability to meet its objectives, but it does not elaborate on the specific elements of those dimensions, or those that might be relevant to rapidly changing environments. This book describes culture, communication, leadership, and decision making that may help managers deal with rapid change.

Dynamism Examples

I've already mentioned how change is driven by deregulation, the information age, globalization, and technology, but what about some real examples from practitioners? From my interviews and focus groups on dynamism, the three main themes associated with change causes were: (a) changing materials, tools, and inputs; (b) changing relationships with other related projects, services, or products; and (c) changing goals. The stories below provide insight into how practitioners perceive the causes of change, and why they believe it is necessary for projects to respond and adapt to these causes and embrace rapid change in some project environments.

Changing Materials, Resources, Tools, and Techniques During the Project Life Cycle

Many industries increasingly struggle with rapidly changing input in the form of materials, resources, and even the techniques used on their projects. One participant reported his entire environment turned over every six to 10 years. The unpredictability of his materials and resources made planning extremely difficult. He reported how “we have no option but to change the material, and we are inventing techniques as we go.” Traditional approaches to project management use progressive elaboration to build complex plans for complex projects. If materials change on a weekly basis, the process of elaboration can become cyclic without end. An IT project manager described how “the size of the learning curve is not predictable; expertise is ‘lumpy,’ which creates resourcing and scheduling issues; testing of all aspects of new technology is difficult and time consuming.” A geothermal power-generating company reported, “we are leading the way in a new industry. There are many unknowns. Essentially we don't know what's down there until we get in and do it.”

Changing Relationships with Other Related Projects, Services, or Products

Managing multiple interdependent dynamic projects could amplify the planning problem for each project significantly. A change in one project can create a change in another. Rapid changes in all projects make prediction difficult. One of the IT industry participants cited high levels of system interdependence. The interrelationships were so complicated that representations were considered to be almost as complex as the product systems, and just as time-consuming to maintain. The IT participants highlighted how they have to run an IT project to replace a running service with ones still being written by a vendor, interacting with several other services in very complicated ways, where each interacting service was also changing rapidly. Detailed planning in these circumstances seemed to be a significant challenge.

Changing Goals

One example of changing goals was given by a film producer who reported that “film making is such a fickle business, because it's partly determined by the whim of the broadcasters and what they might have determined they need for a particular year.” A film director lamented significant changes in government policy that affected investment. A defense industry participant summarized the impact of competition on goals by saying, “the enemy is constantly trying to figure out what your intent is and seeking to undermine it.” An IT project manager reported how “in volatile environments, such as the current global economic crisis, business strategies often change quickly in order to meet the market conditions at the time.”

Case Study 1
The Iridium Satellite Constellation Challenged by Dynamism

An engineer might regard Motorola's multibillion-dollar Iridium project as an astounding success. The project was “on time” and “on budget” according to the plan. Sadly, it was also a catastrophic commercial failure because they were unable to keep up with rapid changes in the business environment (Highsmith, 2004; Lim, Klein, & Thatcher, 2005). The $US6.6 billion project was one of the largest bankruptcies in U.S. history. Iridium was overwhelmed by rapid expansion of competing ground-based cell tower networks. The satellite constellation eventually sold for just US$25 million. Iridium did do their market research, interviewing 23,000 people from 42 countries, and surveying 3,000 corporations. Unfortunately, Iridium used a waterfall style approach, and was unable to adapt to environmental changes. The concept-to-development time was 11 years. By contrast, ground-based cellular networks grew incrementally with demand and were able to accelerate their investment as they discovered they were on to a winning strategy. Projects with long concept-to-development times are a real risk in dynamic environments. These projects might appear to be a good investment initially, but by the time the actual product or service is available, the business environment may have changed completely. Ideally one should deliver in working increments. The initial working version needs to get to market as quickly as possible. The company must re-evaluate the viability of continuing based on a better understanding of the product/service from the results of the initial stages (Finkelstein & Sanford, 2000).

Can We Resist Dynamism?

The most obvious approach to deal with the challenges of a dynamic environment is to attempt to make it more static by resisting change. This could be achieved by:

  • freezing objectives and design, rejecting change requests;
  • reducing or delaying adoption of new (especially unproven) technologies or techniques; and
  • extending the life of existing systems.

Certainly there are industries where this approach is appropriate, and for instance one of my study participants from the construction industry reported that, “change leads to chaos. There should be order and discipline.” However, many organizations have no choice but to embrace rapid change to achieve their goals, and certainly that was the case for all but two of the participants. For these organizations it was more effective to employ strategies that quickly and efficiently embrace change in the project environment rather than resist or precisely control the changes. They argued some forces could not be contained by the “make static” approach. One participant reported, “there are many unknowns. Essentially we don't know what's down there until we get in and do it,” and in the words of a military commander, “plans only survive the first shot.” A participant from the IT industry related, “the size of the learning curve is not predictable; expertise is ‘lumpy.’” Participants from the pharmaceutical industry, IT, and one from construction claimed their organizations’ very existence was dependent on them adjusting projects to suit a dynamic market. A venture capitalist reported, “we have to be responsive to the external environment at all times. This includes both the technology environment and the investment environment.” Some industries that had depended on stability in the past now actively embraced change. A defense industry participant related for instance how the main battle rifle remained static for two decades, helping achieve reliable storage, maintenance, distribution, and training processes, but since then, they have been forced to embrace higher rates of change in order to stay competitive, and the average soldier now carries US$20,000 worth of high technology into campaigns (including night-vision and laser-targeting scopes). The loss of precise control, reliability, and predictability that came from embracing rapid change was considered a more fruitful strategy than the loss of the competitive edge that came from resisting it. Adaptability is regarded to be the key capability in a dynamic environment.

In highly dynamic environments, the benefits of the “make static” approach are countered by its associated challenges when applied to a dynamic environment, including:

  • lost opportunities through delayed implementation of new approaches, materials, or business objectives that provide significant benefits, despite the challenges;
  • reducing business competitiveness, especially when competing organizations offer, or make use of, new systems that are often more effective; and
  • reducing business compatibility when an organization falls too far behind best practice, and finds it difficult to recruit staff familiar with their environment. Sometimes technology used on a previous project simply does not exist anymore, and new ones have to be used.

Indeed, the make static approach can conflict with low material life spans (low mean time to failure (MTTF)) and life cycles (the period before manufacture ceases permanently). Most materials, and therefore products, have to be replaced within three to four years with a next generation material/product. Next generation materials and/or products usually have differing properties to the original, and this has a flow-on effect to dependent products. While standards may be used extensively, some variations in properties are deemed necessary to achieve improvements.

An industry with a strong public safety requirement may be attracted to the “make static” approach. A safety imperative can help justify funds to test and implement strategies, and this can mitigate the reliability disadvantages of early adoption; the medical and the aircraft construction industries are good examples of industries in which this occurs. Conversely, the IT industry cannot easily leverage public safety to justify higher costs, so it trades reliability for faster delivery of new functionality at lower costs. Jones argues that technology-product life cycles are now measured in months, compared to the car industry, which is measured in years (about five), and in the construction industry, where “change in product technology is very limited and products such as steel girders and electrical cable may remain in the mature stage indefinitely” (2004, p. 406). Although the “make static” approach has merits, it also has limitations, and so other approaches are a necessary part of the mix.

Case Study 2
Submarine Project Challenged by Dynamism

The McIntosh and Prescott (1999) review of the US$5 billion Australian Submarine project concluded that “the main problem is the extremely rapid rate of technological change, which can give rise to new technologies which could do the job far better emerging during the course of the contract” (p. 6). These changes led to systems incapable of performing at the required level for military operations.

Over the life of the project, text-based computer interfaces evolved into graphical interfaces. What previously required 49 keystrokes on the systems available at the design stage could be completed with a single click of a mouse on those systems available at the time of launch. The contract prevented adaptation to these developments. The project was touted as “on time” and “on budget,” but the product was technologically obsolete, and cost US$900 million to rectify (Hawthorne, 2007), and compromised a nation's ability to deter regional instability (McIntosh & Prescott, 1999). A more flexible contract with delayed design freeze would have allowed the project to leverage more effective technologies.

It is worth reiterating Laufer's (1997) view that it is best to proceed first with the components least subject to change, followed by the most variable components. It might be assumed this also applies to project contracts and may have been a better approach for the Collins Submarine project, by delaying the weapons system contract until later in the project. There is ongoing debate on the relative benefits of fixed-price versus cost-plus contracts. On the one hand, the rigidity of the fixed-price Collins submarine contract contributed to the installation of obsolete computer systems that required immediate replacement at great cost (McIntosh & Prescott, 1999). On the other hand, there is a belief that cost-reimbursement contracts create inducements to inflate costs, or avoid cost reduction measures. As McIntosh and Prescott (1999) asserted:

For a relatively routine product or one where the specifications are clear and unambiguous and where payment is made mostly on delivery, (a fixed-price contract)…can work well. However, for a large, complex and new project, for which a design does not exist in detail and for which generous up-front payments are made, its effect can be deleterious. Particularly in the later stages, it can encourage the supplier to contest the specifications, and their interpretation, and to avoid responsibility wherever possible to protect profit. (p.5)

What Can We Do About Dynamism?

Knowing to Customize Your Approach

Most researchers agree the project management approach should be tailored to the project type (Payne & Turner, 1998, p. 58; Crawford & Pollack, 2004, p. 645; Sharma, 2001; Highsmith, 2004; Archibald, 2004, p. 43; Shenhar, 2001b; Cardinal, 2001, p. 19). Payne and Turner's (1998) study showed that managers tailoring their procedures reported better results. Simply identifying the project as having a significant dynamic dimension is a necessary prerequisite to applying the approaches outlined in this book. Some of the measures that might be applied to identify a dynamic environment in terms of the rate of environmental change might include:

  • the rate of introduction of new materials;
  • the longevity of products;
  • the turnover of labor;
  • rate of change in customer requirements; and
  • the levels of maintenance required.

Multiplying factors such as the following should be considered:

  • levels of interdependence between products;
  • levels of integration with the existing environment required; and
  • extent of scope.

What About Dynamic Capabilities?

Dynamic capability, a term discussed in organizational literature, is generally agreed to mean an organization's ability to adapt resources or activities to match environmental change (Ambrosini & Bowman, 2009, p. 1107). In this context, “dynamic” refers to the environment rather than the capability (Ambrosini & Bowman, 2009). Many once-successful firms struggle or fail as their environments change as they are unable to adapt successfully (Harreld, O’Reilly, & Tushman, 2007). Teece, Pisano, and Shuen (1997) recognize that it is essential to consider the changing nature of the external environment, and hence the role of strategic management, which is principally about “adapting, integrating and reconfiguring internal and external organizational skills, resources and functional competencies toward the changing environment” (p. 515).

Included in dynamic capabilities are research and development acquisitions, alliances and product innovation, absorptive capacity, organizational structure reconfiguration, and resource divestment (Ambrosini & Bowman, 2009). While there is some overlap with project environment dynamism, this book focuses primarily on project management approaches rather than operational or organizational approaches. Furthermore, the actual dynamic capabilities presented so far are largely illustrative examples and not supported by empirical studies or applied to project management specifically (Ambrosini & Bowman, 2009; O’Reilly & Tushman, 2011). Ambrosini and Bowman (2009) argue that “although there have been theoretical advances in this field, there are still rather too many incompletely answered or unanswered questions. This reduces the field's ability to impact management practice” (p. 30).

For the purposes of this book, it was considered the dynamic capabilities identified in this field were adequately covered by the project management approaches studied.

What About Agile?

In the world of management, agility is “the ability to both create and respond to change in order to profit in a turbulent business environment” (Highsmith, 2005). Difficulties applying traditional project management to turbulent environments gave rise to more emergent management methodologies, often identified by words such as “lean” or “agile” (Turner, 1999). While the primary focus of the agile movement is to discover better ways of developing software (Fowler & Highsmith, 2001), agile approaches are also relevant to dynamic environments. The founders of the agile movement were, like practitioners in other dynamic industries, frustrated with traditional approaches originally designed for more static environments. Agile's rise in popularity gave legitimacy to sound approaches adopted intuitively by software developers over many years. Agile planning and requirements analysis can take as much time as in a conventional serial phased approach, but the activities are spread across multiple iterations (Highsmith, 2005).

Since the development of agile, related approaches have sprung up, including Scrum, lean development, and extreme programming. Along with them has come a range of new techniques, such as burn-down charts, time-boxing, and daily stand ups. More recently, PRINCE2 and PMI incorporated agile approaches: PMI now has an agile certification, and PRINCE2 incorporated agile principles, such as welcoming change and high-frequency iterations. This book attempts to incorporate the elements of these movements that are specifically relevant to the dimension and problem of rapid change.

What About Complexity?

Terry Williams (1999) proposed complexity as one of the leading causes of project failure, and that it is made up of two dimensions: firstly, structural complexity, based on the number of interdependent elements (Baccarini, 1996), and, secondly, the dimension of uncertainty in goals or means (Turner & Cochrane, 1993). In this book I argue dynamism is a key and increasing cause of Williams's second dimension. However, I steer away from the dimension of complexity, and “complexity” theory, because of the ambiguity and disagreement over the concept (Whitty & Maylor, 2009), and because it does not describe the key challenge, which to my mind is rapid change, or dynamism. Dynamism is a more clearly definable term that is easier and more fruitful to deal with.

Is Dynamism Your Biggest Problem?

Project management practitioners need to be confident they are using the right project management approach. Before one implements dynamic approaches, one should consider whether the project is challenged by dynamism and to what extent. Consider the project type and the relative strengths of each dimension (e.g., change, risk, complexity). Dynamism is just one of many dimensions and may not be the most important. The approaches that help manage dynamism may weaken the effectiveness of mitigating other dimensions (e.g., complexity, risk).

If there is a strong dimension of rapid change, Table 2.2 might be useful for identifying whether dynamic approaches are appropriate. In using the table, the practitioner should consider the separate consequences of: (a) resisting change (e.g., missed opportunity) and (b) embracing change (e.g., safety/failure/complexity). Are there changes in business environment that might make the project objectives redundant if it takes too long? Is there a risk of lost opportunity? Are there changes in the project environment that might make it difficult to deliver the project's objectives (e.g., changing technology, regulation)? If so, what is the impact? Conversely for the argument against these techniques, is this a highly complex system of interdependent parts that require detailed planning, and resistance to change? Is there a risk to safety or health? It may be possible to achieve a greater net benefit from a make-static approach using the evaluation matrix of Table 2.2.

To give an example, a tunnel builder has powerful safety imperatives that make it hard to justify dynamic approaches. IT companies generally have low risk and significant benefits from adopting dynamic approaches. Defense companies have powerful benefits and powerful risks so they may benefit from a high intensity approach that embraces dynamic management, but with high cost investment in risk management to offset the dangers.

The most common way to justify dynamic project management techniques is through lost-opportunity costs. The practitioner should therefore consider whether the project will suffer from lost opportunities by using traditional methods. If lost opportunity is an issue, then the project manager should employ practices that actively embrace rather than resist change. Managers should also consider whether it is possible to achieve a greater net benefit from an avoid-change approach. Even if there is little change in the business environment (i.e., no lost opportunity), there may be significant changes in the technologies used to deliver the project. Significant changes to tools, techniques, and materials are another legitimate justification for using dynamic techniques.

Table 2.2 Embrace or resist dynamism - decision matrix.

  Embracing Change Has a Negative Impact Embracing Change Has a Positive Impact
Resisting Change has a Negative Impact High intensity balanced approach (defense, aerospace) Embrace change using emergent approaches (high technology)
Resisting Change has a Positive Impact Resist change (construction) Low intensity balanced approach (low technology)

Definitions

In this book, control refers to the mechanisms through which resources are managed to achieve objectives (Ouchi, 1979, p. 833), and differs from the PMBOK® Guide “technique” (PMI 2013), which according to Williams (2005), is strictly focused on bringing activities in line with a plan. In this research, a project refers to a temporary body of work requiring management processes or resources beyond what an organization provides operationally. General management refers to the process of controlling things or people (Oxford English Dictionary, 2008). Project management refers to a specialist subset of general management regarded as helpful in dealing with this kind of work. The term dynamic is taken to mean something characterized by constant change (Oxford Reference Online, 2008). In the project management context, dynamism refers to a dimension of a project that represents the extent to which a project is necessarily influenced by changes in its environment. Therefore, the ideas in this book may be applied in varying degrees to any project. While dynamism also applies to general management, this book considers specifically how it applies in the project management context. However, it is expected that many of the approaches could be well adapted for application to general management in order to manage rapid change. Dynamic project management refers to project management techniques that mitigate dynamism. In this book, a phase is taken to mean a period of time in the project (e.g., planning phase), whereas a stage relates to a distinct and defined part of the scope, or a clear objective.

Summary

The challenge of dynamism is an increasing problem for project management across all industries, with high stakes for national wealth and security. While dynamism is not a new dimension, it is one that should carry increasing weight, because of the difficulty it creates for planning and control. Traditional responses to dynamism are inadequate. Managers should identify the strength of the dimension in their projects and react accordingly.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.15.218.133