[INSERT PROJECT NAME]€¦ · Web viewStandards for Content and Format – Word document for the release plan and completed change request forms. See Sections 5.7 & 5.8 for further

NMWEBFILE ONLINE DATA CAPTURE

TRD

PROJECT MANAGEMENT PLAN(PMP)

Executive Sponsors – TRD – Dona Cook, Deputy Secretary

Business Owners - TRD – Libby GonzalesTRD – Phil SalazarTRD – Alvan Romero

Program/TRD Project Manager – Ron MartínezOriginal Plan Date: August 17, 2005

Revision Date: August 3, 2007

Revision: 2.0

Project Management Plan i

TABLETABLE OFOF CONTENTSCONTENTS

Revision HistoryRevision History..........................................................................................................................................................vv1.01.0 Project OverviewProject Overview......................................................................................................................................66

1.11.1 IINTRODUCTIONNTRODUCTION..................................................................................................................................................................661.21.2 CCURRENTURRENT S STATETATE..............................................................................................................................................................771.31.3 FFUTUREUTURE S STATETATE..................................................................................................................................................................881.41.4 NNEEDEED................................................................................................................................................................................................1010

2.0 Scope2.0 Scope..............................................................................................................................................................................10102.1 P2.1 PROJECTROJECT J JUSTIFICATIONUSTIFICATION......................................................................................................................................1010

2.1.1 OUT OF SCOPE.................................................................................................112.2 P2.2 PROJECTROJECT O OBJECTIVESBJECTIVES................................................................................................................................................1212

2.2.1 BUSINESS OBJECTIVES....................................................................................122.2.2 TECHNICAL OBJECTIVES.................................................................................13

2.3 D2.3 DELIVERABLESELIVERABLES........................................................................................................................................................................13132.3.1 PROJECT MANAGEMENT DELIVERABLES......................................................15

2.3.1.1 PROJECT MANAGEMENT PLAN..................................................................152.3.1.2 INTEGRATED PROJECT SCHEDULE............................................................152.3.1.3 PROJECT REPOSITORY...............................................................................162.3.1.4 COMMUNICATION PLAN.............................................................................162.3.1.5 CHANGE/SCOPE MANAGEMENT REPOSITORY (FOR CHANGES NOT INCLUDED).............................................................................................................162.3.1.6 RISK MANAGEMENT PLAN.........................................................................172.3.1.7 PROJECT COMMUNICATIONS PLAN.........................................................172.3.1.8 CHANGE CONTROL MANAGEMENT PLAN...................................................17

2.3.2 PRODUCT DELIVERABLES...............................................................................192.3.2.1 PHASE 0: ANALYSIS OF CURRENT BUSINESS AND TECHNICAL REQUIREMENTS.....................................................................................................192.3.2.2 PHASE 1: DESIGN, DEVELOPMENT AND IMPLEMENTATION.....................19

2.3.3 DELIVERABLE APPROVAL AUTHORITY DESIGNATIONS................................202.3.4 DELIVERABLE ACCEPTANCE PROCEDURE.....................................................20

2.4 W2.4 WORKORK B BREAKDOWNREAKDOWN S STRUCTURETRUCTURE (WBS) (WBS)..................................................................................21213.0 Overall Strategy3.0 Overall Strategy..........................................................................................................................................2323

3.1 P3.1 PROJECTROJECT M MANAGEMENTANAGEMENT L LIFEIFE C CYCLEYCLE............................................................................................23233.23.2 DDETAILEDETAILED P PROJECTROJECT P PLANNINGLANNING ANDAND T TRACKINGRACKING....................................................23233.3 C3.3 CRITICALRITICAL S SUCCESSUCCESS F FACTORSACTORS........................................................................................................................23233.43.4 PPROJECTROJECT L LOGISTICSOGISTICS..............................................................................................................................................24243.5 P3.5 PRODUCTRODUCT L LIFEIFE C CYCLEYCLE M MODELODEL..................................................................................................................24243.63.6 TTECHNICALECHNICAL S STRATEGYTRATEGY....................................................................................................................................25254.1 S4.1 STAKEHOLDERSTAKEHOLDERS....................................................................................................................................................................28284.2 C4.2 CUSTOMERSUSTOMERS..................................................................................................................................................................................2828

This is a controlled document, refer to the document control index for the latest revisionNMWebFile employment/tax data capture platform PMP 081905 v1.0

i

Project Management Plan ii

4.3 P4.3 PROJECTROJECT T TEAMEAM......................................................................................................................................................................29294.3.1 PROJECT TEAM ORGANIZATIONAL BREAKDOWN STRUCTURE....................294.3.2 PROJECT TEAM ROLES AND RESPONSIBILITIES............................................31

5.0 Project Management and Controls5.0 Project Management and Controls............................................................................31315.1 S5.1 STAFFINGTAFFING P PLANNINGLANNING ANDAND A ACQUISITIONCQUISITION......................................................................................31315.2 A5.2 ASSUMPTIONSSSUMPTIONS............................................................................................................................................................................32325.3 C5.3 CONSTRAINTSONSTRAINTS............................................................................................................................................................................32325.4 D5.4 DEPENDENCIESEPENDENCIES........................................................................................................................................................................3333

5.4.1 MANDATORY DEPENDENCIES.........................................................................335.4.2 DISCRETIONARY DEPENDENCIES....................................................................335.4.3 EXTERNAL DEPENDENCIES.............................................................................33

5.5 R5.5 RISKISK M MANAGEMENTANAGEMENT......................................................................................................................................................33335.5.1 RISK MANAGEMENT STRATEGY.....................................................................335.5.2 PROJECT RISK IDENTIFICATION.....................................................................345.5.3 PROJECT RISK ANALYSIS................................................................................345.5.4 PROJECT RISK MITIGATION APPROACH.......................................................345.5.5 RISK REPORTING AND ESCALATION STRATEGY...........................................345.5.6 PROJECT RISK TRACKING APPROACH...........................................................34

5.6 I5.6 INDEPENDENTNDEPENDENT V VERIFICATIONERIFICATION ANDAND V VALIDATIONALIDATION - IV&V - IV&V................................37375.7 S5.7 SCOPECOPE M MANAGEMENTANAGEMENT P PLANLAN............................................................................................................................37375.8 I5.8 ISSUESSUE & C & CHANGEHANGE M MANAGEMENTANAGEMENT............................................................................................................3838

5.8.1 CHANGE CONTROL MANAGEMENT.........................................................385.8.2 CHANGE CONTROL TYPES.......................................................................385.8.3 BUGGIT OR FOGBUGS...............................................................................385.8.4 CHANGE CONTROL PRIORITIZATION......................................................405.8.5 CHANGE CONTROL STATUS.....................................................................405.8.6 MEETING/REVIEW SCHEDULE.................................................................405.8.7 CHANGE REQUEST NOTIFICATION..........................................................415.8.8 TECHNICAL ADVISORY GROUP (TAG)...................................................415.8.9 CHANGE CONTROL FLOW........................................................................425.8.10 CHANGE CONTROL BOARD (CCB)..........................................................43

5.9 P5.9 PROJECTROJECT T TIMELINEIMELINE........................................................................................................................................................43435.10 P5.10 PROJECTROJECT B BUDGETUDGET..........................................................................................................................................................44445.11 C5.11 COMMUNICATIONOMMUNICATION P PLANLAN......................................................................................................................................4646

5.11.1 COMMUNICATION MATRIX...........................................................................465.11.2 STATUS MEETINGS........................................................................................465.11.3 PROJECT STATUS REPORTS..........................................................................46

5.12 P5.12 PERFORMANCEERFORMANCE M MEASUREMENTEASUREMENT (P (PROJECTROJECT M METRICSETRICS))......................................47475.13 Q5.13 QUALITYUALITY O OBJECTIVESBJECTIVES ANDAND C CONTROLONTROL........................................................................................4747

6.0 Project Close6.0 Project Close......................................................................................................................................................47476.1 A6.1 ADMINISTRATIVEDMINISTRATIVE C CLOSELOSE........................................................................................................................................47476.2 C6.2 CONTRACTONTRACT C CLOSELOSE............................................................................................................................................................4747

7.0 Glossary7.0 Glossary....................................................................................................................................................................4848


ii

Project Management Plan iii

7.1 A7.1 ACRONYMSCRONYMS ANDAND A ABBREVIATIONSBBREVIATIONS............................................................................................................48487.2 D7.2 DEFINITIONSEFINITIONS................................................................................................................................................................................4848

APPENDIX A—Scope Definition DocumentAPPENDIX A—Scope Definition Document........................................................5454A.1 DA.1 DELIVERABLESELIVERABLES T TIMELINEIMELINE..................................................................................................................................5757

APPENDIX B --Issue ManagementAPPENDIX B --Issue Management......................................................................................5858APPENDIX C--Change ControlAPPENDIX C--Change Control..................................................................................................6161APPENDIX D--Risk ManagementAPPENDIX D--Risk Management..........................................................................................6363APPENDIX E--Acceptance ManagementAPPENDIX E--Acceptance Management..................................................................6666


iii

Project Management Plan iv

A ABOUTBOUT T THISHIS D DOCUMENTOCUMENT

This document is a template that provides the industry accepted guidelines to plan, execute, control, and close a project. This document will need to be tailored and customized to the needs of the project; however, special care should be considered if major sections are “tailored out”.

1. “Tailoring” is the process that modifies the structural components of the template to the needs of a specific project. As an example, the Project Manager may have a standard appendix that does not apply to the project.

2. Customization is the mechanical task of inserting customer or project logos, deliverable identifiers, names, and so on, into a copy of the template. The copy then becomes the live version of the Project Management Plan for the project and will need to be updated, as project conditions require.

3. Any level of tailoring can be applied to the template, as long as the PMO is advised. This notification has several purposes:

a. It allows Quality Assurance to adjust checklists and questionnaires,

b. It allows the Program Management Office (PMO) to adjust its oversight and QA activities to the project’s plan,

c. It allows the PMO to advise the project team of the potential effects and risks that may occur if materials are omitted, and

d. It serves as a trigger for possible improvement of the template by the PMO.

4. Any highlighted text indicates that there are some brief instructions for the completion of that section.


iv

Project Management Plan v

RREVISIONEVISION H HISTORYISTORY

Revision Number Date Comment1.0 August 19, 2005 Original Scope1

1.1 August 23, 2005 Minor revisions to pricing1.2 August 24, 2005 Clarification on Phase deliverables1.3 August 25, 2005 Additional Phase deliverable detail1.4 September 6, 2005 Project name change1.5 September 8, 2005 DOL funding & functionality updates1.6 September 9, 2005 Changes to Executive Sponsor & Steering

Committee, Deletion of Appendix F2.0 August 3, 2007 NM WebFile – Online Data Capture

1 This document is a reference from the New Mexico Department of Information Technology (DOIT) Program Management Office (PMO) created as part of the strategic continuous process improvement initiative. Questions or recommendations for improvement of this document may be forwarded to any DOIT PMO member.


v

Project Management Plan

1.01.0 PPROJECTROJECT O OVERVIEWVERVIEW

1.11.1 IINTRODUCTIONNTRODUCTION

Three New Mexico State Agencies are collaboratively proposing to build and implement a multi-agency One-Stop Platform which will be used by clients submitting data to the participating agencies. The lead Agency in this multi-agency project will be the Taxation and Revenue Department. These agencies are:

NM – Department of Labor Workers Compensation Administration Taxation and Revenue Department

This collaborative effort is being formalized using a Joint Powers Agreement (JPA) or a Professional Services Contract, which is currently being finalized by the legal teams of each agency. The project will be designed and implemented in the following planned phases.

Phase 0 includes: o PMP for Project and Programo Requirements gatheringo System Architectural Design

Phase 1 includes:o Application Designo Application Development o Implementation of core deliverables

Phase 2 includes: (Funding – tbd)o Enhancements to core deliverables, as necessary and will be funded at a future date.

Agency Client HelpDesk enhancements for online applications that will support these programs

RPD Data Capture (DCR – internal data entry – multiple tax programs) – internal data capture from paper to digital

o Additional Tax Programs to be enrolled later Combined Fuel Tax – 3 sub-programs (CFT, Retailer, Rack) Personal Income Tax (PITNet) 2007 Cigarette Tax Liquor Tax

Our project goal is to provide the necessary infrastructure to allow our constituent clients to submit single and multiple transaction data online. High-level features of this online system will include as core deliverables:

Unified Login

This is a controlled document, refer to the document control index for the latest revisionRevision: 1.0 DOIT-PMO-TEM-030

6

OCIO, 01/03/-1,

The Project Overview sets the stage for the details of the project and begins the “story” of the project and plan. It states the vision for the project (and larger effort, if applicable) in terms of a business need – not a solution. It answers “What is the specific answer that will move the business owner from the current state to a valuable future state?” The Project Overview describes the difference (gap) between the current state and future state in terms of the business need. The content structure order is the introduction, which provides background, the current state, the future state, and the need.


o Provides secure, profile based authentication for employees and clients.o Internet Employer Registration

Online Batch Data file transfero Provides real-time submission and validation of data. (Internet wage reporting)

Inter-agency data cross matchingo Improves user authentication characteristics and data reconciliation

There are a number of benefits that will be delivered by the implementation of this collaborative Inter-agency project. First, the inherent efficiencies of process automation will allow each agency to more effectively focus on their day-to-day business instead of on management of the current paper trail processes.

Next, our ability to collect and share common client data will facilitate and enhance our client’s ability to conduct business with the State of New Mexico. Added to this is the convenience of using a single platform for transactions dealing with multiple agencies.

Because of our ability to use technology to efficiently review and evaluate submitted data in real-time, a third benefit will be a distinct improvement in data quality. It also allows us to provide immediate automated feedback to clients if there are errors in their data or in the transfer of the data.

A fourth benefit lies in the process which allows us to build an audit/history trail of the transactions. This improves our confidence in process statistics and allows us to improve our business intelligence resources.

In summary, the benefits are equally shared by our constituent clients and the participating agencies sponsoring this project. Functionally, these improvements are process automation, data quality enhancements, improved customer services and a more effective use of resources. Finally, the cost of a multi-agency solution will be less than individual systems at each agency.

This PMP addresses the method and means to accomplish these important goals. Details related to how this project will be executed, funded and structured are provided in the remainder of this document.

Funding for the DOL components is being obtained from Federal Grants and must be encumbered by September 30, 2005 with liquidation by December 31, 2005. Our request is to encumber the funds for the project and for liquidation to be by phases allowing us to participate in the funding opportunity while moving forward on the design of the project as quickly as possible. The Architectural Design element, a necessary prerequisite, will be completed early in Phase 0 and will be submitted within 30-days with a target timeframe of mid-September. Therefore, we are requesting funding approval for Phase 0 and Phase 1 at this time.

1.21.2 CCURRENTURRENT S STATETATE

For several years, the Agencies participating in this agreement have been collecting their own individual client taxpayer data from their clients. Although this data collection is done in isolation, the information was shared with other agencies. Inefficiencies in this existing process include the collection of nearly


7


identical data submitted to each agency. Also, the timing of filing dates is not always synchronized limiting each agency’s ability to maximize the business intelligence from the data. In some cases, data is collected at the aggregate company level and for other business units the data is captured at the individual employee level.

For example: An oil company from Houston operates multiple production oil wells in Southeastern New Mexico. They regularly file Tax payments and royalties to ONGARD. They also maintain a CRS and corporate income tax (CIT) identification with TRD. For their New Mexico employees they pay wages which are reported in aggregate to the Department of Labor (DOL) and Unemployment Insurance filed with the Workers Compensation Administration (WCA). Their local employees pay personal income taxes (PIT) to Taxation and Revenue Department (TRD). Currently this client needs to work with individual agencies and file multiple transactions individually on various schedules in multiple data formats.

In some cases, data is submitted on paper forms, which uses a slow delivery process and has no automated validation process. Our agencies then need to manually enter the data onto their proprietary systems. Data that needs to be transferred to other agencies needs to be processed as a separate task often requiring reformatting of the data so that it can be used by the receiving agency in a format compatible with their systems. Any reconciliation and reporting that needs to be completed is often completed manually as well from individual data downloads created for these specific business needs.

Eventually, after individual transactions have been submitted, data files must be uploaded by batch processes. Not all legacy systems have an integrated data validation process. Therefore, errors submitted by the client and errors inadvertently introduced by data entry personnel create an added burden to the process.

Each of these individual Agency data systems are made up of a mixture of automated, semi-automated and manual processes within and across agencies. Various sets of similar data are then held in dispersed repositories in the different agencies.

In summary, the current state includes the following situations:

Manual processes Redundant data elements Redundant system maintenance needs Mixed filing submission media/locations Limited audit trail Increased susceptibility to human error

1.31.3 FFUTUREUTURE S STATETATE


8


To improve on the inefficiencies and process/data redundancy characteristic in the current state, we are proposing a project solution that will address these issues through consolidation of effort and integration of technological solutions. These solution components include but are not limited to:

Provide a Unified Login Service (ULS)o This is a service being developed by TRD and is approximately 95% complete.o This service integrates a user created profile and user authentication accessed by a

secure password.o A reporting component provides manager/user authorization and use statistics.o It includes a profile creation/maintenance module allowing users to build and edit

their demographic information in one consolidated location for all applications under the ULS umbrella.

Develop an internet platform through which users will access multiple web-based applications. The application most pertinent to this project is a Batch Data Transfer application.

o Features available to clients: Attach single or multiple returns in one of several accepted formats

CSV XML Online Web form

Receive real-time confirmation that the data submitted was received and was recognized to be for an identifiable business type and contained a specific number of returns/records.

Archive a copy of the data submission and maintain a history of client transactions.

Receive off-line or delayed-time confirmation that the records submitted were validated. If errors are present, errors are identified so the taxpayer can correct the errors and resubmit the return in a timely manner.

o Technical features of value for participating agencies include: Flexibility to receive data in multiple data formats allows for a smoother

transition to existing processing formats or new processes as they are developed in the future.

Convert current magnetic tape data submission components to direct online submission improving delivery time, incorporating data validation and reducing media transfer equipment and resource cost.

Archiving and transaction histories for transaction audit trails. Data validation improvements for the quality of data received. XML technology allows data to be translated to a common format, validated

and then, if necessary, translated again to be forwarded to appropriate agencies for processing.

Minimizes the need for manual data entry from paper forms. Similar data formats from a single client profile improve our ability to monitor

client activity across various business fronts for data consistency and tax fraud related issues.

Old Employer to new employer wage history data transfer. Provide inter-agency cross match of data


9


DOL to TRD-MVD cross match TRD-PIT to DOL Wage data cross match

Summary:

By implementing a One-Stop Online Data Submission Platform for taxpayers to submit their returns to multiple State Agencies we will improve service capabilities to our clients, streamline our internal processes, improve the quality of our data and employ our staffing resources more effectively.

1.41.4 NNEEDEED

Synergy might be the best term to describe the ‘Need’ for this project. We have a need to do more for our businesses and for our clients. We also have a need to do things better.

In general, we need to reduce or eliminate redundancy in our efforts, improve the quality of our data and availability of our client services.

More specifically, the following list of items includes features that need to be improved:

Improve accessibility and availability of services to our clients Create inter-agency access to cross-check data Minimize manual processes requiring staff data entry, data validation and error correction. Unify client login profiles to allow them to focus their work through one website platform

with one secure password. Improve client response time. Integrate data validation and quality improvements into the data submission process. Consolidate redundant tasks among participating agencies. Discover non-compliant businesses. Standardize filing dates and data submission formats. Define business and technical requirements with subject matter experts. Upgrade manual and automated processes that may be up to thirty-years old.

Summary:

By combining and coordinating our solutions for resolving our common business needs we will be more effective in improving the quality of our data, services and business processes.

2.0 S2.0 SCOPECOPE

2.1 P2.1 PROJECTROJECT J JUSTIFICATIONUSTIFICATION


10


The following rationale and justification has been developed to support the request for project inception and certification.

Upgrade and consolidate data submission infrastructure Standardize data format by offering capability to translate from client formats to XML then

translate to meet format needs for the agency that will process the data within their business systems.

Improve data quality through online validation using XML schema Create data transmission efficiencies by consolidating inter-agency e-business transactions. Improve ability for State Agencies to discover non-compliant businesses and pursue audit

and tax fraud issues. Introduce process cost savings by minimizing or eliminating manual data entry by Agency

Staff. Introduce process cost savings by reducing data correction actions by Agency Staff with

clients. Automated data validation also reduces staff resource costs and client communication

expenses. Comply with State e-Gov and e-Business initiatives. Implementation of these initiatives will allow all participating agencies to focus on our daily

and strategic business activities rather than on the paper trail process. It will allow us to more easily identify those clients who may need encouragement to do

business with us on a more regular basis. Improve service to customers and improve quality of service with improvements such as

accelerating client response time.

2.1.1 O2.1.1 OUTUT OFOF S SCOPECOPE

The focus of this project is to provide a common interface that is capable of allowing authenticated clients to submit and transfer data. Components outside of that definition, including the following items, are Out-of-Scope.

It is not the intent of this project to process data for any of the participating agencies. The scope begins with a client login and ends when we export data to the parent agency for them to process through existing applications.

While a necessary ingredient of the outcome of this project will be to communicate the availability and functionality of this One-Stop Data Submission Platform, the administration of this element does not fit into the scope of the deliverables. The project itself will focus on business and technical implementation needs. Communication of system service features to clients is outside our project scope.

Advanced data management and analysis capabilities such as building data cubes, data mining and generating business intelligence are outside the scope of this project. While each agency will have access to more data in a standardized format, it will be up to each agency to extract more value from the availability of the data. Cross match data will be delivered as prescribed but there will be no additional analytical services delivered.


11

OCIO, 01/03/-1,

State the business benefits the project is to accomplish


Primary tax programs to be enrolled include:o Employee Wageso Unemployment Insuranceo Personal Income Taxo Corporate Income Taxo Other tax programs will be out of scope for Phase 0 and Phase 1

2.2 P2.2 PROJECTROJECT O OBJECTIVESBJECTIVES

2.2.1 B2.2.1 BUSINESSUSINESS O OBJECTIVESBJECTIVES

NNUMBERUMBER DDESCRIPTIONESCRIPTION

Bus. Objective 1 Expand availability of e-Gov and e-Business services to constituent clients.

Bus. Objective 2 Consolidate interfaces and data transfer processes to facilitate a client’s ability to do business with the participating agencies.

Bus. Objective 3 Integrate security into the client registration and transaction submittal process allowing participating agencies to become compliant with standards being implemented by the Department of Information Technology (DOIT)

Bus. Objective 4 Eliminate duplication of effort and duplication of data for clients with business transaction needs across participating agencies.

Bus. Objective 5 Improve quality of data through validations integrated into the data transfer process.

Bus. Objective 6 Improve accessibility to data by creating common format translation capability (XML and XSD).

Bus. Objective 7 Create an environment for clients to enter and submit data electronically allowing the participating State Agencies to focus on processing elements of the business functions rather than on processing paper, entering data and correcting taxpayer returns.

Bus. Objective 8 Tax Fraud MitigationBus. Objective 9 Develop program to take newly registered employers from Portal and

integrate into NMDOL system flow. Deal with special situation where new employer registration requires a transfer of wage history from another employer.

Bus. Objective 10 Develop program to take newly reported wages from Portal and integrate into NMDOL system flow. Develop program to transfer wages reported through means other than the Portal (email, magnetic media, etc) to TRD.

Bus. Objective 11 Develop program to pass along to TRD adjustments to wages through process not visible to TRD, e.g. corrections or out-of-balance condition between 903A and 903B.

Bus. Objective 12 Develop batch program to cross-match TRD address and identity data with corresponding NMDOL data weekly for initial UI.

Bus. Objective 13 Develop batch program to cross-match TRD address and identity data with corresponding NMDOL data monthly for benefit payments.


12



Bus. Objective 14 Develop batch program to cross-match TRD address and identity data with corresponding NMDOL data quarterly for addresses that have been flagged as undeliverable.

Bus. Objective 15 Integrate a process to deal with special situation where new employer registration requires a transfer of wage history from another employer.

These project objectives are consistent with the Taxation and Revenue Department FY05 Strategic Plan, September 1, 2004 (TRD SP); Taxation & Revenue FY06 IT Plan (TRD IT FY06); Governor Bill Richardson’s Performance Review Reports: Moving New Mexico Forward, August 2003 (NM PR I) and Moving New Mexico Forward: Further Along, August 2004 (NM PR II); and the State of New Mexico Enterprise Information Technology (IT) Strategic Roadmap, Fiscal Year 2006-2007 Strategic Guide, June 2005 (DOIT SP).

Specific points of agreement include:

SSOURCEOURCE DDESCRIPTIONESCRIPTION

TRD SPTRD IT FY06 Continued efforts to increase the breadth of electronic constituent

services and their increased usage.NM PR INM PR IIDOIT SP Facilitate sharing of systems, processes and data.DOIT SP Enhance delivery of services to constituents.

2.2.2 T2.2.2 TECHNICALECHNICAL O OBJECTIVESBJECTIVES


Tech. Objective 1 Consolidate hardware and infrastructure resources and standards to reduce application maintenance costs.

Tech. Objective 2 Streamline data management capabilities through the use of modern data formats such as XML translation engines as well as validation of data using XML schema within Business Rules engines.

Tech. Objective 3 Leverage skills and experience of the lead agency in web-based applications to the benefit of the other agencies.

Tech. Objective 4 Implement enhanced security and data integrity to ensure business continuity and be consistent with department and enterprise objectives.

2.3 D2.3 DELIVERABLESELIVERABLES

Most of the deliverables for this project will be common to all participating agencies. To a lesser degree, each agency has specific needs which will be addressed through a distinct deliverable:


13

OCIO, 01/03/-1,

Technical Objectives relate to the technical issues or goals that the project is to accomplish


DOL Cross match to TRD-MVD data: This deliverable will be a daily download to DOL from

TRD-MVD allowing them to reference and validate client data. Electronic data submission: Currently most employers submit on paper via mail and on

magnetic tape. This new process will allow them to capture their data in an electronic format for automated processing.

Employer Registration: Develop program to take newly registered employers from Portal and integrate into NMDOL system flow.

WCA Cross match to DOL and TRD-MVD data Electronic data submission

TRD Cross match to DOL Wage data. Increased granularity of wage data from DOL clients.

Common Deliverables – Phase 0:

Project Management Plan Requirements Documents Template XSD (XML schema) for one tax program form System Architectural Design Unified Login Service

Common Deliverables – Phase 1:

Online data submission capability (Batch Transfer) Generate transaction history report templates Create archived copy of submitted datasets XML Translation Engines (import/export) Data Validation with XML Schema Common data format files Schema for DOL forms, WCA forms and PIT 2006 forms Database design and development (Schema, Tables, SPROCS, UDFs) Platform application design and development (code, GUI, classes) Data Cross Match file output (batch)


14


The anticipated schedule for deliverables is based primarily on tax deadline filing dates. Project Management deliverables (as detailed in Section 2.3.1) will be developed on inception of the project. The exception is the Project Management Plan (this document) that is done upon completion of the current approval process.

The sequence of events shown is:

1. Project Management Plan (PMP) 08/23/052. Unified Login Service (ULS) 09/30/053. Business Requirements 09/30/054. Architectural Design 09/30/05

5. Application Development 11/14/056. Database Development 11/14/057. XML Schema development 11/14/058. Application Testing 11/30/059. MVD Batch file to DOL 11/30/0510. Project Sign-off 12/09/0511. Complete Documentation 12/16/0512. Migrate to Production environment 12/16/05

Product Deliverables are scheduled for the following dates:

Phase 0 09/30/05Phase 1 12/16/05

Product deliverables are described in further detail in section 2.3.2 and in Appendix A. Appendix A also includes a graphical timeline depicting the product deliverables schedule.

2.3.1 P2.3.1 PROJECTROJECT M MANAGEMENTANAGEMENT D DELIVERABLESELIVERABLES

2.3.1.1 PROJECT MANAGEMENT PLAN

Description - Project Management Plan (PMP)

Deliverable Acceptance Criteria – Completely integrated project plan that meets DOIT and NMWebFile standards. See the DOIT web site for a template. Web address is: (http://policymanual.hsd.state.nm.us/dscgi/ds.py/Get/File-1561/DOIT-PMO-TEM-020_Project_Management_Plan.doc)Standards for Content and Format – MS Word in the accepted DOIT standard from the DOIT webpageQuality Review – Internal TRD PMO review and approval, DOIT PMO review and approval.


15

OCIO, 01/03/-1,

Project Deliverables are work products or artifacts that are driven by the project management methodology requirements and standard project management practices regardless of the product requirements of the project. Examples are project, phase, and iteration plans, and project schedules. Project Deliverables must be reviewed and approved by the project’s Executive Sponsor prior to their implementation.

OCIO, 01/03/-1,

Quality review provides the opportunity for peer and cross-discipline reviews of the deliverable. This process will improve the Quality Control metrics by reducing the testing cycle and the number of exceptions reported by Quality Control and eventually the executive sponsor.

OCIO, 01/03/-1,

Standards for Content and Format describe the format that the executive sponsor can expect to receive the deliverable. This section ensures that the deliverable will be usable to meet its objective upon delivery. The tools, techniques, and processes used to develop the deliverable must compliment the executive sponsor’s environment and enable the executive sponsor to use the deliverable

OCIO, 01/03/-1,

Acceptance Criteria are quantifiable measures of the success of each deliverable (or set of deliverables). Its how the executive sponsor and the project team know when a deliverable is acceptable and can be approved. Acceptance criteria are similar to measures of success except they are for a specific deliverable. The criteria may include functional and technical testing and utility verification at defined points in the process; methodology and criteria should be published.

OCIO, 01/03/-1,

Deliverable description conveys the features and/or the functions that will be included in the project product. Each deliverable is a subsidiary element of the project product (final deliverable), each with its own separate but interdependent deliverable scope

OCIO, 01/03/-1,

Insert the name of the deliverable


2.3.1.2 INTEGRATED PROJECT SCHEDULE

Description - Project Schedule Deliverable Acceptance Criteria – Completely integrated project schedule that meets DOIT and NMWebFile standards. An example of a project plan can be obtained from the TRD PMO manager.Standards for Content and Format – MS ProjectQuality Review – Project manager and TRD PMO manager review and comment on plan until it meets quality standards

2.3.1.3 PROJECT REPOSITORY

Description – Notebook(s) or binder(s) containing paper copies of project management documentation throughout the project life cycle.

Deliverable Acceptance Criteria –A format can be obtained from the TRD PMO. Standards for Content and Format – Insertion of all final paper copies of final project documents such as sign-offs, specifications, change logs, issue logs, etc. These documents should be arranged into categories and kept updated throughout the life cycle. The binders should also be retained after project closure to ensure capability to perform project audits and reviews.Quality Review – Periodic reviews during the project with the Team Leader, TRD IT Auditor, Project Manager, and TRD PMO Manager

2.3.1.4 COMMUNICATION PLAN

Description – Develop a detailed plan that defines the content, means and timing of communication related to the project.

Deliverable Acceptance Criteria – A communication plan that articulates how and when the changes will be implemented and how those changes will be communicated to the NMWebFile Executive Steering CommitteeStandards for Content and Format – MS Word and/or PowerPoint; see Section 5.13 for further standards.Quality Review – Project team, Executive Steering Committee, TRD PMO manager, TRD CIO.

2.3.1.5 CHANGE/SCOPE MANAGEMENT REPOSITORY (FOR CHANGES NOT INCLUDED)


16

OCIO, 01/03/-1,

Quality review provides the opportunity for peer and cross-discipline reviews of the deliverable. This process will improve the Quality Control metrics by reducing the testing cycle and the number of exceptions reported by Quality Control and eventually the executive sponsor.

OCIO, 01/03/-1,

Standards for Content and Format describe the format that the executive sponsor can expect to receive the deliverable. This section ensures that the deliverable will be usable to meet its objective upon delivery. The tools, techniques, and processes used to develop the deliverable must compliment the executive sponsor’s environment and enable the executive sponsor to use the deliverable

OCIO, 01/03/-1,

Acceptance Criteria are quantifiable measures of the success of each deliverable (or set of deliverables). Its how the executive sponsor and the project team know when a deliverable is acceptable and can be approved. Acceptance criteria are similar to measures of success except they are for a specific deliverable. The criteria may include functional and technical testing and utility verification at defined points in the process; methodology and criteria should be published.

OCIO, 01/03/-1,

Deliverable description conveys the features and/or the functions that will be included in the project product. Each deliverable is a subsidiary element of the project product (final deliverable), each with its own separate but interdependent deliverable scope

OCIO, 01/03/-1,

Insert the name of the deliverable


Description – During the project, it is expected that there will be a number of requests for changes to the design of the system being developed that cannot be incorporated in the current release of the system, this repository will contain both a plan to address the requested changes and a repository for the requests to facilitate ongoing management of the requests

Deliverable Acceptance Criteria – Change management log that contains all submitted change requests that were not included in the current release. Standards for Content and Format – Word document for the release plan and completed change request forms. See Sections 5.7 & 5.8 for further standards.Quality Review – Team review, Executive Steering Committee review, TRD CIO review, TRD PMO review.

2.3.1.6 RISK MANAGEMENT PLAN

Description – The purpose of risk tracking is to identify, document and monitor potential risk areas for the New Mexico Project. A risk is identified as the possibility that something will prevent the project from meeting expectations.

Deliverable Acceptance Criteria – Regular review and tracking of project risks through status and meeting communications.Standards for Content and Format – MS Word format following process outlined in Section 5.5 of this document.Quality Review - Team review, Executive Steering Committee review, TRD CIO review, TRD PMO review.

2.3.1.7 PROJECT COMMUNICATIONS PLAN

Description – The purpose of project communications is to define performance reporting and meeting schedules.

Deliverable Acceptance Criteria – Presentation and acceptance of performance reporting and meeting schedules by the steering committee. Document would flow from the project team to the steering committee.Standards for Content and Format – MSWord, PowerPoint, or email to steering committee. Quality Review - Team review, Executive Steering Committee review, TRD CIO review, TRD PMO review.

2.3.1.8 CHANGE CONTROL MANAGEMENT PLAN

Description - The purpose of the Change Control Process is to ensure changes are made in a

Deliverable Acceptance Criteria – Update original Change Control Management Plan developed for initial project phase.


17


consistent manner and that the appropriate stakeholders are informed. The Change Control Process also ensures that all identified enhancements, defects and issues are tracked and handled in a consistent manner.

Standards for Content and Format – See Section 5.8 of this document for details.Quality Review - Team review, Executive Steering Committee review, TRD CIO review, TRD PMO review.


18


2.3.2 P2.3.2 PRODUCTRODUCT D DELIVERABLESELIVERABLES

2.3.2.1 PHASE 0: ANALYSIS OF CURRENT BUSINESS AND TECHNICAL REQUIREMENTS

Description - Conduct and document an analysis of the current business and technical environments in each business area involved in the NMWebFile Data Platform.

Deliverable Acceptance Criteria – 1) Project Management Plan2) Requirements documents for three participating

agencies3) Template XSD (XML Schema) for one tax program

as prototype for additional tax programs4) System Architectural Design5) Unified Login Service

Standards for Content and Format – Documentation in Word 2003, Visio, and PowerPoint. All documentation must be delivered in “soft” copy along with any printed or bound copies.Quality Review – Project Manager, CIO sign-off. Executive Steering Committee approval.

2.3.2.2 PHASE 1: DESIGN, DEVELOPMENT AND IMPLEMENTATION

Description - Perform and document business and technical environments necessary functions.

Deliverable Acceptance Criteria – 1) Client User interface2) Online data submission module3) Data Archive4) XML Translation engines5) Data validation with XML Schema6) Reports module7) Data Cross Match Batch download program8) Project Documentation



19


3.02 PROJECT EXPANSION- NMWEBFILE – ONLINE DATA CAPTURE, DESIGN, DEVELOPMENT AND IMPLEMENTATION

Description This project will allow the TRD to leverage the technology invested in this infrastructure to expand the number of tax applications available to internal and external clients for online data submission. It also proposes to deliver analytical and reporting resources to help begin to translate data to information.

Deliverables 1. New Tax Program Expansion

Business Unit Requirements Gathering (internal staff)Project Management Plan (internal staff)IV&V ContractArchitectural Design Application Development

2. Application deliveryIV&V Final ReportUser Acceptance Testing (internal staff)Business Unit Sign-offProduction Deployment



20


2.3.3 D2.3.3 DELIVERABLEELIVERABLE A APPROVALPPROVAL A AUTHORITYUTHORITY D DESIGNATIONSESIGNATIONS

DDELIVERABLEELIVERABLE NNUMBERUMBER

DDELIVERABLEELIVERABLE AAPPROVERSPPROVERS (W (WHOHO CANCAN APPROVEAPPROVE))

PMP PMP RREFERENCEEFERENCE

NMWebFile-PRJ-001

Project Management Plan (PMP) DOIT, TRD PMO, Agency CIO

2.3.1.1

NMWebFile -PRJ-002

Integrated Project Schedule DOIT, TRD PMO 2.3.1.2

NMWebFile -PRJ-003

Project Repository Agency Project Manager, TRD PMO

2.3.1.3

NMWebFile -PRJ-004

Communication Plan Agency Project Manager, TRD PMO

2.3.1.4

NMWebFile -PRJ-005

Change/Scope Management Repository

Agency Project Manager, TRD PMO

2.3.1.5

NMWebFile -PRJ-006

Risk Management Plan Agency Project Manager, TRD PMO

2.3.1.6

NMWebFile -PRJ-007

Project Communications Plan Agency Project Manager, TRD PMO

2.3.1.7

NMWebFile -PRJ-008

Change Control management Plan Agency Project Manager, TRD PMO

2.3.1.8

NMWebFile – PRJ-009

Analysis of Current Business and Technical Environments

Agency Project Manager, Exec. Steering Comm.

2.3.2.1

NMWebFile – PRJ – 010

Functional Needs Agency Project Manager, Exec. Steering Comm.

2.3.2.2

2.3.4 D2.3.4 DELIVERABLEELIVERABLE A ACCEPTANCECCEPTANCE P PROCEDUREROCEDURE The Deliverable Acceptance Procedures for this project involve both internal developed deliverables. The objective of the Deliverable Acceptance Process is to ensure quality in the delivery of a product that is fit for the purpose (i.e. tax and data collection) defined in the project deliverables. This objective of quality in delivery will be met by a series of team and steering committee meetings that foster team collaboration and cooperation through joint ownership of specifications and results. The process is described below.

As artifacts are developed, the following process will be followed. The document author will submit each artifact for acceptance to the project review team, the designated quality assurance team member, and the review owner (PM or designee). Each deliverable will be accompanied by a Deliverable Acceptance Form, see Appendix E. The review team will then be responsible for reviewing the document and forwarding their comments on to the deliverable owner. The deliverable owner will then be responsible for summarizing the team’s comments and will either correct the artifact and resubmit for


21

OCIO, 01/03/-1,

Complete the following table to identify the deliverables this project is to produce, and to name the person or persons who have authority to approve each deliverable. Each deliverable should be assigned a control number for tracking. The date approved column serves as a log of when each deliverable was approved.


review or inform the Project Manager to move the final artifact to the appropriate archival library or electronic project file.

The Deliverable Acceptance Form shall be completed with a specific listing of requirements for the given deliverable. Each requirement must be described and signed that it was successfully tested. Any designated project team member may do this. Final acceptance of the given deliverable may only be signed/accepted by the deliverable owner (designated project manager or their representative).DOL will certify through the Joint Powers Agreement and PMP Project Deliverables and will make payments per that agreement.

Any deliverables that do not make it through quality assurance deliverable reviews will be referred back to the project team for rapid response. A time interval will be agreed upon with the vendor as to the timing of the required response to a failed deliverable. All three parties will determine schedule adjustments.

2.4 W2.4 WORKORK B BREAKDOWNREAKDOWN S STRUCTURETRUCTURE (WBS (WBS))

See Appendix A.


22

RonM, 08/25/05,

A WBS is a deliverable-oriented grouping of project elements that organizes and defines the total work scope of the project. Each descending level represents an increasingly detailed definition of the project work. Include at least the highest level grouping for the project in this section and include the detailed WBS as Appendix A.

OCIO, 01/03/-1,

Describe the process that this project will use for the formal acceptance of all deliverables. Generally, a Deliverable Acceptance Form is utilized with specific timeframes allowed for review, approval, rework, etc. Issues identified in this Deliverable Acceptance Procedure should follow the Issues Escalation Process that is defined in a later section.



23


3.0 O3.0 OVERALLVERALL S STRATEGYTRATEGY

3.1 P3.1 PROJECTROJECT M MANAGEMENTANAGEMENT L LIFEIFE C CYCLEYCLE

This section of the project management plan will describe the process used to monitor progress on the project in order to ensure that all tasks are being completed according to schedule, and that the project remains aligned with the primary business goals as stated in the RFP.

Project planning will be an ongoing activity during the life of the project. The planning activities started with the submission of the vendor’s response to the RFP issued by the New Mexico Taxation and Revenue Department. This plan will be flushed out with more detailed explanations of the different tasks, as well as adding responsible parties (i.e. vendor or New Mexico), in the Statement of Work (SOW) that is agreed to by both parties.

Given the level of planning that has been completed prior to the project start up, the Project Managers will be responsible for ensuring the project is tracking to plan, and also for making any adjustments to the plan that may be required due to change orders etc. As with any long-term project, it is expected that the project plan may be adjusted as the project progresses during different phases.

3.23.2 DDETAILEDETAILED P PROJECTROJECT P PLANNINGLANNING ANDAND T TRACKINGRACKING

Each of the different teams on the project will be responsible for executing their tasks according to the plan, and reporting on their progress to the Project Managers each week. Any impediments to completing the individual tasks on a timely basis are considered issues, and should be identified as such in the team leader status reports submitted to the PM’s each week.

3.3 C3.3 CRITICALRITICAL S SUCCESSUCCESS F FACTORSACTORS

The following Success Factors have been identified as Critical in order for the NMWebFile One-Stop Platform project to be successful:

Team members need to be empowered in order to makeo Technical Decisionso Design Decisions

Knowledge Transfer must be an integral part of the project Project development methodology must be followed Regular executive steering committee meetings must be held for the duration of the project to

facilitate:o Requirements managemento Financial oversighto Change managemento Deliverables acceptance


24

OCIO, 01/03/-1,

The Overall Strategy is a high-level scheme and/or specific methodology used to guide the work effort for the project. It tells the story of how the project will be done. It may include what is to be done (actions/activities), why it is being done in this way, why doing it this way (logic, reasons, justifications) is recommended, and what the added value of the strategy and results are. Items to consider and identify either as separate sections or within one section for overall strategy are the details concerning project management strategy, project logistics, the product life cycle model and technical strategy. Describe the strategy/approach at the necessary and relevant level of detail for the specific project.


3.43.4 PPROJECTROJECT L LOGISTICSOGISTICS

The Department of Labor shall provide the items listed below: XML schema for data from current data input forms XML schema for format of MVD export data needs Subject matter experts for defining business requirements Management of all Federal funding acquisition, reporting and documentation with direct

responsibility to the TRD Program/Project Manager to provide regular reporting and summaries on a regular basis (at least monthly)

The Workers Compensation Administration shall provide the items listed below: XML schema for data from current data input forms Subject matter experts for defining business requirements

The Taxation and Revenue Department shall provide the items listed below. A list of agency contacts who are subject-matter-experts in their respective areas A Program/Project Manager to work with the design and implementation who, in addition to

providing overall management and administration of the project and this Agreement, shall manage the activities in Section 3.5

3.5 P3.5 PRODUCTRODUCT L LIFEIFE C CYCLEYCLE M MODELODEL

Project Initiation and Planningo Requirements determinationo Validate assumptions and constraintso Clarify statement of worko Create project scheduleo Create project work breakdown structureo Obtain approval of stakeholderso Prepare work environmento Collect critical documentation

Project Executiono Collect detailed project data and informationo Perform work to complete each deliverableo Obtain acceptance of each deliverableo Manage all issues, changes, and riskso Perform quality assurance activities

Project Closureo Archive appropriate project informationo Perform post-implementation reviewo Track applicable metrics


25

OCIO, 01/03/-1,

Identify the life cycle models being used to develop the project product or service, and discuss each of its phases.

OCIO, 01/03/-1,

Identify the critical success factors for achieving success in this project.


3.63.6 TTECHNICALECHNICAL S STRATEGYTRATEGY


26



27



28


4.0 Project Organization

4.1 S4.1 STAKEHOLDERSTAKEHOLDERS

NAMENAME SSTAKETAKE ININ P PROJECTROJECT OORGANIZATIONRGANIZATION TTITLEITLE

Jan Goodwin All functionality TRD Cabinet SecretaryDona Cook All functionality TRD Deputy Cabinet SecretaryMarlin Mackey All functionality TRD CIOMarilyn Hill All functionality DOL Deputy Cabinet SecretaryMarlin Mackey All functionality DOL CIOCassandra Encinias Business requirements DOL Asst. Bureau ChiefAlice Dominguez Business tax DOL Tax ManagerDulie Espinoza I.T. functions WCA Program Liaison ManagerGary Chavez Program Analysis WCA Economic Analyst

4.2 C4.2 CUSTOMERSUSTOMERS

Internal customers include:

DOL Alice Dominguez Cassandra Encinias

WCA Dulie Espinoza Gary Chavez

TRD Libby Gonzales Phil Salazar Alvan Romero

External customers include: n/a: (After delivery of the external client will be constituent taxpayer clients using the

services of this system.)


29

OCIO, 01/03/-1,

List all of the major stakeholders in this project, and state why they have a stake. Also, identify stakeholders required to sign-off on the PMP by an asterisk after their name. 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.

OCIO, 01/03/-1,

The Project Organization describes the roles and responsibilities of the project team. It also identifies the other organizational groups that are part of the project and graphically depicts the hierarchical configuration of those groups. It exists to clarify interaction with the project team.

OCIO, 01/03/-1,

Discuss the key technical strategies for achieving success in this project.


4.3 P4.3 PROJECTROJECT T TEAMEAM

4.3.1 P4.3.1 PROJECTROJECT T TEAMEAM O ORGANIZATIONALRGANIZATIONAL B BREAKDOWNREAKDOWN S STRUCTURETRUCTURE

Executive Steering Committee

The Executive Steering Committee for the NMWebFile – Onlien Data Capture project consists of representatives from stakeholder departments:

Dona Cook: Deputy Cabinet Secretary - TRD Marlin Mackey: ISB Chief Information Officer – TRD

o Or designee Libby Gonzales: RPD Director – TRD Phil Salazar: ACD Director – TRD Alvan Romero: Tax Fraud Unit Manager – TRD

The Project Team

Exact team roster will be determined upon approval of project for initiation.

Project Sponsors

TRD – Dona Cook, Deputy Cabinet Secretary

Subject-Matter Experts

Staff with expertise in different domain areas will be accessible to the project team, as needed. These subject-matter-experts (SMEs) will be identified after project initiation. SMEs may include the following NMWebFile personnel:

TBD

Communication Procedures

The Executive Steering Committee will meet at least on a monthly basis in order to review project progress, deliverables/milestones and provide direction to the team. The Project Director will be required to provide formal status reports to the steering committee and will present the report during the steering committee meetings. The Project Team will meet weekly to ensure efforts are coordinated and on schedule.

The Project Manager will be required to complete a stakeholder communications plan, which will address communications with the primary business owners of the NMWebFile project.


30


The Project Manager will also be required to report on the overall status of the project on a monthly basis, per standard DOIT/ITC procedures. The project may update these procedures as necessary.

Project Team Training Requirements

Immediate training requirements for the project team are unknown; however, appropriate training or reading will be assigned after the detailed deliverables are established.


31


Project Organization

Committee / Team Name Responsibility

Executive Steering Committee (NMWebFile) Project OversightBusiness Decision Team (Business Manager) Deliverables Acceptance and sign-offBusiness Requirements Process DistillationProject Management Team Project direction, scope, deliverables, timelinesDevelopment Team Project developmentIV&V Deliverables/system verification and validationOther: tbd

4.3.2 P4.3.2 PROJECTROJECT T TEAMEAM R ROLESOLES ANDAND R RESPONSIBILITIESESPONSIBILITIES

To be completed by Project Manger upon project initiation

RROLEOLE RRESPONSIBILITYESPONSIBILITY NNAMEAME FFUNCTIONALUNCTIONAL MMANAGERANAGER

5.0 P5.0 PROJECTROJECT M MANAGEMENTANAGEMENT ANDAND C CONTROLSONTROLS

5.1 S5.1 STAFFINGTAFFING P PLANNINGLANNING ANDAND A ACQUISITIONCQUISITION

TRD employment/tax data capture platform Executive Steering Committee will determine if additional staff is required to support the project. Appropriate resources will be named to the project team.

5.2 A5.2 ASSUMPTIONSSSUMPTIONS22

2 Assumptions are planning factors that, for planning purposes, will be considered true, real, or certain. Assumptions generally involve a degree of risk. They may be documented here and converted to formal risks.


32

OCIO, 01/03/-1,

Assumptions define conditions not known but under which the project is planned, budgeted, and managed. They can include anything that supports the scope. Aim to tie risks to assumptions and place risks in risk documentation.

OCIO, 01/03/-1,

Complete the chart below identifying the project team members and details concerning their project commitment. Type should be State, Contract, Customer (Business Owner), or Vendor.

OCIO, 01/03/-1,

List the team members, their role, responsibility and functional manager. Make sure to include a comprehensive listing including those from the organization managing the project, business members involved to ensure business objectives are met and the vendor members that may have a specific role.

OCIO, 01/03/-1,

Insert a graphical Organization Chart here. The Organizational Breakdown Structure (OBS) is a hierarchical configuration defining levels of program management and may identify all project personnel. The OBS should be simple and straightforward. Include role names and people’s names. Consider identifying the core project team by shading their respective boxes on the chart. On complex projects, consider using a second OBS to identify core project team. The OBS can also be used for management reporting.



ASMPT-001 n/a

5.3 C5.3 CONSTRAINTSONSTRAINTS33


CSTR-001 n/a

3 Constraints are factors that will limit the project management team’s options. Contractual provisions will generally be considered constraints.


33

OCIO, 01/03/-1,

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.


5.4 D5.4 DEPENDENCIESEPENDENCIES

5.4.1 M5.4.1 MANDATORYANDATORY D DEPENDENCIESEPENDENCIES


5.4.2 D5.4.2 DISCRETIONARYISCRETIONARY D DEPENDENCIESEPENDENCIES


5.4.3 E5.4.3 EXTERNALXTERNAL D DEPENDENCIESEPENDENCIES


EDEP-001

5.5 R5.5 RISKISK M MANAGEMENTANAGEMENT

5.5.1 R5.5.1 RISKISK M MANAGEMENTANAGEMENT S STRATEGYTRATEGY

The purpose of risk tracking is to identify, document and monitor potential risk areas for the New Mexico Project. A risk is identified as the possibility that something will prevent the project from meeting expectations.

Each risk identified will be documented in the Project Risk Assessment Summary Document. Project management will review and track the risks periodically. Risks will be regularly reviewed at weekly project status meetings, as well as the Project Steering Committee meetings when appropriate. In general, risks will be created and maintained by the Project Managers. Risks must have documented mitigations steps that can be followed if the risk is to be reduced or eliminated. In some cases, the mitigation steps will be out of the control of the project team, and may be assigned to New Mexico managers who are not on the project.

The New Mexico project is deploying several risk management techniques to aid in identifying, monitoring and resolving risks. To aid in identifying risk, an initial risk assessment meeting will take place. The purpose of this meeting is to collectively, as a management group, identify and document the initial project risks. Risks identified after this meeting will be documented as part of the projects issue tracking procedures.


34


5.5.2 P5.5.2 PROJECTROJECT R RISKISK I IDENTIFICATIONDENTIFICATION

Risks can be identified in either the initial risk assessment or as an issue that eventually becomes a risk. Risks identified during the initial risk assessment will be documented using the Risk Template as shown in Exhibit 1: New Mexico Risk Template. Issues that become risks will be documented as such in the New Mexico Issue Tracking application and move into the Risk Management facility.

5.5.3 P5.5.3 PROJECTROJECT R RISKISK A ANALYSISNALYSIS

One of the first tasks that the Project Management group will do when the project commences will be to brainstorm project risks and begin tracking and reporting on them.

5.5.4 P5.5.4 PROJECTROJECT R RISKISK M MITIGATIONITIGATION A APPROACHPPROACH

Each risk identified will have at least one mitigation action. These mitigations are designed to help avoid the risk.

5.5.5 R5.5.5 RISKISK R REPORTINGEPORTING ANDAND E ESCALATIONSCALATION S STRATEGYTRATEGY

Ongoing monitoring tasks will be deployed including a monthly Project Management review of all identified risks. In this monthly meeting, all risks will be updated to reflect new developments or mitigation actions as well as next steps.

5.5.6 P5.5.6 PROJECTROJECT R RISKISK T TRACKINGRACKING A APPROACHPPROACH

To better track and define risks, the following procedures will be used. Identify risks as direct or indirect:

Direct risk: a risk that the project has a large degree of control over Indirect risk: a risk with little or no project control

Determine the attributes of a risk: Probability of occurrence Impact on the project (severity)

The two can often be combined in a single risk magnitude indicator: High, Significant, Moderate, Minor, and Low.

For each identified risk, the following information should be documented and tracked: Number of Risk Direct / Indirect Risk Description of risk Status of risk Probability the risk will occur (1-5: 5 = highest) Severity of the risk on the project (1-5: 5 = highest) Ranking of the risk (Probability times Severity)

Low = 1-8, Moderate = 9 – 19, High = 20-25


35


Mitigation actions to avoid or reduce the risk and/or the probability of occurrence Contingency actions to be implemented to minimize the impacts of the risk

Exhibit 1: New Mexico Risk Template

# DIRECT/ INDIRECT

RISK/STATUS PROB-ABILITY

SEVERITY RANK-ING

MITIGATIONACTIONS

RECOVERYACTIONS


36


Team members who become aware of potential risks should document the Issue and send it to their respective Team Lead and Project Manager via email.

The minimum information to report includes:1. The name of the person reporting the risk2. The date of reporting3. A description of the risk4. The affected project activity or activities5. The potential impact on the project6. One or more possible solutions7. Perceived criticality of the risk

The Project Manager will then log the risk in the risk tracking form. The risk tracking form can be found at the DOIT web site and in Appendix D of this document. The Team Lead is then responsible for evaluating the risk at the team level. If it is determined by the Team Lead that the risk is of Medium or High Impact they will be responsible for escalating it to Project Management and updating the Risk on the online repository The minimum information to report includes:

1. The Team Lead escalating the risk2. The date of escalation3. An updated description of the risk (if applicable)4. The affected project activity or activities (if changed)5. The potential impact on the project (if changed)6. One or more possible solutions (if changed)7. The criticality of the risk

The Project Manager is then responsible for tracking the risk and ensuring that it is being mitigated effectively. In addition to tracking of the risks, the Project Manager is also responsible for communicating the High Impact risks to the Business Owners to be sure they understand the impact of the potential risks. This activity should take place in the weekly Project Status Meeting.

5.6 I5.6 INDEPENDENTNDEPENDENT V VERIFICATIONERIFICATION ANDAND V VALIDATIONALIDATION - IV&V - IV&V

For the NMWebFile project, IV&V functionality will be incorporated throughout the project life cycle – as required. Meetings with IV&V vendors from the Best Value Vendor list will be held to determine interest and capability for the project IV&V effort. Pricing assumptions for IV&V activity are based on the latest negotiated vendor price agreements.

The scope of activity for IV&V will defined as a vendor is selected and a Statement of Work is developed for the IV&V engagement. Selection of an IV&V vendor is planned once the PMP has been approved.


37

OCIO, 01/03/-1,

Independent Verification and Validation (IV&V) means the process of evaluating a system 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 development organization. Describe the process that will be employed to meet IV&V requirements.


5.7 S5.7 SCOPECOPE M MANAGEMENTANAGEMENT P PLANLAN

The project team will develop specifications in conjunction with system stakeholders. These specifications will be reviewed with the end users and the Executive Steering Committee for final approval. Acceptance forms will be obtained (with signature) and the Project Manager will be responsible for maintaining a log of such approvals. Periodic project reviews will be scheduled throughout the life of the project with the TRD PMO to ensure consistent and quality based project record keeping.


38

OCIO, 01/03/-1,

Describe the process that is going to be used to manage the scope of the project. Make sure to address managing stakeholder expectations.


5.8 I5.8 ISSUESSUE & C & CHANGEHANGE M MANAGEMENTANAGEMENT

5.8.15.8.1 CCHANGEHANGE C CONTROLONTROL M MANAGEMENTANAGEMENT

The purpose of the Change Control Process is to ensure changes are made in a consistent manner and that the appropriate stakeholders are informed. The Change Control Process also ensures that all identified enhancements, defects and issues are tracked and handled in a consistent manner.

Risks are tracked separately from the rest of the Change Control types using a Risk List. For specific details of the Risk List click on the Risk Plan link.

5.8.25.8.2 CCHANGEHANGE C CONTROLONTROL T TYPESYPES

Defects, Issues, and Enhancements are the categories used for the types of change control. A request can be raised by anyone on the project at any time during the course of the project and are the result of:

Defects Omissions or Flaws found during testing Deviations from requirements/expectations Known defects which are not within the scope of the project

Issues Program (Clarification/decisions) Project (Technology related)

Enhancements Enhancements to existing functionality

5.8.35.8.3 BBUGGITUGGIT OROR F FOGOGBBUGSUGS

These items are entered from the main screen in Buggit.


39


The following fields are required when entering any item:

Issue Type: Defect – material defect in codeIssue – concern or problem in design, code, dataEnhancement – functionality outside of core

Title: Brief description of the bug or issue

Location: Data – Bug, Issue or Enhancement affecting the incoming dataSystem [specify] – Bug, Issue or Enhancement affecting the given systemInterface – Bug, Issue or Enhancement affecting the interfaces between the given system and outside systems

Priority: Used to describe the order in which items are to be corrected

Status: Status is used to indicate the flow of the item through the change management process

Issue Details: A long description of the issue or bug


40


The following fields are required when closing or validating and item:

Resolution: The resolution reason

5.8.45.8.4 CCHANGEHANGE C CONTROLONTROL P PRIORITIZATIONRIORITIZATION

Change Control items will be classified by Priority. The Priority will be used to determine how quickly the item needs to be corrected. The assignments will be based on:

Priority – The relative importance assigned to an item 0 - Not assigned1 - Must Fix – Immediately2 - Should Fix – Important, fix as soon as possible3 - Fix when we have time4 - Low Priority / Cosmetic

5.8.55.8.5 CCHANGEHANGE C CONTROLONTROL S STATUSTATUS

Change control items will move through the change management process via statuses. The status indicates where the item resides within the process. See the change control flow.Status – indicates where the item resides in the change management process

Closed - Indicates that an item no longer requires the attention of the project staffFixed - Indicates that an item has been corrected by the project staff and is ready for

testingOpen - Indicates that an item is in process of being correctedReopen - Indicates that an item has been reopened for not passing validationSubmitted - Indicates that in item has been entered and is beginning the change management

processValidated - Indicates that an item has been tested and has passed validation and is

incorporated into the project.

5.8.65.8.6 MMEETINGEETING/R/REVIEWEVIEW S SCHEDULECHEDULE

The Technical Advisory Group (TAG) acting as the Change Control Board is the first level of review for Bugs and Issues. They have the authority to approve or deny all Requests.

If the review of a Bug or Issue results in a request being accepted as a valid request the team will confirm the Priority of the Request. If the Request is outside TAG teams’ area of authority the team will have the appropriate category associated to the Request and have it submitted to the appropriate team for review.


41


5.8.75.8.7 CCHANGEHANGE R REQUESTEQUEST N NOTIFICATIONOTIFICATION The Change Control Request Status Report will be reviewed periodically. This report lists the status of all Change Control Requests that have been assigned. Also, the Notification will be used to document any other issues that are being resolved through the Change Control Process.

5.8.85.8.8 TTECHNICALECHNICAL A ADVISORYDVISORY G GROUPROUP (TAG) (TAG)The Technical Advisory Group acting as the Change Control Board will be comprised of the following people who will attend (on an as-needed basis) a weekly meeting to review, schedule and discuss the status of the change requests and approve or deny Change Requests:

Client PM Vendor PM

The purpose of the Change Control Board meeting will be to review the following change requests: Change requests which have been submitted Changes which have been rejected Changes to be backed out Changes to be scheduled for the next build

If the CCB is unable to come to a conclusion regarding the status or scope of a request, the request will be forwarded to the Project Manager for recommendation/approval. The PM has complete authority to approve or deny all requests.


42


5.8.95.8.9 CCHANGEHANGE C CONTROLONTROL F FLOWLOW


43


5.8.105.8.10 CCHANGEHANGE C CONTROLONTROL B BOARDOARD (CCB) (CCB)

The Change Control Board for this project will be the Executive Steering Committee. All scope changes will be logged by the Project Manager in the change system with any impact reported in status and other associated project documents. The project manager will manage all change control process for the system utilizing the defined change management system.

5.9 P5.9 PROJECTROJECT T TIMELINEIMELINE

MS Project Plan will be developed after the contract is awarded.


44

OCIO, 01/03/-1,

The project timeline is a high-level view of project activities with a focus on project milestones. The project timeline does not replace the need for a detailed project schedule and it is to highlight key events such as deliverable due dates and when go/no-go decisions are made. A summary-level Gantt chart can be used to meet the timeline requirement. The detailed project schedule should be referenced as Appendix B.

OCIO, 01/03/-1,

Insert a graphic or textual description identifying the Change Control Board (or function) for this project. The CCB may be an individual or group of individuals authorized to approve changes to the project plan.


5.10 P5.10 PROJECTROJECT B BUDGETUDGET

System or Project Cost (dollars in thousands)


45


Expenditure Categories (dollars in thousands)


46


System Development Deployment (check when expected to be completed):

FY04& Prior FY05 FY06 FY07 FY08

FY09& Subseq.

Needs Assess. X

Data Modeling

X

Hardware Acquis’n

X

New Systems Installed

X

Fully Op- erational

X

Mainte-Nance X X X X

5.11 C5.11 COMMUNICATIONOMMUNICATION P PLANLAN

The project team will develop the Communication Plan and Communication Matrix after the project has been initiated.

5.11.1 C5.11.1 COMMUNICATIONOMMUNICATION M MATRIXATRIX

TBD

5.11.2 S5.11.2 STATUSTATUS M MEETINGSEETINGS

The project team will hold regular meetings, at least weekly. The Executive Steering Committee will meet monthly for regular meetings and will be convened on a more frequent basis, as necessary.

5.11.3 P5.11.3 PROJECTROJECT S STATUSTATUS R REPORTSEPORTS

All team members will be responsible for preparing a weekly status report to communicate accomplishments, issues, risks, and work plans for the prior and upcoming week. The Project Manager will consolidate status and a project status will be completed each week. Monthly, the Project Manager will prepare an DOIT monthly status that will be forwarded to the TRD PMO on the first of the month. The TRD PMO will forward the consolidated status (for all TRD projects) to the DOIT on the regular reporting schedule.


47

OCIO, 01/03/-1,

Communication planning involves determining the information and communication needs of the stakeholders, executive sponsors, project team and others as needed. The communication plan needs to address who needs what information, when they will need it, how it will be given to them, and by whom. The complexity of the project may require a separate communication plan; however a high level summary of that plan will need to be included here and a reference made to the appropriate Appendix.


5.12 P5.12 PERFORMANCEERFORMANCE M MEASUREMENTEASUREMENT (P(PROJECTROJECT M METRICSETRICS))

The project team will develop proposed metrics once the project is initiated. Metrics will be reviewed with the Executive Steering Committee and ultimately passed to the Business Owners for management after system implementation.

5.13 Q5.13 QUALITYUALITY O OBJECTIVESBJECTIVES ANDAND C CONTROLONTROL

There are a number of considerations for quality and control for this project. The following objectives will be analyzed for potential metrics by the project team with a goal of selecting a number of the most relevant objectives and determining meaningful measurements that will positively reflect the attainment of that objective.

6.0 P6.0 PROJECTROJECT C CLOSELOSE

6.1 A6.1 ADMINISTRATIVEDMINISTRATIVE C CLOSELOSE

Items that required administrative close: All deliverables as specified in this document must be completed and accepted. The system must be accepted by TRD, in writing. Deliverable Acceptance Form – for every formal deliverable in the phase, deliverable acceptance

form: see Appendix E Acceptance Management, must be signed and filed in the Project Workbook.

Baseline Verification – Project deliverables should be inventoried and the project archives updated with the current artifacts.

Staff Transition Completed – As the project schedule is completed, staff members should be transferred to other projects to perform work.

Lessons Learned – Lessons learned sessions should be conducted postmortem to the phase/ project and incorporated into future project plans, procedure, and artifacts.

6.2 C6.2 CONTRACTONTRACT C CLOSELOSE

In addition to the Administrative Close, the following actions should be taken to complete Contract Close:

Procurement Audit – The Project Manager, TRD CIO and TRD PMO Manager should review the vendor Agreement Terms and Conditions to ensure all items and met and/or disposition agreed upon by both parties.

Contract File Creation – A contract file, archiving all project and contractual documentation should be baselined and archived, including invoices, costs, and project documentation.

Formal Acceptance and Close – A document that accepts the contract completion and closure should be submitted by the vendor, accepted by TRD and filed in the Contract File.


48

OCIO, 01/03/-1,

Contract close is similar to administrative close in that it involves product and process verification for contract close.

OCIO, 01/03/-1,

Administrative Close occurs at both the end of phase and end of project. This closure consists of verification that objectives and deliverables were met. Acceptance is formalized and phase activities are administratively closed out. Administrative closure occurs on a “by-phase” basis in accordance with the WBS and should not be delayed to project end. At that point, the burden of closing is too great and audits inaccurate. The specific project close activities for a given project is contingent on the project’s complexity and size. Project managers should work with the project’s project management consultant to tailored Project Close procedures to compliment the project’s objectives

OCIO, 01/03/-1,

Project Close will always consist of administrative project activities and possibly contractual project activities and an external vendor is employed. Completing both sets of activities is a mandatory step in the project life cycle. Administrative activities complete the internal needs for the Agency/Unit that is responsible for managing the project, such as lessons learned, recording the last hours against the project, and providing transition for the staff to other assignments. Contractual activities meet the contractual needs, such as executing a procurement audit and formal acceptance of the project work products.

OCIO, 01/03/-1,

Configuration Management determines how project information (files, reports, designs, memos, documents, etc.) will be managed (tracked, approved, stored, secured, accessed, version control, etc.) and owned by (e.g., Agency managing the project or the Customer). Standards and team awareness are critical.

OCIO, 01/03/-1,

Quality Management includes the processes required to ensure that the project will satisfy the needs for which it was undertaken. It includes all activities of the overall management function that determine the quality policy, objectives, quality assurance, quality control, and quality improvement, within the quality system. If a separate Quality Plan is used, include a high level summary in this document and refer to the appropriate appendix.

OCIO, 01/03/-1,

The Project Manager and Executive Sponsor define the project metrics that will be used to control the project. Each project will need to have an established metrics program. Metrics are collected for measuring the progress of a project against its planned budget, schedule, resource usage, and error rates, and of establishing a historical database, which will aid in planning and forecasting future projects. At a minimum metrics must be established for time (schedule), cost (budget) and quality.


7.0 G7.0 GLOSSARYLOSSARY

7.1 A7.1 ACRONYMSCRONYMS ANDAND A ABBREVIATIONSBBREVIATIONS

DOIT Department of Information TechnologyIPP Integrated Project PlanPMI Project Management Institute.PMBOK Project Management Body of KnowledgePMC Program Management ConsultantPMO Program Management OfficePMP Project Management PlanQM Quality ManagementWBS Work Breakdown Structure

7.2 D7.2 DEFINITIONSEFINITIONS

Acceptance Criteria

The criteria that a system or component must satisfy in order to be accepted by a user, customer, or other authorized entity. [IEEE-STD-610]

Acceptance Testing

Formal testing conducted to determine whether or not a system satisfies its acceptance criteria and to enable the customer to determine whether or not to accept the system. [IEE-STD-610]

Assumptions

Planning factors that, for planning purposes, will be considered true, real, or certain. Assumptions generally involve a degree of risk. They may be documented here, or converted to formal risks.

Baseline

A specification or product that has been formally reviewed and agreed upon that thereafter serves as the basis for further development, and that can be changed only through formal change control procedures. [IEEE-STD-610]

Commitment

A pact that is freely assumed, visible, and expected to be kept by all parties.

Configuration Management (CM)

A discipline applying technical and administrative direction and surveillance to identify and document the functional and physical characteristics of a configuration item, control changes to those characteristics, record and report change processing and implementation status, and verify compliance with specified requirements. [IEEE-STD-610]


49


Configuration Management Library System

The tools and procedures to access the contents of the software baseline library.

Constraints

Factors that will (or do) limit the project management team’s options. Contract provisions will generally be considered constraints.

Contingency Planning

The development of a management plan that identifies alternative strategies to be used to ensure project success if specified risk events occur.

Crashing

Taking action to decrease the total duration after analyzing a number of alternatives to determine how to get the maximum duration compression for the least cost.

Critical Path

The series of activities that determines the duration of the project. The critical path usually defined as those activities with float less than or equal to specified value often zero. It is the longest path through the project.

Dependencies, Discretionary

Dependencies defined by the project management team. They should be used with care and usually revolve around current Best Practices in a particular application area. They are sometimes referred to as soft logic, preferred logic, or preferential logic. This may also encompass particular approaches because a specific sequence of activities is preferred, but not mandatory in the project life cycle.

Dependencies, Mandatory

Dependencies that are inherent to the work being done. In some cases, they are referred to as hard logic.

Dependency Item

A product, action, piece of information, etc., that must be provided by one individual or group to a second individual or group so they can perform a planned task.

Deliverable

Any measurable, tangible, verifiable outcome, result, or item that must be produced to complete a project or part of a project that is subject to approval by the project sponsor or customer.

Duration

The number of work periods (not including holidays or other nonworking periods) required to complete an activity or other project element.

Duration Compression

Shortening the project schedule without reducing the project scope. Often increases the project cost.

End User

The individual or group who will use the system for its intended operational use when it is deployed in its environment.


50


Effort

The number of labor units required to complete an activity or other project element. Usually expressed as staff hours, staff days, or staff weeks.

Fast Tracking

Compressing the project schedule by overlapping activities that would normally be done in sequence, such as design and construction.

Float

The amount of time that an activity may be delayed from its early start without delaying the project finished date.

Formal Review

A formal meeting at which a product is presented to the end user, customer, or other interested parties for comment and approval. It can also be a review of the management and technical activities and of the progress of the project.

Integrated Project Plan

A plan created by the project manager reflecting all approved projects and sub-projects.

Lessons Learned

The learning gained from the process of performing the project. Lessons learned may be identified at any point during the execution of the project.

Method

A reasonably complete set of rules and criteria that establish a precise and repeatable way of performing a task and arriving at a desired result.

Methodology

A collection of methods, procedures, and standards that defines an integrated synthesis of engineering approaches to the development of a product.

Milestone

A scheduled event for which some individual is accountable and that is used to measure progress.

Non-technical Requirements

Agreements, conditions, and/or contractual terms that affect and determine the management activities of an architectural and software project.

Performance Reporting

Collecting and disseminating performance information. This includes status reporting measurement, and forecasting.

Procurement Planning

Determining what to procure and when.

Product Scope

The features and functions that characterize a product or service.


51


Project Leader (Technical)

The leader of a technical team for a specific task, who has technical responsibility and provides technical direction to the staff working on the task.

Project Management

The application of knowledge, skills, tools, and techniques to project activities to meet the project requirements. Project Management is also responsible for the oversight of the development and delivery of the architecture and software project.

Program

A group of related projects managed in a coordinated way. Programs include an element of ongoing work.

Program Management Office

An organizational entity responsible for management and oversight of the organization’s projects. As a specific reference in this document, the Department of Information Technology.

Project Manager

The role with total business responsibility for an entire project. The individual who directs, controls, administers, and regulates a project. The project manager is the individual ultimately responsible to the customer.

Project Charter

A document issued by senior management that formally authorizes the existence of a project. It provides the project manager with the authority to apply organizational resources to project activities.


A formal, approved document used to guide both project execution and project control. The primary uses of the project plan are to document planning assumptions and decisions, facilitate communication among stakeholders, and documents approved scope, cost, and schedule baselines. The Project Management Plan (PMP) is a project plan.

Project Schedule

A tool used to indicate the planned dates, dependencies, and assigned resources for performing activities and for meeting milestones. Software products such as ABT’s Workbench and Microsoft Project are tools used to develop project schedules.

Project Scope

The work that must be done to deliver a product with the specified features and functions.

Project Sponsor

The individual that provides the primary sponsorship for an approved project. This individual will play a key role in securing funding, negotiating for resources, facilitating resolution of critical organizational issues, and approving key project deliverables.

Quality

The degree to which a system, component, or process meets specified requirements.


52


The degree to which a system, component, or process meets customer or user needs or expectations. [IEEE-STD-610]

Quality Management

The process of monitoring specific project results to determine id they comply with relevant standards and identifying ways to eliminate causes of product non-compliance.

Risk

Possibility of suffering loss.

Risk Management

An approach to problem analysis, which weighs risk in a situation by using risk probabilities to give a more accurate understanding of, the risks involved. Risk Management includes risk identification, analysis, prioritization, and control.

Risk Management Plan

The collection of plans that describes the Risk Management activities to be performed on a project.

Risk Management

Risk mitigation seeks to reduce the probability and/ or impact of a risk to below an acceptable threshold.

Scope Change

Any change to the project scope. A scope change almost always requires an adjustment to the project cost or schedule.

Software Life Cycle

The period of time that begins when a software product is conceived and ends when the software is no longer available for use. The Software Life Cycle typically includes a concept phase, requirements phase, design phase, implementation phase, test phase, installation, and checkout phase, operation and maintenance phase, and, sometimes, retirement phase.

Stakeholder

Individuals and organizations that are actively involved in the project, or whose interests may be positively or negatively affected as a result of project execution or project completion. They may also exert influence over the project and its results.


53


Standard

Mandatory requirements employed and enforced to prescribe a disciplined uniform approach to software development

Statement of Work

A description of all the work required completing a project, which is provided by the customer.

System Requirements

A condition or capability that must be met or possessed by a system component to satisfy a condition or capability needed by a user to solve a problem. [IEEE-STD-610]

Subproject

A smaller portion of the overall project.

Task

A sequence of instructions treated as a basic unit of work. [IEEE-STD-610]

A well-defined unit of work in the software process that provides management with a visible checkpoint into the status of the project. Tasks have readiness criteria (preconditions) and completion criteria (post conditions). (see activity for contrast.)

Team

A collection of people, often drawn from diverse but related groups, assigned to perform a well-defined function for an organization or a project. Team members may be part-time participants of the team and have other primary responsibilities.

Technical Requirements

Those requirements that describe what the software must do and its operational constraints. Examples of technical requirements include functional, performance, interface, and quality requirements.

Traceability

The degree to which a relationship can be established between two or more products of the development process, especially products having a predecessor-successor or master-subordinate relationship to one another. [IEEE-STD-610]

Work Breakdown Structure

A deliverable-oriented grouping of project elements that organizes and defines the total work scope of the project. Each descending level represents an increasingly detailed definition of the project work.


54


APPENDIX A—SAPPENDIX A—SCOPECOPE D DEFINITIONEFINITION D DOCUMENTOCUMENT


55


Project Initiation and Planning Identify Team resources Confirm project scope and targeted process areas Validate assumptions and constraints Schedule and conduct kick-off meeting Finalize project work plan and schedule Establish communication and risk plan Develop issue tracking process Prepare work environment Collect critical documentation

Project Execution Review existing detailed documentation Interview key subject-matter-experts Assess Current State of Organization

o Organizational structure, roles and responsibilitieso Current business processeso Current data flowso Current architecture, technology and infrastructureo Document current environment


56


Design and Implementationo Develop Modelo Develop Databaseso Develop XML Schemao Obtain acceptance of each deliverableo Component Testingo Manage all issues, changes, and riskso Perform quality assurance activities

Project Closure Present findings Archive appropriate project information Perform post-implementation review Track applicable metrics


57


A.1 DA.1 DELIVERABLESELIVERABLES T TIMELINEIMELINE


58


APPENDIX B --IAPPENDIX B --ISSUESSUE M MANAGEMENTANAGEMENT


59



60


IISSUESSUE M MANAGEMENTANAGEMENT L LOGOG

PROJECT: PROJECT:

AGENCY:AGENCY: DATE:DATE: PROJECT MANAGER:PROJECT MANAGER: PROJECT #:PROJECT #:

ID:ID: DESCRIPTION:DESCRIPTION:OCCURRENCE OCCURRENCE DATE:DATE: OWNER:OWNER: SEVERITY:SEVERITY: COMMENTS:COMMENTS: STATUS:STATUS:

RESOLVED RESOLVED DATE:DATE:

61


APPENDIX C--CAPPENDIX C--CHANGEHANGE C CONTROLONTROL

62


63


APPENDIX D--RAPPENDIX D--RISKISK M MANAGEMENTANAGEMENT

64


RRISKISK R REPORTEPORT Project:

SECTION I: INITIAL NOTIFICATION

REPORTED BY: REPORTED DATE:

DESCRIPTION:

PROBABILITY OF OCCURRENCE:

SEVERITY OF IMPACT ON PROJECT:

MITIGATION STRATEGY:

INITIAL CRITICALITY: (MARK ONE)

LOW RISK, GREEN MEDIUM RISK, YELLOW HIGH RISK, RED

SECTION II: STATUS TRACKING INFORMATION

NAME OF RISK: TRACKING ID:

RISK CLASSIFICATION: TARGET DATE:

ASSIGNED BUSINESS OWNER: ASSIGNMENT DATE:

CURRENT CRITICALITY: (MARK ONE)

LOW RISK, GREEN MEDIUM RISK, YELLOW HIGH RISK, RED

65


SECTION III: ANALYSIS

NAME OF RISK: TRACKING ID:

DETAILED SEVERITY OF IMPACT:

ESTIMATED DOLLAR VALUE OF IMPACT:

BASIS FOR ESTIMATED PROBABILITY:

ESTIMATED PROBABILITY OF OCCURRENCE:

MITIGATION STRATEGY:

CONTINGENCY PLAN:

SECTION IV: EVENT TRACKING

DESCRIPTION OF EVENT: DATE TAKEN: RESULTING DECISION:

INITIAL ANALYSIS COMPLETED:

FIRST PROJECT STATUS REPORT MADE:

CLOSED:

66


APPENDIX E--AAPPENDIX E--ACCEPTANCECCEPTANCE M MANAGEMENTANAGEMENT

67

Deliverable Acceptance FormDeliverable Description: __________________________________________________________

RequirementNumber

Requirement Description Tested By DatePrinted Name Signature

Project Manager (PM) Acceptance

PM Representative Acceptance

68