Introduction
This paper is not intended to provide a definitive guide to the processes, tools, and techniques of what we call “second order” project management; instead, its primary intention is to enable a dialogue between project management and sponsoring executives that demonstrates the necessity of investment in the additional tools, processes, and techniques necessary to the successful delivery of complex projects and programs.
Complicated versus Complex
It is essential to understand that there is a huge difference between “complicated” and “complex” projects. Complicated projects are those in which there may be many steps but they are understood and known—an example might be quadratic equations. These equations are difficult but there’s a process that solves them, and it is only necessary to apply that process to get the answer. Complexity arises when a design or a plan contains unknowns and uncertainties. Although that plan may very well be broadly accurate, it will almost certainly be precisely wrong. The real reason it would take a beginner months to build something an experienced engineer could build in hours would not be based on how complicated the nuts, bolts, and wiring of the device itself were, it would be the external elements that hadn’t been planned for at all. This is actually the worst kind of complexity—it’s bad enough if the uncertainties are expected (“known unknowns,” to use a Rumsfeldism). When the unknowns are unknown (“things we don't know we don't know”) and therefore unacknowledged, there may be a few surprises in store… (Donald Rumsfeld. (20020. In Brainy Quotes. Retrieved from http://www.brainyquote.com/quotes/quotes/d/donaldrums148142.html)
To an extent, then, every project—indeed every future venture—has its element of complexity, because we live in a constantly changing world. (“you can't stand in the same river twice” Heraclitus of Ephesus). Nobody can predict the changes in the external “PEST” (political, economic, social, technological) environment with 100% certainty. In the simplest projects, such changes are unlikely to have much effect; but the level of project complexity grows in direct proportion to the number of areas of uncertainty. There is a point at which possible changes in both the external environment and the capability of the internal organization demand that the level of complexity be identified and addressed. We term these areas of uncertainty “complexity drivers,” not all of which affect every project to the same extent. They comprise any element of the project that interacts with its environment and other components, whether these are people, organizations, technologies, and/or processes. The project complexity measure (PCM) will thus be the combination of any given project’s complexity drivers, their depth, the number of interactions between them, and the organizational capability to deal with them.
If complex projects are to be successfully planned and managed, it therefore becomes necessary to perform a PCM assessment (essentially an additional component of a pre-project risk identification phase) at the earliest stages of the project life cycle, and to maintain the currency of this assessment throughout.
There are two complexity driver dimensions.
Capability drivers are relevant to the organization and the individuals who make up the project team and include:
Leadership style/experience and behavioural attributes such as wisdom, action orientation, inspiration, focus, courage, and ability to influence;
Team experience, structure, and track record;
Platform/technology novelty;
Learning culture, flexibility, and creativity;
Risk aversity/risk seeking organizational culture;
Internal and external environmental turbulence;
Process/method/tool experience.
Project-specific drivers are made up of elements such as:
Urgency/business criticality;
Outcome novelty;
Intricacy;
Scope, cost/budget, duration;
Safety criticality;
Requirements maturity and stability;
Stakeholder numbers/geographical separation,
Stakeholder organizational stability,
External regulation/governance,
Platform/technology interactions;
Number of component (subsystem and stakeholder) interactions and relationships;
Contracting models
As complexity increases in respect to either or both of the above types of drivers, so does the necessary response need to change; and this introduces the concept of “first” and “second” order tools, methods, and techniques. The appropriate responses can best be illustrated by means of placing them on a Complexity Assessment Matrix, as shown in:
Exhibit 1 - Complexity Assessment Matrix
Low Experience, Low Complexity – An example is any “black box” component such as “plug-and-play” software, in which the complexity and experience all lie with the provider, and all the end user has to do is load a CD or connect an interface. If an organization was even to contemplate building such a product for itself, it would not only be a culpable waste of money, but would also result in a sub-standard product (although it has been tried, and with risible results!).
High Experience, Low Complexity – These are the routine – possibly tailored to individual customer preference, but essentially standardized. Projects in this domain will have been successfully executed many times before (and they may in fact be “complicated”), but the performance of the deliverable will be known and proven; however, that does not mean that they should be allowed to run outside a controlled project framework. They still demand rigorous application of what we will call “first order” project management tools such as earned value management, life cycle management, and Gateway Reviews, along with A Guide to the Project Management Body of Knowledge (PMBOK® Guide), PRINCE2, CMM-I, and similar “process” guidelines. The quality of the delivered product or service will be a function of process compliance and competent management.
Low Experience, High Complexity – This is where things begin to get difficult, and the “can-do” organization is in danger of biting off more than it can chew. It takes courage to admit that a project is too complex for the existing team experience level to undertake, but this is where real leadership kicks in, over and above simple management tasks. It may be that herein lies the strongest argument for PCM assessment—the danger lies in a lack of appreciation of the true complexity of the task, and this is likely to be the case when the project-at-hand is novel to the organization. All too often, however, the assessment is not performed, and uninformed commitments are made out of eagerness to please, enthusiasm to get going, and reluctance to spend time and money on an exercise that may eventually prove not to have been needed. These are the headline-making projects and they are not comfortable headlines.
At an extreme level, the correct response is to “get out quickly.” When this is not possible, for whatever reason (political or commercial pressure being the most common reason), then it becomes imperative to acquire the necessary experience from outside the team, either through recruitment (unlikely to be quick enough) or external consultancy. This does not mean that the project can simply sit back and watch, unless the consultancy intervention incorporâtes a managed knowledge/skill/wisdom transfer, the situation won’t improve and next time will be no better. Opportunities for developing internal repertoire must be grasped when they arrive, so that the sum of team experience/repertoire is increased and future projects placed in the top right quadrant.
High Experience, High Complexity – This is where the glittering prizes lie for those individuals and organizations that possess the repertoire and experience to dare to undertake complex tasks—not without risk— but with eyes wide open to the expectation that the unexpected is inevitable. In addition to their mastery and deployment of first order tools and techniques, they place huge importance on operating on a second order level.
So, what is second order project management and how does it differ from first order project management? Can it be performed by the same people?
First and Second Order Project Management
“They don't want scales… they want… music… all the scales, all mixed up… all the little black notes…
all…piggly-higgly… not only that… they want me to play without looking at the little black notes……just play!”
Signor Piginini (Henson, 1989)
Jim Henson’s The Ghost of Faffner Hall has an episode entitled “Music is more than technique,” (Henson, 1989) which includes a scene where the virtuoso violinist Piginini is discovered in the concert hall basement by the janitor. The maestro is frightened of going out in front of his audience, because, although technically brilliant, he can only play scales and arpeggios with the manuscript in front of him; however, the paying customers want him to play music from memory. (The story has a happy ending: The janitor shows him how to play the blues.)
Exhibit 2 - Excerpt from “The Flow of the Nile” © Rob Fordham. (Used with Permission)
As anyone who has ever tried to seriously learn to play an instrument will testify, scales and arpeggios are very important, because they provide the foundation of the technique necessary to make progress beyond an intermediate level. In themselves , however, nobody would ever buy a ticket to hear them. Essentially, they are the “good practice” processes that every musician needs to master and then apply appropriately in order to convey the message and emotion of the music. They are adequate for simple tunes, but a concert-level performance requires a different skill set altogether, not replacing, but in addition to, the basic principles.
The same holds true for project management. The first order tools and techniques —the PMBOK® Guide, earned value management, PRINCE2, CMM-I, and the others as mentioned above—are absolutely vital, up to a certain level of complexity, and are quite good enough to do the job and deliver against a firm requirement. As the complexity increases, though, simply following the rules isn’t enough. The project manager needs to be able to adapt, modify, and improvise, applying first order tools to the specifics of the task at hand (sometimes even “breaking” the rules on purpose); and, in addition, deploy a range of additional, less prescriptive, techniques and methods, as and when needed—we call these “second order” tools. Whereas first order tools are designed to apply process rigor, the common element of second order methods is that they are targeted toward the achievement of the deliverable purpose. Put differently, it could be argued that first order is about doing things the right way and second order is about doing the right thing. It may very well be that the behaviors necessary to apply first order methods—attention to detail, rigorous adherence to process may be a barrier to second order management, in which creativity and lateral thought are the major components.
Following are a number of components in second order project management:
The systems approach, in the sense we use it here, is the deployment of systems thinking and cybernetic concepts to understanding the interconnectedness of the deliverable to its subsystems and super system and their respective purposes.
Experiential learning is the means by which both individuals and the organization can capture, understand, document, disseminate, and apply the lessons learned from both past and current activities.
Appropriate contracting is the recognition by all stakeholders that in an uncertain future, it is impossible to share risk equitably within a fixed contractual agreement.
On their own, though, even these are insufficient. They depend on improvisational (or “adhocratic”) leadership—having the repertoire and courage to pursue the desired outcome in the face of uncertainty and “events”; in addition to this, it is impossible to ignore the ethical considerations relating to product/service development and implementation. But probably the most important aspect is the necessity of a project culture of outcome management (as opposed to requirements management), ensuring that there is a mutual accommodation between all stakeholders as to what would constitute fitness for purpose in the through-life operational environment. Because, in the final analysis, outcome is what it’s all about—it’s the effectiveness of the product that matters. Process is important in the development and implementation phases, but projects don’t end there; they continue throughout the lifetime of the product, and the true measures of their success will be in the usefulness, durability, and beauty of what they have delivered. Nobody remembers whether the Tąj Mahal, the Pyramids or St Paul’s Cathedral overran their budget and schedule, but nobody cares, either – whatever the cost, it was worth it….
There are many calls on the attention of leadership, many different stakeholders to be convinced, and many cultural and behavioral changes are needed if the above issues are to be addressed. Not the least, a grown-up attitude to project complexity demands the absolute necessity of sacrificing short-term gain and investing in second order project management tools and techniques in order to deliver programs of long-term organizational, social, and international importance. But, until this message is heard and acted upon by the senior executives in both the public and private sectors (and who possess the sufficient power to invest, support, and lead a permanent behavioural change in complex project acquisition), we will stay where we are! We need to remember that if we do what we’ve always done, we’ll receive what we’ve always received; if what we’ve always received isn’t good enough then we need to do something else. Simply applying first order project management processes more rigorously (the most common approach) is like shouting louder when a person from another country doesn’t understand English. As Albert Einstein said: “Insanity is doing the same thing and expecting different results.”
