Uncertainty and Project Management: Beyond the Critical Path Mentality

INTRODUCTION

In executing operational activities, organizations often find it useful to make a distinction between processes, the systematic execution of repetitive activities, and projects, the one-time execution of more or less unique activities. In today’s new ‘new’ economy, the second form of operations is gaining in importance as more and more activities are carried out as projects. One can find many reasons for this shift of emphasis. The fast pace of competition requires constant innovation. Better-informed customers require customization.

Internationalization and constant mergers and acquisition require more agility. In short, the current business environment requires constant change, and implementing change entails the need to master projects. A project can be defined as a unique set of activities with more or less clearly defined objectives, carried out within a limited budget and limited time p. Typically, project management requires paying attention to two major areas of responsibility:

Order custom essay Uncertainty and Project Management: Beyond the Critical Path Mentality with free plagiarism report

450+ experts on 30 subjects Starting from 3 hours delivery

Get Essay Help

•  managing tasks; and
• (managing relationships.

Successful project managers understand that both are important.

However, the available formal management tools address only planning and task management. Consider the following real story: It is 9:30 AM on a Wednesday morning in southern California and thirteen men sit around a rectangular table in an office trailer parked at the edge of a multi-million dollar land development site. It is the weekly grading-logistics meeting at Ladera Ranch, where the project management team, representing the landowners and money partners, sits down with its various engineering and earth-moving subcontractors to discuss the progress of the project and any outstanding issues that need attention.

Most of the men huddle over a topographical map that lies at the center of the table, discussing the most recent changes made to the “final grade” of building lots, streets and community buildings they are supposed to deliver in phases over the next three years. Behind them, taped to one of the dusty walls of the trailer, hangs a six-foot long Gantt chart, dutifully updated using the latest version of Microsoft Project(. At no time during the two-hour meeting do the men refer or turn to the Gantt chart.

The term “critical path” is mentioned only twice during the meeting, and is used on both occasions more as a metaphor for urgency than as an explicit reference to any activities highlighted as critical on the forgotten Gantt chart behind them. After the meeting, one of the authors asked a member of the project management team whether they ever referred to the Gantt chart during one of these meetings. The reply was “If I need a Gantt Chart to tell me what’s going on, I should be fired.

Fifty percent of my job is managing relationships with our subcontractors, regulatory agencies and the landowners. Thirty percent is what I call vision: scanning the horizon more than three months out to identify potential problems while we can still do something about them. The final twenty percent is driving the site and keeping track of what is really happening out there. The Gantt chart is more a reflection of what happened last week, and what someone hopes will happen next week. … The problem is that every play we run is an option play (and the Gantt chart fails to reflect that). This reaction is typical for many of the project managers with whom we interacted. They don’t find the existing formal planning techniques very useful – the critical path method (CPM, PERT) and a plethora of heuristics, algorithms and concepts elaborating it. They dutifully draw the critical path, refer to it for formal performance review meetings, but often pay more attention to other factors. This may, of course, not always be the case: sometimes the Gantt chart is indeed the bible by which the project is managed.

The problem faced by project managers is recognizing which approach is appropriate for the particular project at hand. Should they strictly enforce the discipline inherent in critical path thinking or should they adopt a more ‘contingent’ style of management, utilizing a set of tools and techniques better suited to the particular characteristics of the project? There are few guides to inform the project manager in this important decision. Managers are left to their intuition as to which methods and style of management to choose.

The pressure to adopt the discipline of critical path thinking is strong, but the track record of this approach is not overwhelmingly positive(it is common for projects to miss budgets, schedules, specifications and opportunities in spite of the heroic efforts of the project manager to keep the project on track [i]. Based on an analysis of many projects in different contexts we came to the conclusion that the reason for the high variability in the use of the formal planning and control techniques could not be blamed on lack of knowledge on the part of the project managers.

We examined 20 projects on which we had detailed information, from industries as diverse as internet applications, real estate construction, specialty chemicals and pharmaceuticalss, aerospace, computers, and telecommunications (see appendix). We found that project managers were familiar with the concepts of critical path scheduling. The difference in utilization of these planning and control tools appeared to be driven by the degree and nature of uncertainty in the project, and by the ability of the project manager to recognize the effects of uncertainty on the project’s goals and activities.

Uncertainty is definitely not a new concept in project management. Existing tools from operations research (e. g. , Monte Carlo simulation, GERT) as well as some qualitative approaches (e. g. Synergistic Contingency Evaluation and Review Technique[ii], Analysis of Potential Problems[iii]) explicitly aim to predict the potential sources of disturbances in the project and to undertake preventive actions in order to avoid the negative consequences that these ‘risks’ could have on achieving the project plan. However, if one examines these tools closely, one finds that they are all heavily influenced by critical-path thinking.

That is, the project plan is determined and any project uncertainty or deviation from the plan is seen as a threat to be avoided. If a deviation from the plan does occur, it triggers intense activity to scramble back to the original project plan. This mentality has not, in practice, been sufficient to successfully manage the wide variety of projects often seen by project managers. The core of the argument that we want to develop here is that the project manager needs a better understanding of how uncertainty influences a project, and needs a better toolbox that addresses the specific challenges that different types of uncertainty pose.

We must challenge the idea that detailed project planning can be used in all circumstances to develop the optimal project plan that then must be adhered to at all cost. There are times when the style of the project manager must expand beyond a rigid, ‘critical path mentality’ of project planning and iron-fisted control of the original project plan, to a more ‘iterative and parallel’ project management style, utilizing a set of tools better adapted to reflect the particular nature of the project.

In order to develop this view, we first explain the role of complexity in project management. It is complexity for which the original planning techniques were developed. Secondly we need to understand the influence uncertainty may have on the management of that complexity. We then propose the project management style and toolbox appropriate for different project characteristics. We conclude with some suggestions as to a pragmatic approach to using that toolbox.

PROJECT COMPLEXITY

Critical path thinking arises out of the need for disciplined coordination in complex projects.

Our sample of projects (see Appendix) suggests that project managers typically wrestle with two major sources of project complexity: task complexity and relational complexity. Task complexity refers to the number of interacting and mutually depending components of the project. These can be activities in the traditional sense, or, more generally, distinct influences on the shape and success of the project. Take as an example the design of the Boeing 777, a new plane with millions of new parts[iv]. Boeing adapted its 3D-CAD system so that it could anticipate, through simulation, space conflicts for the whole plane early on in the development.

Coordination of the design of individual components to address these interactions was paramount to the successful completion of this project in a timely manner. In projects with high task complexity, coordination is a key challenge faced by the project manager. Identifying the tasks, scheduling their sequence, allocating resources, determining the critical path, monitoring progress and ensuring that deviations from the critical path are corrected, and achieving the project goals in terms of timing, budget and design quality remain the primary responsibilities of the project manager.

The available methods and software tools for determining the critical path and to design a Gantt chart are most appropriate in this situation. When uncertainty is low, project execution requires rigorous tracking against the project plan and systematic corrections to keep the project ‘on path. ’ Here, the discipline inherent in critical path thinking is most appropriate for coordinating project activities and for keeping the project on target. The second type of complexity is caused by stakeholders with conflicting interests. We call this relational complexity.

Conflicting interests lead to disagreements about project goals and about priorities among tasks and features of the project outcome. Consider the Eurotunnel project: the French and British governments wanted the project completed with private money and ‘convinced’ a consortium of banks to participate. These financial institutions in turn exhibited extreme risk aversion, insisting on a financing covenant that almost halted the project. The contractors wanted to maximize their profits from construction without any interest in the cost structure of running the tunnel, which, of course, was Eurotunnel’s main concern.

These interest conflicts led to major delays, cost overruns and tunnel features that reduced its operating profitability. In the presence of high relational complexity, the project manager must codify ahead of time explicit goals, deliverables, approaches, and penalties in case of negligence on the part of any key stakeholder. This is typically done in the form of a formal contract. Relationship management during project execution then consists of monitoring deliverables and taking action against the formal contract.

DEFINING PROJECT UNCERTAINTY

It is obvious that in the presence of uncertainty, the above methods of managing projects will have serious drawbacks. The greater the uncertainty, the more difficult it becomes to rely solely on the planning and control techniques inherent in critical path thinking. However, before we can adequately discuss the influence of uncertainty on project management approaches, we need to understand the different types of uncertainty that can affect projects.

It is tempting to categorize uncertainty in the traditional way, in terms of technical uncertainty, market uncertainty, etc. However, our project sample suggests that, from the standpoint of project management styles, it is more useful to consider the following four major types of uncertainty:

• variation;
• foreseen risk;
• unforeseen risk; and
• chaos.

Variation in activity durations, costs and the exact performance level delivered by resources is a common source of project uncertainty.

The nature and sequence of the relevant activities, as well as the objectives of the project, may be well known, and thus, the project plan may remain intact, but project schedules and budgets often exhibit variation around their projected values. A typical example would be the implementation of a construction project where the experience of previous projects allows the project manager to develop a near-optimal project plan, but the exact project duration and cost will vary, more or less, around their projected values.

A myriad of small influences play a role, for which it is too expensive to analyze them all individually (e. g. , worker sickness, weather, individual errors, parts not delivered by a contractor, a fight for resources, or some problems being harder than anticipated). We have chosen to label this ‘variation’, because it is parallel to common cause variation in total quality management (TQM), where statistical methods are available (e. g. , control charts) to monitor variations without having access to all the numerous, small, underlying causes. Foreseen Risks are identified but uncertain influences in a project.

Whereas variation might lead the project manager to expect a range of possible activity durations (e. g. “activity x of the project may take anywhere between 32 and 48 weeks” due to a combination of a lot of small influences), risk refers to a distinct and identifiable project influence that may have a singular impact on the project plan. That is, unlike variation, which foresees one single course of action (with “noise” around some outcomes), risks require anticipated “contingent paths” in the project plan (“let’s switch from Plan A to Plan B”)..

For example, pharmaceutical development is geared toward detecting and managing risks, mainly drug side effects. A drug typically has a small number of “probable” side effects that have been previously observed in related drugs. A side effect prompts, for example, a dosage change or a restriction on the drug usage to well controlled circumstances. In the context of risks, the side effect and the response to it are both anticipated. What is uncertain is whether this anticipated event (the side-effect) occurs or not. If it occurs, the anticipated “Plan B” is taken (the dosage change).

In the context of anticipated risks, the occurrence “triggers” a previously planned response, but does not strictly require new original problem solving. It is important to note that risks do not only represent downside, they can also offer opportunities. A “side-effect” in drug development is not always a health hazard, but may also be an additional application of the drug to a related disease (this happens regularly in pharmaceutical development). Unforeseen risks are not formally identified in the project planning stage, that is, they are not anticipated, and a “Plan B” has not been formulated.

While foreseen risk is a major influence that can be anticipated, although the project manager can only estimate a probability of its occurrence, there are sometimes influences that cannot or are not foreseen. In the case of unforeseen risks, the project manager does not have a predefined response to the event, either because the manager is not aware of the possibility of the event, or that the event has such a low probability of occurrence that it is not worth creating contingencies in the original project plan.

A typical reaction we often hear at this point is “what’s the difference between foreseen and unforeseen risk — that is, why can’t we call it simply risk? ” In theory, it can. It simply is not always practical. Conscientious companies develop “risk lists” of all the things that can go wrong in principle in their projects. Thus, unforeseen risks can, to a certain extent, be transformed into foreseen risks if the project team is willing to invest the effort. However, some of these risk lists can get very long and still not anticipate all that can happen to a project plan.

For example, the designers of the Ford Aerostar minivan could not reasonably foresee the crash of the Challenger shuttle in 1986, making customers reluctant to buy the car that reminded them of it. Or when Minitel was introduced in France in the mid-1980s, one could not expect that its biggest use would be for chat-rooms on sexually related topics (though, interestingly enough, one could have been expected to anticipate this phenomenon 10 years later for the Internet).

Whenever a project team pushes the envelope of their technology, or enters a new market (even if it is not completely unknown), it would be foolish to pretend that it can anticipate all possible important events in the project planning phase. When an unforeseen risk occurs, the team must (a) recognize it, and (b) perform new problem solving to develop an appropriate response. These abilities are not at all trivial, and we discuss them further below. Chaos refers to the fundamental uncertainty about the basic structure of the project plan itself.

In totally novel projects, where conceptual understanding is lacking, the project plan itself cannot be fully formulated. Projects that occur in periods of technological discontinuity (e. g. today’s experiments in e-learning) are characteristic of this situation. In this case, one works with temporary conceptual models of the project, while, in reality, the project plan is unknown. A good example is Sun’s development of the web page programming language Java. It was conceived in 1991 as the driver of a controlling device for household appliances (a “super remote control with GUI”).

The programming language was meant to run within the hardware. Sun Microsystems tried to sell it for set-top boxes, for CD ROM players, and for PCs, but all attempts failed. Then the web arose in 1993, and Sun made the connection between the opportunities offered by Java and the needs of programming on the web. So the project was yet again completely reconfigured as an interpreted software for Internet applications. There was no project plan possible from beginning to end that could have incorporated this outcome. Sun went from one application to the next, and totally redefined what they wanted to do after each failure.

This tenacity and flexibility, coupled with the fact that the people on the project were excellent, allowed them to break through at the end with a product that had very little in common with their original objective. Relationships Among Complexity and Uncertainty Before we address the management issues that are a consequence of the different types of risk, we want to make two observations. First, complexity and uncertainty are not orthogonal. Complexity at the extreme can translate into uncertainty when the project manager is incapable of considering all interrelationships (although the project remains deterministic in principle).

And when information exchange and coordination fails (again, because of task or interest complexity) what one party does will surprise the other party, who will then experience the actions by the first party as uncertainty. Second, the different types of uncertainty can, to some extent, be converted into each other. For example, better upfront analysis and a better understanding of the project may help us to translate unforeseen risk into foreseen risk. Similarly, a more refined, detailed examination of the myriad of sources of variation can also translate variation into foreseen risk.

These are managerial decisions incorporating the tradeoffs between upfront planning costs and effectiveness with execution costs and effectiveness. Attempting to translate all variation and unforeseen risk into foreseen risk at the planning stage will not only create tremendous up-front cost and complexity in the resulting project plan, it can also lead to complacency in the execution phase, where the project team, assuming the project plan and all its contingencies is now the ‘bible’, no longer scans the horizon for unforeseen project influences, either positive or negative.

A CONTINGENT APPROACH TO PROJECT MANAGEMENT

Categorizing uncertainty may be a nice academic exercise. The real question is whether such a classification has any relevance for project management. We argue that each type of uncertainty requires different a different management approach in terms of:

• project management style;
• (managing tasks; and
• (managing relationships.

Our ideas are summarized in Table 1. The reader should note that we present the main uncertainty types one by one.

But in practice, complexity and the four uncertainty types may occur together. If we argue, for example, that the project manager’s main challenge under unforeseen risk conditions is to be a flexible orchestrator, this does not imply that he or she can completely forget about coordination, the main task required to manage task complexity. The manager may have to use a combination of approaches to successfully manage the project, as we further discuss below. Variation What happens if the project is confronted with variation in activity durations, costs and/or performance?

While the Critical Path Method remains useful in the planning stage, variations in schedule, cost or performance may cause the critical path to shift during project execution. This will be particularly true for projects with high task complexity. To avoid unnecessary fire-fighting, the project manager will need the capability to simulate different scenarios of timing, and may want to build in buffers at strategic moments in the project (as proposed by Goldratt[v] and applied in some software projects).

A tracked performance variable—such as days ahead/behind schedule—can be used analogously to a Statistical Process Control (SPC) chart; as long as the variable stays within an acceptable range, no action is taken. However, once the tracked outcome falls outside of the control range—for example, more than x% behind schedule—problem analysis is performed to identify assignable causes, and preventive actions are taken to bring the project back on track to the target.

In projects where variation is high, the project manager is first and foremost a trouble-shooter: Someone who can identify when deviations arise and who will expedite the solutions to get the project back on track if and when necessary. Relationship management involves monitoring performance to identify ‘casual deviations’ from targets, and stimulating sufficient flexibility among suppliers, subcontractors and partners so that variations do not snowball during the project. For example, in a building construction project, a delay may cause the non-availability of equipment that must be used elsewhere.

Or the late delivery of window frames for a building construction in a country with a lot of rain (e. g. Singapore) may halt all architectural work requiring a dry environment. Foreseen Risks Identifying foreseen risks allows the project manager to develop alternative action paths. While it is still beneficial to utilize critical path methods for developing the project plan, it is now necessary to represent the influence of foreseen risks as alternative, though possibly similar, project plans.

Foreseen risks are best represented in a decision tree (second box of Table 1). Decision trees have the advantage of forcing the project manager to consider the effects of early decisions on later risks, and thus, later decisions. Branches in the tree reflect discrete outcomes, and may lead to different decisions being taken. Decisions—that is, responses to random outcomes—then influence future risks, and so on. While it is straightforward to evaluate the options inherent in a decision tree, exercising these options does not come “natural” to many project managers.

Their instinct is to chart a good course of action (formalized in a Gantt chart) and to try everything possible to successfully execute that course of action. Project teams are often reluctant to provide for multiple, parallel approaches and project targets, as this typically increases their own workload, and additional investments are required. Let us go back to the Nopane case. The side effects of the drug could have been documented, and the impact on the success of the drug could have been managed. Clearly some useful but additional analysis could have helped.

But the pressure to launch the (very promising) product, more or less according to the original schedule, made scientists and management neglect the information that could have helped them create a successful product. Foreseen risks also affect how project management should approach formal contracts. The project team in one of our samples liked to utilize the phrase “proactively occupy the white spaces in the contract. ” What they meant by this was, through anticipating risks, they could proactively write in the contingencies reflecting these risks.

In a sense, this meant staking out a claim before other stakeholders had even thought about the potential risks and opportunities. Progress tracking demands not only monitoring which activities have been completed, but also “which branch of the tree has materialized”. Risk requires the project manager not only to be able to trouble shoot, but he/she also needs to be a ‘reactive’ consolidator of what has been achieved up to a certain stage in the project. All risks (e. g. , incidents in the environment, or certain outcomes of the project work) must be constantly monitored and communicated to project stakeholders.

Flexible contingent actions, depending on outcomes of key influence parameters, should be anticipated in the decision tree. Unforeseen Risks Unforeseen risk makes contingency planning more difficult because not all influence factors can be anticipated, and thus, prevent including all branches of the project decision tree. The decision tree will evolve over the course of the project. Thus, the project team needs to constantly scan for the emergence of new influence factors. Moreover, when significant new information arises, the team must be willing to re-plan — that is, to add branches to the tree.

This may require significant new problem solving — a redefinition of the course of action, or even of the project objectives. Therefore, the project manager has to be an opportunistic orchestrator and networker who can detect the new options or threats very quickly — for example, possible new branches in the decision tree. Continuous scouting of markets and relevant technologies will be an essential task to be carried out in the project, and the deployment of new options may require the mobilization of new partners. Therefore, the project manager needs to have a powerful network of relations both inside and outside the organization.

In the context of unforeseen risk the project manager is completely at the mercy of the unpredictable occurrence of such an event. However, just knowing that such an event may occur, even though one does not know what it is, can already go a long way in providing for responsiveness. Consider the example of the pharmaceutical company Best Pharma[vi]. Their research organization had to decide which of several possible central nervous system drug research projects to pursue. A serotonin-based molecule looked more attractive in the standard analysis than a calcium-based molecule.

But one researcher dug up company statistics of past projects, showing that the chance of additional (non-anticipated) indications discovered later, during clinical development, was surprisingly high. Moreover, it was much higher for the calcium molecule class than for serotonin-based molecules (60% vs. 40%) because of less “specificity” of the chemical mechanism of action. No particular additional indication could be predicted or planned, but based on past statistics, the researchers could estimate the overall chance of one occurring at all.

Moreover, the statistics showed that additional indications tended to be as profitable, on average, as the primary indications. When this was included into the financial analysis, the calcium project looked much more attractive. Thus, the researchers could significantly enhance the project’s value by providing for the inclusion of an additional drug application during clinical testing. A formal contract in such cases is too blunt an instrument to fine-tune behavior, because not all contingencies can be included, and formal penalties are too heavy to be wielded for every small ‘transgression. “Dedicated assets” may offer a more effective control of selfish behavior: They cause dependence stemming from investments in specific equipment, training, or systems that are useless except in interaction with the current partner, and thus are lost when the partner withdraws. Studies have shown that partners work best together if the dependence is mutual, and thus neither party has an incentive for short-term selfish behavior. For example, in projects performed by companies jointly with their suppliers, efforts to improve project performance were highest when neither side had the power to appropriate all the benefits alone[vii].

Mutual dependencies as well as personal relationships allow the establishment of an atmosphere of accountability and trust, where all parties can make an effort to achieve the project objectives. Once such a spirit of collaboration has been achieved, arising problems can be resolved collaboratively to the best of the project as a whole. The project manager often plays a critical role in establishing a network of relationships, within which project “crises” can be resolved constructively. In many organizations, the project manager is an important ambassador for the project in this sense[viii].

Providing this level of project management flexibility is a major managerial decision that is often resisted. Sometimes the new information is not tracked or not understood, the team cannot develop an effective response plan in time, or it has no incentives to spend the effort. For example, target “hitting” is sometimes valued more highly than doing the best possible. It must also be clearly recognized that putting in place such flexibility is costly in terms of management attention, systems, and resources, as we further explain in Section 5. Chaos

Chaos requires flexible approaches and a constant learning from feedback. A fundamental change in the project structure cannot be handled as a ‘additional alternative’ in a decision tree. It requires a complete redefinition of the project. In addition, the project team may not be able to rely on only one approach because the failure probability may be too high. Rather, the team may have to define several alternative projects in parallel, “options” to be pursued at the same time. The team then needs to iterate and select the ‘surviving solution’ (bottom of Table 1).

Iteration requires a high degree of autonomy for the project team, to give it the flexibility to re-define the project. Coping with constant change will require the project manager to be an entrepreneur, who develops close contacts with customers and opinion leaders in the field. A project of this nature cannot be planned, but requires a continuous verification of the hypothesis on which the original project was based. Planning may be important in order to check the hypothesis of the project, but events may well be fortuitous and thus the plan itself relatively irrelevant.

More important than a plan is the ability to run experiments very quickly and consolidate the learning from these experiments for further use in the project. This is similar to the description that Iansiti and West provided of internet based projects[ix]. The autonomy of an entrepreneurial team must, however, be balanced by an organizational discipline of cutting projects ruthlessly when their chances of any success have become too small. History is littered with organizations that let their project portfolio balloon out of control, and only a painful restructuring could get them back to a sustainable mix of efforts.

COEXISTENCE OF UNCERTAINTY TYPES

We have consciously chosen to use the word ‘type’ of uncertainty. We have explained earlier that the different types are not points on some scale of uncertainty or complexity, but can co-exist. But having said this, in many cases one may be able to determine a dominant type, which will determine the main management focus. Thus, a particular characteristic of the project manager that we emphasized for one type of uncertainty does not mean that the other characteristics become irrelevant.

If the project manager who leads an ambiguous project needs to be a flexible orchestrator, this does not mean he/she can completely forget about trouble shooting. Likewise, the information requirements for a project with unforeseen risk are focused on the evolutions in market and relevant technologies, but that does not mean that the experience built up during the project has become completely irrelevant. So far, we have discussed the impact of uncertainty on complexity and coordination. But as we have alluded to earlier, complexity may create uncertainty.

For example, task complexity may exacerbate uncertainty when coordination breaks down. In that case we may create additional unforeseen risk. Or consider the case of a project characterized by chaos and high relational complexity. Relational complexity causes the parties to insist on defined deliverables, and any failure to deliver will immediately trigger accusations of shirking and cheating. But predefined deliverables are exactly what one cannot produce in a chaotic project! Relational complexity may thus exacerbate the uncertainty level.

Projects with both high complexity (especially relational complexity) and high uncertainty (on the dimensions variation, unforeseen risk or chaos) are difficult to manage. Often, public projects fall into this category. Such projects are almost always characterized by a high degree of relational complexity because they have many stakeholders with conflicting interests. Attempting to tackle unknown applications or technologies in such projects is very dangerous and often leads to project failure. But what can one do?

If possible, one should attempt to use only proven technologies, reducing uncertainty. Where that is not possible, one can try to isolate the uncertainty in one project module with lower complexity. In this case, a master plan satisfying the stakeholders can still be formulated, only that the one sub-project with high uncertainty must be planned with a large buffer (to allow for variation or iteration) and deliverables that are formulated in a flexible way to allow for adjustments to contingencies. These adjustments may then be negotiated when they occur.

The high uncertainty module then must be managed in isolation from the others with an appropriate project management style. As an example, consider the construction of the Denver and Singapore airports[x]. The Denver airport design included a fully automated baggage management system representing cutting edge technology (which the airlines did not even want; they preferred simpler half-automated solutions). The system proved so difficult that it delayed the opening of the airport by 9 months, and finally a manual system had to be put in place instead.

The newly opened Singapore airport, in contrast, started construction with a proven manual system, but with a layout that allowed installation of a fully automated system later. Thus, the state of the art technology was decoupled from the rest of the project and could be added in when it was proven. The Singapore airport was opened on time; the decoupling of high uncertainty and high complexity is a key step in keeping the project management challenge feasible.

A PRACTICAL APPROACH

Now that we have an idea of how complexity and uncertainty influence the management style and the focus of project management, we propose a road map for action. It consists of three steps: a diagnosis phase where the profile of the project is determined, a organizational phase for building the infrastructure for project management, and an assignment phase where accountability for the project results are clarified and communicated. Project Profiling Traditionally, one would start the project by determining what tasks one has to perform, and what resources are needed.

But this may determine only a set of tasks or influences that are certain to arise during the project, neglecting potential influence factors creating risk or unforeseen risk. Similarly, by enumerating the tasks and resources needed for the projects, we pay insufficient attention to the conflicts that may arise among stakeholders. Therefore we argue here that a different job has to come first. This first job consists of determining an uncertainty profile. This is a graph that depicts the relative importance of the different types of uncertainty in the project (Figure 1).

Tasks are secondary, and may be defined differently depending on the project characteristics (e. g. , when uncertainty is high, one may add tasks that are geared toward learning, not output). This is, of course, a qualitative estimation. It is usually impossible to have a number for this importance. But it is our experience that project managers have a pretty good feeling for what is going to disrupt the project. They may not use the labels we have developed here, but they know pretty well whether it is uncertainty about the execution of the tasks that will cause disruption of the project, the management of the relationships or ather the many unknowns about which tasks await the project team. While we accept that the quantification is difficult, we want to remind you of the example of the pharmaceutical company Bestpharma who could estimate the impact of an unexpected and unknown drug indication. This shows that with good analysis one can get an estimate for the size of the threat to the project. Moreover, thinking through the uncertainty profile helps to prepare the project team for the uncertainty challenges they can expect in the project.

One way of approaching the estimation of uncertainty consists of designing lists of areas of potential uncertainty or questions about sources of uncertainty, and then systematically evaluate whether these areas of uncertainty are expected to cause common cause disturbances (variation), assignable cause disturbances (risk), whether they are sources of unexpected opportunities (unforeseen risk) or simply could rock the whole set of hypotheses on which the project is built (chaos). Several of the ranking and scoring lists that have been used in project selection in R&D management can also provide a comprehensive list of uncertainty factors.

These lists are industry specific and never complete, but give the project manager a possibility to thoroughly think through possible risks and opportunities. While the project manager and the project team cannot beforehand quantify the level of unforeseen risk and chaos, they often do have an intuition whether they are low (“we understand the influences on project outcome very well”) or high (“we do not have a good understanding of what drives the project’s success, and we may be in store for large surprises”). What is the team sure of, and where are information gaps that could allow surprises?

As we already mentioned one can go through a few iterations of the design of this profile by trying to convert one type of uncertainty in another. For example, it may be possible and cost-effective to convert unforeseen risk into foreseen risk that can be anticipated and alternative courses of action planned. With unforeseen risk, one must react on the spot which for most of us is more difficult. If an unforeseen risk strikes, not because the event was in principle impossible to anticipate, but only because the plan was not sufficiently thought through, major damage can result.

We provide a few examples of such profiles in Figure 4. Example 1: Variation For example, in the construction of a cruise ship (left profile in Figure 1), the complexity of coordinating 2,000 subcontractors working simultaneously, and monitoring their work to prevent shirking in quality is by far the major concern of the project manager. Variation is probably the main source of uncertainty. Although there is likely to be some foreseen and unforeseen risk, they are unlikely to be of a magnitude to change the nature of the construction of the ship. A major unforeseen risk is unlikely, except for a change in customer requirements.

This, in turn, explains why the customer (the cruise ship operator) is typically present with large teams of “auditors” (often 50 – 100 people) on the construction site, who work with the shipbuilder to avoid late “catastrophic” design changes. Example 2: Risk (foreseen and unforeseen) Large scale infrastructure developments (center of Figure 1) such as the one described in the introduction of the paper often face less complexity but greater risk (both foreseen and unforeseen), as the nature of the soil masses to be moved may pose unexpected problems.

The range of soil conditions may or may not be known, so the management profile is concentrated on anticipating risks and scanning to reduce unforeseen risk. In this case the number of interested parties is lower, as well as the complexity created by the number of tasks to be performed. [pic] Figure 1: Project Uncertainty Profiles Example 3: Chaotic Systems Finally (right part of Figure 2), a hi-tech start-up company with an unproven technology attempting to create a new market faces extreme uncertainty: many success influences are initially unknown, and moreover, they heavily interact.

The ability to iterate, learn and adapt will be crucial for a team engaging in such a project. When the influence parameters are interdependent, the project team cannot construct a reasonably informative project decision tree. Checking for possible new influences in isolation is not helpful, as the later realization of other influences may make the assessment obsolete. It is necessary to hypothesize the whole project at once as a system, to proceed based on rough assumptions, and try to falsify them.

If the hypothesized system constellation does not materialize, the project must be stopped in terms of its original assumptions. This implies choosing a completely new course of action, starting as if it were a new project. Developing the Project Infrastructure Having determined the project uncertainty profile, the second job consists of developing the appropriate infrastructure to manage the project. Management of task complexity requires a system to schedule the tasks and coordinate the relationships. This may become very difficult in complex projects, as the large literature on activity networks illustrates.

The available software provides sufficient heuristics and algorithms to cope with a variety of situations. Tracking through standard metrics, e. g. number of tasks accomplished, serves a double purpose of coordinating multiple parties and providing the incentives to deliver to their commitment. The organization may well be fairly hierarchical. Managing relational complexity requires a different approach and infrastructure. In some project management literature there is substantial attention paid to the management of the relationships in a project.

Top management support, good negotiation techniques, team-building exercises, the charisma of the project manager can help to overcome the conflicts of interest. On top of that we have stressed several times the need for a good project ‘contract’ to be agreed upon by the stakeholders in the projects and made before the project starts. Such a project contract needs to include deliverables, schedules of time and resources, rules to solve conflicts and penalties if the conditions are not met. What has to be added based on the level of uncertainty?

Management of variation requires the added capability to assess, through simulation, the probability of running against ‘control limits’, requiring corrective action. The project manager should become the owner and guard of the common slack which is built in the project schedule, not at the end of each task, but at strategic ‘locations’ in the overall schedule. A hierarchical organization with a capability to quickly mobilize additional capacity to respond to unexpected common influences should be able to do the job. Foreseeable risk and unforeseen risk require flexibility.

While a project schedule may be needed, it is equally necessary to constantly evaluate (known) alternatives and to prepare oneself for sudden changes which require putting into the project schedule alternative or additional tasks. Decision trees can be a useful tool as we argued above. However, putting in place such flexibility is costly in terms of management attention, systems, and resources. A tracking mechanism must be put in place (“what is going on in the environment that could influence the project? ”). The team must have extra capacity to work out responses to sudden events, both on the up- and the downside.

A steering committee or oversight process must be in place in order to provide sufficient organizational authority to change the path of the project or the target. The steering committee also makes sure that the project team does not declare a mistake on their part as an external “uncertainty”. The organization may resemble more that of a network or a bundle of capabilities than that of a hierarchical organization. Finally, the world of chaos requires the ultimate flexibility for a rapid turnaround of experiments or iteration and on the spot decision making.

Very often it makes a lot of sense to split up the project in a series of smaller incremental projects[xi]. Feedback systems that provide a lot of information on customer reactions will become an essential element of the management tools. In this case the reliance on traditional activity networks may become dangerous: they may provide false security, or even blind the project team for major changes in the environment. Small entrepreneurial teams will become the preferred way of organizing. The capabilities necessary to manage chaos are quite different from what one sees in the other types of uncertainty.

The capability to experiment, but perhaps more importantly, to learn from these experiments is crucial. Yet we are trying to manage projects, not to enhance the general state of knowledge. So it is important that the sequence of experiments and the learning are guided by an overall vision, not unconstrained. The project manager should realize that while a learning and experiment driven strategy is nice copy for stories in Fortune or Business Week, the sequence of failed experiments can be very demotivating in practice.

We all know that we learn often more from mistakes than from successes, but the poor project manager who goes through a series of failures is probably not happy with that knowledge. A motivating environment and above all a capacity to persevere are essential elements of managing in chaos conditions. Assigning Accountabilities Different types of uncertainties require different types of project managers. What happens if the team discovers during the analysis of the uncertainty profile that it is ill equipped to carry out the task?

What do we do if the project manager has the wrong personality traits or skills? To get out of that quagmire we propose that the definition of the project profile should be iterative. We also suggest that the project team defines itself during the discussion about the project profile. The management of the different types of uncertainty and complexity requires accountabilities at different levels in the organization. Managing task complexity can be accomplished within the project team. However, this is not trivial.

It requires that the team has control over all the influences and tasks associated with the project. This is often violated: a sub-project manager often has accountability for events that are outside his/her control. Managing relational complexity may already go beyond the project team. While the project manager or the team can manage minor conflicts, one may need arbitration at higher management levels in case of major conflicts. Similarly, responsibility and accountability for the decisions that are required to cope with unforeseen risk or chaos go beyond the project management team.

We alluded previously to the need to constrain the learning with a vision, or to the fact that perseverance requires a favorable context. These are requirements that usually require the intervention by the top of the organization, and go beyond the confines of the project. Changing the basic concept of the project requires involvement of the leadership of the organization. By committing oneself to a particular uncertainty profile, one not only determines the focus of the project management, but also the implication of the different power levels in the organization.

Managing task complexity, risk and variation can be kept within the project management team. Managing relational complexity or unforeseen risk will require regular involvement of the top management team. Managing chaos requires the top management to assume the leadership and to take responsibility for the project.

CONCLUSION

What did we try to achieve? It was not our intention to refine once again the traditional project management techniques. There is sufficient end excellent literature about these.

But we wanted to show that the toolbox of a project manager needs to be much more comprehensive than activity networks alone and that the deployment of these tools is contingent to a large extent on the type of uncertainty with which the project manager is confronted. The core message of the article can thus be summarized in the following four statements: 3 The coordination dictated by task and relational complexity in projects is contingent on the type of uncertainty in the project. We distinguished between four types of uncertainty: variation, foreseen risks, unforeseen risks, and chaos. Contrary to classical project management approaches, we suggest that before one determines the tasks to be carried out in the project, it is necessary to determine the uncertainty profile. 7 This uncertainty profile will enable management to define the infrastructure (resources and authority) needed to manage the project and to assign accountability for the success of the project. 9 The toolbox of a project manager is not limited to activity network planning and risk management, but includes decision trees, contingency planning and rapid experimentation combined with learning.

We have developed an integration of the different techniques that are available to support the project manager and a conceptual model of where to use them. While our framework will require more empirical research to confirm its applicability, our work to date with project managers suggests that our contingent approach is a powerful tool for adapting management approaches to the circumstances. Enhancing the project manager’s intuition can significantly contribute to project management performance. Type of uncertainty |PM Style |Managing Tasks |Managing Relationships | | | |Planning |Execution |Planning |Execution | |No uncertainty (only task and relational |Coordinator |Plan the nature |Monitoring of |Identify interest |Coordination of | |complexity) |& |and sequence of |project progress |conflicts, and codify|stakeholders and | | |master scheduler. |tasks based on |against project |responsibilities and |suppliers | | | |experience. |plan. |deliverables. | | | | | | | | | | | | | | | | | | | | | | |[pic] | | | |Contract design and | | | | |Activity network | |enforcement | | | | |analysis (CPM, |Gantt Chart | |Enforcement of | | | |PERT, etc. ) | | |deliveries by parties | | | | | | |with conflicting | | | | | | |interests | |Variation |Trouble shooter and |Build in |Monitor deviation |Clearly identify and |Monitor performance | | |expeditor |slack/buffers at |from intermediate |communicate expected |against performance | | | |strategic |targets |performance criteria. |criteria. | | |locations in | | | | | | |critical path and | | | | | | |determine control | | | | |[pic] | |limits for | | | | | | |corrective action. | | | | | | | | | | | | | | | | | | | |Simulation of |Use of control | |Maintain some | | | |different |charts | |flexibility with key | | | |scenarios. | | |stakeholders. | Table 1: Focus of project management as a function of uncertainty type |Type of uncertainty |PM Style |Managing Tasks |Managing Relationships | | | |Planning |Execution |Planning |Execution | Foreseen risk |Consolidator of |Anticipate and |Identify |Increase awareness |Continuously inform | | |project achievements |trigger |occurrences of |for changes in |and motivate internal | | | |alternative paths |foreseen risks and |environment along |and external partners | | | |to project goal |implement |known criteria or |in order to cope with | | | |through decision |contingencies |dimensions |major switches in | |[pic] | |tree techniques | | |project execution | | | | | | | | | | | | | | | | | | | | | | | | |Contingency | Occupy the white | | | | |planning, decision| |spaces in the | | | | |analysis. | |cotract. | | |Unforeseen risk |Flexible orchestrator|Bnuild in the |Continuously |Build in ability to |Maintain flexible | | |and networker |ability to add a |question the |mobilise new |relationships and | |[pic] | |set of new tasks |existing project |partners in the |strong communication | | | |to the decision |‘model’ and scan |network who can help|channels. | | |tree |the horizon for |solve new challenges| | | | | |early signs of | | | | | | |non-anticipated | | | | | | |influences. | | | | | | | | | | |Chaos |Entrepreneur & |Consider parallel |Repeated |Build long-term |Close linking with | | |Knowledge maganger. |solutions with |verification of |relationships in |users and leaders in | |[pic] | |iteration and |hypotheses on which|order to create |the field. | | |gradual selection |project is built; |interest alignment | | | | |of final approach. |detail plan only to| |Direct and constant | | | | |next verification | |feedback from markets | | | | | | |and technology | | | | | | |providers. | Table 1: Focus of project management as a function of uncertainty type (continued) Appendix: Project Database Our research is based on detailed data on the following projects: | |Acer notebook computer development[xii]: under extreme time to |E-Bay China (based on conversations with management): this case| |market pressure, Acer reduced the number of correction loops |illustrates the ambiguity caused by applying a known business | |during product development and improved manufacturing ramp-up |concept to a new market. E-bay failed in China because they | |quality (variation). They also concentrated the responsibility|used the same settlement mechanisms used in the US (credit | |for product specifications in one group (interest complexity). card, bank transfer). But these do not work reliably and | | |ubiquitously in China. E-bay was beaten by a local start-up | | |who

Don't let plagiarism ruin your grade

Run a free check or have your essay done for you

Check my essay Hire Writer