PREPARATION WORKBOOK FOR PROJECT CHARTER FOR CERTIFICATION A GUIDE FOR A SUCCESSFUL PROJECT CHARTER REVISION: 1.1 Preparation Workbook for the Project Charter for Certification Page 2 of 42 Table of Contents THE PROJECT CHARTER – BEST PRACTICES.................................................................................................4 PERMISSION TO PLAN THE PROJECT AND SETTING THE GOVERNANCE STRUCTURE ......................................................4 Project Charter – Project Management Institute -PMBOK© ........................................................4 THE PROJECT CHARTER FOR CERTIFICATION.............................................................................................5 PROJECT CERTIFICATION INITIAL PHASE DOCUMENTATION ......................................................................................5 From Project Charter to Certification to Project Management Plan ..........................................6 UNDERSTANDING THE PROJECT CHARTER REVIEWER’S EXPECTATIONS ..................................................7 FILLING IN THE BLANKS ...............................................................................................................................9 STARTING WITH THE TITLE PAGE .............................................................................................................................9 THE TITLE............................................................................................................................................................9 THE EXECUTIVE SPONSOR AND BUSINESS OWNER...................................................................................................9 THE PROJECT MANAGER....................................................................................................................................9 WHAT IS THE ORIGINAL PLAN DATE AND WHY THE REVISION DATE AND REVISION NUMBER?..................................10 THE IMPORTANCE OF REVISION HISTORY .............................................................................................................10 1. PROJECT BACKGROUND......................................................................................................................10 1.1 EXECUTIVE SUMMARY – RATIONALE FOR THE PROJECT...................................................................................10 1.2 SUMMARY OF THE FOUNDATION PLANNING AND DOCUMENTATION FOR THE PROJECT .....................................11 1.3 PROJECT CERTIFICATION REQUIREMENTS ......................................................................................................12 2. JUSTIFICATION, OBJECTIVES AND IMPACTS........................................................................................12 2.1 AGENCY JUSTIFICATION ..............................................................................................................................12 2.2 BUSINESS OBJECTIVES.................................................................................................................................12 2.3 TECHNICAL OBJECTIVES ..............................................................................................................................13 2.4 IMPACT ON ORGANIZATION ........................................................................................................................14 2.5 TRANSITION TO OPERATIONS.......................................................................................................................14 3.0 PROJECT/PRODUCT SCOPE OF WORK...............................................................................................15 3.1 DELIVERABLES ............................................................................................................................................15 3.1.1 Project Deliverables ................................................................................................................15 3.1.2 Product Deliverables ..............................................................................................................15 3.2 SUCCESS AND QUALITY METRICS .................................................................................................................16 4.0 SCHEDULE ESTIMATE ............................................................................................................................16 5.0 BUDGET ESTIMATE ...............................................................................................................................16 5.1 FUNDING SOURCES ....................................................................................................................................16 5.2 BUDGET BY MAJOR DELIVERABLE OR TYPE OF EXPENSE .................................................................................17 5.3 BUDGET BY PROJECT OR CERTIFICATION PHASE ............................................................................................17 6.0 PROJECT AUTHORITY AND ORGANIZATIONAL STRUCTURE ..............................................................18 Preparation Workbook for the Project Charter for Certification Page 3 of 42 6.1 STAKEHOLDERS ..........................................................................................................................................18 6.2 PROJECT GOVERNANCE PLAN....................................................................................................................19 6.3 PROJECT MANAGER..................................................................................................................................19 6.3.1 Project Manager Contact Information ................................................................................20 6.3.2 Project Manager back ground .............................................................................................20 6.4 PROJECT TEAM ROLES AND RESPONSIBILITIES.................................................................................................20 6.5 PROJECT MANAGEMENT METHODOLOGY....................................................................................................20 7.0 CONSTRAINTS......................................................................................................................................21 8.0 DEPENDENCIES....................................................................................................................................21 9.0 ASSUMPTIONS .....................................................................................................................................22 10. SIGNIFICANT RISKS AND MITIGATION STRATEGY .............................................................................22 ORGANIZATIONAL RISKS...................................................................................................................................23 RESOURCE RISKS ..............................................................................................................................................24 EXTERNAL RISKS................................................................................................................................................24 PLANNING RISKS ..............................................................................................................................................25 TECHNICAL RISKS .............................................................................................................................................25 11. COMMUNICATION PLAN FOR EXECUTIVE REPORTING ....................................................................26 12. INDEPENDENT VERIFICATION AND VALIDATION...............................................................................26 IV&V TOPICS FROM WHICH A PROJECT WILL CHOOSE.........................................................................................26 IV&V Project Management ............................................................................................................27 Planning Oversight ...........................................................................................................................27 Project Management ......................................................................................................................28 Quality Management.....................................................................................................................31 Training .............................................................................................................................................32 Requirements Management ..........................................................................................................33 Operating Environment...................................................................................................................34 Development Environment.............................................................................................................36 Software Development ...................................................................................................................37 System and Acceptance Testing...................................................................................................38 Data Management .........................................................................................................................40 Operations Oversight......................................................................................................................40 AN AFTERWORD ........................................................................................................................................41 PROJECT CHARTER TO PROJECT MANAGEMENT PLAN (PMP) ...............................................................41 Preparation Workbook for the Project Charter for Certification Page 4 of 42 THE PROJECT CHARTER – BEST PRACTICES PERMISSION TO PLAN THE PROJECT AND SETTING THE GOVERNANCE STRUCTURE The Project Charter provides the project manager and project team with permission to proceed with the work of the project, within the scope delineated in this document. The Project Charter should be the outcome of a number of documents that went into the pre-planning for the project, and in many cases the agency IT Plan, Business Case for appropriations, Federal funding requests and the like. Project sponsors sign the Project Charter signifying that they have agreed to the governance structure for guiding the direction for the further planning of the project, discovery and defining the requirements, acquiring necessary resources, and within that context the statement of work for any related contracts including a contract for the Independent Validation and Verification. The Project Charter is also the foundation for the creation of the project management plan, and much of the thinking and writing for this charter will be immediately usable for that plan. PROJECT CHARTER – PROJECT MANAGEMENT INSTITUTE -PMBOK© “The project charter is the document that formally authorizes a project. The project charter provides the project manager with the authority to apply organizational resources to project activities. “ “A project imitator or sponsor external to the project, at a level that is appropriate to funding the project issues the project charter.” Developing the project charter is primarily concerned with documenting the business needs, project justification, current understanding of the customer’s requirements, and the new product, serve or result that is intended to satisfy those requirements. The project charter should address the following: • Requirements that satisfy customer, sponsor, and other stakeholder needs, wants and expectations • Business needs, high level project description, or product requirements that the project is undertaken to address • Project purpose or justification • Assigned project manager and authority level • Summary milestone schedule • Stakeholder influences • Functional organizations and their participation Preparation Workbook for the Project Charter for Certification Page 5 of 42 • Organizational, environmental and external assumptions • Organizational, environmental and external constraints • Business Case justifying the project, including return on investment • Summary budget THE PROJECT CHARTER FOR CERTIFICATION PROJECT CERTIFICATION INITIAL PHASE DOCUMENTATION The Project Charter is also used within the State of New Mexico IT Project Certification process as evidence of the project’s worthiness for the Initial Phase certification. The Initial Phase certification is especially critical to many state and agency projects because of its related release of the initial funds required for the project. The Project Charter and the Request for Certification Form are meant to provide a comprehensive picture of the project’s intention and initial planning, that includes the project’s place in the context of the State of New Mexico’s IT Strategic Plan, Enterprise Architecture, and DoIT project oversight process. See “IT Project Oversight Process” Memorandum July 5th 2007 on the OCIO-DoIT web site. Initiation Phase funding is requested by an agency for use in developing project phases, developing Independent Verification and Validation (“IV&V”) plan and contract; address project review issues and/or to develop an overall project management plan. Note: Waiver of the IV&V requirement requires specific written approval by the Secretary of the DoIT. DoIT “Project Certification” Memorandum July 2, 2007 Preparation Workbook for the Project Charter for Certification Page 6 of 42 FROM PROJECT CHARTER TO CERTIFICATION TO PROJECT MANAGEMENT PLAN This Project Charter Preparation workbook is meant to assist the project manager or agency project sponsor team to develop a project charter that will facilitate the Initiation Phase Certification, and in turn provide “a copy and paste” transition to foundation information in the project management plan. Preparation Workbook for the Project Charter for Certification Page 7 of 42 UNDERSTANDING THE PROJECT CHARTER REVIEWER’S EXPECTATIONS The most important thing to keep in mind when creating the project charter is that we cannot make any assumptions about the readers’ knowledge of the project. The challenge is to provide enough information to convey the key elements of the project without getting buried in detail, especially technical detail. The second most important thing to keep in mind is that the project charter is written for decision makers who need to know the reasons that valuable state resources are being requested, and that the project is being approached in a reasonable and sound business manner. The following is a table of questions that will need to be anticipated in this project charter. The next section of this workbook will address in detail each section of the charter document, but for now please consider the messages you will need to get across to the project sponsor(s) and the members of the Project Certification Committee. Charter Area Reviewers’ Questions 1. Project Background Do you understand the purpose of the project, Its preparation and why it is coming for certification? 2. Justification, Objectives and Impacts Does the project fit with the mission of the agency, are the business objectives SMART -specific, measurable, attainable, realistic and achievable in its time frame. Has the project considered the impacts of the organization and started to address the transition to operations at the end of the project? 3. Project/Product Scope of Work Has the project Manager identified deliverables that are appropriate for the type and magnitude of the project? 3.2. Success and Quality Metrics Are the metrics specific enough and appropriate for the type and magnitude of the project – do we understand the expectations of the project sponsor(s)? 4.. Schedule Estimate Is there enough detail to the type of tasks that are required for the project, and does the time frame for the project seem reasonable? 5. Budget Estimate Is there enough information about the source of funding and the estimation of costs? Are Agency Staff time and project manager time calculated into the cost estimates? Do the budget allocations seem reasonable? 6. Project Authority and Organization Structure Have all the project stakeholders been identified? Do we understand the project governance structure? Does the project manager seem to have the background for this project? Does the project team seem to have the right mix of roles and Preparation Workbook for the Project Charter for Certification Page 8 of 42 responsibilities? 6.5. Project Management Methodology Is there evidence of a project management approach appropriate for the nature and magnitude of the project? (This is a requirement from the” IT Project Oversight Process” memorandum) 7. Constraints Is there an adequate appreciation for the constraints operative for this project? 8. Dependencies Is there an adequate appreciation for the dependencies operative for this project? 9. Assumptions Have the assumptions been adequately identified, keeping in mind that assumptions are potential risks to the project 10. Significant Risks and Mitigation Strategy Risks are inherent to project management which includes planning to deal with risk. Have the typical risks for this type of project been identified? Have the risks of doing IT projects in State Government been identified? 11. Communication Plan for Executive Reporting Does the description of this plan appear as adequate for the type and magnitude of the project? 12. IV&V Has the project adequately identified the areas appropriate for IV&V for a project of this type and magnitude? In summary, the project charter for certification will be read by the Project Certification Committee which has the responsibility to certify that the project is well defined and thought out even at the outset. Think about it this way, as you are about to take your vacation trip, you may not have all the details about the restaurants along the way, you may or may not have made hotel reservations along the way – some of us are more adventurous that others, but you want to make sure you have your travelers checks, cash and credit cards that will support the charges you will make. You probably looked at your tires and had your oil changed and other such damage control tasks completed. But have you done the simple things like stopping mail or newspaper delivery? Have you asked someone to check on your house or apartment every once in a while? The Project Certification Committee wants to be assured that state funds and state employee time is well spent. They want you to have a successful project on behalf of your agency and the citizens of the State of New Mexico. The rest of this workbook will provide guidance for you and your team in the planning process for your project. The importance of the charter is twofold – it lays out the permission and governance for the project, and obtains along with other documents the required state level certification of your project. Preparation Workbook for the Project Charter for Certification Page 9 of 42 FILLING IN THE BLANKS STARTING WITH THE TITLE PAGE Even the title page has significant information, and assumptions. It tells us what the project calls itself, who the project benefits, who is running the project, and if the Project Charter has been revised during the project, which is okay and expected. 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? THE EXECUTIVE SPONSOR AND BUSINESS OWNER Project sponsorship is about the resources required to do the project, whether they are the financial resources from state or federal funding/appropriation or from the agency’s own operating funds. Many State of New Mexico projects list the agency Cabinet Secretary as the Executive Sponsor and a combination of the agency CIO and business process owner as the business owners of the project. The following are some key responsibilities of project sponsorship: • Appoint an appropriately skilled project manager • Understand the project complexity • Champion the project and the team • Formally manage the project scope • Provide guidance for business strategies • 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. THE PROJECT MANAGER Preparation Workbook for the Project Charter for Certification Page 10 of 42 According to the “IT PROJECT OVERIGHT PROCESS” memorandum from Roy Soto, Secretary of the Department of Information Technology: “Project manager” means a qualified person from the lead agency responsible for all aspects of the project over the entire project management lifecycle (initiate, plan, execute, control, close). The project manager must be familiar with project scope and objectives, as well as effectively coordinate the activities of the team. In addition, the project manager is responsible for developing the project plan and project schedule with the project team to ensure timely completion of the project. The project manager interfaces with all areas affected by the project including end users, distributors, and vendors. The project manager ensures adherence to the best practices and standards of the Department. 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. THE IMPORTANCE OF REVISION HISTORY Although not on the title page there is a revision history table in the template. This should be used as tracking device to capture the nature of changes made to the project charter document. Used in conjunction with change management, the process will facilitate the response to such questions as when did this get added to the project? 1. PROJECT BACKGROUND Reviewers’ question: “Do you understand the purpose of the project, Its preparation and why it is coming for certification?” The project background section is meant to provide the reviewer with a picture of the development of the project from inception to its being submitted for certification. 1.1 EXECUTIVE SUMMARY – RATIONALE FOR THE PROJECT In this section there should be enough information to portray the situation or problem that the project results will resolve, without getting into too much detail. Some suggestions: The Business Problem and Opportunity section of the one page business case • Briefly explain the business problem faced by the agency and the opportunity the agency has to solve the problem through an IT solution. Briefly present essentials to relay the Preparation Workbook for the Project Charter for Certification Page 11 of 42 problem and opportunity presented including the agency’s business performance, mission, goals, objectives, and strategic plan and, if any, cross agency collaborations and impacts The Problem Statement-Recommendation approach: • A problem statement that outlines what the existing situation is and how the business of the agency is being negatively impacted • A brief “root cause” analysis listing factors that, if resolved by the project, would eliminate the problem, thus benefiting the agency. • The project recommended solution, stating clearly that the solution will address the root cause issues of the problem, resolving the problem and eliminating the negative impact to the agency. The current state-future state-needs 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 The “elevator speech” approach • 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 person’s attention to sell the problem and the solution to the problem. 1.2 SUMMARY OF THE FOUNDATION PLANNING AND DOCUMENTATION FOR THE PROJECT Successful projects represent some degree of thinking and planning upfront securing the executive sponsorship, and even appropriations or ear-marked aspects of the agency budget. What should be presented in this section is the summary of work effort that has lead up to securing sponsorship and funding for the project. This would be the place to mention the one page business case submitted to the Department of Information Technology and the submission of the full business case if the idea was brought to that stage, and any mention in the agency’s submitted IT Plan. Requests for Information and requests for proposals would be appropriate to be mentioned here, to indicate research efforts done towards the solution to the problems mentioned in the previous section. Preparation Workbook for the Project Charter for Certification Page 12 of 42 1.3 PROJECT CERTIFICATION REQUIREMENTS There are the four criteria for requiring certification for the project: • Mission criticality for the agency, • Costs above 100K, • Impacts to customer on-line access • At the discretion of the Secretary of DoIT. There should be a brief presentation of the reason(s) for this project coming before the State of New Mexico IT Certification process. 2. JUSTIFICATION, OBJECTIVES AND IMPACTS Reviewers’ question: “Does the project fit with the mission of the agency, are the business objectives SMART -specific, measurable, attainable, realistic and achievable in its time frame. Has the project considered the impacts of the organization and has started to address the transition to operations at the end of the project?” 2.1 AGENCY JUSTIFICATION In brief, list the objectives the proposed project will support and how it is consistent with established agency’s business performance, mission, goals, objectives, and strategic plan. 2.2 BUSINESS OBJECTIVES 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 Rationale Acceptance/Fi t Criteria 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 Preparation Workbook for the Project Charter for Certification Page 13 of 42 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?” 2.3 TECHNICAL OBJECTIVES Technical objectives relate to the technical issues or goals the project is to accomplish. These may be related to acquisition of hardware, software, consulting, training, application development and other “how’s” of the project. The 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 Requirement # Description Rationale Source Source Document Acceptance/Fit Criteria Because technical objectives should be traceable to specific Business Objectives, 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 DESCRIPTION Bus. Objective 1 Reduce cost of government operations through IT Tech. Objective 1 Identity Management and Directory Services Tech. Objective 2 Common Business Functions and data interchange and discovery methodology for all agencies to access and use for report creation. Bus. Objective 2 Reduce cost of IT operations through an enterprise Model Tech. Objective 4 Common IT service architecture and operating environment, including Standards, SLA (Service Level Agreements) approach, Preparation Workbook for the Project Charter for Certification Page 14 of 42 NUMBER DESCRIPTION governance model and improved funding mechanism 2.4 IMPACT ON ORGANIZATION The impacts on the organization are areas that need to be addressed by the project through its planning process. They may not be internal project risks, but they can impact the success of the project’s implementation. This is not the place for any detail, but what is asked for is some indication that some thought has been given to non-technical aspects. 2.5 TRANSITION TO OPERATIONS Effective project management starts from day 1 to think about how the IT solution will be transitioned to operations. Hardware and software acquisition along with either solution development or COTS package is only the start of the process. The transition to operations areas include items that are asked in the certification form to assure that the project has accounted or will account for these matters in its planning and requirements specifications. A key item is “Preliminary Operations location and staffing plans” where will application be hosted and how will it be supported? The State of New Mexico Certification form asks a number of questions related to this transition to operations theme: Security Strategy (Summarize Plan for Security, Backup and Disaster Recovery) Maintenance Strategy (Describe how the agency plans to maintain this project after deployment) Interoperability (Describe how this project interfaces with existing systems/Applications within the agency) Record Retention Policy (Describe the Agency’s records retention requirements for this project) It would be expected that as the project moves through its phases, more attention will be paid to the transition to operations. Other topics that could be included in this area are staffing, training, location of the servers and the like. Preparation Workbook for the Project Charter for Certification Page 15 of 42 3.0 PROJECT/PRODUCT SCOPE OF WORK Project Reviewer’s question “Has the project Manager identified deliverables that are appropriate for the type and magnitude of the project?” This area of the project charter deals with both deliverables and sponsor success expectations. 3.1 DELIVERABLES A deliverable is any measurable, tangible, verifiable outcome, result, or item that is required to complete a project or part of a project. The term is often used more narrowly in reference to an external deliverable (i.e. this deliverable is subject to approval by the project sponsor or customer). Analyze the project scope and objectives outlined in the Project Proposal and Charter to develop a list of deliverables. 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 3.1.1 PROJECT DELIVERABLES The project document deliverables for the certification processes are pre-populated in the project charter for certification template. The documents are listed in the PROJECT CERTIFICATION memorandum, the graphic illustration of the process, and in the PROJECT OVERSIGHT PROCESS memorandum: Note: this includes: The DoIT “Initial PROJECT RISK ASSESSMENT” template which is meant to fulfill the following requirement: “Prepare a written risk assessment report at the inception of a project and at end of each product development lifecycle phase or more frequently for large high-risk projects. Each risk assessment shall be included as a project activity in project schedule.” Project Oversight Process memorandum As the project moves into the planning phase, other documents will be added to this list 3.1.2 PRODUCT DELIVERABLES Product deliverables can be both completed products, i.e. a COTS package installed on an appropriately configured server, but will also be the product related documents. Among the possible documents could be the requirements for the product, the system specifications document that is based on the requirements, the system architecture document that provides the detailed design specifications for the system, acceptance testing documentation, and operations documents. Preparation Workbook for the Project Charter for Certification Page 16 of 42 3.2 SUCCESS AND QUALITY METRICS Metric are key to understanding the ability of the project to meet the end goals of the Executive Sponsor and the Business Owner, as well as the ability of the project team to stay within schedule and budget. (This category is different that the project metrics that more often deal with changes to scope, slippages in dates and the like.) 4.0 SCHEDULE ESTIMATE Reviewers’ question: “Is there enough detail to the type of tasks that are required for the project, and does the time frame for the project seem reasonable?” The schedule estimate is requested to provide the reviewers with a sense of the magnitude of the project and an order of magnitude of the time required to complete the project. In developing the schedule estimate, certification timelines and state purchasing contracts and procurement lead times are as critical as vendor lead times for staffing and equipment delivery. Project metrics include comparisons of actual vs. target date. At the Project Charter initial phase, these times can only be estimated. Reminder: Keep in mind such project tasks as the phase certifications, and the requirement to: “Prepare a written risk assessment report at the inception of a project and at the end of each product development lifecycle phase or more frequently for large and high-risk projects. Each risk assessment shall be included as a project activity in the project schedule. 5.0 BUDGET ESTIMATE Reviewer’s question: “Is there enough information about the source of funding and the estimation of costs? Are Agency Staff time and project manager time calculated into the cost estimates? Do the budget allocations seem reasonable?” Within the Project Charter the budgets for the project can only be estimated. Original budgets requested in appropriations or within agency budgets are probably not the numbers being worked with at project time. Funding sources are asked for to help evaluate the realism of project objectives against funding, and the allocation of budget estimates against project deliverables. Please remember to include agency staff time including project managers as costs. 5.1 FUNDING SOURCES This question is also asked in the request for certification and release of funds document. A project is not a project unless it has actually funding. Appropriation History (Include all Funding sources, e.g. Federal, State, County, Municipal laws or grants) Fiscal Year Amount Funding source Preparation Workbook for the Project Charter for Certification Page 17 of 42 5.2 BUDGET BY MAJOR DELIVERABLE OR TYPE OF EXPENSE Where a contract will be established and a set of deliverables set in the scope of work, matching up key project or product deliverables would be appropriate. If the project will be purchasing a COTS package, equipment, operating systems etc, you might estimate these costs, along with consulting costs. Expense Amount Staffing Internal Consulting Services Hardware Software TOTAL 5.3 BUDGET BY PROJECT OR CERTIFICATION PHASE This is included in the request for certification and release of funds form. Note that within the table below, the project can include its own internal phases within a certification phase, i.e. Product define, design and build phases as well as deploy phase could be listed under the certification implementation phase. PROPOSED CERTIFICATION SCHEDULE FOR CURRENT FISCAL YEAR (AGENCY TO COMPLETE FOR ALL PHASES) Phases Amount Requested Major Deliverable(s) Due Dates Initiation: Planning: Implementation: Project Phase(s): Closeout: Project Phase(s): Preparation Workbook for the Project Charter for Certification Page 18 of 42 6.0 PROJECT AUTHORITY AND ORGANIZATIONAL STRUCTURE Reviewers’ question: “Have all the project stakeholders been identified? Do we understand the project governance structure? Does the project manager seem to have the background for this project? Does the project team seem to have the right mix of roles and responsibilities?” One of the major reasons for the project charter is the establishment of the authority of the project manager with the governance structure of the project. Because the project operates alongside, or outside, the sponsoring agency’s organization structure, it needs its own rules of the road. Inevitably there are decisions to be made, conflicts or issues resolved, and stakeholders to be heard from. This section establishes the way the project is to be run, and to whom different teams report. 6.1 STAKEHOLDERS 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 project’s 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. 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. Preparation Workbook for the Project Charter for Certification Page 19 of 42 6.2 PROJECT GOVERNANCE PLAN A key element in the project governance is the Organization chart for the project. Describe the process that is going to be used to manage the scope of the project. Make sure to address managing stakeholder expectations. Describe at a high-level how issues will be escalated and resolved and how change requests will be processed. In many projects the business owners sit as the members of the steering committee. The role of the steering committee: • Sets the tone for the project • Manages the project charter including authorizing the role of the project manager • Manages the scope of the project in terms of cost, schedule and quality of the project • Deals with issues escalated to them • Accepts project team recommendations especially in go-no go decision matters. 6.3 PROJECT MANAGER The project manager is a key person in the development and planning of the project and its success. DoIT has expressed this vital role in its PROJECT OVERSIGHT PROCESS Memorandum: PROJECT MANAGEMENT METHODOLOGY A. All IT projects shall be managed: Preparation Workbook for the Project Charter for Certification Page 20 of 42 (1) Using a qualified project manager; “Project manager” means a qualified person from the lead agency responsible for all aspects of the project over the entire project management lifecycle (initiate, plan, execute, control, close). The project manager must be familiar with project scope and objectives, as well as effectively coordinate the activities of the team. In addition, the project manager is responsible for developing the project plan and project schedule with the project team to ensure timely completion of the project. The project manager interfaces with all areas affected by the project including end users, distributors, and vendors. The project manager ensures adherence to the best practices and standards of the Department. “Qualified” means demonstrated experience managing IT projects. Demonstrated experience includes exhibiting the ability to apply project management methodology to maintain projects on time, on budget, and on schedule. Qualified also includes those employees who have the demonstrated ability to manage resources, lead people to accomplishing project objectives and who possess a working knowledge of the project scope. Where an agency has chosen someone without the experience and background outlined, the DoIT project oversight and compliance team will assist the agency in the project management guidance. 6.3.1 PROJECT MANAGER CONTACT INFORMATION The project manager is to supply his or her contact information here. 6.3.2 PROJECT MANAGER BACK GROUND The reader will be helped to understand the rationale for the project manager being chosen for this role on this project. The DoIT Project Oversight and Compliance team and especially the Project Management Services team might be of significant help to a less experienced project manager. 6.4 PROJECT TEAM ROLES AND RESPONSIBILITIES Page: 20 List the team roles and each role’s responsibility. Make sure to include a comprehensive listing including the roles of the organization managing the project, business members involved to ensure business objectives are met and the vendor members that may have a specific role. Be sure to list all the areas of the project, business process owners, operations, application support, training, vendor if known, and their responsibility within the project. 6.5 PROJECT MANAGEMENT METHODOLOGY Reviewers question: “(This is a requirement form the” IT Project Oversight Process” memorandum) is there evidence of a project management approach appropriate for the nature and magnitude of the project?” Preparation Workbook for the Project Charter for Certification Page 21 of 42 In the PROJECT OVERSIGHT PROCESS memorandum, there is a series of statements regarding project management methodology it states that: A. All IT projects shall be managed: (1) Using a qualified project manager; (2) Using a formal project management methodology, process, and techniques, identified in the project charter and approved by the Department. This section requests some perspective as to the methodology to be used. The Department of Information Technology certification process is built around a series of certification or Phase-gates: Initiation, Planning, Implementation and Closeout. Each of these phases-gates has a set of expected documents associated with it. The gates and the associated documents make up the certification methodology. For some projects such a framework might be sufficient, where for some projects the solution development life cycle (SDLC) with plan, define, design, build, close might be more appropriate. Put most simply, how is the project to be structured into a methodology or framework and where do the project and product deliverables fit into this roadmap? 7.0 CONSTRAINTS Reviewers’ question: “Is there an adequate appreciation for the constraints operative for this project?” Factors that will (or do) limit the project management team’s options. Contract provisions will generally be considered 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. 8.0 DEPENDENCIES Reviewers’ question: “Is there an adequate appreciation for the dependencies operative for this project?” 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 car’s 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. Preparation Workbook for the Project Charter for Certification Page 22 of 42 • 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 car’s 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. 9.0 ASSUMPTIONS Reviewers’ question: “Have the assumptions been adequately identified, keeping in mind that assumptions are potential risks to the project” Assumptions make 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. 10. SIGNIFICANT RISKS AND MITIGATION STRATEGY Reviewers’ question: “Risks are inherent to project management which includes planning to deal with risk. Have the typical risks for this type of project been identified? Have the risks of doing IT projects in State Government been identified?” Note: Along with this project charter, the project must submit the The DoIT Initial PROJECT RISK ASSESSMENT template which is meant to fulfill the following requirement: “Prepare a written risk assessment report at the inception of a project and at end of each product development lifecycle phase or more frequently for large high-risk projects. Each risk assessment shall be included as a project activity in project schedule.” Project Oversight Process memorandum That risk assessment template should be used as a guideline for identifying the initial significant risks for the project. The project might also reference the IV&V Exhibit A for areas that would be the focus of IV&V as a risk mitigation strategy. INSTRUCTIONS FOR COMPLETING THE RISK IDENTIFICATION TABLE Risk Name – should easy reflect the challenge without detail Description -Describe the risk’s characteristics and explain why this risk is perceived to have the potential to affect the outcome of the project. Preparation Workbook for the Project Charter for Certification Page 23 of 42 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. Probability Impact Mitigation Strategy Description -Contingency Plan Risk management” – Projects By their temporary nature and unique outcomes are risky –Project management reduces the impact of the threats by making them explicit and then working on reducing their impacts or by eliminating them. • Describe an event or condition that may occur, causing a negative impact on the project, and, • How these risks will be monitored and managed. 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. Some examples: Risk – Staff unfamiliar with technology – Mitigations – staff training, staff augmentation, consulting Risk – Multiple organizations participating each with different approaches – Mitigation – communications, establishing project glossary etc. ORGANIZATIONAL RISKS Preparation Workbook for the Project Charter for Certification Page 24 of 42 • Poor Initiation • Sponsor Changes • 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 – Timing – Quality Preparation Workbook for the Project Charter for Certification Page 25 of 42 – Lack of incentive or penalty • 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 TECHNICAL RISKS • Incomplete Requirements • Scope Creep • No or Poor Change Management Process • Complex or Overly Complex Designs • Technology Readiness • Technical Dependencies Preparation Workbook for the Project Charter for Certification Page 26 of 42 • No Test Environment • Cutting Edge Components • Inadequate Documentation • Vendor Technical Support • Code or Patch directly to Production Environment • No Pilot 11. COMMUNICATION PLAN FOR EXECUTIVE REPORTING Reviewers’ question: “Does the description of this plan appear as adequate for the type and magnitude of the project?” Use this section to describe the method that will be used to effectively disseminate information to the project‘s Executive Sponsor and/or the Business Owner(s) and other governing bodies such as the Office of the Chief Information Officer and the Information Technology Commission. Indicate how, when, what type of information, to whom, and how often project related information will be conveyed. This section does not replace the need for the project manager to develop a detail communication plan as part of the project plan. Keep In mind here the project’s obligation: “For all projects that require Department oversight, the lead agency project manager shall submit an agency approved project status report on a monthly basis to the Department.” PROJECT OVERSIGHT PROCESS memorandum 12. INDEPENDENT VERIFICATION AND VALIDATION Reviewer’s question: “Has the project adequately identified the areas appropriate for IV&V for a project of this type and magnitude?” The PROJECT OVERSIGHT PROCESS memorandum states: “Independent verification and validation (IV&V)” means the process of evaluating a project to determine compliance with specified requirements and the process of determining whether the products of a given development phase fulfill the requirements established during the previous stage, both of which are performed by an organization independent of the lead agency.” The project must choose the appropriate concerns for the type and complexity of project. Keep in mind that DoIT reviews the IV&V contracts to make sure that the items chosen by the project fit the objectives and deliverables of the project. Example: A project that wishes to spend dollars on software development must be sure to include some of the related IV&V items covering software development, software testing and the like. IV&V TOPICS FROM WHICH A PROJECT WILL CHOOSE Preparation Workbook for the Project Charter for Certification Page 27 of 42 Exhibit A of the IT Services and IT IV&V templates lists quite a number of items that could be monitored through this IV&V process. It would make sense here to identify the plans for securing IV&V and to list some of the matters that will be asked of the vendor to monitor: EXHIBIT A -SCOPE OF WORK The following Sections contain lists of IV&V activities to be performed by the Contractor. All IV&V activities in Section 2.1 are mandatory IV&V activities that must be performed by the Contractor. Sections 2.2 through 2.12 are mandatory IV&V activities only if checked. IV&V PROJECT MANAGEMENT IV&V PROJECT MANAGEMENT TASK ITEM TASK # TASK DESCRIPTION IV&V Management Plan IM-1 As the first Deliverable the IV&V provider shall develop an IV&V Management Plan. This plan shall describe the activities, personnel, schedule, standards, and methodology for conducting the IV&V reviews. (see Deliverables for more details) Conduct Initial Risk Assessment IM-2 Prepare and deliver an Initial Risk Assessment report on the required activities. Report on status of each activity and on the effectiveness of Project management and whether the Project activities are meeting the objectives set forth by the Project. (see Deliverables for more details) Conduct Initial Review IM-3 Prepare and deliver an Initial IV&V report on the required activities. Report on status of each activity. (see Deliverables for more details) Conduct Periodic Review(s) IM-4 Prepare and deliver a Follow-up IV&V report on the required activities. Report on status of each activity and progress since the previous report. (see Deliverables for more details) Management Briefing IM-5 Prepare and deliver a formal presentation(s) on the status of the IV&V Project. Presented as required, with at least ten (10) business days notice. No more than once a month. (see Deliverables for more details) PLANNING OVERSIGHT PLANNING OVERSIGHT TASK ITEM TASK # TASK DESCRIPTION APPLICABLE (X) Procurement PO-1 Verify the procurement strategy supports State and Federal Project objectives. Preparation Workbook for the Project Charter for Certification Page 28 of 42 PO-2 Review and make recommendations on the solicitation documents relative to their ability to adequately inform potential vendors about Project objectives, requirements, risks, etc. PO-3 Verify the evaluation criteria are consistent with Project objectives and evaluation processes are consistently applied; verify all evaluation criteria are metrics based and clearly articulated within the solicitation documents. PO-4 Verify that the obligations of the vendor, sub-contractors and external staff (terms, conditions, statement of work, requirements, technical standards, performance standards, development milestones, acceptance criteria, delivery dates, etc.) are clearly defined. This includes verifying that performance metrics have been included that will allow tracking of Project performance and progress against criteria set by the State. PO-5 Verify the final contract for the vendor team states that the vendor will participate in the IV&V process, being cooperative for coordination and communication of information. PO-6 Perform ongoing assessment and review of State methodologies used for the feasibility study, verifying it was objective, reasonable, measurable, repeatable, consistent, accurate and verifiable. PO-7 Review and evaluate the PAPD (U)/IAPD (U) documents. Feasibility Study PO-8 Review and evaluate the Cost Benefit Analysis to assess its reasonableness. PROJECT MANAGEMENT PROJECT MANAGEMENT TASK ITEM TASK # TASK DESCRIPTION APPLICABLE (X) PM-1 Assess and recommend improvement, as needed, to assure continuous executive stakeholder buy-in, participation, support and commitment, and that open pathways of communication exist among all stakeholders. Project Sponsorship PM-2 Verify that Governance Board has bought-in to all changes which impact Project objectives, cost, or schedule. Management Assessment PM-3 Verify and assess Project management and organization, verify that lines of reporting and responsibility provide adequate technical and managerial oversight of the Project. Preparation Workbook for the Project Charter for Certification Page 29 of 42 PM-4 Evaluate Project progress, resources, budget, schedules, work flow, and reporting. PM-5 Assess coordination, communication and management to verify agencies and departments are not working independently of one another and following the communication plan. PM-6 Verify that a Project Management Plan is created and being followed. Evaluate the Project management plans and procedures to verify that they are developed, communicated, implemented, monitored and complete. PM-7 Evaluate Project reporting plan and actual Project reports to verify Project status is accurately traced using Project metrics. PM-8 Verify milestones and completion dates are planned, monitored, and met. PM-9 Verify the existence and institutionalization of an appropriate Project issue tracking mechanism that documents issues as they arise, enables communication of issues to proper stakeholders, documents a mitigation strategy as appropriate, and tracks the issue to closure. This should include but is not limited to technical and development efforts. Project Management PM-10 Evaluate the system’s planned life-cycle development methodology or methodologies (waterfall, evolutionary spiral, rapid prototyping, incremental, etc.) to see if they are appropriate for the system being developed. PM-12 Evaluate the Project’s ability and plans to redesign business systems to achieve improvements in critical measures of performance, such as cost, quality, service, and speed. PM-13 Verify that the reengineering plan has the strategy, management backing, resources, skills and incentives necessary for effective change. Business Process Reengineering PM-14 Verify that resistance to change is anticipated and prepared for by using principles of change management at each step (such as excellent communication, participation, incentives) and having the appropriate leadership (executive pressure, vision, and actions) throughout the reengineering process. Risk Management PM-15 Verify that a Project Risk Management Plan is created and being followed. Evaluate the Projects risk management plans and procedures to verify that risks are identified and quantified and that mitigation plans are developed, communicated, implemented, monitored, and complete. Change Management PM-16 Verify that a Change Management Plan is created and being followed. Evaluate the change management plans and procedures to verify they are developed, communicated, implemented, monitored, and complete; and that resistance to change is anticipated and prepared for. Preparation Workbook for the Project Charter for Certification Page 30 of 42 Communication Management PM-17 Verify that a Communication Plan is created and being followed. Evaluate the communication plans and strategies to verify they support communications and work product sharing between all Project stakeholders; and assess if communication plans and strategies are effective, implemented, monitored and complete. PM-18 Review and evaluate the configuration management (CM) plans and procedures associated with the development process. PM-19 Verify that all critical development documents, including but not limited to requirements, design, code and JCL are maintained under an appropriate level of control. PM-20 Verify that the processes and tools are in place to identify code versions and to rebuild system configurations from source code. PM-21 Verify that appropriate source and object libraries are maintained for training, test, and production and that formal sign-off procedures are in place for approving Deliverables. PM-22 Verify that appropriate processes and tools are in place to manage system changes, including formal logging of change requests and the review, prioritization and timely scheduling of maintenance actions. PM-23 Verify that mechanisms are in place to prevent unauthorized changes being made to the system and to prevent authorized changes from being made to the wrong version. Configuration Management PM-24 Review the use of CM information (such as the number and type of corrective maintenance actions over time) in Project management. PM-25 Evaluate and make recommendations on the estimating and scheduling process of the Project to ensure that the Project budget and resources are adequate for the work-breakdown structure and schedule. PM-26 Review schedules to verify that adequate time and resources are assigned for planning, development, review, testing and rework. Project Estimating and Scheduling PM-27 Examine historical data to determine if the Project/department has been able to accurately estimate the time, labor and cost of software development efforts. PM-28 Examine the job assignments, skills, training and experience of the personnel involved in program development to verify that they are adequate for the development task. PM-29 Evaluate the State’s hiring plan for the Project to verify that adequate human resources will be available for development and maintenance. Project Personnel PM-30 Evaluate the State’s personnel policies to verify that staff turnover will be minimized. Preparation Workbook for the Project Charter for Certification Page 31 of 42 PM-31 Verify that lines of reporting and responsibility provide adequate technical and managerial oversight of the Project. Project Organization PM-32 Verify that the Project’s organizational structure supports training, process definition, independent Quality Assurance, Configuration Management, product evaluation, and any other functions critical for the Projects success. PM-33 Evaluate the use of sub-contractors or other external sources of Project staff (such as IS staff from another State organization) in Project development. PM-34 Verify that the obligations of sub-contractors and external staff (terms, conditions, statement of work, requirements, standards, development milestones, acceptance criteria, delivery dates, etc.) are clearly defined. PM-35 Verify that the subcontractors’ software development methodology and product standards are compatible with the system’s standards and environment. PM-36 Verify that the subcontractor has and maintains the required skills, personnel, plans, resources, procedures and standards to meet their commitment. This will include examining the feasibility of any offsite support of the Project Subcontractors and External Staff PM-37 Verify that any proprietary tools used by subcontractors do not restrict the future maintainability, portability, and reusability of the system. PM-38 Verify that State oversight is provided in the form of periodic status reviews and technical interchanges. PM-39 Verify that the State has defined the technical and managerial inputs the subcontractor needs (reviews, approvals, requirements and interface clarifications, etc.) and has the resources to supply them on schedule. State Oversight PM-40 Verify that State staff has the ultimate responsibility for monitoring Project cost and schedule. QUALITY MANAGEMENT QUALITY MANAGEMENT TASK ITEM TASK # TASK DESCRIPTION APPLICABLE (X) QA-1 Evaluate and make recommendations on the Project’s Quality Assurance plans, procedures and organization. Quality Assurance QA-2 Verify that QA has an appropriate level of independence from Project management. Preparation Workbook for the Project Charter for Certification Page 32 of 42 QA-3 Verify that the QA organization monitors the fidelity of all defined processes in all phases of the Project. QA-4 Verify that the quality of all products produced by the Project is monitored by formal reviews and sign-offs. QA-5 Verify that Project self-evaluations are performed and that measures are continually taken to improve the process. QA-6 Monitor the performance of the QA contractor by reviewing its processes and reports and performing spot checks of system documentation; assess findings and performance of the processes and reports. QA-7 Verify that QA has an appropriate level of independence; evaluate and make recommendations on the Project’s Quality Assurance plans, procedures and organization. QA-8 Verify that the QA vendor provides periodic assessment of the CMM activities of the Project and that the Project takes action to reach and maintain CMM Level __. QA-9 Evaluate if appropriate mechanisms are in place for Project selfevaluuatio and process improvement. QA-10 Review and make recommendations on all defined processes and product standards associated with the system development. QA-11 Verify that all major development processes are defined and that the defined and approved processes and standards are followed in development. QA-12 Verify that the processes and standards are compatible with each other and with the system development methodology. Process Definition and Product Standards QA-13 Verify that all process definitions and standards are complete, clear, upttodate, consistent in format, and easily available to Project personnel TRAINING TRAINING TASK ITEM TASK # TASK DESCRIPTION APPLICABLE (X) User Training and Documentation TR-1 Review and make recommendations on the training provided to system users. Verify sufficient knowledge transfer for maintenance and operation of the new system. Preparation Workbook for the Project Charter for Certification Page 33 of 42 TR-2 Verify that training for users is instructor-led and hands-on and is directly related to the business process and required job skills. TR-3 Verify that user-friendly training materials and help desk services are easily available to all users. TR-4 Verify that all necessary policy and process and documentation are easily available to users. TR-5 Verify that all training is given on-time and is evaluated and monitored for effectiveness, with additional training provided as needed. TR-6 Review and make recommendations on the training provided to system developers. TR-7 Verify that developer training is technically adequate, appropriate for the development phase, and available at appropriate times. TR-8 Verify that all necessary policy, process and standards documentation is easily available to developers. Developer Training and Documentation TR-9 Verify that all training is given on-time and is evaluated and monitored for effectiveness, with additional training provided as needed. REQUIREMENTS MANAGEMENT REQUIREMENTS MANAGEMENT TASK ITEM TASK # TASK DESCRIPTION APPLICABLE (X) RM-1 Evaluate and make recommendations on the Project’s process and procedures for managing requirements. RM-2 Verify that system requirements are well-defined, understood and documented. RM-3 Evaluate the allocation of system requirements to hardware and software requirements. RM-4 Verify that software requirements can be traced through design, code and test phases to verify that the system performs as intended and contains no unnecessary software elements. Requirements Management RM-5 Verify that requirements are under formal configuration control. Security Requirements RM-6 Evaluate and make recommendations on Project policies and procedures for ensuring that the system is secure and that the privacy of client data is maintained. Preparation Workbook for the Project Charter for Certification Page 34 of 42 RM-7 Evaluate the Projects restrictions on system and data access. RM-8 Evaluate the Projects security and risk analysis. RM-9 Verify that processes and equipment are in place to back up client and Project data and files and archive them safely at appropriate intervals. RM-10 Verify that an analysis of client, State and federal needs and objectives has been performed to verify that requirements of the system are well understood, well defined, and satisfy federal regulations. RM-11 Verify that all stakeholders have been consulted to the desired functionality of the system, and that users have been involved in prototyping of the user interface. RM-12 Verify that all stakeholders have bought-in to all changes which impact Project objectives, cost, or schedule. RM-13 Verify that performance requirements (e.g. timing, response time and throughput) satisfy user needs Requirements Analysis RM-14 Verify that user’s maintenance requirements for the system are completely specified RM-15 Verify that all system interfaces are exactly described, by medium and by function, including input/output control codes, data format, polarity, range, units, and frequency. Interface Requirements RM-16 Verify those approved interface documents are available and that appropriate relationships (such as interface working groups) are in place with all agencies and organizations supporting the interfaces. RM-17 Verify that all system requirements have been allocated to an either a software or hardware subsystem. Requirements Allocation and Specification RM-18 Verify that requirements specifications have been developed for all hardware and software subsystems in a sufficient level of detail to ensure successful implementation. Reverse Engineering RM-19 If a legacy system or a transfer system is or will be used in development, Verify that a well defined plan and process for reengineering the system is in place and is followed. The process, depending on the goals of the reuse/transfer, may include reverse engineering, code translation, re-documentation, restructuring, normalization, and re-targeting. OPERATING ENVIRONMENT OPERATING ENVIRONMENT TASK ITEM TASK # TASK DESCRIPTION APPLICABLE Preparation Workbook for the Project Charter for Certification Page 35 of 42 (X) OE-1 Evaluate new and existing system hardware configurations to determine if their performance is adequate to meet existing and proposed system requirements. OE-2 Determine if hardware is compatible with the State’s existing processing environment, if it is maintainable, and if it is easily upgradeable. This evaluation will include, but is not limited to CPUs and other processors, memory, network connections and bandwidth, communication controllers, telecommunications systems (LAN/WAN), terminals, printers and storage devices. System Hardware OE-3 Evaluate current and Projected vendor support of the hardware, as well as the State’s hardware configuration management plans and procedures. OE-4 Evaluate new and existing system software to determine if its capabilities are adequate to meet existing and proposed system requirements. OE-5 Determine if the software is compatible with the State’s existing hardware and software environment, if it is maintainable, and if it is easily upgradeable. This evaluation will include, but is not limited to, operating systems, middleware, and network software including communications and file-sharing protocols. System Software OE-6 Current and Projected vendor support of the software will also be evaluated, as well as the States software acquisition plans and procedures. OE-7 Evaluate new and existing database products to determine if their capabilities are adequate to meet existing and proposed system requirements. OE-8 Determine if the database’s data format is easily convertible to other formats, if it supports the addition of new data items, if it is scaleable, if it is easily refreshable and if it is compatible with the State’s existing hardware and software, including any on-line transaction processing (OLTP) environment. Database Software OE-9 Evaluate any current and Projected vendor support of the software, as well as the State’s software acquisition plans and procedures. OE-10 Evaluate the existing processing capacity of the system and verify that it is adequate for current statewide needs for both batch and on-line processing. OE-11 Evaluate the historic availability and reliability of the system including the frequency and criticality of system failure. System Capacity OE-12 Evaluate the results of any volume testing or stress testing. Preparation Workbook for the Project Charter for Certification Page 36 of 42 OE-13 Evaluate any existing measurement and capacity planning program and will evaluate the system’s capacity to support future growth. OE-14 Make recommendations on changes in processing hardware, storage, network systems, operating systems, COTS software, and software design to meet future growth and improve system performance. DEVELOPMENT ENVIRONMENT DEVELOPMENT ENVIRONMENT TASK ITEM TASK # TASK DESCRIPTION APPLICABLE (X) DE-1 Evaluate new and existing development hardware configurations to determine if their performance is adequate to meet the needs of system development. DE-2 Determine if hardware is maintainable, easily upgradeable, and compatible with the State’s existing development and processing environment. This evaluation will include, but is not limited to CPUs and other processors, memory, network connections and bandwidth, communication controllers, telecommunications systems (LAN/WAN), terminals, printers and storage devices. Development Hardware DE-3 Current and Projected vendor support of the hardware will also be evaluated, as well as the State’s hardware configuration management plans and procedures. DE-4 Evaluate new and existing development software to determine if its capabilities are adequate to meet system development requirements. DE-5 Determine if the software is maintainable, easily upgradeable, and compatible with the State’s existing hardware and software environment. DE-6 Evaluate the environment as a whole to see if it shows a degree of integration compatible with good development. This evaluation will include, but is not limited to, operating systems, network software, CASE tools, Project management software, configuration management software, compilers, cross-compilers, linkers, loaders, debuggers, editors, and reporting software. DE-7 Language and compiler selection will be evaluated with regard to portability and reusability (ANSI standard language, non-standard extensions, etc.) Development Software DE-8 Current and Projected vendor support of the software will also be evaluated, as well as the States software acquisition plans and procedures. Preparation Workbook for the Project Charter for Certification Page 37 of 42 SOFTWARE DEVELOPMENT SOFTWARE DEVELOPMENT TASK ITEM TASK # TASK DESCRIPTION APPLICABLE (X) SD-1 Evaluate and make recommendations on existing high level design products to verify the design is workable, efficient, and satisfies all system and system interface requirements. SD-2 Evaluated the design products for adherence to the Project design methodology and standards. SD-3 Evaluate the design and analysis process used to develop the design and make recommendations for improvements. Evaluate design standards, methodology and CASE tools used will be evaluated and make recommendations. SD-4 Verify that design requirements can be traced back to system requirements. High-Level Design SD-5 Verify that all design products are under configuration control and formally approved before detailed design begins. SD-6 Evaluate and make recommendations on existing detailed design products to verify that the design is workable, efficient, and satisfies all high level design requirements. SD-7 The design products will also be evaluated for adherence to the Project design methodology and standards. SD-8 The design and analysis process used to develop the design will be evaluated and recommendations for improvements made. SD-9 Design standards, methodology and CASE tools used will be evaluated and recommendations made. SD-10 Verify that design requirements can be traced back to system requirements and high level design. Detailed Design SD-11 Verify that all design products are under configuration control and formally approved before coding begins. SD-12 Perform an evaluation and make recommendations on existing job control and on the process for designing job control. Job Control SD-13 Evaluate the system’s division between batch and on-line processing with regard to system performance and data integrity. Preparation Workbook for the Project Charter for Certification Page 38 of 42 SD-14 Evaluate batch jobs for appropriate scheduling, timing and internal and external dependencies. SD-15 Evaluate the appropriate use of OS scheduling software. SD-16 Verify that job control language scripts are under an appropriate level of configuration control. SD-17 Evaluate and make recommendations on the standards and process currently in place for code development. SD-18 Evaluate the existing code base for portability and maintainability, taking software metrics including but not limited to modularity, complexity and source and object size. SD-19 Code documentation will be evaluated for quality, completeness (including maintenance history) and accessibility. SD-20 Evaluate the coding standards and guidelines and the Projects compliance with these standards and guidelines. This evaluation will include, but is not limited to, structure, documentation, modularity, naming conventions and format. SD-21 Verify that developed code is kept under appropriate configuration control and is easily accessible by developers. Code SD-22 Evaluate the Project’s use of software metrics in management and quality assurance. SD-23 Evaluate the plans, requirements, environment, tools, and procedures used for unit testing system modules. SD-24 Evaluate the level of test automation, interactive testing and interactive debugging available in the test environment. Unit Test SD-25 Verify that an appropriate level of test coverage is achieved by the test process, that test results are verified, that the correct code configuration has been tested, and that the tests are appropriately documented. SYSTEM AND ACCEPTANCE TESTING SYSTEM AND ACCEPTANCE TESTING TASK ITEM TASK # TASK DESCRIPTION APPLICABLE (X) System Integration Test ST-1 Evaluate the plans, requirements, environment, tools, and procedures used for integration testing of system modules. Preparation Workbook for the Project Charter for Certification Page 39 of 42 ST-2 Evaluate the level of automation and the availability of the system test environment. ST-3 Verify that an appropriate level of test coverage is achieved by the test process, that test results are verified, that the correct code configuration has been tested, and that the tests are appropriately documented, including formal logging of errors found in testing. ST-4 Verify that the test organization has an appropriate level of independence from the development organization. ST-5 Evaluate the plans, requirements, environment, tools, and procedures for pilot testing the system. ST-6 Verify that a sufficient number and type of case scenarios are used to ensure comprehensive but manageable testing and that tests are run in a realistic, real-time environment. ST-7 Verify that test scripts are complete, with step-by-step procedures, required pre-existing events or triggers, and expected results. ST-8 Verify that test results are verified, that the correct code configuration has been used, and that the tests runs are appropriately documented, including formal logging of errors found in testing. Pilot Test ST-9 Verify that the test organization has an appropriate level of independence from the development organization. Interface Testing ST-10 Evaluate interface testing plans and procedures for compliance with industry standards. Acceptance and Turnover ST-11 Acceptance procedures and acceptance criteria for each product must be defined, reviewed, and approved prior to test and the results of the test must be documented. Acceptance procedures must also address the process by which any software product that does not pass acceptance testing will be corrected. ST-12 Verify that appropriate acceptance testing based on the defined acceptance criteria is performed satisfactorily before acceptance of software products. ST-13 Verify that the acceptance test organization has an appropriate level of independence from the subcontractor. ST-14 Verify that training in using the contractor-supplied software is be ongooin throughout the development process, especially If the software is to be turned over to State staff for operation. ST-15 Review and evaluate implementation plan. Preparation Workbook for the Project Charter for Certification Page 40 of 42 DATA MANAGEMENT DATA MANAGEMENT TASK ITEM TASK # TASK DESCRIPTION APPLICABLE (X) Data Conversion DM-1 Evaluate the State’s existing and proposed plans, procedures and software for data conversion. DM-2 Verify that procedures are in place and are being followed to review the completed data for completeness and accuracy and to perform data clean-up as required. DM-3 Determine conversion error rates and if the error rates are manageable. DM-4 Make recommendations on making the conversion process more efficient and on maintaining the integrity of data during the conversion. Database Design DM-5 Evaluate new and existing database designs to determine if they meet existing and proposed system requirements. DM-6 Recommend improvements to existing designs to improve data integrity and system performance. DM-7 Evaluate the design for maintainability, scalability, refreshability, concurrence, normalization (where appropriate) and any other factors affecting performance and data integrity. DM-8 Evaluate the Project’s process for administering the database, including backup, recovery, performance analysis and control of data item creation. OPERATIONS OVERSIGHT OPERATIONS OVERSIGHT TASK ITEM TASK # TASK DESCRIPTION APPLICABLE (X) OO-1 Evaluate statewide system’s change request and defect tracking processes. Operational Change Tracking OO-2 Evaluate implementation of the process activities and request volumes to determine if processes are effective and are being followed. Preparation Workbook for the Project Charter for Certification Page 41 of 42 Customer & User Operational Satisfaction OO-3 Evaluate user satisfaction with system to determine areas for improvement Operational Goals OO-4 Evaluate impact of system on program goals and performance standards. Operational Documentation OO-5 Evaluate operational plans and processes. Operational Processes and Activity OO-6 Evaluate implementation of the process activities including backup, disaster recovery and day-to-day operations to verify the processes are being followed. AN AFTERWORD Project Management is really the art and science of thinking ahead. Project Management is a game of anticipating and putting in place safeguards. A carefully written and well thought out project charter will not only gain the respect of the project sponsor(s) and business owner(s), but will also enable the Project Certification Committee to make an affirmative decision about the project, and avoid contingencies which would require the project to be brought back again for consideration. PROJECT CHARTER TO PROJECT MANAGEMENT PLAN (PMP) This checklist is intended as a roadmap between the project Charter for certification and the Project Management Plan. Charter Area DoIT Project Management Plan areas with section numbers 1. Project Background 1.0 Project Overview 2. Justification, Objectives and Impacts 1.0 Project Overview-Justification ; Objectives Under 3.0 Scope Impacts to Organization should be a separate project document, as should be transition to operations. Preparation Workbook for the Project Charter for Certification Page 42 of 42 3. Project/Product Scope of Work 4.0 Project deliverables and methodology 3.2. Success and Quality Metrics 3.2 Critical Success factors; 6.6 Project Performance Metrics; 6.7 Quality Objectives and Controls; 6.7.4 project deliverable acceptance process 4.. Schedule Estimate 5.1 Work Break Down Schedule; 5.2 Schedule Allocation -Project Time Line 5. Budget Estimate 5.3 Project budget 6. Project Authority and Organization Structure 2.0 Project Authority and Organizational structure; 5.4 Project team; 5.5 staff planning and acquisition 6.5. Project Management Methodology 4.0, Project Deliverables and Methodology; 4.1 project management life cycle; 4.2 product life cycle 7. Constraints 1.3 constraints 8. Dependencies 1.4 Dependencies 9. Assumptions 1.5 Assumptions 10. Significant Risks and Mitigation Strategy 1.7 Initial project Risks identified; 6.1 Risk Management 11. Communication Plan for Executive Reporting 2.3 Communication Plan for Executive Reporting 12. IV&V 6.2 IV&V Plan

Public Domain

views:191

downloads:27

rating:not rated

reviews:0

posted:1/28/2008

language:English