Project Management

Project Management -
INTERNATIONAL PROJECT MANAGEMENT COMMISSION __________________________________________ Office of PM Knowledge Management
Official Guide and Notes for IWNC Approved Project Management Certification with Relevant Coverage of IT Information Technology Project Management and Risk Management
Project Management Guide Executive Study Manual Produced by: Prof. G. Mentz, JD, MBA, MPM Prof. Brett King, MBA, MPM, CIPM Prof. Carl Thong, MBA, MPM, CIPM Dr. Demitri Leo, MPM, CIPM Dr. Michael Mataev, MD, MPM, CIPM, CEC
International Project Management Commission Project Management Guide for Master Project Managers, Organizations and Various Administrative Information Technicians (VAIT)
November 18, 2005 TABLE OF CONTENTS

EXECUTIVE SUMMARY 5 PROJECT MANAGEMENT 7 I NTRODUCTION 7 USING THIS GUIDE 7 INTRODUCTION TO PM 8 WHAT IS A PROJECT? 8 WHAT IS A PROJECT FOR? 8 WHAT IS PROJECT MANAGEMENT? 9 WHAT IS PMTOP 9
O T HE P ROJECT M ANAGEMENT K NOWLEDGE A REAS 9 O PROJECT MODELS 11
WHAT IS PRINCE 2 12 PRINCE 2 12 ISO 9000:2000 13 W HAT IS ISO 9000? 14 HOW TO DEVELOP A QUALITY MANAGEMENT SYSTEM (QMS) ? 14 A UTHORITY AND A CCOUNTABILITY 15 OVERVIEW OF PRODUCT DEVELOPMENT STRATEGY AND METHODOLOGY 16 USE IT AS THE PROVEN, LOW-COST BASIS FOR YOUR COMPANYS METHODOLOGY 20 PROJECT PHASES AND THE PROJECT LIFE CYCLE 20
http://www.projectmanagementcertification.org/managernotes/_printable.html[10/19/2011 8:34:12 PM]
PROJECT PHASES AND THE PROJECT LIFE CYCLE 20 20 STAKEHOLDERS 20 ORGANIZATIONAL STRUCTURE 21 SOCIAL-ECONOMIC-ENVIRONMENTAL INFLUENCES 22
O S TANDARDS AND REGULATIONS 23
PROJECT MANAGEMENT PROCESSES 23 IPECC 23 P ROJECT V ERSUS P ROGRAM 24 P ROJECT M ANAGEMENT L IFE CYCLE 25 P ROJECT M ANAGEMENT IS AN I TERATIVE P ROCESS 26
Initiating 27 Planning 28 Executing 30 Controlling 31 Closing 33 M ANAGING IT P ROJECTS W ITHIN T HE ORGANIZATION 34 P ROGRAM (I NVESTMENT ) L IFE CYCLE 35 S YSTEM DEVELOPMENT L IFE CYCLE 35 IPMC P ROJECT M ANAGEMENT F RAMEWORK 36 P ROJECT M ANAGEMENT T OOLS 38 M ILESTONE REVIEW P ROCESS 39 Milestone Decision Memo 40 I N -P ROCESS REVIEWS 40 M ONTHLY P ERFORMANCE REVIEW 40
ROLES AND RESPONSIBILITIES 42 T HE P ROJECT T EAM AND S TAKEHOLDERS 42 ORGANIZATIONAL M ANAGEMENT 43

Management Roles and Responsibilities 43
P ROJECT S PONSOR / B USINESS S PONSOR 44

Sponsor Roles and Responsibilities 44
P ROGRAM M ANAGER 45
Program Manager Roles and Responsibilities 46
P ROJECT M ANAGER 47
Project Manager Roles and Responsibilities 47
P ROJECT T EAM 49
Project Team Roles and Responsibilities 49
CUSTOMER 50
Customer Roles and Responsibilities 50
MAKING PROJECTS WORK 51

Processes 54
CONCEPT DEFINITION 55 S TEP 0: CONCEPT DEFINITION 55 M ILESTONE 0: P ROJECT I NITIATION A PPROVAL 56 P ROJECT M ANAGER S ELECTION 57 ONE EA/E NTERPRISE A RCHITECTURE 58 IT OPERATIONS CONSIDERATIONS 58 S IGNIFICANT P ROJECT M ANAGEMENT A CTIVITIES 58 RESPONSIBILITY A SSIGNMENT M ATRIX 58 CONCEPT DEVELOPMENT 60 S TEP 1: CONCEPT DEVELOPMENT 60 M ILESTONE I: P ROTOTYPE DEVELOPMENT A PPROVAL 61 IT S ECURITY 62 P RIVACY I MPACT A SSESSMENT 63 ONE E NTERPRISE A RCHITECTURE 64 IT OPERATIONS CONSIDERATIONS 64 S TEP 1: S IGNIFICANT P ROJECT M ANAGEMENT A CTIVITIES 65 S TEP 1: RESPONSIBILITY A SSIGNMENT M ATRIX 65 SYSTEM DESIGN AND PROTOTYPE 74 S TEP 2: S YSTEM DESIGN AND P ROTOTYPE 74 M ILESTONE II: S YSTEM DEVELOPMENT A PPROVAL 75 IT S ECURITY 75 ORGANIZATIONAL E NTERPRISE A RCHITECTURE 75 IT OPERATIONS CONSIDERATIONS 76 S TEP 2: S IGNIFICANT P ROJECT M ANAGEMENT A CTIVITIES 76 S TEP 2: RESPONSIBILITY A SSIGNMENT M ATRIX 77 SYSTEM DEVELOPMENT AND TESTING 79 S TEP 3: S YSTEM DEVELOPMENT AND T ESTING 79 M ILESTONE III: S YSTEM DEPLOYMENT A PPROVAL 80 COMPLETE S YSTEM AND T ECHNICAL DESIGN 80 IT S ECURITY 80 ONE E NTERPRISE A RCHITECTURE 80 IT OPERATIONS CONSIDERATIONS 80 S TEP 3: S IGNIFICANT P ROJECT M ANAGEMENT A CTIVITIES 81 S TEP 3: RESPONSIBILITY A SSIGNMENT M ATRIX 82 SYSTEM DEPLOYMENT 84 S TEP 4: S YSTEM DEPLOYMENT 84
IT S ECURITY 85 S TEP 4: S IGNIFICANT P ROJECT M ANAGEMENT A CTIVITIES 85 S TEP 4: RESPONSIBILITY A SSIGNMENT M ATRIX 85 SYSTEM OPERATION 87 S TEPS 5: S YSTEM OPERATION 87 M ILESTONE IV: P OST I MPLEMENTATION REVIEW 88 IT S ECURITY 88 ONE E NTERPRISE A RCHITECTURE 88 IT OPERATIONS CONSIDERATIONS 88 S TEP 5: S IGNIFICANT P ROJECT M ANAGEMENT A CTIVITIES 89 S TEP 5: RESPONSIBILITY A SSIGNMENT M ATRIX 89 ABOUT THIS IPMC EXECUTIVE SUMMARY 92
SUMMARY OF PM 94
MPM MASTER PROJECT MANAGER CORE REQUIREMENTS 102 MPM MASTER PROJECT MANAGER- SAMPLE CERTIFICATION TEST 103 SAMPLE MULTIPLE CHOICE QUIZ 103
LIST OF FIGURES Figure 1.1: Project Process Flow 4 Figure 1.2: Project Management Knowledge Areas 6 Figure 1.3: Initiation Process Flow 7 Figure 1.4: Project Initiation Phase 8 Figure 1.5: Project Planning Process Phase Activities 9 Figure 1.6: Project Execution Phase Processes 11 Figure 1.7: Project Control Phase Processes 12 Figure 1.8: Project Closeout Phase Processes 13 Figure 1.9: IPMC Project Management Framework 16
EXECUTIVE SUMMARY The IPMC Commission considers effective project management a fundamental management responsibility and vital to achieving the Departments overall mission and objectives. Agency officials and organizational managers must understand the current status of and risks associated with their programs in order to make informed decisions. Risks must be appropriately mitigated with sufficient controls in place such as to insure that projects are completed on-time, within budget, and aligned with the business case in order to achieve the mission of the VA. As distinguished from ongoing operations and maintenance, a project is defined as a related set of activities having a discreet beginning and end and resulting in the delivery of a specific product or service. Therefore this guide applies to projects defined, approved and funded in order to: Establish and communicate a consistent One project management framework for projects as developed by your organization committees and departments. Implement project management best practices incorporating common terminology and leverage the practices presented in the IPMC Project Management Training and Certification Program, and Provide project management forms and reference information as a tool to aid Project Managers and the organization in the consistent management and delivery of projects. The project management and system development processes, plans, and other outputs identified and described in this guide are based on the existing ORGANIZATIONAL project management practices, incorporate other best practices from throughout the Federal IT sector as well as those of the International Project Management Commissions Guide to the Project Management Treatise of Protocol (PMTOP Guide 2005). The guide is divided into chapters which describe the project management activities and deliverables for each step of the IPMC Project Management Framework. Project management forms for outputs identified in each step are provided in the appendix. The intended audience for this guide is primarily the project and program managers responsible for managing OMB Exhibit 300 level projects. However, the practices documented in the guide are scaleable and are thus applicable to projects which may not be identified as an OMB Exhibit 300-level investment project. Specifically, the following individuals and groups will benefit from the utilization of this guide: Senior executives Program managers, managers of Project Managers, and supervisors Project managers and other project team members Members of Project Management Offices (PMOs) IT Customers and other project stakeholders Functional managers with employees assigned to project teams Consultants working with the organization to provide products and services The IPMC Project Management Framework depicts the processes of the Milestone Reviews, the System Development Life Cycle steps, the Project Management Life Cycle, and the resulting IPMC outputs. This Framework, when incorporated with the IPMC Project Management Life Cycle, covers the initiating, planning, executing, controlling, and closing phases. The Framework addresses an effective, consistent management methodology that will provide the with useful, accurate and timely project information for achieving the successful delivery of project initiatives. The Framework represents the collection and recommended application of project management best practices throughout the organization. These project management processes will be transitioned to and aligned with the organizational environment and current processes. It is the vision of the IPMC Commission is that Project Managers incorporate this guide as a tool to aid in their responsibilities to deliver projects on time, on budget, and within the scope and alignment with the mission of your organization.
PROJECT MANAGEMENT
Introduction Prior to discussing the various phases, processes and standards involved in applying this guide to project management, the guide defines what project management is and the roles involved. Upon acceptance of the definition of project management internally, organizations can develop an infrastructure to provide the knowledge, skill, tools and techniques necessary to support projects, Project Managers and project teams. The guide provides the foundation that enables the organization to conduct projects in a disciplined, well-managed, and consistent manner so that quality products are completed on time and within budget. Throughout the guide reference will be made to the International Project Management Commission (IPMC) and the Project Management Executive Protocol Guide (PMEPG). IPMC has established the industry standards for project management and the PMEPG embodies those standards. Chapter 1 is an introduction to Project Management Best Practices as embodied in the PMEPG as well as other best practices used in both industry and government and describes how those are integrated into the framework to create a holistic approach to managing projects. The guide does not simply restate the standards and processes defined by IPMCs PMEPG but establishes an application of those standards to the Project Management Framework. The guide provides the methods addressing what needs to be done and how it is to be done in the execution and management of projects. Large, complex projects require a more rigorous application of management processes than small, non-complex projects with readily achievable goals. The Project Manager assesses the project characteristics to determine how to tailor the information in the guide to that specific project and determine which project management processes will be required. This tailoring effort is reflected in the Project Management Plan and its associated documentation. Additionally, the guide should be evaluated and refined over time (continuous improvement) in order to maintain the applicability, usability and acceptability of the processes and techniques defined. As the guide is implemented, lessons learned from its use will become invaluable to the continuous improvement effort. Using this Guide Chapter 1 provides background information and sets the context for understanding project management within the organization. Chapter 1 defines project management, discusses the difference between project and program management, and describes the IT Project Management Framework. The remaining chapters lead the reader through the IT Project Management Framework by devoting a chapter to each major step in the organizational project management process. The guide appendices include project management forms a Project Manager would use to initiate, plan, execute, control, and close out their projects. A basis and collection of best practices for project management as defined in the PMEPG is located in the appendix as a reference. There is also an organizational specific reference information, such as a glossary of project management terms within the context of the institution and the project management organizational governance structure, located in the appendix.
INTRODUCTION TO PM
The power of the Project Management Commission
WHAT IS A PROJECT?

Organizations perform work Work involves operations and/or projects Operations are ongoing and repetitive Projects are temporary and unique
WHAT IS A PROJECT FOR?

Key to Success:
Product Product Product Product
Features Quality Attractiveness Price
Guaranteed by a PROJECT MANAGEMENT
WHAT IS PROJECT MANAGEMENT?

Project management is the application of knowledge, skills, tools, and techniques to project activities to meet project requirements
WHAT IS PMTOP
The Project Management Treatise of Protocol (PMTOP) is the sum of knowledge within the profession of project management, which is generally accepted Generally accepted means that the knowledge and practices described are applicable to most projects most of the time, and that there is widespread consensus about their value and usefulness Generally accepted does not mean that the knowledge and practices described are or should be applied uniformly on all projects The project management team is always responsible for determining what is appropriate for any given project
o The Project Management Knowledge Areas

1. Integration Management Plan development Project plan execution control Integrated change control 2. Scope Management Initiation Scope planning Scope definition
Scope verification Scope change control
3. Time Management Activity definition Activity sequencing Activity duration Activity estimating Schedule development Schedule control 4. Cost Management Resource planning Cost estimating Cost budgeting Cost control 5. Quality 6. Human Management quality planning quality assurance quality control Resources organizational planning staff acquisition team development
7. Communication Management Communications planning Information distribution Performance reporting Administrative closure 8. Risk Management Risk management planning Risk identification Qualitative risk analysis Quantitative risk analysis Risk response planning Risk monitoring and control 9. Procurement Management Procurement planning Solicitation planning Solicitation Source selection Contract administration Contract closeout
o PROJECT MODELS
Traditional Model Plan-Design-Build
Adaptive Development (AD) Speculate-Collaborate-Learn
WHAT IS PRINCE 2 PRINCE 2

Projects IN Controlled Environments
In the UK and Europe, PRINCE2 is the project management methodology of choice, and is required by the UK government for all projects it commissions PRINCE2 was constructed to be in conformance with ISO 9001 requirements PRINCE2 is based on the principles of the PMBOK PRINCE2 does not include all the knowledge areas and details specified in the PMBOK PRINCE2 focuses on critical areas The intention of PRINCE2 is to organize and supplement project management knowledge
PRINCE2 is comprised of 8 elements or components 1. 2. 3. 4. 5. 6. 7. 8. Business Case Organization Plans Controls Management of Risk Quality in a Project Environment Configuration Management Change Control Business Case: The existence of a viable Business Case is the main control condition for a PRINCE2 project. The Business Case is verified by the Project Board before a project begins and at every major decision point throughout the project. The project should be stopped if the viability of the Business Case disappears for any reason. Organization: Since the Project Manager often has to direct staff who report to another management structure, some senior
management oversight organization is needed to assure that those diverse resources are committed to the project. In addition, viability decisions need to made by management with an investment in the project, and an accountability for delivering it through the Project Manager. In PRINCE2 this oversight is the Project Board .
ISO 9000:2000
ISO is the International Organization for Standardization. It is located in Switzerland and was established in 1947 to develop common international standards in many areas. Its members come from over 120 national standards bodies. ISO 9000 applies to all types of organizations. It doesnt matter what size they are or what they do. It can help both product and service oriented organizations achieve standards of quality that are recognized and respected throughout the world.
What is ISO 9000?

ISO first published its quality standards in 1987, revised them in 1994, and then republished an updated version in 2000. These new standards are referred to as the ISO 9000 2000 Standards ISO 9001:2000 presents requirements , while ISO 9000:2000 present guidelines The quality management system must meet ISOs requirements, not its guidelines . ISO 9000 is sweeping the world, is rapidly becoming the most important quality standard. It saves money Customers expect it Competitors use it
How to develop a quality management system (QMS) ?

Develop a QMS Development Plan which conforms to ISO 9001 2000 requirements. QMS Development Plan should use a process approach. Organizations must identify and manage the processes that make up their quality management systems. 22 QMS processes: 1. Quality Management Process 2. Resource Management Process 3. Regulatory Research Process 4. Market Research Process 5. Product Design Process 6. Purchasing Process 7. Production Process 8. Service Provision Process 9. Product Protection Process 10. Customer Needs Assessment 11. Customer Communications Process 12. Internal Communications Process 13. Document Control Process 14. Record Keeping Process 15. Planning Process 16. Training Process 17. Internal Audit Process 18. Management Review Process 19. Monitoring and Measuring Process 20. Nonconformance Management Process 21. Continual Improvement Process 22. General Systemic Process Following each of these 22 Steps/Plans, you will end up with a complete quality management system, one that meets all of the ISO 9001 2000 requirements!
Authority and Accountability

In most projects, authority is separated from accountability (consequences of success or failure), senior management has authority (but often not held accountable for success or failure of the project), while the project manager is held accountable (with insufficient authority over the resources to ensure completion of work). PRINCE2 calls for an accountable Project Board to own the project, helping to ensure their commitment to getting the work completed. At the same time, the Project Board grants authority to the Project Manger by explicitly committing resources as the project progresses. The PMBOK suggests this will happen under certain organizational structures; PRINCE2 believes it can be implemented in most environments. Plans: Plans are the backbone of the management information system required for any project, and require the approval and commitment of the appropriate levels of the project organization Controls: Control is about decision making: its purpose is to ensure that the project a) is generating the required products which meet defined Acceptance Criteria b) is being carried out to schedule and in accordance with its resource and cost plans c) remains viable against its Business Case. Management of Risk: Risks is an essential part of project management. To contain risks during the project, they must be managed in a disciplined manner, through risk analysis and risk management (as in the PMBOK) Quality in a Project Environment: Quality management ensures that the quality expected by the customer is achieved through a quality system (similar to the PMBOK). Quality requirements of the projects deliverables are based in Product Descriptions, prepared by the Project Manager and approved by the Project Board Configuration Management: Configuration Management gives the project management team control over the projects assets (the products that it develops), and is vital to any quality system. It provides mechanisms for tracking and controlling the projects deliverables, and a system for tracking project Issues Change Control is a required part of any complete (ISO 9001-certified) quality management system Change Control: Controlling scope change means assessing the impact of potential changes, their importance, cost, impact on the Business Case, and a decision by management on whether or not to include them Issue Management: Tracking and managing the issues is a vital activity for any project, No project methodology could qualify for maturity without an Issue Management process in place PRINCE2 is not meant to stand on its own and needs experience and the depth of PMBOK Use it for its unique approaches and insights into project management
OVERVIEW OF PRODUCT DEVELOPMENT STRATEGY AND METHODOLOGY
For R&D departments

v Common R&D structure (basic configuration)
v Major Documents list:

Project Development Plan Product Development Methodology Project Plan Technical Reviews Marketing Request System Requirements System Specification Risk Analysis Regulatory Plan Major Project Proposal External Product Specification Manufacturing Requirements V&V Release Records
v Project Initialisation
USE IT AS THE PROVEN, LOW-COST BASIS FOR YOUR COMPANYS METHODOLOGY PROJECT PHASES AND THE PROJECT LIFE CYCLE
Project involve a degree of uncertainty Project is usually divided into several project phases The project phases are known as the project life cycle Each project phase is marked by completion of one or more deliverables The conclusion of a project phase is generally marked by a technical review
v Common Project Development Cycle
PROJECT PHASES AND THE PROJECT LIFE CYCLE STAKEHOLDERS

Project stakeholders are individuals and organizations that are actively involved in the project, or whose interests may be positively or negatively affected as a result of project execution or project completion The project management team must identify the stakeholders, determine their requirements, and then manage and influence those requirements to ensure a successful project Stakeholder identification is often especially difficult.
Key stakeholders on every project include: Project manager Customer Performing organization Project team members Sponsor Others: sellers and contractors, team members and their families, government agencies and media outlets, individual citizens, temporary or permanent lobbying organizations, etc. Managing stakeholder expectations is difficult because stakeholders often have very different objectives that may come into conflict. For example: The manager of a department that has requested a new management information system may desire low cost, the system architect may emphasize technical excellence, and the programming contractor may be most interested in maximizing its profit.
ORGANIZATIONAL STRUCTURE
Projectised organization Functional organization
Matrix organization
SOCIAL-ECONOMIC-ENVIRONMENTAL INFLUENCES
o Standards and Regulations

A standard is a document approved by a recognized body, that provides, for common and repeated use, rules, guidelines, or characteristics for products, processes or services with which compliance is not mandatory! A regulation is a document, which lays down product, process or service characteristics, including the applicable administrative provisions, with which compliance is mandatory! Internationalization Time-zone differences, national holidays, travel requirements, etc Cultural Influences Demographic, educational, ethical, religious and other areas of practice Social-Economic-Environmental Sustainability Organizations are increasingly accountable for impacts resulting from a projects outcome.
PROJECT MANAGEMENT PROCESSES

Projects are composed of processes. A process is a series of actions bringing about a result. Project processes are performed by people and generally fall into one of two major categories:
Project management processes - describe, organize, and complete the work of the project. Product oriented processes - specify and create the projects product. Product oriented processes are typically defined by the project life cycle
IPECC
Project 1. 2. 3. 4. management processes can be organized into five groups of one or more processes each: Initiating processesauthorizing the project or phase. Planning processesdefining and refining objectives and selecting the best of the alternative courses of action to attain the objectives that the project was undertaken to address. Executing processescoordinating people and other resources to carry out the plan. Controlling processesensuring that project objectives are met by monitoring and measuring progress regularly to identify variances from plan so that corrective action can be taken when necessary.
Closing processesformalizing 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 managementthe 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: Selecting the project Determining business needs Collecting historical data Determining objectives Determining high level deliverables and estimates Developing a product description Identifying the qualifications of the project manager that would be best suited for the particular project Determining high level resource requirements Obtaining project initiation approval. 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: Identifies specific work to be performed and the goals that define the project. Provides documented estimates regarding schedule, resources and cost for planning, tracking, and controlling the project. Obtains organizational commitments that are planned, documented, and agreed upon Continues the development and documentation of project alternatives, assumptions, and constraints Establishes a baseline of the plan from which the project will be managed. 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 organizations 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 projects 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: Cost management plan Staffing/Resource management plan Scope management plan Schedule management plan Quality management plan Procurement management plan Communications management plan Risk management plan Integrated change control management plan.
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 teams and specifically the Project Managers 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: Conduct, coordinate and manage the ongoing work activities Perform quality assurance activities continuously to ensure project objectives are being met or achieved Monitor identified risks for triggering events and implement containment or contingency strategies as necessary Manage change. 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 projects 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: Team development Solicitation Source selection Contract administration Quality assurance Information collection and distribution. 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 phases 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 customers expectations (features, functionality, performance, etc.). The two core control processes implemented during this project phase are the Performance Reporting and Integrated Change Control. There are several supporting processes interacting with these core processes as depicted below in Figure 0.7.
Figure 0.7: Project Control Phase Processes Only by controlling a project can project progress and stakeholders 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 projects 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 projects 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: Completion and closeout of any contractual agreements with suppliers or providers Formalizing customer acceptance Closeout of any financial matters Preparation of the projects final performance report Conducting a project review Documenting lessons learned Completing, collecting and archiving project records Celebrating project success. 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 incrementmanaged as a projectrepresents some but not all of the systems target capability. As each increment builds on the previous, the systems 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: Step 0: Concept Definition Step 1: Concept Development Step 2: System Design and Prototype Step 3: System Development and Testing Step 4: System Deployment Step 5: System Operation (including System Disposal) 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: Develop the project WBS Work Breakdown Structure Develop a time-phased project budget Develop and control detailed project schedules based on deliverables and milestones Link schedules to budgets, resources and documents Track risks assess and mitigate risks using simulations Set baselines for performance measurement Track manpower resources and requirements Produce schedule Gantt and PERT charts using report wizards Track and summarize multiple project data
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 organizations 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: Milestone 0 Project Initiation Approval Milestone 1 Prototype Development Approval Milestone 2 System Development Approval Milestone 3 System Deployment Approval Milestone 4 Post Implementation Review 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 organizations 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&Ts IT Oversight and Review Services (005P3). After the Project Manager has received their Administrations or Executive Offices 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&Ts 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: Worksheet Category Development Performance Metrics Sustainment Performance Metrics Enterprise Program Performance Metrics Project Status/Type Projects which have completed Milestone 1 (Prototype Development Approval) or milestone 2 (System Development Approval) Projects that have completed Milestone 3 (System Deployment Approval) or Milestone 4 (Post Implementation Review) Government initiatives which do not involve the development of an IT system, i.e., they are program oriented and the milestone review criteria do not apply to them.
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.
ROLES AND RESPONSIBILITIES
It is important to have a defined formal structure for the project and for the project staff. This provides each individual with a clear understanding of the authority given and responsibility necessary for the successful accomplishment of project activities. Project team members need to be accountable for the effective performance of their assignments and achievement of the project goals and objectives. A successful project requires that the project team have the authority to complete a project, be participants (at some level) in the planning process, have ownership and buy-in to the project plan, and be responsible and accountable for completion of the project. The roles and responsibilities of project participants will vary. The requirements placed on participants will be determined and defined during the project planning process phase, however, the following is a good rule of thumb perspective: On a large project, individual role assignments may require full-time attention to the function. On smaller projects, role assignments may be performed part-time, with staff sharing in the execution of multiple functions. Tasking and individual responsibilities are often covered in the Organizational Breakdown Structure (OBS) as activity assignments are defined during the planning phase. Typically these assignments are shorter term and exist only to the completion of the activity deliverable. The Project Team and Stakeholders
A project team includes a diverse combination of people and skills who share the responsibility for accomplishing project goals. Stakeholders are individuals and organizations who have a vested interest in the success of the project. The identification and input of stakeholders help to define, clarify, drive, change, and contribute to the scope, cost, timing, quality and, ultimately, the success of the project. To ensure project success, the project management team needs to identify stakeholders early in the project, determine their needs and expectations, and manage and influence those expectations over the course of the project. Stakeholders on every project include: Organizational Management, who define business needs, goals and objectives of the project as well as defining the policies and procedures governing the project The Project Manager, who has ultimate responsibility for project success The Project Team members, who are responsible for managing the performance of the project work activities. These could include: Project management staff Business development staff Subject Matter Experts (SME) Documentation (user and technical) staff Training staff Technical staff Information Security Officer (ISO), please see Appendix I for more information on the duties of the ISO. Leaders/decision makers The Project Sponsor, who leads in getting the need for the project recognized as well as providing funding, enabling the resource staffing, and certifying the security of IT applications. The Customer, who is the person(s) or organization(s) using the product of the project and who determines the acceptance criteria for the product Organizational Management Organizational Management is responsible for the identification of the need and opportunity for a project, assessment of project risk, and the approval of the projects feasibility and resources. They are also responsible for establishing the strategic plans and for validating that projects are consistent with customer and organizational requirements. Management provides close oversight for high risk or high cost projects. Management Roles and Responsibilities General Functions Provide leadership and resources to establish and improve project management Ensure that sufficient resources are available to conduct projects Review/approve commitments to external entities (e.g., customers, vendors) Ensure staff is properly trained in project management techniques and principles Project Initiation Select Project Manager and assist in project team staffing Review/validate/approve project charter Authorize and provide funding Project Planning Verify that project goals and objectives are defined Review/approve project plan, cost, risk and establish management reserves Provide management oversight as predicated by review of the project risk analysis, risk response planning and project plan Enable project staff availability Project Execution Regularly conduct executive management reviews and provide oversight Project Control Review project status and corrective action plans (if required) Review/Approve changes affecting scope, timing, cost, and/or quality, as required Project Close-out Validate project completion (goals & objectives) Verify customer and sponsor acceptance Review and close project accounting/financial files Review project lessons learned and post project reports for continuous improvement action Project Sponsor / Business Sponsor The Project Sponsor is usually a member of the management team who will be the recipient of the projects end result (the product). The Project Sponsor is typically the head of a program area. This individual makes the business argument for the project to exist, controls the overall funding of the project and defines the acceptance criteria of the product. Many organizations have directives such as Information Technology Security Certification and Accreditation which identifies security related responsibilities for the System Owner. Please see Appendix I for more information on Certification and Accreditation. Sponsor Roles and Responsibilities General Functions
Articulate project and/or customer requirements Validate that project requirements are met Provide the necessary funding and resources as appropriate Champion the project to provide exposure and buy-in Communicate the sponsors views on project progress and success factors to the project team and other stakeholders Project Initiation Provide the strategic goals and objectives of the recipient organization and guidance to the project team to identify the relevance and value of the project Develop project concept document Define sponsor and organizations needs Obtain or provides funding for the project Document requirements Project Planning Review and approve the Project Management Plan and management approach Participate in planning sessions Project Execution Attend executive requirement reviews Resolve escalated project requirements issues, removes barriers and obstacles to the project Provide written agreement to project requirements and qualifying criteria Project Control Attend and participate as needed at Project Status Reviews and steering meetings Attend change control meetings and reviews and approves change in scope, timing, quality and/or cost as impacted Project Close-out Provide representation or input to lessons learned reviews Sign off on project completion Program Manager The terms program and project management are often used interchangeably. However, within this document the two terms and concepts are separate and distinct. Program management is defined as a group or series of related projects and ongoing systems/applications managed in a coordinated way to achieve resource, cost and quality efficiencies not available to individual projects. Programs generally support strategic goals and objectives, while projects may be more targeted in focus. The program manager has responsibility for the management of a series of related projects and the management of the corresponding Project Managers. Program Manager Roles and Responsibilities General Functions Plan, organize, staff, direct, control and coordinate Recommend composition of own program team Own and guide the program Reward and recognize performance Is accountable for cost, schedule, quality and scope Resolve any outstanding issues among the project teams that cannot be resolved within the team Is responsible for overall resource allocation for Project Managers assigned to the program Maintain ongoing communication with the project managers from the program management level perspective Communicate project status to fellow program managers Ensure IT applications are developed consistently with the software development life cycle Ensure projects are managed in accordance with the recommendations for project management as outlined in the Project Management Guide Ensure that IT security certification and accreditation (C&A) requirements are met. Project Initiation Assign Project Manager and assist in project team staffing Review/validate/concur in project charter Validates and communicates individual project objectives Project Planning Verify that project goals and objectives are defined Verify that project is aligned with the strategic goals of the program Review/concur with project plan, cost, risk and establish management reserves Provide guidance in cost and schedule development Ensure project staff availability Conduct routine program planning sessions as defined by individuals organization Project Execution
Conduct regular scheduled project reviews Project Control Review project status and corrective action plans (if required) Review, concur and participate in milestone review briefings Review/concur in changes affecting scope, timing, cost, and/or quality, as required Prioritize any changes to project scope Project Close-out Review whether stated improvements or benefits were realized from the project Assure customer and sponsor acceptance is obtained Review and concur in project accounting/financial file closeout documents Review project lessons learned and post project reports for continuous improvement action Project Manager The MPM Master Project Manager has overall project responsibility. In order to achieve success, the Project Manager should work closely with the Sponsor with respect to staffing requirements and funding availability. The Project Manager is responsible for completing the project on time, within budget, and meeting the quality criteria and requirements. The Project Manager should be assigned as early as possible in the life cycle of the project in order to establish project ownership and management responsibility as well as to begin the development of the project requirements from the ground up. Project Manager Roles and Responsibilities General Functions Comprehend and implement organizational project policies and procedures Maintain project staff technical proficiency and productivity, and provide training where required Establish and maintain project quality Identify and procure project infrastructure needs Develop Project Charter and obtain approval Define project goals, objectives and success criteria Identify and document project constraints Identify and document project assumptions Identify and secure project team resources Serve as focal point for project communications Develop and present Milestone review briefings Ensure that IT security C&A requirements are met Project Planning Develop Project Plan, tailoring the IPMCS to reflect project needs. The Project Plan should include the Project Charter, Scope Statement, constraints, assumptions, WBS defining project deliverables, cost estimates and project budget, major milestones, schedule, resource requirements, acquisition/procurement plans, risk analysis and response plans, project team structure and communications plan. Also included will be the deliverables acceptance criteria (quality metrics) and the acceptance process. Develop the supporting plans such as scope, cost, risk, schedule, quality, resource, security deliverables, procurement and change management plans Obtain stakeholder approval and acceptance of the Project Plan Obtain organizational commitment and support for completion of project task assignments, timing and quality Establish baseline Translate documented requirements into appropriate SDLC documentation (e.g., requirements document) Project Execution Manage and monitor day-to-day activity and provide direction to team members and supporting organizations Manage to and monitor quality targets and goals (both project and product) Manage and monitor risk response strategies Disseminate project information and maintain communication Develop and update system security plan and other security deliverables Manage, or support, procurement process and contract administration requirements Project Control Develop and distribute project performance reports. Regularly review project status, evaluating performance criteria (scope, cost, schedule & quality) Develop and manage corrective action plans Evaluate project performance and initiate change requests as required (scope, cost, schedule or quality) Participate in change control board to review and approve product/project changes Review project risks and establish risk response plans Adjust project planning, as required, to include approved changes in scope, timing, cost or quality after obtaining customer approval Project Close-out Obtain customer and management approval and acceptance of completed product Complete contract closeout
Closeout open action items Develop post-implementation report Conduct lessons learned session and develop recommendations for continuous improvement Close out any financial accounts or charge codes Archive all project data Recognize project team and celebrate success Project Team The Project Team is responsible for performing the project activities. Project Team members, as required, may assist the Project Manager with planning the project (ex. scope and WBS) and they may also assist with obtaining commitments to complete the project within established schedule and budget constraints. Customers and/or stakeholders should interact with the Project Team to ensure that requirements are properly understood and implemented. Project Team Roles and Responsibilities General Functions Identify product alternatives Complete the project within budgeted cost, schedule and quality requirements Support project planning and control Participate in identifying, mitigating, and monitoring project risks Project Initiation Provide estimates for product deliverables Review customer requirements for feasibility and available resources Analyze requirements for clarity (unambiguous), completeness and consistency Project Planning Develop technical approach Participate in the development of the project plan Identify tools needed for project Identify staff training needs Project Execution Create product and process solutions Conduct or participate in internal and external reviews Provide quality assurance support Manage work effort to maintain on time, on cost and on quality result Identify any project roadblocks, barriers or unanticipated risk events Project Control Track the project execution effort and submit status reports (scope, cost, and schedule) Maintain project and product quality requirements Identify and react to risk events as they are identified or occur Participate in change control reviews Project Close-out Participate in lessons learned sessions Identify ways to improve project processes or products (continuous improvement) Turnover all project related documentation to the Project Manager for archiving Customer A Customer is responsible for communicating project needs and verifying that requirements have been met at project completion. A Customer may be internal, external or both. Customer Roles and Responsibilities General Functions Articulate customer requirements Validate that project requirements are met Support and conduct staff training programs as required to make certain that the staff is ready to accept the new product Be proponents of the new product to the customer organization Project Initiation Clearly define customer needs and requirements to the Project Manager and project team Project Planning Review and approve project plan Attend and participate in project requirement reviews
Assign customer personnel as project points of contact Provide written agreement on requirements and qualifying criteria Provide input into deployment planning Project Execution Review project status reports Provide project support infrastructure as required Project Control Participate with project team developing corrective action plans addressing variances in time, cost or quality Communicate identified issues associated with project performance or product Validate quality assurance of deliverables Participate in change control process Review and approve or escalate project changes affecting scope, time, cost or quality Project Close-out Provide representation or input to lessons learned reviews
MAKING PROJECTS WORK

Critical issues
Meeting the Mission: Why are you undertaking this project in the first place? Who are the stakeholders and the customers? What are their expectations for the project? How does the project mission fit into your companys mission? Strategies: What do you want to accomplish with this project? Articulate the business objectives, the technical environment, and the project plan. People: Who are the project participants, and how are they organized? Communicate with the organizational leadership, the project leadership, the team members, the stakeholders and the customers. Processes: How will the project accomplish its objectives over time? Define the planning processes, the technology management, and the control of tasks. Meeting The Project Mission Its why youre here Know the Project Stakeholders A strong project mission can not be created in a vacuum. Who are the people with an interest in the outcome of the project? What are their common expectations? Stakeholders expectations are rarely spelled out in legislation, executive orders, or formal memoranda. Amplify the Voices of Your Customers Who will be paying for this project? Who will actually be using the systems and processes being designed? Clarify the business priorities of these customers and their criteria for success. Actively and emphatically communicate this information. Do this for customers inside the organization as well as those outside the organization. Maintain High-Level Communication About the Project Mission Communicate steadily with stakeholders and customers throughout the project. This will help to manage their expectations and requirements over time. Design project development so that requirements and expectations can be reconfirmed at regular junctures. Periodically check to see that stakeholders and customers understand and support changes, delays, and new developments. Strategies What do you want to accomplish? Set Realistic Business Objectives What are the common business needs of the organizations that will depend on the system? What accomplishments will be critical for the project to be considered successful? Define project boundaries at the outset, and use this definition to manage requirements throughout the project. A clear definition of business success will also help ensure that project efforts support the agencys strategic plan. Define a Sound Architecture Drive Toward an Enterprise-Wide Business Model Ensure that the business model meets business objectives while remaining within the projects scope. Publish a detailed concept of operations which distinguishes clearly among the business model, the layout and relationship of systems and communications, and the technical architecture. These should be anchored in an enterprise-wide IT strategy. Implement Systems Incrementally Work toward a systems implementation that will deliver, in twelve months or less, incremental, useable levels of functionality which support specific business objectives. The detailed concept of operations should explain how the architecture will satisfy these objectives and how it will prioritize them. It should also communicate responsibilities for implementing and managing the architecture. Coordinate Technical Standards Which standards are essential to ensure that the technical architecture ultimately supports business objectives? Define these, paying particularly close attention to technical interfaces. Develop a plan to ensure compliance with architecture standards. The technical architecture must be documented to ensure its consistency with the overall agency-level design. Gain Agreement on the Project Plan The project plan formally captures and documents agreements among customers, stakeholders and project participants. Secure an informed agreement up front, and maintain this agreement throughout the project life. This will ensure that the project meets expected results. This will also help align the project with the organizations business plans and supporting IT plans. Over time, manage the project scope carefully, since there will be a tendency for different areas of the project to acquire their own divergent momentum. People Understand the project participants Organizational Leadership Listen to the Customer and Create a Vision Commit to the Project Leverage the Existing Organizational Structure Support. Project Leadership Select a Strong Project Manager: Drive. Does the project manager have a strong desire to succeed? Ability to Build Consensus. Can the project manager get key individuals to work together towards common ends? Ability to Take Risks. Can the project manager recognize opportunities and find ways to seize them? Ability to Communicate. Is the project manager able to communicate clearly and convincingly to all parties? Experience. Does the project manager have a track record of success? Technical Knowledge. Does the project manager possess demonstrated knowledge in the appropriate technical fields?
Sense of the Big Picture. Does the project manager understand the project from a broad business perspective? Ensure Accountability
Project Team Members Get Whats Needed to Succeed Keep the Core Team Together Monitor Team Productivity
Processes
Making it happen
Planning
Managing Technology Choose an Appropriate Development Model Costs Risks (High development time, high uncertainty associated with the new technology, etc.) Complexity Type (A new development, a modification of an existing system, a system integration, etc.) Select an Appropriate Life Cycle Deal with Shifting Priorities Make Progress Visible to All Know The Limits of Automation Controlling Tasks Controlling Inputs (Budget, resources) Controlling Activities ( meetings, technical reviews) Controlling Outcomes (Desired results)
CONCEPT DEFINITION
Step 0: Concept Definition In Step 0, the predominate IPMC process group is Initiating. (See Appendix B for a detailed discussion of the Initiating process group.) The purpose of Concept Definition is to evaluate projects proposed for the next planning cycle and to reach consensus from the EIB or the appropriate senior leadership to proceed with the project. During this phase in the IPMC Project Management approach, it is important to have a clear understanding of the problem that needs to be solved and how solving that problem supports a strategic objective of the Department. The Project Concept Paper defines the projects reason for being and ensures the project is consistent with the organizational business plan. It defines a high-level approach and other toplevel planning information. Ideally, the information contained in the Concept Paper provides management with the information necessary to decide if the project can be supported. The Concept paper should not be a collection of product or process deliverables, but it should define what is to be done, why it is to be done, and what business value it will provide to the when the project is completed. New IT projects/initiatives require submission of Concept Papers and acceptance of the Concept Papers at a Project Initiation Milestone 0 Review. Each paper is meant to be a high-level, conceptual description of new proposed projects that broadly identify project goals and benefits. Once the Concept Paper is submitted, a Milestone 0 review will be scheduled with the Enterprise Information Board (EIB). A decision to proceed by the EIB authorizes the submitting office to prepare a planning or full acquisition Capital Asset Plan and Business Case (OMB Exhibit 300). If a new IT project/initiative is not approved during the Milestone 0 review, the originating office will have 14 calendar days to reschedule and conduct the review. Rescheduling a review will not postpone the date for completion of the OMB Exhibit 300 in Capital Asset Management System (CAMS). The results of all Milestone 0 reviews will be reported to the Strategic Management Council. A sample Concept Paper can be found in the Appendix. The primary task of the concept definition step is the initiating or chartering of the project . The PM documents produced during concept definition serve as the equivalent of what IPMC would call a project charter. The project charter process at the has several steps and incorporates several organizational-specific documents. These include the Concept Paper, Milestone 0 Review Briefing, and the Milestone 0 Decision memo. Combined, these documents: identify the business need for the project, give the Project Sponsor, Business Sponsor, and/or Project Manager (if one has been assigned to the project yet) the authority to expend resources necessary to lead the project into the next phase or step in the life cycle, describe the project, provide a mapping of the project goals to the enterprise goals, and provide a high-level discussion of the projects work breakdown structure, schedule, major risks, benefits, critical success factors, acquisition strategy, IT security, and order of magnitude life cycle cost estimates. A project is considered to be chartered once these three artifacts exist and the project has been received Milestone 0 approval from the governing bodies or appropriate senior management. Milestone 0: Project Initiation Approval Milestone 0 is intended to have the Project Sponsor, Business Sponsor, or Project Manager address the basic areas necessary to warrant project initiation approval. It does not presume any significant prior investment in analysis (either business or technical), concept or requirements definition or design; rather, it seeks answers to these most basic questions even before committing to that level of investment. The Project Manager should have a clear understanding of the problem that needs to be solved and how solving that problem supports a strategic objective of the Department. Based on a successful Milestone 0 review, the Project Manager will be authorized to expend the resources necessary to establish the projects business case and prepare for the projects Milestone I review. The main steps that need to be taken to reach the project initiation approval include preparing the Concept Paper, and conducting the Milestone 0 Decision Briefing. Preparing the Concept Paper: The Concept Paper information basically documents the business problem and proposed technical approach. The document should be brief, providing a high-level justification for the project, giving enough information to determine if the project should continue onto the next phase. After the appropriate Administration or Staff Office approval, the Concept Paper will be submitted to the CIO for review. The reviewing official will determine whether the project should go forward to EIB or be tabled, reworked, scrapped or refined. Preparing the Briefing: In addition to the documentation, a briefing needs to be given to the Enterprise Information Board (EIB). If the project is approved to go forward and is approved by the EIB, an Exhibit 300, either Planning or Full Acquisition, will need to be developed for the next milestone.
Once a concept is approved, the project team will need to complete a more detailed life cycle cost estimate, breaking out acquisition and recurring costs for each year of the project, in order to provide sufficient information to prepare and justify a budget request. Project Manager Selection The Project Manager is responsible for project cost, schedule and performance. Selection of the project manager should be based upon qualifications and experience commensurate with the size, complexity and profile of the project. All OMB Exhibit 300 level projects must have a Level III master project manager and alternate project manager assigned. A Level II master project manager should be assigned to projects of medium to large size/complexity or to those subprojects that fall under an OMB Exhibit 300 initiative. Level I master project managers are qualified to manage small projects with a short duration. The project manager should be selected as early in the project life cycle as possible. The Project Manager should have broad authority over the entire project. Senior management should empower the Project Manager to take actions necessary to complete the project successfully. This includes the authority to make design decisions during development, as well as the ability to control requirements, budget, schedule, resources, and product quality. Assignment of the Project Manager should take place as early as possible. It is especially important the Project Manager conduct the planning phase of the project. The Project Managers understanding of the projects planning process and trade-offs can be invaluable to team members and matrixed support personnel as they come on-board. That understanding of how we got here will also have a beneficial impact on the decisions made during project execution. One EA/Enterprise Architecture From the perspective of the One- EA, at Milestone 0, PMs are expected to focus on the information relevant to their respective proposed new projects in row 1 of the EA Zachman Framework. This information is described in Chapter 3 of version 2.1 of the One Enterprise Architecture. Chapter 3 provides a delineation of the business of the Department from a business-focused, top-down, enterprise-wide perspective. IT Operations Considerations Projects that will involve telecommunications and operations infrastructure should consider the following questions leading up to Milestone 0: Network Capacity Planning: Will the project use the data network for its operation? What is the projects conceptual data network environment? What metrics were used to define this environment for appropriate network execution? Has this been provided to the Capacity Planning group? Significant Project Management Activities The following is a summary listing of the significant project management activities and outputs for Step 0. Concept Paper Milestone 0 Briefing and Decision Memo Project Manager Selection Responsibility Assignment Matrix The Responsibility Assignment Matrix below is provided as a best practices tool that the PM can adapt and fill out for the appropriate tasks and responsibilities of his or her project. For additional guidance, the PM should refer to the appendices of this guide and consult his or her Administration or Staff Office PMO. Step 0 - Concept Definition Deliverable /Artifact Responsible D = Develop or Designate, S = Support, C = Concur, A = Approve Business Program Project Project Sponsor Manager Manager Team
Task
Stakeholders EIB / / OI&T SMC
Concept Paper
Milestone 0 Briefing
Milestone 0 Decision Memo
Describe Statement of Need Describe how the project will solve the problem Describe acquisition strategy Determine and describe costs for five year rough order of magnitude Determine and describe rough cost estimate for total project Describe benefits the project will bring to the organization Create briefing slides Seek Administration approval Schedule Committee briefing Present briefing to Committee Draft Decision Memo Sign Decision Memo Accomplish Decision Memo tasks
CONCEPT DEVELOPMENT
Step 1: Concept Development In Step 1, the predominate IPMC process group is Planning. (See Appendix B for a detailed discussion of the Planning process group.) During Concept Development, the project manager accomplishes the detailed planning to prepare for project execution. It is here that the project manager develops the project management plan, including the project Work Breakdown Structure (WBS) that communicates the specifics of the project scope and the requirements of the product or service that the project will produce. With an understanding of the project scope the team prepares the project master schedule and time phased budget that become the basis for project performance measurement (such as earned value management). During the concept development phase processes are put in place that will insure close control over the project scope, schedule and budget. Other processes are initiated to identify and assess
project risks and insure product quality. Specific strategies are developed for the acquisition of project labor and materials. It is during this phase that the project manager or project sponsor ensures senior officer and business owner approval of the project scope, schedule, budget, risks, acquisition strategy, and product requirements. A best practice is to have the appropriate senior officer(s) and business owner actually sign the Project Management Plan and subordinate plans that contain the above information. Important distinctions exist between Step 1 Concept Development tasks and the tasks required to prepare and communicate information for the Exhibit 300 process (See Appendix D for a more detailed discussion of the Exhibit 300). The major distinction is that the Step 1 Concept Development process is goal driven, with milestones being reached after intermediate project goals are achieved; while the Exhibit 300 process is an annual process, requiring actions throughout the year to meet OMB submission dates. In the Step 1 Concept Development phase the project plans are created to control the project. This is also the period of time when the groundwork is laid for Exhibit 300 reporting by entering the project planning data into the project management software. Milestone I: Prototype Development Approval The Milestone I review is intended to have the Project Manager address areas necessary to warrant approving the commitment of resources to a prototype or pilot effort. At Milestone I, the PM demonstrates a well-founded business case for the effort. Prototype efforts are encouraged within VA, as a general principle, in order to speed time to market and to increase the likelihood that the delivered product will fit the end users true needs. For certain projects, the project requirements and maturity of the technology will have already been established. In these cases, the project may proceed to a combined Milestone I/II review. Milestone I includes development of the Exhibit 300, either a Planning Application or a Full Acquisition. The applications can be combined depending on whether preliminary funding or full funding is being requested. If preliminary funding for project development is needed, a preliminary Exhibit 300, the Planning Application should be prepared. The Planning Application will be reviewed by the Office of Information and Technology (technical review), the EIB Panel (strategic and financial review), the EIB, and the SMC (if required) for approval and funding. If full funding is needed for the upcoming budget year a complete Exhibit 300 Full Acquisition should be prepared. The Exhibit 300 will be reviewed by the Office of Information and Technology (technical review), the EIB Panel (strategic and financial review), the EIB, and the SMC (if required) for approval and funding. Planning Application (Exhibit 300) for Preliminary Funding: The Planning Application further defines this concept. It also includes a high-level evaluation of alternatives for an IT solution. The document should address functional, security, performance, and reliability requirements, concept of operations, high-level use cases, business case, technical approach, acquisition, testing and fielding strategy, training and documentation requirements, schedule, staffing, and skills requirements. Comparisons of alternative concept solutions normally result in identification of the most promising system concept. The Exhibit 300 also needs to include Return-on-Investment and Cost Benefits analysis estimates. If the project is approved, preliminary funding will be provided and the project will be included in the budget request. The, Full Acquisition Exhibit 300, will be required for the project by the following summer, before the budget year for which it is funded begins. This should document in more detail the scope, schedule, cost resource requirements, test strategy, risk profile and mitigation plan, project organization and staffing, operational support strategy, detailed life-cycle cost, and detailed business case. OMB Circular A-11, Part VII, Section 300 provides full instructions for this document. Concept Development for Full Funding: If full funding is needed for the upcoming budget year a complete Exhibit 300 (Full Acquisition) should be prepared. At Milestone I, additional documentation (in addition to the information from Milestone 0) is required that supports Exhibit 300, such as: Completed Row 2 of the Zachman Framework, the organizational business processes from the perspective of line and staff managers, --revalidating the information relative to the EA addressed in the Milestone 0 review, showing how the project fits into the allocated functional baseline and integration points established in row 2 of the framework. In addition, the Project Manager is expected to take the functional requirements and integration points contained within row 2 and the Technical Reference Model (TRM) and standards profile and begin development of the functional and technical requirements baseline for their project that is the subject of row 3 of the framework, the IT system from the perspective of the Project Manager. An initial change management and communications plan A project organization plan and staffing inventory An updated mapping of the project concept to Performance Goals A prototype development work plan and staffing schedule In addition, the project may need to be presented to the administration if required. IT Security 4.3.1 System Security Plan (SSP). The SSP documents the security risks (not project risks) and overall system security categorization in terms of potential level of impact (Low, Moderate, High) for each of the security objectives of confidentiality, integrity, and availability of federal information and information systems. The plan documents the security processes that will be implemented and tested in the Security Controls Assessment (SCA) plan. The SCA plan is the basis for System Certification and Accreditation and acceptance of residual security risk. The System Security Plan includes the following components: System Boundary Summary Describes what constitutes the system for the purposes of the SSP. IT System Security Categorization and Sensitivity The System Security Categorization classifies the system as a Major Application or a General Support system. The Security Sensitivity identifies the potential level of impact as Low (limited impact), Moderate (serious impact), or High (severe or catastrophic impact) for confidentiality, integrity, and availability of federal information and information systems. The categorization and sensitivity determines the minimum management, operational, and technical security controls required for information and information systems. See Federal Information Processing Standards (FIPS) 199 Standards for Security Categorization of Federal Information and Information Systems. (http://csrc.nist.gov/publications/fips/fips199/FIPS-PUB-199-final.pdf). Guidance on the use of FIPS 199 can be found in NIST Special Publication 800-60. 4.3.2 Configuration Management Approach Develop the approach for managing change over the development and production life cycle of the system application and operating system software, configuration settings, interfaces, and hardware. Note: A security risk assessment differs greatly from a project risk assessment. A security risk assessment assesses the security risks to the information system itself whereas a project risk assessment assesses the project risks. 4.3.3 Contingency and Disaster Recovery Approach Prepare an approach for responding to man-made or natural incidents or disasters. 4.3.4 Federal Information Security Management Act (FISMA) Self-Assessment and Plan of Action and Milestones (POA&M). FISMA requires the completion of an annual self-assessment to identify security deficiencies. Many organizations have an automated tool to facilitate completion of the survey and tracking of deficiencies in the form of P0A&M that are submitted to OMB quarterly. OMB guidance also requires POA&Ms to be addressed by system owners/program managers in order to obtain a security score of 4 in the Exhibit 300 process. 4.3.5 Preliminary Security Risk Assessment. The basic assessment of the confidentiality, integrity, and availability risks that help determine what security controls are necessary to protect the information contained in this information system. Completing the FISMA self-assessment constitutes a preliminary risk assessment. See Appendix I for Federal and VA-specific guidance on IT Security deliverables for this stage. Privacy Impact Assessment
The E-Government Act of 2001 (E-Gov) requires a Privacy Impact Assessment (PIA) to be conducted for any new information collections. Primarily, the PIA formalizes and documents how private data is to be protected. It must describe: What information is to be collected, Why the information is being collected, The intended use of the information, With whom the information will be shared, What notice or opportunities for consent would be provided to individuals regarding what information is collected and how that information is shared, How the information will be secured, and Whether a system of records is being created under the Privacy Act (5 U.S.C. 552a) The PIA is to be initiated in the early stages of system development and completed as part of the required System Development Life Cycle reviews. Privacy must be considered when requirements are analyzed and decisions are made about data usage and system design. Details on the PIA, its privacy principles, and steps for completing one can be found at: http://www.cio.gov/documents/pia_for_it_irs_model.pdf One Enterprise Architecture From the perspective of the One- EA, at Milestone I PMs are expected to focus on the information relevant to their project in row 2 of the One EA Zachman Framework. This information is described in Chapter 4 of version 2.1 of the One Enterprise Architecture. Chapter 4 defines the functionally of information systems in terms of their target processes, functions and sub functions, data, and their integration points with other information systems both inside and outside the enterprise. IT Operations Considerations Projects that will involve organizational telecommunications and operations infrastructure should consider the following questions leading up to Milestone I: Network Capacity Planning: What type of transactions types will the project use: Interactive? File transfer? HTTP? What are the projects data network traffic characteristics per transaction type: Traffic volumes and transmission rates? Traffic at peak and non-peak business hours? What is the projects data network load distribution: Basic traffic flow? User count and locations for application execution and end user access? Potential high traffic points? What communications protocols will the project use? What is the projects network availability objective? What is the projects scalability objective? What is the projects interoperability with existing applications? What is the projects required network environment for prototype testing? Step 1: Significant Project Management Activities The following is a summary listing of the significant project management activities and outputs for Step 1. OMB Exhibit 300 Project Management Plan (including WBS, Scope Statement, Project Schedule, and Cost Estimates) Scope Management Plan Schedule Management Plan Staffing Management Plan Integrated Change Control Plan Cost Management Plan Communication Plan Procurement Management Plan IT Security Deliverables (See 4.3.) Privacy Impact Assessment Milestone I Briefing and Decision Memo
Step 1: Responsibility Assignment Matrix The Responsibility Assignment Matrix below is provided as a best practices tool that the PM can adapt and fill out for the appropriate tasks and responsibilities of his or her project. For additional guidance, the PM should refer to the appendices of this guide and consult his or her Administration or Staff Office PMO. Step 1 Concept Development
Responsible Deliverable /Artifact Task D = Develop or Designate, S = Support, C = Concur, A = Approve Business Program Project Project Stakeholders EIB / Sponsor Manager Manager Team / OI&T SMC
OMB Exhibit 300
Project Management Plan OBS WBS Schedule Cost Estimate
Describe how the project supports the Presidents Management Agenda. Describe the project performance goals. Describe the program management governance, team, and processes. Conduct and describe an analysis of project alternative solutions. Describe the project life cycle cost formulation. Describe the results of the project risk assessment included mandated OMB risk areas. Describe the project acquisition strategy and accommodation Describe the project performance based management system with emphasis on the Earned Value Measurement System (EVMS). Describe adherence to the Enterprise Architecture (EA) and Capital Planning and Investment Control (CPIC) process. Describe the project security and privacy action plan. Approve Exhibit 300 Describe project: description, goals, objectives, strategies, requirements, etc. Develop project Organizational Breakdown Structure (OBS). Develop project Work Breakdown Structure (WBS). Develop detailed project schedule. Develop project cost estimate using OBS, WBS, and schedule. Step 1 Concept Development (continued) Responsible D = Develop or Designate, S = Support, C = Concur, A = Approve
Deliverable /Artifact
Task
EIB Business Program Project Project Stakeholders / Sponsor Manager Manager Team / OI&T SMC
Scope Management Plan
Schedule Management Plan
Staffing Management Plan
Integrated Change Control Plan
Describe project: description, goals, objectives, strategies, etc. Describe process used to develop the WBS. Describe the process used to baseline the WBS. Describe the WBS change control process. Describe project: description, goals, objectives, strategies, etc. Describe the use of Software to develop and manage project schedules. Describe the schedule change management process. Describe how schedules will be used for performance measurement. Describe schedule status reporting. Describe project: description, goals, objectives, strategies, etc. Describe the project organization. Describe the roles and responsibilities for team members and stakeholders Describe project resource requirements by functional areas Describe known resource constraints, such as scarce skills Describe the development and frequency of staffing reports Describe project: description, goals, objectives, strategies, etc. Describe the change review and approval process in areas such as scope, schedule, cost, configuration management, technical design and test. Describe the baseline process and change control thresholds such as a work package exceeding budget by 10%. Describe change identification, documentation, implementation and reporting. Step 1 Concept Development (continued) Responsible D = Develop or Designate, S = Support, Task C = Concur, A = Approve Business Program Project Project Sponsor Manager Manager Team Describe project: description, goals, objectives, strategies, etc. Describe the cost estimating process. Describe the development and maintenance of a time-phased budget. Describe the financial cost maintenance to include responsibilities, reporting, and the management and budget processes Describe cost performance reporting with emphasis on the management and budget process and the Earned Value Management System. Describe cost reporting including the cost performance indexes and variances. Describe the process for managing cost and budget changes. Describe project: description, goals, objectives, strategies, etc.
Cost Management Plan
Communications Management Plan
Identify the project stakeholders and related information (title, etc.). Describe project reports, development process, and responsible personnel. Describe information accessibility, filing, document security, etc. Step 1 Concept Development (continued) Responsible D = Develop or Designate, S = Support, Deliverable Task C = Concur, A = Approve /Artifact Business Program Project Project Stakeholders EIB / Sponsor Manager Manager Team / OI&T SMC Risk Management Plan Describe project: description, goals, objectives, strategies, etc. Describe risk identification, documentation, and assessment. Describe risk triggers, such as missed delivery dates, etc. Describe the risk analysis process, both qualitative and quantitative. Describe the development of a risk severity grid to aid analysis. Describe risk response planning to minimize the affects of risks. Describe risk documentation and reporting, such as tools like the risk register and risk maintenance software. Describe risk control using a reassessment and validation process. Quality Management Plan Describe project: description, goals, objectives, strategies, etc. Describe the organization quality policy, such as document preparation standards or contracting standards. Describe quality management approach to implementing quality management on the project. Describe the implementation of the quality assurance process. Describe the implementation of the quality control process. Describe the change control process for managing changes to the quality process and standards. Describe project team responsibilities as they relate to quality tasks. Step 1 Concept Development (continued) Responsible D = Develop or Designate, S = Support, Task C = Concur, A = Approve Business Program Project Project Stakeholders EIB / Sponsor Manager Manager Team / OI&T SMC Describe project: description, goals, objectives, strategies, etc. Describe the anticipated procurements including preparation lead times and project team responsibilities. Describe how the IPMC Acquisition Process will be employed to approve, initiate, and sustain project procurement efforts. Describe solicitation planning, such as Statement of Work development and the evaluation strategy. Describe the process for contract administration. Describe the process for contract closeout Create briefing slides Seek Administration or Staff Office approval Schedule EIB briefing with OI&T Present briefing to EIB Draft Decision Memo Sign Decision Memo Accomplish Decision Memo tasks
Deliverable /Artifact Procurement Management Plan
Milestone I Briefing
Milestone I Decision Memo
SYSTEM DESIGN AND PROTOTYPE

Step 2: System Design and Prototype In Step 2, the predominate IPMC process groups are Executing and Controlling. (See Appendix B for a detailed discussion of the Executing and Controlling process groups.) At the completion of Step 1 and as a result of the Milestone I briefing, approval is received to proceed forward with Step 2 tasks to design and prototype the system. As an outcome of this approval, planning artifacts are established as baselines and provided to the project team to guide the work effort. During Step 2 the project manager begins executing the approved project management plan and manages work efforts to design the system. These design activities will result in a validation of the approved and published baseline, as each component is detailed and vetted with the appropriate stakeholders. Typically, there are numerous requests for change during this phase, and the project team utilizes the change control procedures in the scope management plan to assess, decision and implementation change proposals. The project manager is required to report the impact of scope changes in the project Milestone II briefing. The system design may take the form of a prototype system, proof of concept, a demonstration or, depending on complexity, the first production article. Step 2 tasks lead to the Milestone II briefing where the results of the initial design effort are reported and the decision is made to continue the project into system development. Milestone II: System Development Approval If the prototype development funding is approved, the system development effort is authorized and begins. During System Definition a prototype is tested and further refinements are made to the various plans and documents based on information learned from the prototype. Once system development is approved, it will be funded and the systems life cycle development and testing can begin.
IT Security It is critical that security be included in the design stage of a new application or information system. Security can be designed into a new system at a lower cost in the design phase than attempting to paint it on later in the life cycle. The security Certification and Accreditation (C&A) process is a formal methodology that examines security risks, threats, and vulnerabilities, as well as sensitivity and criticality of information, to determine what security controls are necessary to mitigate risk to an acceptable level. The process is established in many organizational directives and During this phase of the project, security documentation should continue to be updated as necessary. The following documents and processes, should be addressed: Updated System Security Plan (SSP) Security Risk Assessment (RA) Contingency Planning (CP) and Disaster Recovery Plans (DRP) Configuration Management Plan (CMP) Interconnection Security Agreements (ISA) for systems that interconnect to other systems An Interim Authority to Operate (IATO) which may be required if the prototype or test system will attach to a production network or use live test data during its development Security Controls Assessment (SCA, a.k.a., Security Test and Evaluation, or ST&E) Organizational Enterprise Architecture At Milestone II, to gain approval for full-scale systems development or acquisition, PMs are expected to focus primarily on rows 3 and 4 of the Framework. This is largely addressed in Chapter 5 of version 2.1 of the One Enterprise Architecture. PMs are expected to revalidate the information addressed at Milestones 0, I, and II. IT Operations Considerations Projects that will involve organizational telecommunications and operations infrastructure should consider the following questions leading up to Milestone II: Network Capacity Planning: What are the projects performance requirements: Average expected volume of traffic? Expected peak volume of traffic? Average expected network latency? Maximum network latency allowed? What are the projects availability requirements: Classes of service for different types of traffic? Different availability areas? What are the projects scalability requirements: Expected extensions or addition of sites through life cycle? Expected volume of new users? Expected traffic volume change? What existing applications will be phased out by this project? Has the project provided software and scripts to model the application(s)? What are the special network management features required by the project: Can the project be supported with existing tools? Is training required to support this project? Is new staff required to support this project? Step 2: Significant Project Management Activities The following is a summary listing of the significant project management activities and outputs for Step 2. Updated Project Plans Updated system security documentation Change Requests Monthly Performance Reports Milestone II Briefing and Decision Memo Step 2: Responsibility Assignment Matrix The Responsibility Assignment Matrix below is provided as a best practices tool that the PM can adapt and fill out for the appropriate tasks and responsibilities of his or her project. For additional guidance, the PM should refer to the appendices of this guide and consult his or her Administration or Staff Office PMO. Step 2 System Design and Prototype Responsible D = Develop or Designate, S = Support, C = Concur, A = Approve Business Program Project Project Sponsor Manager Manager Team
Task
Updated Project Plan Change Control
Develop and implement a process to insure the project management plan and the subsidiary plans are continuously updated and kept current. Review the change control process and requests to insure that project changes in scope, schedule, cost, quality, and risk are being captured, assessed, reported, and approved. Prepare and score template for the Office of Information and Technology.
Monthly Performance
Reports
Consolidate project data for presentation to SMC Act on decisions and direction received as a result of the monthly performance review. Step 2 System Design and Prototype (continued) Responsible D = Develop or Designate, S = Support, C = Concur, A = Approve Business Program Project Project Sponsor Manager Manager Team
Task
Milestone II Briefing
Milestone II Decision Memo
Create briefing slides Seek Administration or Staff Office approval Schedule EIB briefing with OI&T Present briefing to EIB Draft Decision Memo Sign Decision Memo Accomplish Decision Memo tasks
SYSTEM DEVELOPMENT AND TESTING

Step 3: System Development and Testing In Step 3, the predominate IPMC process groups are Executing and Controlling. (See Appendix B for a detailed discussion of the Executing and Controlling process groups. )Within this step, system development translates the design approach into a stable, interoperable, producible, supportable, and cost effective design and production system; and demonstrates system capabilities through testing. Key issues to be addressed are whether the project has adequately demonstrated through testing that the system meets its functional and performance requirements and whether the system is adequately supported by documentation, training, etc., (i.e., whether the system to be deployed meets effectiveness and suitability requirements). Testing efforts are expanded and compliance with the enterprise architecture, environmental and security requirements are of prime importance. During Step 3 the Project Manager makes sure the execution and control processes are effective and producing the desired results. Step 3 activities that lead to the Milestone III Briefing relate to the project Executing and Controlling phases of the PMEPG. This section describes the events that take place, roles and responsibilities, and the process relationships within these phases. Milestone III: System Deployment Approval Milestone III is intended to have the Project Manager addresses a basic set of questions necessary to warrant approval to deploy the system. Key issues to be addressed are whether the project has adequately demonstrated through test that the system meets its functional and performance requirements and whether the system is adequately supported by documentation, training, IT security, etc. Depending on the nature of a specific project, this decision Milestone can also be split into a Milestone IIIa for approval of limited initial deployment, and a Milestone IIIb for full, enterprise-wide deployment. Complete System and Technical Design Accomplishing the project goals in accordance with user requirements, security requirements, statutory requirements, telecommunication requirements, and the enterprise architecture is manifested in the system and technical design. Along with schedule and cost performance the results of project design and test efforts will be reported at the Milestone 3 Briefing. Specific areas of interest include reliability, performance, stress and user acceptance testing; and security certification. The briefing will include the project risk profile; cost assessments; and an assessment of change management processes. IT Security In accordance with security directives, the Project Manager should submit a security Certification and Accreditation (C&A) package, to the Office of Cyber Security (OCS) for new information systems. OCS provides support to the System Owner and Project Manager for accomplishing the C&A process. The C&A process ensures that systems security controls meet all applicable requirements and are in place and working properly. Security is a significant topic of the Milestone III Briefing. A Full Authority to Operate (FATO) is necessary prior to a system going into production. Please see Appendix I for more information. One Enterprise Architecture At Milestone III Project Managers must have completed rows 4 and 5 of the Zachman Framework, thereby validating that they have continued to respect the allocated functional baseline established for the project at Milestone I. Additionally, they should have defined the performance metrics to be collected during in-service operation of the system as the basis for evaluating goal achievement in row 6 of the Zachman Framework. Subsequently, during Milestone IV post implementation reviews, PMs are expected to report on the actual performance of the information systems in these areas. IT Operations Considerations Projects that will involve organizational telecommunications and operations infrastructure should consider the following questions leading up to Milestone III: Network Capacity Planning: What are the projects final performance requirements for: Network availability? Network latency? Network packet loss? Network jitter? Network quality of service? What are the projects network performance metrics to be collected during in-service operation? Step 3: Significant Project Management Activities
The following is a summary listing of the significant project management activities and outputs for Step 3. Updated Project Plans Change Requests System and Technical Design (as defined by the Office of Enterprise Architecture) Security Certification and Accreditation (See Appendix I) Monthly Performance Reports Milestone 3 Briefing and Decision Memo Step 3: Responsibility Assignment Matrix The Responsibility Assignment Matrix below is provided as a best practices tool that the PM can adapt and fill out for the appropriate tasks and responsibilities of his or her project. For additional guidance, the PM should refer to the appendices of this guide and consult his or her Administration or Staff Office PMO. Step 3 System Development and Test Responsible D = Develop or Designate, S = Support, Task C = Concur, A = Approve Business Program Project Project Sponsor Manager Manager Team Insure the project management plan and the subsidiary plans are continuously updated and kept current. Review the change control process and requests to insure that project changes in scope, schedule, cost, quality, and risk are being captured, assessed, reported, and approved. Prepare and score template for the Office of Information and Technology. Consolidate project data for presentation to SMC Act on decisions and direction received as a result of the monthly performance review. Create briefing slides Seek Administration or Staff Office approval Schedule EIB briefing with OI&T Present briefing to EIB Draft Decision Memo Sign Decision Memo Accomplish Decision Memo tasks
Updated Project Plan Change Control
Monthly Performance Reports
Milestone III Briefing
Milestone III Decision Memo
SYSTEM DEPLOYMENT
Step 4: System Deployment In Step 4, the predominant IPMC process groups are Executing and Controlling. (See Appendix B for a detailed discussion of the Executing and Controlling process groups.) At this point in the life cycle, the system that has been developed is being deployed. The System Deployment phase of the life cycle is the culmination of the conceptual planning, system design, and assembly efforts. From the systems viewpoint the deployment tasks include training, hardware installation, system documentation reviews, customer feedback, and system effectiveness/verification reviews. From the project management viewpoint tasks include assessing the deployment schedule/WBS for detail and scope control; understanding deployment risks, cost and resource control (next to project planning, this can be the highest cost step of the project life cycle); insuring quality, communications and feedback management; and finally, collecting lessons learned and initiating closeout activities. Essentially, during the deployment step the project manager uses and updates management processes implemented during the earlier project steps. IT Security Change management practices must track all modifications to the application, including the security concerns. Significant changes require re-evaluation of the operating risks, security deliverables (such as the system security plan), FISMA survey, risk assessment, and security controls assessment. These in turn may trigger a revision to the systems C&A package. See Appendix I for additional information. Step 4: Significant Project Management Activities The following is a summary listing of the significant project management activities and outputs for Step 4. Updated Project Plans Change Requests Monthly Performance Reports Step 4: Responsibility Assignment Matrix The Responsibility Assignment Matrix below is provided as a best practices tool that the PM can adapt and fill out for the appropriate tasks and responsibilities of his or her project. For additional guidance, the PM should refer to the appendices of this guide and consult his or her Administration or Staff Office PMO. Step 4 System Deployment Responsible D = Develop or Designate, S = Support, C = Concur, A = Approve
Task
Business Program Project Project Sponsor Manager Manager Team Updated Project Plan Change Control Insure the project management plan and the subsidiary plans are continuously updated and kept current. Review the change control process and requests to insure that project changes in scope, schedule, cost, quality, and risk are being captured, assessed, reported, and approved. Prepare and score template for the Office of Information and Technology. Consolidate project data for presentation to SMC Act on decisions and direction received as a result of the monthly performance review.
Monthly Performance Reports
SYSTEM OPERATION
Steps 5: System Operation In Step 5, the predominate IPMC process group is Closing. (See Appendix B for a detailed discussion of the Closing process group.) Generally a project does not include the repetitive and on-going nature of system operations. But it is also clear that many project management processes should carry on through the life cycle of the system. For this reason, especially on large, multi-year, high dollar projects, project offices will continue to operate during the operational phase. Also, these offices manage small projects that are used to implement improvements to the major systems. This process is described as management by projects which is a method to apply project management techniques to an on-going process. It is good to understand that various life cycles and processes call this period of time by different names. The IPMC Integrated Management process calls Step 5 System Operation or the operational phase; the milestone review process conducts a Post Implementation Review. Other terms include the production phase or as with the OMB Exhibit 300 process Steady State. Processes that remain active during the operational phase are primarily related to the fiscal year funding cycle. They may include performance measurement, life cycle cost formulation, monthly status reviews, staffing planning, communication planning, and scheduling and scope management. There is also the project closeout report that should be accomplished after the initial deployment regardless of on-going operations. Organizations depend on the lessons learned to identify training requirements, identify and mitigate risks and improve project management. Milestone IV: Post Implementation Review The Post Implementation Review evaluates the project history and lessons learned to identify training requirements and knowledge to be used by future project teams to identify and mitigate risks, refine estimating parameters, and improve project management. Milestone IV, Post Implementation Review, is intended to assess the in-service effectiveness and suitability of an IT system as a continuation of the effectiveness and suitability assessment undertaken in Milestone III. This includes assessment of the success in meeting the fielding plans, meeting performance metrics, cost, schedule, security and projected return on investment. It also includes an assessment of the adequacy of training, documentation and maintenance support for the IT system, as well as whether any changes are required to the IT system. The Milestone IV briefing needs to be scheduled after the system has been in operation long enough to provide a good basis for analysis, usually 6 to 18 months after becoming operational. After the initial Milestone IV review, subsequent Milestone IV reviews are conducted every three years. OI&T is also scheduling Milestone IV reviews for legacy systems as a means of evaluating their current status. IT Security An Authority to Operate (ATO) granted is valid for no more than three years, or when significant changes cause an unacceptable increase in operating risk to the system, whichever comes first, thus triggering the C&A cycle. Moreover, the IPMC process requires that a self-assessment be conducted annually, that any identified security weaknesses are tracked and remediated, and that risk is continually monitored and managed in order to identify and mitigate security risks to an acceptable level. Disposal measures are required if an application is shut down. Please see Appendix I for more information. One Enterprise Architecture From a One EA perspective, the PIR provides important feedback to assess not only whether the system continues to be in compliance with the One EA, but also whether in-service experience of the system indicated a need for change in the EA itself. To accomplish this at Milestone 4, PMs must have completed row 6. IT Operations Considerations Projects that will involve telecommunications and operations infrastructure should consider the following questions leading up to Milestone IV: Network Capacity Planning: Are the entire projects final network performance requirements fully met? Are the projects network scalability requirements scheduled? Step 5: Significant Project Management Activities The following is a summary listing of the significant project management activities and outputs for Step 5. Post Implementation Report Milestone IV Briefing and Decision Memo Closeout Report Monthly Performance Reports
Step 5: Responsibility Assignment Matrix The Responsibility Assignment Matrix below is provided as a best practices tool that the PM can adapt and fill out for the appropriate tasks and responsibilities of his or her project. For additional guidance, the PM should refer to the appendices of this guide and consult his or her Administration or Staff Office PMO. Step 5 System Operation
Task
Responsible D = Develop or Designate, S = Support, C = Concur, A = Approve Business Program Project Project Sponsor Manager Manager Team
Closeout Report: Administrative Closure
Closeout Report: Contract Closure Monthly Performance Reports
Prepare a project description including current requirements and concept of operation. Describe how the objectives of the project were met. Describe the archiving of project documentation. Describe the lessons learned from the project. Describe the plans for the Post Implementation Review (PIR) Describe the closeout of all financial activity and records. Describe the results of the final performance analysis Describe any open contract issues. Describe the collection and audit of contract documents Prepare and score template for the Office of Information and Technology. Consolidate project data for presentation to SMC Act on decisions and direction received as a result of the monthly performance review. Step 5 System Operation (continued) Responsible D = Develop or Designate, S = Support, C = Concur, A = Approve Business Program Project Project Sponsor Manager Manager Team
Task
Milestone IV Briefing / Post Implementation Review
Milestone IV Decision Memo
Create briefing slides Seek Administration or Staff Office approval Schedule EIB briefing with OI&T Present briefing to EIB Draft Decision Memo Sign Decision Memo Accomplish Decision Memo tasks
ABOUT THIS IPMC EXECUTIVE SUMMARY

This handbook is derived from actual reviews of mission critical information systems projects. It sets out a concise, high-level framework for project management. Within this framework is provided a series of practical suggestions for Federal executives involved in management of mission critical information systems. The following pages are not intended to be exhaustive. Rather, they provide a quick, sensible overview of useful practices and tools for the effective management of information systems projects.
Contents
Executive Summary: Making Projects Work Meeting the Mission Align the Project Mission with the Agencys Mission Know the Project Stakeholders Amplify the Voices of Your Customers Maintain High-Level Communication About the Project Mission Strategies Set Realistic Business Objectives Define a Sound Architecture Gain Agreement on the Project Plan People Organizational Leadership Project Leadership Project Team Members Processes Planning Managing Technology Controlling Tasks Appendix: Tools for the Toolbox
EXECUTIVE SUMMARY: PROJECT MANAGEMENT Project management delivers results. The practice of project management can focus efforts on your mission by aligning priorities, leveraging resources, and delivering services to customers. A successful project translates a broad public mission into concrete results and outcomes. The following issues are critical for making projects work.
Meeting the Mission: Why are you undertaking this project in the first place? Who are the stakeholders and the customers? What are their expectations for the project? How does the project mission fit into your agencys mission? All activity on a successful project supports a well-bounded, agreed upon mission. As a project progresses, it is often necessary to take a step back and realign individual project elements with one another and with the project mission. Successful projects strike a balance among strategies, people, and processes. Strategies: What do you want to accomplish with this project? Articulate the business objectives, the technical environment, and the project plan. People: Who are the project participants, and how are they organized? Communicate with the organizational leadership, the project leadership, the team members, the stakeholders and the customers. Processes: How will the project accomplish its objectives over time? Define the planning processes, the technology management, and the control of tasks. Project management provides a proven way to set priorities and achieve results. Make use of project management to gain a realistic perspective on the "big picture," to maintain focus on priorities as they evolve, and to help sort out what must be done to make the project a success.
SUMMARY OF PM
Meeting The Mission Its why youre here Align the Project Mission with the Agencys Mission
What is your agencys mission? What is the relationship of your project to your agencys mission? Project activities need to support this mission. Know the Project Stakeholders A strong project mission can not be created in a vacuum. Who are the people with an interest in the outcome of the project? What are their common expectations? Stakeholders expectations are rarely spelled out in legislation, executive orders, or formal memoranda. Amplify the Voices of Your Customers Who will be paying for this project? Who will actually be using the systems and processes being designed? Clarify the business priorities of these customers and their criteria for success. Actively and emphatically communicate this information. Do this for customers inside the organization as well as those outside the organization. Maintain High-Level Communication About the Project Mission Communicate steadily with stakeholders and customers throughout the project. This will help to manage their expectations and requirements over time. Design project development so that requirements and expectations can be reconfirmed at regular junctures. Periodically check to see that stakeholders and customers understand and support changes, delays, and new developments.
One reviewed project was situated within an agency which had recently undergone major budget reductions and large-scale structural changes. Because senior management was unclear about customer expectations, the agency had been unable to articulate a clear strategic view of the project and its role in the new environment. Customers had insufficient information to guide them in improving work processes. The commission recommended that the agency work with customers to accelerate development of a new strategic plan, and that it publish a concept of operations to communicate how the system would operate in future years.
One reviewed project reversed its declining fortunes by making substantial revisions to project requirements several years into the project. Project leaders had conducted an evaluation of requirements, leading to large but necessary reductions in both scope and requirements. Though initially disorienting, this reduction did much to stabilize the project, leading to a significantly improved outlook for project success.
Strategies What do you want to accomplish?

Set Realistic Business Objectives What are the common business needs of the organizations that will depend on the system? What accomplishments will be critical for the project to be considered successful? Define project boundaries at the outset, and use this definition to manage requirements throughout the project. A clear definition of business success will also help ensure that project efforts support the agencys strategic plan. Define a Sound Architecture Drive Toward an Enterprise-Wide Business Model Ensure that the business model meets business objectives while remaining within the projects scope. Publish a detailed concept of operations which distinguishes clearly among the business model, the layout and relationship of systems and communications, and the technical architecture. These should be anchored in an enterprise-wide IT strategy. Implement Systems Incrementally Work toward a systems implementation that will deliver, in twelve months or less, incremental, useable levels of functionality which support specific business objectives. The detailed concept of operations should explain how the architecture will satisfy these objectives and how it will prioritize them. It should also communicate responsibilities for implementing and managing the architecture. Coordinate Technical Standards Which standards are essential to ensure that the technical architecture ultimately supports business objectives? Define these, paying particularly close attention to technical interfaces. Develop a plan to ensure compliance with architecture standards. The technical architecture must be documented to ensure its consistency with the overall agency-level design. Gain Agreement on the Project Plan The project plan formally captures and documents agreements among customers, stakeholders and project participants. Secure an informed agreement up front, and maintain this agreement throughout the project life. This will ensure that the project meets expected results. This will also help align the project with the organizations business plans and supporting IT plans. Over time, manage the project scope carefully, since there will be a tendency for different areas of the project to acquire their own divergent momentum.
The Commission encountered a project which, after eight years of planning, had yet to define an architecture. The project had come to rely heavily upon the functional program knowledge of the technical contractor, and there were insufficient technical resources involved in crucial technology decision-making. The Commission recommended that the organization establish technical requirements for deliverables, define modular delivery of specified interim products, monitor product delivery, and generally strengthen the role of contract management.
The architecture should provide a focal point for project definition and clarity. Indeed, ambiguity surrounding this fundamental concept may be a clue that your architecture requires attention. One Commission-reviewed project exhibited a number of inconsistencies in its use of the term "architecture." This led to conflicting expectations when information about the architecture was disseminated among project participants. Upon closer inspection, the Commission found that the architecture required broad realignment with the organizations strategic plan and budget.
One Commission-reviewed project had negligible high-level involvement on the part of its organizational leadership. It turned out that no single individual was accountable for providing such leadership. Among other things, this explained the absence of a formal planning process and clear business objectives.
The Commission encountered one project which had clearly identified the information needs of key stakeholders, but was having great difficulty prioritizing these needs. The centralized organization running the project simply did not have the resources or the authority to provide an enterprise-wide solution to all of its widely distributed lines of business. Among other recommendations, the Commission noted the need to establish an agency-level CIO who could focus the project architecture on the most critical common needs of the different lines of business. The Clinger-Cohen Act identifies four core competency areas for CIOs: 1. Federal Information Resources Management Policy and Organizational Knowledge Information Resources Strategy and Planning IT Acquisition 2. Capital Planning IT Performance Assessment Capital Planning and Investment Assessment 3. Change Management 4. Managerial/Technical Professional Development and Training IT Topics IT Trends
People Understand the project participants

Organizational Leadership Listen to the Customer and Create a Vision The project sponsor manages high-level customer relationships, translating key customer expectations into a practical vision for the project. To be effective, this vision must be broadly communicated. Commit to the Project The most frequent cause of project failure is the lack of involvement of the organizational leaders. Ongoing involvement is crucial. It is critical to structure the project in such a way that go/no-go decisions may be made at highly visible milestones. Leadership commitment stabilizes the project so that it can accommodate changes over time. Leverage the Existing Organizational Structure The roles and responsibilities of the project and its partners are most effective when they correspond with the way in which the overall agency is managed. For example, in an organization in which field offices have a great deal of autonomy, a centralized approach to IT management could bring about unnecessary conflict. Empower the CIO
Project leadership does not simply appear; it must be nurtured. Among all of the projects reviewed by the Commission, those with the greatest chance for success were those which sought to grow and develop leadership competencies over the long run. Though many aspects of project management may be reduced to defined processes, the development of project management leadership competencies remains a difficult but worthwhile challenge.
One Commission-reviewed project exhibited no partnership among functional program leaders, IT managers and contract managers. Significant confusion resulted among both
Project Management The Chief Information Officer (CIO) position requires extraordinary qualifications in both IT management skills and general management skills. The CIO needs authority and visibility to guide the organization in key decisions. The CIO focuses on three things: Synergy. Bring realistic synergy to IT strategy by focusing disparate IT activities on their contribution to the organizations mission. Ensure that business objectives take precedence over technological advances. Direct architectural compliance across the enterprise. Create a formal strategic IT plan that reflects business priorities. Sharing. Leverage the centralized technical authority to reduce redundancy across different organizational units. Enable them to share systems and data, as well as IT training, approaches, and other commonly needed resources. Coordinate a coherent strategy for commercial off-the-shelf software. Seek to make the enterprise technologically seamless. Support. Establish complementary managerial and technical structures to provide support for critical enterprise functions. Do this in a way that provides different organizational units with the flexibility they require. Project Leadership Select a Strong Project Manager Empower a central point of responsibility for project decisions, and clearly distinguish this role from functional program management roles. Clarify the risks which the project manager is expected to manage strategically. "Leadership ability" is difficult to articulate, and even more difficult to find. At a minimum, it includes the following characteristics: Drive. Does the project manager have a strong desire to succeed? Ability to Build Consensus. Can the project manager get key individuals to work together towards common ends? Ability to Take Risks. Can the project manager recognize opportunities and find ways to seize them? Ability to Communicate. Is the project manager able to communicate clearly and convincingly to all parties? Experience. Does the project manager have a track record of success? Look for characteristics and experiences that relate directly to the project at hand. Technical Knowledge. Does the project manager possess demonstrated knowledge in the appropriate technical fields? Sense of the Big Picture. Does the project manager understand the project from a broad business perspective? Enable a Cooperative Environment Nurture cooperation among members of the leadership, including the project sponsor, functional program manager, project manager, contracting officer and contractor. Create a learning environment which attracts individual skills to the table. Actively encourage team members to innovate by rewarding judicious risk-taking. Ensure Accountability The project manager is responsible for results. Successful project managers actively encourage team members to make minor challenges known before they become major problems. The project needs a "truth culture" let the messenger live. Stress the importance of accountability by systematically introducing constructive criticism into current practices. One recommended technique is to outsource for independent validation and verification (IV&V) support. It is critical for the executive leadership to listen to IV&V advice. Another technique is to create an anonymous channel for reporting problems. Project Team Members Get Whats Needed to Succeed What are the competencies of the team? How does the staffing plan distribute these competencies against project tasks? Assess the teams particular strengths, then get the additional expertise needed. There may be a need to outsource for additional skills to round out the team. Balance the mix of management and technical expertise, and the mix of contractor and government personnel. Distinguish between critical strategic activities and tactical activities. Make use of consultants to leverage the teams capabilities. Keep the Core Team Together Maintain a commitment to the integrity of the core team. The project should include the project manager, the functional program manager, the contracting officer and other key players from project conceptualization through implementation. Empower a central point of responsibility for technical decisions, including standards and architecture. Monitor Team Productivity How does the level of effort contribute to project deliverables and results? How is the team progressing against the project plan? Perform periodic cost-benefit analyses and life cycle cost estimates. This information will be needed for go/no-go decisions at major project and contract milestones. Develop Competencies Over Time Invest in building competencies in key people. Institute and follow a formal plan for skills training and career development. Align the competencies of team members with the long-term needs of the project.
contractor and agency employees as to who made key decisions. In the absence of cooperative leadership, critical analysis of functional requirements was seriously lacking. The Commission recommended that the project not only clarify the respective roles of project team members, but that it reorganize its executive steering committee to make it truly accountable for all final project decisions. In the majority of reviews it has conducted, the Commission has recommended that organizations immediately establish a process for independent validation and verification and that executives explicitly consider IV&V recommendations when making decisions. One Commission-reviewed project found a significant shortage of staff on the agency management team. The Commission recommended that the management team take all possible actions to expand its staff, concentrating on the addition of technical expertise in computer software and systems. The Commission also recommended that contract personnel be more effectively used to provide project management support
One Commission-reviewed project revealed a clear need to integrate IT planning across various organizational units involved in the project. A new business concept of operations required that IT processes be realigned to meet evolving demands. The Commission recommended that the organization use experts in BPR and information modeling to facilitate the necessary process analysis and redesign
One agency requested the Commission review its enterprise-wide architecture. The agency appeared to lack a structured process for testing products within the architecture before placing them into use. The Commission recommended a centralized test bed which would enable the agency to simulate new functionalities and assess them before placing them into service. One Commission-reviewed project faced serious risk of failure due to recent major shifts in the agencys mission. If carried out according to the original plan, the project would simply have automated certain processes which no longer made sense in the new environment. The Commission recommended that the organization cease development of certain sub-systems, and retain consultants to facilitate high-level process redesign. The Commission reviewed one project which had recently negotiated movement from a cost reimbursement contract to a fixed price contract. While the Commission concluded that this was an appropriate step, it noted that the agency would need to consider more thoroughly the different risks entailed by the new contract incentives, and that it would need to balance the risk between the agency and the contractor. For example, the Commission recommended that the agency tie progress payments to accomplishment of specific milestones.
One recently redesigned project lacked test and acceptance procedures for a large set of new technical requirements. The Commission recommended that the agency establish test and acceptance procedures at frequent milestones consistent with the projects work breakdown structure. It further recommended that the requirements be re-baselined, and frozen, in order to ensure an acceptable level of functionality.
The Commission reviewed a project whose software development process was in a perpetual state of change. The Commission recommended the establishment of configuration management baselines as well as cost and schedule baselines.
Processes Making it happen

Planning Define Success Up Front Define project success in terms of specific business objectives. From the customers point of view, how should different business objectives be prioritized? Use Metrics to Focus On Outcomes Focus on outcomes rather than outputs. Prioritize the metrics for which project participants will be held responsible. Gain agreement on critical metrics and use them to drive planning and delivery. Integrate Planning Activities Across the Project Formalize planning processes. Assign roles and responsibilities specifically for planning-related activities. The CIO can help anchor project plans in the organizations business and IT plans. Realign Plans Over Time How will plans need to be modified along the way? Make sure project plans continue to support intended business priorities. If the project encounters significant changes, then the original plans will have to be realigned to ensure desired results. Managing Technology Choose an Appropriate Development Model Base selection of a development model on careful consideration of four factors: Costs. Consider various development alternatives and estimate how they might contribute to project costs.
Project Management Risks. Consider how much risk the project faces due to:
High visibility due to public or political attention or requirements Highly compressed development time High uncertainty associated with the systems requirements, the technology that the system will employ, or the way that the system will affect business processes
Complexity. Consider the project to be complex if it:
Affects many organizations or functional areas. Results from business process reengineering, dramatically altering the use of information technology. Requires new or rapidly advancing technology. Requires a long time for development.
Type. Consider the general type of the project:
A new development A modification of an existing system A system integration
Select an Appropriate Life Cycle The life cycle provides an organizing structure with which to align project objectives with appropriate technologies and resources. Different projects require different degrees of rigidity in the sequencing of their phases. Long, complex projects intended to modify familiar systems typically yield to more rigid sequencing. On the other hand, less rigid sequencing may be required to achieve a series of innovations under conditions of high uncertainty. Deal with Shifting Priorities Business needs may change. All requirements must be formally managed. Address downstream changes in the life cycle through systematic risk assessment. Make Progress Visible to All Project participants need a clear idea of how well the project plan is working. Establish a set of key progress indicators and make them visible to all project participants. Know The Limits of Automation Dont simply automate existing processes. Rethink existing processes instead of simply "paving the cowpaths." If your agency lacks the skills, use consultants to facilitate business process reengineering (BPR) and information modeling prior to defining requirements. Leverage Expertise in Established Management Areas Managing Inputs. Encourage project participants to address evolving technical priorities with appropriate resources. For example, employ contract incentives to deliver the desired results in accordance with the projected cost and schedule. Offer high incentives (18 - 20%) to in-house staff. Managing Activities. Use scope management techniques such as a Work Breakdown Structure (WBS) to organize project activities and tasks. Graphically display the work to be accomplished. Update the display periodically to reflect reality. Managing Outcomes. Encourage all staff to identify potentially problematic outcomes. Use formal risk management techniques to anticipate and mitigate project risks. Controlling Tasks Put Meaning in the Metrics Define requirements so that they may be thoroughly tested and validated at the unit and systems level of granularity. Identify frequent milestones with a defined set of measurable pass/fail performance criteria. Structure related contracts so that they reflect the same units, granularity, and milestones. This enables you to measure earned value throughout the contract life. These criteria should comply with a pre-established test plan. Leverage Expertise in Control Areas Controlling Inputs. Conduct life-cycle cost analysis to evaluate the impact of design implementation alternatives throughout the project. Use agreed upon plans to control the resources applied to the project. For example, periodically review actual project expenditures and compare them to the projected budget. Controlling Activities. Standardize processes which deal with the most routine activities. For example, routine progress reports can be structured to capture and highlight exceptions from anticipated progress. Controlling Outcomes. Use configuration management processes to ensure the project is building what the customer wants. The implications of changes along the way can be understood and incorporated while driving toward the desired result.
MPM MASTER PROJECT MANAGER CORE REQUIREMENTS

Module One: Project Initiation
Definition of IT Project Management Federal Statutes & Guidance Project Management Framework Mission Needs Project Charter Project Requirements Management Acquisition Management Project Kick-off
Module Two: Project Planning and Control -Part A
Project Management Scope Management Schedule Development Work Breakdown Structure Cost Plan - Estimating Performance Measurement Earned Value
Module Three: Project Planning and Control -Part B

Risk Management Quality Management Communication Management Human Resources Management Procurement Management Module Four: Capital Planning and Investment Control Capital Planning and Investment Control Process Overview Pre-Select Phase Project Sponsor Mission Analysis Preliminary Business Case Investment Review Package Select Phase Functional Requirements Feasibility Study Risk Profile Financial Profile Technological Profile Security, EA, and eGov Plans Project Plan Acquisition Plan and Strategy
Control Phase Project Planning, Cost, Schedule & Performance Scope Management Work Breakdown Structure (WBS) Earned Value Management (EVM) Communication Planning Risk Management Enterprise Architecture/ Section 508 Control Review Process Evaluate Phase Post Implementation Review Validate/update CBA System Performance Steady State User/Customer Assessment Operation and Maintenance Review Records Management
Module Five: Master Project Manager and Certified International Project Manager Certification Exam Preparation
What is Master Project Manager (MPM) and (CIPM) Certification: MPM Certification is a globally recognized and respected credential, and therefore requires a valid level of understanding and professional knowledge of Project Management. Following is an overview of the MPM Certification requirements: Experience (consecutive months): With Masters: 12 Months; With Bachelors Degree: 36 (within prior 6 years) Without Degree: 60 (within prior 8 years) Contact Hours: Contact Hours of PM education: 35 Maintain Professional Development: Professional Development Units (PDE): 60+ (within a 3 year period) Please see www.certifiedprojectmanager.org for a more detailed list of MPM Certification Requirements.
MPM MASTER PROJECT MANAGER- SAMPLE CERTIFICATION TEST SAMPLE MULTIPLE CHOICE QUIZ
Part 1 +RECORD ARRAY +RECORD +ATTRS: RECORD ARRAY +RECORD +NAME: 'ACTION' +VALUE: '' +RECORD +NAME: 'ENCODING' +VALUE: 'application/x-www-form-urlencoded' +RECORD +NAME: 'METHOD' +VALUE: 'GET' +TAG: 'FORM'
+RECORD ARRAY +RECORD +ATTRS: RECORD ARRAY +RECORD +NAME: 'NAME' +VALUE: 'QuizName' +RECORD +NAME: 'TYPE' +VALUE: 'hidden' +RECORD +NAME: 'VALUE' +VALUE: 'Multiple Choice Quiz' +TAG: 'INPUT'
+RECORD ARRAY +RECORD +ATTRS: RECORD ARRAY +RECORD +NAME: 'NAME' +VALUE: 'UpdateableLink' +RECORD +NAME: 'TYPE' +VALUE: 'hidden' +RECORD +NAME: 'VALUE' +VALUE: 'no' +TAG: 'INPUT' +RECORD ARRAY +RECORD +ATTRS: RECORD ARRAY +RECORD +NAME: 'NAME' +VALUE: 'ChapterName' +RECORD +NAME: 'TYPE' +VALUE: 'hidden' +RECORD +NAME: 'VALUE' +VALUE: 'Modern Project Management +TAG: 'INPUT' +RECORD ARRAY +RECORD +ATTRS: RECORD ARRAY +RECORD +NAME: 'NAME' +VALUE: 'ChapterNumber' +RECORD +NAME: 'TYPE' +VALUE: 'hidden' +RECORD +NAME: 'VALUE' +VALUE: '1' +TAG: 'INPUT' +RECORD ARRAY +RECORD +ATTRS: RECORD ARRAY +RECORD +NAME: 'NAME' +VALUE: 'contentid' +RECORD +NAME: 'TYPE' +VALUE: 'hidden' +RECORD +NAME: 'VALUE' +VALUE: '358857' +TAG: 'INPUT' +RECORD ARRAY +RECORD +ATTRS: RECORD ARRAY +RECORD +NAME: 'NAME' +VALUE: 'TypeOfQuiz' +RECORD +NAME: 'TYPE' +VALUE: 'hidden' +RECORD +NAME: 'VALUE' +VALUE: '1' +TAG: 'INPUT'
'
1 Project managers are unique because they manage temporary activities. A)True. B)False. 2 Leading an expedition to the moon is not an example of a project. A)True. B)False. 3 The AAPM is a professional organization for project managers. A)True. B)False. 4 Changing the oil of a car is an example of a project. A)True. B)False. 5 PMBOK is a mandatory standard for the Project Managers A)True. B)False. 6 PMBOK consists of how many basic knowledge areas A) 22. B) 9. C) 12. D) None from above is true. 7 Projects are A) unique, one time events. B)have a clear definable end. C)project specifications are loose. D)repetitive activity. E)None from above. 8 Which of the following forces is not contributing to the importance of project management? A)corporate downsizing B)increased customer focus
C)rapid development of third world economies D)global competition E)extension of product life cycle 9 Project development is not affected by Stakeholders A)True. B)False. 10 A standard is a document approved by a recognized body, with which compliance is not mandatory A)True. B)False

Project Management

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Project Management

Uploaded by

Copyright:

Available Formats

Project Management -

INTERNATIONAL PROJECT MANAGEMENT COMMISSION __________________________________________ Office of PM Knowledge Management

November 18, 2005 TABLE OF CONTENTS

http://www.projectmanagementcertification.org/managernotes/_printable.html[10/19/2011 8:34:12 PM]

ROLES AND RESPONSIBILITIES 42 T HE P ROJECT T EAM AND S TAKEHOLDERS 42 ORGANIZATIONAL M ANAGEMENT 43

P ROJECT S PONSOR / B USINESS S PONSOR 44

MAKING PROJECTS WORK 51

WHAT IS A PROJECT FOR?

Product Product Product Product

Features Quality Attractiveness Price

Guaranteed by a PROJECT MANAGEMENT

WHAT IS PROJECT MANAGEMENT?

o The Project Management Knowledge Areas

Scope verification Scope change control

Adaptive Development (AD) Speculate-Collaborate-Learn

WHAT IS PRINCE 2 PRINCE 2

What is ISO 9000?

How to develop a quality management system (QMS) ?

Authority and Accountability

OVERVIEW OF PRODUCT DEVELOPMENT STRATEGY AND METHODOLOGY

http://www.projectmanagementcertification.org/managernotes/_printable.html[10/19/2011 8:34:12 PM]

For R&D departments

v Major Documents list:

v Common Project Development Cycle

PROJECT PHASES AND THE PROJECT LIFE CYCLE STAKEHOLDERS

http://www.projectmanagementcertification.org/managernotes/_printable.html[10/19/2011 8:34:12 PM]

o Standards and Regulations