Project Charter Template 2

Enterprise Project Management Methodology Templates & Examples Project Charter Template Project Background and Description [Describe how this project came to be, who is involved and what the purpose is] Business Need/Opportunity [Also referred to as “problem statement”] [The context of a problem is described in the business need, business opportunity or problem statement. This is an opportunity to explain the nature of the dilemma that the team will solve. The problem statement usually takes a paragraph form in which you are “telling the story” of why the team is working on this problem. The task of the team in the problem statement is to represent the nature, setting, and context of the project in a concise manner. In other words, it is the “What is” and is independent of any efforts or intentions on the part of your team. It explains what the broader need is, what the consequence of the problem not being solved is, and/or what the consequence of the problem being solved would be. You can present a number of ideas that are related to your specific problem. These ideas can include such things as:  causes of the problem,  factors that may aggravate or mitigate the problem,  an explanation of how the problem effects the your agency,  how the problem impacts your clients  the role of the agency in the community  the stake or importance that the agency in an acceptable solution to the problem,  the urgency of a solution High Level Goals and Objectives Goal: [The project goal is a direction-setter and ideal future end related toward which planning and implementation activities are directed. A goal is generally not quantifiable, time-dependent or suggestive of specific actions for its achievement. Number goals to eventually associate with affected objectives, issues, risks, changes and requirements] 1. [insert goal] 2. [insert goal] 3. [insert goal] Objective: [Objectives are specific ends, conditions or states that are intermediate steps toward attaining a goal. They should be achievable and, when possible, measurable and time-specific. An objective may only pertain to one particular aspect of a goal or it may be one of several successive steps toward goal achievement. Consequently, there may be more than one objective for each goal. Number objectives to eventually associate with affected goals, issues, risks, changes and requirements] 1. [insert objective] 2. [insert objective] 3. [insert objective] Business Driver [Driving forces that move the project forward] Critical Success Factor [Insert what must be accomplished by this project in order to satisfy the business driver.] [Insert what business drivers are the impetus for this project (Business Reason, Federal Mandate, etc]. Benefits [Describe what benefits will be realized as a result of this project.] Guiding Principles [Describe what guiding principles must be adhered to during this project (Compliance with ITBs, knowledge transfer to IT staff, etc). Assumptions [Describe any assumptions that the project team is currently operating under; specifically those assumptions that apply to the project or were used to develop the project charter] Constraints [Describe any parameters that must be met in order for this project to succeed; or any parameters which may become obstacles.] Approval and Authority to Proceed We approve the project component as described above, and authorize the team to proceed. Name [type or sign name] Title Date Prepared By: 1 Project Charter—SERTS Example Project Background and Description Background: Currently we have no electronic tracking capabilities and maintain a very limited number of paper logs. This presents a problem when we are directed to provide historical information to appellant organizations such as the Pennsylvania Human Relations Commission (PHRC), State Civil Service Commission (SCSC) or the Equal Employment Opportunity Commission (EEOC). The historical information requested can include: grievances, employee discipline, PHRC and EEOC Complaints, or SCSC Appeals. Therefore, we are forced to ferret through our files or rely on memory to supply the required information. In this age of an ever increasingly litigious work force, this approach leaves the Department very vulnerable for potential liability. This project will develop a system similar to the Personnel Information Tracking System (PITS) application that was recently developed for the Department of Military and Veterans Affairs. SERT will be a relational data base that tracks the following: Employee Discipline, Employee Criminal Conduct, ADA requests, Grievances, PHRC/EEOC Complaints, Civil Service Appeals. Data maintained in the SERT will be used to perform detailed statistical analyses, which are necessary when defending claims of discrimination in the application of our disciplinary program. Additionally, the SERT will allow managers to research the level of discipline that is customary for a specific infraction. The SERT will be available to each District Office, as well as Headquarters. Security will allow each District to view its data only and permit that District‟s administrator to select which segments of the SERT can be viewed by individual employees within that District. Each District will be able to run preestablished and ad hoc reports on its data. Headquarters will be able to run departmentwide reports. Solution: Initiate a project to transform the Personnel Information Tracking System (PITS) to a new State Employee Relations Tracking System (SERTS). 2 Business Need/Opportunity [Also referred to as “problem statement”] Business Need: The department‟s Bureau of Human Resources Labor Relations Division (LR) is vulnerable to Employee Relations (ER) type litigation because they have no electronic capability to effectively store and track ER type information. Additionally:      ER information maintained on paper is limited. Much ER information is obtained from human memory. There is no capability to maintain ER history information whether electronic or paper. There is no meaningful exchange of ER information between LR and the Districts in the field. There is no capability to determine standard and appropriate levels of disciplinary actions against employees. Opportunities:    SERTS trend analysis may lead to proactive employee intervention resulting in less grievances and appeals. LR customers are exposed to ERP type applications. Employee issues shall be addressed more timely. Business Driver [Driving forces that move the project forward] Critical Success Factor Increasing number of employee personnel actions. 3 Benefits 1. SERTS trend analysis may lead to proactive employee intervention resulting in less grievances and appeals. 2. LR customers are exposed to ERP type applications. 3. Employee issues shall be addressed more timely. High Level Goals and Objectives 1. Develop an application that meets the needs of the customer. 2. Develop an application that is easily maintainable and scalable. 3. Do not reinvent the wheel! Utilize the existing PITS front end functionality as a basis for SERTS because the customer is familiar with PITS and prefers its ease of use. 4. Utilize System Development Life Cycle (SDLC) and Project Management (PM) processes in an attempt to standardize the development process at PENNDOT. 5. Conduct a robust User Acceptance Test (UAT) so that UAT testers become qualified to train other SERTS users in their District Offices („Train the Trainer‟ approach). Guiding Principles 4 Assumptions The following assumptions are made to complete the Project Plan and Schedule. If an assumption becomes invalid, then the tasks, estimates and resources in the Project Schedule shall be adjusted accordingly. 1. Some of the requirements specified in the DMVA contractor‟s “Standard Request for Cost Quotation‟ document dated January 18, 2002” are outdated. The document can no longer be used as the basis for project requirements. The current contractor shall capture the project‟s requirements during the Requirement Phase. 2. An electronic copy of PITS exists and shall be delivered to Bureau of Information Systems Project Office (BISPO) for transformation. 3. In PITS, active and inactive employee information is loaded from the IPPS System. IPPS is scheduled to be retired and shall not be part of the SERTS solution. 4. IRIS is an Oracle based application that includes LR data from SAP. 5. IRIS shall be used as the source of SERTS employee Information. 6. SERTS shall be used across Pennsylvania (Wide Areas Network (WAN)). 7. The SERTS application shall support approximately 30 users including but not limited to 2 users in each of the 11 District Offices plus users in Central Office LR. 8. A new server is not required to store the SERTS application. 9. The information in the SERTS Parameter Tables is relatively static. 10. Districts shall be included in SERTS UAT. 11. UAT includes “Train the Trainer”. 12. An electronic copy of the PITS User Guide and System Administrators Guide exists and shall be delivered to BISPO for modification. 13. LR shall train and support the District User community. 14. BISPO shall provide technical post-production support for SERTS application for up to 2 years. 15. LR shall be responsible for SERTS system administration. 5 Project Scale Template Determine Project Size H Complexity H M L Large Large Medium Effort M Large Medium Small L Large Small Express Determine Deliverables Based on Project Size 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 Governance Structure, Roles and Responsibilities Project Charter Project Scale Project Scope Existing Solutions Applicability Assessment Resource Assessment IT Standards Assessment Procurement Strategy Document Management Plan Project Size Express Small Medium Large X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X 2.10 Project Baseline Assessment 3.1 3.2 3.3 Work Plan and Schedule Issue Management Plan Risk Management Plan X X X X X X X X X 6 Determine Deliverables Based on Project Size 3.4 3.5 3.6 3.7 3.8 3.9 Communications Management Plan Change Control Management Plan Quality Management Plan Requirements Management Plan Contract Management Strategy Project Size Express Small Medium Large X X X X X X X X X X X Budget/Cost Management Strategy Performance 3.10 Management/Success Criteria X X X X X X X Deliverables within the Execution and Control Phase are being identified. X X X X X X X X X X X X 5.1 5.2 5.3 Closeout Checklist Lessons Learned Process Assessment Approval and Authority to Proceed We approve the project component as described above, and authorize the team to proceed. Name Title Signature Prepared By: 7 Project Scope Template Project Background and Description [Copy and paste the project background and description from the project charter. Otherwise, describe how this project came to be, who is involved and what the purpose is.] Scope [Project scope is the boundary of the project. Think of the “project scope” as an imaginary box you are describing that will enclose all the activities for the team’s activities. It not only defines what you are doing, but it sets the boundaries on what the team will not be doing over the course of the project engagement. Scope answers what’s inside the box? What’s outside the box? What is the project going to look like? How much is our project going to contain? High Level Requirements [Describe the high level requirements of the system. This can be described as follows: The new system must have the:  Ability to allow both internal and external users to access the application without downloading any software.  Ability to interface with the existing data warehouse application  Ability to incorporate automated routing and notification based on business rules  etc.] Deliverables [Insert a listing of the deliverables that you expect to produce as a result of this project. Refer to the project scale and deliverables matrix to identify the deliverables which you think would apply.] Affected Organizations [Insert a listing of those agencies, bureaus or divisions which will be impacted by this project. Describe how they will be impacted.] Affected Business Processes or Systems [Insert a listing of those business processes or systems which will be impacted by this project. Describe how they will be impacted.] Specific Exclusions from Scope [Describe any specific components that are excluded from this project.] 8 Implementation Approach [Describe how you plan to implement this project. In one deployment or in smaller releases? What will be included within each release?] High Level Timeline/Schedule [Describe what the high level timeline/schedule will be to plan, design, develop and deploy the project. Generally, when do you expect this project to be finished?] Approval and Authority to Proceed We approve the project component as described above, and authorize the team to proceed. Name [type or sign name] Title Date Prepared By: 9 Project Scope—SERTS Example Project Background and Description Currently we have no electronic tracking capabilities and maintain a very limited number of paper logs. This presents a problem when we are directed to provide historical information to appellant organizations such as the Pennsylvania Human Relations Commission (PHRC), State Civil Service Commission (SCSC) or the Equal Employment Opportunity Commission (EEOC). The historical information requested can include: grievances, employee discipline, PHRC and EEOC Complaints, or SCSC Appeals. Therefore, we are forced to ferret through our files or rely on memory to supply the required information. In this age of an ever increasingly litigious work force, this approach leaves the Department very vulnerable for potential liability. This project will develop a system similar to the Personnel Information Tracking System (PITS) application that was recently developed by Transfer Technologies for the Department of Military and Veterans Affairs. SERT will be a relational data base that tracks the following: Employee Discipline, Employee Criminal Conduct, ADA requests, Grievances, PHRC/EEOC Complaints, Civil Service Appeals. Data maintained in the SERT will be used to perform detailed statistical analyses, which are necessary when defending claims of discrimination in the application of our disciplinary program. Additionally, the SERT will allow managers to research the level of discipline that is customary for a specific infraction. The SERT will be available to each District Office, as well as Headquarters. Security will allow each District to view its data only and permit that District‟s administrator to select which segments of the SERT can be viewed by individual employees within that District. Each District will be able to run preestablished and ad hoc reports on its data. Headquarters will be able to run departmentwide reports. Scope High Level Requirements 10 Deliverables           Project Charter Conceptual Flowchart Business Requirement Document Technical Specification Document Test Plan Test Results Implementation Plan Rollout Plan SERTS User Guide SERTS System Administrators Guide Affected Organizations  PENNDOT Bureau of Human Resources Labor Relations Division (LR)  PENNDOT Bureau of Information Systems Project Office (BISPO)  Office of Administration (OA) Applications Division  All PENNDOT District Offices  PENNDOT Bureau of Information Systems Planning & Consulting Division 11 Affected Business Processes or Systems The following processes, data or transactions are impacted:            Americans With Disabilities Act (ADA) Information State Civil Service Commission (SCSC) Appeal Information Employee Criminal Conduct Information Employee Disciplinary Action Information Grievance Information Pennsylvania Human Relations Commission (PHRC) Complaint Information Equal Employment Opportunity Commission (EEOC) Complaint Information Employee Information New functionality for Information Tracking Predefined and Adhoc Reports The following Administrative functionality: o Parameter Table Maintenance o User Account Maintenance o Application Access/Security Maintenance The following applications are impacted:  PITS  SERTS Specific Exclusions from Scope  The following applications are excluded from this project: o Integrated Personnel Payroll System (IPPS) o SAP  The following shall not be processed in SERTS: o Vehicle and Personal Injury Accident Information o Appointment Above Minimum Information o Unemployment Compensation Information o Workers Compensation Information o Classification Information 12 o All references to „Armory‟ Implementation Approach Project Management Project Planning: The Project Manager (PM) develops a comprehensive Project Plan including but not limited to the Project‟s Scope, Approach, Resource Requirements, Schedule, Cost and Quality Assurance criteria. Scope Management: The PM assures that the project stays within scope boundaries. The PM logs all scope change requests, assesses the impact of the request and reports the request to Project Sponsor for approval/denial. Issue Management: The PM assures that all project issues are reported, logged, assigned and disposed of in a timely manner. Resource Management: The PM estimates resource needs, staffs the project, orients the team, assigns the work and releases the resources when appropriate. Communication Management: The PM shall conduct weekly status meetings with the project team. The PM shall report progress to the Project Sponsor on a weekly basis. The PM must be included in all project related meetings. Systems Development Life Cycle Requirements: Interview Customer repeatedly until all business needs are identified, defined and documented. Build: Design, code, unit test the Technical Solution that satisfies the business needs. Test: Conduct various levels of testing, including but not limited to Functional Testing, Integration Testing, Performance/Stress Testing, User Acceptance Testing to assure the product meets the needs of the Customer. A robust Testing Phase shall train the Central Office LR Users so they can in turn train the District Users across the state. Implementation: Implement Product Post-install technical support: Support Product rollout to field 13 High Level Timeline/Schedule Phase / Milestone Kickoff Project Initial Project Planning Phase Requirements Phase Target Completion Date 4/15/2004 05/13/2004 06/25/2004    Build Phase Test Phase 07/16/2004 08/18/2004  Project Charter Document Conceptual Flowchart Business Requirement Document Technical Specification Document   Implementation Phase 09/30/2004     Test Plan Test Results Implementation Plan Rollout Plan SERTS User Guide SERTS System Administration Guide Deliverable Approval and Authority to Proceed We approve the project component as described above, and authorize the team to proceed. Name [type or sign name] Title Date Prepared By: 14 Work Plan and Schedule Example 10-00-000 10-10-000 10-10-010 10-10-020 10-10-030 PROJECT MANAGEMENT Project Planning Develop Project Charter Develop Niku Schedule Conduct Kickoff Meeting 4/23/2004 4/23/2004 5/11/2004 5/14/2004 4/23/2004 8/12/2004 6/10/2004 6/3/2004 5/14/2004 4/23/2004 ggombed ggombed ~BA Proj Mgr jeskuhn young ~Bus Analyst young ~BA Proj Mgr 10-10-040 Approve Project Charter 4/30/2004 6/10/2004 10-10-999 10-20-000 10-20-010 10-20-999 20-00-000 20-10-000 20-10-010 20-10-020 Project Planning Project Tracking Track Project Project Tracking REQUIREMENTS Requirement Definition Develop Conceptual Design Develop Business Requirements 5/13/2004 8/6/2004 8/6/2004 8/12/2004 5/12/2004 5/12/2004 5/12/2004 5/12/2004 5/13/2004 8/12/2004 8/6/2004 8/12/2004 8/9/2004 8/9/2004 6/3/2004 8/5/2004 ggombed ggombed ggombed ~BA Proj Mgr jeskuhn jdevans jdevans ggombed jdevans kpetril ~BA Proj Mgr young 20-10-030 Develop Data Definition Develop Technical Requirements 6/7/2004 8/5/2004 20-10-040 6/15/2004 8/6/2004 20-10-050 20-10-999 20-20-000 20-20-010 Approve Requirements Requirement Definition Technical Design Technical Design 8/4/2004 8/9/2004 7/27/2004 7/27/2004 8/9/2004 8/9/2004 8/6/2004 8/6/2004 kpetril ggombed jdevans 20-20-999 30-00-000 30-10-000 Technical Design BUILD Development 8/4/2004 7/23/2004 7/23/2004 8/4/2004 8/24/2004 8/18/2004 15 Issue Management Plan Template Overview [Provide an overview of the process you plan to employ to manage issues, what roles will be involved, what the procedures will be and how you will measure the impact of issues.] Process [Describe the process you plan to employ to manage issues. Will existing meetings/groups be leveraged in order to alleviate meetings? What will the escalation procedures be?] Roles and Responsibilities [Describe who will be involved in the issue management process. What roles and teams are required? Are meetings required? If so, how often?] Communication Strategy [Describe what methods will be used to communicate on issues. Will existing meetings be used? What will the escalation procedures be?] Rules/Procedures [Describe what rules or procedures the team must follow when logging, managing and assessing issues. Should all issues be submitted to the project manager? What mechanism must be used to log issues?] Impact Analysis Approach [Describe the process that will be used to assess the impact of each issue. Is criticality sufficient or will some issues require further analysis in order to assess their impact? Who will be involved in this impact analysis?] Approval and Authority to Proceed We approve the project component as described above, and authorize the team to proceed. Name [type or sign name] Title Date Prepared By: 16 Risk Management Plan Template Overview [Provide an overview of the process you plan to employ to manage risks, what roles will be involved, what the procedures will be and how you will measure the impact of risks.] Process [Describe the process you plan to employ to manage risks. Will existing meetings/groups be leveraged in order to alleviate meetings? What will the escalation procedures be?] Roles and Responsibilities [Describe who will be involved in the risk management process. What roles and teams are required? Are meetings required? If so, how often?] Risk Communication Strategy [Describe what methods will be used to communicate on issues. Will existing meetings be used? What will the escalation procedures be?] Rules/Procedures [Describe what rules or procedures the team must follow when logging, managing and assessing risk. Should all risks be submitted to the project manager? What mechanism must be used to log risks?] Risk Impact Analysis Approach [Describe the process that will be used to assess the impact of each risk. Who will be involved in this impact analysis? Below is a sample method which might be used to asses risk impact and occurrence probability.] 17 Impact High 3 Med 2 Low 1 Time Greater than 3 month delay of schedule (3) 1-3 month delay in implementation (2) 1 week to 1 month delay in implementation (1) Occurrence Probability Rank (impact x occurrence probability=rank [example: 3 X 70% = 2.1] Very likely greater than 70% Probable:30-70% probability Unlikely: Less than 30% probability Approval and Authority to Proceed We approve the project component as described above, and authorize the team to proceed. Name [type or sign name] Title Date Prepared By: 18 Change Control Management Plan Template Overview [Provide an overview of the process you plan to employ to manage change requests, what roles will be involved, what the procedures will be and how you will measure the impact of change requests.] Process [Describe the process you plan to employ to manage change requests. Will existing meetings/groups be leveraged in order to alleviate meetings? What will the escalation procedures be?] Roles and Responsibilities [Describe who will be involved in the change management process. What roles and teams are required? Are meetings required? If so, how often?] Communication Strategy [Describe what methods will be used to communicate on change requests. Will existing meetings be used? What will the escalation procedures be?] Rules/Procedures [Describe what rules or procedures the team must follow when logging, managing and assessing change requests. Should all change requests be submitted to the project manager? What mechanism must be used to log change requests?] Impact Analysis Approach [Describe the process that will be used to assess the impact of each change request. be involved in this impact analysis?] Who will Approval and Authority to Proceed We approve the project component as described above, and authorize the team to proceed. Name [type or sign name] Title Date Prepared By: 19 Requirements Management Plan Template Overview [Provide an overview of the process you plan to employ to manage requirements, what roles will be involved, what the procedures will be and how you will measure the importance and relative weight of each requirement. Objectives [Describe what the objectives of the requirements identification effort will be. What is to be accomplished?] Requirements Scope [Describe what the areas of focus will be for the requirements gathering effort. What business areas are included or excluded?] Process [Describe the process you plan to employ to manage requirements. Will existing meetings/groups be leveraged in order to alleviate meetings? What will the escalation procedures be?] Roles and Responsibilities [Describe who will be involved in the requirements gathering process. What roles and teams are required? Are meetings required? If so, how often?] Rules/Procedures [Describe what rules or procedures the team must follow when logging, managing and assessing requirements. Should all requirements be submitted to the project manager? What mechanism must be used to log requirements?] Weight and Ranking Approach [Some alternatives: Criticality (H/M/L); Stability (Volatile, Neutral, Unlikely to Change); Level of Effort (1-3, 4-7, 8-10 weeks or months); Impact (H/M/L); Target Release Deployment (1, 2, 3, 4); Dependency – Number requirements and identify relationships] [Describe the process that will be used to assess the importance and relative weight of each requirement. Who will be involved in this analysis?] 20 Requirements Management Tools [Describe what tools will be used to log requirements. Will word or excel be used? Will a database be used? Where will the logging mechanism be stored? How will version control be handled?] Schedule [Describe what the high level plan will be to gather requirements. What will be discussed when (what will the sequencing be)?[ Approval and Authority to Proceed We approve the project component as described above, and authorize the team to proceed. Name [type or sign name] Title Date Prepared By: 21 Communications Management Plan Template Overview [Provide an overview of the process you plan to employ to manage issues, what roles will be involved, what the procedures will be and how you will measure the impact of issues.] Goals and Objectives of Communications Strategy Goal: [The communications goal is a direction-setter and ideal future end related toward which planning and implementation activities are directed. A goal is generally not quantifiable, timedependent or suggestive of specific actions for its achievement.] Objective: [Objectives are specific ends, conditions or states that are intermediate steps toward attaining a goal. They should be achievable and, when possible, measurable and time-specific. An objective may only pertain to one particular aspect of a goal or it may be one of several successive steps toward goal achievement. Consequently, there may be more than one objective for each goal.] Key Messages/Themes [Describe the key messages or themes must be employed throughout the entire communications program. These are themes you want reinforced repeatedly.] Critical Success Factors [Describe those items that must be achieved at the end of the communications program. These factors will basically determine whether the communications program is a success.] Communication Phases [Describe what phases the communications program will employ. Will messages be directly related to the release strategy or phases of the project?] **(additional pages available on website) 22 Issue Log Template Issue Description Potential Impact If not resolved Analysis Required? Cost/Schedule Criticality H/M/L Assigned To: Date Status Resolution Notes 1 2 3 4 5 6 7 23 Risk Log Template Business Priority Risk Category Occurrence Probability Risk Management Strategy Status Mitigation Activities Contingency Assigned to: Risk, Threat Impact Rank [insert date, then status report] 1 0.00 [insert date, then status report] 2 0.00 [insert date, then status report] 3 0.00 [insert date, then status report] 4 0.00 [insert date, then status report] 5 0.00 [insert date, then status report] 6 0.00 24 Change Request Log Template No. Date Requestor Change Request Description Priority High Medium Low Impact, Deliverables Affected Assigned to: Status Status Date Comment, Resolution 1 2 3 4 5 6 7 25 Closeout Checklist Template Access Have all security badges been secured? Have outlook access accounts been disabled? Has access to applications been disabled or modified? Y/N Y/N Y/N Deliverables Have all deliverables been completed and signed off on? Have all deliverables and related financial records been placed in a centralized repository for easy access? Have source files been obtained for all deliverables (No PDF documents)? Y/N Y/N Y/N Knowledge Transfer Has appropriate knowledge transfer occurred on key components of the project? Have all key administrators of the system been identified and trained? Does the maintenance team have access to all the artifacts that could help them maintain the project's deliverables? Y/N Y/N Y/N Transition Has communication been issued indicating that the project (or project phase) is ending? Have all project staff been released or reallocated? Have all invoices and financial obligations been resolved? Y/N Y/N Y/N 26 Lessons Learned Template Overview [Describe what is to be accomplished by the lessons learned sessions. What are the key objectives and what will be done with the information once it has been gathered?] Preparation [Describe what type of preparatory work is required to conduct the lessons learned sessions. What information needs to be gathered? What type of logistics need to be taken care of. Do the facilitators need any kind of training prior to conducting the sessions?] Work Session [Describe how each individual work session is to be conducted. Will white boards be used? Who will conduct the facilitation? Who will be in attendance? What is the schedule for these sessions?] Participants Name Location Phone Email Address Role(s) Category General Processes Verification What were the most critical factors for project success? Y/N/ Partially Explanations/ Lessons Learned When information or documents were handed off to other groups (the downstream process) what “worked well” and what can “be improved”? 27 Category Verification Were there challenges or barriers in the downstream process that you overcame, if so, how? Y/N/ Partially Explanations/ Lessons Learned What worked well in terms of: Logistics (deadlines, meetings, etc.) Were standard templates and deliverables used? Were all templates of value in this project? Which tools or techniques were not used? Were there organizational obstacles that made it difficult or impossible to use any part of the process? Were roles and responsibilities clearly defined? Phase Specific Was the Strategy Phase completed successfully? Was the Planning Phase completed successfully? Was the Initiation Phase completed successfully? 28 Category Verification Was the Execution and Control Phase completed successfully? Was the Close-out Phase completed successfully? Y/N/ Partially Explanations/ Lessons Learned Control-Specific Have any scope changes to this project impacted the schedule? How? Have cross-project dependencies affected scope? How? Was the work plan well documented, with appropriate structure and detail? Did the work plan encompass all aspects of the project? Did stakeholders have appropriate input into the project planning process? How often were deliverables „re-worked‟ based on the introduction of new requirements? How often were deliverables „re-worked‟ because it did not meet requirements? Were communications adequate in all activities? Did you know what you needed to know when you needed to know it? Was risk controlled adequately? 29 Category Verification Was an adequate contingency plan created? Y/N/ Partially Explanations/ Lessons Learned Did the project meet all original scheduled milestones/deadlines? Was project status reported according to plan? Were all issues resolved in a timely manner? Did the change control procedure work adequately? Did the project receive all the necessary approvals to proceed in a timely fashion? Was the project staffed appropriately? Was quality of the product or services adequate? Were Initial cost and schedule estimates were accurate? Was the technology solution chosen appropriate for the project? Communications Were status and issues communicated in a timely manner to all appropriate parties? Did the user community understand the project, what was completed and what was coming next? 30 Category Requirements Verification Were customer needs and /requirements met? Y/N/ Partially Explanations/ Lessons Learned Were requirements gathered to a sufficient detail? Were requirements documented clearly? Were specifications clear and well-documented? Were test plans adequate, understandable, and well documented? Overall Was the project a success? Were project objectives met? 31