SCHEDULE, COST, AND SITUATION ANALYSIS
4.4 SITUATION ANALYSIS (SA)
4.4.1 Overall Situation Analysis Process
Maintaining sharp and continuous monitoring of project schedule, cost, and performance is, of course, an essential element of effective project man- agement. Indeed, the “nuts and bolts” of project management involves the
continuous positing of these questions:
1. Are we on schedule?
2. Are we within budget?
3. Are we satisfying all performance requirements?
However, if we get a “no” answer to any of these questions, or if other issues surface that could adversely affect them, the question then becomes: What else should the PM be doing? The answer lies in situation analysis (SA), which is fundamentally a problem-solving process at the project level. It is an adaptation of the “case study” approach utilized in some business schools.
It may also be viewed as follows: Case studies are to an overall enterprise (or key portion of an enterprise, such as a division) as situation analysis is to a project. Situation analysis is a sequence of steps to be undertaken by the project triumvirate (PM, PC, and CSE) once one or more problems or potential problems have surfaced.
The general situation analysis process is depicted in Figure 4.4. The first step (Box 1) in such a process is, as might be expected, to gather up, or restate, the facts that are known in the given situation. Such facts are usually in the domains of schedule, cost, or performance, but might be other facts not as immediate or obvious. Examples of the latter type of facts might be
1. A strike at the plant of a major supplier or subcontractor 2. Serious conflict between members of the project team 3. Resignation of a key member of the project
After such facts have been identified, two paths are suggested. One leads to a set of evident problems (Box 2) and the other to potential or inferred problems (Box 3). The former represent clear and irrefutable problems, normally of a high priority, that must be dealt with. Examples include:
1. Schedule slippage on the critical path 2. Expenditures greater than budgeted amounts 3. Missed contractual delivery dates
4. System testing failures
All are evident problems, almost by definition. How significant these problems are remains to be investigated in detail.
In the category of potential or inferred problems, we normally find occur- rences that may or may not lead to significant problems. In this regard, one finds secondary events that might eventually do serious damage to the project.
January10,200813:32CharCount=
Plan satisfactory
?
1 Known 2 4
facts a.
b.
c.
Evident problems
5 6
7
3
Problem priorities 1.
2.
3.
Plan for solutions
Risks/
benefits/
costs
8
Potential or inferred
problems
Implementation
Monitoring No
Yes
Who What When Where Why How
Figure 4.4. General situation analysis process.
124
Such events might be:
1. Project staff perturbations or conflicts 2. A change in the PM’s immediate supervisor 3. Company reorganizations
4. Loss of key people, not on the project team, but in support organizations such as accounting/finance, contracts, and human resources
5. Changes in subcontractor/supplier organizations
The point of separating evident (obvious) problems from potential or in- ferred problems is to assist in the eventual step of sorting these problems in order of priority (Box 4). A priority list is intended to force a discipline that assures that key problems cannot be ignored or placed on the back burner.
Without this discipline, a PM might be otherwise inclined to tackle more tractable issues that are of little or no real importance and avoid handling critical problems that might be difficult to confront. Such behavior may be difficult to understand, but it is part of human nature to not want to face unpleasant and stressful tasks.
Given the problems in priority order (Box 4 of Figure 4.4), the next step is to develop plans for solutions (Box 5). Plans at the top of the list must be addressed; plans at the bottom of the list might be deferred until further data are obtained. This is a judgment call that should be decided by the project triumvirate. The usual journalistic questions of who?–what?–when?–
where?–why?–how? should be considered, noting that a plan for situation analysis is not the same as a project plan. Plans must be evaluated in terms of risks (assuming that the plan is implemented), benefits, and costs (Box 6). Alternatives are recommended so that all reasonable solutions are at least placed in evidence. Leaping to premature or incorrect “solutions” can be more damaging than the original problem.
An important footnote to the formulation of the plan for solutions (Box 5) is the question of who it is that devises such solutions. Overall responsibility rests with the PM, PC, and CSE, but it is suggested that a team approach to problem solving be undertaken. In other words, information and proposals for solutions should be consciously elicited from members of the project team.
Full or partial team meetings are a good way to kick off such a process. In this manner, participative management can be demonstrated in addition to being expounded. More importantly, it usually leads to clearer definitions of problems and more effective solutions. More is discussed in this regard in Chapter 6.
Another implicit question is: When does the PM give an alert to the boss when there is a problem? The recommended answer is, for most situations, after the PM has developed an appropriate plan for solving the problem. In general, do not “hide” problems from bosses. At the same time, it is prudent to come to the boss with a complete plan for solution. This shows the boss that
the PM is on top of the problem. It also gives the boss a last opportunity to provide input into the plan, or to modify the plan if necessary. Implementing a solution without consulting the boss carries some risks with it, especially if the problem is severe.
Thus, the situation analysis process shown in Figure 4.4 involves two additional and very important considerations:
1. When and how to involve the project team
2. When and how to involve the PM’s immediate supervisor
Interim plans that are not considered satisfactory (Box 7) have to go back around the loop for improvement and consideration of alternatives. Once the plan is approved, implementation starts (Box 8). After that, the normal monitoring function is resumed.
4.4.2 Example of situation analysis
We pose a “situation” facing the PM as follows:
It is Wednesday afternoon and Jack, the Project Manager, receives a call from the Project Controller who claims that the latest cost report shows the project to be overspent, compared with budget, by 11%. Jack, meanwhile, had been thinking about his lead hardware and software engineers, who incessantly complain to him about each other. Jack now also begins to think about the project review session with his customer that is scheduled for 2P.M. next Monday. What should Jack do, and in what sequence?
A response to this situation, that is, a situation analysis, follows.
Step 1:This step calls for assembling the known facts, which, at this point, appear to be
a. The project is 11% overspent.
b. The lead hardware and software engineers are complaining about each other.
c. There is a project review session planned with the customer in ap- proximately five days (three working days).
Jack next picks up the phone and asks the Project Controller (PC) and Chief Systems Engineer (CSE) to come to his office immediately. The PC is asked to bring all cost and schedule data that are relevant. The project triumvirate then reviews the facts and overall situation from top to bottom.
Step 2: The cost overexpenditures are identified as an evident problem.
Step 3: The hardware and software engineers issue and planned meeting with the customer are placed in the “potential or inferred” problem category.
Step 4: The project triumvirate identifies the problem priorities as 1 Cost overrun
2 Scheduled customer meeting 3 Hardware/software engineer issue
They decide that the scope of the plan for solution will not include the hardware/software engineer issue. They also analyze, to the extent that they are able to, the data they have involving:
1 The cost elements that have been overspent 2 Why these cost elements are overspent 3 Potential effects on schedule
4 Potential effects on technical performance
This activity takes most of the rest of Wednesday afternoon. The project triumvirate agrees that more data are needed. Jack calls for a project team X meeting at 8:30 the next morning (Thursday). He does not reveal the precise purpose of the meeting. Project team X is a subset of the overall project staff and is handpicked for its ability to solve a problem of this type. Jack asks that the PC and CSE think about the situation but not convey it to anyone else until the meeting the next morning.
Step 5: The project team X meets on Thursday morning to discuss the two top-priority problems, in the following sequence:
1 Cost overrun
2 Meeting scheduled with the customer
Reasons for the cost condition are ascertained at this meeting. A basic plan (Plan A) for how to fix the overrun situation is set forth.
Step 6: At the same meeting, which is proceeding through the entire morning, Plan A is reconsidered with respect to risks, benefits, and costs.
Step 7: Based upon the preceding scrutiny, team X does not believe the plan is good enough. It is also 11:30 A.M. on Thursday morning. Jack asks all members of team X to reconvene at 2P.M., coming to the table with new and hopefully better ideas. Team members are encouraged to talk to other project personnel if it is considered helpful. All project personnel are reminded that the situation is to be kept within the project staff for the time being.
Reiteration of Steps 5, 6, and 7: Team X meets at 2P.M. and a new plan is devised that is considered satisfactory and, indeed, the best the team can formulate. This is a plan for correction of the cost overrun. Jack now focuses the team on the matter of the project review session with the customer, scheduled for next Monday. The team agrees that:
1 The customer is very likely to accept the plan.
2 There is no good reason to alert the customer to the problem before Monday.
3 They should confirm the Monday meeting with the customer,
Jack suggests to the team that now is the time to alert his supervisor as to the set of problems as well as the plan for solution. The team agrees that this is an important step prior to the implementation of the plan.
Step 8: As a precursor to implementation, Jack, the PC, and the CSE meet with Jack’s boss. The boss appreciates the steps taken and being kept informed. He also agrees with the plan, but insists on being present at the meeting with the customer on Monday. Jack and his boss agree on how to make the presentation to the customer, who else should attend, and what the roles of all participants should be.
This example illustrates the SA process as well as some of the vagaries of that process. The basic issue for SA is not how well one can analyze schedule charts and cost reports. The issue, rather, is how to mobilize a team effort to prioritize and find solutions to problems that invariably arise during the course of a project. The reader is invited to practice situation analysis for the situations that are included in the questions and exercises that follow.
QUESTIONS/EXERCISES
4.1 For the activity data related to a small project, as shown, draw the PERT chart and find
a. the critical path and its expected time b. the slack in all other paths
c. the standard deviation associated with the project end date
Activity Three Time Estimates (weeks)
A–B 1–3–5
B–D 1–2–3
A–C 1–2–3
C–D 2–4–6
C–F 4–6–8
C–E 1–4–7
D–F 1–2–3
E–F 1–3–5
4.2 Design a cost monitoring report that expands the data provided in Table 4.1.
4.3 You are at the 18-month point of a 24-month project with a$400,000 budget. The schedule variance has been estimated as$30,000 and the cost variance as$20,000.
The BCWS is$300,000.
a. ACWP b. BCWP
c. ECAC d. ETAC
Compare these results with those in the EVA example in the text. Why are they different?
4.4 In general, for a project:
a. If BCWP>BCWS, is the project early or late? Explain.
b. If ACWP>BCWP, is the project over or under cost? Explain.
c. If ACWP<BCWS, what conclusion, if any, can you draw? Explain.
4.5 What role does the Project Manager play in controlling fringe, overhead, and G&A costs and rates? How does the PM deal with increases in these rates that might result in a cost overrun?
4.6 Enter the data from Table 4.1 into a spreadsheet. Print out graphs of the results. Do the graphs provide insights into cost status that might not be revealed in columns of numbers? Explain.
4.7 The chapter provides twelve suggestions for dealing with firm fixed price bids or contracts. Identify three additional actions that might be employed in this regard in order to reduce risk. Explain your rationale.
4.8 Carry out a situation analysis for the following situations:
a. As a PM, you discover, at month 8 in a ten-month project, that you are 8% over cost. Your Chief Systems Engineer tells you that you can meet budget if the entire project team works a 48-hour week.
Your Project Controller estimates only a 50% chance of success with that strategy, but claims that 5% of the work done has been “out of scope.” You have a project status review planned with the customer in two days. What should you do, and in what sequence?
b. As a PM, it is Friday afternoon at 4P.M. and you receive a call from your customer complaining about the quality of your company’s last report and a bad attitude on the part of your on-site lead engineer.
Your customer wants to see you in his office at 9A.M. next Monday.
What should you do and in what sequence?
4.9 Locate a document produced by the Department of Defense that pro- vides guidance to a Project Manager regarding how to perform “sched- ule and cost” analysis of a project. Write a two-page discussion of the key points in this document.
4.10 Locate a document produced by NASA that provides guidance to a Project Manager regarding how to perform “schedule and cost” analysis of a project. Write a two-page discussion of the key points in this document.
REFERENCES
4.1 Frame, J. D. (1991).Managing Projects in Organizations. San Francisco: Jossey-Bass.
4.2 Kezsbom, D. S., D. L. Schilling, and K. A. Edward (1989).Dynamic Project Management.
New York: John Wiley.
4.3 Kerzner, H. (2000).Project Management: A Systems Approach to Planning, Scheduling and Controlling, 7th edition. New York: John Wiley.
4.4 Malcolm, D. G., J. H. Roseboom, C. E. Clark, and W. Fazar (1959). “Application of a Technique for Research and Development Program Evaluation,”Operations Research7:
646–669.