The most important responsibilities of a project manager are planning, integrating, and executing plans. Almost all projects, because of their relatively short duration and often prioritized control of resources, require formal, detailed planning. The integration of the planning activities is necessary because each functional unit may develop its own planning documentation with little regard for other functional units.
Planning, in general, can best be described as the function of selecting the enterprise objectives and establishing the policies, procedures, and programs necessary for achieving them. Planning in a project environment may be described as establishing a predetermined course of action within a forecasted environment. The project's requirements set the major milestones. If line managers cannot commit because the milestones are perceived as unrealistic, the project manager may have to develop alternatives, one of which may be to move the milestones. Upper-level management must become involved in the selection of alternatives.
The project manager is the key to successful project planning. It is desirable that the project manager be involved from project conception through execution. Project planning must be systematic, flexible enough to handle unique activities, disciplined through reviews and controls, and capable of accepting multifunctional inputs. Successful project managers realize that project planning is an iterative process and must be performed throughout the life of the project.
PMBOK® Guide, 4th Edition
5.2 Define Scope
One of the objectives of project planning is to completely define all work required (possibly through the development of a documented project plan) so that it will be readily identifiable to each project participant. This is a necessity in a project environment because:
These considerations are important in a project environment because each project can be different from the others, requiring a variety of different resources, but having to be performed under time, cost, and performance constraints with little margin for error. Figure 11-1 identifies the type of project planning required to establish an effective monitoring and control system. The boxes at the top represent the planning activities, and the lower boxes identify the “tracking” or monitoring of the planned activities.
There are two proverbs that affect project planning:
Without proper planning, programs and projects can start off “behind the eight ball.” Consequences of poor planning include:
There are four basic reasons for project planning:
Planning is a continuous process of making entrepreneurial decisions with an eye to the future, and methodically organizing the effort needed to carry out these decisions. Furthermore, systematic planning allows an organization of set goals. The alternative to systematic planning is decision-making based on history. This generally results in reactive management leading to crisis management, conflict management, and fire fighting.
Planning begins with an understanding of the assumptions. Quite often, the assumptions are made by marketing and sales personnel and then approved by senior management as part of the project selection and approval process. The expectations for the final results are based upon the assumptions made.
Why is it that, more often than not, the final results of a project do not satisfy senior management's expectations? At the beginning of a project, it is impossible to ensure that the benefits expected by senior management will be realized at project completion. While project length is a critical factor, the real culprit is changing assumptions.
Assumptions must be documented at project initiation using the project charter as a possible means. Throughout the project, the project manager must revalidate and challenge the assumptions. Changing assumptions may mandate that the project be terminated or redirected toward a different set of objectives.
A project management plan is based upon the assumptions described in the project charter. But there are additional assumptions made by the team that are inputs to the project management plan.1 One of the primary reasons companies use a project charter is that project managers were most often brought on board well after the project selection process and approval process were completed. As a result, project managers were needed to know what assumptions were considered.
Enterprise Environmental Factors
These are assumptions about the external environmental conditions that can affect the success of the project, such as interest rates, market conditions, changing customer demands and requirements, changes in technology, and even government policies.
These are assumptions about present or future company assets that can impact the success of the project such as the capability of your enterprise project management methodology, the project management information system, forms, templates, guidelines, checklists, and the ability to capture and use lessons learned data and best practices.
Planning is determining what needs to be done, by whom, and by when, in order to fulfill one's assigned responsibility. There are nine major components of the planning phase:
An item that has become important in recent years is documenting assumptions that go into the objectives or the project/subsidiary plans. As projects progress, even for short-term projects, assumptions can change because of the economy, technological advances, or market conditions. These changes can invalidate original assumptions or require that new assumptions be made. These changes could also mandate that projects be canceled. Companies are now validating assumptions during gate review meetings. Project charters now contain sections for documenting assumptions.
Several of these factors require additional comment. Forecasting what will happen may not be easy, especially if predictions of environmental reactions are required. For example, planning is customarily defined as either strategic, tactical, or operational. Strategic planning is generally for five years or more, tactical can be for one to five years, and operational is the here and now of six months to one year. Although most projects are operational, they can be considered as strategic, especially if spin-offs or follow-up work is promising. Forecasting also requires an understanding of strengths and weaknesses as found in:
If project planning is strictly operational, then these factors may be clearly definable. However, if strategic or long-range planning is necessary, then the future economic outlook can vary, say, from year to year, and replanning must be done at regular intervals because the goals and objectives can change. (The procedure for this can be seen in Figure 11-1.)
The last three factors, policies, procedures, and standards, can vary from project to project because of their uniqueness. Each project manager can establish project policies, provided that they fall within the broad limits set forth by top management.
Project policies must often conform closely to company policies, and are usually similar in nature from project to project. Procedures, on the other hand, can be drastically different from project to project, even if the same activity is performed. For example, the signing off of manufacturing plans may require different signatures on two selected projects even though the same end-item is being produced.
Planning varies at each level of the organization. At the individual level, planning is required so that cognitive simulation can be established before irrevocable actions are taken. At the working group or functional level, planning must include:
At the organizational or project level, planning must include:
The logic of planning requires answers to several questions in order for the alternatives and constraints to be fully understood. A list of questions would include:
One of the most difficult activities in the project environment is to keep the planning on target. These procedures can assist project managers during planning activities:
PMBOK® Guide, 4th Edition
Chapter 2 Project Life Cycle and Organization
2.1 Characteristics of Project Phases
Project planning takes place at two levels. The first level is the corporate cultural approach; the second method is the individual's approach. The corporate cultural approach breaks the project down into life-cycle phases, such as those shown in Table 2-6. The life-cycle phase approach is not an attempt to put handcuffs on the project manager but to provide a methodology for uniformity in project planning. Many companies, including government agencies, prepare checklists of activities that should be considered in each phase. These checklists are for consistency in planning. The project manager can still exercise his own planning initiatives within each phase.
A second benefit of life-cycle phases is control. At the end of each phase there is a meeting of the project manager, sponsor, senior management, and even the customer, to assess the accomplishments of this life-cycle phase and to get approval for the next phase. These meetings are often called critical design reviews, “on-off ramps,” and “gates.” In some companies, these meetings are used to firm up budgets and schedules for the follow-on phases. In addition to monetary considerations, life-cycle phases can be used for manpower deployment and equipment/facility utilization. Some companies go so far as to prepare project management policy and procedure manuals where all information is subdivided according to life-cycle phasing. Life-cycle phase decision points eliminate the problem where project managers do not ask for phase funding, but rather ask for funds for the whole project before the true scope of the project is known. Several companies have even gone so far as to identify the types of decisions that can be made at each end-of-phase review meeting. They include:
Consider a company that utilizes the following life-cycle phases:
The conceptualization phase includes brainstorming and common sense and involves two critical factors: (1) identify and define the problem, and (2) identify and define potential solutions.
In a brainstorming session, all ideas are recorded and none are discarded. The brainstorming session works best if there is no formal authority present and if it lasts thirty to sixty minutes. Sessions over sixty minutes will produce ideas that may resemble science fiction.
The feasibility study phase considers the technical aspects of the conceptual alternatives and provides a firmer basis on which to decide whether to undertake the project.
The purpose of the feasibility phase is to:
If practical, the feasibility study results should evaluate the alternative conceptual solutions along with associated benefits and costs.
The objective of this step is to provide management with the predictable results of implementing a specific project and to provide generalized project requirements. This, in the form of a feasibility study report, is used as the basis on which to decide whether to proceed with the costly requirements, development, and implementation phases.
User involvement during the feasibility study is critical. The user must supply much of the required effort and information, and, in addition, must be able to judge the impact of alternative approaches. Solutions must be operationally, technically, and economically feasible. Much of the economic evaluation must be substantiated by the user. Therefore, the primary user must be highly qualified and intimately familiar with the workings of the organization and should come from the line operation.
The feasibility study also deals with the technical aspects of the proposed project and requires the development of conceptual solutions. Considerable experience and technical expertise are required to gather the proper information, analyze it, and reach practical conclusions.
Improper technical or operating decisions made during this step may go undetected or unchallenged throughout the remainder of the process. In the worst case, such an error could result in the termination of a valid project—or the continuation of a project that is not economically or technically feasible.
In the feasibility study phase, it is necessary to define the project's basic approaches and its boundaries or scope. A typical feasibility study checklist might include:
The end result of the feasibility study is a management decision on whether to terminate the project or to approve its next phase. Although management can stop the project at several later phases, the decision is especially critical at this point, because later phases require a major commitment of resources. All too often, management review committees approve the continuation of projects merely because termination at this point might cast doubt on the group's judgment in giving earlier approval.
The decision made at the end of the feasibility study should identify those projects that are to be terminated. Once a project is deemed feasible and is approved for development, it must be prioritized with previously approved projects waiting for development (given a limited availability of capital or other resources). As development gets under way, management is given a series of checkpoints to monitor the project's actual progress as compared to the plan.
The third life-cycle phase is either preliminary planning or “defining the requirements.” This is the phase where the effort is officially defined as a project. In this phase, we should consider the following:
These elements can be condensed into four core documents, as will be shown in Section 11.7. Also, it should be noted that the word “customer” can be an internal customer, such as the user group or your own executives.
The table below shows the percentage of direct labor hours/dollars that are spent in each phase:
The interesting fact from this table is that as much as 50 percent of the direct labor hours and dollars can be spent before execution begins. The reason for this is simple: Quality must be planned for and designed in. Quality cannot be inspected into the project. Companies that spend less than these percentages usually find quality problems in execution.
There is always a question of what to do with a project manager between assignments. For companies that survive on competitive bidding, the assignment is clear: The project manager writes proposals for future work. This takes place during the feasibility study, when the company must decide whether to bid on the job. There are four ways in which proposal preparation can occur:
The typical launch of a project begins with a kickoff meeting involving the major players responsible for planning, including the project manager, assistant project managers for certain areas of knowledge, subject matter experts (SME), and functional leads. A typical sequence is shown in Figure 11-2.
There can be multiple kickoff meetings based upon the size, complexity, and time requirements for the project. The major players are usually authorized by their functional areas to make decisions concerning timing, costs, and resource requirements.
Some of the items discussed in the initial kickoff meeting include:
For a small or short-term project, estimates on cost and duration may be established in the kickoff meeting. In this case, there may be little need to establish a cost estimating schedule. But where the estimating cycle is expected to take several weeks, and where inputs will be required from various organizations and/or disciplines, an essential tool is an estimating schedule. In this case, there may be a need for a prekickoff meeting simply to determine the estimates. The minimum key milestones in a cost estimating schedule are (1) a “kickoff” meeting; (2) a “review of ground rules” meeting; (3) “resources input and review” meeting; and (4) summary meetings and presentations. Descriptions of these meetings and their approximate places in the estimating cycle follow.2
The very first formal milestone in an estimate schedule is the estimate kickoff meeting. This is a meeting of all the individuals who are expected to have an input to the cost estimate. It usually includes individuals who are proficient in technical disciplines involved in the work to be estimated; business-oriented individuals who are aware of the financial factors to be considered in making the estimate; project-oriented individuals who are familiar with the project ground rules and constraints; and, finally, the cost estimator or cost estimating team. The estimating team may not include any of the team members responsible for execution of the project.
Sufficient time should be allowed in the kickoff meeting to describe all project ground rules, constraints, and assumptions; to hand out technical specifications, drawings, schedules, and work element descriptions and resource estimating forms; and to discuss these items and answer any questions that might arise. It is also an appropriate time to clarify estimating assignments among the various disciplines represented in the event that organizational charters are not clear as to who should support which part of the estimate. This kickoff meeting may be 6 weeks to 3 months prior to the estimate completion date to allow sufficient time for the overall estimating process. If the estimate is being made in response to a request for quotation or request for bid, copies of the request for quotation document will be distributed and its salient points discussed.
The Review of Ground Rules Meeting
Several days after the estimate kickoff meeting, when the participants have had the opportunity to study the material, a review of ground rules meeting should be conducted. In this meeting the estimate manager answers questions regarding the conduct of the cost estimate, assumptions, ground rules, and estimating assignments. If the members of the estimating team are experienced in developing resource estimates for their respective disciplines, very little discussion may be needed. However, if this is the first estimating cycle for one or more of the estimating team members, it may be necessary to provide these team members with additional information, guidance, and instruction on estimating tools and methods. If the individuals who will actually perform the work are doing the estimating (which is actually the best arrangement for getting a realistic estimate), more time and support may be needed than would experienced estimators.
The Resources Input and Review Meeting
Several weeks after the kickoff and review of ground rules meetings, each team member that has a resources (man-hour and/or materials) input is asked to present his or her input before the entire estimating team. Thus starts one of the most valuable parts of the estimating process: the interaction of team members to reduce duplications, overlaps, and omissions in resource data.
The most valuable aspect of a team estimate is the synergistic effect of team interaction. In any multidisciplinary activity, it is the synthesis of information and actions that produces wise decisions rather than the mere volume of data. In this review meeting the estimator of each discipline area has the opportunity to justify and explain the rationale for his estimates in view of his peers, an activity that tends to iron out inconsistencies, over-statements, and incompatibilities in resources estimates. Occasionally, inconsistencies, overlaps, duplications, and omissions will be so significant that a second input and review meeting will be required to collect and properly synthesize all inputs for an estimate.
Once the resources inputs have been collected, adjusted, and “priced,” the cost estimate is presented to the estimating team as a “dry run” for the final presentation to the company's management or to the requesting organization. This dry run can produce visibility into further inconsistencies or errors that have crept into the estimate during the process of consolidation and reconciliation. The final review with the requesting organization or with the company's management could also bring about some changes in the estimate due to last minute changes in ground rules or budget-imposed cost ceilings.
Companies that have histories of successful plans also have employees who fully understand their roles in the planning process. Good up-front planning may not eliminate the need for changes, but may reduce the number of changes required. The responsibilities of the major players are as follows:
Successful planning requires that project, line, and senior management are in agreement with the plan.
Successful project management, whether in response to an in-house project or a customer request, must utilize effective planning techniques. The first step is understanding the project objectives. These goals may be to develop expertise in a given area, to become competitive, to modify an existing facility for later use, or simply to keep key personnel employed.
The objectives are generally not independent; they are all interrelated, both implicitly and explicitly. Many times it is not possible to satisfy all objectives. At this point, management must prioritize the objectives as to which are strategic and which are not. Typical problems with developing objectives include:
Once the objectives are clearly defined, four questions must be considered:
If the project is large and complex, then careful planning and analysis must be accomplished by both the direct- and indirect-labor-charging organizational units. The project organizational structure must be designed to fit the project; work plans and schedules must be established so that maximum allocation of resources can be made; resource costing and accounting systems must be developed; and a management information and reporting system must be established.
Effective total program planning cannot be accomplished unless all of the necessary information becomes available at project initiation. These information requirements are:
The statement of work (SOW) is a narrative description of the work to be accomplished. It includes the objectives of the project, a brief description of the work, the funding constraint if one exists, and the specifications and schedule. The schedule is a “gross” schedule and includes such things as the:
Written reports should always be identified so that if functional input is required, the functional manager will assign an individual who has writing skills.
The last major item is the work breakdown structure. The WBS is the breaking down of the statement of work into smaller elements for better visibility and control. Each of these planning items is described in the following sections.
PMBOK® Guide, 4th Edition
5.2.3 Scope Definition
5.2.3.1 Project Scope Statement
12.1.3.2 Contract Statement of Work
The PMBOK® Guide addresses four elements related to scope:
The statement of work (SOW) is a narrative description of the work required for the project. The complexity of the SOW is determined by the desires of top management, the customer, and/or the user groups. For projects internal to the company, the SOW is prepared by the project office with input from the user groups because the project office is usually composed of personnel with writing skills.
For projects external to the organization, as in competitive bidding, the contractor may have to prepare the SOW for the customer because the customer may not have people trained in SOW preparation. In this case, as before, the contractor would submit the SOW to the customer for approval. It is also quite common for the project manager to rewrite a customer's SOW so that the contractor's line managers can price out the effort.
In a competitive bidding environment, there are two SOWs—the SOW used in the proposal and a contract statement of work (CSOW). There might also be a proposal WBS and a contract work breakdown structure (CWBS). Special care must be taken by contract and negotiation teams to discover all discrepancies between the SOW/WBS and CSOW/CWBS, or additional costs may be incurred. A good (or winning) proposal is no guarantee that the customer or contractor understands the SOW. For large projects, fact-finding is usually required before final negotiations because it is essential that both the customer and the contractor understand and agree on the SOW, what work is required, what work is proposed, the factual basis for the costs, and other related elements. In addition, it is imperative that there be agreement between the final CSOW and CWBS.
SOW preparation is not as easy as it sounds. Consider the following:
These three examples show that misinterpretations of the SOW can result in losses of hundreds of millions of dollars. Common causes of misinterpretation are:
Misinterpretations of the statement of work can and will occur no matter how careful everyone has been. The result is creeping scope, or, as one telecommunications company calls it, “creeping elegance.” The best way to control creeping scope is with a good definition of the requirements up front, if possible.
Today, both private industry and government agencies are developing manuals on SOW preparation. The following is adapted from a NASA publication on SOW preparation3:
SOW preparation manuals also contain guides for editors and writers4:
Some preparation documents also contain checklists for SOW preparation.5 A checklist is furnished below to provide considerations that SOW writers should keep in mind in preparing statements of work:
Finally, there should be a management review of the SOW preparation interpretation6:
During development of the Statement of Work, the project manager should ensure adequacy of content by holding frequent reviews with project and functional specialists to determine that technical and data requirements specified do conform to the guidelines herein and adequately support the common system objective. The CWBS/SOW matrix should be used to analyze the SOW for completeness. After all comments and inputs have been incorporated, a final team review should be held to produce a draft SOW for review by functional and project managers. Specific problems should be resolved and changes made as appropriate. A final draft should then be prepared and reviewed with the program manager, contracting officer, or with higher management if the procurement is a major acquisition. The final review should include a briefing on the total RFP package. If other program offices or other Government agencies will be involved in the procurement, obtain their concurrence also.
PMBOK® Guide, 4th Edition
5.2 Define Scope
12.1.3.2 Contract Statement of Work
A specification list as shown in Table 11-1 is separately identified or called out as part of the statement of work. Specifications are used for man-hour, equipment, and material estimates. Small changes in a specification can cause large cost overruns.
Another reason for identifying the specifications is to make sure that there are no surprises for the customer downstream. The specifications should be the most current revision. It is not uncommon for a customer to hire outside agencies to evaluate the technical proposal and to make sure that the proper specifications are being used.
Specifications are, in fact, standards for pricing out a proposal. If specifications do not exist or are not necessary, then work standards should be included in the proposal. The work standards can also appear in the cost volume of the proposal. Labor justification backup sheets may or may not be included in the proposal, depending on RFP/RFQ (request for quotation) requirements.
Several years ago, a government agency queried contractors as to why some government programs were costing so much money. The main culprit turned out to be the specifications. Typical specifications contain twice as many pages as necessary, do not stress quality enough, are loaded with unnecessary designs and schematics, are difficult to read and update, and are obsolete before they are published. Streamlining existing specifications is a costly and time-consuming effort. The better alternative is to educate those people involved in specification preparation so that future specifications will be reasonably correct.
PMBOK® Guide 4th Edition
Chapter 6 Time Management
Project milestone schedules contain such information as:
Project start and end dates, if known, must be included. Other major milestones, such as review meetings, prototype available, procurement, testing, and so on, should also be identified. The last topic, data items, is often overlooked. There are two good reasons for preparing a separate schedule for data items. First, the separate schedule will indicate to line managers that personnel with writing skills may have to be assigned. Second, data items require direct-labor man-hours for writing, typing, editing, retyping, proofing, graphic arts, and reproduction. Many companies identify on the data item schedules the approximate number of pages per data item, and each data item is priced out at a cost per page, say $500/page. Pricing out data items separately often induces customers to require fewer reports.
The steps required to prepare a report, after the initial discovery work or collection of information, include:
Typically, 6–8 hours of work are required per page. At a burdened hourly rate of $80/hour, it is easy for the cost of documentation to become exorbitant.
PMBOK® Guide, 4th Edition
5.3 Create WBS
The successful accomplishment of both contract and corporate objectives requires a plan that defines all effort to be expended, assigns responsibility to a specially identified organizational element, and establishes schedules and budgets for the accomplishment of the work. The preparation of this plan is the responsibility of the program manager, who is assisted by the program team assigned in accordance with program management system directives. The detailed planning is also established in accordance with company budgeting policy before contractural efforts are initiated.
In planning a project, the project manager must structure the work into small elements that are:
The first major step in the planning process after project requirements definition is the development of the work breakdown structure (WBS). A WBS is a product-oriented family tree subdivision of the hardware, services, and data required to produce the end product. The WBS is structured in accordance with the way the work will be performed and reflects the way in which project costs and data will be summarized and eventually reported. Preparation of the WBS also considers other areas that require structured data, such as scheduling, configuration management, contract funding, and technical performance parameters. The WBS is the single most important element because it provides a common framework from which:
The work breakdown structure acts as a vehicle for breaking the work down into smaller elements, thus providing a greater probability that every major and minor activity will be accounted for. Although a variety of work breakdown structures exist, the most common is the six-level indented structure shown below:
Level 1 is the total program and is composed of a set of projects. The summation of the activities and costs associated with each project must equal the total program. Each project, however, can be broken down into tasks, where the summation of all tasks equals the summation of all projects, which, in turn, comprises the total program. The reason for this subdivision of effort is simply ease of control. Program management therefore becomes synonymous with the integration of activities, and the project manager acts as the integrator, using the work breakdown structure as the common framework.
Careful consideration must be given to the design and development of the WBS. From Figure 11-3, the work breakdown structure can be used to provide the basis for:
The upper three levels of the WBS are normally specified by the customer (if part of an RFP/RFQ) as the summary levels for reporting purposes. The lower levels are generated by the contractor for in-house control. Each level serves a vital purpose: Level 1 is generally used for the authorization and release of all work, budgets are prepared at level 2, and schedules are prepared at level 3. Certain characteristics can now be generalized for these levels:
PMBOK® Guide, 4th Edition
Figure 5-6 Sample WBS
Project managers normally manage at the top three levels of the WBS and prefer to provide status reports to management at these levels also. Some companies are trying to standardize reporting to management by requiring the top three levels of the WBS to be the same for every project, the only differences being in levels 4–6. For companies with a great deal of similarity among projects, this approach has merit. For most companies, however, the differences between projects make it almost impossible to standardize the top levels of the WBS.
The work package is the critical level for managing a work breakdown structure, as shown in Figure 11-4. However, it is possible that the actual management of the work packages is supervised and performed by the line managers with status reporting provided to the project manager at higher levels of the WBS.
Work packages are natural subdivisions of cost accounts and constitute the basic building blocks used by the contractor in planning, controlling, and measuring contract performance. A work package is simply a low-level task or job assignment. It describes the work to be accomplished by a specific performing organization or a group of cost centers and serves as a vehicle for monitoring and reporting progress of work. Documents that authorize and assign work to a performing organization are designated by various names throughout industry. “Work package” is the generic term used in the criteria to identify discrete tasks that have definable end results. Ideal work packages are 80 hours and 2–4 weeks. However, this may not be possible on large projects.
It is not necessary that work package documentation contain complete, stand-alone descriptions. Supplemental documentation may augment the work package descriptions. However, the work package descriptions must permit cost account managers and work package supervisors to understand and clearly distinguish one work package effort from another. In the review of work package documentation, it may be necessary to obtain explanations from personnel routinely involved in the work, rather than requiring the work package descriptions to be completely self-explanatory.
Short-term work packages may help evaluate accomplishments. Work packages should be natural subdivisions of effort planned according to the way the work will be done. However, when work packages are relatively short, little or no assessment of work-in-process is required and the evaluation of status is possible mainly on the basis of work package completions. The longer the work packages, the more difficult and subjective the work-in-process assessment becomes unless the packages are subdivided by objective indicators such as discrete milestones with preassigned budget values or completion percentages.
In setting up the work breakdown structure, tasks should:
For large projects, planning will be time phased at the work package level of the WBS. The work package has the following characteristics:
Table 11-2 shows a simple work breakdown structure with the associated numbering system following the work breakdown. The first number represents the total program (in this case, it is represented by 01), the second number represents the project, and the third number identifies the task. Therefore, number 01-03-00 represents project 3 of program 01, whereas 01-03-02 represents task 2 of project 3. This type of numbering system is not standard; each company may have its own system, depending on how costs are to be controlled.
The preparation of the work breakdown structure is not easy. The WBS is a communications tool, providing detailed information to different levels of management. If it does not contain enough levels, then the integration of activities may prove difficult. If too many levels exist, then unproductive time will be made to have the same number of levels for all projects, tasks, and so on. Each major work element should be considered by itself. Remember, the WBS establishes the number of required networks for cost control.
For many programs, the work breakdown structure is established by the customer. If the contractor is required to develop a WBS, then certain guidelines must be considered including:
Applying these guidelines serves only to identify the complexity of the program. These data must then be subdivided and released, together with detailed information, to the different levels of the organization. The WBS should follow specified criteria because, although preparation of the WBS is performed by the program office, the actual work is performed by the doers, not the planners. Both the doers and the planners must be in agreement as to what is expected. A sample listing of criteria for developing a work breakdown structure is shown below:
There is a common misconception that WBS decomposition is an easy task to perform. In the development of the WBS, the top three levels or management levels are usually rollup levels. Preparing templates at these levels is becoming common practice. However, at levels 4–6 of the WBS, templates may not be appropriate. There are reasons for this.
One solution to the above problems is to create “hammock” activities, which encompass several activities where exact cost identification cannot or may not be accurately determined. Some projects identify a “hammock” activity called management support (or project office), which includes overall project management, data items, management reserve, and possibly procurement. The advantage of this type of hammock activity is that the charge numbers are under the direct control of the project manager.
There is a common misconception that the typical dimensions of a work package are approximately 80 hours and less than two weeks to a month. Although this may be true on small projects, this would necessitate millions of work packages on large jobs and this may be impractical, even if line managers could control work packages of this size.
From a cost control point of view, cost analysis down to the fifth level is advantageous. However, it should be noted that the cost required to prepare cost analysis data to each lower level may increase exponentially, especially if the customer requires data to be presented in a specified format that is not part of the company's standard operating procedures. The level-5 work packages are normally for in-house control only. Some companies bill customers separately for each level of cost reporting below level 3.
The WBS can be subdivided into subobjectives with finer divisions of effort as we go lower into the WBS. By defining subobjectives, we add greater understanding and, it is hoped, clarity of action for those individuals who will be required to complete the objectives. Whenever work is structured, understood, easily identifiable, and within the capabilities of the individuals, there will almost always exist a high degree of confidence that the objective can be reached.
Work breakdown structures can be used to structure work for reaching such objectives as lowering cost, reducing absenteeism, improving morale, and lowering scrap factors. The lowest subdivision now becomes an end-item or subobjective, not necessarily a work package as described here. However, since we are describing project management, for the remainder of the text we will consider the lowest level as the work package.
Once the WBS is established and the program is “kicked off,” it becomes a very costly procedure to either add or delete activities, or change levels of reporting because of cost control. Many companies do not give careful forethought to the importance of a properly developed WBS, and ultimately they risk cost control problems downstream. One important use of the WBS is that it serves as a cost control standard for any future activities that may follow on or may just be similar. One common mistake made by management is the combining of direct support activities with administrative activities. For example, the department manager for manufacturing engineering may be required to provide administrative support (possibly by attending team meetings) throughout the duration of the program. If the administrative support is spread out over each of the projects, a false picture is obtained as to the actual hours needed to accomplish each project in the program. If one of the projects should be canceled, then the support man-hours for the total program would be reduced when, in fact, the administrative and support functions may be constant, regardless of the number of projects and tasks.
Quite often work breakdown structures accompanying customer RFPs contain much more scope of effort, as specified by the statement of work, than the existing funding will support. This is done intentionally by the customer in hopes that a contractor may be willing to “buy in.” If the contractor's price exceeds the customer's funding limitations, then the scope of effort must be reduced by eliminating activities from the WBS. By developing a separate project for administrative and indirect support activities, the customer can easily modify his costs by eliminating the direct support activities of the canceled effort.
Before we go on, there should be a brief discussion of the usefulness and applicability of the WBS system. Many companies and industries have been successful in managing programs without the use of work breakdown structures, especially on repetitive-type programs. As was the case with the SOW, there are also preparation guides for the WBS7:
PMBOK® Guide, 4th Edition
5.3.3.1 WBS
There are also checklists that can be used in the preparation of the WBS8:
On simple projects, the WBS can be constructed as a “tree diagram” (see Figure 11-5) or according to the logic flow. In Figure 11-5, the tree diagram can follow the work or even the organizational structure of the company (i.e., division, department, section, unit). The second method is to create a logic flow (see Figure 12-21) and cluster certain elements to represent tasks and projects. In the tree method, lower-level functional units may be assigned to one, and only one, work element, whereas in the logic flow method the lower-level functional units may serve several WBS elements.
A tendency exists to develop guidelines, policies, and procedures for project management, but not for the development of the WBS. Some companies have been marginally successful in developing a “generic” methodology for levels 1, 2, and 3 of the WBS to use on all projects. The differences appear in levels 4, 5, and 6.
The table below shows the three most common methods for structuring the WBS:
The flow method breaks the work down into systems and major subsystems. This method is well suited for projects less than two years in length. For longer projects, we use the life-cycle method, which is similar to the flow method. The organization method is used for projects that may be repetitive or require very little integration between functional units.
A prime responsibility of senior management (and possibly project sponsors) is the selection of projects. Most organizations have an established selection criteria, which can be subjective, objective, quantitative, qualitative, or simply a seat-of-the-pants guess. In any event, there should be a valid reason for selecting the project.
From a financial perspective, project selection is basically a two-part process. First, the organization will conduct a feasibility study to determine whether the project can be done. The second part is to perform a benefit-to-cost analysis to see whether the company should do it.
The purpose of the feasibility study is to validate that the project meets feasibility of cost, technological, safety, marketability, and ease of execution requirements. The company may use outside consultants or subject matter experts (SMEs) to assist in both feasibility studies and benefit-to-cost analyses. A project manager may not be assigned until after the feasibility study is completed.
As part of the feasibility process during project selection, senior management often solicits input from SMEs and lower-level managers through rating models. The rating models normally identify the business and/or technical criteria against which the ratings will be made. Figure 11-6 shows a scaling model for a single project. Figure 11-7 shows a checklist rating system to evaluate three projects at once. Figure 11-8 shows a scoring model for multiple projects using weighted averages.
If the project is deemed feasible and a good fit with the strategic plan, then the project is prioritized for development along with other projects. Once feasibility is determined, a benefit-to-cost analysis is performed to validate that the project will, if executed correctly, provide the required financial and nonfinancial benefits. Benefit-to-cost analyses require significantly more information to be scrutinized than is usually available during a feasibility study. This can be an expensive proposition.
PMBOK® Guide, 4th Edition
5.2.2 Scope Definition
5.2.2.2 Product Analysis
Estimating benefits and costs in a timely manner is very difficult. Benefits are often defined as:
Costs are significantly more difficult to quantify. The minimum costs that must be determined are those that specifically are used for comparison to the benefits. These include:
There must be careful documentation of all known constraints and assumptions that were made in developing the costs and the benefits. Unrealistic or unrecognized assumptions are often the cause of unrealistic benefits. The go or no-go decision to continue with a project could very well rest upon the validity of the assumptions.
Table 11-3 shows the major differences between feasibility studies and benefit-to-cost analyses.
Today, the project manager may end up participating in the project selection process. In Chapter 1, we discussed the new breed of project manager, namely a person that has excellent business skills as well as project management skills. These business skills now allow us to bring the project manager on board the project at the beginning of the initiation phase rather than at the end of the initiation phase because the project manager can now make a valuable contribution to the project selection process. The project manager can be of assistance during project selection by providing business case knowledge including:
Executives are responsible for selecting the project manager, and the person chosen should have planning expertise. Not all technical specialists are good planners. Likewise, some people that are excellent in execution have minimal planning skills. Executives must make sure that whomever is assigned as the project manager has both planning and execution skills. In addition, executives must take an active role during project planning activities especially if they also function as project sponsors.10
Executives must not arbitrarily set unrealistic milestones and then “force” line managers to fulfill them. Both project and line managers should try to adhere to unrealistic milestones, but if a line manager says he cannot, executives should comply because the line manager is supposedly the expert.
Executives should interface with project and line personnel during the planning stage in order to define the requirements and establish reasonable deadlines. Executives must realize that creating an unreasonable deadline may require the reestablishment of priorities, and, of course, changing priorities can push milestones backward.
Previously, we stated that perhaps the most important reason for structuring projects into life-cycle phases is to provide management with control of the critical decision points in order to:
On long-term projects, phasing can be overdone, resulting in extra costs and delays. To prevent this, many project-driven companies resort to other types of systems, such as a management cost and control system (MCCS). No program or project can be efficiently organized and managed without some form of management cost and control system. Figure 11-9 shows the five phases of a management cost and control system. The first phase constitutes the planning cycle, and the next four phases identify the operating cycle.
Figure 11-10 shows the activities included in the planning cycle. The work breakdown structure serves as the initial control from which all planning emanates. The WBS acts as a vital artery for communications and operations in all phases. A comprehensive analysis of management cost and control systems is presented in Chapter 15.
PMBOK® Guide, 4th Edition
4.3.2 Direct and Manage Project Execution
After receipt of a contract, some form of authorization is needed before work can begin, even in the planning stage. Both work authorization and work planning authorization are used to release funds, but for different purposes. Work planning authorization releases funds (primarily for functional management) so that scheduling, costs, budgets, and all other types of plans can be prepared prior to the release of operational cycle funds, which hereafter shall be referred to simply as work authorization. Both forms of authorization require the same paperwork. In many companies this work authorization is identified as a subdivided work description (SWD), which is a narrative description of the effort to be performed by the cost center (division-level minimum). This package establishes the work to be performed, the period of performance, and possibly the maximum number of hours available. The SWD is multipurpose in that it can be used to release contract funds, authorize planning, describe activities as identified in the WBS, and, last but not least, release work.
The SWD is one of the key elements in the planning of a program as shown in Figure 11-10. Contract control and administration releases the contract funds by issuing a SWD, which sets forth general contractual requirements and authorizes program management to proceed. Program management issues the SWD to set forth the contractual guidelines and requirements for the functional units. The SWD specifies how the work will be performed, which functional organizations will be involved, and who has what specific responsibilities, and authorizes the utilization of resources within a given time period.
The SWD authorizes both the program team and functional management to begin work. As shown in Figure 11-10, the SWD provides direct input to Phase II of the MCCS. Phase I and Phase II can and do operate simultaneously because it is generally impossible for program office personnel to establish plans, procedures, and schedules without input from the functional units.
The subdivided work description package is used by the operating organizations to further subdivide the effort defined by the WBS into small segments or work packages.
Many people contend that if the data in the work authorization document are different from what was originally defined in the proposal, the project is in trouble right at the start. This may not be the case, because most projects are priced out assuming “unlimited” resources, whereas the hours and dollars in the work authorization document are based upon “limited” resources. This situation is common for companies that thrive on competitive bidding.
No matter how hard we try, planning is not perfect, and sometimes plans fail. Typical reasons include:
Why do these situations occur? If corporate goals are not understood, it is because corporate executives have been negligent in providing the necessary strategic information and feedback. If a plan fails because of extreme optimism, then the responsibility lies with both the project and line managers for not assessing risk. Project managers should ask the line managers if the estimates are optimistic or pessimistic, and expect an honest answer. Erroneous financial estimates are the responsibility of the line manager. If the project fails because of a poor definition of the requirements, then the project manager is totally at fault.
Sometimes project plans fail because simple details are forgotten or overlooked. Examples of this might be:
Sometimes plans fail because the project manager “bites off more than he can chew,” and then something happens, such as his becoming ill. Many projects have failed because the project manager was the only one who knew what was going on and then got sick.
PMBOK® Guide, 4th Edition
4.6 Close Projects
There are always situations in which projects have to be stopped. Nine reasons for stopping are:
Today most of the reasons why projects are not completed on time and within cost are behavioral rather than quantitative. They include:
The last item appears to be the cause of the first three items in many situations.
Once the reasons for cancellation are defined, the next problem concerns how to stop the project. Some of the ways are:
There are three major problem areas to be considered in stopping projects:
PMBOK® Guide, 4th Edition
4.4 Monitor and Control Project Work
By definition, projects (and even life cycle phases) have an end point. Closing out is a very important phase in the project life cycle, which should follow particular disciplines and procedures with the objective of:
Although most project managers are completely cognizant of the necessity for proper planning for project start-up, many project managers neglect planning for project termination. Planning for project termination includes:
Project success or failure often depends on management's ability to handle personnel issues properly during this final phase. If job assignments beyond the current project look undesirable or uncertain to project team members, a great deal of anxiety and conflict may develop that diverts needed energy to job hunting, foot dragging, or even sabotage. Project personnel may engage in job searches on their own and may leave the project prematurely. This creates a glaring void that is often difficult to patch.
Given business realities, it is difficult to transfer project personnel under ideal conditions. The following suggestions may increase organizational effectiveness and minimize personal stress when closing out a project:
The scheduling of activities is the first major requirement of the program office after program go-ahead. The program office normally assumes full responsibility for activity scheduling if the activity is not too complex. For large programs, functional management input is required before scheduling can be completed. Depending on program size and contractual requirements, the program office may have a staff member whose sole responsibility is to continuously develop and update activity schedules to track program work. The resulting information is supplied to program office personnel, functional management, team members, and the customer.
Activity scheduling is probably the single most important tool for determining how company resources should be integrated. Activity schedules are invaluable for projecting time-phased resource utilization requirements, providing a basis for visually tracking performance and estimating costs. The schedules serve as master plans from which both the customer and management have an up-to-date picture of operations.
Certain guidelines should be followed in the preparation of schedules, regardless of the projected use or complexity:
Although these four guidelines relate to schedule preparation, they do not define how complex the schedules should be. Before preparing schedules, three questions should be considered:
Most organizations develop multiple schedules: summary schedules for management and planners and detailed schedules for the doers and lower-level control. The detailed schedules may be strictly for interdepartmental activities. Program management must approve all schedules down through the first three levels of the work breakdown structure. For lower-level schedules (i.e., detailed interdepartmental), program management may or may not request a sign of approval.
One of the most difficult problems to identify in schedules is a hedge position. A hedge position is a situation in which the contractor may not be able to meet a customer's milestone date without incurring a risk, or may not be able to meet activity requirements following a milestone date because of contractual requirements. To illustrate a common hedge position, consider Example 11–1 below.
Example 11–1. Condor Corporation is currently working on a project that has three phases: design, development, and qualification of a certain component. Contractual requirements with the customer specify that no components will be fabricated for the development phase until the design review meeting is held following the design phase. Condor has determined that if it does not begin component fabrication prior to the design review meeting, then the second and third phases will slip. Condor is willing to accept the risk that should specifications be unacceptable during the design review meeting, the costs associated with preauthorization of fabrication will be incurred. How should this be shown on a schedule? (The problems associated with performing unauthorized work are not being considered here.)
The solution is not easy. Condor must show on the master production schedule that component fabrication will begin early, at the contractor's risk. This should be followed up by a contractual letter in which both the customer and contractor understand the risks and implications.
Detailed schedules are prepared for almost every activity. It is the responsibility of the program office to marry all of the detailed schedules into one master schedule to verify that all activities can be completed as planned. The preparation sequence for schedules (and also for program plans) is shown in Figure 11-11. The program office submits a request for detailed schedules to the functional managers and the functional managers prepare summary schedules, detailed schedules, and, if time permits, interdepartmental schedules. Each functional manager then reviews his schedules with the program office. The program office, together with the functional program team members, integrates all of the plans and schedules and verifies that all contractual dates can be met.
Before the schedules are submitted to publications, rough drafts of each schedule and plan should be reviewed with the customer. This procedure accomplishes the following:
After the document is published, it should be distributed to all program office personnel, functional team members, functional management, and the customer. Examples of detailed schedules are shown in Chapter 13.
In addition to the detailed schedules, the program office, with input provided by functional management, must develop organization charts. The charts show who has responsibility for each activity and display the formal (and often the informal) lines of communication. Examples were shown in Section 4.11.
The program office may also establish linear responsibility charts (LRCs). In spite of the best attempts by management, many functions in an organization may overlap between functional units. Also, management might wish to have the responsibility for a certain activity given to a functional unit that normally would not have that responsibility. This is a common occurrence on short-duration programs where management desires to cut costs and red tape.
Project personnel should keep in mind why the schedule was developed. The primary objective is usually to coordinate activities to complete the project with the:
There are also secondary objectives of scheduling:
Large projects, especially long-term efforts, may require a “war room.” War rooms generally have only one door and no windows. All of the walls are covered with large schedules, perhaps printed on blueprint paper, and each wall could have numerous sliding panels. The schedules and charts on each wall could be updated on a daily basis. The room would be used for customer briefings, team meetings, and any other activities related specifically to this project.
The release of the planning SWD, as shown in Figure 11-10, authorizes the manufacturing units to prepare a master production schedule from which detailed analysis of the utilization of company resources can be seen and tracked.
Master production scheduling is not a new concept. Earliest material control systems used a “quarterly ordering system” to produce a master production schedule (MPS) for plant production. This system uses customer order backlogs to develop a production plan over a three-month period. The production plan is then exploded manually to determine what parts must be purchased or manufactured at the proper time. However, rapidly changing customer requirements and fluctuating lead times, combined with a slow response to these changes, can result in the disruption of master production scheduling.11
Master Production Schedule Definition
A master production schedule is a statement of what will be made, how many units will be made, and when they will be made. It is a production plan, not a sales plan. The MPS considers the total demand on a plant's resources, including finished product sales, spare (repair) part needs, and interplant needs. The MPS must also consider the capacity of the plant and the requirements imposed on vendors. Provisions are made in the overall plan for each manufacturing facility's operation. All planning for materials, manpower, plant, equipment, and financing for the facility is driven by the master production schedule.
Objectives of the MPS
Objectives of master production scheduling are:
The development of a master production schedule is a very important step in a planning cycle. Master production schedules directly tie together personnel, materials, equipment, and facilities, as shown in Figure 11-12. Master production schedules also identify key dates to the customer, should he wish to visit the contractor during specific operational periods.
PMBOK® Guide, 4th Edition
Chapter 5 Project Scope Management
Chapter 4 Integration Management
3.2 Planning Process Group
A project plan is fundamental to the success of any project. For large and often complex projects, customers may require a project plan that documents all activities within the program. The project plan then serves as a guideline for the lifetime of the project and may be revised as often as once a month, depending on the circumstances and the type of project (i.e., research and development projects require more revisions to the project plan than manufacturing or construction projects). The project plan provides the following framework:
Development of a project plan can be time-consuming and costly. All levels of the organization participate. The upper levels provide summary information, and the lower levels provide the details. The project plan, like activity schedules, does not preclude departments from developing their own plans.
The project plan must identify how the company resources will be integrated. The process is similar to the sequence of events for schedule preparation, shown in Figure 11-11. Since the project plan must explain the events in Figure 11-11, additional iterations are required, which can cause changes in a project. This can be seen in Figure 11-13.
The project plan is a standard from which performance can be measured by the customer and the project and functional managers. The plan serves as a cookbook by answering these questions for all personnel identified with the project:
The answers to these questions force both the contractor and the customer to take a hard look at:
The project plan is more than just a set of instructions. It is an attempt to eliminate crisis by preventing anything from “falling through the cracks.” The plan is documented and approved by both the customer and the contractor to determine what data, if any, are missing and the probable resulting effect. As the project matures, the project plan is revised to account for new or missing data. The most common reasons for revising a plan are:
The makeup of the project plan may vary from contractor to contractor.12 Most project plans can be subdivided into four main sections: introduction, summary and conclusions, management, and technical. The complexity of the information is usually up to the discretion of the contractor, provided that customer requirements, as may be specified in the statement of work, are satisfied.
The introductory section contains the definition of the project and the major parts involved. If the project follows another, or is an outgrowth of similar activities, this is indicated, together with a brief summary of the background and history behind the project.
The summary and conclusion section identifies the targets and objectives of the project and includes the necessary “lip service” on how successful the project will be and how all problems can be overcome. This section must also include the project master schedule showing how all projects and activities are related. The total project master schedule should include the following:
The summary and conclusion chapter is usually the second section in the project plan so that upper-level customer management can have a complete overview of the project without having to search through the technical information.
The management section of the project plan contains procedures, charts, and schedules as follows:
Situations exist in which the management section may be omitted from the proposal. For a follow-up program, the customer may not require this section if management's positions are unchanged. Management sections are also not required if the management information was previously provided in the proposal or if the customer and contractor have continuous business dealings.
The technical section may include as much as 75 to 90 percent of the program plan, especially if the effort includes research and development, and may require constant updating as the project matures. The following items can be included as part of the technical section:
The project plan, as used here, contains a description of all phases of the project. For many projects, especially large ones, detailed planning is required for all major events and activities. Table 11-4 identifies the type of individual plans that may be required in place of a (total) project plan. These are often called subsidiary plans.
The project plan, once agreed on by the contractor and customer, is then used to provide project direction. This is shown in Figure 11-14. If the project plan is written clearly, then any functional manager or supervisor should be able to identify what is expected of him. The project plan should be distributed to each member of the project team, all functional managers and supervisors interfacing with the project, and all key functional personnel.
One final note need be mentioned concerning the legality of the project plan. The project plan may be specified contractually to satisfy certain requirements as identified in the customer's statement of work. The contractor retains the right to decide how to accomplish this, unless, of course, this is also identified in the SOW. If the SOW specifies that quality assurance testing will be accomplished on fifteen end-items from the production line, then fifteen is the minimum number that must be tested. The project plan may show that twenty-five items are to be tested. If the contractor develops cost overrun problems, he may wish to revert to the SOW and test only fifteen items. Contractually, he may do this without informing the customer. In most cases, however, the customer is notified, and the project is revised.
PMBOK® Guide, 4th Edition
Chapter 5 Project Scope Management
Chapter 4 Integration Management
3.2 Planning Process Group
The difference between the good project manager and the poor project manager is often described in one word: planning. Project planning involves planning for:
The first two items involve the quantitative aspects of planning. Planning for project administration includes the development of the linear responsibility chart.
Although each project manager has the authority and responsibility to establish project policies and procedures, they must fall within the general guidelines established by top management.
Linear responsibility charts can result from customer-imposed requirements above and beyond normal operations. For example, the customer may require as part of his quality control requirements that a specific engineer supervise and approve all testing of a certain item, or that another individual approve all data released to the customer over and above program office approval. Customer requirements similar to those identified above require LRCs and can cause disruptions and conflicts within an organization.
Several key factors affect the delegation of authority and responsibility both from upper-level management to project management, and from project management to functional management. These key factors include:
Once agreement has been reached on the project manager's authority and responsibility, the results may be documented to delineate that role regarding:
Documenting the project manager's authority is necessary in some situations because:
Although documenting project authority is undesirable, it may be necessary, especially if project initiation and planning require a formal project chart. In such a case, a letter such as that shown in Table 11-5 may suffice.
Power and authority are often discussed as though they go hand in hand. Authority comes from people above you, perhaps by delegation, whereas power comes from people below you. You can have authority without power or power without authority.
In a traditional organizational structure, most individuals maintain position power. The higher up you sit, the more power you have. But in project management, the reporting level of the project might be irrelevant, especially if a project sponsor exists. In project management, the project manager's power base emanates from his
The last item is usually preferred. If the project manager is regarded as a sound decision-maker, then the employees normally give the project manager a great deal of power over them.
Leadership styles refer to the interpersonal influence modes that a project manager can use. Project managers may have to use several different leadership styles, depending on the makeup of the project personnel. Conflict management is important because if the project manager can predict what conflicts will occur and when they are most likely to occur, he may be able to plan for the resolution of the conflicts through project administration.
Figure 11-15 shows the complete project planning phase for the quantitative portions. The object, of course, is to develop a project plan that shows complete distribution of resources and the corresponding costs. The figure represents an iterative process. The project manager begins with a coarse (arrow diagram) network, and then decides on the work breakdown structure. The WBS is essential to the arrow diagram and should be constructed so that reporting elements and levels are easily identifiable. Eventually, there will be an arrow diagram and detailed chart for each element in the WBS. If there is too much detail, the project manager can refine the diagram by combining all logic into one plan and can then decide on the work assignments. There is a risk here that, by condensing the diagrams as much as possible, there may be a loss of clarity. As shown in Figure 11-15, all the charts and schedules can be integrated into one summary-level figure. This can be accomplished at each WBS level until the desired plan is achieved.
PMBOK® Guide, 4th Edition
4.1 Develop Project Charter
PMBOK® Guide, 4th Edition
Chapter 4 Integration Manangement
Finally, project, line, and executive management must analyze other internal and external variables before finalizing these schedules. These variables include:
In small companies and projects, certain items in Figure 11-15 may be omitted, such as the LRCs.
PMBOK® Guide, 4th Edition
4.1 Develop Project Charter
The original concept behind the project charter was to document the project manager's authority and responsibility, especially for projects implemented away from the home office. Today, the project charter is more of an internal legal document identifying to the line managers and their personnel the project manager's authority and responsibility and the management- and/or customer-approved scope of the project.
Theoretically, the sponsor prepares the charter and affixes his/her signature, but in reality, the project manager may prepare it for the sponsor's signature. At a minimum, the charter should include:
The PMBOK® Guide provides a framework for the project charter. What is somewhat unfortunate is that every company seems to have its own idea of what should be included in a charter. The contents of a charter are often dependent upon where in the evolution and life cycle of a project the charter is prepared. (See Advanced Project Management: Best Practices on Implementation by Harold Kerzner, John Wiley & Sons, New York, 2004, pp. 101–102, 120, 629–630.) Some companies such as Computer Associates use both a full charter (closely aligned to the PMBOK® Guide) and an abbreviated charter based upon the size and complexity of the project.
The charter is a “legal” agreement between the project manager and the company. Some companies supplement the charter with a “contract” that functions as an agreement between the project and the line organizations.
Some companies have converted the charter into a highly detailed document containing:
When the project charter contains a scope baseline and management plan, the project charter may function as the project plan. This is not really an effective use of the charter, but it may be acceptable on certain types of projects for internal customers.
PMBOK® Guide, 4th Edition
4.5 Integrated Change Control
Because the planning phase provides the fundamental guidelines for the remainder of the project, careful management control must be established. In addition, since planning is an ongoing activity for a variety of different programs, management guidelines must be established on a company-wide basis in order to achieve unity and coherence.
All functional organizations and individuals working directly or indirectly on a program are responsible for identifying, to the project manager, scheduling and planning problems that require corrective action during both the planning cycle and the operating cycle. The program manager bears the ultimate and final responsibility for identifying requirements for corrective actions. Management policies and directives are written specifically to assist the program manager in defining the requirements. Without clear definitions during the planning phase, many projects run off in a variety of directions.
Many companies establish planning and scheduling management policies for the project and functional managers, as well as a brief description of how they should interface. Table 11-6 identifies a typical management policy for planning and requirements, and Table 11-7 describes scheduling management policies.
PMBOK® Guide, 4th Edition
1.6 Interpersonal Skills
The utilization of management controls, such as those outlined in Section 11.25, does not necessarily guarantee successful project planning. Good project planning, as well as other project functions, requires a good working relationship between the project and line managers. At this interface:
Project managers may be able to tell line managers “how” and “where,” provided that the information appears in the SOW as a requirement for the project. Even then, the line manager can take exception based on his technical expertise.
Figures 11-16 and 11-17 show what can happen when project managers overstep their bounds. In Figure 11-16, the manufacturing manager built a brick wall to keep the project managers away from his personnel because the project managers were telling his line people how to do their job. In Figure 11-17, the subproject managers (for simplicity's sake, equivalent to project engineers) would have, as their career path, promotions to assistant project managers (APMs). Unfortunately, the APMs still felt that they were technically competent enough to give technical direction, and this created havoc for the engineering managers.
The simplest solution to all of these problems is for the project manager to provide the technical direction through the line managers. After all, the line managers are supposedly the true technical experts.
PMBOK® Guide, 4th Edition
2.1 Characteristics of the Project Life Cycle
Sometimes, no matter how well we plan, something happens that causes havoc on the project. Such is the case when either the customer or management changes the project's constraints. Consider Figure 11-18 and let us assume that the execution time for the construction of the project is one year. To prepare the working drawings and specifications down through level 5 of the WBS would require an additional 35 percent of the expected execution time, and if a feasibility study is required, then an additional 40 percent will be added on. In other words, if the execution phase of the project is one year, then the entire project is almost two years.
Now, let us assume that management wishes to keep the end date fixed but the start date is delayed because of lack of adequate funding. How can this be accomplished without sacrificing the quality? The answer is to fast-track the project. Fast-tracking a project means that activities that are normally done in series are done in parallel. An example of this is when construction begins before detail design is completed. (See Chapter 2, Table 2-5 on life-cycle phases.)
Fast-tracking a job can accelerate the schedule but requires that additional risks be taken. If the risks materialize, then either the end date will slip or expensive rework will be needed. Almost all project-driven companies fast-track projects, but there is danger when fast-tracking becomes a way of life.
PMBOK® Guide, 4th Edition
4.5 Integrated Change Control
A critical tool employed by a project manager is configuration management or configuration change control. As projects progress downstream through the various life-cycle phases, the cost of engineering changes can grow boundlessly. It is not uncommon for companies to bid on proposals at 40 percent below their own cost hoping to make up the difference downstream with engineering changes. It is also quite common for executives to “encourage” project managers to seek out engineering changes because of their profitability.
Configuration management is a control technique, through an orderly process, for formal review and approval of configuration changes. If properly implemented, configuration management provides
At a minimum, the configuration control committee should include representation from the customer, contractor, and line group initiating the change. Discussions should answer the following questions:
Changes cost money. Therefore, it is imperative that configuration management be implemented correctly. The following steps can enhance the implementation process:
Effective configuration control pleases both customer and contractor. Overall benefits include:
As a final note, it must be understood that configuration control, as used here, is not a replacement for design review meetings or customer interface meetings. These meetings are still an integral part of all projects.
Enterprise project management methodologies can enhance the project planning process as well as providing some degree of standardization and consistency.
Companies have come to the realization that enterprise project management methodologies work best if the methodology is based upon templates rather than rigid policies and procedures. The International Institute for Learning has created a Unified Project Management Methodology (UPMM™) with templates categorized according to the PMBOK® Guide Areas of Knowledge13:
Communication
Project Charter
Project Procedures Document
Project Change Requests Log
Project Status Report
PM Quality Assurance Report
Procurement Management Summary
Project Issues Log
Project Management Plan
Project Performance Report
Cost
Project Schedule
Risk Response Plan and Register
Work Breakdown Structure (WBS)
Work Package
Cost Estimates Document
Project Budget
Project Budget Checklist
Human Resources
Project Charter
Work Breakdown Structure (WBS)
Communications Management Plan
Project Organization Chart
Project Team Directory
Responsibility Assignment Matrix (RAM)
Project Management Plan
Project Procedures Document
Kickoff Meeting Checklist
Project Team Performance Assessment
Project Manager Performance Assessment
Integration
Project Procedures Overview
Project Proposal
Communications Management Plan
Project Budget
Project Procedures Document
Project Schedule
Responsibility Assignment Matrix (RAM)
Risk Response Plan and Register
Scope Statement
Work Breakdown Structure (WBS)
Project Management Plan
Project Change Requests Log
Project Issues Log
Project Management Plan Changes Log
Project Performance Report
Lessons Learned Document
Project Performance Feedback
Product Acceptance Document
Project Charter
Closing Process Assessment Checklist
Project Archives Report
Procurement
Project Charter
Scope Statement
Work Breakdown Structure (WBS)
Procurement Plan
Procurement Planning Checklist
Procurement Statement of Work (SOW)
Request for Proposal Document Outline
Project Change Requests Log
Contract Formation Checklist
Procurement Management Summary
Quality
Project Charter
Project Procedures Overview
Work Quality Plan
Project Management Plan
Work Breakdown Structure (WBS)
PM Quality Assurance Report
Lessons Learned Document
Project Performance Feedback
Project Team Performance Assessment
PM Process Improvement Document
Risk
Procurement Plan
Project Charter
Work Breakdown Structure (WBS)
Risk Response Plan and Register
Scope
Project Scope Statement
Work Breakdown Structure (WBS)
Work Package
Project Charter
Time
Activity Duration Estimating Worksheet
Cost Estimates Document
Risk Response Plan and Register Medium
Work Breakdown Structure (WBS)
Work Package
Project Schedule
Project Schedule Review Checklist
In recent years, the necessity for a structured independent review of various parts of a business, including projects, has taken on a more important role. Part of this can be attributed to the Sarbanes–Oxley law compliance requirements. These independent reviews are audits that focus on either discovery or decision-making. The audits can be scheduled or random and can be performed by in-house personnel or external examiners.
There are several types of audits. Some common types include:
This section is applicable as a review of the principles to support the knowledge areas and domain groups in the PMBOK® Guide. This chapter addresses:
Understanding the following principles is beneficial if the reader is using this text to study for the PMP® Certification Exam:
In Appendix C, the following Dorale Products mini–case studies are applicable:
The following multiple-choice questions will be helpful in reviewing the principles of this chapter:
Answer questions 5–8 using the work breakdown structure (WBS) shown below (numbers in parentheses show the dollar value for a particular element):
11–1 Under what conditions would each of the following either not be available or not be necessary for initial planning?
11–2 What planning steps should precede total program scheduling? What steps are necessary?
11–3 How does a project manager determine how complex to make a program plan or how many schedules to include?
11–4 Can objectives always be identified and scheduled?
11–5 Can a WBS always be established for attaining an objective?
11–6 Who determines the work necessary to accomplish an objective?
11–7 What roles does a functional manager play in establishing the first three levels of the WBS?
11–8 Should the length of a program have an impact on whether to set up a separate project or task for administrative support? How about for raw materials?
11–9 Is it possible for the WBS to be designed so that resource allocation is easier to identify?
11–10 If the scope of effort of a project changes during execution of activities, what should be the role of the functional manager?
11–11 What types of conflicts can occur during the planning cycle, and what modes should be used for their resolution?
11–12 What would be the effectiveness of Figure 11-3 if the work packages were replaced by tasks?
11–13 Under what situations or projects would work planning authorization not be necessary?
11–14 On what types of projects could hedge positions be easily identified on a schedule?
11–15 Can activities 5 and 6 of Figure 11-11 be eliminated? What risks does a project manager incur if these activities are eliminated?
11–16 Where in the planning cycle should responsibility charts be prepared? Can you identify this point in Figure 11-11?
11–17 For each one of the decision points in Figure 11-13, who makes the decision? Who must input information? What is the role of the functional manager and the functional team member? Where are strategic variables identified?
11–18 Consider a project in which all project planning is performed by a group. After all planning is completed, including the program plan and schedules, a project manager is selected. Is there anything wrong with this arrangement? Can it work?
11–19 How do the customer and contractor know if each one completely understands the statement of work, the work breakdown structure, and the program plan?
11–20 Should a good project plan formulate methods for anticipating problems?
11–21 Some project managers schedule staff meetings as the primary means for planning and control. Do you agree with this philosophy?
11–22 Paul Mali (Management by Objectives, New York: John Wiley, 1972, p. 12) defines MBO as a five-step process:
How can the work breakdown structure be used to accomplish each of the above steps? Would you agree or disagree that the more levels the WBS contains, the greater the understanding and clarity of those steps necessary to complete the objectives?
11–23 Many textbooks on management state that you should plan like you work, by doing one thing at a time. Can this same practice be applied at the project level, or must a project manager plan all activities at once?
11–24 Is it true that project managers set the milestones and functional managers hope they can meet them?
11–25 You have been asked to develop a work breakdown structure for a project. How should you go about accomplishing this? Should the WBS be time-phased, department-phased, division-phased, or some combination?
11–26 You have just been instructed to develop a schedule for introducing a new product into the marketplace. Below are the elements that must appear in your schedule. Arrange these elements into a work breakdown structure (down through level 3), and then draw the arrow diagram. You may feel free to add additional topics as necessary.
|
(* Approvals and review meetings can appear several times.)
11–27 Once a project begins, a good project manager will set up checkpoints. How should this be accomplished? Will the duration of the project matter? Can checkpoints be built into a schedule? If so, how should they be identified?
11–28 Detailed schedules (through WBS levels 3, 4, 5, . . .) are prepared by the functional managers. Should these schedules be shown to the customer?
11–29 The project start-up phase is complete, and you are now ready to finalize the operational plan. Below are six steps that are often part of the finalization procedure. Place them in the appropriate order.
11–30 Below are seven factors that must be considered before finalizing a schedule. Explain how a base case schedule can change as a result of each of these:
11–31 You are the project manager of a nine-month effort. You are now in the fifth month of the project and are more than two weeks behind schedule, with very little hope of catching up. The dam breaks in a town near you, and massive flooding and mudslides take place. Fifteen of your key functional people request to take off three days from the following week to help fellow church members dig out. Their functional managers, bless their hearts, have left the entire decision up to you. Should you let them go?
11–32 Once the functional manager and project manager agree on a project schedule, who is responsible for getting the work performed? Who is accountable for getting the work performed? Why the difference, if any?
11–33 Discuss the validity of the following two statements on authority:
11–34 Below are twelve instructions. Which are best described as planning, and which are best described as forecasting?
11–35 A major utility company has a planning group that prepares budgets (with the help of functional groups) and selects the projects to be completed within a given time period. You are assigned as a project manager on one of the projects and find out that it should have been started “last month” in order to meet the completion date. What can you, the project manager, do about this? Should you delay the start of the project to replan the work?
11–36 The director of project management calls you into his office and informs you that one of your fellow project managers has had a severe heart attack midway through a project. You will be taking over his project, which is well behind schedule and overrunning costs. The director of project management then “orders” you to complete the project within time and cost. How do you propose to do it? Where do you start? Should you shut down the project to replan it?
11–37 Planning is often described as establishing, budgeting, scheduling, and resource allocation. Identify these four elements in Figure 11-1.
11–38 A company is undertaking a large development project that requires that a massive “blueprint design tree” be developed. What kind of WBS outline would be best to minimize the impact of having two systems, one for blueprints and one for WBS work?
11–39 A company allows each line organization to perform its own procurement activities (through a centralized procurement office) as long as the procurement funds have been allocated during the project planning phase. The project office does not sign off on these functional procurement requisitions and may not even know about them. Can this system work effectively? If so, under what conditions?
11–40 As part of a feasibility study, you are asked to prepare, with the assistance of functional managers, a schedule and cost summary for a project that will occur three years downstream, if the project is approved at all. Suppose that three years downstream the project is approved. How does the project manager get functional managers to accept the schedule and cost summary that they themselves prepared three years before?
11–41 “Expecting trouble.” Good project managers know what type of trouble can occur at the various stages in the development of a project. The activities in the numbered list below indicate the various stages of a project. The lettered list that follows identifies major problems. For each project stage, select and list all of those problems that are applicable.
11–42 Table 11-8 identifies twenty-six steps in project planning and control. Below is a description of each of the twenty-six steps. Using this information, fill in columns 1 and 2 (column 2 is a group response). After your instructor provides you with column 3, fill in the remainder of the table.
11–43 Consider the work breakdown structure shown in Figure 11-19. Can the project be managed from this one sheet of paper assuming that, at the end of each month, the project manager also receives a cost and percent-complete summary?
11–44 During 1992 and 1993, General Motors saved over $2 billion due to the cost-cutting efforts of Mr. Lopez. Rumors spread throughout the auto industry that General Motors was considering a plan to offer subcontractors ten-year contracts in exchange for a 20 percent cost reduction.
These long-term contracts provided both GM and the subcontractors the chance to develop an informal project management relationship based on trust, effective communications, and minimum documentation requirements.
11–45 During the recession of 1989–1993, the auto industry began taking extreme cost-cutting measures by downsizing its organizations. The downsizing efforts created project management problems for the project engineers in the manufacturing plants. With fewer resources available, more and more of the work had to be outsourced, primarily for services. The manufacturing plants had years of experience in negotiations for parts, but limited experience in negotiations for services. As a result, the service contracts were drastically overrun with engineering changes and schedule slippages. What is the real problem and your recommendation for a solution?
11–46 When to bring the project manager on board has always been a problem. For each of the following situations, identify the advantages and disadvantages.
*Case Study also appears in Workbook.
1. See A Guide to the Project Management Body of Knowledge®, 4th ed., 2008, Figure 4-4.
2. R. D. Stewart, Cost Estimating (New York: Wiley, 1982), pp. 56–57.
3. Adapted from Statement of Work Handbook NHB5600.2, National Aeronautics and Space Administration, February 1975.
4. See note 3.
5. See note 3.
6. Statement of Work Handbook NHB5600.2, National Aeronautics and Space Administration, February 1975.
7. Source: Handbook for Preparation of Work Breakdown Structures, NHB5610.1, National Aeronautics and Space Administration, February 1975.
8. See note 7.
9. For additional factors that can influence project selection decision making, see J. R. Meredith and S. J. Mantel, Jr., Project Management, 3rd ed., (New York: Wiley, 1995), pp. 44–46.
10. Although this section is called “The Role of the Executive in Planning,” it also applies to line management if project sponsorship is pushed down to the middle-management level or lower. This is quite common in highly mature project management organizations where senior management has sufficient faith in line management's ability to serve as project sponsors.
11. The master production schedule is being discussed here because of its importance in the planning cycle. The MPS cannot be fully utilized without effective inventory control procedures.
12. Cleland and King define fourteen subsections for a program plan. This detail appears more applicable to the technical and management volumes of a proposal. They do, however, provide a more detailed picture than presented here. See David I. Cleland and William R. King, Systems Analysis and Project Management (New York: McGraw-Hill, 1975), pp. 371–380.
13. Unified Project Management Methodology (UPMM™) is registered, copyrighted, and owned by International Institute for Learning, Inc., © 2005; reproduced by permission.
18.222.196.175