This article provides a brief overview of project management, including its purpose, activities, and responsibilities. The beginning sections discuss what projects are, what project management is, and what project management generally entails. Next is a summary of project life cycles and their phases, along with the processes and activities of project management. The article concludes with checklists, definitions, and further resources. The content of this article has been condensed from multiple sources that are listed at the end along with other recommended Web resources that provide more detail and direction for managing projects. Check them out!

A project is a group of activities undertaken to meet one or more specific objectives. These objectives could include solving a problem, building or upgrading a system or product, launching a product or service, implementing a strategic plan, changing a process, or one of many other unique efforts.

Projects can differ in size from small and simple to large and complex. Because they are designed to accomplish specific objectives, projects are temporary and have specific starting and completion dates. Ongoing operations, such as running a maintenance facility or publishing a magazine, are not projects. However, performing a specific aircraft avionics upgrade or printing a monthly issue of a magazine are projects.

Limited, specific performance time frames and objectives are how projects differ from programs. Programs are generally much larger efforts than projects with a longer duration. Relative to projects, they are ongoing rather than temporary efforts.

While this article focuses primarily on project management, most of what is presented will also apply to programs. Programs are made up of multiple projects and in many cases can be treated as longer, more complex projects.

Projects are often divided into smaller components or activities, usually based on technical and functional disciplines such as engineering, manufacturing, testing, and procurement. The relationships among programs, projects, and activities are shown in Figure 1. Some projects are divided along product lines instead of activities.

Figure 1: Relationships Between Programs, Projects, and Activities
(Click on image above to show full-size version in pop-up window.)

Projects are successfully completed when their objectives have been achieved. Projects should be terminated when management can see that the projects will fail to meet their objectives.

Project management is that discipline that employs skills and knowledge to achieve project goals through various project activities. It involves controlling costs, time, risks, project scope, and quality through project management processes.

Project management includes the following functions:

• Planning. Planning the project and establishing its life cycle.
• Organizing. Organizing resources such as personnel, equipment, materials, facilities, and finances. Coordinating work and resources.
• Leading. Assigning the right people to the right job. Motivating people. Setting the project's course and goals.
• Controlling. Evaluating project progress and, when necessary, applying changes to get it back on track.

Performing these functions in an organized framework of processes is the job of the project manager (PM).

Projects rarely succeed by themselves. They must be planned and executed. Projects must have specific support from management, general support from the organization, and appropriate participation from the customer. To be successful, projects must also have a responsible and empowered manager to drive, direct, and monitor them.

The selection of a PM has a major effect on project success. The PM should have the skills, knowledge, and personality necessary to bring the project to fruition. In addition to these traits, the PM must be given the level of responsibility and authority necessary to perform the job.

The PM's actual role depends on the structure of his/her organization, which can be function-oriented, project-oriented, or some type of matrix in between. In a heavily project-oriented organization, the PM may have relatively unlimited authority, answering only to upper management. At the other end of the spectrum is an organization that manages by function. The PM must deal with functional managers as equals, or possibly even superiors, and negotiate for resources. Most organizations fall somewhere in between these two extremes. Figure 2 depicts the level of PM authority associated with different types of organizations.

Figure 2: Organization Type and Project Management Authority
(Click on image above to show full-size version in pop-up window.)

It is essential that the PM understands the organization's structure and knows the level of authority that goes with the job. It is also essential that upper management grants authority and establishes an environment that will enable the PM to successfully accomplish the project objectives.

PMs need both management and technical skills. The key management skills are those needed to perform or direct project management activities, which are listed in Table 1.

Table 1: Management Skills for Project Managers
(Click on image above to show full-size version in pop-up window.)

The PM's technical skills should include at least some technical understanding of the project field. Remember, however, the PM will not typically be doing the technical work but will be directing the work that others do. The essential level of PM expertise is the ability to understand what others are doing, but not necessarily how they do their jobs.

To understand how a project is brought to fruition, the PM must understand project processes. The PM must also understand the differences between program and project life cycles and the difference between life-cycle phases and project-management processes.

As stated earlier, programs are generally large efforts spanning long periods of time and are composed of multiple projects. They are usually associated with developing or acquiring systems such as aircraft, weapons, training operations, communications, etc. An example of a product life cycle with its associated phases and products is shown in Figure 3.

Figure 3: Example of a Product Life Cycle
(Click on image above to show full-size version in pop-up window.)

This example has five phases - planning through operation - each producing a specific output. At the end of each life-cycle phase, a decision is made to either continue or not continue to the next phase. When the final product is completed, it is implemented, and after being in operation for some length of time, it is retired.

Various industries employ different life cycles, depending on their products. Each phase of a product life cycle can consist of one or more projects. Note that in the commercial world, a product life cycle is often described as the length of marketability of a product. We must not forget, however, the potentially long and costly maintenance or sustainment phases.

Projects, like products, have life cycles and are usually performed in phases. Each phase accomplishes specific work toward reaching the project goal and produces one or more deliverables. These are tangible, real items used in attaining the final goal of the project, and could include plans, studies, designs, or software or hardware prototypes. The end of a phase is defined by completing its deliverable. Figure 4 illustrates an example of a very generic project life cycle with its phases and major deliverables.

Figure 4: Example of a Generic Project Life Cycle
(Click on image above to show full-size version in pop-up window.)

While major aspects of project management are applicable across all projects, life cycles may vary depending on the type of project and the organization performing the work. It is important to implement an appropriate life cycle for the product. This article only deals with a generic project life cycle for a generic product or deliverable.

The phases identified in Figure 4 are common across most projects. However, they may be called by different names or split into additional phases. They may even be iterative where, for example, a prototype is designed, built, and tested, then the results are used to design, build, and test a new prototype. Project phases should, in most cases, be comparable to the generic project phases discussed in the following sections.

Definition Phase

This phase begins when upper management creates a project charter that defines the project's purpose and identifies the PM. The charter should also include a statement of support authorizing the PM to perform his/her functions. During this phase, the project rules are defined. Both the PM and stakeholders determine the project's goals, scope, and constraints. Key individuals and groups are identified as members of the project core team, and their roles are defined by both the PM and upper management. Upper management along with the PM also defines communications channels, authority, and the chain of command.

These project rules are written in three documents: the project statement of work (PSOW), the project responsibility matrix, and the project communication plan. The PSOW establishes the scope of the project and documents what is to be accomplished. For an internal project, the PSOW becomes the primary requirements document. However, the PSOW is not the same as a contract statement of work (SOW). For a project where much of the work is contracted, the SOW is a binding, contractual agreement. (See Table 2 for a description of these documents and other terms.) Figure 5 depicts the input, major activities, and products of the definition phase.

Table 2: Definition of Basic Project Management Terms
(Click on image above to show full-size version in pop-up window.)

Figure 5: Project Definition Phase
(Click on image above to show full-size version in pop-up window.)

Planning Phase

The planning phase uses the project rules as a foundation and defines the path to achieve the project goals. It is performed by the PM and the core project team, which interfaces with appropriate elements of the organization, and identifies the actual work to be done. It includes estimating schedule, cost, and resources required to perform the work, and produces plans to serve as a baseline and direct the work. A key part of schedule planning is identifying the critical path. This is the chain of interdependent, sequential project activities that takes the longest time to complete, and thus determines the minimum schedule for the project. Planning also includes risk identification and risk reduction efforts. The results of the planning phase become the project plan.

Figure 6 shows the inputs, activities, and products of the planning phase. Note the feedback loop from the phase activities to the project rules. This indicates that the rules may need to be modified after more detailed analysis in this phase reveals deficiencies or inefficiencies in the rules. This illustrates the iterative nature of project management. Remember, the project plan is fluid and the PM should expect changes.

Figure 6: Project Planning Phase
(Click on image above to show full-size version in pop-up window.)

Execution Phase

With a project plan for guidance, the actual project work can begin in earnest. This is the phase where project goals are achieved. While Figure 7 may make it look far simpler than the planning phase, the execution phase entails directing the various work groups in their activities, monitoring their progress, solving problems and resolving issues that will certainly come up, making changes to the plan, and coordinating these changes. (These activities are part of the executing and controlling processes discussed in the project processes section.) If your planning has been done well, you will have a smoother ride through this phase. This phase is complete when the product is complete, the project goals are reached, or the project is terminated.

Figure 7: Project Execution Phase
(Click on image above to show full-size version in pop-up window.)

Closeout Phase

The closeout phase begins with the delivery of the product or completion of the project goals or project termination. It consists primarily of tying up loose ends. Any unresolved issues from the contract or SOW are resolved in this phase. The contract is signed off as fulfilled, and all other paperwork is completed.

A very important activity of this phase is assembling the project history. This is a summary of all that has been accomplished. It should include information that will allow either you or a follow-on PM to understand what was done and why. Of particular importance is a compilation of lessons learned from the project so either you or others in your organization can do things better on the next project. Figure 8 summarizes the closeout phase.

Figure 8: Project Closeout Phase
(Click on image above to show full-size version in pop-up window.)

The Program Management Institute defines five major process groups used in projects: initiation, planning, executing, controlling, and closing. Processes are sequences of activities that accomplish specific functions necessary to complete or enable some portion of the project. These are not phases themselves but can be found both in projects and in each major phase of a program or large project. Because the activities in later phases may require changes in the products of earlier phases, these processes become iterative and often overlap phases as well as each other. An example would be an issue in the execution phase requiring a change to plans made in the planning phase. This overlap is shown in Figure 9.

Figure 9: Project Management Processes Overlap [1]
(Click on image above to show full-size version in pop-up window.)

Initiation Process

The initiation process consists of formally validating or authorizing the project. It often includes some form of analysis such as a feasibility study, a preliminary requirements study, a concept of operations, or a preliminary plan.

Planning Processes

Planning processes establish the scope or boundaries of the project. They lay the foundation and define an expectation baseline. Future proposed changes are evaluated against this baseline. What must be balanced here and throughout the project are schedule, cost, quality, and scope. Changes to the scope of the project will almost certainly affect at least one of these, requiring changes in the others to achieve balance again. Likewise, changes in one or more of these three constraints will require changes in the others and/or changes to the scope or expectations of the project. This balance is shown in Figure 10. Note that these do not necessarily define the project scope but they do constrain it.

Figure 10: Balancing Constraints Within Project Scope
(Click on image above to show full-size version in pop-up window.)

Again, a manager can control any three of these four constraints. For example, if one chooses to control schedule, cost, and quality, the functional capability of the product may have to be reduced. Likewise, if one attempts to expand functional capability (i.e., requirements bloat) while maintaining cost and quality, the schedule may have to be relaxed to maintain the balance.

Other planning processes include the following:

• Define activities needed to perform the project.
• Estimate activity duration.
• Estimate a minimum schedule and develop a project schedule.
• Conduct risk management.
• Develop communications planning.
• Conduct staff planning.
• Develop organization definition.
• Sequence activities.
• Conduct resource planning.
• Estimate costs.
• Develop a spending plan or budget.
• Conduct quality planning.
• Conduct procurement planning.
• Develop a project plan.

Executing Processes

The executing processes are those that direct or enable the actual work of the project. They consist of the following:

• Execute the project plan.
• Perform quality assurance activities.
• Perform procurement activities.
• Develop team and individual competencies.
• Communicate to team members and stakeholders.

Controlling Processes

Controlling processes are ongoing throughout most of the project. They include verifying that the project is proceeding according to plan or determining where and how much a deviation is occurring. They are absolutely essential to the progress and success of the project. They include the following:

• Monitoring, measuring, and reporting the performance of project activities.
• Verifying the project is continuing within scope.
• Controlling changes to the project scope.

These processes are, in turn, enabled by these supporting processes:

• Schedule control.
• Cost control.
• Quality control.
• Functional scope control.
• Risk monitoring and control.

Earned value management techniques, if properly employed, have been shown to be a worthwhile approach to indicate project status, progress, and trends toward successful completion.

Closing Processes

The closing processes are accomplished following the completion of the project objectives. Their purpose is to resolve any open issues, complete any paperwork required for formal completion of the project, and gather information useful for evaluating project performance for future reference. The first process is contract closeout, where any remaining contract issues are settled. The other process is administrative closure, where formal documents terminating the project are generated, and an appropriate history of project performance and lessons learned is gathered.

Applying the previous information to a real project will depend on several things. A PM assigned to an ongoing project has little control over how the project is set up. In this case, the new PM will need to quickly learn the following:

• Project purpose and objectives.
• Project phases and deliverables.
• Project budget and current spending status.
• Project schedule and current status.
• Current problems and issues.
• Major risks.
• Project team organization and contacts.
• Project management processes in place or planned.
• Life cycle of the product the project is supporting.
• Communications that detail who gets what information and when.

A new project requires the PM to learn or establish the items in the previous list. After understanding the purpose and goals of the project, the PM will need to select an appropriate project life cycle. If it is a small, straightforward software development effort, all the software development lifecycle phases are performed as part of the execution phase, as shown in Figure 11. Remember to distinguish between project phases and software development phases. Also note that this example portrays only one of several possible life-cycle models.

Figure 11: Software Development Phases are Part of the Project Execution Phase
(Click on image above to show full-size version in pop-up window.)

If the software development effort is larger or more complex, the development life cycle will still be performed in the execution phase of the overall project or program. However, each phase of software development now becomes a project in its own right, with all the phases of an individual project. This is shown in Figure 12.

Figure 12: Complex Development Phases Become Projects Themselves
(Click on image above to show full-size version in pop-up window.)

If the PM is managing a project team that is developing software, then he or she will manage both project and software development phases. If managing a contract effort, the PM will manage the overall project, but a contractor PM will manage the actual development effort.

With a contracted software development effort, you will also need to add a procurement phase to your project. This additional phase will take the outputs from the previous stage, including a SOW, and perform procurement activities to contract with an outside organization to perform the work. This additional phase is shown in Figure 13.

Knowing the project goals and selecting a project life cycle establishes the foundation on which to build the project.

Figure 13: Project with Procurement Phase
(Click on image above to show full-size version in pop-up window.)

This checklist is provided to guide you in essential actions to ensure your project is on track in meeting cost, schedule, and performance requirements. If you cannot check an item off as affirmative, you need to either rectify the situation or develop a contingency plan to solve problems that may arise. For example, if the staff does not have sufficient technical skill to do the work, you will need to remedy the situation either by providing training or by obtaining sufficiently skilled people.

• The project has specific goals to accomplish, and you understand the reasoning behind them.
• All stakeholders (interested parties) understand and agree on the expected project outcomes.
• Upper management is solidly behind the project.
• You understand the level of authority you have been granted in relation to the project and the rest of the organization, and the level of authority is appropriate.
• You understand how the organization operates, including how to get things done within the organization.
• You understand what you are responsible for delivering at both a macro and a micro level.
• You know the high-priority risks your project faces.

• You know which external interfaces are not under your control.
• You know the estimated size of the software to be developed, and how the estimate was made.
• Funding has been allocated for the project.
• A credible budget has been prepared, based on project scope and work estimates.
• Adequate time has been allocated to complete the project.
• Adequate staff is or will be available to complete project tasks.
• The project staff has sufficient expertise to perform the work.
• Facilities and tools are or will be available for the project team.
• You know of potential funding cuts and when they might come.
• You know what major problems have plagued projects of this type in the past.
• An appropriate life cycle has been selected for the project, and you understand that life cycle.
• You have a credible work breakdown structure.
• All requirements have work tasks assigned to fulfill them.
• All work tasks are associated with project requirements or support activities.
• Special requirements or constraints are documented.
• You have a budget, schedule, and performance baseline established and documented.
• You have identified the critical path for the project.
• You have a process established to monitor the project and detect problems and departures from the baseline.

• You know what your project's expenditures are to date and any difference between those and your budget.
• You know the status of project activity completion along the critical path and any difference between that and the schedule.
• You are aware of any issues or problems with quality or performance that may impact the critical path.
• You are aware of any contract performance issues.

All project managers desire to bring their projects to a successful conclusion. The typical success factors are meeting cost, schedule, and quality objectives within the allotted scope while also meeting the associated customer expectations. The standard practices to accomplish this desire have been outlined in this article. They include the following: obtaining and maintaining the necessary support from the project sponsor, support organization, and customer; employing an appropriate life cycle and breaking the project into success-oriented phases; setting aside an appropriate amount of time to understand the expectation of key stakeholders; adequate planning to accomplish key objectives; and finally, executing the project plan while balancing the naturally occurring changes with a companion control and tracking system.

1. Project Management Institute. A Guide to the Project Management Body of Knowledge. 2000 Ed. John Wiley & Sons, Inc., 1999.

1. AllPM. Project Managers Home Page. www.allpm.com.
2. Best Manufacturing Practices. TRIMS Risk Management and Best Practices Software downloads: www.bmpcoe.org/pmws/index.html.
3. Best Manufacturing Practices Library. Download know-how software and copies of DoD 5000.1, 5000.2, etc. www.bmpcoe.org/pmws/download/knowhow.html.
4. Can-Plan Project Management. Software download. www.geocities.com/billmcmillan2000/CAN-PLAN.html.
5. Baker, Kim and Sunny. Complete Idiot's Guide to Project Management. 2nd Ed. USA: Alpha Books, 2000.
6. Department of Defense. Defense Acquisition Deskbook. http://web2.deskbook.osd.mil/default.asp?.
7. Department of Defense. Defense Acquisition Deskbook, Program Management. http://web1.deskbook.osd.mil/CS_PM.asp.
8. Defense Systems Management College. Program Manager Magazine. www.dsmc.dsm.mil.
9. Department of Defense Software Clearing House. www.dacs.dtic.mil.
10. Gantthead Online Community for IT Project Managers. www.gantthead.com.
11. Department of Defense. "Guidelines for the Successful Acquisition and Management of Software-Intensive Systems (GSAM)." Ver. 3.0. OOALC/TISE. May 2000. www.stsc.hill.af.mil/resources/tech_docs/.
12. Project Management Forum. www.pmforum.org.
13. Project Management Institute. www.pmi.org.
14. Project Management Knowledge Base. Extensive free library. www.4pm.com.
15. Defense Systems Management College. Project Manager Magazine. www.dau.mil/forms/order_pm.asp.
16. Software Program Managers Network. www.spmn.com.
17. Software Program Managers Network. Risk Radar software download. www.spmn.com/rsktrkr.html.
18. Software Program Managers Network Guidebooks. www.spmn.com/products_guidebooks.html.
19. Software Technology Support Center. www.stsc.hill.af.mil/.
20. TechRepublic Information Technology Forum. www.techrepublic.com.
21. Ten Step Project Management Process Site. www.tenstep.com.
22. Clinger-Cohen Act of 1996. The National Defense Authorization Act for Fiscal Year 1996.
23. Department of Defense. "Mandatory Procedures for Major Defense Acquisition Programs and Major Automated Information System Acquisition Programs." Regulation 5000.2-R. 10 June 2001. Part 2: 2.8 Support Strategy. Part 2: 2.9 Business Strategy. Part 5: Program Design.
24. Department of Defense. "The Defense Acquisition System, 4.5 Effective Management." DoD 5000.1.
25. Department of Defense. "Operation of the Defense Acquisition System, 4.7 The Defense Acquisition Management Framework." DoDI 5000.2.

Tim Perkins has been involved in software process improvement for the past 11 years, including leading the effort to initiate software process improvement at the then five Air Force Air Logistics Centers. As the software engineering process group leader at the Software Engineering Division at Hill Air Force Base, UT, he led the division in reaching Capability Maturity Model® (CMM®) Level 3. The division has gone on to achieve CMM Level 5. Perkins is Acquisition Professional Development Program Level 3 certified in Project Management and System Planning, Research, Development, and Engineering.

Software Technology Support Center
517th SMXS/MXDEA
7278 Fourth St. Bldg.100
Hill AFB,UT 84056-5205
Phone: (801) 775-5736
Fax: (801) 777-8069
E-mail: tim.perkins@hill.af.mil

Roald E. Peterson is a senior systems engineer with Science Applications International Corporation. He has 22 years of electronic systems development experience, specializing in communications, architecture, and software development. Peterson was an editor and contributor for the "Guidelines for the Successful Acquisition and Management (GSAM) of Software Intensive Systems" and is the author of the "Condensed GSAM Handbook." He has a bachelor's degree in physics and master's degrees in computer resources management and electrical engineering.

Science Applications Int'l Corporation
920 W. Heritage Park Blvd. Suite 210
Layton,UT 84041
Phone: (801) 774-4705
Fax: (801) 728-0300
E-mail: roald.e.peterson@saic.com

Larry Smith is a senior software engineer and project manager for the Air Force's Software Technology Support Center at Hill Air Force Base. He provides software engineering, software process improvement, and project management consulting for the U. S. Air Force and other Department of Defense organizations as well as commercial and nonprofit organizations. Smith is a faculty member at the University of Phoenix. He is also certified by the Project Management Institute as a Project Management Professional. Smith has a bachelor's degree in electrical engineering and a master's in computer science.

Software Technology Support Center
517th SMXS/MXDEA
7278 Fourth St. Bldg.100
Hill AFB,UT 84056-5205
Phone: (801) 777-9712
Fax: (801) 777-8069
E-mail: larry.smith4@hill.af.mil