"Case

The Project Manager/Customer Interface (B) Jack R. Meredith The following case continues the Project Manager/Customer Interface case from the previous chapter, exploring issues about the lack of control in that project. Jacqueline Doyle, manager of Contract Management, remains concerned with how the project grew from $500,000 to almost $2 million without her knowledge, and especially how she was drawn into a divisive meeting with the client without knowing ahead of time what the meeting was about. Jacqueline Doyle, Manager of Contract Management for BWNS, was having second thoughts about their recent contract dispute with NLP over the Green Meadow plant outage contract. She had recently issued a memo to project management hoping to avoid such future problems by listing their responsibilities as including the following: (1) Know who the decisions makers are; (2) ask the right questions of the right people; (3) control the customer; (4) get money for work performed; and (5) persevere. However, upon reflection, she was not confident these vague responsibilities would be sufficient to avoid similar problems in the future, or in some cases even actionable. She thus decided to consult some reference books on the topic of managerial control of projects, taking some notes as she read. She was first interested in the way changes occurred in the execution of the project plan due to unexpected changes in the scope of what was to be done and when. She read that this was called "scope creep," and was defined as follows: "The natural inclination of the client (or sometimes project team members) to change the deliverables as they obtain better information about their needs over time." She also found out that there are three common causes of scope creep: (1) Uncertainty about the technology involved in the project; (2) an increase in the knowledge of the client or user about their needs; and (3) A change in the agreedupon rules of the project. Jacqueline then wondered how to exercise control over these kinds of unanticipated changes. She found a book on project control that said there were three major types of control that could be exercised in projects: cybernetic, a type of automatic control based on feedback; go/nogo controls, such as phasegates at various milestones throughout the project; and last, postcontrol, to avoid problems in the future, which she recognized as precisely what she was doing. The book indicated that some incidents that affect the scope are clearly onetime events that, although difficult to predict, can frequently be mitigated by actions preceding the project. Jacqueline was intrigued by some of the techniques the book suggested such as adding time or cost buffers to the project, monitoring potential incidents for their impending occurrence, or through specific exclusions in the contract such as descoping contingencies. However, many events that appear to be onetime occurrences may in fact have been anticipated early on by careful attention to the past actions of the client, potential subcontractors, the likely project team, the PM, the project owner, the sponsor, and other such stakeholders. Jacqueline found the idea of monitoring project progress in real time to be interesting, rather than discovering problems later on after it was too late to rectify them. The book suggested a few different measures that could be used. One overall measure to indicate potential problems was a "critical ratio" defined as the actual over scheduled progress times the budgeted over actual cost which, if less than 1, indicated problems in the project. However, this ratio can be misleading if the actual cost or schedule looks good but the other measure is bad. To dig further into what the problem is, the book recommended individual variance analyses on both cost and schedule, or simply a projection of the final budget at completion. She decided to ask Reggie Brown about the feasibility of doing this. Since Jacqueline was in charge of contracts, the idea of adding contingency language to all project contracts in the future seemed to her to be an easy and excellent way to avoid conflicts with BWNS's clients, as long as they weren't perceived as harming the clients' interests. Thinking back to the NLP contract, a major delaying event in that project was the late delivery of the generators by NLP to SPIS, which could have been anticipated and a clause inserted in the contract. A primary assumption in the contract was that the generators would be delivered on time, but suppose they weren't? Another assumption was that NLP would accept SPIS' badging process, but they insisted on using their own process, which also delayed the project. Clearly, future contracts would have to be carefully reviewed for unspecified assumptions and then either contingency measures added for each of them or monitoring to avoid their occurrence. But what if a client, anticipating a problem, asked to change the contract before the project was completed, which could circumvent the contingency measures? Jacqueline realized that a "change control" section would be needed in future contracts specifying how requested changes by either party regarding things such as schedule, cost, or deliverables would be handled. Any proposed changes would have to be studied by both parties, perhaps a compromise reached, and then signed off by the appropriate officials of both the client and the contractor. Last, Jacqueline was irritated that she and Roberts went into a meeting with a client without having a clue what the meeting was for because the PM was on a field assignment and could not be reached. She wondered why she had not been alerted to the fact that there had been a problem with this project. Here she consulted books on managerial communications and project information systems. As she took notes, she came up with three likely possibilities. One was that the information may have been in her reports but was buried in details that weren't noticeable. Another was that the monitoring systems she relied on at BWNS were not appropriate for tracking projects, or perhaps individual project plans. The information systems book indicated a third possibilitythat the project's and BWNS's information systems did not work together and information about projects got lost at the upper management level. She decided that she needed to look further into these three possibilities.

Questions

1.) Would you consider the scope changes in the case to be "scope creep"? 2.) Are each of the scope changes one of the three basic causes of change in projects? If so, which one and why? 3.) Would you recommend any of the go/nogo control types for BWNS? If so, how would you suggest they implement these controls? 4.) Do you suspect that any of the three common reporting problems Jacqueline found were occurring? Can you find evidence in the case to support your suspicions? 5.) Jacqueline is trying to solve two problems: Avoiding conflicts with clients and learning about potential problems early on when they can be solved. What would you suggest for each one from what she has learned? 6.) What else would you recommend to Jacqueline?"