Home >
Main Sections 
Home
Project Management 

International Project Management Commission
 
Printable version AAPM Project Management ™ Common Law Copyrights Designations and Marks

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 project’s reason for being and ensures the project is consistent with the organizational business plan. It defines a high-level approach and other top-level 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 project’s 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 project’s business case and prepare for the project’s 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 Manager’s understanding of the project’s 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 project’s 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

Task

Responsible

D = Develop or Designate, S = Support,

C = Concur, A = Approve

Business Sponsor

Program Manager

Project Manager

Project Team

Stakeholders / OI&T

EIB / SMC

Concept Paper

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

           

Milestone 0 Briefing

Create briefing slides

           

Seek Administration approval

           

Schedule Committee briefing

           

Present briefing to Committee

           

Milestone 0 Decision Memo

Draft Decision Memo

           

Sign Decision Memo

           

Accomplish Decision Memo tasks

           
Pages 
PROJECT MANAGEMENT
INTRODUCTION TO PM
WHAT IS A PROJECT?
WHAT IS A PROJECT FOR?
WHAT IS PROJECT MANAGEMENT?
WHAT IS PMTOP
WHAT IS PRINCE 2
PRINCE 2
ISO 9000:2000
OVERVIEW OF PRODUCT DEVELOPMENT STRATEGY AND METHODOLOGY
USE IT AS THE PROVEN, LOW-COST BASIS FOR YOUR COMPANY’S METHODOLOGY
PROJECT PHASES AND THE PROJECT LIFE CYCLE

PROJECT PHASES AND THE PROJECT LIFE CYCLE

STAKEHOLDERS
ORGANIZATIONAL STRUCTURE
SOCIAL-ECONOMIC-ENVIRONMENTAL INFLUENCES

PROJECT MANAGEMENT PROCESSES
ROLES AND RESPONSIBILITIES
MAKING PROJECTS WORK
CONCEPT DEFINITION
CONCEPT DEVELOPMENT
SYSTEM DESIGN AND PROTOTYPE
SYSTEM DEVELOPMENT AND TESTING
SYSTEM DEPLOYMENT
SYSTEM OPERATION
ABOUT THIS IPMC EXECUTIVE SUMMARY
SUMMARY OF PMMeeting The Mission
It’s why you’re here

Align the Project Mission with the Agency’s Mission What is your agency’s mission? What is the relatKnow 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 aAmplify 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 welMaintain 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 agency’s 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 project’s 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 organization’s 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 participantsOrganizational 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 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 organization’s 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 What’s Needed to Succeed What are the competencies of the team? How does the staffing plan distribute these competencies against project tasks? Assess the team’s 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 team’s 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. Processes Making it happen Planning Define Success Up Front Define project success in terms of specific business objectives. From the customer’s 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 organization’s 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.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 system’s 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 Don’t 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.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. 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 organization’s 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 CIO’s: 1. Federal Information Resources Management · Policy and Organizational Knowledge· Information Resources Strategy and Planning· IT Acquisition2. Capital Planning· IT Performance Assessment· Capital Planning and Investment Assessment3. Change Management4. Managerial/Technical· Professional Development and Training· IT Topics· IT TrendsProject 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 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 agency’s 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 project’s 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.


MPM MASTER PROJECT MANAGER – CORE REQUIREMENTS
Module One: Project InitiationDefinition of ITFederal Statutes & GuidanceProject Management FrameworkMission NeedsProject CharterProject Requirements ManagementAcquisition ManagementProject Kick-off Module Two: Project Planning and Control -Part AScope Management Schedule Development Work Breakdown Structure Cost Plan - Estimating Performance Measurement Earned Value Module Three: Project Planning and Control -Part B Risk ManagementQuality ManagementCommunication ManagementHuman Resources ManagementProcurement Management Module Four: Capital Planning and Investment ControlCapital Planning and Investment Control Process Overview Pre-Select PhaseProject SponsorMission AnalysisPreliminary Business CaseInvestment Review Package Select PhaseFunctional RequirementsFeasibility StudyRisk ProfileFinancial ProfileTechnological ProfileSecurity, EA, and eGov PlansProject Plan Acquisition Plan and StrategyControl PhaseProject Planning, Cost, Schedule & PerformanceScope ManagementWork Breakdown Structure (WBS)Earned Value Management (EVM)Communication PlanningRisk ManagementEnterprise Architecture/ Section 508Control Review ProcessEvaluate PhasePost ImplementationReview Validate/update CBASystem PerformanceSteady StateUser/Customer AssessmentOperation and Maintenance Review Records ManagementModule Five: Master Project Manager and Certified International Project Manager Certification Exam PreparationWhat 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