Agile Lean Product Development

Project Management Plan

for

Project HELP DESK

Prepared by

Tom Sheives, PhD, PMP

Project Management Plan

The Project Management Plan (PM Plan) is used to drive the successful completion of Project HELP DESK. It consists of documents that support the work associated with the initiation, planning, executing, monitoring and controlling and closing processes. It has been developed primarily within the planning process group although its use is throughout all the process groups

The PM Plan is comprised of the following documents for Project HELP DESK:

PM Plan Component Page Number

Project Charter 4

Scope Statement 5

Scope Management Plan 8

Change Management Plan 9

Work Breakdown Structure 12

Schedule Management Plan 15

Project Schedule 18

Cost Management Plan 20

Issue Management Plan 22

Risk Management Plan 24

Staffing Management Plan 27

Configuration Management Plan 31

Procurement Management Plan 35

Communications Management Plan 37

Quality Management Plan 40

Project Closure Plan 42

Project Charter

Scope Statement – Revision Control

All project management plan documents should have revision control similar to above.

Scope Statement

Scope Management Plan

1. Introduction

This document will describe how the scope will be collected and managed throughout the HELP DESK project providing to ensure that “no more” or “no less” scope is delivered.

2. Scope Statement

The scope statement for HELP DESK describes what is in the project and what is not. The scope statement will be version controlled and is used to drive the creation of the WBS for project HELP DESK. See Scope Statement document.

3. WBS Process

The WBS for project HELP DESK will follow the procedure for other service related projects. The structure for the WBS will be the Life Cycle Approach with the addition of Project Management.

The WBS will be generated using the scope statement and several iterative meetings of core teams with key stakeholders. A High Level Requirements document will be completed for this project which will drive a significant amount of the scope for this project. This high level requirements document is a part of the WBS and will actually be conducted in parallel during the creation of the WBS. The WBS process accomplished by the teams will use the brainstorming approach to make sure all the work is captured. The WBS for HELP DESK will be captured in Microsoft Office Project 2003 and displayed using WBS ChartPro from www.criticaltools.com .

4. Scope Baseline Process

This process is described here but applies to changes to scope, time, or cost. Even though the project scope for HELP DESK should be somewhat clearly defined and baselined, since this is the first type of project done like this in customer service, it is likely that changes will occur. During the first 3 months of the project it is likely that changes will occur on a weekly basis. After that time period, the only changes that might happen are those associated with the completion of the pilot test.

Since project HELP DESK can be defined rather succinctly after the completion of the High Level Requirements document, progressive elaboration is not likely. Hence, after the High Level Requirements document are complete, all the work associated with delivering that functionality will be identified in the WBS. It is at this point that after a management review and peer review with stakeholders that the scope statement and the WBS will be baselined. Any changes to the scope baseline must follow the procedures outlined below in the scope change management process.

5. Scope Change Management Process

The scope change management plan utilizes the change control process described in the Change Management plan. Changes to scope statement baseline or to the WBS baseline that result in 5% more effort measured in person hours should be reviewed as a Class I change. Other changes are reviewed according to the Change Management Plan.

Change Management Plan

1. Introduction

Changes to the scope, time (schedule), or cost require the change control process.

The objectives of the Change Management Process are:

· To manage change to ensure that the scope, cost, schedule, and quality of projects are monitored and controlled.

· To ensure that each request for change is assessed by the appropriate key project players.

· To allow each change request to be accepted, rejected or deferred with the appropriate authority.

· To enable the orderly implementation of each accepted change.

· To identify and manage the impact of all changes.

· To ensure that small changes are managed with a minimum of overhead.

· To effectively communicate the status of change requests.

2. Change Control Process

The change control process is described in the diagram below. Two categories of change have been identified for the project change-management process.

· Class I—Potentially significant impact (over >5%) more resources, time, cost and scope. (The Class I change process will be applied only to the top five priority projects.)

· Class II—Minimal impact (under 5%) to resources, time, cost and scope.

PM sends

request to

change

control team

Change Control

team reviews

change

Notify

Requestor and

Key

stakeholders

Notify

Requestor and

Key

stakeholders

Fill out

change

control log

Fill out

change

control log

Modify

project

plan

Store

change

documents

Change

control

process

complete

Class I and Class II Change

Reject

Approve

Class I

Change

PM Reviews Change

Request

Approve

Disapprove

Change

Change

Requested

3. Change Control Form

The change control form is used to request changes to the project management plan deliverables. Example of a completed change control form is:

PROJECT CHANGE REQUEST

FORMCHECKBOX Charter  FORMCHECKBOX FRS  FORMCHECKBOX Non-FRS  FORMCHECKBOX SDS  FORMCHECKBOX SA Design  FORMCHECKBOX UI Spec.  FORMCHECKBOX Schedule  FORMCHECKBOX Other

.

4. Change Control Log

5. Documents Covered under the Change Control Process

During the life of the project, change control should be implemented when a deliverable/work product are considered baselined. Primary deliverables to be considered subject to project change control include:

· Project Charter

· Scope Statement

· WBS-Project Schedule

· Project Cost

· Functional Requirement Specifications (FRS)

· Nonfunctional Requirement Specifications

· System Architecture Design

· Integration/System Test Plan

· UI Design Specifications

The basic rule of thumb for all other major project deliverables not mentioned above would be to implement change control when the deliverable is considered baselined. This would include items such as HELP DESK procedure drawings, requirements, etc.

6. Excluded elements in the Change Management Process

The change-management process will utilize, but will not be responsible for Software “bugs” processes or changes to code to resolve such problems. These are primarily handled in the Developer’s Internal Bug Fixing/Tracking process.

Work Breakdown Structure (WBS) – Microsoft Project View

ID

Task Name

1

Project HELP DESK

2

Requirements

3

Gap Analysis

4

High Level Requirements

5

Elicit High Level Requirements

6

Analyze High Level Requirements

7

Write High Level Specifications

8

Validate High Level Requirements

9

Detailed Requirements

10

Elicit Detailed Level Requirements

11

Analyze Detailed Level Requirements

12

Write Detailed Level Specifications

13

Validate Detailed Requirements

14

Requirements Verification and Test

15

Design

16

Sytems Design

17

Conduct Achitecture Tradeoffs

18

Parse Components into Hardware and Software

19

Design User Interface

20

Design Network Management

21

Design HELP DESK Procedures

22

Software Design

23

Design High Level COTS

24

Design High Level Application

25

Design Detailed User Interface

26

Hardware Design

27

Design User Workstation

28

Design Server Configuration

29

Pilot

30

Pilot Implementation

31

Install Server Pilot Hardware

32

Install Server COTS Software

33

Build Custom Pilot Software

34

Conduct Subsystem Tests

35

Conduct System Tests

36

Pilot Test

37

Design Pilot Tests

38

Conduct Pilot Tests

39

Analyze Results

40

Update Design

41

Update Build

42

Update Procedures

43

Production System

44

Production Implementation

45

Install Production Server Hardware

46

Install Production Server COTS Software

47

Build Custom Production Software

48

Conduct Subsystem ProductionTests

49

Conduct System Production Tests

50

Production Test

51

Design Production Tests

52

Conduct Production Tests

53

Analyze Results

54

Update Design

55

Update Build

56

Update Procedures

57

Cutover

58

Design Transition Plan

59

Test Operational System

60

Notify Customers

61

Cutover to Production

62

Maintain System - 2 Months

T

W

T

F

S

S

M

T

W

T

F

S

S

M

T

W

T

F

S

S

M

T

W

T

F

S

S

M

T

W

T

F

S

S

Oct 29, '06

Nov 5, '06

Nov 12, '06

Nov 19, '06

Nov 26, '06

Dec 3, '06

IDTask Name

1Project HELP DESK

2Requirements

3Gap Analysis

4High Level Requirements

5Elicit High Level Requirements

6Analyze High Level Requirements

7Write High Level Specifications

8Validate High Level Requirements

9Detailed Requirements

10Elicit Detailed Level Requirements

11Analyze Detailed Level Requirements

12Write Detailed Level Specifications

13Validate Detailed Requirements

14Requirements Verification and Test

15Design

16Sytems Design

17Conduct Achitecture Tradeoffs

18Parse Components into Hardware and Software

19Design User Interface

20Design Network Management

21Design HELP DESK Procedures

22Software Design

23Design High Level COTS

24Design High Level Application

25Design Detailed User Interface

26Hardware Design

27Design User Workstation

28Design Server Configuration

29Pilot

30Pilot Implementation

31Install Server Pilot Hardware

32Install Server COTS Software

33Build Custom Pilot Software

34Conduct Subsystem Tests

35Conduct System Tests

36Pilot Test

37Design Pilot Tests

38Conduct Pilot Tests

39Analyze Results

40Update Design

41Update Build

42Update Procedures

43Production System

44Production Implementation

45Install Production Server Hardware

46Install Production Server COTS Software

47Build Custom Production Software

48Conduct Subsystem ProductionTests

49Conduct System Production Tests

50Production Test

51Design Production Tests

52Conduct Production Tests

53Analyze Results

54Update Design

55Update Build

56Update Procedures

57Cutover

58Design Transition Plan

59Test Operational System

60Notify Customers

61Cutover to Production

62Maintain System - 2 Months

TWTFSSMTWTFSSMTWTFSSMTWTFSSMTWTFSS

Oct 29, '06Nov 5, '06Nov 12, '06Nov 19, '06Nov 26, '06Dec 3, '06

Work Breakdown Structure (WBS) – (Cont.)

WBS Graphic View

Schedule Management Plan

Purpose – The purpose of this document is to describe the process that the project manager will use to manage and update the schedule for the HELP DESK project.

Schedule Storage Locations – The latest versions of all schedules will be maintained at a common shared drive location:

C:\1010_WorkingSchedules on xxx\documents\xyz\TCS1010 \Schedules

Hub Project – It is likely that a HUB project will not be required. However, if a HUB project is required, the external dependencies outside project manager’s responsibility will be placed in a hub project. These will be referred to as gives and gets between sub projects. Hence, the consolidation that has been going on to move the external links to the top of your Project files, will be moved one step higher to the Hub project.

Schedule Quality – Schedule quality will determine the overall benefit to the planning and forecasting effort. Schedule quality will be self assessed by each project manager using the schedule quality checklist that is attached, during the beginning of the project and monitored throughout the project. Significant gaps that are identified will be addressed and improved.

Schedule Baselines and Interim Plans – The primary goal of the properly managed schedule baselines and interim plans is the following: allow the project manager and project director to track the project schedule progress relative to the original plan (baseline) and to also show changes that occur from week to week relative to an interim plan.

Schedule Baselines –

Baseline Initiation –

· Schedules will be baselined once a reasonable plan has been put together where the users of the plan are confident that the schedule can be used as an effective decision making tool. Not all will be known when the initial baseline is generated.

· Use deadlines for Target dates for key milestone deliverables

· HUB baselines and project baselines do not need to be baselined or re-baselined at the same time.

· Baselines should be valid for months not weeks.

· Baselines for individual projects should not be originally baselined or “re-baselined” without agreement from the project director.

Baseline Viewing –

· Baselines on projects when viewed on the Tracking Gantt should use the standard bar graph as shown here by the grey shaded bar below.

Re-Baselining –

· A new baseline will be generated if significant changes to the project have occurred to cause the existing baseline to be no longer effective in driving the project.

· Comparisons of the existing plan to any of the previous baselines will be preserved, hence, do not clear or change a baseline in the project or HUB schedules

· Interim Plans (No requirement now.. more later.. for this…”under construction” – Interim plans save Finish and Start dates only and you can have up to 10 interim plans (Start1, Finish1, …Start10, Finish10) ; Save an interim plan to look at differences most between current vale and last “saved” interim plan value. Values can be reviewed in the Task Sheet view and compared to Baseline and updated plan)

Schedule Updates –

· Updates to the schedule are done weekly, prior to the individual project review meeting.

· Tracking Gantt view should be used to show revised plans and progress on the work

· Updates to schedule by task should include

· updating the actual start (Act Start) and actual finish (Act Finish) dates in the Tracking Table view

· Updating the remaining duration in the Tracking Table view

· Update any new resource assignments or new resource constraints (such as resource availability)

Schedule Status –

· Changes to planned values from previous week need to be highlighted in the review meeting

· Critical path items must be reviewed weekly and shown and discussed at the weekly review meeting

· Tasks that are currently due this week or have not completed by this week should be shown in a tabular view

· Any changes to actual late starts, planned late starts, planned late finishes need to be noted and highlighted

· For those tasks that have late finishes, please use the Project Tool feature of adding a note giving the date and describing the reason for the lateness by task

· A standard view for showing schedules at the weekly project review meeting will be used. (view is TBD)

· Use Project Tool to filter out all those tasks that are later the baseline planned late values and show in the weekly meeting

Schedule Metrics and Trends –

The following graph will be used to track progress. We are investigating ways to automate this for easier collection and updating.

Actual vs Planned Finishes

Integration - Example Only

0

20

40

60

80

100

120

140

051015202530354045

Weeks

# Finishes

Cumulative Planned #

Planned Finishes

Cumulative Actual #

Planned Finishes

Naming Conventions for Externally Linked Tasks – Names should have some 3 letter identifier at front to indicate where task comes from and to.

Resource Assignment and Tracking– Common resource pool by physical location will be set up in a stand alone project in the shared location. All project managers at a location will use the common resource pool. Pool information will be managed by individual project managers responsible for the resource. All tasks must have resources assigned to them using either existing named individuals or New-Hire designee, Contractor, other. All areas that have over-allocated resources will be highlighted and shared in the biweekly status meeting. A common naming convention of first name, last name will be used. If conflicts exist, use middle initial.

(Issues – To effectively use the resource pool for over-allocation, % allocation and consistency in use must be applied relative to fixed duration and fixed effort.)

Remote Access - Instructions for remote access using Citrix terminal server. This will significantly reduce the time to open, update and close Project Tool files when not on a local LAN.

Project Schedule

Project Schedule (cont)

Cost Management Plan

1. Introduction

The purpose of the Cost Management Plan is to describe how costs for HELP DESK will be estimated, planned, monitored and controlled during the course of the project. This includes how to hand cost overruns and corrective action procedures for these overruns.

2. Cost Estimates

Budgetary estimates were used in the approval of the project and were included in the project charter. As is customary, these costs are within +/- 50% in terms of accuracy since the project requirements had not been clearly defined nor had the detailed work been planned.

Cost estimates in the planning phase of the project will use bottom up estimates derived from the detail contained in the WBS. Cost estimates will be divided up for each WBS element in the following way:

Labor Hours – hrs

Labor Cost - $dollars

Contract Labor Cost - $dollars

Materials Cost - $dollars

Equipment Cost – Project Use Only - $Dollars

Equipment Cost – Overhead - $Dollars

Facilities Cost - $Dollars

The Chart of Accounts specified in Accounting Procedure 25-2006-05 will be used for collecting all project and non-project specific costs. These costs should be mapped to the Code of Accounts specified by the WBS.

Cost Contingency – A management reserve of 10% should be included at the high level of project cost. Individual reserves or contingencies at the WBS level must be approved by the project manager.

3. Cost Budget

The Cost Baseline or Budget for the project is included in the Microsoft Project Schedule. The estimated cost summary for the project is:

Labor Hours – 9600 hrs

Labor Costs - $1,425,800

Contract Labor Cost - $248,000

Materials Cost - $50,500

Equipment Cost – Project Use Only - $75,100

Equipment Cost – Overhead - $25,700

Facilities Cost - $25,700/month (Lease)

Management Reserve - $150,000

4. Cost Control

The project team has a full time Project Cost Administrator to help regularly keep the project on track from a cost perspective. The cost control mechanisms will include:

· Weekly review of all scope changes and impacts on project

· Biweekly meeting to specifically review cost estimates and cost actuals by WBS element

· Biweekly meeting to review risks and any changes to risks.

· Revised Cost estimates on individual work elements that exceed 5% must obtain review and updates and modifications to the cost management budget following the change control procedure.

· Ongoing weekly efforts on reducing scope or time would be used to counter any potential cost overruns.

The Project Cost Administrator will prepare cost actuals and compare with cost estimates on a weekly basis. Earned value for Cost Performance will be used to track costs and forecast Estimates at Completion.

Contractor Cost Control - Cost management practices for contractors include formal methods for monitoring and controlling contractor cost performance and minimizing risk. Specific contractor tasks are identified and are detailed in the appropriate Microsoft Project plan. Enforced flow down of technical, schedule, and contractual requirements are incorporated into individual statements of work in each delivery order. Contract management has been given the dual responsibility of ensuring that 1) lines of communication remain open for the exchange of information and 2) negotiated agreements are not compromised.

The HELP DESK Project uses a review and reporting system that requires contractor evaluation and is consistent with contracting requirements. A monthly contractor’s status report including any variances in cost, schedule, or technical performance will be included in the monthly program reviews. The same problem identification and resolution procedures used by the CM Group are extended to the subcontractor, to ensure management visibility and to guarantee that proper and prompt attention is given to risk management and reduction on a program-wide basis.

The technical managers manage the contractor costs directly. They are chartered with the responsibility of monitoring contractor costs and schedules for adherence to budget. They will report directly to the PM, thus ensuring that the PM will have immediate insight into all contractor cost control.

Issue Management

1. Introduction

.A project issue for project HELP DESK is defined as 1) a statement of concern that may affect project scope, risk, schedule, cost and/or system quality that 2) cannot be resolved by the person who has identified the concern and 3) is formally recorded and tracked via a Project Issues Management System.

The issue management system used for HELP DESK contains the following features:

· Formal recording

· Validation of issues

· Prioritizing

· Escalation

· History and Resolution Log

· Purging and archiving

· Overdue notification and e-mail notification

· Clear relationship to other processes

2. Issue Management Process

The issue log below keeps the issues in front of the team. The issue log is owned and updated by the project coordinator. The issue log is reviewed regularly at team meetings for those issues that are not being addressed or whose resolution is behind the dates scheduled.

The prioritization of the issue is set by agreement between the project coordinator and the person raising the issue. Items are on the issue log are either open or closed. Closed items are those where the resolution has been reached satisfactory to the person that raised the issue. Also, items that are on the issue log may migrate to a risk register, if that is the proper resolution of the item.

Sometimes there can be some confusion over whether a project issue is an “issue” or “risk.” There are some distinct and important differences. The most important way to distinguish between a risk and issue is to go back to the basic definitions. Risk represents uncertainty. Issues represent concerns that cannot be resolved by the person identifying the issue that “might” impact the project in some fashion. Some issues are addressed, resolved, and represent no further uncertainty and hence should not be treated as risks.

Issue-Tracking Log

RISK Management Plan

1. Introduction

This risk management plan describes how the risks will be identified, analyzed, tracked, and responded to during the planning and execution of the Project Help Desk.

2. Risk Identification

Several techniques will be used to identify projects risks. During the course of WBS generation, risks will be identified as work is defined. These risks will be listed in the risk register format show below and kept in the project folder on the share drive. In addition, after completion of the WBS, each core team will meet and brainstorm further risks that might be contributing in a positive or negative way to project success.

Also, the project manager and core team leads will review the lessons learned from previous projects as well as the risk registers from previous projects. These risks will be added to the risk register.

3. Risk Analysis

Risks will be analyzed into two segments – Risk Impact and Risk Probability (see the risk register for how these will be handled). See the process below to understand the overall risk process used in this project. Risk probability will be low, medium, and high. Risk impact will use the terms low, medium and high. Ranking the risks by severity will be accomplished by combining the Impact and Probability. Combining these two elements into Risk Severity is done following the Risk Severity Matrix below.

Risk Severity Matrix

4. Risk Response

Risks are ranked in the Risk Register by Severity. Those risks whose Severity is High or Extreme must have both a mitigation strategy proposed and implemented as well as a contingency plan. If these are not done, special approval by the project manager and project sponsor must be obtained.

Risks whose Severity are Medium must have contingency plans developed for them and identified in the Risk Register. Those risks whose Severity is Low or Minimal will generally have neither mitigation strategies and contingency plans

5. Risk Monitoring and Control

Risks trigger owners will notify the project manager of the occurrence of a risk event with 24 hours of the occurrence. If there is a contingency plan that is approved in the risk register, the risk owner has the authority to enact the contingency plan.

Risk meetings will be held biweekly with the project manager updating the risk register. These meetings will specifically address the risk register and changes to assumptions or changes to risk results. These meetings determine if there is 1) work that needs to be added to the WBS as a result of risk event occurrence or not, 2) monitoring of risk responses 3) identifying possible new risk events, and 4) reviewing validity of previous assumptions.

Risk Register

Staffing Management Plan

1. Introduction

The Staffing Management Plan identifies what type of resources and when the resources are required for Project HELP DESK. It also identifies the process and procedures used to manage staff throughout the project’s life cycle. The plan describes the planning and acquisition of both internal staff and contract (from a high-level), describes the responsibilities assigned to each staff, and discusses transition of staff to other assignments.

2. Project Team Skill Sets

The HELP DESK Project Team will be comprised of personnel from the broad area of the company, with the mix of skills required to complete the HELP DESK project. The staff for this project will need to possess the following skill sets: project management, project planning, systems design, systems analysis, programming, testing, acceptance testing, documentation, network administration, configuration management, and training. Below are descriptions of the positions that need to be filled.

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

The Senior Analyst must be capable of interviewing end-users, capturing user wants and needs and translating them into requirements. This person must also be able to perform an analysis of the requirements so CITSS configuration needs can be identified. This person must be able to work closely with the project manager on resolving issues and concerns across organizations.

The Senior Programmer must be able to produce the System Integration document and make the necessary program modifications, based on System Integration Requirements Specification document developed by the Project Team. This position needs very little supervision. The Senior Programmer is responsible for delegating program assignments to the Programmer.

The Programmer must be able to program and unit test specific modules of HELP DESK software using the System Integration document. This position needs to take direction from the Senior Programmer.

The Independent Tester must be able to review the HELP DESK software/system documentation and the System Integration document to determine testability of functions described therein. The Tester must be able to design and execute a System Integration plan and a System Test Plan based on these documents. This position will work independently from the project team to ensure an objective review of customer’s functionality in the Headquarters environment.

The Network Administrator must be able to document requirements for the system to be installed in the Headquarters local area network (LAN) environment, install the application on the LAN, and write and execute a test plan which will determine adherence to LAN response time standards for the total system.

The Independent Consultant must be able to provide expert HELP DESK software support for developing an installation, deployment, testing and training plans and providing training to the Project Team, Pilot Group point of contacts, and the hotline technical support team.

The Documentation Specialist must be able to write the HELP DESK User Manual or Quick Reference Guide of helpful hints, in a Windows-based word processing package. This person must have functional knowledge of HELP DESK in order to capture screens for placement into the manual. The Documentation Specialist must be able to create the user guidance with little supervision from the Project Manager.

The Trainer must be able, based on knowledge gained in the training presented by HELP DESK software and the system’s user guidance, to prepare and execute a Training Plan for Headquarters-wide HELP DESK users. In addition to the software system training, the Trainer must have a working knowledge of HELP DESK features and functionality. The Trainer will be assisted by the Project Team as needed.

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

The Acceptance Tester must have the ability to test HELP DESK separately from, and act as an advisor to, the Project Team. This person must utilize the HELP DESK system documentation and user guidance to determine if all the processes in the application are functioning correctly according to these documents and principles of user friendliness, such as ease of use and response times. This person will perform his or her duties with very little assistance from the development team in order to maintain objectivity.

The Database Administrator (DBA) shall be responsible for the design, implementation, operation, and maintenance of the HELP DESK database management system (DBMS) software. Oracle will be the DBMS used with HELP DESK. The DBA shall assist with all administrative tasks related to the database such as access control, maintenance procedures, database design and configuration, and disaster recovery.

The System Administrator shall provide overall analytical and strategic support for all HELP DESK components. The System Administrator is responsible for the successful operation of the system and its underlying architecture.

The UNIX System Administrator will configure the Oracle database server for optimum performance, establish operational procedures, and establish and test database backup, recovery, and fault-tolerance.

3. Project Team Resource Loading

Microsoft Project will be used to keep track of the resource hours by month needed for the project. An extraction from Microsoft Project is shown here.

4. Project Organization Chart

Project Manager

Configuration

Manager

Functional

Manager

Trainer

Quality Assurance

Acceptance Tester

Documentation

Specialist

Independent Tester

Security Specialist

Sr. Analyst (2)Sr. Programmer

Database

Administrator

Independent

Consultant

Network

Administrator

Programmer (2)

System

Administrator

UNIX System

Administrator

5. Training Needs of Staff

As discussed in the early project documents, the customer service HELP DESK operations people will not get general training on how to be a good customer service person. This was listed as outside the scope of the project.

However, there are training needs that will need to be fulfilled. The 10 Operations people that are not a part of the project team will need specific training to use the new software. In addition, a pilot group of people from our team will take this training first to make sure it covers the needs.

The Programmers and administrators under the Senior Programmer will also need training on the new database system.

Configuration Management Plan

1. Introduction

The Configuration Management Plan maintains version control and changes that occur to the product software and hardware deliverables that are controlled items during the project life cycle.

2. Configuration Management Control Items

Describe the method for selecting each Configuration Management Control Item and list the Configuration Management Control Items.

Describe how Configuration Management Control Items are selected for the project.

The project manager for project HELP DESK will establish a Configuration Control Board, consisting of key stakeholders in software and hardware development and production. These key stakeholders select items that must fall under configuration control.

List identified Configuration Management Control Items selected for the project.

HELP DESK Systems Layout Drawing and Parts List

HELP DESK WorkStation Hardware

HELP DESK Off the Shelf Software on Workstation (Vendor, Version, Application type)

HELP DESK Custom Configurable “HELP CUSTOMER” software package

3. Configuration Management Control Process

Diagram or describe the process for making changes to a Configuration Management Controlled Item.

1) Initiator submits a request to the Project Manager which gets submitted to the HELP DESK CCB 2) Request is entered onto a CCB Log 3) HELP DESK CCB meets once per week in person or by conference call to review changes submitted 3) CCB Assigns individuals on the board or team to review and conduct impact analysis on the hardware, software, users, or support team. 4) CCB determines the length of time needed to review a request 5) Individual assigned reports back to the CCB with findings and recommendation 6) CCB reviews the request and makes final decision based on a 2/3 vote by the CCB. 7) CCB notifies PM of the change and PM takes the responsibility to update the project planning documents as required.

4. Naming and Marking Methods

Describe how the documents, components, revisions, and releases are consistently named and marked.

1) Configuration elements fall into three categories - Hardware, Software, Systems. 2) Hardware elements are those hardware components that comprise an entire system. 3) Software elements are either purchased applications or custom software what runs on the computer hardware. 4) Systems are the high level documents that show how multiple hardware and software systems are interconnected. 5) Drawings for hardware will be labeled using the following convention: H-xx-yyy- V.z where x = subsystem number, y = component sequential number, Z = positive numbers post release, and negative numbers before initial release. 6) Software configuration control uses Configuration Control Document 10020-457. 7) Systems configuration control uses Configuration Control Document 10020-458.

5. Submission and Retrieval of Control Items

Describe the process for submission and retrieval of Controlled Items within the project.

Submission – All hardware and systems configuration control items are controlled and stored according to Configuration Control Document 10020-459 using the Production Server PS-22 for storage. All submission procedures will be followed according to those described in Configuration Control Document 10020-459. Retrieval – Same as submission for hardware and systems Submission – All hardware and systems configuration control items are controlled and stored according to Configuration Control Document 10020-460 using the Production Server PS-22 for storage. All submission procedures will be followed according to those described in Configuration Control Document 10020-460. Retrieval – Same as submission for software

6. Version Control

Define the Document Version Control and Release Approval procedure.

Version control of software and release approval will follow the procedures described in Configuration Control Document 10021-459. Procedures for making these changed are described in section 3.

7. Storage, Handling, and Disposition of Project Media

Describe storage, handling, and disposition requirements for project media (both automated and paper). The information in this paragraph is also included in the Communications Plan. Verify that there is no conflict in the plans for storage, handling, and disposition of project documentation.

All project management deliverables and documents will be kept on Sharepoint under the site /TH001/ Engineering/Sharepoint/HELP DESK Documents contained on the share point include all the plans, schedules, and tracking documents. All configuration control item documentation will be kept on the Production Server PS # 22 for hardware, software, and systems items. The production server PS #22 is partitioned into these three elements.

8. Configuration Management Responsibilities

Identify members of the project or configuration team and outline their Configuration Management Responsibilities.

Team Member	Responsibilities
Project Manager	Responsible for establishing and running the CCB and the configuration management control process.
Functional Manager	Responsible for ensuring that their designated and assigned team mates follow the CCB process
Sr. Analyst (2)	Responsible for and owns the FRS and the NFRS. All changes to these documents must receive concurrence from the Sr. Analyst (1)
Sr. Programmer	Responsible for all software buildings and submitting build plans to the PM.
Independent Tester	Responsible for identifying and fixing bugs and keeping Configuration Control items updated as needed and submitting changes to items.
Quality Assurance	Conducts an audit of CC Processes at 30, 70, and 100% complete points in project.
Documentation Specialist	Updates documents per the approved submittal process for change control items.
Configuration Manager	Owns and manages the overall process and recommends and advises the PM on CC issues.

PROCUREMENT MANAGEMENT PLAN

1. Project Initiation Phase

This document addresses the purchases of products and services to be used for Project HELP DESK. This portion of the Procurement Plan document is used to provide the project selection team with general information about the possible purchase of goods and services.

2. Procurement Statement

The products likely to be procured for this project with estimated costs with confidence limits are:

· Dual Windows Servers with database software SQL ($20,000 +/- 25%)

· Computer Workstation to support Network Manager ($5,000 +/- 25%)

· Computer Workstations for each Customer Service Help Desk support person ($20,000 +/- 25%)

· Ergonomic work areas and cubes for Help Desk support people ($10,000 +/- 35%)

The services to be procured for this project include:

· Computer consultant ($100,000 +/- 10%)

3. Vendor Selection

All products will be purchased using the standard company policies and procedures. Since the company as a long term agreement with ACE COMPUTERS, the computer hardware and software will be purchased from them. The ergonomic work areas will be specifically selected and purchased by facilities department personnel.

The computer consultant services will be purchased through one of the standard contracting agencies that are approved by company. Rates through these contract agencies will be around $95/hour +/- 10%)

5. Project Planning Phase – The following sections describe the actual products and costs associated with the products and services to be purchased.

6. Procurement Definition

· Dual Windows Servers with database software SQL – Detail Attached - $18,545.00 - Purchase Order

· Computer Workstation to support Network Manager – Detail Attached - $6,100 - Purchase Order

· Computer Workstations for each Customer Service Help Desk support person – Detail Attached - $21,995 - Purchase Order

· Ergonomic work areas and cubes for Help Desk support people $12,150 - - Purchase Order

The services to be procured for this project include:

· Computer consultant ($90/hour – 1000 hours) $90,000 - Purchase Order – Detailed Statement of Work attached

7. Selection Process & Criteria

Used standard agreements in place for all computer hardware and software. Facilities Department purchased the ergonomic workstations based on modeling them after another division’s use. Consultant resumes and interviews determined basis for selecting consultant.

8. Project Procurement Team

All purchases must have the project manager’s approval and signature. Those requesting the above purchases included the Senior Programmer, Business Analyst, and Quality Assurance team member.

9. Contract Type

All contracts used standard purchase orders with standard terms, except for the computer consultant where we used a Statement of Work to control scope.

10. Contract Standards

All contracting followed the company standard PRO-1501.

11. Vendor Management

Vendor supplying the computer equipment has a maintenance agreement with company and hence the support from this vendor for this equipment will not be an issue. Same is true for the ergonomic workstations.

The contracting agency meets with us monthly to review performance of their independent consultants.

COMMUNICATION MANAGEMENT PLAN

Core Stakeholders: Project Manager Functional Manager Sr. Analyst-1 Sr. Programmer Quality Assurance Configuration Manager Extended Stakeholders: Programmer (2) Independent Tester Independent Consultant Security Specialist Documentation Specialist Trainer Acceptance Tester Network Administrator System Administrator Database Administrator UNIX System Administrator
Project Records: The electronic project notebook is at the following location: /TH001/ Engineering/Sharepoint/HELP DESK
Project Team Directory: A project team directory is located in the project notebook, under filename: /TH001/ Engineering/Sharepoint/HELP DESK/Team_Directory Paper Files are stored in PM Files/HELP DESK/PMO Office
Responsibility Assignment Matrix: A responsibility assignment matrix will be provided and is attached to this document.
Status Reports: Team Weekly Status Reports: Yes, Required, Standard Format Distribution Core Project Team Yes Extended Stakeholders Yes Project Combined Status Reports: Yes, Required, Standard Format Distribution Core Project Team Yes Extended Stakeholders No Monthly PM Reviews: Yes, Required, Standard Format	Indicate below where status reports are stored: /TH001/ Engineering/Sharepoint/HELP DESK/Status_reports

COMMUNICATION MANAGEMENT PLAN (cont)

Communication Guidelines—E-mail: 1) Do not use reply all to emails 2) Be conscious about CC’ing needlessly 3) Use the RACI chart for guidelines on copying others 4) The project manager specifically requests that he not be copied on items unless they show in the RACI or unless you are asking him for a decision or his opinion. 5) When out for more than 1 day, team members must use OUT OF OFFICE reply message 6) Responses to emails from team members should be within 24 hours, or approximately 1 business day 7) Use of urgent on email messages is reserved for responses needed within 2 hours. 8) Use of OUTLOOK for meeting setup is required. Same response for meeting requests as for email responses – 24 hours or approximately 1 business day

Communication Guidelines—Meetings: 1) Meetings must have pre-published agendas, prior to meeting request…agenda must accompany the OUTLOOK meeting request 2) Scribe other than Meeting Facilitator must be appointed, if meeting attendance is more than 4 people 3) Meeting organizer may not be the meeting facilitator and can rotate the assignments. 4) Parking lots will be established for catching items brought up not on agenda 5) Team agrees to be present 5 minutes before scheduled start of meeting 6) Meetings will start on time and end on time. Separate meetings will be used for extended meetings.

Project Closure: A brief lessons-learned report at the end of the project will be provided in the closure of the project. All electronic files contained in the project notebook will be archived for future use at location: TH001/ Engineering/Sharepoint/Archive/HELP DESK All paper files contained in the paper project notebook will be archived for future use at location THOO1 Building , Document Archival Room under PROJECT HELP DESK.

Responsibility Assignment Matrix – RACI

Task/Resource

Project Mgr

Functional

Manager

Sr. Analyst-1

Sr.

Programmer

Quality

Assurance

Configuration

Manager

Programmer (2)

Independent

Tester

Independent

Consultant

Security

Specialist

Documentation

Specialist

Trainer

Acceptance

Tester

Network

Administrator

System

Administrator

Database

Administrator

UNIX System

Administrator

High Level Requirements

A

C

R

C

C

I

I

I

I

I

Detailed Requirements

A

C

R

C

C

I

I

I

I

I

Requirements Verification and Test

A

C

R

C

C

I

I

I

I

I

R

Systems Design

C

A

C

C

C

I

I

I

R

I

I

Software Design

I

A

I

R

I

C

C

I

I

I

Hardware Design

I

A

I

C

C

I

I

I

R

I

Install Server Pilot COTS Hardware

A

I

I

I

C

R

C

C

C

Install Server COTS Software

A

I

I

R

C

I

C

C

C

I

I

I

I

Build Custom Pilot Software

A

I

I

R

C

C

C

C

C

I

I

I

I

Conduct Pilot Subsystem Tests

C

I

C

I

C

I

I

R

C

A

I

I

I

I

Conduct Pilot System Tests

C

I

C

I

I

C

C

R

I

A

Design Pilot Tests

C

I

I

C

C

C

C

R

I

A

Conduct Pilot Tests

C

C

C

C

C

C

C

R

I

A

Analyze Results

C

I

I

C

I

I

I

R

I

A

Update Design

A

I

I

I

I

I

I

I

R

Update Build

A

I

I

C

C

C

I

I

R

Update Procedures

A

C

C

I

I

I

I

I

R

Install Production Server Hardware

I

I

I

I

A

C

C

C

R

Install Production Server COTS Software

I

I

I

R

A

C

C

I

I

I

I

I

I

Build Custom Production Software

I

I

I

I

A

R

C

C

C

I

I

I

I

Conduct Subsystem ProductionTests

I

I

I

I

A

C

R

Conduct System Production Tests

I

I

I

I

A

C

R

Design Production Tests

I

I

I

I

A

C

R

Conduct Production Tests

I

I

I

I

A

C

R

Analyze Results

I

I

I

I

A

C

R

Update Design

A

C

I

I

I

C

C

R

Update Build

A

C

I

I

I

R

Update Procedures

A

C

I

I

I

C

R

Design Transition Plan

R

C

I

I

A

C

Test Operational System

I

I

I

I

A

C

R

Notify Customers

R

C

C

I

A

C

I

I

I

Cutover to Production

R

I

I

I

A

C

I

I

I

I

I

I

I

Maintain System - 2 Months

R

C

C

I

A

C

I

I

I

I

I

I

I

R

R

espsonsible for Task Being Completed

A

A

pproves Task Deliverables

C

C

onsulted - Must be consulted before deliverables approved

I

I

nformation - must be informed on status

Quality Management Plan

Responsible person for quality assurance (and completing corresponding sections of plan) · Software: Quality Assurance Engineer · Hardware:  Quality Assurance Engineer

Planned software quality assurance activities to be conducted during project · Applicable Standards: The software shall meet any standards required by the functional and nonfunctional requirement specifications that are implemented in part or whole by software. · Configuration Management: All software produced by this program shall be configuration managed. The Harvest CM tool will be used for CM. · Overall Change Management: The day-to-day change management of software fault fixes shall be managed by a Software triage team. Software Changes are not bug fixes. Software changes are changes to the original functional or nonfunctional requirements and shall be approved by the HELP DESK CCB with concurrence by Software QA. See the Change Management Plan. · Defect Tracking: A DevTrack database shall be established for this project. It shall utilize the standard priority and severity classifications and other DevTrack standard formats (under development) required of all projects by SQA. · Quality Metrics: HELP DESK shall utilize the metric set documented in company standard PMET – 0111. In addition, a weekly summary set of test metrics will be provided to SQA using the crystal reports tools developed by SQA. · Software Quality Attributes: The software quality attributes for HELP DESK shall be identified in the functional and nonfunctional requirements. Other attributes may be identified by SQA or the project during the development and audit processes. · Generate Software Release Requirements: Software production release requirements for this program shall be generated with SQA, and will be documented in a separate document. The requirements shall include, as a minimum, demonstrated compliance with the requirements identified in the FRS and NFRS documents. All priority 0 and priority 1 software issues have been fixed. All priority 2 software issues have been satisfactorily dispositioned, as determined by an SQA review. The test coverage has been adequate as determined by an SQA review. The software robustness and reliability shall be demonstrated to meet the product needs to the satisfaction of an SQA review. The software shall be approved for production release by the SQA organization prior to duplication and delivery to customers. · SQA Plans for Third Party Software: The Project team shall develop a third party software quality plan as part of the make buy decision and third party contracting activities. · Audit Points · Planned: SQA release review. · Unannounced: The software development and test and fix process are subject to audit by the SQA organization at any time during the product life cycle. · Other:

Quality Management Plan (cont)

Planned hardware quality assurance activities to be conducted during project · Applicable Standards · For devices connected to the mains (AC Power) EN60950/UL1950 with CB report demonstrating compliance. Third party agency listing is required as follows: - North America: UL or CSA - Europe: TUV or VDE · For all active electronic components, EN55022 & EN50082 and applicable National Requirements, FCC, CE, Ctick, ICES, and others depending on target markets. · For all wireless devices, ETSI 300-328, and IEEE 802.11b. · USB devices shall be certified to USB 1.1. · Ethernet devices shall be certified to IEEE 803.3 and 802.3u. · AC-DC adapters must be tested to QRA 10809 revision A. · Primary batteries must meet the requirements of QRA 11171 revision A. · Secondary (rechargeable batteries) must meet the requirements of ANSI C18.2. · All devices must meet the requirements of QRA 10237 revision Q for the usage scenarios defined in the NFRS. · PVL (Product Verification, Life) shall be performed in accordance with QRA 11256. · Configuration Management · Regulatory compliance technical documentation files and declarations of conformity are maintained on \\regs14\qra\cemark · All other test plans, test reports, certifications, and related documents will be maintained on \\regs14\intl\ SUPPLIER_QUALIFICATION-PVL_DATA. · Schematics, BOMs, PWB layouts, and construction photos must be included with all quality reports and must reflect the configuration tested. · Overall Change Management: Changes to the design or purchased components must be reviewed by QRA for potential impact to test plans. Test plans will be changed as needed to verify performance to requirements with the changed design or component. See the Change Management Plan. · Defect Tracking: Defects noted during test are documented in the test report. All defects must be corrected or dispositioned according to the Acceptance or Release Criteria below. · Quality Metrics: Percent of qualification test elements fully met, per the Supplier Excellence Award criteria (\\dpcs14\wrldwide\INTERNATIONAL OPERATIONS\SEA Criteria\SEA 2002.doc) section 7(e) · Acceptance or Release Criteria · All items requiring performance verification shall meet one of three criteria: - P (pass) meets or exceeds required performance without exception. - A (acceptable) the performance does not meet the specified requirements but is acceptable to marketing for the foreseeable future. - Q (released conditionally) the performance does not meet the specified requirements but is acceptable for a limited number of units or period of time until it must be corrected or improved. · Required FMEAs shall be completed with required corrective actions completed and verified. PVI test will be in place and operators trained to perform test.

PROJECT CLOSURE PLAN

Project	HELP DESK
Reason project closed	FORMCHECKBOX  Completed objectives FORMCHECKBOX  Canceled FORMCHECKBOX  Other If other:
Date project closed: 7/21/2007	Date project closing form completed: 8/15/2007
Original project objectives	Establish a centralized customer help desk and integrated support business process that services the needs of the customer inquiries for the entire company enterprise.
Objectives achieved	Established a centralized customer help desk and integrated support business process that services the needs of the customer inquiries for the entire company enterprise.
Customer sign-off achieved? FORMCHECKBOX  Yes FORMCHECKBOX  No	If Yes, list storage location of customer sign-off documentation: THOO1 Building , Document Archival Room under PROJECT HELP DESK.
Was a Project Post-Mortem held? FORMCHECKBOX  Yes FORMCHECKBOX  No	If Yes, list storage location of Post-Mortem report:  THOO1 Building , Document Archival Room under PROJECT HELP DESK. If Yes, give brief summary of Post-Mortem report:  · Under budget by $10,000 · Delivered project 1 week earlier than expected · Pilot tests were late but made up time during production ready work · Customer results from the pilot and 2 months operation showed delighted customer response from the help desk operations

Project Lessons Learned
Did project meet objectives originally intended? FORMCHECKBOX Yes FORMCHECKBOX No	If not, why not?
Project duration (months)	8 months
Estimated project costs incurred ($$)	$990,000
Did project team work together well? FORMCHECKBOX Yes FORMCHECKBOX No	If no, describe what were the problems and what could have been done better?
Did senior management support project well? FORMCHECKBOX Yes FORMCHECKBOX No	If no, describe what were the problems and what could have been done better:

PROJECT CLOSURE PLAN (cont)

Did project contain significant vendor content? FORMCHECKBOX Yes FORMCHECKBOX No	If yes, describe performance of vendor: Workstation vendor (Computers Unlimited) was outstanding – went the extra mile. Software Vendor (HELP MY Customer, Inc) was marginal…lots of post completion and warranty work to help get the software more usable. It ended up with great results, but struggles along the way made them somewhat difficult to work with.
List decisions/actions that could be done next time to improve project performance:  Check out the software vendor more thoroughly prior to contract. Have better terms and conditions in the contract and better requirements for the software vendor.
List decisions/actions that you would do again to preserve project performance:  Project Manager was extremely knowledgable and kept the entire team on track. Processes in place really kept the scope from creeping that really wanted to expand. Keep these robust processes for sure next time. Turns out the extra scope wasn’t that necessary.

Project Archives

Printed project records and documentation are stored in the following locations:  THOO1 Building , Document Archival Room under PROJECT HELP DESK.

Computer storage of project records and documentation are located:  TH001/ Engineering/Sharepoint/Archive/HELP DESK

This project closure document was prepared by

Name: John Bradstreet Role on project: Quality Assurance Engineer

 Higher

Identify risk events

Estimate likelihood and impact

Estimate severity

Determine risk source/cause

Rank risks by severity

Develop mitigation �plans

Lowest

Accept and do nothing

Done

Develop contingency plans

Lower

Done

Step 1

Step 2

Step 3

Step 5

Step 4

Step 6

Step 7

Step 8

Project Management Plan Harrisburg University – M.S. Project Management – PMGT 699

1

_1224525798.vsd

Name Title

Name Title

Name Title

Project Manager

Configuration Manager

Functional Manager

Trainer

Quality Assurance

Acceptance Tester

Documentation Specialist

Independent Tester

Security Specialist

Sr. Analyst (2)

Sr. Programmer

Database Administrator

Independent Consultant

Network Administrator

Programmer (2)

System Administrator

UNIX System Administrator