Agile Lean Product Development

PROJECT PLAN

Maryland State Department of Education

Educator Information System (EIS)

Document Revision #: 1.3

Date of Issue: 14 September 2005

Project Manager: Don Morgan

Approval Signatures

Approved by: Business Project Sponsor		Approved by: Technical Project Sponsor
Dr. John Smeallie		Sidney Drake
Prepared by: Business Project Manager		Reviewed by: Project Manager
Don Morgan		Kevin Bronke
Approved by: Business Customer		Reviewed by: Site Manager
Dr. Joann Ericson		Tony Palcher

Table of Contents

61. Document Overview

1.1 Introduction 6

1.2 Purpose 6

1.3 Scope 6

1.4 Overview 6

1.5 Project Plan Review Schedule 7

2. Project Overview 8

2.1 Project Description 8

2.2 Problem Statement 9

2.3 Goals 10

2.4 Project Background 11

2.5 Product Objectives 12

2.6 Assumptions, Constraints and Dependencies 14

2.7 Project Deliverables 15

2.8 Schedule and Budget Summary 17

2.9 Evolution of the Plan 17

2.10 References 18

2.11 Definitions and Acronyms 18

3. Project Organization 19

3.1 External Interfaces 19

3.2 Internal Structure 19

3.3 Roles and Responsibilities 20

4. Managerial Process Plans 23

4.1 Management Priorities 23

4.2 Project Tracking and Control 23

4.2.1 Status Reporting 23

4.2.2 Gate Exits (Project Checkpoints) 24

4.3 Start‑up Plan 24

4.3.1 Estimates 24

4.3.2 Staffing 31

4.3.3 Resource Requirements 31

4.3.4 Resource Acquisition 31

4.3.5 Project Staff Training 32

4.4 Work Plan 32

4.4.1 Work Breakdown Structure 32

4.4.1.1. Summary Work Breakdown Structure 33

4.4.1.2. Project Work Breakdown Structure 33

4.4.1.3. Contract Work Breakdown Structure 33

4.4.1.4. Work Breakdown Structure Dictionary 33

4.4.2 Schedule Allocation 34

4.4.2.1. Project Plan 34

4.4.2.2. Phase Plan 34

4.4.2.3. Iteration Objectives 34

4.4.2.4. Releases 35

4.4.3 Resource Allocation 35

4.4.4 Budget Allocation 35

4.5 Project Monitoring and Control 35

4.5.1 Requirements Management 35

4.5.1.1. Validate Requirements 35

4.5.1.2. Control Change 36

4.5.1.3. Control the Architecture 36

4.5.2 Schedule Control 36

4.5.2.1. Promote Reuse 36

4.5.3 Budget Control 36

4.5.4 Quality Control 37

4.5.4.1. Assign Users Testing Accountability 37

4.5.4.2. Embrace Standards 37

4.5.4.3. Develop and Implement by Release 37

4.5.5 Reporting 38

4.5.5.1. Integrate the Project Team 38

4.5.6 Project Metrics 38

4.5.6.1. Evaluation Criteria 39

4.5.7 Change Control Process 39

4.6 Risk Management Plan 39

4.6.1 Risk Management Categories 39

4.7 Project Closeout Plan 40

5. Technical Process Plans 41

5.1 Process Model 41

5.2 Methods, Tools, and Techniques 44

5.3 Infrastructure 44

5.4 Product Acceptance 44

5.5 Security and Privacy 44

5.5.1 Privacy Issues 44

5.5.2 Computer Security Activities 44

6. Supporting Process Plans 45

6.1 Configuration Management 45

6.2 Verification and Validation 45

6.3 Documentation 46

6.4 Quality Assurance 46

6.5 Reviews and Audits 46

6.6 Problem Resolution 47

6.7 Subcontractor Management 47

6.8 Process Improvement 47

6.9 Communication Process 47

6.9.1 Communication Items 48

6.10 Communication Item 48

6.11 Methods of Communication 48

6.11.1 Communication Protocol 49

6.11.1.1. Meetings 49

6.11.1.2. E-mail 49

7. Additional Plans 51

8. Project Evolution 52

8.1 Project support and maintenance 52

8.2 Follow-up projects 52

Annex A 53

Document Change Control

This section provides control for the development and distribution of revisions to the Project Plan. The Project Plan changes throughout the project life cycle. It is developed at the beginning of the project (immediately following project initiation approval, and in the earliest stages of project planning). The Project Plan provides an ongoing reference for all project stakeholders. The table below includes the revision number (defined within your Documentation Plan Outline), the date of update/issue, the author responsible for the changes, and a brief description of the context and/or scope of the changes in that revision.

Revision Number	Date of Issue	Author(s)	Brief Description of Change
1.0	8/20/04	Project Manager	Initial Creation of Plan
1.1	11/08/04	Project Manager	Update timeline and Identify communication paths
1.2	1/12/05	Project Manager	Flush out deliverables and add the new CIO to the review list
1.3	8/10/05	Project Manager	Revise for submittal to DBM

1. Document Overview

1.1 Introduction

The P Project Management Plan provides a statement of how and when a project's objectives are to be achieved, by showing the major products, milestones, activities and resources required on the project. It is used as a baseline against which to monitor project progress and cost stage by stage. It provides the business case with planned project costs and it identifies the management stages and other major control points.

The Project Management Plan provides an overview of the purpose, scope and objectives of the project for which the Plan has been written, the project assumptions and constraints, a list of project deliverables, a summary of the project schedule and budget, and the plan for evolving the Project Management Plan.

1.2 Purpose

The purpose of the Project Management Plan is to gather all information necessary to control the project. It describes the approach to the development of the software and is the top-level plan generated and used by managers to direct the development effort.

The following people use the Project Management Plan:

· The project manager uses it to plan the project schedule and resource needs, and to track progress against the schedule.

· Project team members use it to understand what they need to do, when they need to do it, and what other activities they are dependent upon.

1.3 Scope

This Project Management Plan describes the overall plan to be used by the Educator Information System (EIS) project, including deployment of the product. The details of the individual iterations will be described in the Iteration Plans. The plans as outlined in this document are based upon the product requirements as defined in the Functional Requirements Document.

1.4 Overview

This Project Management Plan contains the following information:

Project Overview — provides a description of the project's purpose, scope, and objectives.  It also defines the deliverables that the project is expected to deliver.

Project Organization — describes the organizational structure of the project team.

Management Process — explains the estimated cost and schedule, defines the major phases and milestones for the project, and describes how the project will be monitored.

Technical Process — explains the process model, identifies any tools or techniques needed, and what is the acceptance criteria.

Supporting Process — identifies the supporting control documents and processes needed to manage the project.

1.5 Project Plan Review Schedule

This is a living document. The Project staff should review this plan on an agreed upon basis to reflect any changes that are found most effective as measured by indicators. This plan will be reviewed and updated if necessary according to the following schedule:

2. Project Overview

This section of the Project Management Plan provides an overview of the purpose, scope and objectives of the project for which the Plan has been written, the project assumptions and constraints, a list of project deliverables, a summary of the project schedule and budget, and the plan for evolving the Project Management Plan.

2.1 Project Description

The Educator Information System (EIS) Project was created to reengineer, and implement an information system to support, the educator certification processes for the Maryland State Department of Education (MSDE), Division of Certification and Accreditation (C&A).

The product of this project is a Web-based Automated Educator Information System that will allow secured storage, rapid retrieval, and a clear presentation of relevant certification information for evaluation

The Educator Information System (EIS) is a partnership between the Division of Certification and Accreditation and Invoke.

During fiscal year 2001 (FY01), The Maryland State Department of Education - Teacher Certification Division, initiated the Educator Information System (EIS). The EIS is envisioned to become an integrated and comprehensive system designed to automate the educator certification process. The project spans over several fiscal years, Phase I started in January 2001 and is scheduled to be completed by January 2002. Funds for Phase I of the EIS Project were encumbered during FY01. The FY01 outcomes and benefits of Phase I include: web-based technology, sophisticated software, and powerful hardware to significantly improve the speed and quality of the certification process in Maryland. The new educator certification process will include on-line interactivity with certificate holders and local school systems, as well as scanning capabilities to store and retrieve documents. Specifically, the FY01 outcomes and benefits associated with the EIS project can be categorized into six distinct groups: 1.) Current Certification Workflow Analysis, 2.) Requirement Analysis, 3.) Solutions Analysis, 4.) Comprehensive System Design, 5.) Web Site, and 6.) Document Storage. An expanded discussion of each of these is provided below.

1. The Current Certification Workflow Analysis consisted of documenting the current teacher certification processes, sub-processes and roles. This activity was completed during FY01, with the completion of the final MSDE EIS Current Workflow Analysis - Final As-Is Process Model on 30 April 01.

2. As of September 2001 the Requirement Analysis Document is undergoing final review and expected to be completed by mid October 2001. Virtually all of the current and future requirements for the EIS, including that of the Local School Systems (LSS), have been identified and documented. The draft MSDE Teacher Certification Requirements Analysis Educator Information System Functional Requirements (MSDE EIS and LSS Combined) Document was completed on 27 August 01.

3. The Solutions Analysis is well underway and an EIS solution will be selected as a part of Phase I. Specifically, a draft version of the evaluation criteria was completed on 18 April 01. In addition, alternative solutions are in the process of being determined. Subsequently, each alternative will be scored against the evaluation criteria. It's expected that a solution will be selected in late October 2001.

4. The Comprehensive System Design will be completed during Phase 1, by utilizing the Reengineered Business Process design and mapping it to the requirements. It is expected to start in November 2001.

5. The Teacher Certification static web site went live on 19 September 01. Template development as well as the reorganization and expanded definition of the static content were all completed prior to the Go-Live. Dynamic capabilities, including the ability to conduct on-line interactivity with certificate holders and local school systems is underway and will be completed as a part of Phase I.

6. Over 2,000,000 documents will be scanned into the EIS system as a part of EIS Phase I. As of 7 September 01 approximately 1,537,899 documents, (contained in 50,502 folders), had been scanned into the EIS System. In addition, an interim imaging solution was provided to the employees of the Teacher Certification Division which allowed them to access each of these documents, with the ease of a few mouse clicks, at the convenience of their own desk.

2.2 Problem Statement

The EIS is intended to address two major problems; the current architecture has the application running on an HP3000 that will not be supported in 2006, and the processing time, in the current application, for a certification is approximately 9 months.

The perceived weaknesses are that the current process:

· Takes too long from application submission to certificate mailing,

· Requires applicants to request (phone or mail) and receive (mail) an application packet to start the process,

· Does not allow applicants to inform LSSs of their desire to teach in Maryland,

· Labor intensive,

· Does not assign certification cases to specialists in the most efficient manner,

· Requires much handling of paper documents throughout the process,

· Does not store paper documents in a manner that ensures confidentiality,

· Does not allow the rapid retrieval and presentation of all relevant information needed by a specialist to evaluate an application,

· Prints certificates in an inefficient manner,

· Does not provide self-service certificate status information to either applicants, certificate holders, and only a very few LSSs

· Does not allow automated input of teacher test scores or electronic transcripts,

· Does not store data in a way that allows easy integration with other teacher data,

· Does not store data in a way that is easily accessible for analysis to support decision makers,

· Requires repetitive responses from C&A staff to common, simple requests for information, and

· Does not adequately measure process performance.

2.3 Goals

The main goals of the Educator Information System (EIS) are to:

· Decrease the time from application submission to certificate mailing,

· Allow applicants to inform LSSs of their desire to teach in Maryland,

· Less labor intensive,

· Assign certification cases to specialists in the most efficient manner,

· Decrease the handling of paper documents throughout the process,

· Store application and records in a manner that ensures confidentiality,

· Rapid retrieval and presentation of all relevant information needed by a specialist to evaluate an application,

· Print certificates in an efficient manner,

· Provide self-service certificate status information to all authorized applicants, certificate holders, and LSS employees,

· Automated input of teacher test scores or electronic transcripts,

· Store data in a way that allows easy integration with other teacher data,

· Store data in a way that is easily accessible for analysis to support decision makers,

· Reduce repetitive responses from C&A staff to common, simple requests for information, and measure process performance.

2.4 Project Background

Education professionals in Maryland public schools and in approved schools operated by state agencies are required to hold the appropriate Maryland State Department of Education (MSDE) certificate. Nonpublic school personnel and prospective professionals may also be issued an appropriate certificate.

The MSDE Certification Branch of C&A, which was formed in 1981, is responsible for certifying Educators, Evaluators, and administrators employed in public and private schools, other state institutions and the general public.

In order to properly align the current MSDE educator certification process with the stated goal of providing quality teachers to the classroom, the information system sought to support the educator certification process should assist in:

· Decreasing the current 18 week processing time,

· Actively referring teachers to existing job openings,

· Providing Local School Systems (LSS) efficient, direct access to the certification information they need to make hiring decisions, evaluate teacher quality, assess recruiting and hiring policies, and project future needs, and

· Providing adequate customer services.

Each month C&A processes 1,600 certification applications, 800 pieces of correspondence, and 3,000 phone queries (Figure 1). All contacts are logged, and must be responded to. Incoming correspondence is sorted and routed by type. Submitted application packets are reviewed for completeness. Incomplete packets are returned. Fees are posted and deposited. Complete applications are assigned to certification specialists on a first-come, first-serve basis. Specialists review the submitted application. The disposition of the review are recorded in the documentation, and passed to data entry staff. The disposition triggers one of several form letters to be generated. If a certificate is to be awarded, it is added to a batch of certificates that are printed each Monday. C&A staff checks the printed certificates for accuracy and proper alignment and mail them to the certified educators.

Each November, MSDE’s Division of Planning, Results and Information Management (PRIM) collects information from twenty-four local school systems on all full and part-time personnel employed as of October 15 of the year. Based on the information received, MSDE publishes summary data in various publications, including Analysis of Professional Salaries; Characteristics of Professional Staff; Staff Employed at School and Central Office; and Professional Staff by Assignment, Race/Ethnicity and Gender.

These four reports are distributed to federal and state educational agencies, local school systems, research organizations and the public.

Examples of Staff data to be reported includes: name, gender, ethnicity, contract months, salary, budget, staff who are on the payroll actively employed (or on a leave of absence) as of October 15 of the year, certificate/professional staff who resigned or left the school system the previous year, contractual personnel with a contract of one school year or more; and long-term substitute teachers who have taught continuously for more than one school year.

MSDE has completed Phase I of the EIS Project. The Phase I activities included business process reengineering and requirements analysis, scanning of the existing 2.6 million paper certification case documents into browser-accessible PDF files, and web-enabling access to existing legacy certification information (http://certification.msde.state.md.us).

Figure 1

2.5 Product Objectives

1. Improved process design. The new process model for the Educator Certification Process is designed to minimize processing time by using strategies such as: using technology to automate many tasks, simplifying processes, removing redundant tasks, removing tasks without outputs, reducing transfer time between tasks, and increasing the number of tasks that can be accomplished in parallel.

2. Improved information gathering. The new process should be more efficient because document gathering will be aided by technology. Applications will be completed online using a web browser over the Internet. Paper applications will be scanned, reducing paper handling. Test scores will be sent to MSDE in electronic form and easily imported into the database. All relevant correspondence will be scanned to simplify filing and speed later retrieval. Student transcripts can be requested online on the Internet, and sent to MSDE electronically by participating institutions, using Electronic Data Interchange (EDI) technology.

3. Improved certification evaluation system. The current process requires retrieval of the case file for the application being evaluated, and a thorough review of the file contents by specialists, to reach a disposition. The new system should allow specialists to retrieve those documents electronically and view images of any of them on their computer, as well as any data already in the database. Electronic checklists will aid the specialist during the evaluation process.

4. Improved output generation system. As specialists post the results of their evaluations in the certification database, this will trigger the generation of appropriate output. Disposition letters will automatically be generated, as well as certificates for successful applicants. Certificates can be produced as mailers that can be taken off the printer and placed directly into postal bins. Applications can be electronically referred to participating LSSs to trigger their recruitment processes. The certification database can be used as the source for any number of reports, tables, or graphs, distributed by email or website.

5. Improved customer service. Customer service will be improved by using the Web to make services and information available to customers for 24x7 self-service. This will reduce the volume of repetitive requests for frequently asked questions, leaving customer service and specialist staff available for higher level customer service and other tasks. Technologies that will be used include the enhanced certification website that continues to provide basic certification information, but also allow applicants to apply online, or download an application online. Applicants can check their application status at the site at any time to see if all the needed supporting documents have been received at MSDE. The Applicants will be able to request transcripts from participating institutions be sent to MSDE, and that MSDE refer their information to LSSs to trigger the LSS recruitment process.

6. Improved access to information. The information in the new certification database will be made accessible to those who require it using the Web and other methods. The certification website will provide a query capability for use by applicants and LSS administrators. Based on authenticated identity and role, the user will be provided with any appropriate certification information for an individual. Standard certification statistics will be made available to the general public on the website. Authorized MSDE staff will be able to access information from the new Certification database system using standard displays, reports, and graphs. Certification information will be loaded into the MSDE Education Data Warehouse to enable historical trend analysis. MSDE analysts will be able to use off the shelf data access tools against the Certification database and the data warehouse for ad hoc, point-and-click analysis, reports, graphs, and export files.

7. Improved information management. The new system will be able to electronically store and present all information related to a certification case. All documents and data will be indexed by applicant ID and name to allow rapid retrieval. Security will be improved by: destroying paper documents once scanned; by limiting access to electronic data by user login and password or digital certificates; by limiting access to the level of information users can view; and eliminating dialup modems. Data reliability will be improved by only handling documents once, by the reduction of paper documents, and by the periodic backup of all certification information, all of which will reduce missing or duplicate information. Storing the information in a modern database management system will allow easy integration with other modern databases, such as the Staff Database component of the Education Data Warehouse, as well as improve performance

8. Improved workflow management. The new process will be supported by an automated workflow management system. The system will aid the certification process by: automatically triggering events based on predefined conditions (e.g., sending an email to an applicant when a document is received), routing documents to appropriate individuals, checking electronic case files in and out of the repository, automatically launching applications needed to accomplish tasks, providing automated checklists for each task in the process, automation of tasks (sending emails, generating letters, etc.), event notification (e.g., notify manager when workloads exceed a predefined limit), monitoring the process (current and future workloads measures, process status information), and user activity logging (for accountability and performance measures). Implementing the workflow management system will institutionalize the implementation of the new optimized process design; improve communication; provide the flexibility and power to implement future process improvements; and will take the accumulated knowledge of the process participants, embed it in the process, and expose that information to all current and future participants.

2.6 Assumptions, Constraints and Dependencies

Assumption: Ad-hoc Reporting Tool will be selected and procured

It is assumed that the selected ad-hoc reporting software tool will be procured and installed on the server of for use by the report writing personnel, and that these users will be trained in this application prior to their using the software.

Dependency: Security Approval

Since EIS will contain privacy data, a Computer Security and Privacy Plan (CSPP) must be developed before complete implementing of the system. The plan must be submitted to the security officer. There will be a need to schedule annual security reviews and security refresher training.

Assumption: Administrative Support

It is assumed that there will be adequate administrative support for the development, production, and distribution of work products, etc.

Constraint: This is a fixed price contract

Assumption: ???

Assumption: ???

Assumption: ???

Assumption: ???

Assumption: ???

2.7 Project Deliverables

· Deliverable 1: Project Plan (Microsoft Project 2002)

· Deliverable 2: Presentation of the Project Plan to Project Steering Committee at the MSDE site.

· Deliverable 3: Periodic status reports and meetings as specified in Scope of Services

· Deliverable 4: Revised Process Model (Microsoft Visual Studio.NET).

· Deliverable 5: Revised Logical and Physical Entity Relationship Diagrams (Microsoft Visual Studio.NET)

· Deliverable 6: List and description of required documents and reports (Microsoft Excel 2000)

· Deliverable 7: List of critical system functions and performance standards (Microsoft Excel 2000)

· Deliverable 8: Hardware and system software requirements document (Microsoft Word 2000)

· Deliverable 9: Requirements Specification Document (Microsoft Word 2000), with walkthrough.

· Deliverable 10: IT Architecture Design Specification (Microsoft Visio 2002), with walkthrough. Must include diagrams and descriptions of all hardware and software component configurations for the development and production environments. Must include a discussion of all architecture issues and risks.

· Deliverable 11: Revised Logical and Physical Data Model (Microsoft Visual Studio.NET)

· Deliverable 12: Report Formats (Microsoft Word 2000)

· Deliverable 13: User Interface Models (Microsoft Visual Studio.NET or Actual), with walkthrough.

· Deliverable 14: Document Management Information Architecture Design (Microsoft Word 2000)

· Deliverable 15: Interface Diagrams and Descriptions (Microsoft Word 2000)

· Deliverable 16: Legacy Data Migration Map (Microsoft Excel 2000) and Plan (Microsoft Word 2000)

· Deliverable 17: System Implementation Plan (Microsoft Word 2000), with walkthrough.

· Deliverable 18: System Testing Plan (Microsoft Word 2000)

· Deliverable 19: System Training Plan (Microsoft Word 2000)

· Deliverable 20: System Documentation Plan (Microsoft Word 2000)

· Deliverable 21: Development Environment Readiness Certificate (Email message to MSDE Project Manager)

· Deliverable 22: Production Environment Specifications and Configuration Manual (Microsoft Word 2000)

· Deliverable 23: Production Environment Technical Support Service Level Agreement (Microsoft Word 2000)

· Deliverable 24: Release 1 Software Components (CD-ROM)

· Deliverable 25: Release 1 SQL Server Backup of Imported Source Data (DLT Tape)

· Deliverable 26: Release 1 Alpha Test Results Documentation (Microsoft Excel 2000)

· Deliverable 27: Release 1 Systems Documentation (Online, integrated with Deliverable 25)

· Deliverable 28: Release 1 System Training (Instructor-led at MSDE site)

· Deliverable 29: Release 2 Software Components (CD-ROM)

· Deliverable 30: Release 2 Backup of Imported Document Management Repository (DLT Tape)

· Deliverable 31: Release 2 Alpha Test Results Documentation (Microsoft Excel 2000)

· Deliverable 32: Release 2 Systems Documentation (Online, integrated with Deliverable 30)

· Deliverable 33: Release 2 System Training (Instructor-led at MSDE and CAP sites)

· Deliverable 34: Release 2 CAP LSS Site Scanning Readiness Certificates (Email to MSDE Project Manager)

· Deliverable 35: Release 3 Software Components (CD-ROM)

· Deliverable 36: Release 3 Alpha Test Results Documentation (Microsoft Excel 2000)

· Deliverable 37: Release 3 Systems Documentation (Online, integrated with Deliverable 35)

· Deliverable 38: Release 3 System Training (Instructor-led at MSDE site)

· Deliverable 39: Release 4 Software Components (CD-ROM)

· Deliverable 40: Release 4 Alpha Test Results Documentation (Microsoft Excel 2000)

· Deliverable 41: Release 4 Systems Documentation (Online, integrated with Deliverable 39)

· Deliverable 42: Release 4 System Training (Instructor-led at MSDE site)

· Deliverable 47: Transition documentation (Microsoft Word 2000)

· Deliverable 48: Post-implementation Support Service Level Agreement (Microsoft Word 2000)

2.8 Schedule and Budget Summary

· The projected budget for Phase II is $2,079,945.00 with a reoccurring years cost of $131,500.00.

· The project is broken into 4 releases with a start date of January 01 2004 and a projected completion date of January 01 2006.

2.9 Evolution of the Plan

The Project Management Plan will be revised prior to the start of each Iteration phase.

The structure of this Project Plan is in compliance with the recommendations of IEEE STD 1058‑1998.

Version	Primary Author(s)	Description of Version	Date Expected
Draft	Project manager	Initial draft created for distribution and review comments	8/20/04
Revision 1	TBD	Revised draft, revised according to the change control process and maintained under change control	TBD
Revision 2	TBD	Revised draft, revised according to the change control process and maintained under change control	TBD
Revision 3	TBD	Revised draft, revised according to the change control process and maintained under change control	TBD
Preliminary	Project manager	Second draft incorporating initial review comments, distributed for final review	TBD
Final	Project manager	First complete draft, which is placed under change control	TBD

2.10 References

Previous activities that influenced the decision to develop a new application to support the C&A personnel needs are recorded in the following documents:

· Current workflow Diagrams

· Data Model.

· System Architecture.

· Process Models.

2.11 Definitions and Acronyms

This section provides a glossary of all terms and abbreviations used in the plan.

3. Project Organization

3.1 External Interfaces

The following chart indicates direct reporting or communication relationships. Dotted lines indicate an expectation between groups, to effectively coordinate and communicate work and share knowledge.

3.2 Internal Structure

The following chart defines the project team for the EIS project. The historical experience and stakeholder needs were used to determine which functional areas should participate in the project.

Project Team
Core Team	Extended Project Team	Approvers
Project Manager	Project Manager	Project Manager
Business Sponsor	Business Sponsor	Business Sponsor
Technical Sponsor	Technical Sponsor	Technical Sponsor
Site Manager	Site Manager	Quality Assurance Manager
C&A Branch Chief	C&A Branch Chief
	Vendor Project Manager
	Vendor Technical Lead

3.3 Roles and Responsibilities

The following chart defines the roles and responsibilities of the members of the project team and their function at stage exit.

Note: Due to staffing fluctuations, if a particular person is unable to fulfill his/her responsibilities, it will be the responsibility of the manager overseeing that area to ensure a replacement, with appropriate skills and experience, on a timely basis.

Responsibility	Individual(s) Responsible	Function
Overall Project Management	TBD
Engineering Management	TBD
Quality Assurance Management	TBD
End-User Documentation Management	TBD
Requirements Development	TBD
Software Architecture	TBD
Technical Self-Reviews	TBD
Verifies developers' understanding of the application purpose and design.	TBD
Has overall responsibility and accountability for system and data.	TBD
Helps resolve conflict	TBD
Acts as the single point of contact for approving project deliverables and changes.	TBD
Reviews project deliverables.	TBD
Represents the field's interests and ensures that the organization's information needs are met.	TBD
Reviews and approves project deliverables from QA perspective.	TBD
Reviews plans and deliverables for compliance with applicable standards.	TBD
Provides guidance and assistance on process matters	TBD
Responsible for daily planning and control of the project.	TBD
Prepares and administers project plans.	TBD
Tracks and reports progress.	TBD
Provides support and guidance to the project manager and team.	TBD
Ensures project staffing.	TBD
Resolves conflict across organizations.	TBD
Facilitates communications	TBD
Reviews data model and assists in interviewing.	TBD
Acts as primary author of design document	TBD
Designs user interface for the application.	TBD
Assists the Designer/Programmer in writing programs	TBD
Prepares the Configuration Management Plan.	TBD
Conducts testing of the application at all stages of development	TBD
Evaluates the application for overall operability and ease of user interface at acceptance.	TBD
Writes the user and programmer manuals	TBD
Assists in the development of the Training Plan.	TBD
Provides internal consulting, testing, and support	TBD
Provides guidance in the development of the Computer Security Protection Plan	TBD
Coordinates resolution of issues.	TBD
Manages and coordinates technical effort.	TBD
Performs adequate and timely staffing.	TBD
Provides regular and timely communications	TBD
Trains EIS users	TBD
Handles configuration management activities	TBD
Acts as primary author of Design document.	TBD
Writes or delegates the writing of all programs related to the application	TBD

4. Managerial Process Plans

This section of the Project Management Plan specifies the project management processes for the project. This section defines the plans for project start‑up, risk management, project work, project tracking and project close‑out.

4.1 Management Priorities tc "3.1 Management Priorities " \l 2

The EIS project will provide a critical component of the C&A division's application set, allowing it to provide the highest possible level of support to all of its clients - both internal and external to the branch. The highest EIS priority is to develop a product that meets all of the user's requirements. This is followed closely by delivery of the system on the date planned. The third priority is an application that is flexible in allowing for future expansion. The EIS development team is committed to meeting these priorities, as well as the overall project objectives.

The sections below address the project management activities that will help meet these priorities and the project's objectives. This includes how project progress will be tracked and reported, how problems will be addressed and resolved, and certain assumptions and dependencies that are key to the project's success.

4.2 Project Tracking and Control tc "3.2 Project Tracking and Control " \l 2

The project schedule will be laid out in detail in the weekly status report. This is where actual completions are tracked against what was planned. If problems are encountered in the development of the project, they will be reported in a problem/issue Log. This log will consist of a problem description, date the problem was reported, person who reported the problem, person who owns the problem, the resolution, and date the problem was resolved. This log will be maintained by the project manager and used for project status discussions.

4.2.1 Status Reporting tc "3.2.1 Status Reporting " \l 3

As required

Since the Invoke development team is located outside the office building, they will meet informally as needed throughout the project to coordinate work assignments and plan upcoming work.

Weekly

The sr. project manager will update the status report on a weekly basis to provide the approvers information about recent completions, accomplishments, and effort expended. The project manager will discuss the progress of the EIS project every other week at the internal core project status meeting between the project sponsor, the site manager, and the executive stakeholder. The technical project manager will discuss the progress with the extended project team on the opposite week and that meeting will include development team lead, the project sponsor, the site manager, the executive stakeholder, and the sr. project manager. The development team will also meet weekly to discuss internal problems and issues.

In addition to these weekly means of reporting status, the sr. project manager will be available to answer questions about the progress of the application at any point in the development cycle.

Monthly

All of the above information will be summarized in the Technical Status Report (TSR). The TSR is the official reporting mechanism for the MSDE. It is prepared monthly, and is distributed to DBM via the CIO.

4.2.2 Gate Exits (Project Checkpointstc "3.2.2 Stage Exits (Project Checkpoints " \l 3)

Each stage of the project will conclude with a formal checkpoint called a gate. When a gate has been successfully "exited", it indicates that all deliverables due to date have been completed, all outstanding issues have an acceptable action plan, and there is a sound plan for the remainder of the project (detailed for the next gate). The project's designated approvers (sign-off authorities) must provide a written position of concur/non-concur at gate exit. All affected functional areas involved in the project also participate in and provide input to the stage exit.

4.3 Start‑up Plan

4.3.1 Estimates

4.3.1.1. Size Estimates

Estimates for the EIS effort were determined by analyzing the project requirements that are known to date. This includes the current project objectives and information gathered during interviews conducted with various future users of the proposed EIS application.

For this project both the Function Point estimating methodology and the Lines of Code (LOC) estimating methodology were considered. Both are valid and accepted methods of estimating size of effort for software projects. The Function Point method was identified as most appropriate for this project.

The size estimate will be revisited in the Analysis stage, after more detailed requirements become available.

4.3.1.2. Time Estimates tc "3.5.2 Time Estimates " \l 3

The size estimates were used to project time required for this project, based on skill/experience levels as defined in the Staffing Plan section. They will also be provided to the functional areas, along with the known requirements, to support them in estimating their activities for the project. This includes documentation, testing, and training.

The estimates received from the functional areas, when added to the base project estimates produce a total project expenditure of 16,640 FTE hours required to produce the EIS application. This figure was validated using MS Project. To ensure all project activities are accounted for, all estimates were mapped to the activities detail in the WBS.

The resulting resource allocation chart represents a best effort to achieve a combination of optimum resource utilization and early project delivery. At the completion of the analysis stage of the project, the estimate of total person hours will be updated and the target completion date will be validated.

4.3.2 Staffing Plan tc "3.6 Staffing Plan " \l 2

A variety of resources and skills will be required to complete the EIS project. The staff for this project will need to possess the following skill sets: project management, project planning, systems design, systems analysis, programming, testing, acceptance testing, documentation, network engineering, configuration management, and training. Below are descriptions of the positions that need to be filled.

4.3.2.1. Required Skills tc "3.6.1 Required Skills " \l 3

The Project Manager must have demonstrated the ability to plan development tasks, coordinate activities among various groups, coordinate the flow of work, conduct project meetings, and ensure issue resolution. This position needs very little supervision. Must be capable of developing a project plan using a bottoms-up approach. This person must be able to coordinate the activities of several persons who will provide the WBS detail, project estimates, and dependencies. This person must be able to work closely with the project sponsors on resolving issues and concerns across organizations.

The Business Analyst must be capable of interviewing end-users, capturing user wants and needs and translating them into system requirements. This person must also be able to perform an analysis of the requirements and develop a conceptual system architecture.

The Designer/Programmer must be able to produce the Design Specification document and program an application, using Microsoft .Net, based on the Requirements Specification document and the Design document. This position needs very little supervision. The Designer/Programmer is responsible for delegating program assignments to the Programmer.

The Programmer must be able to program and unit test specific modules of an application using Microsoft .Net and using the Design Specification document. This position needs to take direction from the Designer/Programmer.

The Independent Tester must be able to review the Requirements Specification document and the Design document to determine testability of functions described therein. The Tester must be able to design and execute a System Integration plan and a System Test Plan based on the Requirements Specification document. This position will work independently from the development team to ensure an objective review of the products as they are being delivered.

The Network Engineer must be able to document requirements for the system to be installed on the agency network, install the application on the EIS Servers, and write and execute a test plan which will determine adherence to network response time standards for the EIS system.

The Documentation Specialist must be able to write the EIS User Manual in a Windows-based word processing package. This person must be able to execute the application in order to capture screens for placement into the manual. The Documentation Specialist must be able to create the User Manual with little supervision from the Project Manager/Analyst.

The Trainer must be able, based on knowledge gained in the study of the EIS User Manual, to prepare and execute a Training Plan for approximately 100 users of the EIS application. The Trainer must know how to use the application. The development team as needed should assist the Trainer.

The Configuration Manager must be able to write a Configuration Management Plan (CMP), which identifies the project items that will be placed under formal change management and the method by which change against these items will be managed. This person must also be able to execute the CMP, managing all changes from the Design through Installation stages.

The Acceptance Tester must test the application separately from the development team, as an advisor to the client. This person must utilize the EIS User Manual to determine if all the processes in the application are functioning correctly according to that manual, and principles of user friendliness. This person will perform his or her duties with very little assistance from the development team in order to maintain objectivity.

4.3.2.2. Resource Loading Chart tc "3.6.2 Resource Loading Chart " \l 3

Refer to the chart in the MS Project to show the estimated hours required by month for each person on the project.

The project resources will ramp up as the project moves forward from analysis and requirements activities (February/March), to design activities (May/June), and wind down with the transition from programming and testing to pre-acceptance and acceptance activities (March/April).

Some resource leveling was performed in order to find a balance between optimizing usage of human and material resources and the project schedule.

4.3.3 Resource Requirements

All partners will contribute toward accomplishment of the project goals and deliverables. The chart below describes the resource requirements necessary to accomplish the project goals and who is responsible for providing these resources.

Deliverable	Tasks Necessary to Accomplish the Deliverable	Resources Provided by	Resources Provided by	Resources Provided by

4.3.4 Resource Acquisition

Refer to the Project Acquisition Document (GGG-HHH-X.Y.doc) for detailed information.

4.3.5 Project Staff Training

· User Acceptance Testing.

· Test Case Creation.

· Cognos Reporting tool.

4.4 Work Plan

4.4.1 Work Breakdown Structure

This section describes the WBS’s required for the project. The WBS is a family-tree structure that relates to products produced and tasks performed at the various phases of the project life cycle. A WBS displays and defines the product(s) to be developed or produced and relates the elements of work~ (tasks) to be accomplished to each other and to the end product(s).

Typically, three levels of WBS’s are developed during the system development process Summary, Project, and Contract. A WBS Dictionary is also helpful for creating and recording the WBS elements.

· The WBS will be decomposed to a level that exposes all project risk factors, and that allows accurate estimation of resource requirements and schedule duration for each work activity.

· The level of decomposition internally within the WBS may vary depending on the quality of the requirements, familiarity of the work, applicable level of technology, etc.

4.4.1.1. Summary Work Breakdown Structure

Need the first three levels of the Project WBS.

4.4.1.2. Project Work Breakdown Structure

Refer to the Project Schedule (MMM-NNN-X.Y.doc) for detailed information.

4.4.1.3. Contract Work Breakdown Structure

The Contract WBS (CWBS) will be combined with the Project WBS. Depending on the nature of the project, the contractor may be responsible for a given part of the project development activities (such as QA), for a specific part of the development life cycle (such as the Requirements Definition phase), or for the entire development process.

4.4.1.4. Work Breakdown Structure Dictionary

A WBS Dictionary provides detailed descriptions of each WBS element. Each WBS Dictionary entry should contain a title that is the same as the WBS element it amplifies; a narrative describing the work represented by the element; the effort required (in person hours); the most likely duration (in calendar days); and references to any special skills or resources required to accomplish the work. WBS Dictionary entries should be completed only for the lowest-level WBS elements. This project will not create a WBS Dictionary.

4.4.2 Schedule Allocation

· Identify the critical path in the schedule.

· Identify appropriate schedule milestones to assess the scope and quality of project work products and of project achievement status.

4.4.2.1. Project Plan

[This section contains the schedule and resources for the project.]

4.4.2.2. Phase Plan

[Include the following:

· a Gantt chart showing the allocation of time to the project phases (Not necessarily detailed to the activity level; this type of Gantt Chart is providing along with the Iteration Plans themselves; Provide an Overview of the project Timeline with the major miles stones]

· identify major milestones with their achievement criteria

Define any important release points and demos.]

[If available, refer to the related Iteration Plan Documents for more details]

Milestone	Target Date
Project Plan Accepted	January 2004
System Requirements Specification Accepted	March 2004
System Designs & Implementation Plans Accepted	May 2004
IT Architectures Implemented	June 2004
System Releases Implemented and Accepted	February 2005
Post-Implementation Support Delivered	December 2006

4.4.2.3. Iteration Objectives

[Briefly list the objectives to be accomplished for each of the iterations and Refer to the related Iteration Plan Documents for more details.]

4.4.2.4. Releases

[A brief description of each software release and whether it’s demo, beta, and so on.]

4.4.3 Resource Allocation

· Provide a detailed itemization of the resources allocated to each major work activity in the project WBS.

· Specify the numbers and required skill levels of personnel for each work activity.

· Specify, as appropriate, the allocation of the following resources:

· personnel (by skill level),

· computing resources

· software tools

· special testing and simulation facilities, and

· Administrative support.

· Use a separate line item for each type of resource for each work activity.

4.4.4 Budget Allocation

· Provide a detailed breakdown of the necessary resource budgets for each of the major work activities in the WBS.

· Specify the estimated cost for activity personnel, and include as appropriate, the costs for the following items:

· travel,

· meetings,

· computing resources,

· software tools,

· special testing and simulation facilities, and

· Administrative support.

· Use a separate line item for each type of resource in each activity budget.

4.5 Project Monitoring and Control

MSDE will execute the following strategies to manage the performance of the EIS Phase II Project:

4.5.1 Requirements Management

The requirements for this system are captured in the Software Requirement Specification document. Requested changes to requirements are captured in Change Requests, and are approved as part of the Configuration Management process.

4.5.1.1. Validate Requirements

To ensure that MSDE and the contractor have a common understanding of the scope and nature of the undertaking, the first project activity will be a review and validation of the requirements. Any improvement opportunities identified by the contractor can be proposed as changes, and handled through the project change control process.

4.5.1.2. Control Change

MSDE will manage a change control process to ensure that project scope changes provide net benefits, are funded, and planned. The contractor should not implement, and MSDE will not pay for, functions outside the approved project scope.

4.5.1.3. Control the Architecture

The IT architecture for this project will be consistent with the MSDE CIO’s target enterprise architecture, reducing the technology risk associated with the project, thereby mitigating the inherent risks associated with massive business process change. MSDE has demonstrated the competencies to operate the technologies contained in the MSDE target enterprise architecture. Alignment with the MSDE target architecture is one of the service contract proposal evaluation criteria.

4.5.2 Schedule Control

· Specify the schedule control activities by identifying the processes to be used for the following purposes:

· to measure the progress of work completed at the major and minor project milestones,

· to compare actual progress to planned progress, and

· To implement corrective action when actual progress does not conform to planned progress.

· Specify the methods and tools that will be used to measure and control schedule progress.

· Identify the objective criteria that will be used to measure the scope and quality of work completed at each milestone, and hence to assess the achievement of each schedule milestone.

4.5.2.1. Promote Reuse

MSDE will favorably view solution components that can be reused in other MSDE IT solutions, or even adopted as architectural components. Examples include the document management, portal, workflow, external system interface, and other software components of EIS.

4.5.3 Budget Control

· Specify the budget control activities by identifying the processes to be used for the following purposes:

· to measure the cost of work completed,

· to compare the actual cost to the planned and budgeted costs, and

· To implement corrective action when the actual cost does not conform to the budgeted cost.

· Specify when cost reporting will be done in the project schedule.

· Specify the methods and tools that will be used to track the project cost.

· Identify the schedule milestones and objective indicators that will be used to assess the scope and quality of the work completed at those milestones.

· Specify the use of a mechanism such as earned value tracking to report the budget and schedule plan, schedule progress, and the cost of work completed.

4.5.4 Quality Control

Defects will be recorded and tracked as Change Requests, and defect metrics will be gathered (see Reporting and Measurement below).

All deliverables are required to go through the appropriate review process, as described in the Development Case. The review is required to ensure that each deliverable is of acceptable quality, using guidelines and checklists.

Any defects found during review which are not corrected prior to releasing for integration must be captured as Change Requests so that they are not forgotten.

4.5.4.1. Assign Users Testing Accountability

C&A staff will be the final judges as to whether the deliverables meet the defined requirements. The MSDE Office of IT (OIT) will not accept any project deliverables, but will co-sign on infrastructure deliverables, and provide quality assurance consulting throughout.

4.5.4.2. Embrace Standards

MSDE will always favor “good enough” industry standard technologies over “best-of-breed” proprietary technologies. This strategy provides better opportunities for integration and adaptability, reduces project risk, is more cost effective, and matches MSDE’s technology adoption profile (mainstream rather than early adopter).

4.5.4.3. Develop and Implement by Release

While the EIS system design will be comprehensive, the contractor will build, test, and implement the system in phases, called releases. The release strategy is designed to:

· reduce the overall project risk by breaking down the project into smaller related sets of functions (and their deliverables),

· prioritize the development efforts to produce legacy functions first, new customer-oriented functions next, followed by new administrative functions, and

· Establish the dependencies that exist between functions.

The contractor will develop and implement releases in numerical sequence. All functional components comprising each of the releases shall be completed before the release is determined to be complete. Acceptance testing will be performed on complete releases.

4.5.5 Reporting

Updated schedule estimates, and metrics summary reports, will be generated at the end of each iteration.

The Minimal Set of Metrics, as described in the RUP Guidelines: Metrics will be gathered on a weekly basis. These include:

· Earned value for completed tasks. This is used to re-estimate the schedule and budget for the remainder of the project, and/or to identify need for scope changes.

· Total defects open and closed – shown as a trend graph. This is used to help estimate the effort remaining to correct defects.

· Acceptance test cases passing – shown as a trend graph. This is used to demonstrate progress to stakeholders.

Refer to the Project Measurements Document (AAA-BBB-X.Y.doc) for detailed information.

4.5.5.1. Integrate the Project Team

MSDE’s project team includes co-sponsorship by the Chief of Information Technology and Assistant Superintendent for Certification and Accreditation to demonstrate to all participants the importance of the project to the organization. The project team includes formal membership from both C&A and the Office of IT, and is led by a full-time professional project manager. This approach has proven successful in prior MSDE IT projects, including EIS Phase I. Because this project is classified as a Maryland Major IT Project, the Department of Budget & Management’s Office of IT, as well as the MSDE IT Steering Committee, will be monitoring project performance.

4.5.6 Project Metrics

While the estimating and scheduling activities are going on, assign members of the planning team to identify and document standards and procedures for the project team. These standards and procedures may already be in place Agency-wide, but, if not, they should be discovered and/or determined now. These include technical standards, business-related standards, and QA standards. Technical standards and procedures include such things as naming conventions, walk-through requirements, CM rules, security standards, documentation requirements, tools, modeling techniques, and technical contractual obligations. Business-related standards and procedures include such things as procedures for scope changes, requirements changes, costing, earned value implementation, and sign-off standards. QA standards and procedures include such things as review processes, testing procedures, and defect tracking requirements. QA may also provide standards on the use of metrics.

4.5.6.1. Evaluation Criteria

The EIS project will be successfully completed when:

1) All deliverables have been accepted,

2) All MSDE project assets have been accounted for,

3) All contractors have received final payment,

4) All project objectives have been met, including:

· Certification application processing time has been reduced to 10 working days or less,

· More than 50% of educators apply or renew certifications electronically,

· Certification operating costs are reduced,

· The educator certification process does not rely on paper retention,

· Decision makers will have ready access to all needed information, and

· Legacy certification data systems are retired.

4.5.7 Change Control Process

As the project is implemented it is expected that some changes in the project plan will be necessary. As the potential for change is identified, the following process will be used to review and approve/disapprove changes:

Refer to the Configuration Management Document (DDD-EEE-X.Y.doc) for detailed information.

4.6 Risk Management Plan

Risks will be identified in Inception Phase using the steps identified in the RUP for Small Projects activity “Identify and Assess Risks”. Project risk is evaluated at least once per iteration and documented in this table.

Refer to the Risk List Document (CCC-DDD-X.Y.xls) for detailed information.

MSDE will develop a risk management plan to identify, mitigate, and review risks throughout the project lifecycle. All project participants will be involved in this process.

Refer to the Risk Management Plan Document (FFF-GGG-X.Y.xls) for detailed information.

4.6.1 Risk Management Categoriestc "3.4 Risk Management " \l 2

Risk Category: Schedule

The EIS team has developed a project schedule that covers the anticipated span of the project. This schedule is based on estimates for requirements identified to date. Due to the project being in the early stages, it is possible that additional requirements may be identified as the project progresses through the Requirements Definition and Design stages. This may result in additional effort required and changes to the current project schedule.

Resolution of risk: If additional requirements are identified and deemed necessary for the initial release of the application, the project manager will prepare an impact assessment and all approvers will have to sign off on the impact to schedule and budget before they will be implemented.

Risk Category: Changing Requirements

There is a possibility that requests for changes to the requirements will arise throughout the design and programming stages. Typical reasons for these change requests include providing missing functionality and improved usability.

Resolution of risk: The development team will apply rigorous software engineering principles of modularity and high level functionality. As requirements evolve over the lifecycle, the team will apply the change management procedures outlined in the Change Control Process and Configuration Management sections to determine which changes to make, and their impact on schedule and budget.

4.7 Project Closeout Plan

· Identify the plans necessary to ensure orderly closeout of the project.

· Specify the following:

· a staff reassignment plan

· a process for archiving project materials,

· a process for capturing project metrics in the business projects database,

· a process for post‑mortem debriefings of project personnel, and

· A plan for preparation of a final report to include lessons learned and an analysis of project objectives achieved.

5. Technical Process Plans

5.1 Process Model

Describe:

· Define the relationships among major project work activities and supporting processes.

· Describe the flow of information and work products among activities and functions.

· Specify the timing of work products to be generated.

· Identify the reviews to be conducted.

· Specify the major milestones to be achieved.

· Define the baselines to be established.

· Identify the project deliverable to be completed.

· Specify the required approvals within the duration of the project.

· In the process model for the project, include project initiation and project termination activities.

· Use a combination of graphical and textual notations to describe the project process model.

· Indicate any tailoring of your organization's standard process model for a project.

· The project’s lifecycle model (e.g., waterfall model, spiral model, evolutionary prototyping model, etc.)

· The project’s major milestones (content and completion schedule). Include a text description of the meaning of each milestone plus a Gantt chart or other high-level description of the project’s schedule.

· Major work products, tabularized as follows:

Work Product Name	Planned Completion Date	Placed Under Change Control?	Deliverable to Customer?	Who Must Sign Off on Work Product
Software Project Management Plan Controlling document for managing a software development project. Defines technical and managerial processes necessary to deliver the project requirements.	TBD	Yes	No	Project Manager, Engineering Lead, QA Lead, Documentation Lead
Name of work product	TBD	TBD	TBD	TBD

Consider including all of the following:

· Change Control Plan

· Change Proposals

· Vision Statement

· Top 10 Risks List

· Software Development Project Plan, including project cost and schedule estimates

· User Interface Style Guide

· User Manual/Requirements Specification

· Quality Assurance Plan

· Software Architecture

· Software Integration Procedure

· Staged Delivery Plan

· Individual Stage Plans, including miniature milestone schedules

· Coding Standards

· Detailed Design Documents

· Software Construction Plans

· Deployment Plan

· Release Checklist

· Release Sign-Off Form

· Software Project Log

· Software Project History Document

The items in this section (and, in general, in this document) can be fully described here, if not described in sufficient detail elsewhere.

2.1 Development Model tc "2.1 Development Model " \l 2

Development of HRIS will follow the DOE Software Engineering Methodology (SEM). The SEM is the lifecycle methodology standard for all EXBR system development projects. Tailoring of the lifecycle for this project includes modifications to the stages and to the number and types of documents. Listed below are the deviations from the SEM large system model that HRIS is planning to take.

Planned Deviations - Stages

The Functional Design and System Design stages will be combined into a single stage called Design. A stage exit will be conducted at the end of this stage. The Functional and System Design documents will be combined (see below). This approach will require one less stage exit and its associated activities, and does not introduce any undue risk to the project.

Planned Deviations - Deliverables

 A Feasibility Statement is not required for this project. A LAN-based approach is already being used for another application, MISview, which obtains its information from the EXBR server on a weekly basis. Since HRIS will be built on the same premise as MISview, the HRIS application is considered feasible.

 The Functional and System Design documents will be combined into a single document called the Design Specification. To reduce the risk associated with combining the two documents, mock up copies of the various screens and reports will be provided to the primary user as they are being developed to assure user satisfaction with the application's user interface.

 The Conversion and Installation Plans will be produced in the Programming stage. All necessary information to produce this deliverable will not be available earlier.

 The Configuration Management Plan will be produced in the Functional Design stage, rather than the Requirements Definition stage.

 The System Test Plan will be produced in the Programming Stage. It is felt that information will be more accurate and timely since this will be closer to the actual execution of the system tests.

Methods, Tools, and Techniques

· Specify the development methodologies, programming languages and other notations, and the processes, tools and techniques to be used to specify, design, build, test, integrate, document, deliver, modify and maintain the project deliverable and non‑deliverable work products.

· Specify the technical standards, policies, and procedures governing development and/or modification of the work products.

5.2 Infrastructure

· Specify the plan for establishing and maintaining the development environment (hardware, operating system, network and software), and the policies, procedures, standards, and facilities required to conduct the project. These resources may include workstations, local area networks, software tools for analysis, design implementations, testing, and project management, desks, office space, and provisions for physical security, administrative personnel, and janitorial services.

5.3 Product Acceptance

· Specify the plan for customer acceptance of the deliverables generated by the project.

· Specify objective criteria for determining acceptability of the deliverables.

· Reference a formal agreement of the acceptance criteria signed by representatives of the organization and the customer.

· Specify any technical processes, methods, or tools required for deliverable acceptance, such as testing, demonstration, analysis and inspection.

5.4 Security and Privacy

This section should review security and privacy requirements for the project and should ensure that the Project Plan reflects these requirements.

5.4.1 Privacy Issues

This section identifies privacy issues that should be addressed during the phases of the information system development effort and define the process to be established for addressing the privacy issues throughout the life cycle. It is important that there be a preliminary analysis of the potential privacy effects of the proposed information system. The purpose will be to establish for the project team and the review process an awareness of the privacy-related issues that will have to be addressed as the system is planned, developed, and implemented.

5.4.2 Computer Security Activities

This section reviews and evaluates requirements for security risk assessment and computer security planning to determine that all system vulnerabilities, threats, risks, and privacy issues will be identified and that an accurate determination will be made of the sensitivity of the system and information. Refer to the System Concept Development Phase, Requirements Definition Phase, and Design Phase for more information on security considerations.

6. Supporting Process Plans

6.1 Configuration Management

Appropriate tools will be selected which provide a database of Change Requests and a controlled versioned repository of project artifacts.

All source code, test scripts, and data files are included in baselines. Documentation related to the source code is also included in the baseline, such as design documentation. All customer deliverable artifacts are included in the final baseline of the iteration, including executables.

The Change Requests are reviewed and approved by one member of the project, the Change Control Manager role.

Refer to the Configuration Management Plan (EEE-FFF-X.Y.doc) for detailed information.

· Specify or reference the configuration management plan for the project, providing the information identified in the following lines.

· Specify the methods that will be used to perform the following activities:

· configuration identification,

· configuration control,

· status accounting,

· evaluation, and

· Release management.

· Specify the processes of configuration management including procedures for the following activities:

· initial base lining of work products,

· logging and analysis of change requests,

· change control board procedures,

· tracking of changes in progress, and

· Procedures for notification of concerned parties when baselines are established or changed.

· Identify the automated configuration management tools used to support the configuration management process.

6.2 Verification and Validation

· Specify or reference the verification and validation plan for the project, providing the information identified in the following lines.

· Specify the scope, tools, techniques and responsibilities for the verification and validation work activities.

· Specify the organizational relationships and degrees of independence between development activities and verification and validation activities.

· Specify the use of verification techniques such as traceability, milestone reviews, progress reviews, peer reviews, prototyping, simulation and modeling.

· Specify the use of validation techniques such as testing, demonstration, analysis and inspection.

· Identify the automated tools to be used in verification and validation.

6.3 Documentation

· Specify the plans for generating non‑deliverable and deliverable project documentation.

· Specify the organizational entities responsible for providing input information, and for generating and reviewing the project documentation.

· Specify the following information or object identification:

· list of documents to be prepared,

· controlling template or standard for each document,

· who will prepare each document,

· who will review each document,

· due dates for review copies,

· due dates for initial baseline versions, and

· a distribution list for review copies and baseline versions and quantities required

6.4 Quality Assurance

· Specify or reference the quality assurance plan for the project, containing the information identified in the following lines.

· Specify the plans for assuring that the project fulfills its commitments to the process and the product as specified in the requirements specification, the Project Management Plan, supporting plans and any standards, procedures, or guidelines to which the process or the product must adhere.

· As applicable, specify the quality assurance procedures to be used, such as analysis, inspection, review, audit, and assessment.

· Indicate the relationship among the quality assurance, verification and validation, review, audit, configuration management, system engineering, and assessment processes.

6.5 Reviews and Audits

· Specify the schedule, resources, and processes, and procedures to be used in conducting project reviews and audits.

· Specify the plans for joint customer‑project reviews, management progress reviews, developer peer reviews, quality assurance audits, and customer‑conducted reviews and audits.

· List the external agencies that approve or regulate any project deliverable.

6.6 Problem Resolution

· Specify the resources, methods, tools, techniques and procedures to be used in reporting, analyzing, prioritizing and processing problem reports generated during the project.

· Indicate the roles of development, configuration management, the change control board, and verification and validation in problem resolution work activities.

· Provide for separate tracking of effort expended on problem reporting, analysis and resolution, so that rework can be tracked and process improvement accomplished.

6.7 Subcontractor Management

· Specify or reference the plans for selecting and managing any subcontractors that may participate in or contribute to the project.

· Specify the criteria for selecting subcontractors.

· Generate a separate management plan for each subcontract, using a tailored version of this Project Plan, and include all items necessary to ensure successful completion of each subcontract as follows:

· requirements management,

· monitoring of technical progress,

· schedule and budget control

· product acceptance criteria,

· risk management procedures,

· additional topics as needed to ensure successful completion of the subcontract, and

· A reference to the official subcontract and subcontractor/prime contractor points of contact.

6.8 Process Improvement

· Specify the plans for periodically assessing the project, for determining areas for improvement, and for implementing the improvement plans.

· Ensure that the process improvement plan is closely related to the problem resolution plan.

· Include in the improvement plan, a process to identify the project processes that can be improved without serious disruption to an ongoing project, and to identify the project processes that can best be improved by process improvement initiatives at the organizational level.

6.9 Communication Process

This section should discuss frequencies, target audiences, media, sources, formats, locations, forms, and types of information delivered in each form of communication. Careful thought should be given to satisfying existing standards and following existing conventions, and consideration should also be given to improving the communication process in general and to ensuring that communication is enabled and simplified for all project team members and external entities. Periodic status reports, newsletters, bulletins, problem reports, issues lists, status and review meetings, team meetings, and other forms of communication should all be carefully considered and documented when creating the communication plan. Output the communication plan in the fonu of a communication item/audience matrix.

Effective and open communication is critical to the success of any endeavor. Throughout the course of the project, full and clear communication is necessary to ensure that all stakeholders and involved parties understand any topic that impacts the project’s success. These issues may involve positive and negative changes, problems, delays, questions, requests, and general status. The more complex the project is, especially from an organization standpoint, the more important the communication. Because of this, the method of reliable delivery of communication must be planned.

A structured communication plan helps to reduce or eliminate problems that may be associated with information distribution. These problems may include undistributed information, communications to the wrong parties, and information that is distributed that is not of interest to those receiving it. In addition, formal communication can become burdensome to the program when those receiving the information want the same information in different formats.

A communication plan addresses who receives what information, how, and when. This is an essential element of the communication plan as it establishes the expectations for what documents and work products the stakeholders can expect to receive and when they can expect to receive them. Our goal in communicating about the project is to: [modify these as appropriate]

· Establish and maintain the project credibility by communicating current status of all stakeholders,

· Generate a common understanding of how the activities of this project will improve the partners ability to achieve the goals,

· Prevent disenfranchising powerful and important stakeholders,

· Garner long-term and broad-based support for developing and maintaining the partnership that are consistent, reliable and complete.

6.9.1 Communication Items

Communication items are the regular deliverables or artifacts for the project’s communication. Include: 1) descriptions of the items required by each audience; 2) expectations – what people are expected to do in response; 3) results – what result is hoped will be achieved as a result of the item; 4) distribution method – how the item will get distributed, such as via email; 5) frequency of distribution; and 6) audience.

6.10 Communication Item

Charts,

6.11 Methods of Communication

This section describes the forms in which the project team interacts with its communication partners other than distributing a document. Meetings will be scheduled in advance.

Include the following sections as appropriate to the project and include descriptions and purpose

· Monthly Meetings

· Weekly Meetings

· Change and Issue Review Meetings

· Monthly Program Executive Briefing

6.11.1 Communication Protocol

Communication Protocol provides an overview of the standards to be followed and describes the “rules of engagement”.

6.11.1.1. Meetings

Standing Meetings: Three working days prior to standing meetings, the project coordinator should solicit topics for discussion. If no topics are raised, the meeting will be cancelled.

All meetings should have an agenda with a stated purpose and/or outcome(s). If relevant, be sure to provide the participants with advance background materials so they can understand why it is that they are being asked to come to this meeting.

Length of meetings: Specify expectations a appropriate

Location of meetings: Specify if possible

Minutes should be kept of each meeting and should reflect any issues, decisions, and action items that were discussed during the meeting. Minutes should be sent to the participants and relevant stakeholders within 3 days after the date of the meeting.

· Ad hoc Meetings:

· Work Group Meetings: Should have a meeting facilitator.

· Meetings with external representatives:

Again, it is essential that the outcome of the meeting be formally documented in minutes.

6.11.1.2. E-mail

E-mail is a formal means of written communication. Decisions and agreements may be documented and communicated through e-mail messages.

Special Handling of Inquiries from the media and the Legislature

There are special guidelines for communicating with the press or the legislature. In general, if the partnership will be interacting with the press or State Legislature(s), each partner’s process for doing so must be considered and the process the partnership will use must be discussed and formalized in advance. Use this section to describe who will handle these types of inquiries, the process that will be used to determine how these inquiries are handled and how the other partner(s) will be kept informed.

7. Additional Plans

· Specify or reference any additional plans required to satisfy product requirements and contractual terms, which may include:

· plans for assuring that safety, privacy, and security requirements are met,

· special facilities or equipment specification,

· product installation plans,

· user training plans,

· integration plans,

· data conversion plans,

· system transition plans,

· product maintenance plans, or

· Product support plans.

8. Project Evolution

8.1 Project support and maintenance

· Specify or reference to the support, maintenance and operational model for the project when the project will be used by the potential customers

8.2 Follow-up projects

· Identify potential follow-up projects which will use this project

· Identify potential follow-up projects which will supersede this project

Annex A

Item	Description	Expectations	Result	Distribution Method	Frequency of Distribution Change as appropriate for the project	Audience
Project Schedule	Time line to monitor tasks, activities, events, & milestones of campaign	Use as guide to keep on track	Measure progress or lack of; use info in Update Report		Quarterly	Project Director and Project Staff from all partnership organizations
Update Report	Status of project schedule items	Respond as necessary	Take action if project at risk; log in Issues Log		Quarterly	Project Director and Project Staff from all partnership organizations
Issues Log	List of issues that would impede success of the project	Raise issues & concerns, address each one, arrive at resolution	Close out issues		Monthly	Project Director and Project Staff from all partnership organizations
Review Comments List	Summary of comments if the project includes development of products and receiving feedback on these products from reviewers	Share comments received with all stakeholders	Action on the changes – accepted or rejected and the decisions documented		Following each review and comment period	Project Director and Project Staff from all partnership organizations
Change Request	Revise document or deliverable	Use when change required	Correct errors			Project Director and Project Staff from all partnership organizations Person with authority to approve changes at each partner organization
Meeting Summary	Minutes of meetings	Will be read & when necessary, and referenced	Documented chronicle of meetings	Word document attached to e-mail	Within 5 days after meeting is complete	Assigned work group members
Issue Paper Include or delete this row as appropriate to the project	Statement of situation that includes background	Initiate discussion or meeting	Decision made on next steps
E-mail Include or delete this row as appropriate to the project	Subject specific	Ditto	Ditto
Letter Include or delete this row as appropriate to the project	A formal communication	Ditto	Ditto
Memo Include or delete this row as appropriate to the project	Subject specific	Ditto	Ditto
Program Newsletter Include or delete this row as appropriate to the project	Subject specific	Ditto	Ditto		Monthly