Software Configuration Management
Authors: Keyes J.
Published year: 2006
Pages: 156-158/235
Buy this book on amazon.com >>

PROPOSED SOLUTION

Current

Not all functionality was built into the new <application name> System from the old <application name > System. This lack of functionality is causing many manual work-arounds and in some cases loss of revenue. Some of the requested changes also position <application name> in compliance with <company name> strategic standards.

Proposed Solution

The <application name> management team is working with the Project Manager to ensure that detailed Business Requirements are fully documented and to prioritize those requirements based on business need. Those requirements have been sized and presented to the various Business Lines. A resource plan will be updated to reflect the number of resources available during the Release ?? timeframe. The Business Lines will then obtain funding for the requirements that can be completed in that Release ?? timeframe.

The project plan will be updated and an issues log and task plan will be maintained throughout the term of the project.



PROJECT SCOPE

Inclusions

The scope of this project includes the following:

  1. Defining and communicating the business requirements to all affected applications that are included in the Release ?? requirements

  2. Assessing and managing the impacts to the various Operational/Support Groups/Business Lines

  3. Participation in development of customer, department, and vendor communications

  4. Participation in development of customer or internal training

  5. Participation in development of user documentation and procedures

  6. Participation in regression testing

  7. Validation of requirements, design, development, and unit and system testing of application changes necessary to the applications listed in the Business Units Involved

  8. Changes needed for other applications requirements

A list of the requirements scheduled for Release ?? is attached as Appendix P6.

Exclusions

The scope of this project does not include the following:

  1. Any non-<APPLICATION NAME > accounts

  2. <APPLICATION NAME> (??) application conversion (although it is a dependency)

Security Statement

  1. The Security Plan is prepared to ensure that appropriate controls are being designed that meet security policy and standards. The plan should identify risks and exposures to information, systems, and networks that may result from any exceptions to the standards. The System Managers are responsible for ensuring that the security plans are updated or created for all systems.



PROJECT APPROACH

Project Management

<Project Manager name > has been assigned to manage the project. The responsibilities of the project manager will be:

  1. Establish and execute a project plan

  2. Ensure completion of project estimates, as required

  3. Track actual costs against budget/planned costs

  4. To assist in maintaining the overall project direction

  5. First point of escalation of project issues

  6. Obtain project resource commitments

  7. Define project milestones

  8. Create and maintain a project issues log

  9. Schedule and conduct project status meetings

  10. Complete project status meeting minutes

  11. Complete project status reports

  12. Contact lists for all project participants with defined roles and responsibilities

  13. Ensure detailed test plans are complete

  14. Participate in the post-event review

  15. Communicate with the other End-to-End Project Managers

  16. Close the project

Methodology

This project will follow the <methodology name> methodology.

One overall project manager will be assigned as the end-to-end project manager as well as the Technical Lead. This project manager will manage the details of the <APPLICATION NAME> System development efforts. The project manager will maintain a common format for issues, project plans, and technical requirements. The project manager will provide day-to-day management for the technical team and provide a roll-up of all issues, plans, and requirements.

Deliverables

Key Project Deliverables

Key deliverables from this project include:

  1. Statement of Work

  2. Risk Assessment

  3. Project Change Requests

  4. Project Requirements Document

  5. Design Documents

  6. Communication Plan

  7. Data Security Plan

  8. Resource Plan

  9. Critical Success Factors Document

  10. Master Test Plan

  11. Training Plan

  12. Implementation Plan

  13. Post-Implementation Review

Approvals

Approval of key project deliverables must be received from the following individuals:

  • A = Approval Required; R = Review Only

Area

Deliverables

 

1

2

3

4

5

6

7

8

9

10

11

12

13

<manager name>

Operations Manager

A

A

A

A

A

A

R

A

A

A

A

A

A

<manager name>

Technical Manager

A

A

A

A

A

A

R

A

A

R

R

A

A

<manager name>

TM Product Manager

A

A

A

A

A

A

A

A

A

A

A

R

A

<manager name>

Operations Manager

A

A

A

A

A

A

R

A

A

A

A

A

A

<manager name>

Project Manager

A

A

A

A

A

A

R

A

A

A

R

A

A

<manager name>

Wholesale Services

A

A

A

A

A

A

R

A

A

R

A

R

A

<manager name>

Wholesale Integration

A

A

A

A

A

A

R

A

A

A

A

R

A

Audit Representative

R

R

R

R

R

R

R

R

R

R

R

R

R

Acceptance Criteria

This project will be considered completed when the following acceptance criteria have been met:

  1. Each system change has passed all levels of test successfully and is implemented into production successfully.

  2. Delivered system functionality meets agreed-upon functionality

  3. There is no undue fallout up to two weeks after implementation.

Assumptions

The following assumptions are being made for this project:

  1. Resources assumption. The key resource assumptions for labor, space, and equipment are:

    • Technical Lead will be identified and assigned

    • A test coordination leader is identified and assigned for <APPLICATION NAME>.

    • Testing Assumptions in general:

      • Test coordination with all affected applications will be managed by an assigned resource from testing. Other testing resources will be drawn from each of the applications.

      • Testing by all affected applications will be conducted at the specified time established by Release Management for this release.

    • All Business Line resources are available to the overall project.

    • Project support resources are available to the overall project.

  2. Production support has the highest priority for resources. Other resource issues will be addressed and prioritized at the Steering Committee Meeting level.

  3. The Release ?? key dates will not be changed and the various phases of the project will start and end on time.

Key Facts

Key facts identified for this project include the following:

  • If the ?? requirement is not implemented with this release, we will continue to lose revenue at the rate of approximately $?? a month.

  • If the new statement paper and logo requirement is not implemented with this release, <APPLICATION NAME> will continue to be out of compliance with enterprise standards.

  • If <requirement> is not implemented with this release, there will be staffing impacts to the Operations group .

  • All <APPLICATION NAME> and <application name> related changes must be implemented concurrently.

  • If <requirement> is not implemented, there will be customer and Operational impacts.

  • If the file format changes are not made, there will be customer impacts.

  • If the <requirement> changes are not made, there will be customer impact.

Issue Management

Project-related issues will be tracked, prioritized, assigned, resolved, and communicated as follows :

  1. The project manager and participants will report issues that are identified throughout the life of the project.

  2. The project manager will maintain a log of all issues and report on the status of issues.

  3. The project manager will assign the priority and ownership to the issue. If necessary, the Executive Sponsors will assist the project manager in assigning appropriate ownership for resolution.

  4. Individual team members assigned to resolve the issue will be responsible for communicating the issue status to the project manager.

See Appendix P5 for the Issue Log template.

Change Management

A change management procedure will be used by this project to help ensure that changes impacting the project are assessed, understood , and agreed upon by stakeholders before the change is made or before initiating specific actions to accommodate the change. The purpose of this procedure is to control change and impacts to the project and not to discourage change.

A Project Change Request form (PCR) must be submitted to the Project Manager for any changes that impact the project's cost, schedule, or scope. The Project Manager will review the proposed change request with the project team members impacted by the change to assess the impact of the change. The Project Manager will present the change request to the Steering Committee to approve or reject the request. The decision will be communicated to the requester and project team.

See Appendix P4 for the Project Change Request form and instructions.

Communication Plan

A project communication plan will be completed. This plan identifies the approach that will be used to share information with key internal and external parties throughout the project. The key elements of the communication plan include:

  • Who must receive the information

  • What intervals the information will be shared

  • Who will provide the information

  • What medium will be used

Project Status

The status of this project will be communicated in multiple ways. These include:

  • Weekly project team status meeting

  • Weekly project management status meeting

  • Monthly project status reporting to the business lines

  • Monthly online project status reporting to the PMO

  • Project Plan Updates

A meeting agenda will be published prior to the meetings so participants can be prepared for the meeting. Meeting minutes will be distributed after the meeting has occurred so the team is aware of the discussion at the meeting.


Software Configuration Management
Authors: Keyes J.
Published year: 2006
Pages: 156-158/235
Buy this book on amazon.com >>

Similar books on Amazon