RFI Attachment 2 - PMLC Overview_Additional Guidance - 202000423.pdf
PDF 763 KB Posted
- Solicitation number
- 47QFPA20N0002
View the file
Other files
On GovTribe
Work with this file
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
NOTE: Hyperlinks in this document do not work. The purpose of this document is to provide a high-level overview of the Library’s PMLC process. Supporting document templates, guides and other information that supports the execution of these processes have not been included in this overview.
PMLC Directives: Initiation (Phase 1)
Workflow Diagram
RACI Chart:
Process Details
1. Approved Investment. An outcome of the Library's IT Planning cycle, an approved investment initiates the project PMLC
2. Finalize Scope statement. Service unit provides a description of the business need and justification of why it should take place
3. Develop & prioritize High-level Business requirements. An artifact outlining a large body of work
(i.e. features) that is confined to the boundaries described in the scope statement
4. Request Project ID. After an IT investment is approved, the Customer Liaison for the project will request to initiate each activity identified as a project in the Investment using the IT PMO Project Access tool which results in the creation of a new Project ID.
5. Assign Project Manager. For each requested project, the IT PMO will verify the requested project is associated with an approved Investment. IT PMO will also assign Project Manager, if requested by Project Owner, and authorize the creation of a project site in the IT PMO Confluence for storing, collaborating and reviewing project documents. Confluence project site requests may be sent to cms@loc.gov.
6. Develop Agile suitability scorecard & Classification worksheet.
7. Confirm Technology direction. Based on Technical expertise, high level business requirements and associated project artifacts (i.e. Agile suitability scorecard and classification worksheet), the OCIO directorates recommend a viable technology direction https://staff.loc.gov/resources/download/attachments/17302059/PMO%20Project%20Access.accdr?api=v2 https://staff.loc.gov/resources/download/attachments/17302059/PMO%20Project%20Access.accdr?api=v2 mailto:cms@loc.gov
8. Identify Roles and allocate resources. After all stakeholders have approved the technical content of the charter, the OCIO Resource Managers verify requested resources are available to perform the work during the schedule provided.
9. Develop a sprint plan or a high level implementation roadmap. Service units in collaboration with the other key stakeholders (i.e. Business analysts) shall develop a high level implementation roadmap and/or sprint plan
10. Develop procurement package. The Project Manager shall coordinate with respective OCIO directorates and the Contracting Officer Representative to develop/initiate the procurement package.
Additional considerations to include:
Verify and analyze project estimate. If not known up front, the Project Manager will coordinate and work with Project Owner, Resource Managers, Solutions Architects, Technical Lead, Business Analyst, Subject Matter Experts and other stakeholders as necessary to determine the high level requirements, proposed solution, technology approach, project cost, length and cost estimates, and staff resources required to implement the project by following the Cost Estimating Process and developing associated deliverables. This analysis may include conducting formal Assessment, Alternative/Cost Benefit Analysis or other preliminary analysis.
Review resource contention. Projects with resource contention issues must be reviewed at a
Project Portfolio Review meeting to resolve the resource issue.
o At the meeting, the PMO will show current project allocations across OCIO projects and specific areas of resource contention.
o In consultation with the PMO and OCIO management team, the CIO will make a final decision on whether or not to approve the project. This may require changing the timeline or scope of the project and/or shuffling resource allocations to other projects.
o If the CIO decides not to approve a project to proceed, the Investment and Project Sponsor may withdraw the project or defer it to a future year which would end the project initiation process for the current project. Note, deferred or withdrawn projects should also be updated in the corresponding Investment
11. Develop Budget worksheet. Based on the solution proposal, technology approach, and project estimates, a Project Charter Package is developed including the draft Project Charter with the requested scope, cost, schedule, and resources for the project, Project Personnel Budget,
12. Develop Project charter. Based on the solution proposal, technology approach, and project estimates, a Project Charter Package is developed including the draft Project Charter with the requested scope, cost, schedule, and resources for the project, Project Personnel Budget, PMO Project Classification Worksheet and the Agile Suitability Scorecard
13. Project charter Technical Review. The draft charter package is reviewed via a multi-step charter review process, with reviews by multiple project stakeholders, including:
Project Sponsor - Senior Service Unit manager who authorizes the project and confirms SU resources required for this project are available
IT Investment Owner – Ensures project is in alignment with investment goals and objectives
Project Owner – Provides project scope and expected outcome for project. Is expected to partake in the project on a day-to-day basis for general decision-making. May also be the Product Owner or System Business Owner for the corresponding system or product.
Partner Engagement Manager – Serves as primary OCIO representative for Service Unit, maintains general awareness of project progress, and provides an escalation path for project issues
Resource Manager/Tower Owner – OCIO Director or Manager who ensures technology approach is feasible and IT resources required to perform work, including both personnel and non-personnel IT resources, are accurately represented and available as assigned. Generally includes OCIO IT Systems Operations, Design and Development, and Security.
https://staff.loc.gov/resources/display/PMO/Cost+Estimating?src=contextnavpagetreemode https://staff.loc.gov/resources/display/PMO/Cost+Estimating?src=contextnavpagetreemode https://staff.loc.gov/resources/display/PMO/Assessment+Process https://staff.loc.gov/resources/download/attachments/17993618/Project_Charter_Template.doc?api=v2 https://staff.loc.gov/resources/download/attachments/17993618/Project_Personnel_Budget_Template.xlsm?api=v2 https://staff.loc.gov/resources/download/attachments/17993618/Project_Charter_Template.doc?api=v2 https://staff.loc.gov/resources/download/attachments/17993618/Project_Personnel_Budget_Template.xlsm?api=v2 https://staff.loc.gov/resources/download/attachments/17993618/Project_Classification_Worksheet.xlsx?api=v2 https://staff.loc.gov/wikis/download/attachments/17993618/Agile_Suitability_Scorecard.xlsx?api=v2 https://staff.loc.gov/wikis/display/PMO/Project+Charter+Review+Process+Workflow https://staff.loc.gov/wikis/display/PMO/Project+Charter+Review+Process+Workflow
Project Management Officer – Ensures charter follows PMO project charter checklist and general PM best practices, and that project scope, schedule and costs are clearly defined and verifiable
IT Management Portfolio Officer – Confirms project costs are appropriately captured and covered by the corresponding investment
Other Stakeholders – Other individuals or groups who may be knowledgeable, interested in, and/or impacted by the project including Project Team Members, End Users, or Subject Matter Experts
14. Obtain signatures from reviewers. Prior to the Final Charter review, the Project manager is responsible for obtaining signatures from all of the reviewers
15. Final Charter review. The final charter is then discussed at a Final Charter Review meeting for review and approval by the CIO/DCIO and Project Sponsor. Signatures from the CIO/DCIO and Project Sponsor are obtained at the Final Charter Review meeting. Obtaining all required signatures marks the official approval of the project. If the Project Sponsor is expected to be unable to attend the meeting to sign the charter, the Sponsor must sign the charter prior to the meeting. The CIO and DCIO will not sign the charter until the Sponsor and all other reviewers have signed
16. Revise & Finalize charter package. If issues are discovered by one or more stakeholder, the draft charter is revised.
Obtain signatures from all "Other Approvers" in charter, and schedule kickoff meetings. Once any issues or discrepancies have been resolved, the final Project Charter package is prepared including agreed upon scope, schedule and staffing resources. All signatures listed under the "Other Approvers" section in the charter are then obtained, and the kickoff meeting is scheduled to occur on or shortly after the planned project start date (see step 11 below). The Project Manager uses the Project Initiation Checklist to document that all required deliverables have been completed and signed and that the kickoff meetings have been scheduled
17. Kick off project. As the final step in the Initiation phase, the Project Manager notifies the PMO governance team (PMmail@loc.gov) once the kick off meeting has been scheduled. The kicks off meetings include:
Project Kickoff Meeting: The purpose of the Project Kickoff Meeting is to formally notify all team members, users, and stakeholders that the project has begun and make sure everyone has a common understanding of the project and their roles.
Technical Kickoff Meeting: In addition, for IT implementation projects, the Project Manager works with the ITD&D Dev/Ops team to facilitate a Technical Kickoff Meeting. The purpose of the Technical Kickoff meeting is to provide an overview of the various Dev/Ops technologies and services, review standard processes and the infrastructure for the Test environments (See the Technical Project Onboarding page for more info).
https://staff.loc.gov/wikis/display/PMO/Project+Charter+Review+Checklist https://staff.loc.gov/wikis/download/attachments/17993618/Project_Initiation_Checklist.xlsx?api=v2 mailto:PMmail@loc.gov https://staff.loc.gov/resources/display/SE/Technical+Project+Onboarding+-+DRAFT
PMLC Directives: Planning (Phase 2)
1. Develop Main Project Management Plan (PMP). The PMP should include the description of project scope as defined in the Project Charter, team members, approach, assumptions, constraints, and dependencies. The PMP serves as the initial planning document for the project.
2. Determine Project Methodology and High Level Schedule or Project Milestones. Based on the type of project, the Project Manager may choose to employ an additional product type-specific methodology to guide the work. For example, system development projects will use the System Development Life Cycle along with the PMLC. Similarly, Commercial Off The Shelf (COTS) acquisition projects may use the SDLC for COTS implementation along with PMLC. Note that whichever methodology may be employed, all projects must minimally follow the PMLC. The PM may consult with the Project Owner to determine which execution methodology is best suited for the project.The Project Manager will develop an initial project schedule following the Scheduling Guidance, optionally using the MS Project Schedule Template. For system development projects, the necessary time to complete Security Assessment and Authorization (A&A) needs to be factored in the project timeline according to Standard Security Assessment and Authorization activities. The schedule should be completed in sufficient detail to allow the PM and project team members to be confident that all major tasks associated with the project are included; however, the project schedule is expected to be updated regularly as the project proceeds.
3. Develop Communications Management Plan, Risk Management Plan, and/or Change Management Plan. Project Manager creates these plans as appropriate based on project classification/size. During the Planning Phase, it is important to consider how communications, risks, and unanticipated changes will be managed over the course of the project as they can impact the schedule and/or outcome of a project and it is important to plan in advance how these changes will be addressed. Note, these planning documents should guide how the project will actually be managed and serve as a roadmap for ensuring the project is successful.
https://staff.loc.gov/resources/display/PMO/SDLC?src=contextnavpagetreemode https://staff.loc.gov/resources/display/PMO/Scheduling+Guidance?src=contextnavpagetreemode https://staff.loc.gov/resources/display/PMO/Scheduling+Guidance?src=contextnavpagetreemode https://staff.loc.gov/resources/download/attachments/17993618/Project_Schedule_Template.mpp?api=v2 http://www.loc.gov/staff/security/docs/Security%20Assessment%20and%20Authoriztaion%20Activities_WBS_19OCT2017.xlsx
PMLC Directives: Execution and Control (Phase 3)
1. Conduct status meetings, track and report progress, and maintain and update the project schedule. The Project Manager conducts regular status meetings to track and report project progress and update the project schedule accordingly leveraging Scheduling Guidance. The Project Manager should use meeting notes to capture key points, decisions and any action items discussed during the meeting. The Communications Management Plan documents the frequency of meetings and status reporting. At a minimum, all projects must be reported at a frequency determined by PMO via the IT PMO Project Reporting process. Agile projects need to use the Initial Milestone spreadsheet to document the baseline milestone information to PMO at PMMail@loc.gov and report milestone status through PMO Project Access.
2. Track issues, risks, and change requests. The Project Manager tracks issues, risks, and change requests as described in the Project Management Plan and subsidiary plans developed during the Planning Phase. In general for smaller projects, the Project Manager maintains a single log for issues, risks, and change requests, while larger projects require a separate log for each.
https://staff.loc.gov/resources/display/PMO/Scheduling+Guidance?src=contextnavpagetreemode https://staff.loc.gov/resources/display/PMO/Monthly+Project+Reporting?src=contextnavpagetreemode https://staff.loc.gov/resources/download/attachments/17993618/Initial_Milestone_Report.xlsx?api=v2 https://staff.loc.gov/resources/download/attachments/17993618/Initial_Milestone_Report.xlsx?api=v2 mailto:PMMail@loc.gov https://staff.loc.gov/resources/download/attachments/17302059/PMO%20Project%20Access.accdr?api=v2 https://staff.loc.gov/resources/display/PMO/Project+Change+Management?src=contextnavpagetreemode https://staff.loc.gov/resources/display/PMO/Project+Change+Management?src=contextnavpagetreemode
PMLC Directives: Closeout (Phase 4)
1. Conduct Lessons Learned and publish results. The Project Manager meets with project team members and primary stakeholders to conduct a lessons learned meeting based on the questions provided in the checklist. The Project Manager then combines meeting results with lessons from the project documentation (such as status reports and issue logs) and creates a Lessons Learned document. Lessons Learned of completed projects are archived here.
2. Finalize documentation, collect, and archive project artifacts. Before closing the project, the
Project Manager reviews and updates the documentation as necessary to ensure all documents reflect the latest version of any changes or decisions.
3. Create closeout report. The closeout report is the final report card for the project and informs management of the projects status at closeout.
4. Release Resources. It is very important to inform management that the project is complete and that dedicated resources are no longer required. This can be done as part of the Closeout Report.
https://staff.loc.gov/resources/display/PMO/Lessons+Learned
File details come from the government source that posted it. Updated .