Project management is the application of relevant logic and tools to planning, directing, and controlling a temporary endeavor. Almost all companies encounter the need for project management at some point. The need may arise for a new physical plant, an expansion of office space, or a move to a new location. Reengineering may suggest a change in processes, with an accompanying equipment
rearrangement and retraining to ensure the effectiveness of the change. The present-day speed of technology change often forces companies to adopt new hardware and software to stay current. Softer issues, such as the implementation of quality programs, also are within the project management purview. While some organizations specialize in projects, others may require project management skills only occasionally to effect a change, either physical or sociological in nature, from the norm.
A project is typically defined as a set of interrelated activities having a specific beginning and ending, and leading to a specific objective. Probably the most important concept in this definition is that a project is intended as a temporary endeavor, unlike ongoing, steady state operations. Secondary is the uniqueness of the output.
To ensure that a project is temporary, it is necessary to define the ending explicitly. The outputs of the project, or deliverables, may be tangible (a new heating system) or intangible (a retrained workgroup), but in either case should be defined in measurable terms (completed installation or documented level of expertise). While the reason for undertaking the project may have been to reduce utility costs by 10 percent or to increase productivity by 20 percent, achieving such goals may be outside the scope of the project.
Each project requires specific definition of its goals. In a training project example, the project manager may be given responsibility for identifying and implementing a training system that will enhance productivity by 15 percent; in this case, the project is not complete until the 15 percent goal is reached. If the initial training program enhances productivity by only 12 percent, the project manager is obligated to provide additional training, or the project may be terminated as a failure. Note that a 12 percent increase in productivity was something to celebrate, but did not meet the hurdle rate of acceptability. If instead the project is to implement a previously identified training program, known to achieve excellent results, then the project is finished when the trainees achieve the test scores known to correlate with a specified level of improvement in productivity. At this point, the project manager has achieved the deliverable, as measured in specific terms; the project is a success. Whether or not the desired improvement in productivity follows is outside the scope of the project.
Obviously, it behooves the project manager to have a well-defined scope for the project. The more nebulous the assignment, the more the project is subject to “scope-creep,” or the tendency for the project to acquire additional duties. A “statement of work” document or charter, outlining the relevant specifications of deliverables, helps to keep a project clearly defined. Once the work is completely specified, the requisite activities can be identified and assigned.
The work breakdown structure (WBS) is one of the tools used by project managers to ensure that all activities have been included in planning. By numbering the project “1.0.” the implication is that this is the first project for the company; subsequent projects would be numbered sequentially. In the illustrated example, the deliverables are specified on the second layer of the WBS, along with an overhead allocation for the project management team. Under each deliverable is an increasingly specified description of the activities involved in achieving the deliverable. Alternatively, the second line may be functional headings (finance, marketing, operations) or time periods (January, February, March). The objective of the WBS is to clarify that all activities have been addressed and assigned.
While the definition of a project also tends to include the word unique, this may be true only in a narrowly defined sense. A company that builds a new branch location (first project) has a template for the construction of a second branch location (second project). In the marketing field, subsequent product rollouts can learn
from the initial product introduction. To the extent that the project is repetitive, the planning process, WBS, and cost estimates can provide a valuable template for future projects.
Scheduling is an important part of the planning of any project. Program Evaluation and Review Technique (PERT) and Critical Path Method (CPM) are tools widely used in project scheduling. Both are based on network diagrams applicable for both the planning and control aspects of production. Visual display of the network enhances the communication and highlights the interdependency of the various activities required for project completion. Perhaps the greatest contribution of these tools is the identification of sequentially time-critical activities that require the closest monitoring.
It is first necessary to develop a list of all the activities required, as listed in the work breakdown structure. Activities require both time and the use of resources. Typically, the list of activities is compiled with duration estimates and immediate predecessors. Some expertise is required in the planning stage. The concept of concurrent engineering makes the planning stage even more important, as enhanced expertise is needed to address which stages of the project can overlap, and how far this overlap can extend.
Both PERT and CPM rely heavily on time estimates, as derived from local experts, to determine the overall project time. These two project management tools, frequently used together, can assist the project manager in establishing contract dates for project completion, in estimating the risks and costs of contingencies, and in monitoring project progress. Many commercial software packages exist to support the project manager in tracking both costs and time incurred to date throughout the project duration.
Using CPM to Schedule and Control a Project. CPM uses the concept of the critical path to estimate project-completion time. The critical path is the longest path through the system, defining the minimum completion time for the overall project. This generally depends on which activities must be done in sequence so that there is no way to shorten the overall time. Note that this critical path is not dependent on the number of activities, but is rather dependent on the total time for a specific sequence of activities.
The managerial importance of this critical path is that any delay to the activities on this path will delay the project completion time. It is important to monitor this critical set of activities to prevent the missed due-date of the project. Other paths tend to require less monitoring, as these sets of activities have slack, or a cushion, in which activities may be accelerated or delayed without penalty. Total slack for a given path is defined as the difference in the critical path time and the time for the given path.
Slack for the individual activities is calculated by taking the difference between the late-start and early-start times (or, alternatively, between the late-finish and early-finish times) for each activity. If the difference is zero, then there is no slack; the activity is totally defined as to its time-position in the project and must therefore be a critical path activity. For other activities, the slack defines the flexibility in start times, but only assuming that no other activity on the path is delayed.
CPM was designed to address time-cost tradeoffs, such as the use of additional resources to speed the overall process. The project manager should perform contingency planning early in the project to identify potential problems and solutions and the costs associated with employing extra resources. Cost-benefit analysis should be used to compare the missed due-date penalty, the availability and cost of resources, and the effect of these resources on the required quality of the output.
Using PERT to Schedule and Control a Project. In repetitive projects, or in projects employing well-known processes, the duration of a given activity may be estimated with relative confidence. In less-familiar territory, however, it may be more appropriate to forecast a range of possible times for activity duration. The estimated time and or standard deviation for each activity (E ) are calculated from the formula for the flexible beta distribution. With a reasonably large number of activities, summing the means tends to approximate a normal distribution, and statistical estimates of probability can be applied.
The mean is calculated as [(a + 4m + b ) ÷ 6], an average heavily weighted toward the most likely time, m. The standard deviation for an activity is [(b − a ) ÷ 6], or one-sixth of Managers the range. with a basic understanding of statistics may relate this to the concept of the standard deviation in the normal distribution. Since ±3 standard deviations comprise almost the entire area underthe normal curve, then
there is an intuitive comparison between a beta standard deviation and the normal standard deviation.
From a managerial viewpoint, it should be reiterated that there is only a 50/50 chance of completing the project within the sum of the activity-time estimates on the critical path (T ). This perspective is not emphasized in the CPM analysis, but is likely relevant in that context also. Adding a buffer to the promised due date (where C > T ) enhances the probability that the project will be completed as promised.
There may be competitive advantages to bidding a project on the basis of a nearer-term completion date (where C < T ), but managers can assess the risks involved using PERT analysis. By using PERT, managers can allocate the resources on a more informed basis.
The traditional measures for judging project success are: scope, time, and budget. This is frequently depicted as a triangle.
Increasing any of the triangle's sides inherently changes at least one of the other sides. Thus, increasing the scope of the project will necessarily increase either the time required to complete the project or the budget allocated to the project. Unfortunately, the expanded scope can cause both time and budget to escalate simultaneously, as constrained resources come into conflict. Some project contracts have penalty clauses that elicit hefty payments if the project completion is past the contract date. Similarly, when the scope is decreased, the requisite time and budget may be reduced; resources may be assigned elsewhere.
The triangle analogy breaks down when the time factor is reduced, i.e., the project completion date is moved up. An unexpected deadline change may necessitate the use of overtime resources. Overtime hours strain the budget, and may still be insufficient to complete the project within the specified time. Managers attempting to respond to deadline changes should note the relative costs
of time-intensive expenses (such as weekly rental of equipment) and of resource-intensive expenses (wages).
The schedule and budget are developed subsequent to the work breakdown structure, so that all activities and resources are identified. The budget is typically developed by estimating expenses at the bottom layer of the WBS, then rolling up the expenses to a project total. The numbering system in the WBS can be tailored to form a chart of accounts for tracking expenses associated with each activity. The project management heading is appropriate under any of these alternatives to ensure that staff salaries/wages are suitably allocated to the project. Earned value analysis incorporates both on-time and within-budget concepts of tracking the costs incurred to date on a project.
While customer satisfaction is sometimes added as a fourth factor in the list of project performance measures, this complicates the evaluation. If the project manager brings in the project according to scope specifications, on time, within budget, then customer dissatisfaction may be due to the customer's inability to define the scope in terms that would achieve the objective. Customer service in the project management context should include adequate discussion of alternative outcomes at the scope development stage.
Who is the customer of a project? Generally, the customer is the entity to which the deliverables are actually delivered. In an externally contracted project, the customer is easily identified. In an in-house project, the customer is the executive authorizing both the initiation of the project and the money allocated to it. In either case, the customer is the one with the right to complain when the performance measures of scope, time, and budget are not met.
Ideally, a project will have a sponsor, an intermediary between the customer and the project manager. This individual can help to define the scope for optimal delivery of results, to allocate appropriate funding, to resolve conflicts during the execution of the project.
The project champion is the source of the idea for the project. While the champion is frequently an individual, the idea may originate with the board of directors or the safety committee in a company. The project champion, however, may not be the ideal choice for project manager.
The project manager is in charge of the work to be accomplished. This is not to say that the manager actually does the work, but rather that he/she is the coordinator of all relevant activities through delegation. In many cases, this manager may not possess expertise in the field, but rather possesses the skills to oversee a large number of diverse tasks and to identify the best-qualified employees to carry out the
tasks. The manager should exercise judgment in assigning tasks; seasoned professionals will expect to accomplish the tasks according to their knowledge and experience, while others may require much definition and direction. In some cases, the project manager's ability to accomplish the job depends on negotiating and persuasive skills.
The authority of the project manager depends heavily on the organizational structure. In the “projectized” organization, resources are assigned exclusively to the project, then returned to a pool and assigned to a new project. The manager has near absolute authority and responsibility. In the functional organization (finance, marketing, operations, etc.), the project manager must negotiate with the functional manager for resources obtained from the department. Individuals tend to feel a greater responsibility to the functional manager. In this organization, the project manager has responsibility for the project, but relatively little authority without interference by the sponsor. The matrix organization is a managerial attempt to compromise these extremes by transferring some extent of authority from the functional manager to the project manager; thus, there are both strong-form and weak-form matrix organizations.
The project manager should be a master of many skills. Organization, negotiation, and teambuilding are desirable, while technical expertise may be less important. An expert whose intense focus on technical detail excludes the broader aspects of the project can undermine projects. Communication skills are of prime importance, as written and oral reports are mandatory. In addition, clarity of the initial assignment can reduce the amount of conflict management required in later stages of the project.
Surrounding the project manager is a team with the goal of supporting the planning, directing, and controlling functions. Typically, a full-time (or nearly full-time) team member is assigned responsibility for traditional office functions, such as communication coordination. This member may also be in charge of fielding reports and recording the responses for comparison to the baseline schedule. Other members exercise delegated authority in project oversight, up to and including direct responsibility for sub-projects within the larger project context.
Management of project integration includes the process of synthesis and response to change. The overall project employs five basic processes: initiating, planning, executing, controlling, and closing.
The initiating process incorporates development of the idea for the project and justification based on a feasibility study. It is at this stage that the boundaries of the project should be defined. To return to the earlier training example, the responsibility for identifying a specific training program should be determined.
Project planning addresses the specific timeframe and budget for the project. Activities are identified and assigned. Planning is considered a most important process because without excellent planning the ensuing activities are unlikely to succeed. Executing involves carrying out the assigned activities, while controlling monitors the activity for scope, time, and budget concerns.
Perhaps the most ignored process of projects in general is the closing process. Toward the end of a project, enthusiasm can wane, and it is the responsibility of the project manager to maintain active collaboration until the end of the project. Phased-out employees should be evaluated and returned to the pool/function from which they were recruited. A series of meetings should be held to review the degree to which the performance measures were met, from both the defined scope and the satisfaction of the customer. If these are not in agreement, then the reasons should be documented. Areas of success and failure are both important to note, as these can be the basis for company-wide learning. Even dissimilar projects can provide some learning opportunities, as the company understands, for instance, its tendency to underestimate costs or scheduling requirements.
While these processes, initiated through closing, appear to be linear in nature, they instead define a feedback system. The specifics of the planning process may indicate that the initiating idea was flawed. Execution may encounter problems with planning. Controlling may indicate a return to planning, or even to the earlier initiating idea process. And closing may determine that the entire project was doomed from the outset. Failure to recognize the iterative nature of these processes can be costly, as a project may be adjusted or abandoned at early stages to prevent loss.
Within the company, the project life-cycle stages of the project should be identified. Generically, these may be identified as definition, design, test, implementation, and retirement stages, or some variation on this theme. Interestingly, each of these stages employs each of the processes described above. For example, in the definition life-cycle stage, there is an initiation process, progressing to a feasibility study. As the definition stage reaches its conclusion, it “delivers” the project to the design stage, but only if the mini-project of definition has been successful. Many projects have lingered when a rational analysis would suggest that revision or abandonment would be less costly. The iterative nature of project management logic suggests a stringent review at frequent stages to ensure that both the project itself and the environment to which the project was to respond are in agreement. Management of the
integration of project stages is especially important in a rapidly changing environment.
One of the fundamental skills of project management is understanding, managing, and preparing for risk. Risk management may be the activity that best defines project management. This umbrella concept addresses the risks in all aspects of managing a project.
The four basic stages to risk-management planning are:
- Risk Identification
- Risks Quantification
- Risk Response
- Risk Monitoring and Control
To identify risks, managers must consider the traditional performance measures. Was the scope well defined? If the customer assumed that a specific aspect was included, then the contracting firm's reputation may be damaged when the aspect was not specified in the charter. Were the costs estimated correctly? Underestimating can undermine profits, while overestimating can lose an opportunity for business or in-house improvement. Were the time estimates reasonable? Past-due penalties can be significant. Other risks can include the insolvency of the customer and/or a sub-contractor, or the lack of in-house expertise to accomplish the tasks involved in the project. Weather, economic changes, and governmental regulations can change the feasibility of any project. Above all is the risk that the project is not sufficient to respond to changes in the environmental circumstances that triggered the project's initiation, especially in a project of long duration.
To quantify risk, two dimensions need to be taken into account: (1) the potential impact of the risk; and (2) the probability of the risk occurring. The potential impact is a stronger factor. If the probability of a risk is high but the impact is low, then the risk is considered a medium one, while a high-impact risk with a low probability is a high priority. As project management expert Neville Turbit notes, “A remote chance of a catastrophe warrants more attention than a high chance of a hiccup.”
There are several different strategies available for planning risk response. One is to avoid the risk by doing something to remove it or to mitigate the risk by taking actions to lessen the impact or the probability of the risk occurring. Another is to transfer the risk by making someone else—a vendor perhaps—responsible for a particularly risky part of the project. Finally, the project manager may decide to accept the risk based on a cost-benefit analysis of the potential impact and the costs associated with avoiding, mitigating, or transferring the risk.
The final step in risk management is to monitor risks continually throughout the project in order to note any change in the status or a potential risk. Risk managers accomplish this by holding regular risk reviews that identify changes in risk probability or impact, risks that have passed, and new risks that have arisen since the project began.
Managing a project, and its associated risks, requires a structured approach to solving a problem with a temporary, unique solution. Project planning is a most important stage, setting the stage on which the rest of the project must play out. The project manager should be heavily involved in this planning process to ensure his/her understanding of scope, time, and cost, the primary performance measures by which project success is measured. Monitoring of the activities enhances the probability that the project will stay on track for all of these measures. Each stage and process of project management should address the minimization of risk to the firm, in terms of both money and reputation.
SEE ALSO Operations Scheduling; Process Management; Product-Process Matrix; Production Planning and Scheduling
Gido, Jack, and James P. Clements. Successful Project Management. 4th ed. Cincinnati, OH: South-Western College Publishing, 2008.
Kerzner, Harold. Project Management: A Systems Approach to Planning, Scheduling, and Controlling. 9th ed. Hoboken, NJ: John Wiley & Sons, Inc., 2005.
Lewis, James P. Fundamentals of Project Management. 3rd ed. New York: AMACOM, 2006.
Mantel, Samuel J., Jr., Jack R. Meredith, Scott M. Shafer, and Margaret M. Sutton. Project Management in Practice. 3rd ed. New York: John Wiley & Sons, Inc., 2007.
PMI Standards Committee. A Guide to the Project Management Body of Knowledge. 3rd ed. Upper Darby, PA: Project Management Institute, 2004.
Tate, Karen, and Cynthia Stackpole. The Advanced Project Management Memory Jogger. Salem, NH: GOAL/QPC, 2007.
Taylor, Bernard W., III. Introduction to Management Science. Englewood Cliffs, NJ: Prentice-Hall, 2004.
Turbitt, Neville. “Basics of Managing Risks.” The Project Perfect White Paper Collection. Available from: http://www.projectperfect.com.au/downloads/Info/info_risk_mgmt.pdf.
"Project Management." Encyclopedia of Management. . Encyclopedia.com. (February 19, 2018). http://www.encyclopedia.com/management/encyclopedias-almanacs-transcripts-and-maps/project-management
"Project Management." Encyclopedia of Management. . Retrieved February 19, 2018 from Encyclopedia.com: http://www.encyclopedia.com/management/encyclopedias-almanacs-transcripts-and-maps/project-management
Modern Language Association
The Chicago Manual of Style
American Psychological Association
To understand project management, it is necessary to have a clear understanding of what a project is. A project exists to achieve some goal and once that goal has been achieved the project is finished. Projects do not carry on indefinitely; they have a start, a life-time, and an end. Projects can range from such challenging undertakings as sending a person to the Moon to more everyday tasks such as building a house. A complex project may involve thousands of people working over a number of years to achieve a goal; a simple project may involve only a single person working for a short time.
Project management involves organizing the actions needed to achieve the project goal. The two primary aspects of project management are project planning and project tracking. Project planning involves defining how you will achieve the goal, including listing the specific tasks required. Project tracking means looking at how the project is progressing and comparing that to the plan that describes how you expected things to happen.
The first step in project planning is to define very clearly what the goal of the project is. A clear goal is necessary so that everybody involved can agree on what constitutes a finished project. For example, the goal of a project to build a house could be that the house has everything necessary for living in it except for the furniture. This implies that the house includes plumbing, electricity, and decorations. Exactly what is required to meet the goal must then be spelled out in detail.
Once the project has a clear goal, the next step in project planning is to define the tasks that need to be completed to achieve this goal. For example, the project to build a house includes the following general tasks:
- Lay the foundation
- Build the structure (walls, floors etc.)
- Put on the roof
- Install plumbing
- Install electricity
- Decorate the house.
Ideally, a project plan would include these general categories, plus the sub-tasks that must be accomplished within each category to constitute a finished task. Without a detailed list of the necessary tasks and sub-tasks, it is very difficult to plan a project accurately.
Once tasks are identified, they must be organized to reflect the dependencies between them. Some tasks depend on the output of others. For example, decorating the house cannot be started until the structure has been built and the roof has been put on. In our example we have defined six tasks but a complex project may have hundreds of interdependent tasks. To help manage this complexity, a technique called Program Evaluation and Revue Technique (PERT) was developed by the U.S. Navy for its Polaris missile project. Project planning using PERT involves drawing a diagram, called a PERT chart, to show the dependencies between the tasks. On a PERT chart, the tasks are represented as arrows and events are represented as circles. One event that will appear on all PERT charts is the end of the project. The time order of the tasks on a PERT chart is from left to right, so the end of the project event will be the rightmost, however, the PERT chart does not say anything about the actual duration of the tasks. Figure 1 shows a PERT chart for our build-a-house project. Event A is the start of the project and event E is the end of the project. This PERT chart shows the dependencies between the six general tasks we have defined.
As well as identifying the tasks to be performed, it is necessary to estimate how much work it will take to complete the task. Table 1 shows estimates for how long each of the house building tasks will take.
Based on the time estimates for the tasks and the list of dependencies between tasks, a schedule can be created. The schedule maps the project tasks to time, indicating when individual tasks will be completed and ultimately when the complete project will be finished. Just as the PERT chart is a good way to identify and track dependencies between tasks, Gantt charts are useful for representing project schedules in a graphic format. The Gantt chart displays a list of tasks. For each task, it shows when in time it will be performed. Figure 2 shows a Gantt chart for the build-a-house project. As shown on the PERT chart, tasks 1, 2 and 3 are scheduled sequentially, due to dependencies among them, while tasks 4, 5, and 6 are scheduled simultaneously, because there are no dependencies between them.
While the project is underway, the project manager must focus on tracking the progress of the project. Project tracking involves comparing the actual progress of the project against the plan for the project. While the project is running, the project manager may modify the plan to take account of unexpected events that happen during the project.
Planning and Tracking Tools
Many software tools are available to support project management. These tools typically support a number of graphical descriptions of the project including PERT and Gantt charts. The software tools will check that the various representations of the project are consistent, highlighting any inconsistencies. Although software tools can be very helpful in managing a
|Task Number||Task Name||Estimate (in weeks)|
|1||Lay the foundation||8 weeks|
|2||Build the structure (walls, floors etc.)||6 weeks|
|3||Put on the roof||3 weeks|
|4||Install plumbing||2 weeks|
|5||Install electricity||4 weeks|
|6||Decorate the house||3 weeks|
project, it is important to remember that the software will not manage the project for you. The project manager must do the project planning and tracking; the software is only a tool to support the project manager.
Project management is about organizing actions to achieve some goal. The principles of project management are the same no matter what the goal of the project is. The example we have used is of building a house but the same principles apply to other types of projects including the development of computer hardware and software.
see also Decision Support Systems; Information Systems; Office Automation Systems.
Declan P. Kelly
O'Connell, Fergus. How to Run Successful Projects II: The Silver Bullet. New York: Prentice Hall, 1996.
"Project Management." Computer Sciences. . Encyclopedia.com. (February 19, 2018). http://www.encyclopedia.com/computing/news-wires-white-papers-and-books/project-management
"Project Management." Computer Sciences. . Retrieved February 19, 2018 from Encyclopedia.com: http://www.encyclopedia.com/computing/news-wires-white-papers-and-books/project-management