By Ian Whittingham, PMP in Gantthead
They are emblematic of the challenges of creating massive computational power, of visionary ambition thwarted by technological insufficiency. Debates over why they were never constructed and assembled during their designer’s lifetime break between the limits of manufacturing competency and the novel intricacy of their technical design. But in the end, it was a lack of sponsorship and the withdrawal of government funding that relegated an innovative turning point in the history of computing to a tantalizing “What if…?”
Today, however, if you are anywhere in the vicinity of
A combination of political, financial, engineering and legal issues are generally held to have been responsible for preventing Babbage--apparently a difficult man to work with--from constructing those steam age ancestors of today’s silicon chip computers. But through the sponsorship of another computer visionary (Nathan Myhrvold), a working version of Babbage’s Difference Engine No. 2 has now been fully realized and is on exhibit to the public at the Computer History Museum until May, 2009.
Many moving parts
Watching the highly synchronized movements of the many moving parts in Engine No. 2 is a mesmerizing experience, its 8,000 components the very image of mechanical order triumphing over mathematical complexity. In the world of computing, managing complexity at the machine level is something we all take for granted. But in the world of project management, it is something we are confronted with in a variety of hidden guises.
“Many moving parts” is an apt description of what complexity feels like for many project managers. Although it is difficult to pin down exactly what it is, we know it when we see it. We often experience it in the sometimes-chaotic juggling of requirements, resources and timelines that a particular project seems to create in its wake. Complexity manifests itself in many different ways, and there is a growing body of literature and research devoted to the understanding and modeling of how complexity impacts projects.
For the most part, complexity in projects--certainly where IT is concerned--tends to be synonymous with technological complexity. Even the historical example of Babbage’s difference engines appears to confirm that assumption. For many years, the failure of Babbage to actually build one of his engines was attributed to the limitations of Victorian technology.
The blueprints for the engines’ components called for a degree of manufacturing precision that was not possible to achieve with contemporary mechanical processes. Thus, excepting some partial mechanisms, none of the engines was ever fully manufactured and assembled. However, it was not simply the complexity of the engines’ technological requirements that sank Babbage’s grand project. Other factors were at work, too.
But before we look at those, how do we recognize that complexity, in general, might be present in a project we are working on? How does complexity manifest itself in a project that has many moving parts? While there is no single complexity indicator, complexity creates effects that ripple through a project in perceptible ways, of which the most common is ambiguity.
In general, ambiguity usually signals that there is some element of complexity present in a project. If you look at project planning and control techniques, one way of describing their purpose is the purging of ambiguity from the project and replacing it with clarity and certainty. (In fact, one way of viewing the process of progressive elaboration--of “developing in steps and continuing by increments”, emphasized in the Guide to the Project Management Body of Knowledge--is as a general purpose technique for driving out ambiguity from projects.)
Ambiguity is present when requirements are being interpreted in multiple ways or appear fuzzy and fluid in their definition. Or the sequence and order of project tasks keeps changing or appears disjointed. Or the objectives of the project itself are unclear or, even worse, unknown. Or at the participant level, when you find yourself in a project meeting and you have no idea what anyone is talking about or why you are there.
Ambiguity, incomprehension, opacity…these are some of the effects of complexity. (They can also arise in badly managed projects where the root cause is often discovered to be some element of complexity.) So, if these are representative of what the effects of complexity feel like, where do we locate the source of complexity that gives rise to these effects?
Accounting for the moving parts
Evaluating projects for sensitivity to complexity is not generally performed, either during project initiation or at post mortem reviews. There is no PMBOK knowledge domain that is devoted to complexity. The argument for supporting the view that no such special treatment is required is that complexity can be effectively analyzed and managed through the standard project knowledge domains: scope, time, cost, quality, risk, etc. Integrate these elements effectively, and you can manage any complexity that the project may create (so runs the logic of this argument).
However, I know that when assigned to a new project, many project managers like to ask the reasonable question: “Just how complex is the delivery of this project?” Intuitively, we know that complexity is the biggest constraint on project execution, and our instinct to account for it cannot always be satisfied by the standard project measures of time, scope and cost.
Failure to manage complexity implies a level of risk to completing a project successfully. Thus, how complexity impacts a project is usually represented in terms of ability to influence and control the impact in the same way that risk management assessments weigh the probability of the risk event occurring and the severity of its impact should it occur. A similar weighting approach can be applied to evaluating complexity.
The objective of such an assessment is to identify where a project may be most sensitive to the effects of complexity--that is, what aspects of project execution are likely to be most challenging to achieving the project’s desired results? The criteria that are applied in the evaluation, and how each criterion is weighted for sensitivity, should be determined by the needs of the performing organization, as appropriate to its own project management methodology. The table below provides some sample criteria that might be used to perform a typical complexity sensitivity assessment.
Table 1: Complexity Sensitivity Assessment
| COMPLEXITY CRITERIA | Example of low IMPACT | L | 2 | 3 | 4 | H | Example of high IMPACT |
| Technology Assets and Standards | Technical work required to achieve results reuses pre-existing capabilities and core technologies. Strong adherence to standards and policies. Process and methodology are well understood. | | X | | | | Work required is technically difficult and is new to the company. Technology is immature. New or multiple interdependent capabilities will need to be developed and deployed. Tactical workarounds may be required to bridge gaps while strategic solution is developed. |
| Organizational Complexity | Work can be achieved with a small group of geographically co-located staff, reporting to the same management group and adopting common working practices. | | | | X | | Many different parts of the organization will need to be engaged. Delivery depends on integrating many geographically and functionally dispersed groups. There may be conflicting priorities. Working (cultural) practices may be very different between groups. |
| Organizational Stability | There are existing groups in place who are responsible for delivering the components of the project solution. They can commit experienced and knowledgeable resource at the right time. | | X | | | | The delivery groups are in transition (onshore vs. offshore). Accountability and control may be an issue during the life of the project. Shortage of experienced or knowledgeable resource may constrain deliverables. |
| 3rd Party Involvement | This is an internal project, wholly under the control of internal and directly contracted resources. | | | X | | | A number of external parties are involved in delivery, either through partnership, recent acquisition or purchase of technology or services. An acquisition is anticipated during the life of the project. |
| Managing Expectations | There is some degree of flexibility in meeting the end date of the project. Trade-offs between functionality, quality and cost can be made without compromising the expected project deliverables. | | X | | | | There is an immovable, hard end date that must be met. The date is unrealistic. Quality, functionality or performance will be significantly compromised to meet the target end date. |
| Project Duration | This is a 6-month project and therefore would expect little impact from major, external change factors. | | X | | | | This project is expected to last more than 2 years and is therefore likely to be subject to major external change impacts that are not known and cannot be accounted for at the start of the project. |
| Sponsorship and Priority | Clearly sponsored by a single group or individual who has the ability to supply funds and resources and maintain priority. Project has a recognized and acknowledged priority within the company. | | | | | X | Sponsorship is ambiguous with several interested parties, none of whom have this as their top priority. Project has no company mandate or priority and is subject to discretionary funding, ad hoc resourcing and arbitrary decision making. |
| Dependencies | The project has no external, in-bound dependencies. | | | X | | | The project is dependent on multiple external projects run by different groups whose goals and priorities are not aligned with this project’s objectives. |
Another way of looking at each of the complexity criteria selected is as a barrier to achieving the project’s goals. A low barrier may be negotiated without significantly impacting project performance. A high barrier represents a potential roadblock that needs to be removed, through adjustment to the project schedule, resourcing, funding, organizational structure or whatever combination is required to manage the sensitivity of the criterion’s impact on project execution. But the most important part of this kind of analysis is to ensure that all factors that may introduce complexity into the project are included in the scope of the evaluation.
Construction of the Difference Engine No. 2 in 1991 by
With rigorous exactitude, Babbage accounted for the many moving parts that his calculating machines required in order to operate and function correctly. Unfortunately, in his visionary zeal he neglected to account for the complexity of those other moving parts on which so many projects depend for their delivery and success.
