A natural approach to project management
Over the years, there have been many surveys and studies concerning reasons that projects fail. The reasons given usually point to uncontrollable external factors or, more commonly, inadequate execution of the plan. One reason that never seems to appear in these studies is that the wrong methodology was used. In other words, if we are to believe the studies, the strategy is always right, with failure caused by poor execution.
The purpose of this article is to:
Question the applicability of certain strategies in the delivery of Systems Integration (SI) projects—especially in the computer industry,
Sensitize the reader to some of the underlying assumptions that traditional PM techniques are based on, and
Suggest directions for further action.
Wrong Strategy or Poor Execution?
As stated, failed projects are usually attributed to uncontrollable external factors or to faulty execution. Projects will always be victims to some degree of outside interference, which can neither be predicted nor controlled. To deal with this, one usually includes some form of risk fund or schedule “slack” in an attempt to budget for the probability of some unknown problems occurring. But even so, certain events such as social unrest, natural disasters, regulatory or political intervention or other acts of God, may interfere to an unmanageable degree and cause the project to fail. But even with these we cannot rule out the strategy as the cause of failure. If, for example, an approach is chosen to deploy a small team over two years rather than a large team over one year and in the second year a so-called external event occurs that causes the project to fail, then in fact one could argue that the failure is caused by the approach and not by the event.
More importantly, however, we need to question whether poor execution is really just that. Indeed in many cases it is likely that the methodology may have been poorly executed, possibly due to incompetent or inexperienced application of the methodology, but possibly because it was impossible to execute correctly because it was the wrong approach. For example, using a matrix structure for a project team in an organization that is very hierarchical may never work—no matter how hard everyone works at it. Similarly, using a very structured and disciplined waterfall methodology for a new MIS system may fail in a very unstructured, loosely run organization where the users don't have a clear idea of what they want. It is easy to point fingers in those situations, but it may simply be a case of forcing a square peg into a round hole.
Modern Project Management, as we know it today, is only about 40 years old. As a profession, it is quite young and immature. The roots of modern project management come from large construction projects in the 1950s (mostly shipbuilding and aerospace). The techniques developed, most notably CPM and PERT, were subsequently applied successfully in the construction industry in general and more recently to virtually any kind of project in every industry, including software development and systems integration.
When we examine the rules around using techniques such as CPM, PERT and related tools, we can see some underlying (and generally unstated) assumptions. The four most significant of these are:
1. The techniques will be used in a command-oriented management structure . The assumption is that people need to be told what to do. This is certainly consistent with the military and bureaucratic roots of these techniques and the use of large numbers of skilled workers (blue-collar).
This is in stark contrast to the kinds of SI projects typical in the information processing industry these days, where one has a small number of highly educated, highly motivated people who are largely self-managed and accustomed to working in a cooperative team environment. The negative impact of using a command-oriented management style in this kind of environment is that it is at best ineffective, and at worst a disaster.
2. Tools (traditionally heavy equipment) and physical resources (traditionally the available labor pool) are the constraining and limiting factors generating an inherent conflict that needs to be managed.
This is a consideration to some degree in today's SI projects. Meeting and training facilities still need to be scheduled, and economics may require that the team share certain tools, such as a specialized workstation or other equipment—but for the most part, these are not significant issues that require a complex scheduling and management tool.
3. Users know exactly what they want. Project management tools demand that the project team identify and define all the discreet tasks that will be performed, regardless of the size or duration of the project, even if the WBS results in many thousands of tasks. This is only possible if there is a crystal-clear definition of requirements and solution up-front and if it doesn't change significantly.
When constructing a ship or a building, this is certainly more true. But in today's fast-paced world of change—and certainly in the computer business—this is definitely not true. Even if a user does know what he or she wants, there is a good chance it will change before it can be implemented.
4. Individual tasks have clearly defined boundaries including a start, an end, some dependencies, and a discreet and definable level of resource to execute. In other words, tasks are concrete, objective, atomic elements interdependent on each other, but also existing on their own in a particular time and place.
In a world of fourth-generation languages, prototyping, and end-user computing, it is ridiculous to try to put concrete boundaries around all the minute tasks that will be performed.
Collectively, these four assumptions paint a very mechanistic view of the world. Managing an SI project these days is just not that straightforward, and certainly contrary to the environment we find ourselves in today.
So What Do We Do About It?
First, I must say that I don't have all the answers. That said, here are some suggestions worth considering when addressing the concerns raised in this article:
1. Strike a balance between developing detailed specifications and getting on with the job. Don't “spec it to death,” but also don't jump in without requirements or planning. This is really a question of finding the optimal risk/ return ratio. We don't need to eliminate risk, only define it to the point where it becomes manageable. After all, that is why we have project managers—to manage risks.
2. Think in terms of “flows” of work  rather than rigid work breakdown structures. Keep the flows in synchronization through effective team communications and maintain control with tools like charters, checklists, and milestones rather than CPM and PERT. Expect the flows to have “eddies and whirlpools” (rework cycles) and strong “undercurrents” (politics and unknowns). This is a more natural view of the world in which we operate and in which we manage projects.
3. Learn to recognize and adapt to different organizational cultures. What works in one culture can be disastrous in another culture. The first challenge is simply to recognize the customer's or supplier's culture and do it quickly and early in the project cycle. Certainly experience is one of the best teachers in this regard, but formal training in “systems thinking” is a powerful tool that can help analyze and understand a particular organization.
1. Thamhain, H.J., and Gemmill, G.R. 1974. Influence Styles of Project Managers: Some Project Performance Correlates. Academy of Management Journal, 17, 2, 216–224.
2. Cooper, Kenneth G. 1993. The Rework Cycle: Why Projects Are Mismanaged. PM Network, vol. VII, no. 2 (February). Project Management Institute.
John Schmidt is a senior consultant and project manager at Digital Equipment Corporation with over 18 years experience in applying information processing solutions to business problems in diverse application and industry areas.
PM Network ● July 1995