4squareviews

1. Scope Creep and the St. Francis Dam disaster of 1928

Scope creep is changing the original scope during the course of the project without considering the impact this change has on other constraints such as time, cost, or even customer approval.

This this is the bane of the project manager, and it is hard to underestimate the importance of protecting against it. At a recent meeting of the Orange County Project Masters Club, a Toastmasters club for Project Managers, one of our members, Van Wray, gave a talk on the St. Francis Dam disaster of 1928.

NOTE: I must commend Mr. Wray on his excellent presentation; he won the award for the best speech of the evening, and he definitely deserved it. (I can say that with particular conviction because he won against the speech I gave that same evening!)

The St. Francis Dam was located about 40 miles NW of Los Angeles, and was constructed in 1924 and 1926 under the supervision of the legendary chief engineer William Mulholland.   The dam collapsed just before midnight on March 12, 1928, killing 600 people in the ensuing flood. On the morning before the flood, the dam keeper alerted Mulholland to a leak, which seemed particularly ominous since it was a leak of dirty water, indicating that erosion may have been occurring at the foundation. Mulholland deemed the dam safe, but his judgment was proved wrong less than 24 hours later.

A commission formed at the time to analyze the cause of the disaster laid the fault on incomplete knowledge of the geology of the rock formations around the dam.   However, a more recent study published in 2004 in the journal California History by historians Norris Hundley Jr. (Professor Emeritus, UCLA) and Donald C. Jackson (Professor Lafayette College) showed that the more direct root cause of the disaster was that there were two changes in the height of the dam that were done without having an engineering analysis done of the effect of those changes on the rest of the dam’s design. In other words, as we would put it today in project management terms, 600 people died because of scope creep. It was one of the largest civil engineering disasters of the 20^th century, and was responsible for the second largest loss of life in California in the 20^th century, second only to the great San Francisco earthquake of 1906.

2. Scope Management

The PMBOK® Guide lists 5 processes for the management of project scope.

What I plan to do is go through these five processes in some detail to discuss each of the processes and to discern some principles that project managers can take away to be able to manage the scope on a project.

The next post will go through the first process, that of Collecting Requirements. It’s not just collecting them and collating them, but resolving conflicting requirements that it is the key to avoiding scope changes later on in the project.

Filed under: Uncategorized | Leave a comment »

The following is the text of the speech I did tonight at our Toastmasters Club.  I was doing the speech project from the Entertaining Speaker Manual called A Dramatic Talk.   In it I talk about the experiences I had living in New York one day exactly 11 years ago …

Time to Remember

(Stepping out to audience, and singing these lyrics of “Time to Remember” from The Fantastiks )

♫

Try to remember the kind of September when you were a tender and callow fellow

Try to remember and if you remember then follow … follow follow follow

♫

(beckoning to audience in “follow me” gesture, sitting down in chair)

(Picks up imaginary telephone) Hello, this is Mitsubishi Motors, can I help you? (Suddenly smiling and relaxing) Oh, Dad! Why are you calling me here in New York so early? It must be only 7:00 AM there in Chicago—oh, slow down, slow down. (Sitting forward, with worried look.) Oh you were watching CNN when you saw a report of … what? A plane hit the World Trade Center? John’s company is in one of those buildings, you know. Did you call him? You got a busy signal. Okay, I’ll call him and then call you back. Oh, speaking of planes, did Mom get on her plane yet? Well, call her while I’m calling John.

(reaches for telephone) First, I’d better tell Ken about this—he’s the only with a TV in his room. (Getting up, knocks on imaginary door in center stage.) Sorry, Ken—this is an emergency. My Dad called from Chicago and said he saw on television that a plane had hit the World Trade Center. You’d better turn the TV on to find out what’s going on. (Now looking to left at imaginary TV.)

Watches TV—I have no idea what kind of plane it was, but it must be one hell of an accident. (Puzzled look, and then shakes head in noncomprehension.) What? A second explosion? Where did that come from? A second plane (“oh my God” look forming on face)? You know what this means, don’t you. I’ve get to tell our boss.

(stepping back, folding hands in calm gesture and speaking directly to the audience)

At this point, we knew it was a terrorist attack, not an accident. I tried calling my brother John, but there was no answer; all communication was now cut off. It turns out his company, Marsh & McLellan, was in the center of where the plane hit in the North Tower. I knew he was safe because he didn’t work in that building, but rather in a building in Midtown Manhattan near where I worked. It was my mother I was worried about, because as far as I knew, she was getting ready to board a flight heading from the East Coast to Chicago.

(Moving forward and talking in center stage at same colleague’s “door” as before.)

I heard the secretary next door started a rumor that they “got the Sears Tower in Chicago” (imitating New York accent). Did they attack it or are they just evacuating it?  What is it, Ken? What’s happening to the South Tower? (looking at TV, staring in horror, as hands slowly cover face)

For months after seeing the South Tower fall in September 11, I had a recurring nightmare. I’m in an office building, and there’s a rumbling like an earthquake. I look outside the window and the high-rise buildings next to us inexplicably start shooting upward. And then, I realize that they are not shooting up in the air—it is our building that is falling to the ground, and I have only a few seconds to live … and then I wake up in a cold sweat.

I finally went to a hypnotherapist and he found under hypnosis that during that time when I saw the building fall, I empathized with those poor people who were about to die to the point that I identified with them. That’s why in my imagination I joined them in their final moments.

Yes, Hase-san. Major Guiliani as just given the evacuation has just been ordered.  One problem: there’s no public transport going in or out of Manhattan. I guess we’ll have to walk to the bridge, cross it and take transport on the other side. Hai, gambarimasho. Yes, let’s all persevere.

On the way back home, as I crossed the bridge from Manhattan to Queens, I saw the two gaping wounds in the Manhattan skyline pouring out smoke. I had the same feeling many had that day that we had just experienced the Pearl Harbor of our generation.

Oh, I’m so thirsty, thank Heaven for 7-11. (Tries door, face showing surprise) How could a 7-11 be closed? Wait a minute–there’s a sign … “closed due to terrorist attack”. Oh, for goodness sake. Why, did they think they were next? That’s what I call delusions of grandeur.

I can just see it now, Osama bin Laden is in a cave somewhere saying, “well, did you get the World Trade Center?” “Yes, we did!” “What about the Pentagon?” “Yes, we did!” “What about the 7-11 in the mini-mall in Queens?” “Uh, no, we didn’t!” “Son of an infidel! You’d better get it next time!” (Laughs at ridiculous image.)

I realized just then that I had laughed for the first time since all of this started. Of course I wasn’t laughing at the terrorist attack, I was laughing at fear. It was suddenly as if a fog lifted, and I realized, if I can laugh at fear, I can survive and move forward. I walked home the rest of the way.

(Hands in prayer position) Hey, I know you’re busy today, but you’re the only one who hasn’t given me a busy signal all day. Please make sure my brother and mother are okay, that’s all I ask. (phone rings) Dad! (points thumb up to ceiling in “OK”gesture). Oh, I’m so glad to hear your voice. I just got in. Is Mom okay? Oh, her plane got grounded. Yeah, she and thousands of other people. Oh, well, at least she’s okay. And John? I’m sure he sounded shaken, considering … Poor guy! Well, Dad, at least all in the people in your family are still alive. I really appreciate you calling. I love you, Dad! (looking upward and mouthing the words) Thank you.

(getting up and singing final verses from “Time to Remember”

♫

Deep in December it’s nice to remember without the hurt the heart is hollow

Deep in December it’s nice to remember the fire of September that made us mellow

Deep in December our hearts will remember and follow …

♫

Filed under: Uncategorized | Leave a comment »

This is a text of a speech I will give today at the Orange County Project Masters’ Toastmaster meeting.

1. Challenge Disaster

On January 28, 1986, the space shuttle Challenger broke up 73 seconds after launch, causing the death of 7 crewmen aboard. The Rogers Commission was established to find out the cause of the disaster.  The technical reason for the disaster was the faulty design of the O-rings on the solid rocket booster. But one of the members of the commission, Richard Feynman, the legendary theoretical physicist, dug deeper to find the root cause of the problem.

He found that NASA management lacked understanding of some scientific and engineering principles, including the project management principle of “the iron triangle of constraints.”

2. Iron Law of Constraints

Dr. Martin Barnes first described the iron triangle of constraints as far back as 1969 in terms of time, cost and output (what we today refer to scope).  These three constraints are strongly connected to each other, hence the name “the iron triangle.” To understand how this principle works, think of a water balloon in the shape of a triangle. One point of the triangle is the project’s time, the second point is the project’s cost, and the third point is the project’s scope, which can include such elements as level of quality on the project.

What happens if you squeeze one end of that water balloon? This creates increasing pressure on the other two ends. In a similar way if you constraint one of the three variables of time, cost, and scope, it will put pressure on the other two variables is why engineers have a popular saying “faster, cheaper, better”—pick two. This acknowledges that if you constrain one variable, one of the other two variables has to give.

What you cannot do is constrain all three variables at the same time. What happens if you squeeze a triangle water balloon on all three sides at the same time? A broken water balloon, or in terms of our analogy, a failed project.

3. Challenge Disaster—Root Cause Analysis

This is exactly what NASA’s management did. They were given a reduced, but then they turned around and expected the same level of scope of the project with the same schedule. They asked for one variable to be constrained, and said that it should not affect the other constraints. That is impossible, and their decision had with fatal consequences.

4. Project Constraints—definition complete, but not coherent

Given this extremely important principle of project management, I was very dismayed to find that when a PMP exam prep course was put on this summer by the OC chapter of PMI, many people found it hard to understand. I wanted to find out why. I looked at the PMBOK® guide’s explanation of “constraints”, and looked at some PMP exam guides like the one put out by Rita Mulcahy. I found my answer there: gone is the simple iron triangle. Their definition of “project constraints” listed six or sometimes seven constraints. People say they can’t remember all of the project constraints, and they are the relationship between them is not clear. In trying to make the list of constraints more complete, they lost the consistency or coherency of the definition, because the simple connection between constraints which is at the heart of the principle was now obscured.

5. The Incompleteness Theorem

What they unwittingly ran into was another conflict of constraints, but this one due to the structure of logic itself. A man named Kurt Gödel in Germany in the 1930s discovered the Incompleteness Theorem which today bears his name, and this discovery shocked not only the scientific world, but the world of mathematics as well. What it says is that a mathematical or logical theory has two constraints, it can be complete, which means that it contains all the necessary elements, or it can be consistent or coherent, which means that it contains all the necessary connections between the elements, but it cannot be both 100% complete and consistent.

I’m not here to give the technical details of the proof, but I can a tantalizing glimpse of how it works.

Here’s a 3-by-3 matrix of dots. Can you draw a connection between all of the dots with a series of only 4 connected lines? If you try it, you will find that the only way to solve the problem is to go outside the framework of these dots. In order to make the connections between the elements and make it coherent, you have to admit the original framework of elements is not complete and go beyond it.

6. Project Constraints Definition: emphasis on completeness → lack of coherence

In any case, what does this Theorem have to with the theory of constraints in project management? The original iron triangle of constraints had three variables, and three connections between them (the three sides of a triangle). It was consistent; people understood it. One member of the study group was asked in an interview, “what are the basic constraints on a project?” Luckily, she had learned about project constraints in the “old school” way as the iron triangle, and said, “why that’s simple: time, cost and scope.” Others couldn’t answer that simple question. She got the job, by the way.

But at some point, the Project Management Institute felt that they wanted to make the list of constraints more complete, that is, they wanted to more and elements to the list. So they added quality, risks, resources, and even customer satisfaction. The problem now is the list is more complete, but the relations between them are now not so clear, the coherence is lost.

Now what if my friend from the study group had answer the question based on what she had studied in the PMBOK Guide. “Well, they are arranged in a seven-sided polygon and using the formula n(n-1)/2, there are 21 possible relationships between them.” That answer would have been met with non-comprehension at best.

7. Summary

So it’s important for PMI to understand that when you try to teach project management principles to aspiring project managers, if add more and more material to a theory or definition, it’s like barnacles that encrust the outside of a ship making it harder to go through the water. In reality, all of those additional constraints that PMBOK lists can all be understand to be aspects of the scope of the project. In other words, inside this complicated heptagon is the same simple, easy-to-understand triangle.

In summary, when teaching vital principles of project management to people, the best method may be summed up in the acronym KISS, the polite version of which can be read as keep it short and simple. Make your explanation COHERENT so that people can FIRST understand the principle 100%, and then and only then worry about it being 100% COMPLETE.

Filed under: Uncategorized | 1 Comment »

The purposes of closing a project are to:

a) get formal acceptance of the product, service, or result that is produced by the project,

b) get formal closure of the project activities, and

c) get the final update of documents for inclusion in the organization’s archive of records.

These can be understood in general to be covering the organization’s legal, financial, and administrative responsibilities towards the project, respectively. I am taking the detailed description of the closure activities as found in the Rita Mulcahy PMP exam guide and going into more detail about the processes that are involved. Our study group has used the Rita Mulcahy PMP exam guide and I heartily recommend it for those who want to get a fuller understanding of the interplay of the various project management processes described in the PMBOK® Guide.

Let’s look into each of these three areas and see what processes are involved:

1. Acceptance of the product, service, or result of the project

a) Confirm product conforms to project requirements

This is a function of quality control, and is the final iteration of the process 8.3 Perform Quality Control. Once the final deliverable is internally verified, then it goes to the next step.

b) Closure of procurement

If components of the product have been received and are functioning, then the procurement of those components from the contractor or supplier needs to be closed through the process 12.4 Close Procurements.

c) Formal acceptance of the product

This is the final iteration of the process 5.4 Verify Scope, where the sponsor (if it is an internal project) or customer (if it is an external project) takes the final deliverable that has been internally verified in step a) above, and gives a formal acceptance of it. If it is not accepted, then the organization must remedy this situation and the project cannot yet be closed.

2. Formal closure of the project activities

a) Complete financial closure

This is the point where you say you need no more of the company’s resources. Why is this important? For you, the project may be over. If you finished the project under budget, that may look good on your performance review, but remember that the company cannot utilize these unused resources until you do the financial closure which says those resources can now be reassigned to other projects. So this step is particular important for program managers and/or portfolio managers who must fund the other projects which they are responsible for, and may now be able to get additional resources that were not used on your project.

b) Complete final performance reporting

This is an extension of the process 10.5 Report Performance, where the stakeholders are involved about the results of the project and its closure. This can then prompt their feedback regarding the project, which goes into the next process. The most important stakeholder to hear back from would be, of course, the sponsor and/or customer.

3. Final update, archiving of project documents

a) If there were issues that came up during the project, or risks that materialized, the issue logs or risk registers would have been updated, as well as lists of change requests that were considered by the change review board, etc. All of these records are reviewed, and are included in the “lessons learned” knowledge base of the organization, in addition to the feedback about the project from the stakeholders mentioned in paragraph 2.b) above.

b) Archive records

These records are then kept as part of what the PMBOK® guide refers to as the Organizational Process Assets for use on future projects.

You can NOW say the project is done after this step!

All of the administrative parts of the closure process listed in section 3 above may not seem exciting, but they are an absolute gold mine of information for the next project manager who comes along and is assigned a project similar to yours. Or just imagine being assigned a project where there is NO “lessons learned’ knowledge base, and realize how much time you will have to spend reinventing the wheel, so to speak. This is why it is so important.

4. Summary

Here’s a summary of the three parts of the closure process

This covers the final 4.6 Close Project of Phase process in the Integration Knowledge Area.

I will now turn in the next series of posts to issues relating to the Scope Knowledge Area.

Filed under: Uncategorized | Leave a comment »

In the last post, I dealt with the high-level review of the change request review process which can be summed up in the acronym ECHO (see previous post). In this post, I am summarizing the detailed processes that surround the change requests that are performed as part of the process 4.5 Perform Integrated Change Control.

I am indebted to the Rita Mulcahy’s PMP Exam Prep book for its clear statement of the process for change requests. What I have done is taken her high-level overview and made a summary in the table below. For those who want to get more detail, I strongly recommend that you buy her review book and use it to help prepare for the PMP exam.

What I’m doing is taking her detailed list on page 125 of her book and illustrating it with diagrams that show how the high-level overview in the last post is related to this more detailed description.

1. Change Request Workflow (overview)

The overall pattern is clear: Change Requests are made, and then approved or rejected as part of Integrated Change Control, and then for those that change requests that are approved, they are then implemented.

Fig. 1. Overall change management workflow

Here’s a little more detail about these steps:

a. Change Requests

Change requests are generated, either as part of the process 4.3 Direct and Manage Project Execution in the Executing Process Group, or as part of the process 4.4 Monitor and Control Project Work. However, the need for changes to the project may be identified during other processes in the Executing Process Group, such as 8.2 Perform Quality Assurance, 9.4 Manage Project Team, or 10.4 Manage Shareholder Expectations, or ANY of the other processes in the Monitoring & Controlling Process Group. The changes may be identified by the project manager after he or she measures the project against the performance baseline, or it may be identified by other stakeholders such as project team members, sponsors, or customers.

 b. Integrated Change Control

Once the change requests are created, they are inputs to the process 4.5 Perform Integrated Change Control. The approval can be done by the project manager (depending on his/her authority level and the magnitude of the change), the sponsor, or a change review board.

 c. Implement Changes

If changes are approved as a result of the process 4.5 Perform Integrated Change Control, then outputs of that process are updates to the project management plan and project documents. The changes themselves are implemented back in the Executing Process Group under 4.3 Direct and Manage Project Execution.

2. Change Requests Workflow (Detailed)

 Let’s take the first part of the workflow listed in Fig. 1 above involving the creation of Change Requests and expand it:

Fig. 2 Change Requests Workflow

a. Prevent changes

This is not an obvious step, but preventing changes is the most effective thing you can do on a project, even more than managing them when they occur. How do you do this? One of the main reasons for unexpected changes on the project is that the risk identification was not done thoroughly enough. So you try through risk management to do what you can to prevent the need for changes.

In fact, if a change occurs because of a previously identified risk event, one that has a risk reserve assigned to it, then that change should be handled as part of risk management, and not the change management process.

b. Identify changes

Okay, if you can’t prevent changes, the second most effective thing you can do on a project is identify them as early as possible. Why? The impact of a change increases as the project goes forward.

The need for a change may be identified by any stakeholder and during many different project management processes both in the Executing and Monitoring & Controlling Process Project (see paragraph 1.a above for details).

c. Evaluate the impact of the change

This is the “E” of the ECHO acronym mentioned in the last post. If the change affects one constraint, how will this affect the other constraints?

d. Create a change request

This change request is then sent on as an input to the process 4.4 Perform Integrated Change Control.

3. Implement Change Control Workflow

Let’s take the second part of the workflow above in Fig. 1 involving Implement Change Control and expand it:

Fig. 3 Implement Change Control Workflow

a. Assess change

In a way, this is an extension of the E for Evaluate already done immediately upon identifying the change. The evaluate change process before meant investigating what the effect of this change in one constraint (scope, time, cost) will have on the other constraints. This is necessary because if the change will cost a certain amount of money to implement, this will effect who gets to approve the change in step 3.

The assess change done in this step means seeing if the change involves changes to the following:

i. Changes to policies or procedures

Minor changes that would not affect the PM plan, but only change certain policies or procedures, would only involve implementing in the Executing Process Group.

ii. Changes to performance measurement baseline, PM plan

Moderate changes would involve going back into the planning process to re-calibrate the performance measurement baseline (scope, time, or cost baselin) or to update the project management plan. These would be implemented by updates to the PM plan in the Planning Process Group before the change themselves are implemented as part of the Executing Process Group.

iii. Changes to project charter

Major changes that would change the product scope to the point that it would affect those high-level definitions in the project charter would be implemented by getting the updates to the project charter approved in the Initiating Process Group. It is possible that changes of this magnitude may not be approved, at which point the project comes to a screeching halt! If and only if they are approved, they then go on to change the PM plan in the Planning Process Group and then to implementation in the Executing Process Group.

Fig. 3a Levels of Magnitude of Project Changes

b. Create (options)

This is the “C” of the ECHO acronym from the last post. This is where options are considered on how to compress the schedule if necessary, how to perform the work involved in the change, or how to minimize the impact of the change. These options are presented along with the changes themselves to the change approval authority in the next step.

c. Have it Approved (by change approval authority)

In case of a minor change, the project manager may have approval authority. Otherwise, it will have to go to a sponsor or to a change control board. This is the “H” of the ECHO acronym from the last post. If the result of the project is to create a product for that customer, then you must okay it with the customer. This is the “O” of the ECHO acronym from the last post. However, in this case the change control board will already have the customer on it as a member, so this is also part of the same approval process.

d. Update Status

The status of the change is noted. If it is rejected, the reason is listed. Once a change is approved, it can then go and be implemented, noting that the implementation may be more complicated if the change is of greater magnitude (see diagram 3a above).

4. Implement Changes

Let’s take the third part of the workflow above in Fig. 1 involving Implement Changes and expand it:

Fig. 4 Implement Changes Workflow

a. Adjust PM Plan, Baselines

If the change is moderate, that is, it changes the performance baselines or other aspects of the PM plan, then that plan needs to be adjusted before implementation can begin.

b. Update Project Documents

If the change to the scope is moderate, then the project scope statement, the scope baseline (project scope statement + WBS + WBS dictionary), and the requirements traceability matrix will have to be updated in addition the PM plan as part of the Planning Process. If the change to the scope is major, then the project charter will have to be updated, which means it will have to be re-approved as part of the Initiating Process Group. These different types of updates are covered in figure 3a above.

 This changing of the project documentation can be considered part of configuration management. Once the changes to the project are done through the change management process, the configuration process takes over and manages changes to the deliverables and the project documentation.

 c. Communicate Changes

All stakeholders affected by the change need to be informed of its configuration (this is project update 5.3.1, for example). This is part of configuration management, although it is part of communication management as well.

 d. Implement Changes

After the changes are approved, documented, and communicated, then it is time to implement the changes in the Executing Process Group, specifically process 4.3 Direct and Manage Project Execution.

 This concludes the expansion of each of the processes involved in creating, approving, and implementing changes requests.

 The next post covers the last process in the Implementation Knowledge Area processs 4.6 Close Project of Phase.

Filed under: Uncategorized | Leave a comment »

In this post, I am summarizing the high-level overview of the change request process that comprises the process 4.5 Perform Integrated Change Control. Because up to 10% of the PMP Exam can revolve around this topic, it is vitally important to understand it to pass the exam. But beyond the pragmatic goal of passing the exam, managing change requests is at the heart and soul of good project management practice, and so special attention needs to be paid to this area in any case.

I am indebted to the Rita Mulcahy’s PMP Exam Prep book for its clear statement of the process for change requests. What I have done is taken her high-level overview and added my own acronym which I have shared with our study group because the content needs to be memorized, and more importantly, understood.

A. ECHO—acronym for overall change request process

You want a change on my project? Tell it to the ECHO chamber! In other words, follow the four general processes outlined below.

• Evaluate the Impact
  
• Create Options
  
• Have it Approved
  
• Okay it with Customer (if needed)
  

This is an acronym I created to keep these four general processes straight in terms of order. What do they mean? I’ll discuss each of them in turn.

B. ECHO—meaning of individual terms

Remember there are three basic types of changes: corrective action (dealing with problems that are occurring now), preventive action (dealing with problems that may occur in the future), and process improvement to correct defects (dealing with problems that have already occurred).

C. ECHO—Summary of change request process

1. EVALUATE THE IMPACT

The iron law of constraints means that each constraint is effected by the others. So if there is a scope change, you must evaluate what impact it will have on the other major constraints of time and cost. Remember that “scope” in the above diagram can include, in the larger definition of project constraints (see p. 6 of PMBOK® Guide) such constraints as quality, resources, risks, and even customer expectations.

2. CREATE OPTIONS

In response to the change request, there are different types of changes that may require different options. A preventive action may be suggested as a change with the idea preventing a risk from occurring or mitigating the impact of the risk if it does occur.

If a variance is detected between the actual performance and the baseline, then crashing or fast tracking may be an option which will allow the project to “get back on track,” so to speak. However, if analysis of the variance shows that it was the original estimates that were unrealistic, then it may be necessary to change the performance baseline through re-estimating.

If defects are discovered as part of quality control, then it may be necessary to repair those defects, but then through quality assurance it may be necessary to get to the root cause of the defects and create improvements to the manufacturing process which prevent those defects from reoccurring.

These are just some examples of the types of options that you can create to respond to the change request.

C. HAVE IT APPROVED

Another way I have to remember this step is to think of “H” in ECHO standing for “Higher Authority”, either the a) sponsor or the b) change control board. You send the change request, together with the a) analysis of its impacts on the project and b) your suggested options to the sponsor or, in a larger company with a more formal system, to the change control board.

The approval/rejection decision is then made by that authority.

D. OKAY WITH CUSTOMER

Again, for projects which are external, i.e., where the result of the project is to be used or delivered to a customer, they must approve of the change request because they must in effect approve the consequences of the change request as they effect the project as a whole.

This is the change request process at a high level. The next posts will discuss the process in a more detailed fashion.

Again, my thanks to Rita Mulcahy’s PMP Exam Prep book for laying out the change request in such a clear way. My adding an acronym to this high-level process is just my way of making it more easily memorizable by those trying to prepare for the exam.

Filed under: Uncategorized | Leave a comment »

This post is geared towards explaining why change requests originate from different processes, explaining what can be in change requests, and explaining where change requests go next in the project management processes.

A. Change requests

Before we consider what change requests are specifically, let’s get a better idea of what they are in general on a project.

One way of doing this is by analogy. Let’s say your goal is to take a road trip from city A to city B. You are trying to do it within a certain time period, let’s say, 4 hours. That will be analogous to doing a project. You plan to go a certain distance every hour, so that you will get to your destination on time. You have decided to check the actual mileage every half hour with the planned mileage in order to figure out whether you are on schedule or not.

In this analogy to a project, the process 4.3 Direct and Manage Project Work is equivalent to the process of driving. This is in the Executing Process Group. The process 4.4 Monitor and Control Project Work, in the Monitoring & Controlling Process Group, is represented in this analogy by your checking your actual mileage every half an hour or so.

At that point, if you actual mileage differs from the planned mileage for that portion of the trip, you may make a change in your speed based on that information. This would be an analogous to a change request on a project based on your measuring against the performance baseline

However, even if you haven’t reached your half-hour “checkpoint”, you may want to change your speed, or your route entirely, depending on current conditions in the road. So change requests can come either during the Executing Process Group, or during the Monitoring and Controlling Process Group.

B. Change requests

There are many types of changes you can make on a project, and these have analogies in the road trip analogy I’ve been using.

If you’re behind schedule on your trip, and you accelerate your speed in order to catch up, that’s an example of corrective action. This is, in formal PMBOK® Guide terms, “action which is designed to bring expected future performance of the project work in line with the project management plan.”

Let’s say your GPS system warns you of a impending traffic jam because of an accident. You decide to take the surface street rather than the freeway to bypass this traffic bottleneck. This is an example of a preventive action. This is, in formal PMBOK® Guide terms, “action that can reduce the probability of negative consequences associated with project risks.”

If you find that you accidentally took a wrong turn, then you will have to change your route immediately in order to get back on the right road. This is analogous to a defect repair, an action that repairs the defect or a problem with the deliverable.

In reality, these three categories of changes are designed to handle present (corrective action), future (preventive action), and past (defect repair) mistakes on the project.

C. Where do the change requests go?

You can see from this diagram that, whichever process originates the changes requests, they get transferred over to the process 4.5 Perform Integrated Change Control, which is the process of managing changes including approving or rejecting them. This is an integration process in the Monitoring & Controlling Process Group. For only those approved changes, the implementation of those changes is done back in the Executing Process Project under the process 4.3 Direct and Manage Project Execution.

I hope this clarifies the general flow of how changes are made to a project in in terms of the project management processes.

Filed under: Uncategorized | Leave a comment »

This latest series of posts is covering the Integration Knowledge Area, which as you can guess from its title, works on processes that integrate all of the processes from all of the other knowledge areas.

Since I’ve covered the first Integration process, 4.1 Develop Project Charter, in the last few posts, I am now going to cover topics related to the second Integration process, 4.2 Develop Project Management Plan.

You don’t get too many brownie points for answering the question “What’s the output of the Develop Project Management Plan?” (If you answer anything other than “the Project Management Plan,” you need to do a lot more studying.) A most interesting question is, “what are the inputs of the Project Management Plan?” I know I’ve already covered inputs and outputs to all the processes in a separate series of posts, but the Project Management Plan is a guide to the project plan in the same way that the PMBOK® Guide is a guide to the field of knowledge related to project management.  So I thought it would be worthwhile to do a post outlining the inputs, and going into some detail regarding some of these inputs.

A. Inputs to Project Management Plan–PMBOK® Guide Explanation

Formally, the PMBOK® Guide on p. 78 of the Fourth Edition lists the following as the inputs for the Project Management Plan:

I found this a not very helpful list, for the following reasons:

a) The project charter is an output of the process 4.1 Develop Project Charter. It is an input to the process 5.2 Define Scope which has as its output the Project Scope Statement. In reality, it is the Project Scope Statement, and not the Project Charter, that is a more direct input into the Project Management Plan.

b) The input listed as “outputs from planning processes” is a little vague, because there are eight processes, one of each from the eight knowledge areas other than Integration, but there are four additional processes that are also required.

c) There is an additional set of inputs NOT listed above, and that is the performance baseline consisting of the scope, cost, and schedule baseline.

B. Inputs to Project Management—More Complete Explanation

However, on the very next page there is a diagram of the various inputs and outputs of the Project Management Plan and it is more accurate in terms of the inputs. This post is used to list these inputs in a more complete way consistent with that diagram.

C. Additional management plans—additional explanation

It is fairly obvious that the eight management plans listed under item 3 above come from the various knowledge areas listed. However, I feel a little more detail should be in order for those 4 additional management plans listed under item 4.

These are the elements of the Project Management Plan. In my opinion, it is the most integrative of ALL the 42 processes and that is why it is important to focus on all the inputs that go into it.

Filed under: Uncategorized | Leave a comment »

This recent series of posts has to do with the Integration Management Knowledge Area. The purpose of this post is to discuss in more detail the process of presenting the business case for a project and how project selection criteria are used. I am doing this because a) these criteria are not in the PMBOK® Guide, but may be referred to in questions on the PMP certification exam, and b) the importance of these criteria on the project during the lifetime of the project cannot be understated.

A. The Business Case for a Project

I have dealt with the Project Statement of Work (SOW) in a previous post. It is an input to the process 4.1 Develop Project Charter, and it contains the following three elements.

a) Business need for the project—is the project being launched in response to a perceived market demand, as a response to new government regulations, or to take advantage of the availability of new materials and/or technologies? Why is the project being launched?

b) Product scope description—characteristics of the product or service being created. What will the project create?

c) Strategic plan—documentation of the organization’s strategic goals. How will the organization profit from doing the project?

The business case is another input into the process 4.1 Develop Product Charter. It is an analysis that that ties together the three elements of the Project Statement of Work together. It takes the product scope description and shows how the product fits a business need and, with a cost-benefit analysis, shows how the product fits into the organization’s strategic plan.

The business need is simply an identification of which of the business needs mentioned above explains why the project is being launched in the first place. To do the cost-benefit analysis, product selection criteria are sometimes used. From the PMP exam prep books I have read, you will not have to calculate any of these numbers dealt with in the criteria, but you have to understand their significance, both in terms of the initial selection of the project and their subsequent significance for the rest of the project.

B. Product Selection Criteria—Benefit measurement methods (comparative approach)

In general there are two categories of project selection: 1) Benefit measurement methods (comparative approach) and 2) Constrained optimization methods (mathematical approach).

Here is a table explaining the various product selection criteria under the category Benefit measurement methods

and how they are used to select a project.

C. Product Selection Criteria—Other terms to know

Here are some additional terms dealing with product selection criteria:

D. Product Selection Criteria—Constrained optimization methods (mathematical approach)

Now there is another category of project selection criteria of constrained optimization methods, such as linear, integer, dynamic, and multi-objective programming. Note the word they have in common, which is “programming”, which means they are usually done on a computer. For this reason, they are too complicated to ask questions about so you will probably not get questions on the exam involving them. Just recognize they are from a different category of methods (the mathematical approach) than the questions you might get asked about on the exam, those from the comparative approach. Even these do not require calculation on the exam, but they will ask you questions that give you one of the four methods, state the value of two or three projects, and ask you to compare these and indicate which one you would select as a project. Examples of all of these are included in the table in section B.

E. Why do we have to know this stuff?

The project selection criteria, as part of the business case, are important for the Initiating Process in getting the project green-lighted by management. But they are also important during the rest of the project because they give you a vital clue as to which constraints have priority. For example, if the payback period method was used to select the project, and the supplier tells you that there will be a delay in supplying you a critical component such that it delays the project, then you need to have this selection criterion in the back of your head. If the entire basis for the project being profitable was that it would be done in 6 months, and you now tell the sponsor it will take 12 months, it could mean that the profit is no longer profitable, or no longer as profitable as another project that was initially rejected in favor of yours.

If the project selection criterion used was a cost benefit analysis, then the costs may be the more important constraint to pay attention to. If the benefit cost ratio is 1.5, and you now must increase the cost of the project to the point that the ratio is now only 1.2, then the project will no longer be as profitable in the eyes of the organization. It could be that your project was selected over a project that had a benefit cost ratio of 1.3, and now it is more profitable than yours. So this is why it is important to understand the business case and the project selection criteria behind the selection of your project in the initiating process, because it will affect the project for its entire duration.

Filed under: Uncategorized | Leave a comment »

1. Introduction

Yesterday I wrote a post making a distinction between the Project Charter and the Project Scope Statement. In reviewing my notes from our study group I realized that there is another document which people had trouble distinguishing from the Project Charter, and that’s the Project Statement of Work. Like the confusion with the Project Scope Statement, this confusion also exists because there are some common elements between the two documents, as well as differences with regards to their contents and their purpose.

The purpose of this post is to make the distinction between the Project Statement of Work and the Project Charter clearer. I will do this by answering the questions: What is it? How does it fit in the flow of PM processes? Who creates it? What’s in it? How does it compare to the Project Charter? How is it related to procurements?

2. Project Statement of Work (SOW)—What is it?

The best way I can describe the Project Statement of Work is as the “seed” of the project. It is watered during the Initiating Process into the Project Charter which causes it to germinate and become a seedling. The seedling is planted in the ground during the Planning process of creating the Project Scope Statement. It then turns into a plant during the Executing Process (where it is given sunlight and water, analogous to project resources) and Monitoring & Controlling Process (where it is checked periodically to see if there are any adverse conditions such as pests or diseases), and is finally harvested at the time of the Closing Process.

3. Project Statement of Work (SOW)—How does it fit into the flow of PM Processes?

The SOW is the seed or kernel of the idea for the project which is then developed at a high level for the purpose of approval of the project during the Initiating Process Group as process 4.1, Develop Project Charter. As seen in the previous post, this Project Charter, if approved, is developed at a higher level of detail in the Planning Process Group as process 5.2, Define Scope. So here’s the flow of how the documents are connected:

3. Project Statement of Work (SOW)—Who creates it?

This is going to depend on the end result of the project is going to be a product, service, or result that is used internally within the company, or is to be delivered to an external customer.

If the sponsoring organization is the one that is going to use the end result, then the sponsor is the one that originates the SOW. If a customer is the one that is going to use the end result, then the customer is the one that originates the SOW. The SOW may be part of a bid document (request for proposal, request for information, request for bid) or as part of a contract.

4. Project Statement of Work (SOW)—What’s in it?

The PMBOK® Guide references 5 inputs to the 4.1 Develop Project Charter process, two of which are the generic Enterprise Environmental Factors (EEF) and the Organizational Process Assets (OPA), the “company culture” and “company processes” that are inputs to many PM processes.

However, listing these three like this is somewhat misleading and obscures their interrelationships. Here are more detailed descriptions of these three inputs

a. SOW
The components of the Project SOW are as follows:

b. Business Case

How is the business need different from the business case? The business case takes the business need outlined in the SOW (element 1 in the chart above) and justifies how the result of the project (element 2 in the chart above) will satisfy that need AND align with the strategic goals of the organization (element 3 in the chart above). It is the analysis that ties together the 3 elements of the SOW like so:

c. Contract

As mentioned above, IF the product is to be made for a customer in an external organization, then the SOW may come EITHER in the form of a procurement document OR a contract. So, in reality the contract may contain the SOW and is not separate from it.

I hope this explanation clears up the distinction between these three inputs of the process 4.1 Develop Project Charter

5. Project Statement of Work: How does it Compare to the Project Charter?

Here are the elements of the Project Statement of Work (the “seed” idea of the project) compared to the elements of the Project Charter (used for approval of the project). Those elements which are similar are put in the same row. In this chart, the elements 1 and 3 from the above chart on the Project Statement of Work correspond to the first element of the Project Charter, and element 2 from the above chart corresponds to the second element of the Project Charter.

The Project Statement of Work is therefore the core of the first two elements of the Project Charter, indeed the most IMPORTANT elements of the Project Charter, and that is the relationship between the two. Again, that is why I refer to it as the “seed” of the project.

For the purpose of completeness, I am copying from my previous post a description of the elements of the Project Charter.

Project Charter

a. Project purpose or justification

In order for the project to go forward, it has to be for a specific business need and it must fit into the company’s strategic plan. This is why a program manager and/or portfolio manager would be involved in the decision to green light a project. The project has to fit into the company’s work that is external to the project.

b. Project objectives, product characteristics

This is a high-level description of the project, which will be progressively elaborated into a description of the scope of the project as part of the Project Scope Statement.

c. Project success criteria

If the purpose of the project is to produce a product, service, or result, then this is a description of what a successful project will be. This may be related to the Summary schedule, budget item below.

d. High-level requirements

The various stakeholders will have their requirements, assumptions, and risks identified.

e. Summary schedule, budget

This is a high-level estimate or ballpark figure used for preliminary approval of the project. These may be considered as the high-level constraints for the project which are elaborated later during the Define Scope process. Note that if the actual schedule and/or budget as a result of the Planning Process are wildly different from the this summary schedule/budget, it may require a revisiting of the Initiating Process to see if the project c can actually proceed or not.

f. Project manager

This is very important to have a project manager assigned at the Initiating Process and NOT later on during the Planning Process.

g. Project approval requirements and approval authority

Who is the person or persons within the organization who will green light the project and what criteria will they use for doing so?

6. Project Statement of Work—How is it related to Procurements?

Sorry to jump ahead from the Integration Knowledge Area to the Procurements Knowledge Area, but there is something called the Procurements Statement of Work. How is this different from the Project Statement of Work?

Well, the project statement of work is initiated by the a) sponsor or the b) customer, so that in case b), you are the supplier or the seller. If you are producing that product for the customer, and in order to produce it you need a subcontractor to do part of your work, then you become the buyer and some other company is the seller. The Procurements Statement of Work is the “seed” of the subproject, if you will, that produces that subcomponent produced by the seller for inclusion into your product, which you will in turn sell to the customer.

However, the Procurements Statement of Work is derived from the portion of the Product Scope during the process 12.1 Plan Procurements, and becomes the basis for the bidding process to obtain a seller.

However, from the component manufacturer’s standpoint, when they receive this Procurements Statement of Work, from THEIR standpoint, it is exactly like the Project Statement of Work that you received from YOUR customer: it is the basis for their proposal, which if accepted, then become the basis for a formal procurement contract between the component manufacturer and your organization. To them, it is a project; to you it is a subproject, or a project within a project.

I hope this post clears up the different between a Project SOW, a Project Charter, and a Procurements SOW.

The next post will cover the project selection criteria for a project, something which is not covered in the PMBOK® Guide, but which nevertheless can show up on the PMP exam.

Filed under: Uncategorized | 14 Comments »