Back to Basics

Overview of Project Management

Tim Perkins and Roald E. Peterson Software Technology Support Center/SAIC Larry Smith Software Technology Support Center

Every organization or program creates and implements projects to help it move toward its goals. Every assigned project manager wants to be successful in executing assigned projects, and a number of standard practices exist to assist and guide the project manager. This article is extracted from the Software Technology Support Centers soon-to-be-released condensed guidelines for software acquisition. It outlines some of these key practices that, while are common sense, are not always common practice.

his 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!

Projects and Programs

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. 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 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 projects 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. Project Manager 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 PMs 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. It is essential that the PM understands the organizations 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
January 2003

Figure 1: Relationships Between Programs, Projects, and Activities

PROGRAM
Project
Activity Activity Activity Activity Activity Activity

Project
Activity Activity Activity Activity Activity Activity

Project
Activity Activity Activity Activity Activity Activity

4 CROSSTALK The Journal of

Defense Software Engineering

Overview of Project Management

management activities, which are listed in Table 1. The PMs 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.

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. Project Phases 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

Organization Type Function Oriented Matrix Project Oriented

PM Authority

Figure 2: Organization Type and Project Management Authority creates a project charter that defines the projects 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 projects goals, scope, and constraints. Key individuals and groups are identified as members of the

Process Description

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. Product Life Cycle 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. 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. Project Life Cycle 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 (see page 6) illustrates an example of a very generic project life cycle with its phases and major deliverables. 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
January 2003

This phase begins when upper management Table 1: Management Skills for Project Managers
Skill Integration Management Scope Management Risk Management Time and Schedule Management Cost and Budget Management Quality Management Communications Procurement Management Human Resources Management Earned Value Management

Description Coordinate project plan development, execute the plan, and manage the change control process to ensure that all aspects of the project are working together. Establish project scope at the start. Develop and implement plans and procedures to verify that scope is achieved and maintained. Define and oversee the process for controlling changes to the scope. Identify potential risks. Mitigate large risks and plan how to deal with smaller risks. Monitor the project to detect and resolve problems. Estimate the duration of project activities, the proper sequence of these activities, and develop and control the project schedule. Estimate project costs and develop and control the project budget. Establish and control processes to ensure project goals are met to the stakeholders' satisfaction. This includes quality planning, quality assurance, and quality control. Define methods and lines of reporting and information distribution: Who gets reports and project information? How often? What is the content? Oversee procurement and delivery of materials, equipment, and services needed for the project. This includes planning, solicitation, source selection, and contract administration. Develop good leadership qualities. Plan team organization, obtain the right people to staff the positions, and develop their skills as individuals and as a team. Develop a systematic approach to project control integrating cost and schedule control with performance control.

Figure 3: Example of a Product Life Cycle

Planning
Decision Program Plan

Requirements
Decision

Product Requirements

Design Example
Decision

Product Design

Product
Life Cycle

Construction

Actual Product Implementation and Acceptance

Operation
Retired

Time
Note: In some life cycles, e.g., evolutionary or rapid prototype, the output of a design phase may be a product prototype.
www.stsc.hill.af.mil

Back to Basics

Definition

Project Rules

Planning Example

Project Plan

Project
Life Cycle

Execution

Project Goal Complete Formal Closure and Project Review

Closeout Time Figure 4: Example of a Generic Project Life Cycle

Definition Phase
Project Charter - Announces Project - States Purpose - Identifies Project Manager - Statement of Support Determine goals, scope, and project constraints. Identify core team members (individuals and groups) and their roles. Define communications channels, methods, frequency, and content.

Project Rules Project Statement of Work

Responsibility Matrix

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.
Execution Phase

Communications Plan

Figure 5: Project Definition Phase 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 contract Baseline A standard against which future status, progress, and changes are compared and measured. Most plans developed during the planning phase are used as baselines. The budget usually serves as one baseline, the schedule as another, etc. Communications Plan A document that defines the lines, content, method, and frequency of communications between the project manager, members of the project team, stakeholders, and management. Critical Path The sequence or chain of interdependent activities in the project that takes the longest time to complete. This sequence determines the shortest schedule for the project. Any delay in a critical path activity increases the project schedule. Life Cycle The complete set of phases something goes through, beginning with its conception and ending with its retirement from service. Process A series of related activities or steps that accomplish a specific purpose. Project Charter Document that announces the project by name, states its purpose, identifies the
Defense Software Engineering

ed, 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.
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

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.
Closeout Phase

Table 2: Definition of Basic Project Management Terms

project manager, and announces his or her authority. Project Manager (PM) Individual with responsibility and authority for directing the project. Project Statement of Work (PSOW) Document that defines the goals, scope, and constraints of the project. It states what needs to be done, not how to do it. Responsibility Matrix Document that identifies members of the project team and defines their roles. Stakeholders Those persons and organizations that have an interest in the performance and completion of the project. The customer or user of a product created through a project is usually a primary stakeholder. Statement of Work (SOW) A contractual document that defines the work to be performed for a specific project under contract. Work Breakdown Structure (WBS) A breakdown of the project into its constituents tasks or activities. It lists the specific work needed to complete all aspects of the project.

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. Project Processes The Program Management Institute defines five major process groups used in projects:
January 2003

6 CROSSTALK The Journal of

Overview of Project Management

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.
Initiation Process

Planning Phase
Identify risks and develop a plan to control them. Identify the tasks required to achieve project goals. Estimate effort required. Project Rules Estimate required staffing levels and specialties. Estimate quantity and timing of materials and equipment needed. Define task sequence, estimate minimal schedule, and develop a schedule. Estimate costs: labor, materials, facilities, etc. Develop a budget.

Project Plan Risk Management Plan

Work Breakdown Structure

Staffing Plan
Material and Equipment Plan

Feedback

Project Schedule

Project Spending Plan

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

Figure 6: Project Planning Phase

Execution Phase
Project Plan Execute project plan and accomplish project goals. Feedback Product or Goal

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. 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.
January 2003

Figure 7: Project Execution Phase

Closeout Phase
Resolve open issues. Product is delivered or goals are met. Complete contractual obligations (contract closeout). Assemble project history and lessons learned. Stakeholders Satisfied Contract Closed

Project History

Figure 8: Project Closeout Phase

Executing

Activity
Initiation

Planning Controlling Closing

Start

Time

Finish

Figure 9: Project Management Processes Overlap [1] Estimate costs. Develop a spending plan or budget. Conduct quality planning. Conduct procurement planning. Develop a project plan.
Scope Cost

Executing Processes

Balance Schedule Quality

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.

Figure 10: Balancing Constraints Within Project Scope

www.stsc.hill.af.mil

Back to Basics

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

er 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.

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 gath-

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

Project Management Application

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. 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. 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.

Project Management Checklist

Figure 11: Software Development Phases are Part of the Project Execution Phase

Definition

Planning

Execution

Closeout

Requirements Design

Implement

Test

Integrate

Figure 12: Complex Development Phases Become Projects Themselves

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. Beginning a Project " 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
January 2003

Definition

Planning

Execution

Closeout

Requirements Design

Implement

Test

Integrate

Definition Planning Execution Closeout

Definition Planning Execution Closeout

Definition Planning Execution Closeout

Definition Planning Execution Closeout

8 CROSSTALK The Journal of

Defense Software Engineering

Definition Planning Execution Closeout

Overview of Project Management

"

"

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.

Definition

Planning

Procurement

Execution

Closeout

Requirements Design

Implement

Test

Integrate

Figure 13: Project with Procurement Phase

During Project Planning " 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. During Project Execution " You know what your projects 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.
January 2003

Conclusion

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.

Reference

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/ b i l l m c m i l l a n 2 0 0 0 / C A N - P L A N. html>. 5. Baker, Kim and Sunny. Complete Idiots 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.desk book.osd.mil/CS_PM.asp>. 8. Defense Systems Management College.

Resources

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/gsam/guid.asp>. 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.
www.stsc.hill.af.mil

Back to Basics

About the Authors

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 T echnology Support Center OO-ALC/MASE 7278 Fourth St. Bldg. 100 Hill AFB, UT 84056-5205 Phone: (801) 775-5736 Fax: (801) 777-8069 E-mail: [email protected]

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 bachelors degree in physics and masters degrees in computer resources management and electrical engineering.
Software T echnology Support Center Science Applications Intl Corporation 920 W. Heritage Park Blvd. Suite 210 Layton, UT 84041 Phone: (801) 774-4705 Fax: (801) 728-0300 E-mail: [email protected]

Larry Smith is a senior software engineer and project manager for the Air Forces 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 bachelors degree in electrical engineering and a masters in computer science.
Software T echnology Support Center OO-ALC/MASE 7278 Fourth St. Bldg. 100 Hill AFB, UT 84056-5205 Phone: (801) 777-9712 Fax: (801) 777-8069 E-mail: [email protected]

10 CROSSTALK The Journal of

Defense Software Engineering

January 2003