PMAP Frequently Asked Questions
Content of PMAP
What is a Project Management Practice?
A Project Management Practice is a collection of techniques, processes, and tools applicable to a specific aspect of managing the work effort, such as schedule or issue management. The Project Management Practices used in this version of PMAP are listed in the PMAP Lifecycle
section of the PMAP Documentation on this website.
Which Project Management Practices are required for each phase?
The Project Management Practices connected with specific phases are laid out in the PMAP Lifecycle Chart
on this website.
What are the PMAP deliverables and templates?
Each PMAP phase includes a number of activities that result in either deliverables or outcomes. Deliverables are tangible work products that are agreed upon as part of the project scope, whereas outcomes are a final product, the end result or consequence of an activity. For deliverables, annotated templates
are provided on this site. Each template feature should be considered for applicability to a given project. Project managers have latitude in the level of formality in which template data is captured.
Can a person serve more than one role in PMAP?
Yes, A single person can certainly occupy more than one role in the PMAP
structure. For example, one person may be both an owner and a sponsor.
Is the "close -out" phase necessary to complete a PMAP project?
Some version of the Close-out phase should be done, even if it is relatively small. Any documents relating to the project should be archived where they can be most useful for future projects; any resources associated with the project should be released; and the budget should be closed out.
Are the Post-Implementation/Lessons Learned documents to be turned into anyone other than the project manager and project owners?
That depends on the project. Check with your project manager or program leader.
My PMAP projects tend to be upgrades of an existing application rather than a major development project. How should the project be structured with regards to iterative execution phases?
PMAP provides the flexibility to accommodate one or multiple execution phases
, and can be used regardless of whether the project is an upgrade or a new project. It is recommended that you iterate the execution phase for each environment scheduled to be upgraded. At the end of each execution phase, there will be a phase gate with the project owners to obtain agreement to move forward with the next upgrade or iteration of the execution phase.
Is there a simplified version of PMAP for smaller projects?
Yes, For smaller projects, certain elements of PMAP are not required.. Minimum requirements are that a document is created that outlines the Project, this could be either a Project Proposal or Document of Understanding, governance and organizational structure is identified – who owns this project, who is manages the project and who is assigned and a schedule is established, that reflect the various phases of PMAP.
Client related quetions
Can PMAP be used for intradepartmental projects?
Yes, in fact it is recommended that PMAP is used in these cases, since it provides structure, governance and operating guidelines to mitigate the risks working across departments, across disciplines and across the University.
Is there documentation available to share with my clients to educate them on the PMAP nomenclature and overall processes associated with the enhanced PMAP?
Information about PMAP can be taken from this website and included in the project kick-off or other communications with the client.
My client wants additional information on the status report; do individuals have the flexibility to alter the template to accommodate the client desire?
You can add an appendix to the status report that includes the additional information your client wants.
Where can I find more information about the various software development life cycles (SDLCs) available or being used at Penn?
There is a page on the ISC Confluence wiki called Software Development Lifecycle. It contains information about three different SDLCs (Waterfall, Iterative and Agile). Login to the Flash Jump Page, then click on Confluence wiki, and then on Software Development Lifecycle.
When should the Office of Audit, Compliance and Privacy (OACP) be involved in a PMAP project?
OACP should become involved if the project deals with financial, regulatory or process issues, or when requested by upper management.
Can PMAP be integrated with other methodologies?
PMAP is generic and may be integrated with almost any type of project development methodology, including:
traditional life cycle methodologies such as Waterfall
- rapid development prototyping processes such as Agile
- engineering, networking, documentation, and user services methodologies
- other methodologies that take the larger business enterprise into account
Am I required to do every step in the PMAP system?
Not every element of the PMAP methodology is required for every project. For example, smaller projects may not require a Work Request or Project Proposal. Project managers should adapt PMAP so it ismost useful to them. However, there are some elements that should be common to all projects, including appropriate communications with stakeholders and monitoring schedule, scope and cost.
Why does PMAP work outside of technology driven projects?
PMAP works for all types of projects because the structure of the methodology is not fundamentally about IT. Dividing a project into phases, obtaining appropriate approvals at the end of each phase, and engaging in activities such as status reporting to monitor adherence to original cost, schedule and scope estimates are all elements of any successful project methodology.
I've been using PMAP since I got to ISC. What's changed in the revised version?
Most key PMAP principles, like staged approval and project ownership, remain the same. Major changes include:
- Reducing the number of identified phases from five to four
- Explicitly acknowledging the possibility for certain phases to iterate (be repeated)
- Identifying project management practices that are common to all projects and articulating the most important ones
- Generalizing the execution phase (formerly design and development) to accommodate different system development lifecycle methodologies more readily
Where has PMAP been used successfully previously?
ISC has used PMAP successfully on many projects, both large and small. The essential elements of the methodology – the 4 phases, approvals at the end of each phase, and the deliverables and activities associated with each phase – can be adapted to many different kinds of projects, whether IT-related or not.
What are the limits to the PMAP system?
PMAP is for use in projects, which are defined as temporary endeavors with a specific outcome. It is probably not useful for ongoing operations, or for management of larger-scale programs and portfolios, since these do not have a specific end-date.
Who can I contact for specific questions about PMAP?