0% found this document useful (0 votes)

86 views40 pages

Sample PMO Process Framework

Breakdown of typical project mgmt process frameworks (waterfall, but could be iterative)

Uploaded by

capnjack69

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as PPT, PDF, TXT or read online on Scribd

0% found this document useful (0 votes)

86 views40 pages

Sample PMO Process Framework

Breakdown of typical project mgmt process frameworks (waterfall, but could be iterative)

Uploaded by

capnjack69

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as PPT, PDF, TXT or read online on Scribd

You are on page 1/ 40

The Project Management Lifecycle is for use with any project.

A project is a set of activities with a start and end date and defined outcomes.

Project Management Lifecycle (PMLC)

Initiate Plan Execute Close
Formally recognizing that a Devising and maintaining a workable scheme to Coordinating, integrating and managing all resources in order Gaining formal acceptance
new project exists or that an accomplish the business need that the project was to achieve the project objectives by carrying out the letter of the project deliverables
existing project should undertaken to address. and intent of the Project Execution Plan while responding to and bringing the project to
continue into its next phase. change and mitigating risks. an orderly end.

• Scope • Schedule • Quality Control • Costs • Resources • Risks

Comparing actual performance with planned performance, analyzing variances, evaluating possible alternatives and taking appropriate corrective action as needed.

Project Management Framework (PMF)

The Systems Development Lifecycle includes the key components of the Project Management Lifecycle and is designed to support technology projects.

Systems Development Lifecycle (SDLC)

Feasibility Planning Design Construction Testing Deployment

Pre-Feasibility Clearly define the scope Devise a total solution to Manufacture all aspects of the solution. Close
(requirements) schedule meet the project Certify each component and ensure that the
(timelines, milestones, project requirements. All aspects of interaction of all of the components (new and
Includes project initiation, plans) and cost (budget, the solution are defined in existing) meets the project’s requirements. Put the solution to work;
formulation and approvals to resources) of the project, given detail, including people, make it a realty. Implement
proceed. Approval is based on the desired quality and acceptable process, technology, the necessary support
strategic fit/alignment and risks. The high level approach to deployment and mechanisms. Assess
meeting requirements is defined. support/maintenance Define Design
prioritization within the larger Iterative project successes/failures
portfolio of projects. aspects. Changes to the and Phased for continuous improvement
requirements are Approach efforts. Bring it to an orderly
aggressively managed. close.
Build

Last Saved: 8/2005 HRB Project Management Framework v2.0.12 Page 1

HRB Project Management Lifecycle (all
projects)
Initiate Plan Execute Close
• Scope • Schedule • Quality Control • Costs • Resources • Risks

• Understand Business Needs • Define Scope • Execute the Plan • Verify and Document
- Review for Strategic Alignment • Develop Schedule - Activity Management Results
• Define Project Objectives - Activities Defined, Sequenced and - Deliverable Management • Administrative Closeout
• Define Project Deliverables Estimated - Communications Management • Transition to Operational
• Identify Assumptions • Plan Resources - Project Team Management State
• Identify Constraints • Estimate Costs and Develop Budget • Execute Change Control • Obtain Formal
- Schedule • Plan for Quality - Scope Change Control Acceptance by the
- Resources/Costs • Plan for Change Control - Schedule Control Sponsor
- Quality • Plan for Communications - Resource/Cost Control
- Risk • Identify, Quantify and Prepare - Risk Response Control
• Identify Key Individuals Responses to Risks - Quality Control
• Document all Findings (Project • Acquire and Organize Project Team • Conduct Performance Reporting
Charter) • Document all Findings (Project
• Obtain Authorization to Proceed Execution Plan)
• Obtain Authorization to Proceed

Last Saved: 8/2005 HRB Project Management Framework v2.0.12 Page 2

Initiate Formally recognizing that a new project exists or that an existing project should continue into its next phase.

L M H Key Tasks Description Job Aids

SDLC Reference:
• The business need should be presented in the form of a business case, but may also
• Service Request
be partially described in a “service request”, a “change request” or a “work order”.
   Understand Business Needs • Retail Tax Service Request
• It is critical to understand the true business need and not just the request for work that
Best Practice Library:
is being made. Business needs may come in the form of a problem or opportunity.
• Sample Business Case

• Identify the "fit" with overall department, business unit and corporate strategies. One Input to:
tool that can be used to determine this ‘fit’ is to perform a SWOT analysis around the • Project Charter
project. Reference:
  Review for Strategic Alignment • Determine if sufficient benefits and commitments exist to proceed with high-level • SWOT Analysis
scoping. SDLC Reference:
• SDLC Reference: The IT Business Analysts should complete a review of the Service • Service Request Analysis Form
Request if there is a technology component in the projected solution. • Project Initiation Report

• Document the overall project objectives.

• While it is not the explicit goal of this task to define high-level project requirements, Input to:
some may be identified at this point and should be captured. • Project Charter
   Define Project Objectives • Changes to the project objectives need to be managed as a part of the Controlling SDLC Reference:
activities through the life of the project. • High Level Project Requirements
• SDLC Reference: The Intersystem Interface Log may be used as a way to clearly • Project Initiation Report
document and communicate the expected interfaces between systems.

• Confirm understanding of the project’s expected outcomes. Input to:

• Consider an interim or phased approach to project outcomes. • Project Charter
   Define Project Deliverables
• Changes to the project’s deliverables need to be managed as a part of the Controlling SDLC Reference:
activities throughout the life of the project. • Project Initiation Report

• Record the assumptions associated with the project. These should be used as a Input to:
management tool and as communication tool. • Project Charter
• Changes to assumptions need to be monitored as part of the Controlling activities Reference:
   Identify Assumptions
through the life of the project. • Risk Management Processes
• Assumptions that prove not to hold true during the life of the project may develop into SDLC Reference:
risks or issues. • Project Initiation Report

• Project constraints are items that can or will limit the project team’s options, such as Input to:
Identify Constraints
necessary delivery dates, predefined budget, contract provisions or resource •Project Charter
• Schedule
availability. Reference:
   • Resources/Costs
• Changes to the constraints need to be monitored as part of the Controlling activities •Risk Management Processes
• Quality
throughout the life of the project. Constraints that change during the life of the project SDLC Reference:
• Risk
may develop into new risks, issues or opportunities. •Project Initiation Report

• This task includes the identification of key stakeholders and project sponsors.
• This task also includes the identification of the project manager(s) who will be
responsible for further scoping, costing, project execution plan development and overall Input to:
  Identify Key Individuals
project management. • Project Charter
• At the same time, critical team members should be identified. Team members may be
considered critical for their functional/business, technical or management expertise.

“SDLC” refers to the Systems Development Lifecycle and is provided as a cross-reference.  indicates that a task is recommended for this type (L/M/H) of project. See Appendix for L/M/H guides.
Last Saved: 8/2005 HRB Project Management Framework v2.0.12 Page 3
Initiate
L M H Key Tasks Description Job Aids
• Project Charter
• The Project Charter is a document endorsed by senior management that provides the
• PMLC Compliance Checklist
project manager with the authority to apply organizational resources to project
SDLC Reference:
Document all Findings (Project activities.
   • Project Initiation Report
Charter) • SDLC Reference: This task aligns to the draft version of the Project Initiation Report at
• Project Initiation Checklist
the end of the Feasibility Phase.
Audit Alert – Documentation of this task could be requested if audited! Best Practice Library:
• Sample Project Charter

• Gather lessons learned throughout the project by all stakeholders starting at kickoff
• Project Lessons Learned
  End of Phase Lessons Learned • Conduct project lessons learned workshops at the end of each life cycle phase, and
• Lessons Learned Agenda
upon project conclusion whether successful or not

• Executive/Project Sponsor approval to continue with project. Includes a review of

information in the Project Charter to determine if planning is warranted or if the project
   Obtain Authorization to Proceed should end at this point.
• This is also a time to collect lessons learned to date.
Audit Alert – Documentation of this task could be requested if audited!

L M H Key Tasks Description Job Aids

• A written scope statement clarifies the information contained in the project charter by
• Scope Statement
restating in more detail the project’s objectives and major deliverables. It drives the
Input to:
requirements for the project.
• Project Execution Plan
• The project’s scope statement puts down on paper what will be done, and equally
Reference:
   Define Scope important, what will not be done.
• Risk Management Processes
• The scope statement should also reflect the project’s critical success factors and how
SDLC Reference:
they will be measured.
• Project Initiation Report
• Note that scope, schedule, budget and quality are interrelated constraints. Changes to
• High Level Project Requirements
one of those factors will most likely have effects on the other three.

• Activity definition is the process of identifying and documenting the specific activities
Input to:
that must be performed in order to produce the deliverables identified.
Develop Schedule • Project Schedule
   • A Work Breakdown Structure (WBS) is one common way to perform this activity. The
• Activities Defined SDLC Reference:
WBS is essentially an outline of the activities and tasks that need to be done to compete
• Project Initiation Report
the deliverables.

• Activity sequencing is the process of identifying and documenting task dependencies.

• Activities have to be sequenced in order to support later development of a realistic and
achievable schedule.
Input to:
• Identifying and accounting for dependencies is critical in this step. Dependencies may
Develop Schedule • Project Schedule
   include things like: other projects or programs, regulatory or legal mandates, corporate
• Activities Sequenced SDLC Reference:
policies, seasonality, lead times for procurement and critical resource availability.
• Project Initiation Report
Dependencies may be internal or external.
• This task is greatly enhanced when performed using a computer application such as MS
Project or Project Workbench because “what if” scenarios are easy to generate.

• This task is completed using top-down and/or bottom-up estimating, along with the
Input to:
expert judgment of those who have done similar activities.
• Project Schedule
• Goals at the end of the estimating process: an updated activity list, estimates
Develop Schedule Reference:
   (durations) for each activity and reasoning behind the estimates.
• Activities Estimated • Risk Management Processes
• The critical path through the project schedule needs to be clearly defined as well.
SDLC Reference:
• Note that scope, schedule, budget and quality are interrelated constraints. Changes to
• Project Initiation Report
one of those factors will most likely have effects on the other three.

Input to:
• Project Execution Plan
• Resource planning and allocation is the process of determining what physical resources • Project Schedule
(people, equipment, materials) and what quantities of each should be used to perform Reference:
project activities. • Risk Management Processes
   Plan Resources • The basic steps to resource planning include identifying resources, determining • Resource Planning Guide (TBD)
availability and estimating costs. • Strategic Sourcing BlockNet page
• It is appropriate during this task to work with Enterprise Sourcing and Settlement • Roles and Accountability Matrix
regarding any third party procurements, including RFI and RFPs. • Project Initiation Report
SDLC Reference:
Roles and Accountability Matrix

• Quality planning is the process of identifying which quality standards are relevant to the
project and determining how to satisfy them.
• The quality management plan should describe how the project team is going to
implement the organization’s quality policy.
• It should be part of the overall project execution plan and address quality control, quality • Quality Control Process (TBD)
assurance and quality improvement for the project. Input to:
   Plan for Quality • Depending on the project scale or size, the quality plan can be anywhere from a formal, • Project Execution Plan
detailed document to a simple outline. SDLC Reference:
• Checklists should be used to verify that quality tasks or activities have been completed. • QA Framework
• Note that scope, schedule, budget and quality are interrelated constraints. Changes to
one of those factors will most likely have effects on the other three.
• SDLC Reference: The quality planning activities are covered under the QA Framework
section of the Systems Development Lifecycle.

• Change is inevitable. It can’t and shouldn’t be avoided but it can and should be
managed.
• A project change control process needs to be in place to deal with changes in scope, • Project Change Control
schedule, resources, costs and quality. • Project Control Logs
   Plan for Change Control
• Any project change control processes need to be aligned with larger program-level Input to:
change control. • Project Execution Plan
• Most importantly, the change control process must be communicated to and agreed
upon with all project stakeholders and project sponsors prior to execution.

• Risk management centers around identifying, quantifying and developing a response to

risks.
• In identifying the project risks, spend time determining which risks are likely to affect the
• Risk Identification List
project and document them.
• Risk Analysis and Management Work
• Risks are quantified by evaluating them and assigning a measure of likelihood and sheet
Identify, Quantify and Prepare magnitude. The process of risk quantification is a conscious effort to focus on those Input to:
 
Responses to Risks risks which warrant a response and to document the potential outcomes if those risks • Project Execution Plan
should actually happen. Reference:
• The outcomes to be considered include schedule delay, cost overruns, team morale, • Risk Management Processes
and lower quality, etc.
• Once risks are identified and quantified, a plan needs to be developed to respond to the
risks if they occur.

• Project Team Organization

Input to:
• Creating a project team includes organizational planning as it relates to the project and
• Project Execution Plan
Acquire and Organize Project the process of getting staff assigned to work on the project
   Reference:
Team • Creating a project team includes identifying all stakeholders (internal and external), all
• Roles and Accountability Matrix
customers (internal and external), project sponsors, review board members, etc.
SDLC Reference:
• Project Initiation Report

• The Project Execution Plan is a document produced by the project manager and
endorsed by senior management that provides guidance and governance during the
• Project Execution Plan
Document all Findings (Project execution of project activities.
   SDLC Reference:
Execution Plan) • SDLC Reference: This task aligns to the final version of the Project Initiation Report at
• Project Initiation Report
the end of the Planning Phase.
Audit Alert – Documentation of this task could be requested if audited!

• Executive/Project Sponsor approval to continue with project. Includes a review of

information in the Project Execution Plan and associated Planning Phase documents to
   Obtain Authorization to Proceed determine if execution is warranted or if the project should end at this point.
• This is also a time to collect lessons learned to date.
Audit Alert – Documentation of this task could be requested if audited!

L M H Key Tasks Description Job Aids

• Executing is managing the activities, deliverables, communications and the project
team.
• Activity management:
• Overseeing and coordinating the actual completion of the project work
• Leading the project team
• Deliverable management:
Execute the Plan • Ensuring the quality of the outputs
• Define • Meeting stakeholder expectations
SDLC Reference:
• Design • Communications management:
   • Design, Construction, Test and
• Build • Reporting progress/status (individual and project)
Deployment phases
• Verify • Conduct meetings (team, steering committee, stakeholders, etc.)
• Implement • Project Team Management:
• Keeping the team staffed with the skills the project needs to complete all its work on
time and within budget plans.
• Getting the maximum productivity out of team members through training, motivating,
coaching, team building, mentoring, and dealing with team conflicts.
• SDLC Note: Executing the Plan corresponds to most of the activities covered in the
Design, Construction, Test phases, as well as parts of Planning and Deployment.

• Change happens. If it isn’t controlled and coordinated, the project will probably fail to
meet initial expectations or fail to materialize all together.
• The project manager is responsible for identifying and managing changes when and as
they occur.
• The Project Charter, Project Execution Plan, Project Schedule and Project Budget
Execute Change Control become critical, baseline documents during the change control process.
• Scope Change Control • The results of change may include: project execution plan updates, scope changes,
• Project Change Control
• Schedule Control schedule changes, budget or forecast changes, etc.
SDLC Reference:
   • Resource/Cost Control • Open and frequent communication to the project team, stakeholders, sponsors and
• Design, Construction, Test and
• Risk Response Control others affected by changes is critical to success.
Deployment phases
• Quality Control • Sources of change may include: project sponsors, stakeholders, regulatory changes,
• Issues Management competitor’s actions, shifting resource/cost constraints, new information
uncovered/revealed as the project progresses, influences of other projects, initiation of
risk mitigation strategies, issues that arise, moving deadlines, etc.
• SDLC Note: Executing Change Control involves many of the activities covered in the
Design, Construction, Test phases, as well as parts of Planning.
Audit Alert – Documentation of this task could be requested if audited!

L M H Key Tasks Description Job Aids

• Also known as “lessons learned”, this activity ensures there is a clear record of what
was accomplished during the project. Reference:
   Verify and Document Results
• It is equally important to focus on how outcomes were accomplished in order to become • Lessons Learned
more efficient and avoid repeating the same mistakes the next time.

• The final set of communications to let all stakeholders/team members know that the • Project Wrap Up Worksheet
project has officially ended. This may include activities such as closing down financial Reference:
and time tracking applications (PeopleSoft or Planview). • Project Closeout
   Administrative Closeout
• Prepare a Project Wrap Up Report to officially close the project and capture its status. • Project Wrap Up Report Guide
This report can provide valuable feedback into future project budgeting, the project Example:
cost estimation tools, as well as to the project manager. • Project wrap Up Example

• Any outcomes/deliverables that are expected to continue beyond the life of the project
must have a formal transition to some operational state.
• In the case of processes, tools or software that have been created, a new owner needs Reference:
   Transition to Operational State
to be identified that will ensure proper maintenance and upkeep of the deliverable. • Project Closeout
• Any long-term project benefits tracking (ROI) defined in the Business Case and/or
Project Charter needs to be transitioned as well.

• Gather lessons learned throughout the project by all stakeholders starting at kickoff • Project Lessons Learned
  End of Phase Lessons Learned • Conduct project lessons learned workshops at the end of each life cycle phase, and • Lessons Learned Agenda
upon project conclusion whether successful or not • Project Surveying

• Executive/Project Sponsor agreement that all project objectives have been met.
• Any outstanding items need to be documented and a mutually agreeable resolution
Obtain Formal Acceptance by
   needs to be reached, which may include additional phases or new projects to address.
the Sponsor
• This is also a time to collect final lessons learned.
Audit Alert – Documentation of this task could be requested if audited!

L M H Key Tasks Description Job Aids

• A subset of project management that includes the processes required to ensure that the
project includes all of the work required, and only the work required, to complete the
project successfully. It consists of:
• Initiation – authorizing the project or phase.
• Scope planning – developing a written scope statement as the basis for future
   Control Scope project decisions.
• Scope definition - subdividing the major project deliverables into smaller, more
manageable components.
• Scope verification – formalizing acceptance of the project scope.
• Scope change control – controlling changes to project scope.
Audit Alert – Documentation of this task could be requested if audited!

• A subset of project management that includes the processes required to ensure timely
completion of the project. It consists of:
• Activity definition – identifying the specific activities that must be performed to
produce the various project deliverables. May be accomplished in a WBS.
• Activity sequencing – identifying and documenting interactivity dependencies.
   Control Schedule • Activity duration estimation – estimating the number of work periods that will be
needed to complete individual activities.
• Schedule development – analyzing activity sequences, activity durations, and
resource requirements to create the project schedule.
• Schedule control – controlling changes to the project schedule.
Audit Alert – Documentation of this task could be requested if audited!

• A subset of project management that includes the processes required to ensure that the
project will satisfy the needs for which it was undertaken. It consists of:
• Quality planning – identifying which quality standards are relevant to the project and
determining how to satisfy them.
• Quality assurance – evaluating overall project performance on a regular basis to
provide confidence that the project will satisfy the relevant quality standards.
SDLC Reference:
   Control Quality • Quality control – monitoring specific project results to determine if they comply with
• QA Framework
relevant quality standards and identifying ways to eliminate causes of unsatisfactory
performance.
• Continuous Improvement/Lessons Learned
• Part of controlling quality involves conducting “lessons learned” sessions throughout
the project, not just at project close.
Audit Alert – Documentation of this task could be requested if audited!

• A subset of project management that includes the processes required to make the most
effective use of the people involved with the project. It consists of:
• Organizational planning – identifying, documenting, and assigning project roles,
responsibilities, and reporting relationships.
   Control Resources • Staff acquisition – getting the needed human resources assigned to and working on
the project.
• Team development – developing individual and group skills to enhance project
performance.
Audit Alert – Documentation of this task could be requested if audited!

• Risk management is the systematic process of identifying, analyzing, and responding to

project risk. It includes maximizing the probability and consequences of positive events
and minimizing the probability and consequences of adverse events to project
objectives. It includes:
• Risk management planning – deciding how to approach and plan the risk
management activities for a project.
• Risk identification – determining which risks might affect the project and • Project Control Logs
documenting their characteristics. • Risk Identification List
• Qualitative risk analysis – performing a qualitative analysis of risks and conditions to • Risk Analysis and Management Work
   Control Risks sheet
prioritize their effects on project objectives.
• Quantitative risk analysis – measuring the probability and consequences of risks and Reference:
estimating their implications for project objectives. • Risk Management Processes
• Risk response planning – developing procedures and techniques to enhance
opportunities and reduce threats from risk to the project’s objectives.
• Risk monitoring and control – monitoring residual risks, identifying new risks,
executing risk reduction plans, and evaluating their effectiveness throughout the
project life cycle.
Audit Alert – Documentation of this task could be requested if audited!

“SDLC” refers to the Systems Development Lifecycle and is provided as a cross-reference.  indicates that a task is recommended for this type (L/M/H) of project. See Appendix for L/M/H guides.
Last Saved: 8/2005 HRB Project Management Framework v2.0.12 Page 12
HRB Systems Development
Lifecycle
Feasibility Planning Design Construction Testing Deployment
•Project Management Setup for •Project Management Setup •Project • Pilot •Project Management
Pre-Feasibility Phase (See Below) for Phase (See Below) Management Setup •Test Execution Setup for Phase (See
• Assign Team, Roles and • Perform Vendor Selection (if for Phase (See - Analyze/Review Below)
•Create Service Request
Responsibilities Applicable) RFP & RFP Below) Results • Assess Business
•Identify Sponsor and
•Define Communications Plan Response Evaluation •Construct / Build •User Acceptance Readiness
Constituents • Define Project Success • Define Detailed Process Flows • Conduct Training
- Technology Testing
•Identify Project Benefits
• Define Current and Future Functional •Develop Detailed Design - Process, Policies, - User Signoff •Project Board Review
•Determine High-Level Effort
Process Flows • Develop Capacity Plan Procedures - QA / Testing Group • Implement Business
•Strategic Alignment Review
• Refine (High Level) Business • Develop Training Plan - Training/People Signoff Changes
•Executive Review
Requirements • Develop Design Phase Change •Deployment & - Processes/Procedures
- Decision to Proceed • Gather Functional Requirements Architecture Blueprint Operational - Training
•Business and Functional •Develop Test Designs Readiness Review • Production Dry Run Test
Project Initiation/Feasibility •Test Plan / Design Review •Execute ‘Go Live’
Requirements Business Review and FLS Certification
• Assign PM(s)
- Establish Change Management •Technology Design Review •Regulatory - Implement Deployment &
•Define Scope and
Process •Design Approach and Test Compliance Review Operational Readiness
Objectives • Develop Planning Phase Architecture Design Stakeholder Review •Project Board Review Planning Agreement
- Gather (High Level) Business •Deployment and • Transition to Operations
Blueprint - Decision to Proceed
Requirements •Regulatory Compliance Review Operational Readiness • End of Phase QA/
• Create Conceptual Solution(s)
• Identify Development and Review Lessons Learned
- People • Develop Approach for
Implementation Approach (Build vs.
- Process
Buy, Iterative, Waterfall, Pilot, Measuring Project Benefits
- Feasibility Phase Architecture
Blueprint
Prototype) • Revise Project Schedule Close
•Architecture Review • Revise Project Budget
- User Experience Evaluation • Define Product Requirements •Project Board Review • Measure Project Success
• Develop Initial Project Budget
• RFI (if Applicable) - Decision to Proceed - Conduct User Experience
• Develop Initial Project Schedule
•Develop Test Plans - Funding Adjustments Approval Define Design Research
• Identify Risks Iterative and
•Business, Functional and Product - Schedule Adjustments • Conduct Lessons Learned
• Document Assumptions Phased
Requirements Baselined Approval Approach • Complete Project Closeout
• Initiate QA Process / Gather
- Gain Business Signoff • End of Phase QA/ Lessons • End of Phase QA/ Lessons
LOEs •Deployment & Operational Learned Learned
• Initiate Project Status Reporting
Readiness Review Build
•Draft Project Initiation
•Update Project Schedule
Report •Update Project Budget
•Executive Review
• Finalize Project Initiation Report
- Decision to Proceed •Project Board Review Project Management Setup
- Initial Funding Approval  Identify and regularly update key stakeholders, project sponsors and
- Decision to Proceed project board
- Initial Schedule Approval
- Funding Approved and Baselined  Establish and maintain project team organization through defined roles
• End of Phase QA/ Lessons
- Schedule Approved and and responsibilities
Learned  Manage team’s productivity and provide appropriate status
Baselined
• End of Phase QA/ Lessons Learned  Develop and enforce scope change control process
 Update project schedule (milestones)
 Establish and conduct tracking of financial actuals to budget
 Document and manage project issues and risks
Legend
 Identify and conduct project quality reviews and checkpoints
Red - Reviews
Bold - Minimum Required Tasks Contingency  Establish and report weekly status
to be Lifecycle Compliant
Green- PM Controlling Processes Confidence Level in Estimates The Project Management Setup activities map closely to the
Controlling Processes identified in the Project Management Lifecycle.
Last Saved: 8/2005 HRB Project Management Framework v2.0.12 Page 13
Feasibility Includes project initiation, formulation and approvals to proceed. Approval is based on strategic fit/alignment and prioritization
within the larger portfolio of projects.

L M H Key Tasks Description Job Aids

• Service Request
Requestor generates an idea, documents benefits, gains approval and submits service
   Document Service Request Reference:
request. The source for project funding is identified in the service request.
• Retail Tax Service Request

Identify Sponsor and Input to:

   Determine Project Sponsor and key stakeholders.
Constituents • Service Request

• Confirm understanding of project being requested.

• Ensure the requestor has identified quantitative and qualitative benefits and are willing
Input to:
   Identify Project Benefits to "sign up" for them.
• Service Request
• Confirm requestor has evaluated process changes prior to requesting a technology
solution.

• An assessment needs to be made regarding the amount of effort required o complete

the project. The Rough Order of Magnitude tool has been developed to aid in that
determination. The tool provides:
• a uniform method of calculation at a high level and early stage of the project
• consistency of estimation approach across all projects
• an overview of the estimate based on certain key factors
• a benchmark and foundation to move forward with detail level estimation using Reference:
Components/Tasks • Rough Order of Magnitude Tool
  Determine High-Level Effort
• The tool assumes certain pre-requisites and there is a risk that it may show incorrect • Technical Service Request Process
calculations, if the parameters are not specified correctly. The tool is applicable to • Customer Engagement Assignments
projects which require a fair degree of software development.
• Note: If a representative from Enterprise Technology has not been assigned to the
project, a request can be submitted via the Technical Service Request process for any
ET estimates. Alternatively, the Engagement Manager for your group may be
contacted to engage Enterprise Technology. Please see the ET Customer
Engagement assignments if you are not sure who to contact.

• Identify "fit" with overall Business and IT strategy. One tool that can be used to
• Service Request Analysis Form
determine this ‘fit’ is to perform a SWOT analysis around the project.
Input to:
• Determine if sufficient benefits and commitments exist to proceed with high-level
   Strategic Alignment Review • Service Request
scoping.
Reference:
• As a part of this task, IT Business Analysts should complete a review of the Service
• SWOT Analysis
Request if there is a technology component.

Executive Review • Executive approval to continue with feasibility assessment.

  Audit Alert – Documentation of this task could be requested if audited!
• Decision to Proceed

• Identification of project managers, from the Business and IT (as appropriate) who will
be responsible for further scoping, costing, project plan development, and overall
Reference:
project management.
  Assign Project Manager(s) • Project Startup Checklist
• The assigned PM will have several tasks to complete to get the project started and
• SDLC Compliance Checklist
visible to outside groups. These tasks are documented in the Project Initiation
Checklist.

Bolded tasks indicate required steps to “Follow the Framework”.  indicates that a task is recommended for this type (L/M/H) of project. See Appendix for L/M/H guides.
Last Saved: 8/2005 HRB Project Management Framework v2.0.12 Page 14
Feasibility
L M H Key Tasks Description Job Aids

• High Level Project Requirements

• Project Requirements Log
• Document the project description, approach, inclusions, exclusions, and business
Input to:
objectives.
• Project Initiation Report
Define Scope and Objectives • High-level Project Requirements defined at this point.
• Conceptual Solution
   - Gather (High Level) • The Intersystem Interface Log may be used as a way to clearly document and
Business Requirements • Feasibility Phase Architecture Bluepri
communicated the expected interfaces between systems. nt
• Note: If a project architect has not been assigned to the project, a request can be Reference:
submitted via the Technical Service Request process for any architecture reviews. • Intersystem Interface Log
• IMS Data Architecture Web Site
• Technical Service Request Process
The Conceptual Solution should be documented by addressing the people, process and
technology components involved with the solution. Keep in mind that there may be
more than one Conceptual Solution – that is perfectly acceptable (and actually
preferred). Each will have its own risks/benefits/costs, and all of them need to be
documented. The PIR should contain the best or most likely solution, but should clearly
mention and summarize all of the solutions considered. Below are some questions that
may be useful to consider when thinking about the Conceptual Solution:

People - describe at a high level how people will be impacted by this project. Which • Feasibility Phase Architecture Bluepri
departments will be impacted? How many will be impacted? Will our customers be nt
Create Conceptual Solution(s) impacted? Should internal audit or legal be consulted regarding the project deliverables • Usability Impact Analysis
• People of this project? Will training be required? Who will need to be trained? Input to:
• Process • Project Initiation Report
  • Capacity Plan
• Feasibility Phase Process - identify all existing processes that will be impacted by this project. To identify
Architecture Blueprint and processes, first think through each area to be impacted by the project, then identify all Reference:
Solution Approaches processes that will be involved. Consider all areas of H&R Block, not just our tax • Architecture Impact Analysis
business. Consider both internal and external areas. Consider customer impact. • Architecture Framework
Usability analysis is one method of reviewing the impact of process changes. • IMS Data Architecture Web Site
• Technical Service Request Process
Technology – Develop conceptual solution alternatives, in alignment with the HRB Target
State Architecture, to address high-level Business Requirements and gaps in technical
capabilities. Solutions should include technology impacts to cost, risk and scope of the
project and capture architecturally significant requirements associated with the project.

• Note: If a project architect has not been assigned to the project, a request can be
submitted via the Technical Service Request process for any architecture reviews.

 indicates that a task is recommended for this type (L/M/H) of project.

Bolded tasks indicate required steps to “Follow the Framework”. See Appendix for L/M/H guides.
Last Saved: 8/2005 HRB Project Management Framework v2.0.12 Page 15
Feasibility
L M H Key Tasks Description Job Aids
• Cost Template
Develop initial cost estimates for the project based on the defined requirements and Input to:
conceptual solutions. Prepare a high level analysis that begins to compare the costs to • Project Initiation Report
   Develop Initial Project Budget
the benefits. For assistance in completing the costing template contact your Senior • Planning Phase Architecture Blueprint
Financial Analyst.
Reference:
• IMS Data Architecture Web Site
Input to:
   Develop Initial Project Schedule Identify the end date for the project as well as major interim milestones. • Project Initiation Report
• Project Schedule

• Project Control Logs

• Risk Identification List
• Risk Analysis and Management Work
sheet
   Identify Risks Identify potential events or conditions that require mitigation. Input to:
• Project Initiation Report
Reference:
• Risk Management Processes

Record the assumptions upon which the feasibility of the project is based. Should be Input to:
   Document Assumptions
used as a management tool and a communication tool. • Project Initiation Report

Start the QA Process and Activities focused around gathering LOEs and impacted
systems as described in the QA Framework.
Initiate QA Process / Gather • Identify key applications Reference:
  
LOEs • Estimate resource needs and related costs • QA Framework
• Estimate test environment needs & estimate costs
• Estimate tool costs, if applicable

Initiate minimum project status reporting. The frequency, audience, etc. of status
   Initiate Project Status Reporting • Automated Project Status Reporting
reporting will be further defined by communication planning in the Planning phase.

• Includes project scope, conceptual solution, project costs & benefits, project budget &
schedule and risks.
• The PIR will be used as the basis to secure funding and approval to proceed with the
Draft Project Initiation project. Attach initiative worksheet. • Project Initiation Report Draft
 
Report (PIR) • A Project Summary should also be completed by copying and pasting corresponding • Project Summary
sections from the PIR and distributed to ensure the various IT organizations are aware
of the project and its purpose. The Project Summary is a useful tool for communicating
the basics of the project to anyone seeking to become familiar with the project.

 indicates that a task is recommended for this type (L/M/H) of project.

Bolded tasks indicate required steps to “Follow the Framework”. See Appendix for L/M/H guides.
Last Saved: 8/2005 HRB Project Management Framework v2.0.12 Page 16
Feasibility
L M H Key Tasks Description Job Aids
Executive Review Reference:
• Decision to Proceed • Review estimated costs/benefits/scope and risk to determine if planning is warranted. • Baseline and Initiatives Definitions
  Audit Alert – Documentation of this task could be requested if audited!
• Initial Funding Approval
• Initial Schedule Approval

• During the business planning process, project determinations are made with respect to
priority and resource availability.
Prioritize Project In Light Of Reference:
• If a project is identified after the FY business planning process, evaluate it in light of the
  Existing Portfolio and Existing • Baseline and Initiatives Definitions
existing portfolio. If it is deemed a higher priority than an existing project, reprioritize
Resources
portfolio, obtain budget variance approval, or submit to investment fund. If submitting to
the investment fund, complete a Business Case.

• Project Lessons Learned

End of Phase QA / Lessons • Peer review of conformance to PM Framework and best practices. • Lessons Learned Agenda
 
Learned • Initiate QA process following the QA Framework. Reference:
• QA Framework

 indicates that a task is recommended for this type (L/M/H) of project.

Bolded tasks indicate required steps to “Follow the Framework”. See Appendix for L/M/H guides.
Last Saved: 8/2005 HRB Project Management Framework v2.0.12 Page 17
Planning Clearly define the scope (requirements) schedule (timelines, milestones, project plans) and cost (budget, resources) of the
project, given the desired quality and acceptable risks. The high level approach to meeting requirements is defined.

L M H Key Tasks Description Job Aids

Project Management Setup for Develop/update project management framework and phase approach, project work plan, See Project Management Setup (Page
  
Phase issues list, risk document, communication plan, etc. 13)

• Roles and Accountability Matrix (RAM

• Gain agreement on Business and IT roles and responsibilities. )
Assign Team, Roles and • Includes identification of work planning and management responsibilities (Business Input to:
   • Project Initiation Report
Responsibilities and IT), budget ownership, coordination of support teams such as training, Service
Center, Field Technologies, etc. Reference:
• Project Team Organization
• SDLC Swimlanes
• Determine the communication channels for project status. Determine frequency,
content, format and audience for internal and external stakeholders.
• It is important to note that enterprise-wide groups, such as BAs, architecture, data,
• Communication Plan
   Define Communications Plan deployment and operations, QA, etc. will be using the project status report to stay
• Automated Project Status Reporting
abreast of the project’s progress and issues/risks. Consideration should be given to
content of the report so that the appropriate groups can understand the project’s true
status.

Input to:
• Project Initiation Report
  Define Project Success Gain agreement on the critical success factors and how they will be measured. • Planning Phase Architecture Blueprint

Reference:
• IMS Data Architecture Web Site
• Document business, technical, or other system processes – current and future/”to be”
Input to:
states.
• Design Documents
Define Current and Future • Review "to be" business processes, identifying opportunities to streamline business
  • Planning Phase Architecture Blueprint
Functional Process Flows processes before automating.
• Include culture change as part of the future process. Reference:
• IMS Data Architecture Web Site
• Project Requirements
• Project Requirements Log
Input to:
Refine (High Level) Business • Modify high level business requirements in order to set or adjust project scope and • Project Initiation Report
 
Requirements budget. • Planning Phase Architecture Blueprint

Reference:
• Architecture Impact Analysis
• IMS Data Architecture Web Site

 indicates that a task is recommended for this type (L/M/H) of project.

Bolded tasks indicate required steps to “Follow the Framework”. See Appendix for L/M/H guides.
Last Saved: 8/2005 HRB Project Management Framework v2.0.12 Page 18
Planning
L M H Key Tasks Description Job Aids
• Project Requirements
• Define functional requirements and specifications, user characteristics, content • Project Requirements Log
requirements, design requirements, data requirements (conversion, etc.), and • Input to Design Documents
traceability. • Input to
• Consider use of facilitated sessions. Planning Phase Architecture Blueprint
   Gather Functional Requirements • The Intersystem Interface Log may be used as a way to clearly document and
communicated the expected interfaces between systems. Reference:
• Take into account the user experience when gathering and defining the functional • Intersystem Interface Log
requirements. This requires addressing the user interface, but also the entire process • Architecture Impact Analysis
flow for the end-user. • IMS Data Architecture Web Site
Example:
• User Experience Strategy Example
• Business and Functional requirements need to be collected, defined and reviewed –
unofficial signoff by the business.
• The Intersystem Interface Log may be used as a way to clearly document and
communicated the expected interfaces between systems.
• A project change control process needs to be in place to deal with changes in scope,
schedule, resources, costs and quality.
• Project Requirements
Business and Functional • Any project change control processes need to be aligned with larger program-level
• Project Requirements Log
   Requirements Business Review change control.
Reference:
• Most importantly, the change control process must be communicated to and agreed
• Intersystem Interface Log
upon with all project stakeholders and project sponsors prior to execution.
• Requirements change management process is now in effect when changes to the
baseline are required.
• Note that all changes must be coordinated with all other dependent
projects/products to ensure the integrity of the delivery schedule.
Audit Alert – Documentation of this task could be requested if audited!

•A project change control process needs to be in place to deal with changes in scope,
schedule, resources, costs and quality.
•Any project change control processes need to be aligned with larger program-level
change control.
• Project Change Control
Establish Change Management •Most importantly, the change control process must be communicated to and agreed
• Project Control Logs
Process upon with all project stakeholders and project sponsors prior to execution.
•Requirements change management process is now in effect when changes to the
baseline are required.
• Note that all changes must be coordinated with all other dependent projects/products
to ensure the integrity of the delivery schedule.

 indicates that a task is recommended for this type (L/M/H) of project.

Bolded tasks indicate required steps to “Follow the Framework”. See Appendix for L/M/H guides.
Last Saved: 8/2005 HRB Project Management Framework v2.0.12 Page 19
Planning
L M H Key Tasks Description Job Aids
Detailed analysis and logical model for preferred conceptual solution alternative
including:
• Rationale for selection of a particular solution. • Planning Phase Architecture Blueprint
• Domains, applications, processes with interfaces, integration, and touchpoints to • Input to
illustrate architecture after project completion (the “To Be” view). Design Phase Architecture Blueprint
• Adherence to direction of Target State Architecture, or specific justification for • Input to Capacity Plan
Develop Planning Phase variance. Reference:
  
Architecture Blueprint • Further detail and clarification of architecturally significant requirements. • Architecture Framework
• Further analysis of technology gaps and risks, impact to the project (cost, risk, • Data Architecture Governance
scope), and approach to addressing the gap or risk. • IMS Data Architecture Web Site
Completed blueprints should be circulated to all interested parties, including the QA and • Technical Service Request Process
IMS teams.
• Note: If a project architect has not been assigned to the project, a request can be
submitted via the Technical Service Request process for any architecture reviews.

• Meet with compliance teams to ensure requirements are satisfied.

• Consider legal, regulatory and contractual implications of the project.
  Regulatory Compliance Review
• Determine if further checkpoints are required.
Audit Alert – Documentation of this task could be requested if audited!

Determine the best way to deliver the requirements of the project. Consider the
following factors when making the decision:
• Build vs. buy – can this solution be purchased and customized
cheaper/better/faster than a 100% custom solution?
• 3rd party or in-house – can this work be accomplished cheaper/better/faster by Input to:
   Identify Delivery Approach • Project Initiation Report
using contractors or by assigning it to in-house resources. Consider the skill sets
• Project Schedule
required and the resources available.
• Path through the Framework – should the project be delivered in a single “waterfall”
pass through the Framework or should an iterative approach be taken to planning,
design, construction and test resulting in multiple releases?

• Review architecturally significant requirements and logical architecture.

• Should include inputs from Security Review and Development/ Implementation
• Planning Architecture Review Agenda
Approach.
• Primarily serves to communicate architectural approach to Product domains.
Input to:
• Note: If the project will require hardware/infrastructure purchases, it is important to
  Architecture Review • Capacity Plan
order the equipment with sufficient lead time. Please contact the Enterprise
Reference:
Technology team and Enterprise Sourcing and Settlement by the end of Planning to
• Technical Service Request Process
arrange hardware purchases if necessary/appropriate. If a project architect has not
been assigned to the project, a request can be submitted via the Technical Service
Request process for any architecture reviews.

 indicates that a task is recommended for this type (L/M/H) of project.

Bolded tasks indicate required steps to “Follow the Framework”. See Appendix for L/M/H guides.
Last Saved: 8/2005 HRB Project Management Framework v2.0.12 Page 20
Planning
L M H Key Tasks Description Job Aids
• Project Requirements
• Project Requirements Log
Input to:
Document non-functional requirements identified by the business that will impact • Design Architecture Blueprint
   Define Product Requirements
applications/products. • Design Documents
Reference:
• Architecture Impact Analysis
• IMS Data Architecture Web Site

If the selected solution alternative is to "buy," a Request for Information document

should be prepared for delivery to vendors with possible solutions. Should be worked
through Enterprise Sourcing and Settlement . A link to the Enterprise Sourcing and Input to:
Settlement BlockNet page is provided in the Job Aids column. The documents to be • Design Architecture Blueprint
referenced on that site include: Reference:
  RFI (if Applicable)
• Vendor Bid Analysis Procedure • Strategic Sourcing BlockNet page
• Contract Review Procedure • Data Architecture Governance
• RFP Procedure • IMS Data Architecture Web Site
• Standard RFP Template
• Strategic Sourcing Procedures Manual

Begin developing Master Test Plan as defined in the QA Framework.

• Develop the testing strategy for the project, including the scope for the coverage of
testing that will be performed.
• Include LOE, applications, environment requirements, etc. form feasibility activities.
• Identify high level application features. • Master Test Plan
• Complete functional risk analysis and prioritize test requirements. • Usability Test Plan
• Identify test levels needed. • End-to-End Test Plan
   Develop Test Plans • Assign Roles and Responsibilities. • User Acceptance Test Plan
• Set entrance and exit criteria. • Performance Test Plan
• Diagram test environment. Reference:
• Begin developing supporting test plans: • QA Framework
• Usability Test Plan
• E2E Test Plan
• User Acceptance Test (UAT) Plan
• Performance Test Plan

Business, Functional and • All requirements need to be collected, defined, finalized, mutually understood and
Product Requirements agreed upon by the requestor and the solution provider.
  
Baselined • Requirements change management process now in effect when changes to the
– Gain Business Signoff baseline are required.

 indicates that a task is recommended for this type (L/M/H) of project.

Bolded tasks indicate required steps to “Follow the Framework”. See Appendix for L/M/H guides.
Last Saved: 8/2005 HRB Project Management Framework v2.0.12 Page 21
Planning
L M H Key Tasks Description Job Aids
Develop the Software Configuration Management Plan to support the build process
including:
• Plan for build process
• Plan for emergency build process
Software Configuration Template:
   • Plan for defect workflow
Management Plan • SCM Plan template
• Plan for source control library
• Assess check-in/out procedures
• Plan for version control
• Define roles and responsibilities

The purpose of the operational readiness process and tools are to ensure successful
deployment of business solutions through quality checkpoints embedded in the SDLC
framework that enable a smooth transition from development to operations.

Initiate Operational Readiness Planning Process

• Provide Production Operations Committee (POC) with notification of project and
current version of PIR
• Ensure POC has planned for project impact on production
• Ensure POC is prepared for project deployment
• FLS Certification Checklist
• Front Line Services Certification Che
Support Transition Plan cklist
• Identify support ownership • Monitoring Support Checklist
• Identify staffing needs • Implementation Plan
• Deployment Plan
Customer Support • Disaster Recovery Assessment Que
• Define requirements using Customer Support tools stionnaire
Deployment and Operational
   Reference:
Readiness Review
Service Level Management • Operational Readiness Planning Gui
• Define requirements using SLM tools de
• Production Operations Council Chart
System Operations & Monitoring er
• Complete the System Monitoring Support checklist • FLS Operational Readiness Process
• Review the OpenView SLA guidelines on the BlockNet OpenView website Swimlane
• Contact the UNIX or Windows monitoring Teams with any questions • Enterprise Technology Monitoring P
ortal
• Disaster Recovery Methodology
Disaster Recovery Impacts
• Disaster Recovery Design Guideline
• Complete the Disaster Recovery Assessment Questionnaire s
• Review the Disaster Recovery Methodology and HRB Disaster Recovery Design • Validation of
Guidelines Planning Phase Architecture Bluepri
nt
Implementation Planning
• Begin Implementation Planning and potential issue identification

Audit Alert – Documentation of this task could be requested if audited!

 indicates that a task is recommended for this type (L/M/H) of project.

Bolded tasks indicate required steps to “Follow the Framework”. See Appendix for L/M/H guides.
Last Saved: 8/2005 HRB Project Management Framework v2.0.12 Page 22
Planning
L M H Key Tasks Description Job Aids
• Coordinate planning efforts with the Deployment Management team to identify
dependencies which could impact project schedule.
• Project Schedule
• At this point, all dependencies (project or product) should have their delivery schedules
   Update Project Schedule Input to:
completely “in synch”.
• Project Initiation Report
• Ensure all impacted organizations are made aware of schedule updates around their
deliverables.

• Provide updates to the project budget based on increased level of confidence and
project knowledge.
• Updated Cost Template (or other
• Adjust contingency as appropriate.
Project Budget tools)
• Update Project Financial Tracking spreadsheet. Identify any financial issues that need
• Input to:
resolution.
   Update Project Budget • Project Initiation Report
• Ensure all impacted organizations are made aware of budget updates in their areas.
Example:
This includes providing them with an opportunity to adjust LOEs submitted as a part of
• Project Financial Tracking Example
Feasibility. #1
• Note: these are the figures on which the “on-budget” KPI is measured. It should only be • Project Financial Tracking Example
adjusted through the change management process. #2
• Includes project scope, organization, schedule, budget, development approach, high
level conceptual design, and risks.
• This document will be used as the baseline for managing the project and establishing • Project Initiation Report
   Finalize Project Initiation Report
on-time and on-budget metrics. • Project Summary
• Upon completing the updates to the PIR, an updated Project Summary document needs
to be constructed and distributed.

Project Board Review

• Review contents of the Project Initiation Report and make a decision to proceed to the
• Decision to Proceed
next phase, cancel the project, or refine the Project Initiation Report.
• Funding Approved and • Project Board Signoff
  • Upon Project Board Review and approval to proceed, project schedule and funding
Baselined • Updated Project Schedule
needs to be baselined.
• Schedule Approved and Audit Alert – Documentation of this task could be requested if audited!
Baselined

• Project Lessons Learned

• Lessons Learned Agenda
End of Phase QA / Lessons • Peer review of conformance to PM Framework and best practices.
  Reference:
Learned • Includes a review of Operational Readiness using the FLS Certification Checklist.
• QA Framework
• Front Line Services Certification Che
cklist

 indicates that a task is recommended for this type (L/M/H) of project.

Bolded tasks indicate required steps to “Follow the Framework”. See Appendix for L/M/H guides.
Last Saved: 8/2005 HRB Project Management Framework v2.0.12 Page 23
Design Devise a total solution to meet the project requirements. All aspects of the solution are defined in detail, including people,
process, technology, deployment and support/maintenance aspects. Changes to the requirements are aggressively
managed.
L M H Key Tasks Description Job Aids
Project Management Setup Develop/update project management framework and phase approach, project work plan, See Project Management Setup (Page
  
for Phase issues list, risk document, communication plan, etc. 13)

• For packaged systems implementation, develop an RFP based upon the above defined
technical and business requirements.
• Analyze responses and select vendor.
Input to:
• Should be worked through Enterprise Sourcing and Settlement. A link to the Enterprise
• Design Architecture Blueprint
Sourcing and Settlement BlockNet page is provided in the Job Aids column. The
Perform Vendor Selection Reference:
  documents to be referenced on that site include:
(If Applicable) • Strategic Sourcing BlockNet page
• Vendor Bid Analysis Procedure
• Data Architecture Governance
• Contract Review Procedure
• IMS Data Architecture Web Site
• RFP Procedure
• Standard RFP Template
• Strategic Sourcing Procedures Manual

Input to:
• Design Documents
Define Detailed Process
  Document business, technical, or other system processes. • Design Architecture Blueprint
Flows
Reference:
• IMS Data Architecture Web Site

• Develop Technical Architecture and Design Document.

• Design Documents
• Document high-level user scenarios and process flows
Input to:
• Document step/action/results and screen flow for each task within the process flow
• Design Architecture Blueprint
• Create working prototype screens within the program
Reference:
• Evaluate other alternatives and risks.
Develop Detailed Design • Intersystem Interface Log
• Design security, privacy and regulatory compliance components.
• Functional Design • Data Architecture Governance
   • Design integration / touchpoints with other systems and processes, in addition to other
• Technical Design • IMS Data Architecture Web Site
projects.
• Technical Service Request Process
• Note: Upon the completion of Testing, all detailed design documents need to be updated to
Example:
reflect the “as-built” state. This will make maintenance and future enhancements easier to
• Functional Design Prototype Scenari
assess. os (paper-based)
• Note: If a project architect has not been assigned to the project, a request can be submitted • Functional Design Prototype (paper-b
via the Technical Service Request process for any architecture reviews. ased)
• Functional User Interface Design Doc
ument
Build Prototypes as Build prototype (process and/or technology) to demo for business SMEs and to validate
 
Appropriate design.

 indicates that a task is recommended for this type (L/M/H) of project.

Bolded tasks indicate required steps to “Follow the Framework”. See Appendix for L/M/H guides.
Last Saved: 8/2005 HRB Project Management Framework v2.0.12 Page 24
Design
L M H Key Tasks Description Job Aids
• Capacity Plan
Input to:
• Design the solution capacity requirements. • Design Architecture Blueprint
• For IT projects, this includes hardware components. Reference:
  Develop Capacity Plan
• Note: If a project architect has not been assigned to the project, a request can be submitted • Capacity Planning Process Guide
via the Technical Service Request process for any architecture reviews. • Capacity Planning Overview
• IMS Data Architecture Web Site
• Technical Service Request Process

• Define and document training needs.

  Develop Training Plan • Identify trainers and trainees for initial training. • Training Plan
• Identify timing requirements – pre-rollout? One-time? On going?

• Design Phase Architecture Blueprint

• Defines cross-domain technical architecture (the “As Built” view) for the project.
Reference:
• Further analysis and definition of Interface Contracts.
• Architecture Framework
• Supports definition of end-to-end processes such as production support, business activity
• Intersystem Interface Log
Develop Design Phase monitoring, run-time feedback and reaction, etc.
  • IMS Data Architecture Web Site
Architecture Blueprint • Completed blueprints should be circulated to all interested parties, including the QA and
• Technical Service Request Process
IMS teams.
Example:
• Note: If a project architect has not been assigned to the project, a request can be submitted
• Design Phase Architecture Blueprint –
via the Technical Service Request process for any architecture reviews. Example 1
• Design Phase Architecture Blueprint –
Example 2
Begin developing the test designs as described in the QA Framework • Unit Test Workbook
• Develop the testing strategy for the project, including the scope for the coverage of • Performance Test Case Design
testing that will be performed. • Test Design Workbook
   Develop Test Designs • Document coverage, strategy, timeline, and commitments from other groups. • End to End Test Plan
• Create test cases based on design documentation • User Acceptance Test Design
• Construct test data. Reference:
• Conduct peer review of test designs. • QA Framework

Reference:
Test Plan / Design
   Review all test plans and designs with project team as described in the QA Framework. •Test Plan Review Process
Review
•QA Framework

•Usability Test Plan

Review the use cases and/or demo prototype (process and/or technology) based upon the Example:
  Usability Review
user experience strategy for principal stakeholders. •Functional Design Prototype Scenario
s (paper-based)
•Functional Design Prototype (paper-ba
sed)
• Review technical requirements, high level design and architecture.
  Technology Design Review • Technology Design Review Agenda
• Should include inputs from Security Review.

 indicates that a task is recommended for this type (L/M/H) of project.

Bolded tasks indicate required steps to “Follow the Framework”. See Appendix for L/M/H guides.
Last Saved: 8/2005 HRB Project Management Framework v2.0.12 Page 25
Design
L M H Key Tasks Description Job Aids
Design Approach and Test •Review design approach and test designs with the project stakeholders.
  Audit Alert – Documentation of this task could be requested if audited!
Design Stakeholder Review

Implement the Software Configuration Management Plan to support the build process
including:
• Document the build process
Template:
• Document the emergency build process
•SCM Plan Template
Implement Software • Create a defect workflow
•Emergency Build Process Template
   Configuration Management • Create the source control library
Reference:
Plan • Document the check-in/out procedures
•Defect Workflow Process Example
• Implement version control
•Build Process Example
• Build configuration item identification and labeling procedures
• Document migration process
• Define roles and responsibilities

Operational Readiness Planning Process

• Work with Production Operations Committee (POC) to complete Operational Readiness
Planning

Support Transition Updates from Planning

• Define headcount
• Define new customer support procedures
• Define mini-Command Center work plan

Customer Support Updates from Planning

• Front Line Services Certification Chec
• Define customer support model using Customer Support tools
klist
• Define ServiceWare Impacts • Operations Monitoring Requirements
• Define Clarify Impacts • Deployment Plan
• Disaster Recovery Plan
Deployment and Service Level Management (SLM) Updates from Planning Reference:
   Operational Readiness • Define service level model using SLM tools • Operational Readiness Planning Guid
Planning e
System Operations & Monitoring • FLS Operational Readiness Process
• Outline system monitors Swimlane
• Outline system health reports • Production Operations Council Charte
• Outline data center procedures r
• Create staffing plan (headcount, skills, etc) • Enterprise Technology Monitoring Por
tal
Disaster Recovery Impact Updates • Disaster Recovery Methodology
• Design necessary changes to DR plans • Validation of
Design Architecture Blueprint
Information Security Updates from Planning
• Design necessary changes to security environment

Implementation Planning
• Incorporate Implementation Plan Changes from Planning phase

 indicates that a task is recommended for this type (L/M/H) of project.

Bolded tasks indicate required steps to “Follow the Framework”. See Appendix for L/M/H guides.
Last Saved: 8/2005 HRB Project Management Framework v2.0.12 Page 26
Design
L M H Key Tasks Description Job Aids
Establish the measurements that will be used to assess the overall project benefits post-
Develop Approach for
  deployment. These measurement criteria will be reviewed with the Project Owner, Project
Measuring Project Benefits
Sponsor and Project Stakeholders.

  Revise Project Schedule Review and update the project schedule. •Updated Project Schedule

•Revise Cost Template (or other

• Provide updates to the project budget based on increased level of confidence and project Project Budget tools)
  Revise Project Budget knowledge. Example:
• Adjust contingency as appropriate. •Project Financial Tracking Example #1
•Project Financial Tracking Example #2

Project Board Review

• Decision to Proceed • Review design, detailed Level 2 Architecture, capacity plan, budget, revised schedule,
• Funding Adjustments deployment plan, and contingency plan with Project Board.
  •Project Board Signoff
Approval • Make a decision to proceed to the next phase, cancel the project or refine the PIR.
• Schedule Adjustments Audit Alert – Documentation of this task could be requested if audited!
Approval

• Project Lessons Learned

• Lessons Learned Agenda
End of Phase QA / Lessons • Peer review of conformance to PM Framework and best practices.
  Reference:
Learned / FLS Certification • Peer review of Operational Readiness using FLS Certification Checklist.
• QA Framework
• Front Line Services Certification Chec
klist

 indicates that a task is recommended for this type (L/M/H) of project.

Bolded tasks indicate required steps to “Follow the Framework”. See Appendix for L/M/H guides.
Last Saved: 8/2005 HRB Project Management Framework v2.0.12 Page 27
Construction Manufacture all aspects of the solution. Certify each component and that the interaction of all of the
components (new and existing) meets the project’s requirements.

L M H Key Tasks Description Job Aids

See Project Management Setup

• Develop/update project management framework and phase approach, project work
(Page 13)
Project Management Setup for plan, issues list, risk document, communication plan, etc.
   Example:
Phase • Maintain the project budget tracking document, updating the actual spend against the
• Project Financial Tracking Example #
finalized budget. 1
• Project Financial Tracking Example #
2
• Develop solution according to the business, functional, and technical requirements.
• Solution
• Develop / reengineer policies and procedures to ensure consistency with previously
• Updated Job Descriptions
Construct / Build defined processes. Prepare for business changes.
• Updated Training Plan
• Technology • Ensure people understand how to work effectively and efficiently in the new
• Training Documentation (if applicable)
   • Process, Policies, environment. Create documentation containing navigation, data flow for end users, on-
Reference:
Procedures line help, training, and reference materials.
• Policies and Procedures Manual
• Training/People Change • Note: If a project architect has not been assigned to the project, a request can be
• Technical Service Request Process
submitted via the Technical Service Request process for any development environment
requests.

  Peer Review (if Applicable) Peer review of code or process development while in progress.

Iterative process of conducting single, stand alone tests on 100% of solution units,
  Unit Test
documenting / reviewing test results and correcting any defects.

 indicates that a task is recommended for this type (L/M/H) of project.

Bolded tasks indicate required steps to “Follow the Framework”. See Appendix for L/M/H guides.
Last Saved: 8/2005 HRB Project Management Framework v2.0.12 Page 28
Testing Manufacture all aspects of the solution. Certify each component and ensure that the interaction of all
of the components (new and existing) meets the project’s requirements.

L M H Key Tasks Description Job Aids

A limited rollout to the end user to gain “real life” learnings about the suitability of the
  Pilot
solution, reviewing pilot results and correcting any defects.

Complete environment configuration, perform test execution and analyze results as

described in the QA Framework.
 Execute test levels in scope according to the Master Test Plan, including:
 Unit / Integration
 Usability • Test Designs Workbook
 Functional • Test Results Report
 System • QC Metrics Summary
 Performance • Performance Test Results
 E2E • Performance Test Daily Results
 User Acceptance • Performance Test Executive Summar
   Test Execution  Log defects. y
 Track, manage and communicate test coverage, progress, defects and overall • User Acceptance Test Plan
quality metrics. • User Acceptance Test Design
 Analyst coverage, open defects, assess risk and reach production readiness Reference:
decision. • Defect Management Process
 Analyze test results. • QA Framework
 Review results against exit criteria. • Technical Service Request Process
 Communicate final results with release recommendation .
•Note: If a project architect has not been assigned to the project, a request can be
submitted via the Technical Service Request process for any test environment requests.

User Acceptance Testing

•User Signoff
   Testing to ensure the system meets users' needs.
•QA / Testing Group
Signoff

 indicates that a task is recommended for this type (L/M/H) of project.

Bolded tasks indicate required steps to “Follow the Framework”. See Appendix for L/M/H guides.
Last Saved: 8/2005 HRB Project Management Framework v2.0.12 Page 29
Testing
L M H Key Tasks Description Job Aids
Operational Readiness Planning Process
• Work with Production Operations Committee (POC) to finalize Operational
Readiness Planning

Deployment Execution
• 30 days prior to deployment, ERM, FLS and PM meet to define plan

Support Transition Plan

• Meet 45 days prior to deployment
• Hire additional headcount
• Implement mini-Command Center

Customer Support
• Update customer support systems using Customer Support tools
• Front Line Services Certification Chec
Service Level Management (SLM) klist
• Update service level systems using SLM tools • Operations Monitoring Requirements
• Deployment Plan
Deployment and Operational System Operations & Monitoring • Implementation Plan
Readiness Review and FLS • Complete the Operations Monitoring Requirements Document. Contact the UNIX • Disaster Recovery Plan
   Reference:
(Front Line Services) Monitoring Team or Windows Monitoring Team with any questions.
Certification • Update system monitors • HERMIT
• Update system health reports Sample:
• Update data center procedures • Implementation Plan Example
• Hire/train support staff • Customer Support Plan Example
• Validation of
Disaster Recovery Impacts Design Architecture Blueprint
• Create/test necessary changes to DR plans

Security
• Create/test necessary changes to security environment

Implementation Planning
• Submit a Production Change Request with appropriate lead time
• Create plans as outlined during Planning phase

FLS Certification
• Finalize and received sign-off on FLS Certification Checklist

Audit Alert – Documentation of this task could be requested if audited!

 indicates that a task is recommended for this type (L/M/H) of project.

Bolded tasks indicate required steps to “Follow the Framework”. See Appendix for L/M/H guides.
Last Saved: 8/2005 HRB Project Management Framework v2.0.12 Page 30
Testing
L M H Key Tasks Description Job Aids
• Meet with compliance teams to ensure requirements are satisfied.
  Regulatory Compliance Review • Consider legal, regulatory and contractual implications of the project.
Audit Alert – Documentation of this task could be requested if audited!

Project Board Review • Project Board approval to continue with deployment.

  Audit Alert – Documentation of this task could be requested if audited! •Project Board Signoff
• Decision to Proceed

• Project Lessons Learned

• Lessons Learned Agenda
End of Phase QA / Lessons
  • Peer review of conformance to PM Framework and best practices. Reference:
Learned
• QA Framework
• Front Line Services Certification Chec
klist

 indicates that a task is recommended for this type (L/M/H) of project.

Bolded tasks indicate required steps to “Follow the Framework”. See Appendix for L/M/H guides.
Last Saved: 8/2005 HRB Project Management Framework v2.0.12 Page 31
Deployment Put the solution to work; make it a realty. Implement the necessary support mechanisms. Assess project
successes/failures for continuous improvement efforts. Bring it to an orderly close.

L M H Key Tasks Description Job Aids

Project Management Setup for Develop/update project management framework and phase approach, project work plan, See Project Management Setup
  
Phase issues list, risk document, communication plan, etc. (Page 13)

• Conduct a business readiness assessment of the solution to ensure the business is

aware of, ready and prepared for change.
  Assess Business Readiness
• Ensure the users are trained in processes, policies, procedures
• Confirm compliance and benefits monitoring and reporting in place.

Implement the training plan to ensure everyone in the solution supply chain (support
  Conduct Training
staff, users, etc.) are trained in policy, process and systems.

   Project Board Review Go / No Go •Project Board Signoff

Implement Business Changes

  • Processes/Procedures Execute plan for implementing business change.
• Training

Execute Production Dry Run Test as described in the QA Framework:

• Once the production build has been completed and before the environment is
• Smoke Test Design
available to users, QC runs smoke tests in the production environment (without
Reference:
   Production Dry Run Test changing production data) to ensure the build was successful.
• QA Framework
•Note: If a project architect has not been assigned to the project, a request can be
• Technical Service Request Process
submitted via the Technical Service Request process for any production change
requests.

 indicates that a task is recommended for this type (L/M/H) of project.

Bolded tasks indicate required steps to “Follow the Framework”. See Appendix for L/M/H guides.
Last Saved: 8/2005 HRB Project Management Framework v2.0.12 Page 32
Deployment
L M H Key Tasks Description Job Aids
Release solution to production

Deployment Execution
• Monitor and report deployment execution

Support Transition Plan

• Operate the mini-Command Center
• Front Line Services Certification Che
Customer Support cklist
• Start providing support • Operations Monitoring Requirements
• Deployment Plan
Execute ‘Go Live’ Service Level Management (SLM) • Implementation Plan
• Execute Implementation • Manage SLAs Reference:
   • Operational Readiness Planning Guid
Plan and Operational
Readiness System Operations & Monitoring e
• Implement Service Level Requirements • HERMIT
• Implement Operations Monitoring Procedures Sample:
• Transition to production • Implementation Plan Example
• Customer Support Plan Example
Disaster Recovery Impacts • Validation of
• Utilize updated DR plans as needed Design Architecture Blueprint

Security
• Utilize updated security procedures as needed

Production Change Control

Reference:
Complete the transition to Operations as agreed upon in the Deployment and Operational • Operations Monitoring Requirements
  Transition to Operations
Readiness Reviews. • Operational Readiness Planning Guid
e
• Front Line Services Certification Che
cklist
• Record actuals and close project budget.
• Update metrics (Costs, Metrics, ROI). Measure according to established Critical Success Input to:
  Measure Project Success Factors. • Project Closeout
• Assess the success of the project management process.
• Conduct usability research through User Experience Surveys and Field Reviews

 indicates that a task is recommended for this type (L/M/H) of project.

Bolded tasks indicate required steps to “Follow the Framework”. See Appendix for L/M/H guides.
Last Saved: 8/2005 HRB Project Management Framework v2.0.12 Page 33
Deployment
L M H Key Tasks Description Job Aids

Conduct Lessons Learned Provides guidelines on gathering lessons learned throughout the project and conducting a
• Project Lessons Learned
Session project lessons learned session following implementation.

Provides a framework to monitor and record how well a new application meets its success
criteria, record any new/desirable enhancements, and note any start-up issues to be
• Project Wrap Up Worksheet
remedied in the next increment or during a planned maintenance cycle.
Reference:
• Close outstanding project work.
• Project Closeout
  Complete Project Closeout • Cleanup and archive project.
• Project Wrap Up Report Guide
Example:
Prepare a Project Wrap Up Report to officially close the project and capture its status. This
• Project wrap Up Example
report can provide valuable feedback into future project budgeting, the project cost
estimation tools, as well as to the project manager.

• Project Lessons Learned

• Lessons Learned Agenda
End of Phase QA / Lessons
  • Peer review of conformance to PM Framework and best practices. Reference:
Learned
• QA Framework
• Project Surveying

 indicates that a task is recommended for this type (L/M/H) of project.

Bolded tasks indicate required steps to “Follow the Framework”. See Appendix for L/M/H guides.
Last Saved: 8/2005 HRB Project Management Framework v2.0.12 Page 34
PM Framework Appendices

Mission
 Frequently Asked Questions

 High / Medium / Low Project Management Effort

 Confidence Level in Estimates / Contingency

 Sarbanes-Oxley 404 Compliance

 Advisors to the PM Framework

HRB PMF Appendices

Last Saved: 8/2005 HRB Project Management Framework Page 35
Frequently Asked
Questions
Welcome to the Project Management Framework! Below are some frequently asked questions concerning this version of the PM Framework.

Q: What happened to the old “chevron” PM Framework from FY05?

A: Nothing! It’s still there, but it has been renamed to the Systems Development Lifecycle (SDLC) because of it’s technology focus. It is
available in this document by clicking here.

Q: Are there two frameworks now?

A: No, there are now two “views” of the same core framework. There has been an increasing interest in developing a project management
framework for projects that are not technology focused. To fill that need, the PMO has developed a new “view” of the PM Framework which
essentially removes all but the core project management components. It should be applicable to any type of project and is called the Project
Management Lifecycle (PMLC). It is available in this document by clicking here.

Q: Do I have to use both views (SDLC and PMLC) of PM Framework on my project?

A: No. The SDLC contains all of the essential components of the PMLC. It is a self-contained lifecycle, as is the PMLC.

Q: What if I see a deliverable in the PMLC that I want to use? May I mix and match job aids?
A: Absolutely! The PM Framework is not intended to be a step-by-step methodology - it is a framework that Project Managers should start
from but customize to fit their project’s needs.

Q: What about SOX and other audits? Will I have to be using a certain lifecycle of the PMF to be “SOX compliant”?
A: No. Audits focus on sound project management principles, demonstrated by adherence to either of the two lifecycles. Make sure you
have completed the Compliance Checklist for the lifecycle you are using. Contact the PMO or the SOX team with specific questions.

Q: How do I choose which lifecycle to follow?

A: Most (75-85%) of all technology projects will continue to use the SDLC. It is incumbent on the Project Manager to chose the lifecycle that
best fits their project’s needs. The PMO is available to help you make this choice if you have any questions.

Q: I still have more questions!

A: Contact the PMO using the Program Office mailbox or call any of members of the PMO team.

HRB PMF Appendices

Last Saved: 8/2005 HRB Project Management Framework Page 36
High/Medium/Low Project Management
Effort
All projects should be classified as “high”, “medium” or “low” according to how much project management effort they require. The
classification will help determine which key tasks within the framework should be completed for that project. The continuum below provides
some guidelines, but the Project Manager and the PMO should make the final determination together.

Low Medium High

<100 hours 100 to 1000 hours > 1000 hours

low capital outlay moderate capital outlay significant capital outlay

well-defined technology/process/business new technology/process/business

no risk low risk some risk high risk
completely self contained project moderate impacts/integration far reaching impacts/integration

All projects should “Follow the Framework” by completing the recommended tasks by high/medium/low classification. The Project Manager
must exercise good judgment as to the “degree of formality” required when completing a task.

For example, a multi-phase, high risk/reward project such as Major Franchise Acquisition should clearly have a formal Service Request,
PIR, Project Board meetings, a detailed Deployment Plan, etc. A simple project such as an Oracle upgrade for a non-mission critical
application may only have an e-mail containing the initial request, a few face-to-face (but documented!) meetings to define the steps and
schedule, and a simple go/no-go conference call.

Project Managers should always feel free to contact the Program Office if they have questions about which tasks to complete and how
formally they should be completed.

HRB PMF Appendices

Last Saved: 8/2005 HRB Project Management Framework Page 37
Confidence Level in Estimates /
Contingency

Contingency

Confidence Level in Estimates

As the project progresses, a greater level of confidence should be able to be

applied to the estimates around project schedule and project budget. At the same
time the level of contingency required should decrease as the confidence in the
schedule and the budget increases. At the end of each phase, the project manager
should re-assess the estimates included in the project schedule and project budget
and make the appropriate updates. Updates to the schedule, budget and
contingency will be taken before the project board for review and approval.

HRB PMF Appendices

Last Saved: 8/2005 HRB Project Management Framework Page 38
Sarbanes-Oxley 404 Compliance

The Project Management Framework is extremely important in

maintaining compliance for Sarbanes-Oxley 404.
Specific actions each project should follow:

The framework must be followed for all projects

The Compliance Checklist must be completed to indicate if a deliverable was
or was not completed

If a deliverable is not completed, a reason for non-compliance must be documented

Quality Assurance reviews must be scheduled and executed with the
project’s respective QA / QC department at the end of each framework phase

All deliverables and documentation must be stored in the HRB Projects
directory or contain a link to it from the HRB Projects directory

Any deviation from the framework on a project needs to be discussed with
Jeff Phillips or Greg Maltby, the SOX Subject Matter Experts

HRB PMF Appendices

Last Saved: 8/2005 HRB Project Management Framework Page 39
Advisors the PM Framework
Subject Matter SME Contact
Long Range Planning, Project Initiation, Duane Aldridge, Gary Broils, Tiffany Hiller
Pipeline Management, LOE Estimates
Project Cost Management Donna Rosenbaum, Matt Dayton
Resource Planning & Management Patrick Allen
Requirements Planning & Mgmt Krista Nelson, Brett Nugent, Duane Aldridge
Quality Assurance Mike Deloney, Mario Potts
Development Cliff Harrison, Umesh Kunigahalli, Ken Meade, Patrick Steiner
Database Shelley Weakley, Bob Horkay, Mark Sander
Risk Management Bob Bolinger
Capacity Planning Mark Richardson, John Leek
Design & Architecture Ken Wiebke, Steve Chase, Michael Pastushkov
Infrastructure Planning & Mgmt Mark Richardson, Tim Brownfield, James Maynard
Software Configuration Management Sheryl Saunders, Terry Cox
Operational Readiness and FLS Certification Jim Slinkard, Ron Morgan, Randy Buckman
Operations and Support Steve Erke, Steve Salter, Chris Baker, Dennis Ehrich, Keith
Harrington
Disaster Recovery David Christianson
Information Security James Maynard, Mark Butler
Deployment Management Jim Slinkard, Ron Morgan
Service Level Agreements Mark Chapman, Ron Morgan, Terry Cox, Randy Buckman
Enterprise Sourcing and Settlement Matt Pyle, Vernon Thompson
Regulatory Compliance Ken Madsen – HRBFA, Murray Walton – HRB
Sarbanes-Oxley 404 Compliance Jeff Phillips, Greg Maltby
HRB PMF
Appendices
Last Saved: 8/2005 HRB Project Management Framework Page 40

A. Westwood - PMP Exam Prep - The Comprehensive Guide To Passing The Exam On Your First Try (2023, Project Management Publishing) - Libgen - Li
No ratings yet
A. Westwood - PMP Exam Prep - The Comprehensive Guide To Passing The Exam On Your First Try (2023, Project Management Publishing) - Libgen - Li
358 pages
Project Management and PMP Courses V6
No ratings yet
Project Management and PMP Courses V6
452 pages
121905000-KM-02 - Facilitator Guide
No ratings yet
121905000-KM-02 - Facilitator Guide
15 pages
121905000-KM-01-Summative Assessment Memo
No ratings yet
121905000-KM-01-Summative Assessment Memo
12 pages
Lec 6 PM 3 Project Integration MGT and Time MGT
No ratings yet
Lec 6 PM 3 Project Integration MGT and Time MGT
95 pages
121905000-KM-01-Learner Guide
No ratings yet
121905000-KM-01-Learner Guide
69 pages
Agile Estimation Workshop
No ratings yet
Agile Estimation Workshop
18 pages
PMP Liste Processus
No ratings yet
PMP Liste Processus
20 pages
The+PMP+Fast+Track David+McLachlan
No ratings yet
The+PMP+Fast+Track David+McLachlan
34 pages
Project Mnagement Framework & Initiation
No ratings yet
Project Mnagement Framework & Initiation
73 pages
Coursebook Management Coaching (Whole Course)
No ratings yet
Coursebook Management Coaching (Whole Course)
242 pages
MODULES
No ratings yet
MODULES
14 pages
Effective Team Formation
No ratings yet
Effective Team Formation
187 pages
9750 KSB Rot Man 0001 - B - Installation and Operating Manual
No ratings yet
9750 KSB Rot Man 0001 - B - Installation and Operating Manual
425 pages
Itto
No ratings yet
Itto
19 pages
Entrepreneurial Finance
100% (1)
Entrepreneurial Finance
112 pages
Process ITTO Guide
No ratings yet
Process ITTO Guide
20 pages
PMP Cheat Sheets PDF Uuixn0
No ratings yet
PMP Cheat Sheets PDF Uuixn0
32 pages
Module 1 PM Fundamentals DP V2 (OS)
100% (1)
Module 1 PM Fundamentals DP V2 (OS)
74 pages
Atoha PMPPRO S2 - Integration
No ratings yet
Atoha PMPPRO S2 - Integration
63 pages
How To Memorize The PMP Process Chart in
No ratings yet
How To Memorize The PMP Process Chart in
12 pages
KM 01 Summative Assessment
No ratings yet
KM 01 Summative Assessment
14 pages
Atoha PMPPRO S11 - Stakeholder
No ratings yet
Atoha PMPPRO S11 - Stakeholder
33 pages
Atoha PMPPRO S4 - Schedule
No ratings yet
Atoha PMPPRO S4 - Schedule
46 pages
Project Success Report 2024
No ratings yet
Project Success Report 2024
45 pages
National Federation of Junior Philippine Institute of Accountants
No ratings yet
National Federation of Junior Philippine Institute of Accountants
36 pages
Global Star Rating Manual - English - V
No ratings yet
Global Star Rating Manual - English - V
96 pages
Business Proposal
100% (1)
Business Proposal
22 pages
Microeconomics Chapter 1 MCQs
No ratings yet
Microeconomics Chapter 1 MCQs
9 pages
PMP - 02 Integration
No ratings yet
PMP - 02 Integration
25 pages
Chapter 2-3
No ratings yet
Chapter 2-3
26 pages
Atoha Pmppro s5 - Cost
No ratings yet
Atoha Pmppro s5 - Cost
37 pages
Insurance Notes - Tambasacan
No ratings yet
Insurance Notes - Tambasacan
13 pages
Stocks Pick
No ratings yet
Stocks Pick
56 pages
Atoha PMPPRO S8 - Communication
No ratings yet
Atoha PMPPRO S8 - Communication
38 pages
PMP Cost
No ratings yet
PMP Cost
82 pages
Session 2. Project Integration Management
No ratings yet
Session 2. Project Integration Management
33 pages
4-5. PEC - PMP - PM Processes - Initiating Group PDF
No ratings yet
4-5. PEC - PMP - PM Processes - Initiating Group PDF
16 pages
Lesson 14-PMP - Process Group View - V3
100% (1)
Lesson 14-PMP - Process Group View - V3
25 pages
For OYO
No ratings yet
For OYO
3 pages
Atoha Pmppro s3 - Scope
No ratings yet
Atoha Pmppro s3 - Scope
50 pages
MSY Affidavit Format
No ratings yet
MSY Affidavit Format
2 pages
SH Questions
No ratings yet
SH Questions
21 pages
Project Control Book: Project Information Links To Key SVC Providers
No ratings yet
Project Control Book: Project Information Links To Key SVC Providers
40 pages
Partnershipco Ownership Estate and Trust Long Quiz
No ratings yet
Partnershipco Ownership Estate and Trust Long Quiz
3 pages
TS-SLW700AIWA усилвател PDF
No ratings yet
TS-SLW700AIWA усилвател PDF
35 pages
PMP Tools and Tech Final
100% (1)
PMP Tools and Tech Final
20 pages
Public Relation and Advertising
No ratings yet
Public Relation and Advertising
8 pages
Paris Fashion Show Infographics by Slidesgo
No ratings yet
Paris Fashion Show Infographics by Slidesgo
17 pages
F Cash 8 Maria, Capital: Date Particulars Debit
No ratings yet
F Cash 8 Maria, Capital: Date Particulars Debit
33 pages
PMP Predictive Notes
No ratings yet
PMP Predictive Notes
14 pages
Itto Pmbok 5
No ratings yet
Itto Pmbok 5
19 pages
Project Planning and Management
No ratings yet
Project Planning and Management
24 pages
Item Name HSN Code GST Rate QTY Rate Amount
100% (1)
Item Name HSN Code GST Rate QTY Rate Amount
5 pages
5.project Scope Management
No ratings yet
5.project Scope Management
24 pages
Class 12 Accounts Notes Chapter 1 Studyguide360 - 2
No ratings yet
Class 12 Accounts Notes Chapter 1 Studyguide360 - 2
17 pages
Screenshot 2025-02-27 at 18.33.13
No ratings yet
Screenshot 2025-02-27 at 18.33.13
2 pages
Project Integration Management: Pmbok® Fifth Edition
No ratings yet
Project Integration Management: Pmbok® Fifth Edition
36 pages
Domain Analysis: © 2009 Pearson Education, Inc. Publishing As Prentice Hall
No ratings yet
Domain Analysis: © 2009 Pearson Education, Inc. Publishing As Prentice Hall
45 pages
Pmp-Exam-Prep-T90 9
No ratings yet
Pmp-Exam-Prep-T90 9
8 pages
PMP Itto Mnemonics
100% (1)
PMP Itto Mnemonics
5 pages
June 2023
No ratings yet
June 2023
11 pages
Process #1: Develop Project Charter: - PG 75, PMBOK 6th Ed
No ratings yet
Process #1: Develop Project Charter: - PG 75, PMBOK 6th Ed
9 pages
PMP Study Notes Donkim 2007
No ratings yet
PMP Study Notes Donkim 2007
56 pages
Flipkart Labels 14 Apr 2023 10 11
No ratings yet
Flipkart Labels 14 Apr 2023 10 11
7 pages
Form PDF 767967830311221
No ratings yet
Form PDF 767967830311221
6 pages
PMP (2021 Alig)
No ratings yet
PMP (2021 Alig)
3 pages
02 - 05 Planning Process Group
100% (1)
02 - 05 Planning Process Group
7 pages
Risk Assessment - Manual Handling
100% (1)
Risk Assessment - Manual Handling
1 page
Reliability & Maintainability Exam Solutions 2010
No ratings yet
Reliability & Maintainability Exam Solutions 2010
9 pages
Fee Structure Trident Schools 2024
No ratings yet
Fee Structure Trident Schools 2024
3 pages
Steel Construction UKCA Marking v3
100% (1)
Steel Construction UKCA Marking v3
20 pages
Project Management GuideBook PDF
No ratings yet
Project Management GuideBook PDF
18 pages
Hindustan Unilever Limited: Company Profile
No ratings yet
Hindustan Unilever Limited: Company Profile
5 pages
Preparing For Capm Pmi
No ratings yet
Preparing For Capm Pmi
9 pages
Airway Bill
No ratings yet
Airway Bill
8 pages
Third Quiz of MGt503 16-12-2011
No ratings yet
Third Quiz of MGt503 16-12-2011
10 pages
Drive 5 PMP Questions and Answers
No ratings yet
Drive 5 PMP Questions and Answers
4 pages
Project Scope Management and Its Importance in 2022
No ratings yet
Project Scope Management and Its Importance in 2022
31 pages
Critical Success Factors For Project Management Office - An Insight From Indonesia
No ratings yet
Critical Success Factors For Project Management Office - An Insight From Indonesia
6 pages
Aer Lingus Interview Tips and Guidelines
No ratings yet
Aer Lingus Interview Tips and Guidelines
2 pages
PMP PMI Rita Framework
No ratings yet
PMP PMI Rita Framework
7 pages
How Has Mass Media Influenced Your Decisions and Choices in Life
No ratings yet
How Has Mass Media Influenced Your Decisions and Choices in Life
1 page
B.Sc. Phy. Education & Sports 2nd Semester
No ratings yet
B.Sc. Phy. Education & Sports 2nd Semester
2 pages
Travelport Viewtrip - My TripNURE
No ratings yet
Travelport Viewtrip - My TripNURE
2 pages
Exam Ipmp
No ratings yet
Exam Ipmp
10 pages
PMP Ten Step Training
0% (1)
PMP Ten Step Training
5 pages
Initiating Planning Executing Monitoring & Controlling Closing Project Integration Management
No ratings yet
Initiating Planning Executing Monitoring & Controlling Closing Project Integration Management
9 pages
Project Management
No ratings yet
Project Management
1 page
PMP® Success Guide
From Everand
PMP® Success Guide
SUJAN
No ratings yet