Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Project Management Plan Overview Date Contents The Project Management Framework – Review Project Plan Project Charter Business Case Development Requirements Project Plan Initial Schedule Template Change Control Project Tracking Performance Reporting Estimating Risk Management Quality Management Communications PMO Integration Organization Roles and Responsibilities Rules of Engagement -2- Project Management Framework - Review Project Management Processes Project Objectives Project Phases Plan Time Concept Schedule Cost Definition Control Performance Design Development Deployment Post-completion Project management processes are the things Project Managers do to control project objectives in each project phase. -3- Project Plan Terms Project Plan A formal, approved document used to guide both project execution and project control. The primary uses of the project plan are to document planning assumptions and decisions, to facilitate communication among stakeholders, and to document approved scope, cost, and schedule baselines. A project plan may be summarized or detailed. Baseline The original plan (for a project, a work package, or an activity), plus or minus approved changes. Usually used with a modifier (e.g., cost baseline, schedule baseline, performance measurement baseline). Four parts to a Project Plan: Refined descriptions of goals, objectives, performance criteria, and technical impacts (see Project Charter template tab and page) Completed requirements document (see Requirements sample table of contents and checklist tab and page) Refined Business Case (see Business Case template tab and page) Refined Schedule (see Initial Schedule template tab and page) -4- Project Charter Defined Project Charter A document which defines the project in three parts: (1) A clear and thorough written description of the project scope that includes goals, objectives, performance criteria, and technology impacts; (2) A business case that establishes baseline metrics against which project results can be measured (includes a quantitative cost/benefit analysis as well as qualitative baselines); and (3) A written statement by senior management that provides the project manager with the authority to apply organizational resources to project activities. -5- Concept Phase = Project Charter Development 1. Project Scope Goals and objectives Performance criteria Technology impact If a feasibility study, includes marketing inputs 2. Business Case Establishment of quantified baselines through cost/benefit analysis Establishment of qualitative baselines If a feasibility study, includes competitive analysis 3. Authorization Presentation of case Authorization decision made and obtained Communication of decision to organization Major Outcome: APPROVAL -6- How to Develop the Business Case Complete first draft of the project business case template Complete first draft of the project financial model template Review assumptions in first draft of both templates with Financial Planning and adjust as necessary Review for process considerations (whether requisite fields are filled out correctly) Review for content (consult with Financial Planning on rationales and numbers) Review adjusted draft with Project Sponsor Iterate between Financial Planning and Sponsor until satisfied Finalize project business case and financial model templates and move to Authorization steps -7- Definition Phase = Requirements and Outcomes Outcome defines the “what” which is to be done Development of a comprehensive single requirements document Includes detailed business requirements of business users Includes detailed technical requirements of IT The requirements documented should be elaborated directly from the descriptions of the goals, objectives, performance criteria, and scope developed in the Concept Phase. If this proves difficult, it’s a good indication that the Concept Phase descriptions need to be revisited. This phase calls for very close collaboration between business and IT, requiring many iterative loops between business and IT. This phase also: Specifies technical architecture Specifies QA procedures Sets up control system (WBS, time estimates and skill sets, initial schedules) Establishes project organization Major Outcome: REQUIREMENTS -8- Requirements - SAMPLE TABLE OF CONTENTS -9- Requirements - CHECKLIST - 10 - Project Schedule Terms Work Breakdown Structure (WBS) The WBS is a deliverable-oriented grouping of project elements which organizes and defines the total scope of the project. Each descending level represents an increasingly detailed definition of a project component. Project components may be products or services. Up to 20 levels can be used. At Company, we will use only these four: Phase > Deliverable > Activity > Task A WBS does not show the sequencing of the work to be performed. Such sequencing is determined when a schedule is developed. A WBS should be developed before scheduling and resource allocation are done. - 11 - Deliverables Framework Phases Concept Project charter Project scope Business case model Authorization Business/ Application Project charter Current technology assessment Technical Management Definition Definition work plan Consult IA and Compliance Risk assessment Design Requirements document High level use case model Preliminary object model Bus model Process model Detailed use case model Object model Data Model System test plan Bus proc model Development Architecture guidelines and principles Architecture definition Technology blueprint Application frameworks Development environment Release plan Design and development work plan Risk assessment - 12 - Risk assessment Tested system Sales materials Hiring Plan Training plan Training material Policies and procedures Coded and integrated software Test environments Release environment Installation and Admin. Guide Defect analysis report Deployment work plan Risk assessment User sign-off by Project Acceptor Deployment Trained users Implemented system PostCompletion Post project report Change Control Terms Change Control Decision Maker The Project Acceptor is accountable for approving or rejecting changes requested to the project baselines. There will be no need for a formal Change Control Board at Company. Change Control Form A formal document used to request a change in scope of time, cost, and/or performance. Any member of the project team, including the Sponsor, can initiate a change request. The Project Managers (business and IT) must concur with the requested change before it is formally logged. Once approved by the PMs, the change is recorded on the Change Control Log. The Project Acceptor must approve the change before it can take effect. If so approved, changes are recorded as additions in scope to the Project Plan and baselines. Change Control Log Maintained by the IT Project Manager (or IT Project Director if there is one) to log and document additions in scope to the Project Plan and baselines. - 13 - Authorization and Change Control Through The Project Phases Project Charter Phased Authorization (As Required) Requirements Charter Authorization Project Plan > Initial Schedule > Refined Bus Case > Refined Scope > Requirements Specifications DEV SYS TEST Project Authorization UAT Concept Definition Design - 14 - Development Deployment Post-Completion Change Control - PROCEDURE - 15 - Change Control Log - TEMPLATE and EXAMPLE - 16 - Change Control - TEMPLATE and EXAMPLE - 17 - Tracking Status Reports Status Reporting roll-ups - 18 - Project Tracking: Why Track To understand progress and determine if adjustments are necessary To surface issues and support fact-based decision making To measure overall effectiveness against the projects goals for scope and quality To determine the effectiveness of Risk Mitigation plans To increase knowledge of actual experience to be used as input for estimating future (similar) projects Predicting the future is easy. It’s trying to figure out what’s going on now that’s hard. - Fritz R. S. Dressler - 19 - Project Tracking: What to Track Status Scope Schedule Cost Performance Risk Mitigation Effectiveness Anything that is to be tracked requires a baseline from which to do comparison. Effective tracking cannot be done prior to a baseline being established - 20 - Project Tracking: How to Track Status Scope Tasks scheduled for completion and completed Tasks scheduled for completion and not completed Completed tasks not scheduled Issues by Project size with Change Control Logs, Documents, and Metrics Schedule by Milestones - actual versus plan by capacity analysis - 21 - Project Tracking: How to Track (Continued) Cost Performance by Effort - actual versus plan by $ expenditures - actual versus plan by Software defect metrics by Financial metrics (e.g., ROI, IRR, NPV) Risk Mitigation Effectiveness by Risk Event Status over time (individual and aggregated) by Contingency utilization - 22 - Project Tracking: Frequency Tracking Component Status Weekly Monthly As Needed Scope: Size Scope: Change Control Schedule: Milestones Schedule: Capacity Cost Performance: S/ W Defects Performance: Financial Risk Mitigation - 23 - Project Tracking: Summary Effective project tracking is essential to achieving project objectives Baselines and success measures for all components being tracked must be known, understood, and agreed to at project start by all key stakeholders - 24 - Weekly Status Report PROCEDURE, TEMPLATE, & EXAMPLE - 25 - Monthly Status Report PROCEDURE, TEMPLATE, and RISK EXAMPLE - 26 - Weekly Issues Status Review Status Reporting (weekly and monthly) covers the reasons for not meeting plan dates and calls out the issues which have caused project tasks to be late However, issues are not worked for resolution in status review meetings Issues are managed and resolved through a separate Issues Status Report which becomes the basis for a weekly Issues Status Review Meeting - 27 - Weekly Issues Status Review PROCEDURE, TEMPLATE, & EXAMPLE - 28 - Estimating Techniques Preliminary Estimating Based on External Count Based on Coding Estimates Based on Object-oriented Analysis, Design, and Development Contingency Estimating - 29 - Preliminary Estimating: Externals Estimating models based on # Screens (and dialogues) Reports (and notices) External System Interfaces Total counts are extended by an average number of days per external based on historical information (and allocated based on historical percentages) - 30 - Preliminary Estimating: Coding Estimating models based on # and complexity ranking modules Complexity provides a range of effort Small = 1 - 3 days Medium = 3 - 5 days Complex = 8 - 10 days Total “code and unit test” is calculated by multiplying Remaining estimates are allocated in relation to the overall percentage of “code and unit test” based on historical information - 31 - Preliminary Estimating: OO Estimating models based on #, complexity ranking, # of iterations, and iteration multiplier for: Use Cases Use Interfaces Dataviews Domain Objects Object Model-to-Data View interactions User Interface-to-Data Model interaction - 32 - Contingency Estimating Based on a high, medium, low assessment of key factors: Confidence regarding unknowns Team experience with project technology Team experience with business (e.g., PDA knew nothing about the flood business before they got involved) Team experience with project methodology Team experience working together - 33 - Estimating - PROCESS and TEMPLATE - 34 - Estimating - USE CASE GUIDELINES - 35 - Risk Management - Basic Terms Project Risk Management A subset of project management that includes the processes concerned with identifying, analyzing, and responding to project risk. It consists of risk identification, risk quantification, risk response development, and risk response control. Risk Identification Determining which risk events (discrete occurrences that may affect the project for better or worse) are likely to affect the project. Risk Quantification Evaluating the probability of risk event occurrence and effect (impact). We often call this “Risk Assessment”. Risk Response Development Defining enhancement steps for opportunities and mitigation steps for threats. We often call this “Risk Mitigation”. Risk Response Control Responding to changes in risk over the course of the project. - 36 - Project Risk Management Project risk is the cumulative effect of the chances of uncertainty adversely affecting project objectives. - 37 - Risk Management: Definitions Risk Event Precisely what might happen to the detriment of the project Risk Probability How likely is the event to occur Amount at Stake The severity of the consequences if the event occurs Risk Event Status Equals “Risk Probability” times “Amount at Stake” Risk Event, Risk Probability, and Amount at Stake are the three risk factors used to characterize all risks. - 38 - Risk Management: Risk Identification Three types of Risk Knowns, Known-unknowns, and Unknown-unknowns Two kinds of Risk Events Discrete and Continuous Five “source” categories External Unpredictable, External Predictable, Internal Non-technical, Technical, Legal Eight methods to identify Brainstorming, Sensitivity Analysis, Probability Analysis, Delphi Method, Monte Carlo, Decision Tree Analysis, Utility Theory, Decision Theory - 39 - Risk Assessment Five step process 1. Select the risk events to be examined. High 2. Assess the probability and timeframe associated with the event(s). High Risk 3. Assess the consequences and severity of the events. 4. Develop mitigation plans to reduce the probability and/or the impact of the event(s). Probability Low Risk 5. Accumulate the assessment results into a “Conclusions and Recommendations” document. Low - 40 - Severity High Risk Management: Risk Response Response options: Ignore Recognize but take no action Avoid (by taking appropriate steps) Reduce (by taking an alternative approach) Share (by joint venture) Transfer (by contract or insurance) Retain and absorb (by contingency allowances) Three mitigation components Standards Insurance Planning Alternatives - 41 - Risk Management: Documentation Project Risk Profiling Project Risk Database Historical Risk Database Structured post-project reviews are a key best practice to ensure historical risk information is captured and available as input to future projects. - 42 - Risk Management: Summary Risk Management is an essential component of Project Management that is required for all projects A standard Project Risk Management methodology will provide consistency in identifying, assessing, mitigating, and reporting risk events across all projects and programs Corporate and individual Project Risk Management skills and methods will evolve and improve over time Project Risk Management is an on-going process through all phases of the project’s life cycle - 43 - Risk Management - PROCESS and TEMPLATES - 44 - Quality Management - Basic Terms Project Quality Management 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, quality assurance, and quality control. Quality Planning Identifying which quality standards are relevant to the project and determining how to satisfy them. Quality Assurance (QA - planning and taking proactive measures) (1) The process of evaluating overall project performance on a regular basis to provide confidence that the project will satisfy the relevant quality standards. (2) The organizational unit that is assigned responsibility for quality assurance. Quality Control (QC - measuring) (1) The process of monitoring specific project results to determine if they comply with relevant quality standards and identifying ways to eliminate causes of unsatisfactory performance. (2) The organizational unit that is assigned responsibility for quality control. - 45 - Quality Management - PROCESS and TEMPLATES - 46 - Communications Via Weekly and Monthly Status Reports to team and to PMO audiences Coordinate with Communications Department for routine periodic updating to organization to keep project in the public eye - 47 - Enterprise Program Management Office Vision Statement “We empower the people of Company to identify and create new ways of conducting business. To fuel growth we encourage new, innovative uses of business and information technologies. To manage this growth, we are deploying throughout Company standard program and project management processes. These processes enable us to manage risk, determine cost and benefit, and assure the strategic alignment of all initiatives with the corporate goals and objectives.” - 48 - Governance and Structure Inter-Organizational Alignment of Strategic Business Initiatives & IT Projects Operating Committee Enterprise Program Management Office Business Units Information Technology Strategic Business Initiatives Sponsor/Owner IT Program Management Office IT Project 1 eBusiness Integrated Product Integrated Benefits IT Project 2 IT Project 3 IT Project N Bank & Agent Consolidation - 49 - Governance and Structure IT Internal Coordination Crosses all IT Organizational Boundaries Operating Committee Enterprise Program Management Office Information Technology Business Units IT Program Management Office Strategic Business Initiatives Sponsor/Owner Operations Infrastructure Application Development IT Project 1 eBusiness Integrated Product Integrated Benefits IT Project 2 IT Project 3 IT Project N Bank & Agent Consolidation - 50 - Special Projects Governance and Structure Business Unit Provides Justification and Alignment Operating Committee Enterprise Program Management Office Information Technology Business Units Strategic Business Initiatives Sponsor/Owner Business Business Case IT Program Management Office Operations Infrastructure Results Strategic Alignment Application Development IT Project 1 eBusiness Integrated Product IT Project 2 IT Project 3 Integrated Benefits IT Project N Bank & Agent Consolidation - 51 - Special Projects Governance and Structure Operating Committee and the PMO Operating Committee •Make Decisions •Provide Direction •Ensure Alignment •Allocate Resources •Ensure Success Enterprise Program Management Office •Report Results Information Technology Business Units IT Program Management Office Strategic Business Initiatives Sponsor/Owner Business Business Case Operations Infrastructure Results Strategic Alignment Application Development IT Project 1 eBusiness Integrated Product IT Project 2 IT Project 3 Integrated Benefits IT Project N Bank & Agent Consolidation - 52 - Special Projects Roles and Responsibilities Program Management Office (PMO) General • Align strategic business initiatives with overall corporate vision • Ensure successful implementation of strategic business initiatives • Provide direction, guidance, and timely decision making • Review recommendations and resolve conflicts among competing and conflicting initiatives and resources • Provide recommendations to adapt and refocus the business in response to changing marketplace and business changes • Schedule meetings at regular intervals • Conduct meetings based on published agendas • Communicate regularly with stakeholders on progress and success of strategic business initiatives • Drive decision-making process through fact-based analysis and commitment to measurable performance criteria - 53 - Roles and Responsibilities (Continued) Program Management Office (PMO) Specific • Employ consistently project management methodologies, processes and tools • Define business case development, planning, tracking, risk assessment and reporting standards and tools • Provide mentoring and training for Project Managers • Assist with Business Case development, Risk Assessments, Estimating and Planning, and Project Reviews • • • Prepare Enterprise Risk Profile Reports Establish and maintain Project Management metrics database A full time PMO administrator is recommended - 54 - Roles and Responsibilities IT Program Management Office (ITPMO) General • Ensure IT portfolio (infrastructure, platforms, applications, tools and human capital) resources are aligned to support strategic business priorities • Employ consistently project management methodologies, processes and tools • Provide recommendations to adapt and refocus the IT portfolio in response to changing IT and business changes • Provide direction, guidance, and timely decision-making on IT solutions • Review recommendations and resolve conflicts among competing and conflicting initiatives and resources • Communicate regularly with stakeholders on progress and success of IT solutions • Drive decision-making process through fact-based analysis and commitment to measurable performance criteria - 55 - Roles and Responsibilities (Continued) IT Project Management Office (ITPMO) Specific • The CIO will chair the ITPMO • Employ consistently project management methodologies, processes and tools • Deploy standard life cycle methodology and planning, tracking, risk assessment and reporting standards and tools • Provide mentoring and training for IT Project Managers • Assist with Business Case development, Risk Assessments, Estimating and Planning, and Project Reviews • Prepare IT Risk Profile Reports • Establish and maintain IT Project Management metrics database - 56 - Rules of Engagement (PMO and ITPMO) Collaboratively Achieving Success • Active participation of all team members • Encourage debate and discussion Challenge all assumptions Acknowledge expertise Facts drive decisions, not emotions Consensus is the goal; however, decision making must be timely • • • • • Decisions will not be second-guessed, but may be revised by the entire PMO based on compelling business or information technology changes • Prepare, distribute, and review agenda and all material prior to meetings • Stick to the agenda • Timebox all discussions and stay within the time contact • Post-meeting distribution of the “Final Document” will be in lieu of minutes and will be the responsibility of the PMO administrator - 57 - Operating and IT Steering Committee and PMO Current, Transition and Future Operating Environment Current • Operating Committee membership provides core of Interim Program Management Team (IPMT) • Additional IPMT membership represents both business and IT • IPMT membership should remain the same through August, 2000 Transition and Future • Formal PMO should be composed of second level business and IT managers • Membership should rotate every 18 to 24 months • Positions are part-time, with meetings scheduled bi-monthly for first six months, then monthly thereafter • Additional (full or part-time) staff required includes a financial analyst (recommended) Future ITPMO • IT Steering Committee will be eliminated and replaced by the PMO • Within IT a newly formed group, IT Program Management Office (ITPMO) will manage IT internal program management activities and will be chaired by the CIO • ITPMO will report to the PMO and thus is subordinate to PMO decisions, vision, and direction • Membership should be composed of mixture of senior and second level IT managers • Membership should rotate every 18 to 24 months • Positions are part-time with meetings scheduled bi-monthly - 58 -