Chapter 3

Phase II: Create the OPM System Implementation Plan

Introduction

The purpose of this phase is to create an Organizational Portfolio Management (OPM) System Implementation Plan and set the stage for implementation. Also known as Project Management Information Systems (PMIS), the Organizational Portfolio Management System is a software program/application which provides a centralized system and methodology for the management of portfolios, programs, projects, resources and costs, providing visibility into overall and detailed level performance tracking. As an input to this chapter, we have a number of portfolios, anywhere from two to five (10 depending on the size, scope, and span of the organization), scalable as the organization grows (or contracts). Each portfolio has a Portfolio leader established. Each portfolio contains a number of subportfolios, projects, and programs. Each project/program has a Portfolio leader assigned to it, and each Portfolio leader is managing multiple personnel/resources, who likely are participating on other projects as well.

The problem most organizations face is how to oversee not only the Portfolio leaders, but the way the collection of portfolios, programs, and projects collectively interact and operate using shared and constrained resources. One solution is to bring them all together into a Project Office that has all of the Portfolio leaders and project managers reporting to it. Another is to have them all remain independent and reporting to the function that they are concerned with (e.g., all of the Portfolio leaders who are assigned to software programs could be reporting up through the information technology function). All of the new product development Portfolio leaders and project managers could be reporting into different departments in the development organization. Each type of organizational structure has distinct advantages and disadvantages.

Then there are the questions of portfolio operations and governance. Should all of the portfolios within the organization be operating to the same guidelines? For example, should the portfolios that are related to new products operate under the same guidelines as the portfolios that support information technology functions, or would that put too great a constraint on innovation? Each organization must come to consensus on how to agree on common operating procedures to answer, up front, these key questions. How will the outputs from projects that feed into inputs to other projects be connected? Where are the handoffs and points of negotiation? This may be fairly simple when working within a single portfolio of programs and projects, but careful consideration must be given on how to structure and manage outputs (and resource management) across multiple portfolios.

There are advantages to having a Project Management Office established with roles, authorities, and responsibilities clear to all involved. In our experience, organizations trying to manage portfolios of programs and projects without a Project Management Office typically run into conflicts early on during initiation and planning around lack of standard definitions, governing practices, and project management authority. This becomes even more critical during the stages of execution, monitoring, and control.

OPM Systems play a key role in managing the Organizational Portfolio by minimizing the potential for projects continuing to operate past the point when they should have been shut down. Small to mid-sized organizations with four or less portfolios probably do not need a dedicated Project Management Office, and the same principles can be applied by forming a committee that meets and works together to define and agree on the operating rules, reporting, and project status/review process. Portfolio management software also provides visibility for the Portfolio leader working with the program and project managers reporting to their Portfolio leader. Managing across portfolios helps the Portfolio leader add positive value in support of the organization’s strategic objectives, while staying within budget and minimizing resource burdens to the operations, functional work units, and departments they are intended to support.

OPM involves identifying and aligning the organization’s priorities, establishing governance, and providing a framework for performance management and continuous improvement. However, in order to successfully implement a sustainable OPM System, the approach to OPM must go beyond the aggregation of projects, programs, and subportfolios that support the organization’s strategic objectives.

An organization seeking to embrace an OPM methodology must develop the framework and infrastructure for deployment of an OPM System to manage the inherent complexity that arises when the needs of the organization require strategic alignment on its collection of projects and programs. For example, a gap analysis performed recently with a large North American retailer revealed that project management previously had been largely decentralized and that the organization’s strategic plan was not in alignment with the multitude of requests for projects that the senior leadership team was tasked with prioritizing for the upcoming year. A Portfolio Operations Deployment (POD) team was established that consisted of key stakeholders who were facilitated by outside consultants to assemble a complete picture of all current program and project requests. Only with the visibility of having all of the programs and projects on the board did it become clear to the senior leadership team that there were strategic decisions planned for the second and third quarter of the year that would have major implications on projects planned for the first quarter (Q1). These projects would have had major capital investments incurred in Q1, only to be suspended (and likely cancelled) in Q2 or Q3. This simple 360-degree view of the organization’s programs and projects helped save the client tens of thousands of dollars (and countless resource hours) by stopping sure-to-fail projects before they started.

The remaining programs and projects were prioritized against the organization’s strategic objectives using empirical criteria in a matrix similar to the example in Table 3.1.

• Rating: Programs and projects are rated 1 to 5 based on their impact on the specified criterion (established by the steering team) with 1 as low/5 as high.
• Weighting: (Optionally) each criterion can be assigned a weighted value with 1 as low/5 as high if it is desirable to give more “weight” to one or more criteria over the others (e.g., if customer growth and retention is the organization’s top strategic priority, this could be weighted as a 5 and the other criteria given a 4.
• Finally, calculate the total scores for each program and project, then prioritize them to quickly demonstrate which are the top candidates for scheduling and implementation.

  * (Rating × Weight) = Criterion Score

  + Criterion Score + Criterion Score + Criterion Score = TOTAL

Our client in this example also realized the need for a comprehensive centralized OPM System to manage the complexity and need for constrained resources across the spectrum of prioritized programs and projects.

The OPM System solved the organization’s need to have a centralized collection of independent projects or programs grouped together in a centralized database to facilitate its prioritization, effective management, and resource optimization in order to meet strategic organizational objectives.

Activities for Phase II

Phase II (Create the OPM System Implementation Plan) is made up of the following four activities:

Activity #1: Prerequisites for OPM System Implementation Planning

Activity #2: Establish the Project Management Office (PMO)

Activity #3: Assemble the OPM System Implementation Team

Activity #4: Create the OPM System Implementation Plan

Activity #1: Prerequisites for OPM System Implementation Planning

Creation of the OPM System Implementation Plan is dependent on the following prerequisite activities. Assuming the organization is just starting out with a concept of implementing an OPM System, this activity provides the required guidance.

One of the very first things that should be done is to establish an integrated Project Management Plan for each project that includes the following sub-plan elements (Figure 3.1) for effective portfolios.

1. 1. Project Integration Management: Answers the question: Where does this portfolio intersect with its subprograms and projects, or with other portfolios? (Critical to understand and minimize cross-portfolio impacts.)
2. 2. Project Scope Management: The span, scope and boundaries of each project or of the portfolio program (as outlined in the Business Case). Ideally the Project Scope also includes any items that have been identified as out of scope.
3. 3. Project Time Management: Outlined in the Work Breakdown Structure; see next section.
4. 4. Project Cost Management: As outlined in the Value Proposition and Business Case. Derived from the high-level budget outlined in the Value proposition and Business Case, integrates Earned Value Management (EVM).
5. 5. Project Quality Management: Essential to establish how project performance will be measured and evaluated.
6. 6. Project Human Resource Management: Consider use of the Critical Resource Chain method (A Framework of Critical Resource Chain in Project Scheduling1) to maximize and integrate constrained resources within a tight schedule.
7. 7. Project Communications Management: See sample plan in the next section and Chapter 5 (Practical Applications of Change Management within Portfolio Management).
8. 8. Project Risk Management: See sample plan in the next section; also consider the processes outlined in the PMI’s Practice Standard for Project Risk Management,2 which outlines risk identification, risk quantification, risk response development, and risk response control.
9. 9. Project Procurement Management: This may be handled by a dedicated procurement department within the organization, or within the province of the Project Management Office on a dedicated or as-needed basis for individual portfolios, programs, and projects.
10. 10. Project Stakeholder Management: Stakeholder Identification and Engagement is particularly critical across the portfolio as the Stakeholders may very well have differing and often conflicting objectives.
11. 11. Project Change Management: As of this writing, work is under way to introduce Project Change Management within the PMI methodology.
12. 12. Project Information Management: See Activity 4: Sample OPM System Implementation Plan: Section 4. Technology Resource Management Process; Sample Documentation. This element is covered for organizations undertaking PMIS/OPM System implementation.

Activity #2: Establish the Project Management Office (PMO)

Doing a good job at this stage is absolutely crucial.

H. James Harrington

Establishment of the PMO is critical for the success of the OPM System as an organizational unit with authority to affect change (within the boundaries of approved business cases) and serve as central repository for all project artifacts within the organization.

As directed by the Executive Committee, the organization’s PMO is there to not only lead the projects, but to serve as the face of the organization’s change agenda, implementing and integrating the OPM System into existing organizational business processes, including planning, auditing, technology optimization, process optimization, sales, marketing and new product, and service development. The PMO aids in the identification and training of portfolio, program, and project managers, and is an essential actor in the implementation of both the OPM System and the Program Management infrastructure the system is intended to support.

Distributed Portfolio and/or Program and Project Management scenarios in larger organizations may require one PMO for each location. However, if there are separate PMOs for different functions, communication, cooperation, and alignment must be established between them, and the Project Team manager and senior executives must give the Portfolio leader the authority to unify them and bring them together. The OPM System becomes a powerful tool for attaining this required level of synergy across multiple distributed locations. The following high-level tasks should be considered prior to embarking on wide-scale deployment of an OPM System, because the PMO provides a central authority for managing the span of portfolios, programs, and projects across the enterprise.

1. 1. Direction for the establishment a PMO and related activities (or an interim PMO if one does not exist)
2. 2. Establishment of OPM System implementation milestones
3. 3. Outlining of the organizational structure (via org charts) and drafts of job descriptions for the permanent PMO, which defines the roles, responsibilities, and authority for a PMO and the Portfolio leaders
4. 4. Drafting of PMO policies and procedures and reviewing them with the Executive Committee
5. 5. Development of Standard Operating Procedures (SOPs) for the interim (if needed) and permanent PMO
6. 6. Standardization of Portfolio/Project Quality Assurance and Quality Control Processes and PMO templates (see Appendix C)
7. 7. Establishment of permanent PMO measures and reports

At this stage, the organization should be giving serious consideration to chartering a PMO (if one is not already in place). There are many advantages to having a PMO, including:

• Management has a central authority and single point of contact for real-time information, reporting and status on the priorities, and milestones of all programs and projects.
• The PMO has a total view of all the projects and will be the first to go to management to warn when a project should be canceled.
• The PMO highlights projects that are having problems and gets management to react to the problems that require their attention.
• The PMO provides a central contact point to understand what projects are being considered for approval and those not yet ready for official project status.
• The PMO can help prepare value propositions and business cases, and are ultimately held accountable for any overruns in budget, ability to meet schedules, or lack of performance in any of the departments within its projects.
• The PMO plays a difficult role in negotiating project deliverables and tasks with a variety of operations and development managers.

In a recent example from our work with the Office of Innovation and Information Technology (OIT) leadership team and the Program Management Office (PMO) at Nova Southeastern University (NSU) (Fort Lauderdale, Florida), a Strategic Planning Team was chartered in tandem with their Lean Six Sigma Green Belt and Black Belt training to develop a Strategic Planning process that yielded their PMO mission statement aligned to their vision and values.

• PMO Mission Statement: The mission of Project Management Office (PMO) provides an enterprise-wide approach to identify, prioritize, and successfully execute a technology portfolio of initiatives and projects that are aligned with the NSU strategic goals and educational vision. A primary responsibility is to manage and control project constraints by ensuring project plans are implemented on schedule, within scope, and budget. Project management leadership is responsible for establishing and implementing best practices for the benefit of NSU in a way that encourages collaboration, standardization, and overall improvement in our educational community.
• PMO Vision Statement:
  • Build project management maturity at the organizational level.
  • Support students, faculty, staff, and the NSU community as a source of project management leadership and expertise.
  • Promote best practice standards, quality, and methodologies into a project management discipline.
  • Utilize PMBOK-based methodology3 as well as support “best fit” approach for project management at NSU.
  • Provide a channel of communication for project status, financial health, and mitigation of issues, risk, and dependencies across projects, departments, and/or divisions.

Examples of Project Decentralization

Organizations that grow to the size where PMOs and OPM Systems become warranted and justified expenditures often are at a size, breadth, and scope that necessitates project development be geographically and functionally decentralized. With corporate and regional headquarters, branch locations, hubs, and offices (and home offices) in play, the system must adapt to a dispersed and flexible workforce, distributed regionally, if not nationally and internationally around the globe.

In a 2007 self-audit of the Texas Department of Transportation (TxDOT) Field Operations, several essential elements for decentralized project management were recommended. The first recommendation focused on the deployment of standardized tools and strategies to manage their large portfolio of programs and projects and subportfolios. According to the audit report, “Developing standardized strategies and tools for managing project schedules throughout the project development life cycle would improve execution of the planning process for future projects and improve the accuracy of reported schedule progress. Potential issues could be identified early in the development process” so the execution strategy could be adjusted to ensure milestones are achieved.

Following the release of the audit report, the administration set up a working group to identify and recommend a statewide OPM System for use during project development. They recommended the use of Critical Path Method (CPM) scheduling and implementation of Oracle’s Professional Project and Portfolio Management software application.

Although CPM scheduling is not uncommon for transportation project development, its use at the portfolio level of the enterprise had been uncommon in the public sector, in part because CPM scheduling requires trained employees with skills in both (industry specific) project development and formal project management.

In addition, the TxDOT work group recommended and implemented an interim Project Management System for all projects in active development, and an interim PMO to give them the best chance of meeting the key milestones identified and achieving their strategic objectives.

Activity #3: Assemble the OPM System Implementation Team

Establishing clear roles and responsibilities is crucial at this stage.

H. James Harrington

While in most cases the Portfolio leaders do not directly manage the employees that roll up under their programs and projects, they are directly responsible for the time to which various resources are committed throughout the project and delegating the activities described in the work breakdown structures across the series of programs and projects under their span of control. The Portfolio leader also should be highly capable of motivating individuals to complete work when the individual may not always see the big picture or rationale for the importance of the given tasks and roles. The Portfolio leader can explain that the individual’s completed work may be required for other team members to complete their tasks. The Portfolio leader reviews and provides input on program and project plans prepared by other project managers who work within the portfolio of their responsibility, such as training and mentoring programs and project managers to improve their knowledge and base of experience, thereby increasing organizational capacity.

There is a certain subtle art in mentoring project managers working on your portfolio without giving the impression that you are dictating to them or circumventing the authority of their existing management structure that provides the structure for their daily work (their perceived “real job”).

In order to ensure the success of the organization’s key objectives, the organization’s professional project managers should have a defined career path toward becoming a Portfolio manager. In order to ensure the success of the organization’s portfolios, programs, and projects, the Portfolio Steering Committee and all aspiring Portfolio leaders also must be able to answer—or find the answers—to the following five essential questions:

1. 1. How does our portfolio align with the organization’s strategic objectives? (This should be clear at this stage.)
2. 2. Who are the primary stakeholders of our portfolio and how will the results and status of the portfolio be communicated and reported? (This should be included in the stakeholder register.)
3. 3. What levels of training, experience, abilities, and knowledge should be required of potential Portfolio managers?
4. 4. What is the current baseline skill level of the current project managers? Is the performance delta between project and Portfolio leaders known and understood?
5. 5. How do you evaluate individual project managers and give feedback to them when you are not their manager? (Consideration should be given to both the interpersonal and technical results of their project management activities.)

Corporate culture is shifting to support collaboration in a less isolated work environment. They see the value and advances in productivity they get from making their workers more comfortable with each other, building trust, and, ultimately, making the company a lot more money in its respective market.

For additional information on the roles/definitions of portfolio, program, and project managers and associated teams, see Appendix A: Project and Portfolio Management Definitions; Organizational Influencers on the Project Lifecycle. At a high level, Portfolio Managers manage portfolio components, programs, and projects against strategic objectives. Program managers manage programs and projects that are best managed when grouped collectively, and project managers plan and manage temporary endeavors to achieve specific requirements versus the constraints of time, cost and resources.

Activity #4: Create the OPM System Implementation Plan

The section that follows is a detailed sample OPM System Implementation Plan that can be used as a template for outlining milestones and project artifacts. A sample organizational chart is provided, as well as an outline of scope and responsibility, and Project Management and Change Management processes (including scheduling, budgeting, assumptions, dependencies and constraints, risk management, change management, and control).

Then, the Technology Resource Management process outlines a sample system environment, methodology, and support systems overview and common documents generated during the OPM System Implementation Project.

There are certain decisions that will impact the way the organization adopts, utilizes, and supports the OPM System. For example, the decision is to go with a traditional client server-based system maintained on internal servers in-house, or utilization of Software-as-a-Service (SaaS)-based products that provide greater degrees of flexibility and scale, typically at a lower cost.

We see adoption of SaaS from on-premise as a way to gain faster access to key functional IT PPM capabilities without maintenance or internal labor costs and with decapitalization benefits.

Application Life-Cycle Management Market Data Analysis; International Data Corporation (IDC), December 2013

Finally, the sample plan concludes with resource and work management, and budget and resource allocation, including a sample cost/benefit analysis.

Sample OPM System Implementation Plan

1. 1. Introduction
   1. 1.1 Executive Overview
   2. The purpose of the OPM System Implementation Project is to deploy OPM System software, policies, and procedures, including alternate/optional components including organizational structure and reporting. The software will be tested for three months on a sample program to ensure all applicable features are enabled and provide lessons learned, which will be used as the basis for portfolio/program/project manager (PM) training on the new system. The software has an existing per license startup cost, plus additional costs to be determined for vendor configuration and consulting support.
   3. The objectives of this initiative are to:
      1. A. Procure and implement a OPM System
      2. B. Implement project time tracking and resource management
      3. C. Create standard reports within the overall PMO governance structure
      4. D. Elicit additional requirements for eventual integration with other back-office systems (including but not limited to Active Directory, HR, and Finance)
   4. 1.2 Milestones
      1. 1. Create the database and central archive/project repository
      2. 2. Gather input from the test (process execution and end user input)
      3. 3. PM training (process execution and usability review)
      4. 4. Time tracking workshops
      5. 5. Completion of Change Management phase (including enrollment, communication, training, documentation, and end-user support)
      6. 6. Reporting (including milestone reporting, portfolio roll-up, resource, time, and task detail)
      7. 7. Implementation and Integration
   5. 1.3 Glossary
   6. Optionally, this section can provide standard operational definitions for common technical terms and acronyms incorporated in this plan.
2. 2. Project Components
   7. 2.1 Project Artifacts
   8. Use this section to manage the artifacts intended to be produced and/or utilized throughout the scope of the project, inclusive of the following components (Table 3.2).
   9. 2.2 Portfolio Management Organization
   10. Sample organizational chart (Figure 3.2).
   11. 2.3 Scope and Responsibility
   12. The sponsor, in alignment with the organization’s strategic objectives, has allocated budgeting and management authority for this initiative. This project is within the span of control of the organization’s Program Management Office (PMO), and a dedicated project manager (PM) has been appointed. Subject Matter Expertise (SME) and end-user testing (UAT) will be utilized to failsafe the implementation of the OPM System. System manuals will be provided by the vendor; end-user training, documentation, and job aids will be developed by the Change Management/Training Team in coordination with Information Technology and Systems Support.
   13. 2.4 Implementation Responsibility
   14. Utilize this section to expand upon the sample roles and outline responsibilities as appropriate throughout implementation’s lifecycle:
       • Project Team Manager: Secures implementation-required resources and provides technical and political direction to individuals working on a specific project/program
       • Project Manager: For implementation of the OPM System
       • Change Management, Communications, and Training Team
       • Deployment Team Members: With resources and approval to carry out required tasks
       • Database and System Administration: For support and maintenance of the system
       • Information Technology and Systems Support: For general ongoing user support
   15. (See Appendix A: Project and Portfolio Management Definitions; Organizational Influencers on the Project Life Cycle)
3. 3. Project Management and Change Management Processes
   16. 3.1 Schedule
   17. The schedule for this project is designed for concurrency and speed of implementation (in under a year). Driving factors include planned expansion into new markets that will drive exponential growth and new project requests. Project Teams will meet biweekly at first (Monday a.m. goal setting, and Friday p.m. weekly status reviews). A third Wednesday mid-week status meeting will be inserted at the first sign of project slippage. Sponsor debriefs will be held every other week or as needed on an ad hoc basis. Project status reports will be uploaded to the central repository each week, and made available as needed for executive and Portfolio Steering Committee monthly and quarterly reviews.
   18. 3.2 Budget Review
   19. The project manager is responsible for adherence to the project schedule and budget. Variation +/– 5 percent of the project budget and/or schedule requires immediate review with the Project Team manager.
   20. 3.3 Assumptions
   21. The only assumptions are that the project will continue to be funded (and staffed) as long as it stays on track within the published schedule. Barring major financial or environmental impacts, the project is intended to be completed on time, within budget.
   22. 3.4 Dependencies and Constraints
   23. The implementation of the OPM System is dependent on alignment of the organization’s strategic plan 2014–2015. The only other dependency is the decision on optional system integrations (with Active Directory, HR, and/or Finance).
   24. The existing constraints include the organization’s capacity for planning and prioritization of projects to be managed through the OPM System. A minimum of one program or project is required for the pilot phase. Once the project is successfully under way, time tracking will be enabled for the end-user testing phase.
   25. 3.5 Risk Management
   26. The Project Team manager is responsible for ensuring the Project Team identifies, prioritizes, and mitigates any known or possible risks to successful completion, as well as the ongoing sustainability of the system. The known risks to date are as follows:
       1. 1. Senior management commitment: This project cannot proceed until this risk is mitigated; it will require alignment within the ranks of the Executive Committee, before any vertical alignment is attempted with the rest of the organization.
       2. 2. Alignment with Strategic Objectives: Implementation of the OPM System will require changes to the way the organization adapts to and aligns its objectives to support the overall strategic plan 2014–2015.
       3. 3. Resistance to change: Project managers will need to actively involve their teams, subject-matter experts (SMEs), and change agents (to be identified) to ensure their enrollment with the change effort to minimize resistance to change. This system and its outcome reports will only be as good as the quality of input required to get actionable information up to senior management.
       4. 4. Technical and environmental constraints: Contingency plans must be in place for system/database redundancy off-site at a secured location. Within the Wide Area Network (WAN) and Local Area Networks (LANs), access to the system is to be always on to minimize impacts to the project schedule. Service levels will be established to ensure 99.9 percent system uptime within normal business hours including Saturdays, with an agreed upon (tentative) maintenance window of Saturday from midnight until 2 a.m. for planned/scheduled downtime for database backups and system maintenance.
   27. 3.6 Change Management and Control
   28. Change Control Board: In Information Technology and software development, a Change Control Board (CCB) or Change Control Committee is a committee that makes decisions regarding whether or not proposed changes to a project should be implemented, evaluating potential impacts to stakeholder groups or other systems. In many cases, the CCB also reviews results of implemented changes, and evaluates corrective actions in the event planned changes have any adverse impacts.
   29. The project manager reports to the Change Control Committee on a weekly basis to inform about any planned actions that may impact the assembled stakeholders from the various technical and functional units/teams. The Change Control Committee will come to consensus on planned changes impacted by or impacts to the implementation of the OPM System. The project manager is responsible for updating the project plan and risk register as impacts are identified and reporting back to the Project Team manager if there will be any impacts that could impact the project schedule. The project manager will report back to the Change Control Committee on the status of all scheduled updates for the purposes of corrective and preventive actions that will ultimately guide the implementation of the system across the enterprise.
   30. The OPM implementation team (in coordination with the change management team) accordingly reports back to the Change Control Committee on all status relating to the implementation, end user acceptance, and adoption of the final implemented product.
   31. If impacts are above tolerable thresholds at any point in time during the implementation, the project manager and the Change Control Committee will enact emergency rollback and recovery to ensure no other systems or functional user groups are impacted by changes determined to be problematic. The Project Team manager is ultimately responsible for the successful implementation of the system across the enterprise of portfolios, programs, and projects.
4. 4. Technology Resource Management Process
   32. 4.1 System Environments, Methodology, and Support Systems
   33. This section can be utilized to outline the technology environments, platforms, and support methodology of the organization.
       • Computer/Network environment: For example, Windows, Cisco LAN, SQL Server
       • Planned interface with other systems: For example, Active Directory, HR, Financials
       • Project repository and storage policy: For example, SharePoint client-server or cloud-based
       • Implementation and Support Methodology: For example, Agile, ITIL, ISO 21500
   34. 4.2 Sample Documentation
   35. The following are just a sampling of the type of documents/project artifacts that may be outcomes of the OPM System Implementation Plan:
       • Strategic Plan (as reference and guidance)
       • Project Plan (including implementation, risk and change management, communication, training, documentation, measurement and control plans)
       • Project Status Reports and Milestone Reports
       • Process maps (before and after), models, and design documentation
       • Change request templates and procedures
       • Project Team charter, scope (required), and mission statement (optional)
       • Project budget, costs/benefit analysis, resource and schedule estimate
       • System specifications and system manuals (vendor provided)
       • User guides and system architecture (including systems integration plans if applicable)
       • Release documentation
       • Defect and corrective action reports
       • Project lessons learned and closure report
   36. 4.3 Technical Support Resources
   37. Use this section to outline any additional technical and/or support requirements, resources, schedule, and budget for project technical resources.
5. 5. Resource Management, Deliverables, and Budget Estimation
   38. 5.1 Work Breakdown Structure (WBS) provides a graphical depiction of activity sequences, decomposed to an appropriate level for facilitating estimation
   39. This section describes the estimated schedule for the near term. Best-case/worse-case range of estimates and prior project results can provide essential inputs into the initial project schedule for the project tasks and activities. Upon construction of the WBS by the team to further aid in building the Gantt chart, as well as estimating activity cost and duration planning for task concurrency and project milestones for management, Quality Assurance, tracking, and reporting purposes.
   40. 5.2 Resource Enrollment and Alignment
   41. This section is used to outline the resource matrix, establish the Executive Committee, create enrollment session agendas, and schedule individual enrollment plans. In addition, the resource matrix can be used to plan for the anticipated skills, estimate the number and type of resources, while providing further clarity on task duration estimates and training needs of the project teams and impacted resources (see the Resource Enrollment/Alignment Matrix below, Figure 3.3).
   42. 5.3 Budget and Resource Allocation
   43. This section describes the project resource costs, project budget, and also can allocate portions of the budget to distinct project components, such as hardware, software, training, and other direct costs. Consider inclusion of a cost/benefit ratio as well as an estimated return on investment (ROI) (Figure 3.4).

       *Net present value (PV) represented as

       Table 3.2

       Project Artifacts

       Component	Start Date	Completion Date (Planned)	Responsibility
       Project plan	Q1	Q1	Project Team Manager, Portfolio/Project Manager/PM
       Action log	Q1	Q1	PM
       Design specification	Q1	Q1	Business Analyst (BA)/PM
       Software installation amd database administration	Q2	Q2	Systems Administrator, DBA
       Initial pilot report	Q2	Q2	Project Team
       How to guide	Q2	Q2	Change Management Team
       Implementation plan (production)	Q3	Q3	Project Team Manager, PM
       Program review of lessons learned	Q3	Q3	PMO Manager, Project Team Manager, PM

       Figure 3.2

       

       Sample Portfolio Management org chart.

       Figure 3.3

       

       Resource Enrollment/Alignment Matrix.

       Figure 3.4

       

       Cost-benefit analysis.

       PV = Future Value

       (1 + interest rate)n

       where n = # of years to achieve the baseline (generally 3) or

       FV = PV(1+R)n

6. 6. Supplemental Section
7. Depending on the size and complexity of the project, this section may be used to include any number of supplemental plans and/or links to reference materials used during the execution of the project, such as alternatives analysis, vendor management plans, rollback plans, data backup and storage information, competitive solicitation criteria, install docs, failover plans, and ongoing application maintenance, security, and support requirements.
8. 7. Appendices
9. As indicated in the preceding Supplemental Section, detailed documentation (numerous pages of text) on large-scale deployments, such as requirement specifications and extensive plans, may be best suited for inclusion in a separate appendix at the end of this document.
   44. 7.1 Appendix A
   45. 7.2 Appendix B: Project Plan Revision History (Table 3.3)

References

1. Liu, S. S., and K. C. Shih. 2009. A framework of critical resource chain in project scheduling analysis. Construction Management and Economics 27: 857–869. Online at: http://www.iaarc.org/publications/fulltext/A_Framework_of_Critical_Resource_Chain_in_Project_Scheduling.pdf

2. Project Management Institute. 2009. Practice standard for project risk management. Philadelphia, PA: Project Management Institute.

3. Project Management Institute. 2013. A guide to the project management body of knowledge (PMBOK guide), 5th ed. Philadelphia, PA: Project Management Institute.