Project Planning Techniques

Parviz F. Rad, PhD, PE, CCE, PMP

Vittal S. Anantatmula, DSc, CCE

About the Authors

Parviz F. Rad, PhD, PE, CCE, PMP, is an independent project management consultant. He holds an MSc from Ohio State University and a PhD from Massachusetts Institute of Technology. He has over 35 years of professional experience, during which he has served in governmental, industrial, and academic capacities. He has participated in project management activities and in the development and enhancement of quantitative tools in project management in a multitude of disciplines, including software development, construction, and pharmaceutical research. He has authored and coauthored more than 60 publications in the areas of engineering and project management. Dr. Rad is the past Editor of the Project Management Journal.

Vittal S. Anantatmula, DSc, CCE, is the director of the graduate degree program in project management, School of Business, The George Washington University. He has more than eight years of academic experience in research, teaching, and administration. Dr. Anantatmula previously worked in the petroleum and power industries as an electrical engineer and project manager. As a consultant, he worked with the World Bank, Arthur Andersen, and other private international consulting firms. He has authored numerous publications and has been an invited speaker at several conferences and meetings. Dr. Anantatmula is a certified cost engineer and his academic qualifications include Doctor of Science in engineering management from The George Washington University, MS (Engineering Management), MBA, and BE in Electrical Engineering.

1 Introduction

Project planning is the art and science of using the historical data, archived information, personal expertise, institutional memory, organizational knowledge, and project scope statement to predict a project’s resource expenditures, total cost, and duration. Project planning also includes developing guidelines for ensuring the quality of the deliverable, responding to adverse events, and dealing with the inevitable changes to the project plan.

To arrive at an estimate of the project’s cost and duration, the project manager will identify the various constituent physical elements and related activities that are necessary to meet the project’s objectives. Based on this information, the project manager will estimate the amount of resources and length of time necessary for each of the constituent elements of the project.

The estimate of the cost starts with the estimate of resources, which is more valuable to the project team. Then the resource estimate is reduced to cost, because total cost usually is more important to the client. The project manager then develops the estimate by summing the estimate of resources for these elements. Next, the project manager computes the elemental cost and the total cost for the project. He or she develops a schedule network depicting the sequential relationships between the project elements. Then, using this network, the project manager calculates the project duration.

The information necessary for a comprehensive and accurate set of plans includes details of the objective, scope, quality, and delivery date. When the project is conceived, the first estimates of cost and duration are inaccurate because very little information is available about the expected deliverables, the project team, and the project environment. As the project evolves and more information becomes available, the estimate can be fine-tuned.

The evolving planning documents also might include increasing details about the procedures that will be used when implementing the project. Thus, the project plans should be updated frequently, even if there are no changes in scope. Additionally, changes in project plans might become necessary because of expanded or modified client requirements, environmental changes, and changes in design philosophy.

To develop a detailed and logical set of estimates for cost and schedule, two separate structures must be created, defined, or modified for the purposes of a project: the work breakdown structure (WBS) and the resource breakdown structure (RBS). Successful project management depends on a well-defined and fully implemented WBS and RBS. With such comprehensive tools in hand, a successful project can be achieved through clear planning, accurate reporting, and regular updating. As project details become available, they will trigger enhancements to the WBS, RBS, estimate, schedule, and other project planning documents.

The estimates of the cost and duration of the WBS elements and the project that are developed during the early stages of the project will form the baseline budget for measuring its cost and schedule performance during the implementation phase. The cost estimate, and hence the budget, will initially be very rough and inaccurate, as is the anticipated delivery date.

When establishing the project budget on the basis of the project estimate, the project manager must keep in mind whether the estimate was developed using a rough conceptual estimate technique or a detailed bottom-up estimate. If the budget was established in the early stages of planning, it will be less accurate. The budget development process, therefore, should be open to modification. In enlightened organizations, the project budget will go through continued enhancements as the details of the project are being developed.

During budget development, awareness of the degree of the baseline estimate’s accuracy is essential when making commitments for time and cost and when comparing projects. Similarly, when making judgments regarding variances during the project progress monitoring phase, knowing the accuracy of the baseline is critical. During the implementation phase, the project estimates of cost and delivery date will serve as the basis for developing quantitative indicators of the project’s performance.

The estimate of cost and duration, which forms the baseline for progress monitoring, should be vigorously updated during the entire lifecycle of the project, and particularly during its early stages. Depending on the accuracy and limitations of the estimate, the project manager should incorporate appropriate contingencies, reserves, and flexibilities into the budget so that at any point it is realistic and accurate.

The credibility, accuracy, and completeness of the project plans will be enhanced by the project manager’s skills in disciplines related to the project, such as engineering, technology, information systems, manufacturing, assembly, marketing, management, or production planning. The project manager’s expertise must extend into the areas of business, management, finance, and all facets of project management activities.

It is unrealistic to expect one person to have expertise in all of these areas, so organizations sometimes form planning committees or planning boards. The members of these boards come from all disciplines affected by the project, such as IT, engineering, operations, business development, purchasing, contracting, financial management, and of course the project team and representatives from the project management office.

The project’s cost estimate is derived by adding the resource expenditure, and hence the cost, of the project’s individual components. The estimate duration also is derived from WBS elements—not in a linear summary fashion, but rather from calculations of a schedule network. With the expectation that cost estimating and scheduling processes use the same structural foundation, the estimate of the duration of the project’s component elements is used in developing the schedule network, which in turn will formulate a time management structure for the project.

Thus, the relationship between the cost and the schedule of the project is interdependent. The project manager should keep this interdependence in mind during project implementation, when the changes in scope and specifications cause changes in project cost or schedule. The relationship between cost and schedule must continually be reviewed as the project evolves, when detailed project plans are formulated, when more definitive baselines are established, and finally when the inevitable tradeoffs must be made during the implementation phase.

A review of marginal or failed projects shows that the vast majority of them suffered from lack of detailed planning, or that the procedures for managing were casual and ad-hoc. Conversely, the literature shows that organizations that encourage detailed planning experience far better financial growth compared to those organizations that do not. Finally, organizations that employ competent project management professionals and consistent project management procedures tend to produce more successful projects (Ibbs & Kwak 1997; Vigder & Kark 1994).

When the project is in its formative stages, very little information about it is available. Consequently, the accuracy and dependability of the estimate are very low. In other words, the risks of unforeseen and undesirable occurrences in the project are very high. Therefore, early plans and budgets are usually far from definitive, and they rarely predict the actual cost of individual components and the definitive cost of the total project.

During the early stages of the project, modifications to project plans can be formulated and conducted with minimal impact on cost and schedule. As the project proceeds, the cost of implementing modifications to the baseline plan increases substantially, although the risk and possibility of such events is lower at that point.

The bottom-up estimate uses a detailed WBS and RBS and is preferred over the less accurate and less sophisticated methods. Creating these structures requires nominal time and effort. However, for the purposes of project initiation and the project charter, and in the absence of sufficient information, rough estimates will be used during the early stages of the project.

PROJECT SCOPE AND OBJECTIVES

The client’s needs and preferences are communicated to the project team through such documents as the project charter, project objectives, project scope statement, and project specifications. The terms “requirements,” “specifications,” and “scope” are often used interchangeably, and sometimes differently, depending on the industry of the project. Construction, industrial, and process projects refer to the description of the deliverable as scope and specifications. Scope refers to a broader expression of the client’s objectives, while specifications refers to the detailed expression of the client’s objectives.

Systems and software development projects often do not use the terms “specifications” or “scope” to refer to the deliverables. Instead, they use the term “requirements” to describe the performance attributes of the projects, such as processing speed, error rate, database size, and the degree of friendliness of the deliverables.

Sometimes systems and software projects use the term “specifications” to describe the attributes of the hardware. Hardware specifications for systems and software development projects might be either predetermined by the client as part of project objectives or developed by the project team as one of the deliverable components of the project. Generally speaking, although requirements are the client’s preferences that will result in the scope and quality of the deliverable, requirements and scope are not the same. The former describes the preferences and needs of the client, while the latter describes the project team’s solutions in response to those needs.

The requirements document includes the client’s wants and needs, the distinction being that “wants” are those items that would be nice to have, although they are not crucial to the success of the project, while “needs” are those items that are essential to the success and usability of the project deliverable. Again, this information might be very sketchy during the early stages of project evolution, and it will be refined, clarified, and progressively elaborated as more information becomes available to the client and to the project team. At some point, both sets of wants and needs should converge on a set of definitive project scope specifications documents.

Project specifications usually are included in the contract documents if the project is an external project, and particularly if the contract is awarded on a lump-sum basis. (When the client directs the activities of the project, the description of tools and techniques that the team should use in implementing the project also will be included in the specifications document.) However, enlightened organizations develop specifications documents even for their internal projects. The project objectives or specifications of an internal project usually are spelled out in an authorization memo that has the same elements as the project charter, which empowers the project manager to implement the project.

The rationale for using a project charter for an internal project is that, although an internal project does not involve a formal contract, it should have a well-defined set of objectives for scope and quality so that delivery performance can be carefully and more realistically monitored. If there are no focused project objectives, and hence no detailed specifications, the evaluation and monitoring of the internal project will become ad-hoc, inaccurate, and somewhat arbitrary.

Planning details will be initially formalized and embodied in the project charter. A typical project charter will outline the attributes of a new physical deliverable, the details of performance enhancements to a system, or the purpose of a specific service. The specific service, which is described in the project objectives, will meet the needs of the organizational objectives that will form the business case for the project. The project charter will also include any assumptions and constraints. The definition of project objectives, as reflected in the project charter, involves detailing the project scope, attributes of the deliverables, acceptance tests, scheduled delivery date, expected budget, and team structure.

A carefully drafted project charter is essential to the success of the project because the charter is the focal point and the definitive reference for managing the project’s triple constraints of cost, schedule, and scope during the implementation phase. Project processes and procedures must include instructions on how to treat the project charter as a living document, to be enhanced continually. Project management procedures also must highlight uniform and consistent guidelines for developing and making modifications to the baseline project charter and its corresponding specifications.

The current version of this document will serve as a base of performance reference throughout the life of the project. Likewise, there must be procedures for drafting and continually enhancing the document that highlights the business need to which this project responds; this document is often called the business case document.

It would be highly useful if the first estimate of the cost and duration of the project were a pristine one, reflecting the optimal use of resources in crafting the deliverable. The pristine plan would be unencumbered by milestone constraints and low resource availability. Thus, it would be poised to deliver the project in the most efficient and cost-effective manner. If, however, the estimate of cost or delivery date is different from the client needs for those values, then a tradeoff analysis must be performed before the project starts. In other words, if the initial unconstrained project schedule calculations result in a date later than what the client wants, then the schedule must be compressed to comply. Likewise, if the pristine project estimate calculations result in a higher cost than reflected in the current budget, then either the scope or the schedule must be modified to bring the cost within the client’s budget.

In some organizations, there might be a scarcity of resources, particularly human resources. In these cases, the project duration must be extended so that the resource demand does not exceed the level of available resources. In rare cases, the client’s cost expectations are higher than the project team’s estimate, and the client’s delivery constraint is later than the delivery date calculated by the team. In these cases, the project team will have the rare opportunity to inform the client that they will surpass their expectations.

Sometimes the quality of the project deliverable is not explicitly addressed as one of the project objectives. Ironically, it is this issue of quality, independent of the volume of deliverables, that determines the usability of the project deliverable and the resulting satisfaction of the stakeholders.

As the client’s expectations of the project results become finalized, the acceptance procedures and validation tests determine the physical quality and performance tolerances of the deliverable. Therefore, the tests must reflect all of the important operational facets of the project deliverable and not frivolous features.

In the same vein, the project team should make every effort to craft the deliverable to the spirit, and not necessarily to the letter, of these tests, which might miss some important facet of the product. This kind of due diligence on the part of the project team will promote long-term client satisfaction, which is considered one of the most important indicators of a project’s success. For the purposes of this book, quality and scope are treated collectively.

The desired delivery date is the most important date in the project schedule. For a variety of historical and operational reasons, several intermediate milestones usually are defined as well. Intermediate milestones are not crucial to the execution of the project, although achieving these milestones often signifies or verifies the expected pace of the project and the desired quality of the deliverables.

Establishment of the intermediate milestones can be in response to the needs and desires of the client, the collective project team, individual team members, or the stakeholders. Establishing and monitoring the intermediate milestones provide a means of assuring the stakeholders that the project is progressing satisfactorily.

Project planning documents must include details of processes, procedures, and methodologies that will be used for monitoring the effectiveness and efficiency of the project team in producing the project deliverable. Since the project team’s characteristics can have subtle but significant impacts on the project’s success, the characteristics of the project team must be outlined as part of the process of planning the physical deliverable of the project. Such attributes might be the skills of team members, the administrative affiliation of team members, and the extent to which these professionals might be diverted to other duties during the time that they are involved in the project.

Project management activities that deal with team formation and the team charter must also be well defined and planned during the very early stages of the project. Finally, when the client specifies the means and modes by which the project will be conducted, the project charter and WBS might spell out the major items of equipment that will be used to craft the project deliverables and the tools that will be used to test their important attributes.

PROJECT BUSINESS CASE

Projects usually are undertaken in response to a set of goals for achieving organizational objectives. The most common categories of organizational objectives for internal projects are operating necessity, competitive necessity, or innovative ventures. Therefore, as a prelude to project selection and initiation, organizational priorities must be clearly identified and clarified, particularly as they relate to the project’s utility.

One of the important components of a project charter is the statement of how the project investment is reconciled with organizational strategic goals and investment policies. Further, a detailed and clear project charter, which includes a focused business purpose and a specific objective, will enable the team to develop alternative options for achieving the same organizational goal, using innovative and creative processes in crafting the project deliverable.

The alternative projects that respond to the same opportunity must be highlighted in terms of expected deliverables, conceptual estimate, preliminary schedule, and a quantified list of benefits and risks. The plan for each project should provide the details of all of the costs, benefits, and risks associated with providing the deliverable. Accordingly, the cost and duration of each project will be considered when determining whether the project should be funded for implementation.

To reconcile the project costs with corporate investment strategies, each project must have a business objective that is aligned with the strategic plan and that will serve as the foundation for the project’s investment proposal. The document containing the project objectives and investment strategies is called a business case or a business plan. It provides ample information on the project deliverable’s utility. The business plan must provide a detailed description of the problem, need, or opportunity to which the project is expected to respond.

The planning documents for each project must include as much detail as possible on the project’s sponsor, objectives, and deadline. The project’s business plan must clearly articulate the reasons for initiating this project and the expected benefits of the project’s deliverable. To satisfy this requirement, the benefits the deliverable will bring to the enterprise must be identified in the project charter or its supporting documents.

In many ways, particularly for internal projects, implicit or explicit corporate support for the project will determine its organizational viability and importance. If none of the members of senior management is willing to sponsor the project, it does not have sufficient administrative support. A formal survey of the key executives and major stakeholders sponsoring the project, therefore, must be conducted before authorizing it.

PROJECT INITIATION

In some cases, the business plan for a specific organizational objective might be related to several alternative projects. These projects might offer slightly different deliverables, and yet they all would achieve the same general business objectives. On the other hand, in some cases, one project might affect two separate organizational strategies.

In a proactive and dynamic organization, having a large portfolio of possible projects is a normal occurrence. However, funding limitations usually preclude implementing all of these projects. A formalized project ranking and selection process therefore must be developed to identify the projects with the greatest potential impact on the current organizational needs, at the lowest possible funding, and with optimized values of other issues that are important to the organization.

Selection of projects for implementation must take into consideration the organization’s corporate strategic plans, realistic expectations for sophistication of the deliverables, predicted success attributes of the project, and constraints to the project’s success. To make consistent and logical decisions in prioritizing the projects and selecting projects from a potentially continuous stream of options, a company-specific process of evaluating projects must be established. Finally, a project should be considered for authorization in light of the current workload of individuals, operational obligations of divisions, and financial obligations of the parent organization.

Ranking projects for implementation is most commonly conducted using an index, sometimes called a metric, or a group of indices called a model. In general, models are easy-to-use characterizations of operations, organizations, and relationships. Even the very sophisticated models, however, are only a partial representation of the reality that they attempt to portray. Further, although models are very useful as an aid in the decision-making process, they do not fully duplicate all facets of the real world. Nevertheless, models can be exploited to purge extraneous elements of a problem and to highlight the important elements of the issues surrounding the project’s implementation.

The objective of the project selection process, and its accompanying model, is to rank the projects in order of the best interests of the organization. Thus, the selection process would utilize a model that is specifically formulated to optimize parameters such as organizational goals, project cost, project duration, and the anticipated attributes of the project deliverable. Depending on the organization, project selection models range from the very simple to the very complex.

Because project planning models depend on numeric input from the indices describing the characteristics of the organization and those of the project deliverable, even subjective indices ultimately must be quantified. Accordingly, the project initiation process will be refined if the quantification of the subjective model indices is based on consistent and organization-specific procedures. Then, using the project data, organizational priorities, the customized model, and the consistent scoring process, the prospective projects will be ranked systematically and in a formalized fashion.

For external projects, the number of subcontractors and the overall contracting strategy must be carefully evaluated in light of the best interests of the project and its business plan, and not simply on the basis of the lowest initial cost. Contracting strategy will affect the communication pattern among project stakeholders, and it will subtly affect project performance. The fee structure of a contractor can profoundly affect the total project cost. Therefore, a careful analysis of direct and indirect costs, overhead, and profit margin of the contractor is advisable, particularly if the contract is being awarded on a cost-plus basis.

The numerical results of the project selection model always must be tempered by the experience and professional expertise of the organizational entity that is charged with managing the project portfolio. Ideally, this entity is the Project Management Office, although the function might be performed by an ad-hoc, or standing, team designated by upper management. The project selection group is expected to make a judgment on the project’s viability using the information generated by the model, although sometimes the quantified values provided by the less sophisticated models are enhanced and modified in light of the limitations and constraints of the model and its constituent indices.

Two separate sets of indices are used for the project selection process: organizational priorities and project attributes. The models that characterize the selection process include the important indices, describing these two sets of issues organized so that a quantified ranking for each project results. During a typical project selection process, one would identify organizational priorities for all projects and formulate company-specific scoring schemas for the ranking process. Thus, one can establish metrics that evaluate a specific project in the light of these priorities. A project selection model is, or should be, very organization-specific, and as such it should use a customized combination of indices to satisfy the organizational project selection objectives.

The indices used for project selection tend to fall into two major categories. Figures 1-1 and 1-2 show a listing of the most commonly used organization-based project selection indices. The first category includes quantitative indices (see Figure 1-1) that are generally based on financial characteristics, such as return on investment and net present value, cash flow, internal rate of return, cost-benefit analysis, and payback period. The second category includes qualitative indices (see Figure 1-2) that are intended to measure subjective issues, such as operational necessity, competitive necessity, product line extension, market constraints, desirability, recognition, and success.

Figure 1-3 depicts a generic selection model composed of four indices. The simple summation or weighted summation of the results of the indices will be used to compute the project’s rating. Figure 1-4 shows a sample of a customized model. The possible total points for a project are 100; therefore, prospective projects can be compared on the basis of the total score. In this model, the importance of the indices, as signified by the points assigned to each, have been customized for a particular organization.

The relative importance of these indices is reflected by how many maximum possible points are assigned to each. For example, a hypothetical project might earn a total score of 60 points received on individual indices that were identified and ranked specifically for that organization (see Figure 1-5). The score of an individual project is not as important as the relative scores of several projects that were ranked using the same model and the same rating process.

When conducting project comparisons among a large pool of projects, normalizing the base of reference for cost and duration is useful and logical. One of the more convenient techniques is to use the direct cost as the base of reference for the prospective internal or external projects. Compartmentalizing the direct cost of the project from other elements has the advantage of developing a project estimate strictly from the standpoint of the level of effort. Other elements such as indirect costs, overhead, and return on investment are important values, but, because they tend to be somewhat variable with organizational entity and with time, they might add unnecessary inaccuracy to the project selection process. Normalization should then extend to equalizing the cost effects of the location of the project.

Figure 1-5
100-Point Project Scoring System—Total Project Score