CASE STUDIES

Week 7 - Ch. 3-4 - Managing Project Execution, Monitoring, Control, and Closing

Contents I. Managing Project Execution 2 On Execution and Work 3 Module Highlights, Commentary, and Lecture - Managing Project Execution 3 Steps to Successful Project Execution 4 II. Managing Project Monitoring and Control 4 On Monitoring, Control, Measurement, and Correction 5 Module Highlights, Commentary, and Lecture - Managing Project Monitoring and Control 6 Project Control 6 Earned Value Management 6 Baselining 10 Bibliography 10 Scope Creep (reprise) 10 Change Control and Change Management 11 III. Managing Project Closure 11 On Closure and Completion 12 Project Closure and Completion 12 Project Success 13 Project Post-Mortem Evaluations 13 Bibliography 13

Figure 1 Work: Factory and desk

Screen Beans Art © A Bit Better Corporation

This is what it's all about. This is "where the rubber meets the road" (as the old tire ad used to say). Or, as Bill Cosby said in one of his routines, "I told you that, to tell you this."

Most of the previous chapters were about planning and preparation -- planning and preparation for Project Execution, in order to make Proj Execution go better, easier, and be more successful.

Sometimes, especially in PM classes, it's too easy to concentrate on the planning, the documents, the methodologies and techniques, while overlooking the fact that the whole point of the project is to deliver the deliverables. Not the PM deliverables like the plans and schedules, etc, of course; but the technical work of the project -- the software, services, networks, products, what the project was done for in the first place. All that happens during Proj Execution.

However, Project Execution isn't only about the technical work, either. We did all that planning in order to make Proj Execution go better. We don't want to abandon all that now! So now, we need to stick to our plan and execute our plan.

This isn't easy. It's not a toy to wind up and just let go. If it was easy, and if it usually went according to plan, then they wouldn't need a project manager to do it!

As we're all pretty much aware, the system operation and maintenance stage (when users actually use the operational production system) is much longer than the project itself. Similarly, the Project Execution phase (when we actually develop and build the system) is normally much longer than the project initiation and planning phases. In other words, while in this class we spend more time on project planning, real projects spend much more time in Project Execution.

Simultaneously with managing Project Execution, we also monitor and control the project. Some of that will be discussed in this section on Project Execution, and some in the next unit (below) on Project Control and Closure.

Plan your work and work your plan.

-- Anon.

The fundamental qualities for good execution of a plan is first; intelligence; then discernment and judgment, which enable one to recognize the best method as to attain it; the singleness of purpose; and, lastly, what is most essential of all, will -- stubborn will.

-- Ferdinand Foch (1851 - 1929)

It is amazing what can be accomplished when nobody cares about who gets the credit.

-- Robert Yates

Being busy does not always mean real work. The object of all work is production or accomplishment and to either of these ends there must be forethought, system, planning, intelligence, and honest purpose, as well as perspiration. Seeming to do is not doing.

-- Thomas Edison

Nothing is really work unless you would rather be doing something else.

-- J. M. Barrie

"Once it is in motion, a project acquires a direction and momentum which is totally independent of anything you predicted."

Note: Recognizing your heavy life load and not wanting you to duplicate your effort, these lectures do not repeat what is in the textbook, but add on, and occasionally emphasize, in order to give you everything we expect you to know about this topic. In order to comprehend the subject matter, it is necessary to read both the textbook selections and these lectures. (The same applies to the other lectures, below.) Every effort has been made to give you a quality educational opportunity without wasting your time.

Figure 2 Monitoring and Control: EKG, stethoscope, complex jet cockpit, bar graphs

Simultaneously with managing project execution (the previous unit), we also monitor and control the project. So there is some overlap with these last two units.

Also notice that monitoring and control overlap with all the PM process areas. That is, there is scope monitoring and control, configuration management (which has elements in both execution in monitoring and control), cost monitoring and control, schedule monitoring and control, risk monitoring and control, quality control, etc. So some of the elements of monitoring and controlling should look familiar, as they have already been discussed, at least in brief. We will get into more depth here, however.

"You can't manage what you don't measure."

-- Anon.

"Be vigilant. Lackadaisical project managers rarely manage successful projects."

-- Dana Bobko Isenberg former IFSM 438 student Aug. 9, 2012

"In God we trust. All others bring data."

-- Jim Marsden Master Project Scheduler

"Trust, but verify."

-- Ronald Reagan, quoting a Russian proverb

"Possibly the most important issue to consider for ensuring project management success is project control…."

-- Fuller, Valacich, and George Information Systems Project Management, p.407

"Frustration, although quite painful at times, is a very positive and essential part of success."

-- Bo Bennett, Year to Success

"Problems are only opportunities in work clothes."

-- Henry Kaiser (1882–1967)

"No battle plan survives first contact with the enemy."

-- Helmuth von Moltke the Elder, Chief of Staff of the Prussian General Staff, c.1861

"He who does not remember the past is doomed to repeat it."

-- George Santayana

First, let me emphasize that project control is not the same as controlling the people. If project monitoring and control sounds like micromanaging or managing by fiat, then that misses the point. In fact, the whole area of monitoring and control is not about controlling the people, but about controlling the project . There's a difference.

Remember Week 1 and Chapter 2 on project organization? It is highly likely that the project manager does not supervise or directly control the people on the project team -- especially in a functionalized or matrix organization. But the PM still monitors the project, its status, its tasks, and its execution. And the PM still controls the project. That's the PM's job regardless of the organization structure. Granted, it's more difficult when the team does not report to the PM, but that's exactly the situation in in functionalized, matrix, and even some projectized organizations. The PM is responsible, the PM is accountable, but the PM has to manage by leading, negotiating, encouraging, exhorting, and personal power -- not by formal authority, or legitimate, reward, or coercive power.

Suppose we're in the middle of our project, have finished half the tasks, and have spent half our budget. Are we on schedule and on budget? How would we even know? What if we've completed all the easy tasks or all the cheap tasks and still have the long, hard, expensive ones ahead of us? In this case, are we still on schedule and on budget? What about if we're 3/4 done with the project and have spent only 1/4 of our budget? Are we ahead or behind? Again, what if it's the slow, complex, difficult, expensive tasks that are coming up? Have we spent our time and money where it should have been spent? How would we know?

Earned Value Management (EVM) -- or just Earned Value (EV) -- is a technique to answer these questions, get a fairly accurate project status, and well as to forecast the future of our project's costs and schedule.

The gist of EVM is to assign a worth to each task (its Earned Value), and that worth is its budgeted cost and budgeted schedule time. Then when a task is completed, we can compare the actual cost and actual time to what it is worth, i.e., to what we should have spent on it.

EVM is one of the only ways I know to get a fairly accurate adjusted estimate of how a project is doing and when it will be completed, based on how it's done so far. It is useful during execution and control (not planning) for such estimates. For instance, suppose we know that our project has slipped a little and know it has gone over budget a little; or suppose we know it's slipped but is under budget. The initial (baselined) schedule and budget are now incorrect. When will it complete and what will it cost? EVM can tell us that.

· The standard Estimate to Complete formula = ETC = EAC - AC to completion. This is not the same parameter as the some sources' Estimated Time to Complete, which might be better abbreviated as ETTC, as I've called it above. (For that matter, the standard Estimate to Complete parameter might be better abbreviated as ECTC -- Estimated Cost to Complete. However, ETC is the standard abbreviation for this.)

· It's not that the formulas are wrong; they're actually both correct. Rather, it's that they're calculating two different and unrelated things. The unfortunate thing is that they used the same abbreviation for these two different and unrelated things.

· As nearly as I can tell from checking a lot of references including the PMBOK and the Gold Card, both of which are definitive, the simplified formula for EV = PV * % Complete is only correct if the PV figure is PV at completion, i.e, project budget, i.e., BAC. Otherwise, it's got the equivalent of two percentages in it, which doesn't make sense. Fortunately, that rarely if ever matters, because EV, PV, and AC are essentially always given or measured, not calculated from other parameters, so this would probably never actually occur in real life. It's the other parameters that are calculated from these three, not these three from the others.

· More on this in my answers commentary after we complete the week's work

The textbook discusses baselines in Chapter 4, Chapter 5, and Chapter 7.

The book mentions that we can baseline almost everything -- the schedule, the cost, the scope, the documents, etc. In this class, we will be concerned primarily with schedule baselines, and secondarily with cost baselines. The textbook fails to emphasize, however, that it is normally most useful to maintain three schedules for each project:

· The original baseline as of when the project was first planned and approved. This is the baseline mentioned in the text. Comparison of actual performance to this baseline shows how far off our original plan we have come (if any). It will also be very useful for historical estimating purposes. Even if the plan is subsequently changed, comparison to this plan will help us estimate better in future projects.

· The current baseline, that is, the most recently approved baseline if there were project, scope, or other changes. If approved project changes have been made since the beginning of the project, we need to compare actual to this baseline to determine whether or not we're on the currently approved plan or whether we've slipped. (We still want to know how far off of the original plan we are, so we still need the original baseline, also.)

· And the actual schedule, that is, what actually has happened to date, regardless of what was planned. This is not a baseline, but objective truth; this is what happened.

Egeland, B. (September 9, 2009). "What is Project Control?" Retrieved from PMTips Web site: http://pmtips.net/project-control/

Kendrick, T. (2006). Results without Authority: Controlling a Project when the Team Doesn't Report to You. New York: American Management Association.

(TBD. More to follow)

Figure 4 Closure: Closing book

(For what it's worth, the book closing was animated and actually closes, but I don't think that comes across successfully in LEO)

When it's all done, there is project closure. However, it's more than just project closure, since every phase really has an element of closure to it when it is completed. Procurement, especially, has an aspect of closure in closing the contracts out when they are completed.

One of the most important parts of project (and phase) closure is to assess what's been done -- an after-action, lessons learned assessment. This is often slid over for the same reasons that technical documentation is often slid over: We're both anxious to get on to other things and are under pressure to do so. Besides, techies don't often like to document; it's not their thing. In the case of lessons learned, we don't like to look at what might have gone wrong and don't like to cast blame -- or more to the point, accept it. However, it is crucial to learn from our mistakes so that we don't repeat them in the future. That's how we improve and grow.

Note that an after-action lessons learned session need not -- and should not -- be an unpleasant, blame-casting, "murder board" (as some call it). The point is not to find scapegoats, but to learn and to improve processes for the future.

Finally, once the project closes, the system operation and maintenance stage (when users actually use the operational production system) begins. This is not actually part of the project since the project is now completed. Also, as we're all pretty much aware, system operation and the "maintenance tail" is much longer than the project itself.

"A project is complete when it starts working for you, rather than you working for it."

-- Scott Allen (Technology Entrepreneur)

"Done is better than perfect."

-- Scott Allen (Technology Entrepreneur)

"A perfect method for adding drama to life is to wait until the deadline looms large."

-- Anonymous

"I may not have gone where I intended to go, but I think I have ended up where I needed to be."

-- Douglas Adams

"He who does not remember the past is doomed to repeat it."

-- George Santayana on project post-mortems?

"Begin at the beginning," the king said very gravely, "and go on until you come to the end. Then stop."

-- Lewis Carroll, Through the Looking Glass, 1871

Of Abraham Lincoln's many anecdotes, this one was reportedly his favorite -- and a test of logic, to boot:

"How many legs does a dog have if you call the tail a leg?"

"Well, five, I suppose, if you call a tail a leg."

"No. Four. Calling a tail a leg doesn't make it a leg."

Just because someone chooses to call a failure a success, doesn't make a failure a success. It may have been a success from a design point of view or a publicity point of view or any other point of view, but that doesn't mean that the project was successfully managed -- so that doesn't make it a success from a PM point of view. It doesn't enhance the resume of the PM for such a project to say that it was hugely over budget and behind schedule, but "other than that," everybody liked its design. That wouldn't be a good recommendation for future PM jobs.

So How can we know whether a project actually is a success? I'll leave the specifics to a Discussion question. However, I'd like to emphasize that the question should be asked up front -- during the project initiation and planning -- What will make the project successful? The answer to that -- the project success criteria -- should be addressed in the project charter and agreed upon by all parties (customer, executive sponsor, PM, etc). Then at the end of the project during project closing, those success criteria can be assessed to determine whether or not the project actually was a success. If it was done that way, then at the end there should be minimal, if any, disagreement about whether the project was a success.

Project post-mortem evaluations (lessons learned, after action reports) are constructive evaluations to find out what went wrong and make recommendations for process changes so that the next project doesn't have the same kinds of problems as the current project did. At least, that's what they're intended to be. Unfortunately, they sometimes degenerate into finger-pointing and blame sessions. That's not the intent. It doesn't matter who is at "fault". Instead, what matters is that we identify our mistakes (we're human: like it or not, there always are some -- always) and that we improve our processes so that we don't repeat the same mistakes next time. But sometimes it's tough to get that through to people.

When you run your project post-mortem evaluations (certainly in your class ITP teams, but especially in your real world projects), please make sure to keep your focus on the right thing. That's firmly on identifying problems and improving processes. It is not on casting blame!