Concerns of Project Managers
According to the Olde Curmudgeon
Sam began to feel better about this stuff called “Project Management.” While the demands of being a project manager were great, they did not seem out of reach. It was now time to get onto the details of how to get that raft built. Sam recalled two admonitions from earlier lessons: “Render unto thy client that for which thy client has agreed to pay” and “Thou shalt knowest what thou was asked to create. “Somehow this seems so simple, but could it really be? Could there be more to it than meets the eye? Are there traps and pitfalls ahead? Sam would learn that profit is that which is left of the revenue less all the costs of performing the project, including the extra work that was not anticipated and all the cost of any claims that would ensue if the Project is not completed to the client's satisfaction.
At a recent meeting, a simple solution was offered for avoiding disputes and their associated costs…write a better contract with a more complete statement of work! Later, a rhetorical question was asked: “Have you ever performed a project exactly as called for in the contract?” One person raised a hand. When asked, “100 percent?” the hand slowly went down. Of course, that was expected. It is in the nature of projects that there will be change.
The anomaly of projects is that while projects are to create change, change itself creates most of the problems of managing projects.
THE GENESIS OF PROJECTS
[Note: Projects come in all shapes and sizes and can be either internal or external. While the following discussion implies an external project of some magnitude, the concepts are equally applicable to an internal project of small magnitude Simply read “client” as “boss” and “contractor” as “myself”]
Projects are initiated as the result of a perceived need. That need may be for a new product or service for which a market is deemed to exist. The product must be designed, tested and plans prepared for its manufacture. The need may be to expand capacity to produce an existing product. The need may be for a structure to house people or objects.
Whatever the need, there is an urgency to fulfill that need. The urgency leads to two things: a pressure to get on with the project, and less-than-complete knowledge of what is actually required. In addition, there is an inevitable pressure to complete the project without spending any more money than is necessary, given the urgency and the performance requirements. Perceptions differ on how much money is necessary.
Under such conditions, there is inevitably risk. Risk that the project duration will be longer than expected. Risk that the cost will exceed expectations. Risk that society will insist on requirements being met that were never anticipated. Risk that the performance of the product of the project will perform at less than was expected. And, yes, risk that the need for the product of the project will disappear, e.g., the Superconducting Super Collider, or that a competitor will meet the need first and thus significantly reduce market share. All of these risks must be weighed in decision making about the project.
Thus, the instigator of a project must make a myriad of decisions in the face of less-than-complete information. If the contract is desired, the contractor who hopes to provide the services of performing the project must also make many decisions in the face of less-than-complete information. Thus, the game is defined.
Editor's Note: This is the seventh in a series of articles depicting the travels of Sam in search of the wisdom necessary to successfully execute this project. [It is left to the reader to decide whether Sam is short for Samantha or Samuel!]
There have been times, and people, where agreements to perform a project could be based on a handshake. That happens occasionally even today. However, the pressure for profits and the litigious nature of our society make it extremely difficult. Thus, it is common practice to enter into contracts to define the relationships between two parties to a project and the nature of the product that is to be produced.
Characteristically, the contract development process has been a complex “game” to define the product desired by the client and the project that is to be performed to produce that product. The client is motivated to obtain the product at the least cost, time and risk while the contractor is motivated to get the project, make a profit, and incur minimum risk. Thus the stage is set for conflict.
It could be argued that both parties are acting in good faith…the client not wanting anything for which they have not paid a fair price and the contractor dedicated to deliver everything for which they were paid. But that would lead to a rather short and uninteresting, if not unrealistic, analysis. The more likely scenario is that each party is looking out for their own self-interests, generally in the short run.
Given this scenario, it is easy to impute all sorts of behaviors to both the client and the contractor. For example, one strategy sometimes followed by contractors is to bid low and make it up on changes. The client may use a strategy of leaving out some of the small details, expecting to persuade the contractor to do them without issuing change orders.
So what can be done to manage this “game”?
The first step is to establish a clear definition of what is understood to be the product of the project and what work will be done to produce that product. This presumes a relatively clear idea of the nature of the product of the project and of the work required to produce it. This understanding must be put in writing in a clear and concise manner. It forms the baseline from which future changes in the product, the project, or both can be measured.
Often it is necessary to describe the product in terms of performance requirements. In such cases, it is much more difficult to accurately describe the work content of the project, especially when the project involves pushing the state-of-the-art of one or more technologies. This makes defining the baseline more difficult. Nevertheless, the more definitive the baseline, the less likelihood there is for disagreement during the project.
One way to deal with this situation is to break the project down into phases, with each phase designed to reduce the uncertainties in the next phase. Go/no-go decisions at the end of each phase provide a means of controlling the commitments for the future.
MANAGING CHANGE (or Dealing with Sneaky, Creepy Change)
If change is inevitable in projects, then we must behave as if it will happen rather than as if it will not happen. Working from this understanding, it is reasonable to manage the changes in such a way as to build confidence between the parties to the contract and protect the financial interests of both parties. There are two aspects of change that require managing: formal and informal.
Formal change is the most straightforward to manage. Basically, there is a recognition that the product of the project must be different than was originally envisaged or that the process of the project must be modifiedin order to produce the envisaged product. The need for change can be recognized by either the client or the contractor. A formal request is issued, the impact of the change is analyzed, the cost estimated, and the price submitted to the client. The client either accepts, rejects, or negotiates, eventually making a deal. Managing this process requires excellent administrative procedures combined with very fast resolution of the issue. Failure to achieve speedy resolution often leads to dispute, either over delays or the acceptable cost of the change.
One essential aspect of change management is document control. Since change is inevitable, the effective and assured communication of all changes is of the utmost importance. All members of the team must be playing from the same sheet of music. The result if this is not done can be interesting. For example, in building a house, the plumber was not provided the latest changes. A drain pipe from the upstairs sink ended up cast in concrete about six inches from the “changed” location of the partition in which it was to run. Upon completion of the house a small white ceramic vessel was installed on that partition and connected to the drain line. The result was the opportunity for the project manager to fulfill a life-long ambition!
Informal change is the difficult part to manage. It is insidious. Without a clearly defined baseline for scope, it maybe impossible to identify the change. One scenario, in developing a computer-based system, is for the client to sit with the programmer and suggest modifications to the program that go beyond the specifications. “Wouldn't it be neat if we just add three more lines of code?” is typical. Being an ingenious and obliging programmer, the statements are added. Not being in the specifications, there is no test for them. Eventually, they show up in the last integration test, causing test failure, a lot of searching for the problem, and rework to remove the offending statements. Sometimes the code works and the client gets a nice freebie. To paraphrase the late Senator Everett Dirksen, “A small change here, a small change there, and the first thing you know you are talking about real money.”
What can be done to manage informal change? A well-disciplined project team is important. Even more effective is a team that is motivated by incentives tied to successful completion of the project. “But that cuts into our profit!” On the other hand, the cost of rework, delays in completing the project and receiving payment, and resolving disputes may completely wipe out all profit.
(For the internal project, it is equally, if not more, important to document scope. Bosses are often even more adept at changing the scope of work. Formal change can be managed as discussed above. Documentation is the key. Informal change may require more adroit behaviors. For example, one boss used to have me write speeches for him. After the last one was written and approved by my boss, he asked me to get it approved by corporate public relations. They asked that one paragraph be modified to reflect a positive rather than negative view. It was easy but required the use of the phrase “all other things being equal” or its Latin counterpart, Ceteris paribus. After careful calculations, the probability that my boss would reread the speech before getting to the podium was determined to be nil. I used Ceteris paribus. He stared at those words for, well, quite a while. Thereafter, my scope of work remained somewhat reduced. Not a generally recommended strategy except for the most secure or the most foolhardy.)
One of the interesting areas of project management today is the quest for better ways of working together to minimize, if not remove, this conflict. Partnering is the focus of this issue of the PMNETwork. In partnering, the basic approach is to change the game from me and them to we. One way to view the situation is that the client has temporarily hired the contractor's personnel for the duration. (If the project comes out well, they may hire them again.) If the project is approached with both parties on the same side, their respective self-interests are best served by selecting the ultimate best solution for the client. This does not negate the need for scope management but does make it somewhat easier because a change effects both parties in the same manner.
THE GOOD NEWS
Avoiding disputes is only one aspect of good scope management. It leads to greater profitability, more repeat business, and probably more new business. It leads to greater satisfaction by the project team and greater willingness of good team members to want to be on the project manager's team in the future. It also leads to more peaceful sleep and lower bills for antacid.
Thinking about the scope of the project at hand, Sam recalled the effort required to get a clear statement of the objectives of the project. It was necessary to build a raft to carry all the household items, 50 sheepskins of grain, 30 sheep, 20 geese, /0 goats, 5 asses, 2 oxen, and I aged mother-in-law. There were other questions to be asked. What would be the size of the flock… and the family, for that matter…by the time the raft is completed? Must all these items be transported at once or could they be transported in several trips? If it had to be one trip, what would be the numbers of these critters by the time the raft was completed? Could the animals be tethered or would they have to be contained within the structure? And on and on. Finally, Sam decided to make a sketch of the raft and a detailed list of all the work to be accomplished to build that design. Then, if the size of the flock or the family changes, appropriate compensation could be sought in a rational manner. Sam heard that a Work Breakdown Structure could help define the work to be accomplished but sought a better way to describe the product of the project. Perhaps a structured bill of materials or something like that would be useful.
PMNETwork • September 1994