Documente Academic
Documente Profesional
Documente Cultură
FOR
REVISION: 1.1
REVISION HISTORY.............................................................................................. I ABOUT THIS DOCUMENT PREPARING THE PROJECT MANAGEMENT PLAN.............II STARTING WITH THE TITLE PAGE........................................................................V 1.0 PROJECT OVERVIEW .....................................................................................1 2.0 PROJECT AUTHORITY AND ORGANIZATIONAL STRUCTURE...............................5 3.0 SCOPE ......................................................................................................... 7 4.0 PROJECT DELIVERABLES AND METHODOLOGY................................................9 5.0 PROJECT WORK........................................................................................... 19 6.0 PROJECT MANAGEMENT AND CONTROLS......................................................22 7. 0 PROJECT CLOSE.........................................................................................37 ATTACHMENTS................................................................................................. 37
REVISION HISTORY
REVISION NUMBER 1.0 2.0 2.1 2.2 DATE July 27th, 2007 COMMENT DoIT Project Management Office Revision
II
3 4
5 6
III
It is more about the temporary organization than the unique product, service or result. It is more about the interested parties, technical teams and the solution building process!
PROJECT MANAGEMENT QUESTIONS 1 2 3 4 5 6 What is the unique product, service or result? What do we need to do to accomplish the goal or goals? How do we know when we are finished? Who is doing what for whom? How do we know how we are doing? How do we handle uncertainty or conflict?
UNIQUE PRODUCT, SERVICE OR RESULT 0 Product what are we trying to accomplish and how will we know when we are finished? 7 Product Development Project Objectives-> Business Requirements -> System Requirements-> Architecture-> Solution Design-> Build-> Pilot-> Deploy 0 8 9 10 11 12 Quality of Product Trace-ability and Quality Assurance-> Test Cases, Test Planes, Pilot and Deployment Success Criteria Deployment of Product Resource Requirements and staffing for new product Deployment Plan and Transition To Operations Operations and Support for product Cost- What is the estimated cost of creating and implementing?
IV
0 0 1 2 3 1 0 1 2 3
For Whom Project Sponsor Project Funding Source End User Beneficiaries of new solution Who Project Team Subject Matter Experts Vendors Operations
HOW ARE WE DOING? 8 Time 9 0 1 10 Calendar of tasks, task targets Work Breakdown Structure What needs to be done Time estimation how much time will be needed? Budget Do we have funding for project and product development, implementation and on-going support? How much money have we spent? Are we spending the right amount of money for specific tasks? Quality and IV&V Are we doing what we have set out to do? Metrics How many changes are we making?
0 1 11 0 12 0
HOW WELL ORGANIZED ARE WE 13 Are we meeting with stake holders and team members?
IV
14 15 16 17
Have we identified possible roadblocks? Do we document disagreements and work towards resolutions? Do we secure formal approval of changes and requirements from stakeholders? Do we keep stake holders informed?
PROJECT MANAGEMENT PLAN 0 Is about how we create and manage a temporary organization to deliver the unique product, service or result! 1 Is not a Microsoft Project file -MS Project is a scheduling aid
THE TITLE
Does the title convey to the reader the essence of the project? Is the title of the project required by any funding considerations?
Understand the project complexity Champion the project and the team Formally manage the project scope Provide guidance for business strategies
VI
Approve plans, schedules and budgets Ensure sustained buy-in Ensure timely availability of resources Review project progress
Both executive sponsor and business owner are listed. While both may sit on the project steering committee, usually the business owner is more involved in the project after the project charter is established. More discussion on the steering committee will be covered under 6.2 Project Governance Plan.
WHAT IS THE ORIGINAL PLAN DATE AND WHY THE REVISION DATE AND REVISION NUMBER?
As the project develops and the sponsors, project manager and team learn about the project, it is expected that the content of the project charter will change. Because the project charter is so critical to the agreements between the sponsors and the project, change management should be followed once the project charter is a signed document.
VI
The current state-future state- need approach The current state with its issues is described The ideal future state is described as if the solution were in place The need provides a description of the gap and tells how the work of the project will resolve the gap between the current and future states
PAGE 1
Imagine that you are in an elevator with the executive sponsor or Cabinet Secretary and can take advantage of the few minutes to pitch the project. You have a limited amount of that persons attention to sell the problem and the solution to the problem.
SOURCE
AMOUNT
ASSOCIATED RESTRICTIONS
APPROVERS
1.3 CONSTRAINTS
Constraints are factors that restrict the project by scope, resource, or schedule. Constraints can include parameters that force the project or work effort to fit a particular timeframe. They lead us into a certain way of doing things. Constraints limit the project management teams options. Contractual provisions will generally be considered constraints. NUMBER DESCRIPTION
1.4 DEPENDENCIES
Literally dependencies are items required for something else to happen. My success in being able to drive for hundreds of miles is to have enough gas in my cars gas tank, which usually means finding an open gas station, having cash or a credit card with which to pay for the gas. The table in this section asks for a reference number, a description and whether the dependency is: Mandatory dependencies are dependencies that are inherent to the work being done. D- Discretionary dependencies are dependencies defined by the project management team. This may also encompass particular approaches because a specific sequence of activities is preferred, but not mandatory in the project life cycle.
PAGE 2
E-External dependencies are dependencies that involve a relationship between project activities and non-project activities such as purchasing/procurement
By way of simplification, having enough gas in my cars gas tank would be Mandatory; a specific gas station might be considered External, as our favorite corner gas station might not be open; Cash or credit card would be Discretionary. Dependencies help the reader and the project manager/team view the playing field realistically. A back-ordered part becomes a dependency for meeting a project schedule. NUMBER DESCRIPTION TYPE M,D,E
1.5 ASSUMPTIONS
Assumptions may contain little or significant amount of risk. We can assume that members of our teams will always show up, and that the project manager will stay through the project, but people get sick, or get better offers. Here is an exercise. List all of the people, factors, and things we take for granted around the project environment that if they were not there would negatively impact the project. We assume vendors will stay in business, and that their key technical staff will remain in place. Assumptions are planning factors that, for planning purposes, will be considered true, real, or certain. Assumptions generally involve a degree of risk. They may be documented here and converted to formal risks. Assumptions define conditions not known but under which the project is planned, budgeted, and managed. They can include anything that supports the scope. Aim to tie risks to assumptions and place risks in risk documentation. NUMBER DESCRIPTION
PAGE 3
Section 6.1 Risk Management calls for an understanding of how the project will be handling risks. Projects By their temporary nature and unique outcomes are risky Project management reduces the impact of the threats by making them explicit and the working on reducing their impacts or by eliminating those Risks are always around. A project is not judged on how many risks are identified, but by its strategy and success at planning through the risks. See 6.1.2 Project Risk Identification for a listing of typical project risks. Description Probability Impact
Risk Name should easy reflect the challenge without detail Description - Describe the risks characteristics and explain why this risk is perceived to have the potential to affect the outcome of the project. Probability and Impact - Probability should be measured as the likelihood of that the risk will occur. Impact should be measured in terms of deviations from the schedule, effort, or costs from the schedule if risks occur. Probability Levels: Certain, Expected, Likely, Possible, Unlikely Impact Levels: Very High, High, Medium, Low, Very Low
Mitigation Strategy - Identify what actions can be taken in order to reduce the probability of the risk, or to reduce its impact on the project. Contingency Plan Identify what actions will be taken when the risk materializes and threatens the scope, budget, or the schedule of the project.
[Risk 1 Name] Description Probability and Impact Mitigation Strategy Contingency Plan
PAGE 4
[Risk 2 Name] Description Probability and Impact Mitigation Strategy Contingency Plan
2.1 STAKEHOLDERS
List all of the major stakeholders in this project, and state why they have a stake. Stakeholders are individuals and organizations that are actively involved in the project, or whose interests may be positively or negatively affected as a result of project execution or project completion. They may also exert influence over the project and its results.
The PMBOK of the Project Management Institute defines project stakeholders: Project stakeholders are individuals and organizations that are actively involved in the project, or whose interests may be affected as a result of project execution or project completion. They also exert influence over the projects objectives and outcomes. This all encompassing definition would have us think about such stakeholders as: Cabinet Secretaries Agency Division directors CIO-IT Leads Project Manager IT operations staff Business process owners System user representatives Key project team members Training staff
The Various stake holders should also have their stake in the project spelled out.
PAGE 5
NAME
STAKE IN PROJECT
ORGANIZATION
TITLE
PAGE 6
2.2.2 DESCRIBE THE ROLE AND MEMBERS OF THE PROJECT STEERING COMMITTEE In many projects the business owners sit as the members of the steering committee. The role of the steering committee is set the tone for the project, manage the project charter authorizing the role of the project manager, manage the scope of the project in terms of cost, schedule and quality of the project, deal with issues escalated to them, and also to accept or deny project team recommendations especially in go-no go decision matters. 2.2.1 ORGANIZATIONAL BOUNDARIES, INTERFACES AND RESPONSIBILITIES Use this section to describe any special considerations regarding contact between the project team, the project manager, and individuals from various organizations involved in the project: The key interface between the organizations is between the Project Manager from the DoIT and the Project Managers from Contracting Vendor and between the Project Manager and the assigned Team Leaders.. The primary methods utilized will be the Status Report/Briefing, adhoc meetings, electronic mail, and phone conversations. Interaction may occur directly between the technical components of all teams. However, overall task direction can only come from the Project Manager. Final decisions will be made at the Steering Committee level.
3.0 SCOPE
3.1 PROJECT OBJECTIVES
As the project progresses it must be able to answer the following question as Yes!: Has the project established the ability to verify that business requirements can be traced through technical design, system building or software coding/ configuration and test phases to verify that the system performs as intended and contains no unnecessary elements?
PAGE 7
Bus. Objective 1 Business objectives are the high level business requirements of the project. The following table comes from a requirement collection template. It suggests the ingredients of a well written business objective. Description <Enter concise description of requirement> Rationale Acceptance/Fi t Criteria <Provide a brief rationale, and or business value for the requirement.> <Provide a target that makes it possible to test if requirement was satisfied>
The typical problems with business objectives include: Lumping more than one objective into a business objective Use of too many loose phrases such as more, better, improve, fix, solve
3.1.2 TECHNICAL OBJECTIVES Technical objectives relate to the technical issues or goals the project is to accomplish. These maybe related to acquisition of hardware, software, consulting, training, application development and other hows of the project. NUMBER DESCRIPTION
Tech. Objective 1 The business requirement table presented in the section above is useful here as well, with one addition, the parent Objective/ requirement which should be one of the Business Objectives presented. Parent <Enter the unique id #(s) for each requirement that this requirement supports Requirement (This field will be empty for high level requirements e.g., business # requirements)> Description <Enter concise description of requirement> Rationale Source Acceptance/Fi t Criteria <Provide a brief rationale, and or business value for the requirement.> <Name of Reqmnt. Provider> Source <filename> Document <Provide a target that makes it possible to test if requirement was satisfied>
PAGE 8
Because technical objectives should be trace-able to specific Business Objective, when there is more than one business objective, it would be advisable to present the technical objectives in a hierarchical manner: The following is an example of such a presentation of technical objectives. NUMBER Bus. Objective 1 Tech. Objective 1 Tech. Objective 2 Bus. Objective 2 Tech. Objective 4 DESCRIPTION Reduce cost of government operations through IT Identity Management and Directory Services Common Business Functions and data interchange and discovery methodology for all agencies to access and use for report creation. Reduce cost of IT operations through an enterprise Model Common IT service architecture and operating environment, including Standards, SLA (Service Level Agreements) approach, governance model and improved funding mechanism
DESCRIPTION
PAGE 9
10
In its efforts to move from the high level business objectives to the desired end product/service the project team will need to deliver specific documents or work products. The State of New Mexico Project Management Methodology distinguishes between the project and the product. Project Deliverables relate to how we conduct the business of the project. Product Deliverables relate to how we define what the end result or product will be, and trace our stakeholder requirements through to product acceptance, and trace our end product features and attributes back to our initial requirements
Here is some background: The following is a description of a Project Management Life Cycle based on the PMI (Project Management Institutes PMBOK.
Key Project Deliverables of each of these five processes are identified as including the following:
PAGE 10
11
Initiating: Project Charter Project Scope Business Requirements Business Case Assumptions Constraints Authorization to proceed with planning Planning: Project Plan Critical success factors Work Break down Structures Project Schedule Controlling: Performance/Status Reports Corrective Action Measurement Metrics Plan Change Requests Product Change Request Risk Management Issues Management Execution: Actual efforts Project Deliverables completion Closing: Deliverable or Product Acceptance Lessons Learned As a companion to the five major project processes, PMI through the PMBOK has instituted nine management focuses that will be followed in this project: Integration Management
PAGE 11
12
The purpose of integration management is to ensure coordination of the different elements of a project to achieve the needs and expectations of project stakeholders. It includes project plan development, project plan execution, and integrated overall change control. Scope Management The purpose of scope management is to ensure the work performed in a project is necessary to the successful completion. It includes initiation, scope planning, scope definition, scope verification, and scope change control. Time Management The purpose of time management is to ensure a project completes in a timely manner. It includes activity definition, activity sequencing, activity duration estimating, schedule development, and schedule control. Cost Management The purpose of cost management is to ensure a project completes within its approved budget. It includes resource planning, cost estimating, cost budgeting, and cost control. Quality Management The purpose of quality management is to ensure the products and services produced by a project satisfy the needs for which the project was undertaken. Quality the satisfaction of project needs is a measure of adherence to stated requirements combined with fitness for use. The Quality Management Knowledge Area includes quality planning, quality assurance, and quality control. Human Resource Management The purpose of human resource management is to ensure effective use of the people involved in a project. It includes organizational planning, staff acquisition, and team development. Communications Management The purpose of communications management is to ensure timely and effective flow of information for a project. It includes communication planning, information distribution, performance reporting, and administrative closure. Risk Management The purpose of risk management is to ensure the identification, analysis, and appropriate response to the risks encountered by a project. It includes risk management planning, risk identification, qualitative risk analysis, quantitative risk analysis, risk response planning, and risk monitoring and control. Procurement Management The purpose of procurement management is to ensure effective acquisition of products and services from sources external to the projects organization. It includes procurement planning, solicitation planning, solicitation, source selection, contract administration, and contract closeout.
PAGE 12
13
4.1.1 PROJECT MANAGEMENT DELIVERABLES Project Deliverables are work products or artifacts that are driven by the project management methodology requirements and standard project management practices regardless of the product requirements of the project. Examples are project, phase, and iteration plans, and project schedules. Project Deliverables must be reviewed and approved by the projects Executive Sponsor prior to their implementation. Description - Deliverable description conveys the features and/or the functions that will be included in the project product. Each deliverable is a subsidiary element of the project product (final deliverable), each with its own separate but interdependent deliverable scope Deliverable Acceptance Criteria - Acceptance Criteria are quantifiable measures of the success of each deliverable (or set of deliverables). Its how the executive sponsor and the project team know when a deliverable is acceptable and can be approved. Acceptance criteria are similar to measures of success except they are for a specific deliverable. The criteria may include functional and technical testing and utility verification at defined points in the process; methodology and criteria should be published. Standards for Content and Format - Standards for Content and Format describe the format that the executive sponsor can expect to receive the deliverable. This section ensures that the deliverable will be usable to meet its objective upon delivery. The tools, techniques, and processes used to develop the deliverable must compliment the executive sponsors environment and enable the executive sponsor to use the deliverable Quality Review - Quality review provides the opportunity for peer and cross-discipline reviews of the deliverable. This process will improve the Quality Control metrics by reducing the testing cycle and the number of exceptions reported by Quality Control and eventually the executive sponsor.
Quality Review -
PAGE 13
14
Standards for Content and Format Quality Review 4.1.2 DELIVERABLE APPROVAL AUTHORITY DESIGNATIONS Complete the following table to identify the deliverables this project is to produce, and to name the person or persons who have authority to approve each deliverable. Each deliverable should be assigned a control number for tracking. The date approved column serves as a log of when each deliverable was approved. DELIVERABLE NUMBER PRJ-DEL-001 DELIVERABLE Project Management Plan (PMP) APPROVERS (WHO CAN APPROVE) DATE APPROVED
4.1.3 DELIVERABLE ACCEPTANCE PROCEDURE Describe the process that this project will use for the formal acceptance of all deliverables. Generally, a Deliverable Acceptance Form is utilized with specific timeframes allowed for review, approval, rework, etc. Issues identified in this Deliverable Acceptance Procedure should follow the Issues Escalation Process that is defined in a later section.
PAGE 14
15
The typical approach is one of the SDLC, solution/software development life cycle. One example is presented here. What is a product life cycle? A collection of generally sequential project phases whose name and number are determined by the control needs of the organization or organizations involved in the project. Project Management Institutes PMBOK Guide 2000, Glossary p. 205 .
The Product Life Cycle includes identifiable and distinct phases, each of which encompasses the critical five project management processes. Each phase has its own initiation, plan, execute and control aspects and each will have its own close process. The close process or gate will include project approval to enter the next phase of the project. Where the DoIT Project Management Office has not yet published product life cycle development templates to use, projects have used documents similar to those mentioned in this approach. The following is a high level description of project document-deliverables per phase Initiation Product development Rationale End Vision and purpose Project Scope Plan Work Breakdown Schedules Project Schedule Business Requirements Initial technical requirements Initial deployment and transition to operations plan Initial Operations and Support Plan Define
PAGE 15
16
Analysis of the current state Technical Requirements Systems Specifications Requirements Initial Training Requirements System Architecture Document System Use Cases where appropriate Test Cases or system acceptance criteria Revised deployment and transition to operations plan Revised Operations and Support Plan Design Systems Design Documents Training Curriculum Revised deployment and transition to operations plan Revised Operations and Support Plan Build Systems Design Documents applied Training Materials ready Revised deployment and transition to operations plan Revised Operations and Support Plan Pilot Acceptance Criteria Pilot Systems Design Documents applied Training Materials ready Revised deployment and transition to operations plan Revised Operations and Support Plan Pilot Run, Evaluated Pilot Acceptance Deploy Systems Design Documents applied Training Materials Used Deployment and transition to operations plan Operations and Support Plan Close
PAGE 16
17
Systems Acceptance by Operations 4.2.1 TECHNICAL STRATEGY Discuss the key technical strategies for achieving success in this project. Among these might be: Build-reuse-buy approach Commercial Off The Shelf COTS- criteria development Hardware-Operating System choices New Mexico Enterprise IT Standards or exceptions or requests for new standards Hosting location with justification Outsourcing with justification Adoption of new technologies
4.2.2 PRODUCT AND PRODUCT DEVELOPMENT DELIVERABLES Product Deliverables are work products or artifacts that are driven by the product management methodology requirements and standard project management practices regardless of the product requirements of the project. Examples are project, phase, and iteration plans, and project schedules. Product Deliverables must be reviewed and approved by the projects Executive Sponsor prior to their implementation. Description - Deliverable description conveys the features and/or the functions that will be included in the project product. Each deliverable is a subsidiary element of the project product (final deliverable), each with its own separate but interdependent deliverable scope Deliverable Acceptance Criteria - Acceptance Criteria are quantifiable measures of the success of each deliverable (or set of deliverables). Its how the executive sponsor and the project team know when a deliverable is acceptable and can be approved. Acceptance criteria are similar to measures of success except they are for a specific deliverable. The criteria may include functional and technical testing and utility verification at defined points in the process; methodology and criteria should be published. Standards for Content and Format - Standards for Content and Format describe the format that the executive sponsor can expect to receive the deliverable. This section ensures that the deliverable will be usable to meet its objective upon delivery. The tools, techniques, and processes used to develop the deliverable must compliment the executive sponsors environment and enable the executive sponsor to use the deliverable Quality Review - Quality review provides the opportunity for peer and cross-discipline reviews of the deliverable. This process will improve the Quality Control metrics by reducing the testing
PAGE 17
18
cycle and the number of exceptions reported by Quality Control and eventually the executive sponsor.
DATE APPROVED
4.2.4 DELIVERABLE ACCEPTANCE PROCEDURE Describe the process that this project will use for the formal acceptance of all deliverables. Generally, a Deliverable Acceptance Form is utilized with specific timeframes allowed for review, approval, rework, etc. Issues identified in this Deliverable Acceptance Procedure should follow the Issues Escalation Process that is defined in a later section.
PAGE 18
19
PAGE 19
20
Or..
Phase / Activity Umbrella Tasks Phase 1 Project Preparation & Planning Phase 2 Phase 3 Phase 4 Project Closing TOTALS Project plan Project Schedule Associated Deliverables Estimated Budget
PAGE 20
21
5.4.1 PROJECT TEAM ORGANIZATIONAL STRUCTURE Insert a graphical Organization Chart here. The Organizational Structure (OS) is a hierarchical configuration defining levels of program management and may identify all project personnel. The OS should be simple and straightforward. Include role names and peoples names. Consider identifying the core project team by shading their respective boxes on the chart. On complex projects, consider using a second OS to identify core project team. The OS can also be used for management reporting. 5.4.2 PROJECT TEAM ROLES AND RESPONSIBILITIES List the team members, their role, responsibility and functional manager. Make sure to include a comprehensive listing including those from the organization managing the project, business members involved to ensure business objectives are met and the vendor members that may have a specific role.
ROLE
RESPONSIBILITY
NAME
FUNCTIONAL AREA
PAGE 21
22
5.5.2 NON-PERSONNEL RESOURCES Use this section to list services or product (HW/SW and such) needed for project Cost Estimated Work Resource Estimate units/hours Availability Source Product/Deliverable
5.6 PROJECT LOGISTICS Logistics describes how the project manager, project team, the business owner/customer and any vendor resources will physically work together. Include anything to do with moving or starting resources. Identify a role to coordinate logistics with the business owner/customer and vendors. Logistics includes factors, issues, notes, etc. relating to operational details (space, materials, access, etc.) at the customer or vendor site. It can also be used to describe the need and use of a forthcoming logistics document. Cross-reference any risk, assumption or exclusion that is related to logistics. Training specifically related to project team members should be included here. 5.6.1 PROJECT TEAM TRAINING Describe training if any needed by project team members. This is not to include training for end users, system administrators or business owners; those should be handled within a training document or part of the transition to operations planning.
Cost Estimate Estimated Hours
Resource
Availability
Skill Set
Work Product/Deliverable
PAGE 22
23
Risk: An uncertain event or condition that, if it occurs, has a positive or negative effect on a projects objectives. Issue: A point or matter in question or dispute, or a point or matter that is not settled and is under discussion or over which there are opposing views or disagreements. Both Risks and Issues can significant impact a projects success, and both should be handled in similar ways. Project Management IS Risk Mitigation. Is about how we create and manage a temporary organization to deliver the unique product, service or result! By providing structure to the temporary organization and the solution development/deployment process we reduce the risk of counterproductive Chaos. By communicating with stakeholders we keep them in the loop, and often involve them in risk mitigation or lessening its impact By acknowledging that there is risk, we can structure ways of avoiding or effectively dealing with specific risk.
6.1.1 RISK MANAGEMENT STRATEGY Provide a detailed explanation on the strategy for how risks are identified, analyzed/ quantified, mitigated, reported, escalated and tracked. Include the use of tools such as project management software, forms, and templates. A separate risk management plan may also be developed if needed for the project and included as an Appendix to this document. If that is the case, a high level summary of this plan needs to be included here with the specific reference. 6.1.2 PROJECT RISK IDENTIFICATION Organizational Project Organization Staff, Skills, Etc Vendors, suppliers Uncertainty, Complexity Requirements, Reliability Resource External Risks Planning Risks Technical Risks
Organizational Risks
Poor Initiation Sponsor Changes
PAGE 23
24
Priorities Change Unrealistic Deadline Funding Lack of internal stakeholder support Delayed Approval/Decisions Lack of Technical or business direction Project Manager Experience or inexperience No organization history No established project templates or processes No organizational understanding of RISK
Resource Risks
Lack of Resources Staff Availability Staff Inexperience Holiday and Vacation Personal or Family Illness Retirement or resignations Overbooking Personalities Ineffective training Contractor or Consultant Team Morale Ineffective Communication
External Risks
Vendor/Supplier
PAGE 24
25
Misunderstood requirements Statement of Work incomplete Too Many External vendors or suppliers Weather Issues Key Staff issues or sickness Dependencies on other projects Purchasing or hiring
Planning Risks
Lack of Planning Lack of Anticipation Poor Estimation Lack of stakeholder involvement Lack of end customer involvement Poor Project Definition Unrealistic expectations Number of implementation sites Training process Government or Regulatory Changes Poor Communications Poorly Run or attended meetings No record keeping
PAGE 25
26
Technical Risks
Incomplete Requirements Scope Creep No or Poor Change Management Process Complex or Overly Complex Designs Technology Readiness Technical Dependencies No Test Environment Cutting Edge Components Inadequate Documentation Vendor Technical Support Code or Patch directly to Production Environment No Pilot
PAGE 26
27
6.1.4 RISK REPORTING AND ESCALATION STRATEGY The DoIT Risk and Issue Log Template uses a calculation based on the following values: Probability Levels: Certain, Expected, Likely, Possible, Unlikely Impact Levels: Very High, High, Medium, Low, Very Low
The following table suggests the values at which the risks should be tracked, reported and escalated: Minimum risk - Acceptable Some risks - Monitor at PM/Team Level High risks - Active monitoring with ongoing Contingency/Mitigation activity Show stoppers - Active participation with steering committee to mitigate This is an example of the calculation that indicates a serious risk that needs to be escalated to the Steering Committee. Number 1 Risk Example Probability Certain Impact High Rating 0.7125
PAGE 27
28
6.1.5 PROJECT RISK TRACKING APPROACH In the DoIT Risk and Issue Template the risk log provides a risk log that not only calculates the risk level, but also provides space for inputting the contingency and mitigation plan summary highlights. Number 1 Risk Example Probability Certain Impact High Rating 0.7125 Contingency Mitigation Plan Plan
6.1.6 ISSUE MANAGEMENT For either type of issue, projects should consider using the DoIT Risk and Issue Log template as is presented below: Issue Log:
Issue No. 1 Issue Example Person Responsible Project Manager Date Opened (From Issue Log) 03/15/07 Date Opened Month/Day/year 03/15/07
Issue Form
Issue No. (From Issue Log) 1 Level (High, Medium, Low) Status (From issue Log) Open
Date Closed
Originator
Consequence(s) If not resolved this issue could delay the project by 30 days, resulting in a fine for non-compliance
Resolution
Hiring a contractor could resolve this delay at a cost less than the fine for non-compliance
PAGE 28
29
PAGE 29
30
DATE: PROJECT #:
DATE: DATE:
PAGE 30
31
IMPACT:
Technical
Schedule
Cost
Other
ACTION PLAN:
MARK ONE:
THIS CHANGE: THIS CHANGE IS:
Is Accepted Is NOT Denied Within Scope. On Hold Delayed
PAGE 31
32
6.5.1 COMMUNICATION MATRIX 6.5.2 STATUS MEETINGS 6.5.3 PROJECT STATUS REPORTS
Milestone Dates Component Status Requirement Status Test Case Status Critical Paths Tested Problem Report Status Reviews Completed Change Request Status
Build Content Component Build Content Function Effort Staff Experience Staff Turnover Earned Value Cost Resource Availability Dates Resource Utilization Lines of Code Components Database Size
Financial Performance Availability Growth and Stability Product Size and Stability
PAGE 32
33
Requirements Function Points Change Request Workload Problem Reports Defect Density Cyclomatic Complexity Rework Size Rework Effort Capability Maturity Model Level Product Size/Effort Ratio Functional Size/Effort Ratio
Product Quality
Defects
1 2 3
Project phase is completed by the established finish date. Project is completed within budget. Quarterly project reviews show contractors deliver requirements specified in the contract by due dates or pay penalties.
Project Schedule Project Status Project Charter Project Status Vendor Contract Final Customer Acceptance
PAGE 33
34
No.
Quality Standard
4 5
Project issues are resolved and documented within 10 calendar days of identification or extensions are justified. Project will be completed based on the original project scope and approved scope changes.
6.7.3 AGENCY/CUSTOMER SATISFACTION The project manager should assess the on-going sense of the customer agency about how they feel the project is going, and how team members are acting on the project. This feedback would be helpful to the success of the project and the professional growth of the project team members. Examples: Areas of feedback Agency awareness Quality of communications Manages project tasks Productive Meetings . An example used by some State of New Mexico agencies: When How Often
SSTANDARDS
Not Applicable
Strongly Disagree
Disagree
Somewhat Agree
Agree
Strongly Agree
PAGE 34
35
The level of business or agency knowledge of [projects name] meets your expectations. [Projects name] performs in a professional and cooperative manner. The level of communications by [projects name], both written and oral, meet your expectations. [Projects name] project team works well with you and your staff. [Projects name] project management team is accessible when you need them. [Projects name] provides adequate information and training resulting in effective knowledge transfer. [Projects name] completes project tasks within the agreed upon schedule. The level of technical or business expertise of [projects name] meets your expectations. You are receiving full value from the [projects name] project management team. The overall service provided by [projects name] is fully meeting your expectations.
6.7.4 PRODUCT DELIVERABLE ACCEPTANCE PROCESS How the client takes procession of the product. Delivery of media; manuals; contracts; licenses; services agreements; configuration settings; status of patches to COTS products; in-house or vendor developed code; test cases, routines, and scripts; and other items required to operate the product.
PAGE 35
36
Deliverable
PAGE 36
37
7. 0 PROJECT CLOSE
Project Close will always consist of administrative project activities and possibly contractual project activities and an external vendor is employed. Completing both sets of activities is a mandatory step in the project life cycle. Administrative activities complete the internal needs for the Agency/Unit that is responsible for managing the project, such as lessons learned, recording the last hours against the project, and providing transition for the staff to other assignments. Contractual activities meet the contractual needs, such as executing a procurement audit and formal acceptance of the project work products. 7.1 ADMINISTRATIVE CLOSE Administrative Close occurs at both the end of phase and end of project. This closure consists of verification that objectives and deliverables were met. Acceptance is formalized and phase activities are administratively closed out. Administrative closure occurs on a by-phase basis in accordance with the WBS and should not be delayed to project end. At that point, the burden of closing is too great and audits inaccurate. The specific project close activities for a given project are contingent on the projects complexity and size. Project managers should work with the projects project management consultant to tailor Project Close procedures to compliment the projects objectives 7.2 CONTRACT CLOSE Contract close is similar to administrative close in that it involves product and process verification for contract close. Projects that have been certified need to complete the required DoIT project closure certification processes.
ATTACHMENTS
Attachments are included for additional information, but are not formally considered part of the Project Plan for approvals and change management purposes. Examples Acronyms, abbreviations and definitions Technical glossary of IT terms Project Work breakdown schedule Project timeline
Project Management Institute. Project Management Body of Knowledge Program Management Office
38
PMP WBS
DEFINITIONS
Acceptance Criteria The criteria that a system or component must satisfy in order to be accepted by a user, customer, or other authorized entity. [IEEE-STD-610] Acceptance Testing Formal testing conducted to determine whether or not a system satisfies its acceptance criteria and to enable the customer to determine whether or not to accept the system. [IEE-STD-610] Assumptions Planning factors that, for planning purposes, will be considered true, real, or certain. Assumptions generally involve a degree of risk. They may be documented here, or converted to formal risks. Baseline A specification or product that has been formally reviewed and agreed upon that thereafter serves as the basis for further development, and that can be changed only through formal change control procedures. [IEEE-STD-610] Commitment A pact that is freely assumed, visible, and expected to be kept by all parties. Configuration Management (CM) A discipline applying technical and administrative direction and surveillance to identify and document the functional and physical characteristics of a configuration item, control changes to those characteristics, record and report change processing and implementation status, and verify compliance with specified requirements. [IEEE-STD-610] Configuration Management Library System The tools and procedures to access the contents of the software baseline library. Constraints Factors that will (or do) limit the project management teams options. Contract provisions will generally be considered constraints. Contingency Planning The development of a management plan that identifies alternative strategies to be used to ensure project success if specified risk events occur. Crashing Taking action to decrease the total duration after analyzing a number of alternatives to determine how to get the maximum duration compression for the least cost.
PAGE 38
39
Critical Path The series of activities that determines the duration of the project. The critical path usually defined as those activities with float less than or equal to specified value often zero. It is the longest path through the project. Dependencies, Discretionary Dependencies defined by the project management team. They should be used with care and usually revolve around current Best Practices in a particular application area. They are sometimes referred to as soft logic, preferred logic, or preferential logic. This may also encompass particular approaches because a specific sequence of activities is preferred, but not mandatory in the project life cycle. Dependencies, Mandatory Dependencies that are inherent to the work being done. In some cases, they are referred to as hard logic. Dependency Item A product, action, piece of information, etc., that must be provided by one individual or group to a second individual or group so they can perform a planned task. Deliverable Any measurable, tangible, verifiable outcome, result, or item that must be produced to complete a project or part of a project that is subject to approval by the project sponsor or customer. Duration The number of work periods (not including holidays or other nonworking periods) required to complete an activity or other project element. Duration Compression Shortening the project schedule without reducing the project scope. Often increases the project cost. End User The individual or group who will use the system for its intended operational use when it is deployed in its environment. Effort The number of labor units required to complete an activity or other project element. Usually expressed as staff hours, staff days, or staff weeks. Fast Tracking Compressing the project schedule by overlapping activities that would normally be done in sequence, such as design and construction. Float The amount of time that an activity may be delayed from its early start without delaying the project finished date.
PAGE 39
40
Formal Review A formal meeting at which a product is presented to the end user, customer, or other interested parties for comment and approval. It can also be a review of the management and technical activities and of the progress of the project. Integrated Project Plan A plan created by the project manager reflecting all approved projects and sub-projects. Lessons Learned The learning gained from the process of performing the project. Lessons learned may be identified at any point during the execution of the project. Method A reasonably complete set of rules and criteria that establish a precise and repeatable way of performing a task and arriving at a desired result. Methodology A collection of methods, procedures, and standards that defines an integrated synthesis of engineering approaches to the development of a product. Milestone A scheduled event for which some individual is accountable and that is used to measure progress. Non-technical Requirements Agreements, conditions, and/or contractual terms that affect and determine the management activities of an architectural and software project. Performance Reporting Collecting and disseminating performance information. This includes status reporting measurement, and forecasting. Procurement Planning Determining what to procure and when. Product Scope The features and functions that characterize a product or service. Project Leader (Technical) The leader of a technical team for a specific task, who has technical responsibility and provides technical direction to the staff working on the task. Project Management The application of knowledge, skills, tools, and techniques to project activities to meet the project requirements. Project Management is also responsible for the oversight of the development and delivery of the architecture and software project. Program
PAGE 40
41
A group of related projects managed in a coordinated way. Programs include an element of ongoing work. Program Management Office An organizational entity responsible for management and oversight of the organizations projects. As a specific reference in this document, the Office of the Chief Information Officer. Project Manager The role with total business responsibility for an entire project. The individual who directs, controls, administers, and regulates a project. The project manager is the individual ultimately responsible to the customer. Project Charter A document issued by senior management that formally authorizes the existence of a project. It provides the project manager with the authority to apply organizational resources to project activities. Project Management 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, facilitate communication among stakeholders, and documents approved scope, cost, and schedule baselines. The Project Management Plan (PMP) is a project plan. Project Schedule A tool used to indicate the planned dates, dependencies, and assigned resources for performing activities and for meeting milestones. Software products such as ABTs Workbench and Microsoft Project are tools used to develop project schedules. Project Scope The work that must be done to deliver a product with the specified features and functions. Project Sponsor The individual that provides the primary sponsorship for an approved project. This individual will play a key role in securing funding, negotiating for resources, facilitating resolution of critical organizational issues, and approving key project deliverables. Quality The degree to which a system, component, or process meets specified requirements. The degree to which a system, component, or process meets customer or user needs or expectations. [IEEE-STD-610] Quality Management The process of monitoring specific project results to determine id they comply with relevant standards and identifying ways to eliminate causes of product non-compliance. Risk Possibility of suffering loss.
PAGE 41
42
Risk Management An approach to problem analysis, which weighs risk in a situation by using risk probabilities to give a more accurate understanding of, the risks involved. Risk Management includes risk identification, analysis, prioritization, and control. Risk Management Plan The collection of plans that describes the Risk Management activities to be performed on a project. Risk Management Risk mitigation seeks to reduce the probability and/ or impact of a risk to below an acceptable threshold. Scope Change Any change to the project scope. A scope change almost always requires an adjustment to the project cost or schedule. Software Life Cycle The period of time that begins when a software product is conceived and ends when the software is no longer available for use. The Software Life Cycle typically includes a concept phase, requirements phase, design phase, implementation phase, test phase, installation, and checkout phase, operation and maintenance phase, and, sometimes, retirement phase. Stakeholder Individuals and organizations that are actively involved in the project, or whose interests may be positively or negatively affected as a result of project execution or project completion. They may also exert influence over the project and its results. Standard Mandatory requirements employed and enforced to prescribe a disciplined uniform approach to software development Statement of Work A description of all the work required completing a project, which is provided by the customer. System Requirements A condition or capability that must be met or possessed by a system component to satisfy a condition or capability needed by a user to solve a problem. [IEEE-STD-610] Subproject A smaller portion of the overall project. Task A sequence of instructions treated as a basic unit of work. [IEEE-STD-610] A well-defined unit of work in the software process that provides management with a visible checkpoint into the status of the project. Tasks have readiness criteria (preconditions) and completion criteria (post conditions). (see activity for contrast.)
PAGE 42
43
Team A collection of people, often drawn from diverse but related groups, assigned to perform a welldefined function for an organization or a project. Team members may be part-time participants of the team and have other primary responsibilities. Technical Requirements Those requirements that describe what the software must do and its operational constraints. Examples of technical requirements include functional, performance, interface, and quality requirements. Traceability The degree to which a relationship can be established between two or more products of the development process, especially products having a predecessor-successor or master-subordinate relationship to one another. [IEEE-STD-610] Work Breakdown Structure A deliverable-oriented grouping of project elements that organizes and defines the total work scope of the project. Each descending level represents an increasingly detailed definition of the project work.
PAGE 43