Create Work Breakdown Structure

The Work Breakdown Structure (WBS) is one of the most important documents in all of project management. It is a deliverable-oriented breakdown of the tasks to be done for the execution of the project. The project team works from the WBS and uses it as a guiding document throughout the project. As the WBS is broken down, each lower level gives detail to the task it is breaking down. The inputs, which have been previously discussed, are the organizational process assets, project Scope Statement, project Scope Statement plan, and approved changes requests.

The breaking down of the WBS is called decomposition. The verb used to describe this process is "to decompose." The purpose of WBS decomposition is to make the tasks listed manageable. For instance, if a listed task takes eight weeks, you do not have enough control over the task to make it happen on time. You need to decompose the task into smaller units. Generally, the largest unit you can actually manage is considered 40 hours or five days. So any task that is longer than that in your WBS should be broken down to give you control of the sub-tasks as you go through the project.

Identifying major deliverables of the project is another factor that comes from decomposing the WBS. If you are running the project with each major life cycle shown in your WBS, each phase of the life cycle will have deliverables against which you can measure your success. Give yourself clear deliverables that are manageable, and you will be able to control your project.

Project Scope Management

Scope planning is "creating a project scope management plan that documents how the project scope will be defined, verified, controlled, and how the WBS will be created and defined". You begin doing the scope planning process by using the inputs that will give guidance to the project manager. The inputs to scope planning have been discussed elsewhere. They are enterprise environmental factors, organizational process assets, a project charter, preliminary Scope Statement, and the project management plan. All five of these are needed to begin doing scope planning.

The organizational process assets describe processes that are in place in the organization that will be useful in doing the scope planning. Any organizational policies and procedures that are already in place and pertain to scope planning and management are considered assets, as would be historical information about previous projects, according to the 3^rd edition of the Section. Historical information can be in the form of lessons learned, although historical information is available in many other formats, such as reports and requirement documentation from previous projects.

A word on the preliminary Scope Statement is necessary. The preliminary nature of the Scope Statement listed in this scope management process indicates that the preliminary Scope Statement is not the final Scope Statement to be used to manage the project. Be careful to understand that a Scope Statement is not final until it is locked under version control, and only then will it be the baseline for your project. This is an input in the scope planning, not the final Scope Statement.

The tools and techniques for scope planning include expert judgment and the various templates, forms, and standards that are useful in constructing a Scope Statement. The Scope Statement is your baseline and one of the most important documents you have on a project. The Scope Statement that is given to the project manager at the beginning of the project is the baseline of scope for the project. It should be put under change control, and any changes to the Scope Statement should require a new version number. Failure to control the Scope Statement carefully and rigorously will result in major problems as the project is executed.

The various templates, forms, and standards that are inputs into scope planning can come from a variety of places in a variety of forms. You should check with your organization to see which types they have for use.

Closing a Project

The inputs into the close project process include the project management plan, contract documentation, enterprise environmental factors, organizational process assets, work performance information, and the deliverables. The project plan and contract documentation have been described several times already in this book.

The enterprise environmental factors include the organization's culture and structure. Standards, as established by the industry or government regulations, are also part of the enterprise environmental factors.

The people available for the project are a major part of the internal environmental factors, as are the personnel administration guidelines set up by the company. Another important internal environmental factor is the stakeholder risk tolerances, which will determine how you will manage the risks that occur in the execution of projects.

An external factor in the enterprise environment will be the marketplace conditions. These conditions are outside the control of the organization but will still influence how the project is executed and will probably influence whether the project is actually chosen in the first place.

The work performance information will come from the various performance reports that are done throughout the project, and your job, as outlined before, is to manage the variances between the planned and the actual in the execution of the project.

The outputs of the close project process are the administrative closure procedures. These will be the guidelines that are needed in order to bring full administrative closure to the project, and they should be clearly recorded and kept throughout the project. Without these, the project will go on and on and on...

Integrated Change Control

Another major area of Project Integration Management is Integrated Change Control. According to the PMBOK, there are four major factors to consider: identifying that a change has occurred or needs to occur, making sure that only approved changes are implemented, reviewing and approving requested changes, and managing the actual changes when they occur. In order to do this, you must be able to delineate the original performance measure baselines. These are the standards you use to measure change.

Developing the Project Plan

To begin the process of planning the project, it is necessary to gather as much information concerning the new project as you can. Because projects are not exactly the same time after time, you can get information from other projects that will at least give you guidelines to follow. These guidelines will not be plans that you can follow exactly because there are by definition differences between projects. But other plans used in the past can be valuable if you use them with the caveat that your project is not the same as what you are examining.

The first place to go for information is other project managers who have planned and executed projects like the one you are about to undertake. This is particularly true if these project managers are also PMPs. I have had many good conversations with other project managers about projects I was about to undertake, and I know that I saved a great deal of time by using other PMPs as a resource. If nothing else, I get a sounding board for my planning and also experience with a similar project. Ideas and tasks almost always come up that I had not thought about in any depth or at all. There is nothing quite like a conversation with another project manager about risks he or she overcame during the execution of his or her project.

You may also be able to find databases of formally recorded information. This information can include how the estimating was done as well as how the project was executed against its original baseline. Any information that has been kept on former projects can be very useful to you as you plan and execute yours.

A very valuable addition to your information can be the WBS of a previous project. These can be very helpful in defining tasks and sequencing. One of the problems with looking at a previous project's WBS, though, is the trap of using the numbers in the WBS you are examining. These were probably different people in a different time setting who almost certainly had deliverables other than those that your project has now.

Develop Preliminary Project Scope Statement

The inputs into developing this process are the project Charter, project statement of work, enterprise environmental factors, and organizational process assets according to the Section. The Charter has been described previously. The project statement of work, or SOW, is created at this stage and contains narrative that describes the products or services that will be the output of the project. The SOW shows the business need for the project, which links it closely to the Charter. In addition, the scope definition gives the product requirements. Finally, the Charter has a clear link to the strategic plan of the organization. Because all projects support the organization's overall strategic vision, the strategic plan (or at least the main points in the strategy) should be part of the development of the early project scope statements.

One of the techniques of managing an organization or project is to manage the variance between what was planned and what actually occurs. This is also one of the tools and techniques found in project management methodology. We have already encountered one of the techniques used in project management through the use of earned value (EV), as discussed in This technique measures the variance in projects and is an accounting form that is not often seen in general management. In Project Integration Management, the term used to describe the process of managing by variance is called Earned Value Management (EVM). EVM is a project integrating methodology, whereas EV is the technique. EVM is the way project management uses variance management to assess the state of the project.

The Project Plan

The actual project plan that you will manage flows from the normal way an organization determines its activities, goals and objectives for the future. The strategic planning conducted by an organization's management determines which projects will be sponsored in order to achieve the organizational goals. For many companies, strategic planning is a formal process through which the top management goes in order to utilize the assets of the company in the best possible way for the shareholders. In later chapters, we will look at various tools and techniques for determining the selection of projects to be funded, but in this chapter, suffice it to say that the organizational management team determines in some fashion that certain projects will bring about better results for the organization than others.

Project Integration Management

The first half of this book deals with the phases of a project. The final half will deal with the knowledge areas as they are found in the Section. The various knowledge areas permit you to study specific topics in depth, while the phases deal with topical areas that occur throughout a project.

The nine knowledge areas of Section all use the same format. The sections to be studied are in sequence as they would happen in a project. For instance, in the Integration knowledge section, there are seven sections or processes through which you go to execute and manage a project. They are: Develop Project Charter, Develop Preliminary Project Scope Statement, Develop Project Management Plan, Direct and Manage Project Execution, Monitor and Control Project Work, Integrated Change Control, and Close Project.

Within each of these sections are Inputs, Tools and Techniques, and Outputs. This organization greatly corresponds to systems theory, where Inputs are transformed into Outputs by use of throughput. In the PMBOK version, Tools and Techniques are the transformation mechanisms to go from Inputs to Outputs.

Because Section is set up this way, and in order to make it easy to use this book with Section , the Inputs, Tools and Techniques, and Outputs formats will be followed. If there is something that does not fit exactly within these three areas, it will be explored, but only if it is going to be on the exam. So we start the knowledge area section of the book. By studying both sections of this book, you will have a better understanding of the exam topics and different ways to approach them.

Responsibilities to Customers and the Public

The Code of Professional Conduct states that a PMP has the "Responsibility to provide accurate and truthful representations to the public in advertising, public statements and in the preparation of estimates concerning costs, services and expected results." The key part of this statement that is new is the preparation of estimates. This is often a very difficult problem to handle and is something that sets apart a professional project manager.

The first task that a project manager must handle is ensuring that the correct Scope Statement is written. Even if no Charter is written, there must be a Scope Statement for the project to progress. This is where all the estimates start. The clearer the Scope Statement, the better the chance for making good estimates. All projects involve estimates because no project is exactly the same as another.

"Project Cost Management." The Code of Professional Conduct is not about how to do estimates but rather how to be professional in your work. On several occasions, I have been asked as a consulting project manager to look at estimates from outside vendors. Some vendors have a tendency to bid low and then, after receiving the contract for the work, immediately put in change requests. This type of conduct should not be happening if you are a PMP.

Professional Conduct and Ethics

The next step in the evolution of a profession is to establish rules of conduct and ethics. Professions such as medicine and architecture have had codes of conduct and ethics for years. PMI believes, and rightly so, that in order to make project management more of a profession, a standardized code should be published, and the various parts of the code of ethics and professional conduct should be tested on the PMP examination.

The first attempt at implementing this idea has been the publishing of a page on the PMI website (page 22 of the Project Management Institute Certification Handbook) that describes the basic concepts to be recognized as standards for the PMI member and the PMP candidates and certified project professionals. This has become a major part of the PMP certification exam, and we will use this chapter to help prepare you for this particular part of the exam. The code of professional ethics and conduct is more than theory; it is a workable delineation of how a project manager should conduct himself or herself in normal project management practice. As such, it is an extremely valuable part of preparing for the PMP exam and something that is usable each day in practicing project management.

The website divides the information concerning ethics and conduct into two sections. Each of those two sections is then subdivided. We will look at the area of conduct and ethics by using questions to show how the examination will ask about the topic. In many cases, ethics and conduct simply involve using common sense. One would hope that most people would use high standards in practicing project management, and the following shows you how PMI wants project managers to conduct themselves. We will look at each section and its subsections.

Contract Closeout

Although Administrative Closeout will occur on every project, Contract Closeout occurs only when a formal contract has been written. For instance, there may be no formal contract if you are doing the project as part of an internal system for an organization. In this case, it is unusual to have a formal contract.

However, if you are a delivering organization outside of the one where the project is being done, then it is likely that you will have a contract with specific terms and specifications. This means that you will have contract documentation that you will need to conform to in order to fulfill the obligations as written in the contract itself.

The well mentions procurement audits as a part of Contract Closeout. A procurement audit is "a structured review of the procurement process from procurement planning through contract administration." Procurement audits are prevalent in government contracting, although more and more private businesses use procurement audits on their projects. Usually, procurement audits are not controlled by the project manager but rather are conducted by a separate individual or organization.

Control and Closing

Everyone with whom I have talked describes some project they have been on where it seemed that the project never ended. Even if they were switched to another project, the initial project seemed to go on and on of its own volition. Almost everyone called this a part of their "project from hell." There are many reasons why projects don't end. Some projects can go on and on because of funding issues. In many companies, it is easier to get funds to do a project than it is to get operating funds. Even when the project is actually complete, it is sometimes easier to request ongoing funds even though the product of the project is completed. When the project has been done and the actions have become a part of the operating system, the project is over. It is not unusual for a group of people or a segment of a company to want to continue the process they have started, but in fact it doesn't help the company to continue to call an operating process a project.

How do you stop this? At the beginning of the project planning process, the project manager needs to work with all of the stakeholders to get agreement on what a complete project is. There must be a well defined deliverable that is the final output of the project. Failure to define project completion will cause the project to drag on and on. In one organization for which I consulted, several so-called "projects" had been running for years. In fact, the projects were part of the overall operating system and required some maintenance, but they weren't true projects.

Earned Value Acronyms and Formulas

This chapter has several formulas that you need to memorize. Because they are so important, they are included here again. These mathematical formulas are not hard; you simply have to know them and apply them to a set of questions. These formulas deal with earned value. They will be shown here and again later in the book because of their importance on the test.

Both the old and new acronyms are shown here; the new ones are used on the test, but the old ones are included here for completeness. The new ones are much clearer and make more sense.

EV = Earned Value. The value of the work on the project that is already complete.

PV = Planned Value. What you show in your plan for the project.

AC = Actual Cost. The actual cost of performing the work on the project.

Cost Variance (CV) = Earned Value-Actual Cost. In acronyms, EV-AC.

Cost Performance Index (CPI) = Earned Value divided by Actual Cost, or EV/AC.

Schedule Performance Index (SPI) = Earned Value divided by Planned Value, or EV/PV.

The earned value section of the exam can be found in different sections . It was put in the Execution and Control phases of this book because it belongs there. Your knowledge of earned value and how to use it can be very helpful in explaining how a project is being conducted.

I should mention again that in many cases, doing an accurate job of earned value analysis is extremely difficult. Most of the time in projects, the preciseness that we present in theory is not as clear as it is in a book. However, you need to do some sort of analysis on variances as you execute and control the project, and earned value is another tool with which you can work.

Whats Earned Value?

This is one part of the Control phase that is unique to projects. It is also questioned on the examination, so it is a good idea to know it well. Having taught this concept for many classes, I find that if you can get the general concept, it is fairly easy to understand and use the various formulas for earned value. Understand that this concept is project-oriented and that if you discuss it with the accounting department at your firm, they will often look at you with glazed eyes, or even worse, with a slightly demeaning smile. Earned value is not taught in standard accounting, and the concepts, although simple, are not a part of the vocabulary of an accountant. Let us go gently into the good night that is earned value.

When you do standard corporate accounting, for the most part you look at one year at a time. This becomes the grade card against which the company is measured and the standard by which the managers are analyzed and compensated. When you do a project that takes a six-month period or a fourteen-month period, the way you analyze and control the information about the project changes.

Earned value analysis is simply the analysis of what has actually been done so far on the project. Think of a six-month project. You are now at the end of the third month. By looking at the plan, you will see how far along you should be at this point. You will also see how much money you were supposed to have spent by the end of the third month.

All you do is measure what was in the plan against what you actually have done at the end of the third month. If you were scheduled to be 50% done with all your tasks by the end of the third month and you find that you are only 45% done, then you are behind the original schedule. If you were to have spent 55% of the funds for the project by the end of the third month and you have only spent 50% of the funds, you are under the budget at this time. There are formulas to explain these calculations.

Two sets of acronyms are used on the exam. The old ones were used through the 1996 edition of the PMBOK, and the new ones came out with the 2000 edition of the same book and are used in the 3^rd edition. Most people, myself included, think that the new acronyms are much easier to use. (On the exam, both sets are shown at the same time.) They are easy to comprehend. Here are the acronyms.

EV=Earned Value. This is the value of the work on the project that is actually completed. The old acronym was BCWP, or Budgeted Cost of Work Performed. EV and BCWP mean the same thing.

What is Statement of Work (SOW)?

Although this document is usually described in the procurement knowledge area, it can also be seen as a major part of control that is needed in the project. It will be discussed again in the procurement area, but here is an explanation of the SOW.

According to the us, the SOW is "a narrative description of products, services, or results to be supplied." The SOW is extremely important on projects that will use materials and items from outside vendors. The better the description in the SOW, the better the vendor will be at offering an item that fits the needs of the project.

The SOW should be done in sufficient detail so that all collateral services are also included in the description. For instance, if you are planning an IT project that involves outside vendors who will do the actual code development, you should explain the product of the development you expect as well as how you want the vendor to report the progress on this part of the project.

The SOW is often seen with a Request for Proposal. For most government projects, an RFP is sent out to a list of authorized bidders. But a Request for Proposal doesn't give detail on the specific items. That is in the SOW. This is a thin line for many projects, but in PMBOK, the SOW is a specific document that you can use to control the costs of the project and to give various vendors as much information as possible about the type of items you want to purchase for your product.

Work Authorization System

Yet another way to control a project is through a work authorization system . This a work authorization system as "a collection of formal documented procedures that defines how project work will be authorized to ensure the work is done by the identified organization, at the right time, and in the proper sequence." This is most often a written authorization to begin a specific activity or work package that is part of the project plan.

we that determining whether to use a formal work authorization system is a question of balancing cost against use. If putting a formal system in place will take too long or will actually be a cost that the project must support, there certainly will be times when verbal authorization will be used. Verbal authorization is used most often in smaller projects where a formal work authorization system may be too costly or complex to install.

Whats is Version Control?

As much as Scope Change Control is important to running a project smoothly, so too is having version control of the documents used on the project. Recently I was in a meeting with eight people, and we were all looking at a WBS done in MS Project. The problem was that the manager running the meeting failed to ask for a specific version to be used at the meeting, so three versions of the same document were being used at the same time.

It didn't take very long to ascertain that there were different versions, and the meeting leader made a good decision when she had all the documents collected, copied the latest version, and distributed it to everybody at the meeting. All of us were on the same page (literally), and the meeting ran well.

This incident highlights several issues. First, several versions of documents will be created during the course of a project. It is necessary to change the version number every time the content changes. So it is possible to have several versions of a single document going on at the same time, particularly when the changes made to the document are coming fast and furious. Second, when a meeting is being held, the chair of the meeting (in many cases the project manager) should specify the version number to be discussed at the meeting.

When this type of control is first implemented in an organization, many people fail to understand the importance of version control. Much like with Scope Change Control, small incremental changes are left out at the beginning of an organization's attempts at project management techniques and processes. But just like Scope Change Control, version change control will be a great help in the Controlling Phase of the project. This is particularly true when you are using documents in meetings. You will be getting the latest information to various people on the project team, which they can discuss with confidence.

After a document is finalized in the project plan, it should be locked down under version control. That is, the baseline form of the document is version 1.0. Any changes, repeat, any changes made in the document from that time on warrant a version change. This may seem like much ado about nothing, but as with scope creep, you will have "version creep" if you do not note all changes. It is very hard to inculcate this technique into an organization when its people are accustomed to version creep.

Change Control System and Change Control Board

A change control system includes the documentation, tracking systems, and approval levels necessary for authorizing changes. It includes the paperwork, tracking systems, processes, and approval levels necessary for authorizing changes." In practice, this describes a way of determining how the project manager will deal with changes and also a way of tracking whether the changes have been accepted. If you don't write the changes down and make them a permanent part of the project record, problems will probably occur later. Make sure you keep track of changes. If you do not have the information about how you, the project manager, should deal with changes, then meet with functional managers and the sponsor to get this information recorded.

One of the systems that you need to put in place immediately upon beginning the execution of a planned project is a Change Control Board. This group is the one through which all changes to the project are channeled. It is not always necessary to have a CCB, particularly on fairly small projects. But as the projects get larger, it is important to have a board that controls changes.

Who is on the CCB? The first person on the CCB is always the project manager of the project. You do not want to have changes going on as a project manager without the capacity to give input into how the changes will affect the project. If possible, you should include the sponsor. This may be problematic if the sponsor is a high-ranking manager in the organization who does not really have the time to look at each change. In that case, get someone to represent the sponsor. It is also possible that a project manager may be able to sign off on changes up to a certain dollar amount or a certain time span. If the change in question goes above the approved dollar or time amount, the sponsor or the sponsor's representative should be on the CCB.

Often technical experts are included on a CCB. For an IT project, several functions are needed to complete a project. You may choose someone from marketing or someone from development to sit on your CCB if his or her particular expertise is useful.

General Comments on Planning and Execution

More than 90% of a project manager's job is done in the Planning and Execution phases. Planning is where you create the roadmap you are going to follow to the end of the project, and Execution is where you make it happen. Which is more important? Neither and both. If you are not a very good planner, then problems will occur in the Execution phase because you probably will be "winging" it at some point, which is not very good project management. At the same time, you can save projects during execution even if the first planning was less than excellent.

Although the project manager must be able to do "workarounds" for unexpected problems, if you have planned well, there will be few of these. You will not, repeat not, have a project that goes exactly as planned from day one to the end of the project. That happens only in theory. If you are using people on your project (or I guess animals too), something will happen that is unexpected. But plan for the best.

There are also cases where projects aren't planned completely, but a good project manager manages to bring the project in close to time and cost. This is not recommended procedure, but all of us have had to do it. Sometimes the organization is ready to start at a certain date and does not build in the necessary planning time. My only hope is that they are fortunate enough to have a professional project manager in place and that he or she can draw on enough intelligence and experience to bring it off.

So, having a project manager who can handle workarounds or any type of unexpected action taking place, and who understands the various organizational structures in which he/she finds him/herself, means that the Execution phase of the project is one where the actual project

what is need of Status Meetings?

As you go through the project, one of the important actions that you take is to set up status meetings for the project team. In these meetings, you look at the project baseline and discuss the project's status, or in other words, how well you have kept to the original plan. You will have a Schedule and a WBS at a very minimum. Even if you don't create formal plans for other areas (which will happen in some cases, particularly in fairly short projects), you must have a Schedule and a WBS to manage a project.

For many organizations, it seems that meetings take the place of working. Don't let this happen on your projects. First, you should write down and formalize who is going to attend the status meetings. This simple information is part of the communication plan. Who should go to the meetings? That depends on who needs information to get the project done. On long projects, there may be people who won't be involved at the beginning of the project but who will do important tasks later. There is no, I repeat, no good reason to ask those people to be at the early status meetings. You can talk to them by phone, keep them up to date, email them, but they do not need to sit in meetings where the discussion doesn't directly affect them. If their tasks begin five months from now, you shouldn't demand that they sit through early status meetings unless they actually want to do so. If they find it helpful to be there, people will ask to be informed about when your status meetings are held. If they find it painfully boring to sit through status meetings that give them no useful information for their particular part of the project, you will see their eyes glaze over during your meetings.

Communication in the Execution Phase

During the Planning phase, the project manager constructs the communication plan for the project. In a survey in which I participated, more than 90% of the PMs suggested that communication during the Execution phase was the number one priority action for the successful project manager. However, even knowing that communication is a major priority, most of the time, project managers don't write out a formal communication plan. Part of the reason is that it isn't very clear exactly what should be in the plan. Here are some of the communication components that are important for the success of the project.

Channels

There are two aspects concerning communication channels that you need to know for the exam. First, there is a formula that you should remember for the test. It determines how many channels are involved with any number of people. The formula is:

N(N1)/2, where N=the number of people

What is Stakeholders?

project stakeholders are "persons and organizations such as customers, sponsors, performing organization and the public, that are actively involved in the project, or whose interests may be positively or negatively affected by execution or completion of the project." As a project manager beginning to plan and execute a project, there is no more valuable information than to know who is a stakeholder for the project. This information will help determine who will be on the project team, manage it, sponsor it, and use the output of the project when it is completed. Communication with stakeholders is a constant task of a project manager. On all successful projects, this is one of the most important tasks possible. Here are various stakeholders you will find on all projects.

• Project Manager The person who has the responsibility for the outcome of the project.

• Team Members The project team that does the actual work on the project.

• Sponsor The person or group that allocates resources to the project.

• Customer The individual or organization that will use the output of the project. Other names for this stakeholder may be "client" or "user."

All these people or organizations need to be constantly informed about the progress of the project itself. This communication will ultimately determine the overall success of the project.

IT and Engineering

Although all projects follow basic phases, it's important to note that IT projects and engineering projects differ, for a few simple reasons. First, engineering is a discipline that is taught with very rigid standards that have been gathered for thousands of years. In fact, as you go through an engineering school, you will be taught project management implicitly because engineering projects are conducted according to well-designed plans. You don't start building a bridge without something written down. It just won't work.

IT, however, has a very different feel to it. Many of the people I meet each day in IT didn't start in the area and were not trained in it. Instead, they had extraordinary skills of some sort, and they often began as codersthat is, writers of the language for the machines. They then continued up the corporate ladder but often topped out as a group leader or lead technical person. For many, the next step is project management, and because most people don't take anything like project management topics in their undergraduate studies, PMI offers a way to become aware of and then competent in Project Management Practices.

Another major consideration in IT is that often a single "build" is done and then sent to the sponsor for approval. This means that often it is difficult to write a complete project plan because rework or sponsor input sometimes change the original schedule. This issue causes consternation among those who want project management to be a rigid science, as in the engineering realm. But in fact there is a major divide between IT and engineering that should be acknowledged even as we teach for the exam. The notion of an "agile" programming process originated conceptually as a response to the more rigid building standards of engineering, and it is becoming more and more important in the IT world. For this exam, most of the model describes a plan that is written at the beginning and followed to completion of the project. The original writers of PMBOK seem to have had an engineering frame of reference, and the book reflects it. Remember this point if you want to pass the exam, no matter what your area of project management.