PROJECT MANAGEMENT PROCESSES

IPECC

Project management processes can be organized into five groups of one or more processes each:

Closing processes—formalizing acceptance of the project or phase and bringing it to an orderly end.

Project Versus Program

According to the MPM and IPMC:

A project is a temporary endeavor undertaken to create a unique product or service.

A project exists only after a decision has been made to address a specific business need, either internal or external (customer need) to the organization, funding is available to support its execution, and measurable goals and objectives are well defined. Without knowing the expected results, quality level or capability of the end product, a project is difficult to plan, execute or conclude.

A project is temporary in that there is a defined start (the decision to proceed) and a defined end (the achievement of the goals and objectives). Ongoing business or maintenance operations are not projects. Process improvement efforts that result in better business processes or more efficient operations can be defined as projects.

Figure 0.1 depicts the process flow of a project.

Figure 0.1: Project Process Flow

In most organizations, there is a descending hierarchy of endeavors ranging from the strategic plan to programs, projects, and subprojects. According to the PMEPG:

A program is a group of projects managed in a coordinated way to obtain benefits not available from managing them individually.

A program should consist of several associated projects contributing to the achievement of the strategic plan. Programs may also contain elements of ongoing operations.

Another means of grouping programs/projects for better management visibility and more effective decision-making is through Project Portfolio Management. This refers to the selection and support of projects from an enterprise perspective based on how they relate to the Strategic Plan. Programs/projects are ranked based on their return on investment (ROI) and their contribution to the achievement of the Strategic Plan.

Project Management Life Cycle

Project management processes are organized into five process groups. Each process group either interacts with the other process groups within a system development phase or across phases. These process groups are known as initiating, planning, executing, controlling, and closing. As depicted in Figure 1.9, IPMC Project Management Framework, these processes may be repeated during any of the steps of the life cycle. For example, repeating the planning process during each phase helps to keep the project focused on the business need and cost, schedule, and performance objectives. The project management processes are not discrete, one-time events; they are overlapping activities that occur at varying levels of intensity throughout each phase of the project.

These process groups and their relationship are depicted in Figure 0.2. Also identified are nine areas of knowledge that could be applied to a given project.

Figure 0.2: Project Management Knowledge Areas

Project Management is an Iterative Process

The application of project management is an iterative process. For example, within the Planning Phase, several iterations of planning may occur as the team develops the optimal product solution for a customer. Identified solutions may require refinements to the schedule, the cost estimates, the quality requirements and/or the risk planning. As changes occur, the impact to other areas must be determined. Over time, the iterations should become smaller in magnitude and more defined as more detailed information is developed

After the initial Planning Phase has been completed, feedback from the Execution Phase (identified through the Controlling Phase) may results in adjustments to the project plan. Adjustments due to feedback typify the project management process. Project Management is a dynamic effort and requires a continual process of evaluation. Evaluation activities, such as oversight, quality control, and executive review are ongoing activities and affect every phase of the project.

Initiating

Initiating is the conceptual element of project management—the basic processes that should be performed to get the project started. This starting point is critical because those who will deliver the project, those who will use the project, and those who have a stake in the project need to reach an agreement on its initiation. Involving all stakeholders in the project phases generally improves the probability of satisfying customer requirements by garnering the buy-in and shared ownership of the project by the stakeholders. The basic processes for the initiation phase are:

Figure 0.3 depicts the initiation process flow.

Figure 0.3: Initiation Process Flow

For the project to get started “right,” it is essential that all stakeholders participate in this critical initial phase of the project. The success of the organization and the project team depends upon starting with complete and accurate information, management support, and the authorization necessary to manage the project.

Figure 0.4 illustrates the project initiation phase stakeholder participation.

Figure 0.4: Project Initiation Phase

Planning

The planning phase is considered the most important phase in project management. Time spent up front identifying the proper needs and structure for organizing and managing a project saves countless hours of confusion and rework during the execution and control phases of the project.

Project planning defines project activities that will be performed, the products that will be produced, and describes how these activities will be accomplished and managed. Project planning defines each major task, estimates the time, resources and cost required, and provides a framework for management review and control.

Planning involves identifying and documenting scope, tasks, schedules, cost, risk, quality, and staffing needs. This planning process:

The result of the project planning, the project plan, will be an approved, comprehensive document that allows a project team to begin and complete the work necessary to achieve the project goals and objectives (product/process). The project plan will address how the project team will manage the project elements. It will provide a high level of confidence in the organization’s ability to meet the scope, timing, cost, and quality requirements by addressing all aspects of the project.

The planning phase is comprised of a number of processes that will estimate the project’s size, technical scope, and the required resources. It will produce a schedule, identify and assess risks, and negotiate commitments. Completing these processes is necessary to establish the entire, comprehensive project plan. Typically, several iterations of the planning processes are performed before the plan is completed and approved.

Figure 0.5 depicts the planning process as a series of activities and steps to be completed that result in a complete project plan. These process activities will:

1. Produce a plan that will define how the project objectives will be achieved – scope, schedule, resources and cost.

2. Establish subsidiary management plans that will define how specific aspects of the project will be managed to make certain the objectives are met.

Figure 0.5: Project Planning Process Phase Activities

The planning process will result in the development of the subsidiary management plans which are:

Executing

Once a project moves into the execution phase, the project team and all necessary resources to carry out the project should be in place and ready to perform project activities. The project plan is completed and baselined by this time as well. The project team’s and specifically the Project Manager’s focus now shifts from planning the project efforts to participating in, observing, and analyzing the work being done.

The execution phase is when the work activities of the project plan are executed, resulting in the completion of the project deliverables and achievement of the project objective(s). This phase brings together all of the project management disciplines, resulting in a product or service that will meet the project deliverable requirements and the customers need. During this phase, elements completed in the planning phase are implemented, time is expended, and money is spent.

This phase requires the Project Manager and project team to:

In short, it means coordinating and managing the project resources while executing the project plan, performing the planned project activities, and ensuring they are completed efficiently.

The execution phase is when the project’s deliverables are produced and the objectives are met. This phase entails the completion of the work activities, the expenditure of resources, and the application of the quality assurance processes to ensure that the end product(s) is viable and meets customer requirements.

Several supporting processes are part of this phase. They may include:

Figure 0.6 shows how these processes fit into the execution phase.

Figure 0.6: Project Execution Phase Processes

The execution phase involves coordinating and managing project activities and the subsequent output. The focus of the Project Manager and the project team is on the day-to-day management of the overall effort. In addition to the processes and activities defined above, the subsidiary management plans are implemented and project performance is monitored and managed accordingly. Several of these facilitating processes (quality, communication, human resource, change, and procurement) are an integral part of the project execution process, while others serve as support functions for managing the project.

Controlling

Control is a formal process in project management. The PMEPG defines Project Control as a project management function that involves comparing actual performance with planned performance and taking corrective action to yield the desired outcome when significant differences exists. By monitoring and measuring progress regularly, identifying variances from plan, and taking corrective action when necessary, project control ensures that project objectives are met.

Project control involves the regular review of metrics and report status to identify variances from the planned baseline. The variances are determined by comparing the actual performance metrics from the execution phase against the baseline metrics assigned during the planning phase. If significant variances are observed, adjustments to the plan are made by repeating and adjusting the appropriate project planning processes.

A significant variance from the plan does not explicitly require a change, but should be reviewed to determine whether preventive action is warranted. For example, a missed activity finish date may require adjustments to the current staffing plan, reliance on overtime, or trade-off between budget and schedule objectives. Controlling also includes taking preventive action in anticipation of possible problems.

While the control phase’s relationship to other project phases is relatively concise and clear, control is often difficult to implement as a formalized system. Project control is still important however, because a project is unlikely to be considered successful by stakeholders if it is not controlled effectively. Success in this context translates to metrics (project, cost, completion dates, etc.) and customer’s expectations (features, functionality, performance, etc.).

Figure 0.7: Project Control Phase Processes

Only by controlling a project can project progress and stakeholder’s expectations be achieved in unison. Projects rarely fail because of one issue. Rather, failure is usually a collection of minor items that individually have negative impact in a specific project area. However, when looked at over the life of a project, these minor items can cause significant impact to cost, schedule, risk, and functionality and can manifest themselves as deviations from the original project plan.

As discussed in the planning phase section, the project plan will include the initially agreed upon baseline project schedule and budget. These become the primary tools for evaluating project performance.

Closing

The last major phase of a project’s life cycle is the project closeout phase. Project closeout is performed after all defined project objectives have been met and the customer has formally accepted the project’s deliverables and end product or, in some instances, when a project has been cancelled or terminated early. Project closeout is fairly routine, but it is an important process. By properly completing the project closeout, organizations can benefit from lessons learned and information compiled at closure.

The project closeout phase is comprised of two processes: contract closeout and administrative closure. These are depicted in Figure 0.8.

Figure 0.8: Project Closeout Phase Processes

Some of the key elements to project closeout are:

Managing IT Projects Within The Organization

The IPMC Project Management Framework diagram shown in Figure 1.9 illustrates the integrated process flow developed to insure a structured approach to product development within the ORGANIZATION as well as providing systematic checks and balances both annually and at critical points with the project life cycle.

This guide focuses on project management and the steps necessary to deliver a project within the constraints identified by the organization. It provides standard methods and guidelines to ensure the ORGANIZATION conducts projects in a disciplined, well-managed, and consistent manner promoting the delivery of quality products on time and within budget. As stated before, the application of project management is an iterative process.

For the purpose of this guide, a project takes place within the context of the organization and the business unit driving the work effort. Therefore, the project life cycle methodology reflects the structure of the organization and the type of project being undertaken. Because the capital needs and high-level feasibility studies are performed in the organization during the budget formulation and allocation processes, project life cycle will begin with project initiation and end with project closeout. The life cycle phases between initiation and closure encompass activities dictated by the type of project and the work complexity.

The IPMC Project Management Framework diagram is included at the beginning of each of chapter of the guide to illustrate the steps and related project management process groups.

Program (Investment) Life Cycle

The Program (Investment) Life Cycle integrates the project management and system development life cycles with the activities directly associated with system deployment and operation. By design, system operation management and related activities occur after the project is complete and are not documented within this guide. The program management life cycle is depicted and describe in the overall IPMC Project Management Framework to address the integration of OMB Exhibit 300 project (investment) management activities and the overall project budgeting process.

The IPMC Project Management Framework diagram illustrates Milestone 4 which occurs following the deployment of a system and the closing of the project. The project closing phase activities in the organization continues through system deployment and into system operation for the purpose of illustrating and describing the system activities that the organization considers to be part of the project.

System Development Life Cycle

The System Development Life Cycle (SDLC) identifies the processes and tasks and their order that must be completed to produce and maintain a system throughout its life cycle. Your organizational SDLC is designed to produce systems in an evolutionary or incremental manner and not in a “big bang” or “all at once” manner. PMs should develop systems one increment at a time and one project at a time. Each increment—managed as a project—represents some but not all of the system’s target capability. As each increment builds on the previous, the system’s target capability is realized. In this way risk is reduced and the systems initial (and often most critical) capability is delivered faster. In addition, PMs should manage changes or enhancements to operational or production systems as new projects.

There are different approaches or methods to systems development such as waterfall, spiral, or iterative. These variations exist to address the various types of systems being developed and the approach an organization chooses to develop. The project manager works with the systems design and development subject matter experts to determine the appropriate development methodology to apply within the overarching IPMC Project Management Framework. For example, multiple software development iterations or “spirals” could take place within Step 3 (System Development and Testing) of the Framework. (More on this topic is discussed in section 1.11 below.)

Project Managers need to address IT security threats and vulnerabilities early in the SDLC when the cost of implementing security controls and practices are relatively low and convenient to budget and schedule. Moreover, adherence to security-based software development practices will prevent deficiencies, rather than implement them after the fact. The cost to remediate a security weakness increases geometrically as a project moves through the SDLC.

The SDLC must also include those activities which will ensure the incorporation of an adequate security control baseline into all phases of system development, operations, maintenance, and disposal. Including information system security early in the SDLC for an information system will usually result in less expensive and more effective security than adding security to an operational system. NIST Special Publication 800-64, Security Considerations in the Information System Development Life Cycle, presents a framework for incorporating security into all phases of the SDLC process, from definition to disposal.

The SDLC includes the following steps:

IPMC Project Management Framework

The mapping of the IPMC Project Management Process and the IPMC life cycle identifies the project management outputs for each IPMC project management step and milestone review. It also shows the project management process groups with corresponding actions and artifacts identified by IPMC.

Figure 1.9 illustrates the actions and associated artifacts of the IPMC Project and Program Management process.

In addition, please see Appendix H for a high-level process flow chart that depicts the typical major actions, information flows, decisions, and roles for each step in the IT Project Management Process.

Figure 0.9: IPMC Project Management Framework

Project Management Tools

A Project Management Information System (IPMCS) facilitates project information to flow within an organization. The software application is a core component of the overall IPMCS and is considered to represent the tools and techniques used to gather, integrate, and distribute output of the other project management processes (e.g. project management outputs such as the overall project management plan and subsidiary plans).

Many organizations have selected a project management software for managing projects as well as Government level projects. Many software systems can be used as a unified project, process and resource management software that offers the combined benefits of managing projects, building and using standard methodologies and efficiently leveraging resources to deliver projects on time, on budget, and within scope. Organizations will generally as the software provider to provide “train the trainer” training to support your organization. Project managers and project team members receive ongoing support from software providers.

Project management tasks accomplished with specialized software are:

Specialized PM Software is the primary method of providing the Project Manager performance measurement data. The data will be used to develop the inputs to the monthly performance reviews, Milestone briefings and Exhibit special projects. The Project Manager accomplishes this by entering the project WBS into the software system. The WBS becomes the framework for a time-phased project budget and detailed project schedule. By comparing the budget with actual expenditures over time (schedule) the system can calculate earned value variances, estimates to complete and other performance measures. This data can produce project level reports and be rolled up to produce enterprise metrics such as those required for monthly performance reviews and milestone decision briefings.

While not utilized entirely for managing projects, the Capital Asset Management System (CAMS) is used by the 300-level Project Managers to input project data including project scope, schedule, cost performance, and risks as part of the annual budget submission internal to the organization and as a future output to governing bodies in the form of an Exhibit 300.

In general CAMS is used to establish, analyze, monitor, and manage organization’s portfolio of capital assets (major programs). And because the portfolio is made up of projects managed individually by software system, the two systems are used in conjunction to manage to organizational investments.

Milestone Review Process

The project management process is structured into discrete, logical steps separated by major decision points (called milestones). These milestones provide the basis for comprehensive management, progressive decision-making, and authorization of funding for each step in the process. These are to be used by projects in the regular or IT Portfolio, for new projects, and those identified as high priority by the organizational leadership. The milestones require both written documentation and a briefing. The milestones include:

Each milestone builds upon the information provided in the previous milestone and increases in detail. The number, sequence, and timing of milestone decision points shall be tailored to meet the specific needs of individual programs. For example, some milestones can be combined (e.g., I and II), especially for projects that are not systems development efforts, but rather are efforts to establish an IT service. In addition the time between milestones can be shortened and the milestones (and the SDLC steps between milestones) can be iterated (e.g., IIa, IIIa and then IIb, IIIb, etc.), especially for iterative or spiral system development efforts.

An organization’s Enterprise Architecture (EA) must be linked with the milestone review process in order to ensure projects remain aligned and synchronized with the EA throughout their life cycle rather than just at the outset when an investment decision is initially justified. Several of the milestones refer to documenting specific parts of the framework. A specialized framework is the tool your organization may use to build its EA, an explicit description and documentation of the current and desired relationships among program/business and management processes and IT. The framework describes the data, functions, network, people, time, and motivation for the project, from different perspectives. Information on the Zachman framework can be obtained online: www.zifa.com

All IT project milestone reviews that are to be provided to the Enterprise Information Board are scheduled by OI&T’s IT Oversight and Review Services (005P3). After the Project Manager has received their Administration’s or Executive Office’s approval to schedule a briefing, the Project Manager submits a request to the Project Oversight Department or other related office, which will provide the Project Manager with a template for creating the project milestone package. The Project Manager returns the completed package for review and briefing scheduling.

See appendix G for more detailed guidance on the milestone review briefings and process.

Milestone Decision Memo

Following the milestone decision briefing the project decision authority will sign a project decision memorandum that provides information pertaining to the meeting. The decision memorandum will be forwarded to the appropriate official. The memorandum will include the briefing date, background/discussion material, any required action items, and the CIO decision regarding the project. A status report and estimated completion dates for the required actions will be requested as noted in the memorandum.

See appendix G for a sample Milestone Decision Memo.

In-Process Reviews

In-Process Reviews are briefings that are provided to the Enterprise Information Board (EIB) because a project is either experiencing problems or variances that are outside tolerance levels or because the time span between milestone reviews is too long to allow the EIB to conduct adequate, timely oversight and control on the project. In-Process Reviews are scheduled by OI&T’s IT Oversight and Review Services (005P3). See appendix G for more information.

Monthly Performance Review

Performance reviews are conducted monthly on all projects listed in the IPMC portfolio of projects. Using a template, the Project Manager provides to OI&T an assessment of project performance in each of the following areas: acquisition requirements, funding, staffing, schedule, budget and quality. OI&T summarizes the performance data and presents at the monthly performance review.

The performance review template is divided into three categories with a Project Manager completing the category appropriate to the project. The table below shows the categories and the project status or type for each category:

Each worksheet category reports the same metric areas listed in the first paragraph with the exception that enterprise programs do not report milestone or system related metrics. Scoring a project depends on where it is in the development life-cycle. Projects early in the cycle are weighted heavily in the acquisition requirements area, while funding will be given a lesser weight. The weighting changes as the project moves forward. Later in the life-cycle, acquisition requirements are weighted less and other areas such as Cost and Schedule increase. As the project nears closeout, the emphasis will be on quality performance. The overall score is influenced by scores in primary categories like acquisition requirements, funding and staffing. The worksheet color codes each area and overall scores with green, yellow, orange, and red according the score values.

To complete the template, the Project Manager scores each metric from the drop down menu. A color is chosen based on the metrics shown under the Ratings column. The colors are automatically translated into values and the overall score is determined.

See appendix F for more detailed guidance on the monthly performance review process.