Complexity Part 2: Solutions To Project Complexity
In Part 1 of this GATEKEEPER series on complexity, we identified 8 key sources of project and project team complexity. In Part 2, we discuss what can be done about them.
INHERENT PROJECT COMPLEXITY
The discussion has to start with inherent project complexity, which includes technical complexity and non-technical, or social-political complexity. A structured approach is necessary to ensure completeness. Table 1 lists a few of the sources of technical complexity, and Table 2 lists a few of the sources of social-political complexity.
ACTION: Use a structured process to identify sources of inherent complexity on your project, and communicate the findings to the project team. Consider that non-technical complexity is likely to cause you more pain than technical complexity.
Also, be aware that assessing inherent project complexity is more difficult than it would seem. The project team is usually predisposed to optimism and will likely under-estimate many of the threats to the project.
REQUISITE PROJECT COMPLEXITY
You probably won’t be able to develop an inherently complex project based on a simple design, but the design should not be any more complex than it needs to be. We can, at least conceptually, define a requisite complexity, and compare the actual design against what is really required.
ACTION: Apply a trimming process to cut out unnecessary project complexity. This requires a comprehensive identification of design objectives, followed by removal of kit and processes that do not contribute to achieving meaningful ends. The trimming process can be applied at any stage of the project. During concept selection, try to trim entire platforms or drill centers, for example. During FEED, try to trim systems. During detailed design, try to trim components. During operations, try to trim unnecessary processes.
COMPETENCY OF THE DESIGN ORGANIZATION
Competency of the design organization is critically important, of course. The most complex scope of work may be flawlessly executed if the ‘A’ Team from a highly-experienced firm is used, whereas the simplest “engineering 101” task may be booted by an over-worked, inexperienced team from a less-qualified shop.
Organizational competency requires more than just the right technical skills. It also requires defined processes and procedures, effective coordination of narrowly-focused, subject matter experts, relevant experience and effective learning from previous projects.
ACTION: Perform a gap analysis on the entire design organization. To effectively identify gaps, we must fully understand the tasks to be executed, the execution plan, the parties contracted to execute the plan, and the distribution of responsibilities between the parties. Since different parties with different skill sets will be required at different project stages, a gap analysis should be conducted prior to each stage.
TECHNOLOGY
We now have deeper wells, higher pressures and temperatures, harsher environments, larger projects driven by necessary economies of scale, and increased complexity is a consequence. Sometimes, a high tech solution is required (inherent complexity); sometimes it’s not. Existing technology is frequently employed on a larger scale. Installing the largest ever “xxx” or the highest pressure “yyy” adds complexitythat may not be fully appreciated by the design team. Modern communication technology makes possible the execution of complex projects by large project organizations that are scattered across the globe. This creates the illusion that we can effectively coordinate widely dispersed, complex design teams, simply through use of this technology.
ACTION: Apply the trimming process described above to specifically address technological complexity.
CULTURE
Several important aspects of culture should be considered:
Major projects are international, and differences between local cultures may have a significant impact.
Remarkable changes in safety culture have transpired over the past 30 years.
The cultures of the operating company and project team may conflict.
Consider the impact of changing safety culture. This has had several effects, including a large increase in the number of safety studies. Safety studies add significant complexity, in large part because they usually occur after the design work is completed.
Consider HAZOPs for example. A HAZOP is an audit of a “completed” process design. The Process Engineer enters the HAZOP believing that the design is finished. When the HAZOP generates dozens or even hundreds of action items, it effectively results in out-of-sequence engineering work. Actions taken to close HAZOP action items frequently create other problems, sometimes problems worse than the ones they were intended to fix.
ACTIONS: First, rationalize the studies being performed. Which add value and which don’t? Then work towards better integration of safety studies into the design process. For example, GATE has developed a HAZOP process that can be implemented in two parts 1. The first part is designed to be performed early in the design process.
DECISION MAKING
Complex projects do complicate decision making and, in turn, poor decision making can add a great deal of complexity to projects. The standard way of thinking about decision making is that we have some decisions made by individuals and some made by groups, but on complex projects the important decisions are made by groups of groups.
There is a great deal of attention paid to decision making on projects, but most of the attention is focused on making the major concept selection decisions. Such decisions typically revolve around cost, but how much sense does that make when our average project overruns its budget by 33%?
The everyday decisions made by individuals, teams, and teams of teams are more important, but little attention is paid to improving project decision-making in the trenches.
ACTION: Decision-making training. We can decrease project complexity by training individuals and teams to make better decisions every day.
STANDARDS, SPECIFICATIONS, REGULATIONS
Fit-for-purpose codes, standards and regulations can make projects much less complex. They constitute a series of ready-made decisions or an accepted method of making decisions, but they can also be complexity generators.
Codes, standards, specifications and regulations tend to become more complex, more specific, and more comprehensive over time. Disruptive events such as Piper Alpha or Macondo often result in spasmodic changes to the regulatory codes and standards.
Individual company specifications introduce some additional complexity. When different companies specify even minor variations from a vendor’s standard kit, we have increased complexity at the vendor interface. Project teams may not recognize that the vendor interface has been made more complex, and often don’t have the staff to review vendor documents as well as necessary.
ACTIONS: First, at the project level, challenge company standards and specifications that are “gold-plated.” Understand the methods of getting exemptions from unreasonable specifications. Then, on an industry level, participate in the World Economic Forum Capital Project Complexity initiative or other initiatives that seek to develop a more uniform approach to project specifications across the industry.
MANAGEMENT
We should expect that our largest projects would be staffed by the most experienced and competent project managers, and that those projects would be subject to the most rigorous project control technology and risk management.
Yet, it is precisely on these megaprojects where we see the worst failures.
Here’s an irony: If you have a simple project, a military style command and a control management philosophy might get the job done. If you have a complex project, you’ll need a simpler management style with distributed responsibilities. The more complex the project, the less direct control that Management can have.
Increased communication gives managers the illusion that they can understand complex issues by getting high level input, for instance, in a conference call. This tends to inject more project management interference in decisions that should be left to SMEs.
Weick and Sutcliff, in a study of highly reliable organizations, noted that organizations can respond effectively to emergencies only if the people on the ground are empowered to take effective action in real time, and if Management yields to the experts in those situations 2.
This is a good metaphor for decision-making in complex projects. When things go wrong, emergent problems have to be dealt with quickly. They have to be dealt with by the people “on the ground” who have relevant information in real-time; Management has to stay out of the way.
ACTION: First, make the project easier to manage by simplifying it via the actions described above. Then, apply a systems view. Pay attention especially to the systems that cross interface boundaries. Hire/develop more generalists who see the big picture. Finally, address the inherent problems with managing complex projects – adhocratic vs bureaucratic management 3.
REFERENCES
2011, Howard Duhon, SPE141982, “Stream-based HAZOP, A More Effective HAZOP Method”
2007, Karl Weick and Kathlene Sutcliff, Managing the Unexpected, Resilient Performance in an Age of Uncertainty, Wiley
2011, Kaye Remington, Leading Complex Projects, Gower
