Preventing Project Management Meltdown
A software company successfully launched its first product in its market—a groundbreaking application. The company received awards, sales picked up, and a well-known entrepreneur invested fourteen million dollars in the venture. A year later and out of money, the company desperately sought a buyer or merger—unfortunately having rejected a $150-million buyout offer eight months earlier.
What happened? Sales of software release 1.0 dried up because new versions of the product were announced. Millions of dollars of orders were in the pipeline, but the company could not deliver the new versions. With its earlier success and infusion of cash, why couldn’t this company deliver the software? It suffered from a common business epidemic—poor project management. The causes of which are complex and pervasive throughout most organizations.
The Standish Group, an independent research firm, recently reported that in large organizations—including private and public sector organizations—9 percent of projects come in on time and on budget, 52 percent wildly exceed their original estimates, and 31 percent are cancelled before completion. Information Technology (IT) and software project failures have led to increased awareness of, and interest in, project management. The International Organization for Standardization, for example, became involved leading to the development of ISO 10006 Quality Management—Guidelines to Quality in Project Management. ISO 10006 has been adopted as a standard by nearly one hundred member nations since 1997.
The Project vs. The Organization
An understanding of why projects fail can be gained by examining what appear to be two separate forces that contribute to failure: the dynamics of the project itself and the dynamics of the organization. These forces represent two distinct states: the project, a temporary state, and the organization, a permanent state. If left unrecognized and unattended, interaction between these two forces can produce catastrophic results. Management Elements Maximize Constrain Accept Performance Cost Schedule Effort Elements
Project Dynamics
The dynamics of projects are dominated by rules of engagement, which are the basis for project planning and decision making. Rules of engagement are a blend of management and effort elements used to establish quality objectives for a project. These elements may be aligned in a matrix to achieve project balance.
Effort elements are performance, cost, and schedule. Performance includes the functions, features, and benefits of the product or service being developed. An example might be a system that must process four thousand transactions per minute or a product that must weigh less than four ounces. Cost includes the financial resources budgeted to achieve the specified performance level of the product or service. Schedule is the time it takes to achieve the specified performance in the product or service.
Management elements are: maximize, constrain, and accept. These elements specify how each of the effort elements is treated during the project. Maximize means that the effort element cannot be negotiated or adjusted. Failure to achieve the maximized effort element results in project failure. Constrain means the effort element can be negotiated, allowing some flexibility without adversely affecting the project results. Accept means the effort element is accepted to achieve the specifications of the other two effort elements.
To complete the matrix, simply align one effort element to one management element. An example is maximized performance, constrained schedule, and accepted cost as shown in the matrix. Once an effort element is aligned to a management element, it cannot be reused. For example, if schedule is maximized, neither cost nor performance can be maximized. Doing so creates an impossible situation. Once alignment is complete, the rules of engagement have been identified for the project and effective project plans can be created. The same project under various rules of engagement will result in very different plans. Even after a project is well underway, the nature of the project may change, resulting in a change to the rules of engagement.
For example, a project may start with performance maximized, schedule constrained, and cost accepted. During the life of the project, funding may be severely curtailed, resulting in cost becoming maximized. Once an alignment changes, one or both of the other alignments must also change: for example, performance becomes constrained and schedule becomes accepted.
This is not a problem in and of itself. Change happens—especially in the volatile environment of high technology. What this means to a project manager is that new plans must now be developed. A change in the rules of engagement almost always means a new sequence of activities, with new dependencies, based on new thinking—in other words, a new project.
Failure to recognize a change in the rules of engagement means that project plans no longer reflect project realities.
Organization Dynamics
The following chart represents a model of almost any organization. It could be a university, a pharmaceutical company, a manufacturing company, a governmental agency, a hospital, or a department store.
The organizational scope spreads across the top of the model representing the functions of an organization, such as manufacturing, accounting, information services, customer service, inventory, research, and development. Depth lines the side of the model, showing the increasing level of detailed activities within each function of the organization. Scope Schedule Executive Layer Communication Gap Cost Operational Layer Communication Gap Performance Technical Layer Depth
The Executive Layer
Senior executives know a lot about their organization, its activities, and its functions. However, they do not know a great deal about the details of how each area operates. For example, a vice president of information services understands why the department exists and what its mission and objectives are, but is not expected to know details about the type of software tools used to create web-based applications.
The Operational Layer
Middle-level managers understand what their functional areas do. For example, a software development manager knows the process behind debugging Java™ in web-based applications, but would not be expected to do the task.
The Technical Layer
An organization’s technical layer is its largest group, made up of nonmanagement workers, technicians, and skilled and nonskilled labor. There is no group in the organization with deeper knowledge. These people are responsible for knowing how to perform specific project-related tasks such as debugging Java™ in web-based applications.
Motivational Drivers
Each organizational layer has a motivational driver that influences day-to-day decisions: schedule, cost, or performance. While all three motivational drivers influence all layers, typically one driver is the primary influence on the decisions of a specific layer.
Schedule, as a motivational driver, causes an individual or group to place highest priority on meeting milestones. The influence of this driver is typically most dominant in the executive layer. For example, executives will announce delivery dates before their project managers have developed plans to produce the product.
Cost causes an individual or group to place highest priority on meeting budgets and reducing costs—the most dominant influence in the operational layer. Middle management faces the constant challenge of controlling costs by whatever means, including downsizing, reorganizing, and generally attempting to do more with less.
Performance causes an individual or group to place the highest priority on producing the best product possible and is most dominant in the technical layer. These people are responsible for producing the product. They may have spent years perfecting their trade, and they want to ensure the product is a reflection of their skill and talent.
Communication Gaps
Motivational drivers influence more than just decision making. They influence entire behavioral patterns that can create intrinsic obstacles for organizations. The most common obstacle within all layers of organizations is poor communication.
Because people listen selectively and filter, the fidelity of communication spanning the organizational layers is questionable. This results in distinguishable communication gaps. An executive, for example, may only be receptive to schedule information, and not cost and performance information. Because of these gaps, the project is allowed to continue with people in each layer perceiving that the project is progressing satisfactorily according to their interpretation of the rules of engagement. In reality, however, the project may be completely out of control. Ineffective communication will always result in control defaulting to the technical layer. Management may continue to control actions, but is no longer able to control results.
Identifying the Problem
A host of problems have been identified through surveys as the purported causes of project failures: lack of resources, poor communication, the wrong project manager, changing requirements, lack of executive support, inconsistent decision making, and so forth.
However, according to consensus that emerged during the development of ISO 10006, the top three problems facing projects are changing requirements, poor communication, and inconsistent decision making.
Examining these problems reveals a valuable insight. Changing requirements really isn’t a problem. Can any organization embark on a project realistically expecting requirements to never change? It makes more sense to identify changing requirements as an event or situation that can be expected to occur throughout the project life cycle.
When a situation occurs, an action will be performed—effectively or ineffectively—followed by a result. Looking again at the three most common problems reveals another insight: if the requirements of a project change (situation), and are not properly and effectively communicated throughout the organization (action), inconsistent and random decision-making will occur (result).
Effective communication can align decisions with project realities and ensure that motivational drivers do not supercede decisions. With effective communication, the rules of engagement can be realigned and new project plans created.
Communication is the cornerstone of project success or failure. It plays a critical role in controlling the relationship between project dynamics and organization dynamics.
When the dynamics of the organization are allowed to influence the dynamics of the project, all three effort elements can become maximized—creating an impossible situation—and setting the stage for disaster.
Is There a Solution?
Identifying poor communication as the most significant threat to project success is not that difficult. However, finding solutions to the underlying causes of poor communication is not easy. There are as many solutions as there are consulting companies willing to provide them.
It is clear, however, that solutions must address both project dynamics and organization dynamics. Adherence to sound principles of project management is a good place to start. But, no matter how good a single project manager or group of project managers is, the organization must be infused with practices and processes that won’t go away or change when a project manager leaves or new projects are started. The establishment of a program management office is one solution finding acceptance in many organizations. This office approves, monitors, and supports projects across the enterprise. Among its most important functions is the facilitation of communication horizontally and vertically throughout the organization.
The software company illustrated at the beginning of this article failed because it did not recognize a change in the rules of engagement. In the confusion that followed, communication deteriorated and decisions no longer reflected the realities of the project. By establishing effective communication between the project and the organization, the project can be protected from organizational influences, preventing good projects from going bad.
Case Studies
APOLLO PROGRAM In 1961, President John F. Kennedy announced a bold initiative to send men to the moon. “I believe that this nation should commit itself to achieving the goal, before this decade is out, of landing a man on the moon and returning him safely to the earth.” Consider how this goal establishes rules of engagement. Kennedy’s statement contains two effort elements: performance and schedule. The performance statement is “landing a man on the moon and returning him safely to the earth.” The key here is “returning him safely to the earth.” If the astronaut could not be returned safely, the project would be cancelled. Based on this statement, the performance of the project was maximized. “Before this decade is out” is a clear schedule statement indicating that the schedule was flexible. The political reality of this statement was to beat the Soviet Union to the moon. The United States could afford to be a little late without jeopardizing the success of the project. The schedule was constrained. President Kennedy could not make a clear cost statement because the budget was in the control of Congress. Kennedy relied on popular support to pressure Congress to fund the project as specified, which they did, accepting the cost. With rules of engagement in place, NASA began planning for one of the biggest projects ever undertaken. The project to get to the moon was managed by these rules of engagement: maximized performance, constrained schedule, and accepted cost. In July of 1969, the Eagle lunar module landed on the moon with Neil Armstrong and Edwin “Buzz” Aldrin aboard. Three days later the team returned safely to earth.
SHUTTLE PROGRAM
NASA began the Shuttle Program following the same rules of engagement. However, throughout the late seventies and eighties, Congress was not so disposed to accept the costs and began to put limits on NASA’s budget, constraining the cost. Once an effort element is aligned with a management element, it cannot be reused. Because schedule had previously been constrained, it should have been moved to accept when cost became constrained. In order to regain the original levels of funding, NASA began to compensate by allowing the following influences to affect operations and decision making: attracting private sector funds through the satellite launching business; regaining both public and congressional confidence; and attempting to return to the “good old” glory days. To satisfy these motivational factors, NASA needed to establish its credibility from both a political and business perspective—something it never had to do before. The most visible way of establishing this kind of credibility was to maintain schedule. The year 1985 brought an aggressive schedule to the shuttle program. Launches were regular and on time. Schedules became maximized. NASA began to shift its rules of engagement without reassessing the entire program. By maximizing schedule, rather than accepting schedule, NASA maximized both performance and schedule—creating an impossible situation. The moment NASA decided to maximize schedule, and possibly without fully understanding what they had done, they allowed performance to be accepted. On 28 January 1986, with ice on the launch pad, a decision was made to launch the Challenger and its seven crewmembers—on schedule. A few seconds later the craft exploded. Although the rules of engagement had changed, NASA allowed organizational pressure to influence project decisions. This organizational influence widened the communication gap between the organizational layers allowing motivational drivers to take control over actions with disastrous results.
__
Article written by Michael G. Addario & Lloyd S. Weber Illustration by Tom Curry
About the Authors
Michael G. Addario is president of ADD/Ware Development Systems, Inc., a consulting firm that provides education and consulting in project and process management, quality assurance, and formal methodologies and standards. Addario has more than twenty-eight years experience in the IT industry and has worked in technical, management, executive, training, and consulting positions in a variety of organizations in North America, Europe, and Africa. He specializes in salvaging failing projects and implementing formal methodologies and standards. He earned a BS in business from Niagara College in Ontario, Canada in 1972.
Lloyd S. Weber is a senior partner at ADD/Ware Development Systems, Inc. He has been in the IT and computer industry for eighteen years working in various communication roles such as technical information developer, editor, manager, and consultant. His areas of expertise include communication planning and problem-solving strategies. He earned a BA in English from BYU in 1981 and an MS in Technical Communication from Rensselaer Polytechnic Institute in 1983. For more information on project management, contact the authors at (607) 272-7091 or at addware@addware.com.
