Project Pitfalls
Despite the best efforts of the project manager and the project team, organizational forces may work against project success, especially on projects with tight time constraints.
This column normally deals with issues of applying Total Quality Management (TQM) to Information Systems. A recent consulting assignment, managing a system development project on a very tight time schedule, afforded an opportunity to experience organizational forces which worked to defeat even the best project management efforts. Therefore, this column will discuss the organizational pitfalls and obstacles which a Project Team may encounter.
In the Winter 1994 issue of Information Systems Management, I wrote an article entitled "Productivity Through Project Management -- Controlling the Project Variables." The article discussed project management methodologies, directed at controlling the work to be done, the resources assigned to the project and the schedule within which the project was to be completed. These are all factors directly under the control of the Project Manager.
Other factors may determine the likelihood of project success or failure. These are not under the control of the Project Manager and are not factors dealt with in Project Management methodologies, books or training classes. They are organizational factors which must be overcome in the course of the project effort.
Observation of these factors comes from many projects which I have managed in all types of organizations. They are present to some degree in every organization. Tight schedules, or "crunch mode" projects, will focus their effects. Even though the Project Manager may not be able to control these factors, awareness of them and appreciation for their effect will provide an increased chance of project success.
Project scope and objectives
Project objectives are never communicated to all parties who will be affected. Top management usually feels that the decision to undertake the project should be sufficient to get everyone behind it. They feel that they don't have to "sell" the project, to explain why it is important or what it will do for the organization.
Many times individuals who feel that they should have been consulted on the decision to undertake the project, or whose point of view was not heeded, will not support the project or will continue to actively oppose it.
If the Project Manager finds that he or she has to "sell" the project or explain it to individuals who are affected by it, then the project is probably already in trouble.
Project scope is not understood by all parties who may be affected. Management does not even recognize who all these people might be. Individuals who are unaware of the project cannot be expected to support it.
Sometimes, when difficult scope questions are raised, they are simply ignored. The attitude is often "we'll worry about that later." Failure to deal with fundamental scope questions out front is another sure sign that the project is in trouble.
Requirements are not fully known. Decisions are made based on partial understanding of the project. The impact is not fully appreciated. Surprises are the rule rather than the exception.
Requirements may be stated for which there is no known solution. If you can't express how you are going to meet a requirement, the chances are that you won't be able to meet it. For every requirement, there should be a definition of acceptance criteria -- evidence that the requirement has been met. If this cannot be clearly stated at project inception, then the project is in trouble.
Lack of business rationale
The business rationale for undertaking the project is almost never communicated and is never given wide dissemination. This is often true because many "crunch" efforts don't make good business sense if given close scrutiny. They represent efforts to correct some gross oversight or major mistake (usually at or near the top of the organization).
Crunch projects are typically ones which could have been accomplished as a normal part of the business if management had been sufficiently far sighted to plan effectively. They are reactionary in nature, meant to address a problem which already exists, usually a problem that is severely impacting the business.
Project budgets and approvals
If there is a project budget established at all (frequently not the case with crunch projects), that budget may be grossly insufficient as major items may have been overlooked in the rush to start the project. When the budget is exceeded, this could cause problems in getting expenditures approved. If there is no budget, the same problems can occur at any time someone chooses to look at expenditures. Funding is always an issue after the fact.
The decision to approve the project is not necessarily a decision to approve what it takes to do the project. Many separate approvals may be needed and these are often poorly coordinated or communicated.
Often approvals are held up to make a point. We once experienced a chief executive refusing to approve an expenditure for four days on a project with an extremely tight deadline "just so everyone around here remembers who the boss is."
Mistakes can be made when attempting to rush things through, causing requests to be held up or denied. Delays are to be expected. Without extraordinary management action, some requests may be denied or delayed indefinitely. Extraordinary management action is not always forthcoming.
Project Support
The project may not be taken seriously in some quarters. There may be an unstated but generally held belief that the project will not achieve its objectives nor meet its schedule. This, of course, damages the credibility of the project team and inhibits cooperation. Project team members may share this view as well, reducing their commitment or level of effort.
Look at the history of the organization in this regard. If crunch projects are common, how many of them succeeded? How many projects of any type actually achieved their objectives on schedule and within budget? When managing one such project for a large client, I was told that implementation on schedule would be impossible, even though development was on schedule. The client manager told me that never in the history of the organization had any project been completed in "less than two years behind original plan." Of course, nobody believed that the system would be ready for implementation so nobody was prepared.
The project will not have unqualified support. Members of management may continue to oppose the project long after it has been approved. This opposition can be vocal and active or it can be simply refusal to cooperate in small ways which delay the project or damage its chances for success.
Given the structure of most organizations, these problems are impossible to deal with unless all involved parties report to the same individual. This individual must be committed to the project and be willing to demand cooperation.
In one organization I was involved with, absolutely nothing ever got accomplished unless one senior vice president insisted that it be done and commanded all the resources necessary to accomplish it. Cooperation across departmental lines was impossible -- this was due in part to the fact that rivalries between vice presidents were at least tacitly encouraged by the president.
In another organization, the structure was such that no one person had the authority to make and implement even the most mundane decisions. The organization structure limited span of control. Members of middle management did not get ahead by making decisions which affected others (these decisions were simply ignored anyway) or by bringing issues up to vice presidents who generally did not have the power to deal with them effectively anyway.
Organizations are structured to allow, and even encourage, individuals to pursue independent courses of action. Where the organization does not have a clearly defined strategy and agenda, and feedback mechanisms in place to ensure that the agenda is followed, employees at all levels will adopt and follow their own private agendas. The organization may have many agendas and conflicting priorities. It is then left up to the individual to decide which course of action to pursue.
Politics is the name of the game in these organizations. Employees form temporary alliances and engage in horse-trading to get what they want. Cooperation is often secured by threats of exposure of errors or negligence.
The ability to accomplish anything in these environments is looked upon as "resourcefulness." Individuals who are successful in spite of all the obstacles the organization presents sometimes reap benefits -- usually in the form of an assignment to take on another project and go through all of this again. A danger is that in accomplishing things one may gore some sacred oxen, incurring lasting animosity and limiting future effectiveness.
Issues will arise of both support from upper management and freedom to act. It is wise to test this early but don't feel that the results will be the same on every issue.
Other Priorities
Employees outside the immediate project team have other priorities. They will not be responsive within the requested time frames. Management may be unable or unwilling to deal with these issues.
Personnel may be asked to assume duties outside of their normal assignments in support of the project. They, or their management, may resist or give these duties very low priority.
A sure sign of trouble is the necessity for the Project Manager to negotiate agreements among these individuals for support.
Project Control Control is not firmly established, at any level. Several individuals may attempt to wrest control or test the limits of the Project Manager's control. They may be unwilling, however, to also assume responsibility.
Attempts at control can be insidious. In one instance I was forced to deal with, an individual assigned to the project team on a part time basis set himself up as a conduit for communications between the project team and user management. He proceeded to provide both parties with false information about project activities. When this became known he then refused to cooperate further in performing assigned duties on the project.
"Turf battles" are common, often over seemingly small considerations, such as the control or use of a tool. Some individuals will insist that all communications go through them, restricting access to subordinates or other groups.
The assignment to perform a task, no matter how small and insignificant, is viewed as authority to withhold or delay performing that task. As an example, a clerk was assigned to enter contractor rates into the organization's Payroll System. This was part of her normal job, she entered all employee pay rates as well. The clerk's manager decided that he would "approve" contractor rates before allowing them to be entered, thus delaying the ability to hire contractors on a critical project.
Some individuals will insist on rigor when there is clearly no time for the desired level of rigor. While rigor may be waved in some quarters to meet the schedule, other areas may insist on following procedures or preparing voluminous documentation or justifications. Insistence on rigor may be viewed as lack of support, lack of confidence in the project team, or deliberate attempts to create obstacles for the project.
Project Management Approach
Every person has his or her own approach to project management. They feel free to criticize a different approach. Very rarely will anyone say, "What do you need?" or "How can I be of help? ", but many will feel free to say, "You've got to do this or that," or "Unless you do such and so, the project is doomed." The worst case is that management, through fear or lack of understanding, supports these views. Beware of instant experts, doomsayers and hip shooters.
Some members of the project team may be uncomfortable with a given approach, to the point where their performance suffers or the morale of the project team is undermined. This may be especially true of highly specialized disciplines, such as Data Administration or Quality Assurance. The Project Manager must be sure to "sell" the approach to the team. Good project team orientation is essential. Even so, there are some people who will not perform well on crunch projects. If possible, they should not be made part of the project team.
There will be pressure to proceed before sufficient understanding is obtained. Some people, usually members of management, will insist on a plan, schedule and estimates before the work is fully known. Or, they may insist on starting development without adequate design. You can't plan what you don't know, and you can't accomplish what you don't plan. The Project Manager must insist on adequate time to plan the project and top management must support the Project Manager in this regard. If this support is not forthcoming, the project is almost certainly doomed to failure.
Dealing with Outside Vendors
Outside vendors and organizations not under the direct control of the project team may not be responsive. They have their own way of doing business. Many vendors are not able to effectively alter their mode of operation on short notice. This may cause disruption and/or lack of cooperation. "An emergency situation on your part is not necessarily a crisis situation on my part."
Vendors may also attempt to assume control of the project. They may wish to use their status to obtain additional work. Lack of responsiveness may be used as a tool in this regard.
Project Execution -- Changing The Rules
Project requirements which should have been known out front creep in later. Ground rules have not been clearly set, and so they keep changing.
Standards which should have been established at project inception are imposed retroactively.
Staffing, equipment, work space, supplies, training, security access and support are poorly coordinated. The Project Manager can insist on certain things but execution is dependent on individuals and organizations outside the Project Team. Idle time is to be expected, and cannot usually be planned.
Personnel who are assigned "part time" and/or are not located contiguously with the Project Team may be unavailable even if promises are made. "Vanishing resources" are common on crunch projects. The Project Manager can carefully document these problems but may only reap enmity and further lack of cooperation.
There may be resistance to frequent status reporting. Feedback and control mechanisms are not always in place. Frequent status reporting is essential to the success of projects on a tight time schedule. Small adjustments to the plan are needed throughout the project if the overall schedule is to be met. Feedback must be timely and accurate throughout the project. Resistance to status reporting cannot be tolerated if the project is to be successful.
Informal agreements may be made to expedite progress but then may not be honored later. Lack of formal agreements may cause discomfort for some individuals. However, insistence on formal agreements may needlessly delay progress and create hostility and lack of cooperation. There is just no way to balance these issues with any degree of certainty.
At project inception, many short cuts may be taken, especially if individuals believe that success is problematic. Later, when success seems imminent, standards may be imposed which could jeopardize the very understandings that brought the project to the brink of success.
Summary -- Project Success or Failure?
When the project is successful, those who did not believe it would happen and those who were unaware of the scope of the effort will not be prepared for implementation. This may cause significant delays and necessitate changes to the system. Political considerations can play a major role in determining when and how the system will be implemented. The Project Manager may still have to "sell" the project at this point.
There will always be those who will feel that their own interests (or the interests of the organization) are best served if the project fails. Failure is always possible if the Project Team is not diligent. Even the best systems can be undermined well after they have been implemented.
There are no easy answers for these problems, and maybe no answers at all. The best a Project Manager can hope for is to be aware of the problems and to make management aware of them as well. Management support in dealing with organizational issues will always be a major determinant of project success, especially on projects with tight time schedules.
Email this article to a friend.
Comments to:
