MANAGEMENT PLAN

Approvals:

The above signatures represent agreement with the attached plan including agreement with the activities, the risks, the effort and the cost of the associated project

Revision History

Table of Contents

Introduction

Purpose of Project Plan

Project Plan Content

Project Scope Statement

Purpose of Project Scope Statement

Work Breakdown Structure - (WBS)

Purpose of WBS

WBS Information

Project Schedule

Major Milestones

Project Schedule

Project Organization Plan

Purpose of Project Organization Plan

Abbreviations

Project Stakeholders

Stakeholder Directory

CMA Project Organization Chart

Project Communication Plan

Purpose of Project Communication Plan

Communications Plan

Scope Management Plan

Purpose of Scope Management Plan

Scope Management

Change Control Process

Change Analysis Framework

Risk Management Plan

Purpose of Risk Management

Risk Management Process

Risk Identification

Risk Identification Summary (Top Five Risk)

Annexes

Tools and techniques for developing WBS. Decomposition

Role Description

Project Sponsor Role

Steering Committee Role

Project Manager Role

Development Team Role

End User

Change Request Form (Cerere de Modificare)

Risk Management Worksheet

Suggested Preventive and Contingency Measures

List of Figures

Figure 1. CMA Project Organization Chart

Figure 2. Change Management Process

Introduction

Introduction

Purpose of Project Plan

The project plan is a formal, approved document used to manage project execution.

The project plan is used to:

• Guide project execution.
• Document project planning assumptions.
• Document project planning decisions regarding alternatives chosen.
• Facilitate communication among stakeholders.
• Define key management reviews as to content, extent, and timing.
• Provide a baseline for progress measurement and project control.

Project Plan Content

The project plan is a document or collection of documents that should be expected to change over time as more information becomes available about the project.

The project plan commonly includes all of the following (these items are described in more detail elsewhere):

1. Project charter.

2. Scope statement, which includes the project objectives and the project deliverables.

3. WBS to the level at which control will be exercised, as a baseline scope document.

4. Schedule baseline (project schedule) and the cost baseline (timephased project budget).

5. Cost estimates, scheduled start and finish dates (schedule), and responsibility assignments for each deliverable within the WBS to the level at which control will be exercised.

6. Major milestones and target dates for each.

7. Project organization plan. Key or required staff and their expected cost and/or effort.

8. Risk management plan, including: key risks, including constraints and assumptions, and planned responses and contingencies (where appropriate) for each.

9. A description of the project management approach or strategy

10. Open issues and pending decisions.

11. Subsidiary management plans, namely:
1. Scope management plan
2. Schedule management plan
3. Cost management plan
4. Quality management plan
5. Communications management plan
6. Risk response plan
7. Procurement management plan

Project Scope Statement

Project Scope Statement

Purpose of Project Scope Statement

The scope statement provides a documented basis for making future project decisions and for confirming or developing common understanding of project scope among stakeholders. As the project progresses , the scope statement may need to be revised or refined to reflect approved changes to the scope of project.

A. Business Need:

(the project justification, describe why the project was undertaken; more detail than in Project Charter)

B. Project's product:

(brief summary of product description, but more than in Project Charter)

C. Project deliverables

(list of summary-level subproducts whose full and satisfactory deliverables marks completion of the project)

D. Project Quantifiable Objectives:

(quantifiable criteria that must be met for the project to be considered successful. Must include at least cost, schedule and quality measures. )

E. Success Factors:

List factors that will be used to determine the success of the project. This part of the project statement should answer the question, "How do we know if the project was successful?" It is essential that the criteria be quantifiable and measurable. Short-term success factors are used to determine if a project is complete.

F. Assumptions:

G. constraints:

H. RISKS:

WORK BREAKDOWN STRUCTURE

(WBS

Work Breakdown Structure - (WBS)

Purpose of WBS

WBS is a deliverable-oriented grouping of project components that organizes and defines the total scope of project

Together wit the project scope statement, the WBS is used to develop or confirm a common understanding of project scope.

Work not in the WBS is outside the scope of the project and will not be performed.

WBS Information

Project Schedule

Project Schedule

Major Milestones

Summarize the Project Schedule by listing the Milestones or Events on the critical path of the Project Schedule. The critical path is: a series of activities, which determine the earliest completion time of the project. For each event, provide the Projected Date of completion and a brief description of the Significance of the Milestone or Event listed.

Project Schedule

An electronic version can be found at:

https://projsrv.softwin.ro/projectserver

https://projsrv/projectserver

Project Organization Plan

Project Organization Plan

Purpose of Project Organization Plan

The Project Organization Plan identifies, documents, and assigns project roles, responsibilities, and reporting relationships. Roles, responsibilities, and reporting relationships may be assigned to individuals or to groups. The individuals and groups may be part of the organization performing the project, or they may be external to it.

The results of project organization planning should be reviewed regularly throughout the project to ensure continued applicability. If the initial organization is no longer effective, then it will be revised promptly.

Abbreviations

PM - Project Manager

SC - Steering Comitee

PS - Project Sponsor

DT - Development Team

Project Stakeholders

Stakeholders are those with a vested interest in the success of the project. The identification and input of stakeholders helps to define, clarify, change, and contribute to the scope and, ultimately, the success of the project.

To ensure project success, stakeholders are identified early in the project, their needs and expectations are determined, and we strive to manage those expectations over the course of the project.

Stakeholders on this project include:

• Project Manager, who has ultimate responsibility for ensuring project success.
• Project Sponsor, who leads in getting the need for the project recognized.
• Users, who are the persons using the product of the project.
• Management, who refines business needs of the project.
• Development Team members, who are responsible for performing the work on the project.
• Configuration management and quality control entities.
• Legal Department, who provide legislative oversight.
• Resource managers, who allocate the resources (people, equipment, etc) as necessarry

The management of stakeholder expectations is potentially difficult because of conflicting goals and expectations.

The expectations may require more resources than are currently available.

Stakeholder Directory

CMA Project Organization Chart

Figure . CMA Project Organization Chart

Project Communication Plan

Project Communication Plan

Purpose of Project Communication Plan

This document addresses the Comunications Planning for the project.

Communications planning involves determining the information and communications

needs of the stakeholders:

• who needs what information,
• when they will need it,
• how it will be given to them, and
• by whom.

The results of project communications planning should be reviewed regularly throughout the project and revised as needed to ensure continued applicability. If the initial communications plan is no longer effective, then it will be revised promptly.

.

Communications Plan

A.    Communications technology

The technologies or methods used to transfer information back and forth among project stakeholders.

B.     Information Description, Collection, and Reporting

For each Information Need, describe the information, the provider of the information, when and how is it collected, and how the information will be reported.

D.    Distribution Methods

List each report or document needed to communicate the information (in the first column) identified in the last column of Section C. Identify the primary and secondary distribution methods for each report or document (e.g., voice, electronic mail, spreadsheet, formal presentation). Specify the frequency or distribution for each report or document.

E.     Distribution Groups

Organize into logical groups, stakeholders identified in section B, who have common information needs. List the stakeholder(s) for each group in the columns provided. Specify the common information needs for each group.

F.     Method for Updating the Communications Plan

Describe who, when, and how the Communications Plan will be maintained.

Scope Management Plan (Change Control)

Scope Management Plan

Purpose of Scope Management Plan

The purpose of Scope management Plan (Change Control) is to provide the standards and procedures for submitting, analyzing and approving or disapproving changes that occur after the official requirements have been agreed upon (i.e., 'signed off').

A scope change is any modification to the agreed-upon project scope as defined by the approved WBS. Scope changes often require adjustments to cost, time, quality, or other project objectives.

Project scope changes are fed back through the planning process, technical and planning documents are updated as needed, and stakeholders are notified as appropriate.

Scope Management

This process provides a framework for minimizing changes that impact the scope, schedule, and cost of the project, while facilitating project team members' ability to make simple improvements to the solution.

Changes in the project approach, business requirements, technology, and resources will impact key components of the implementation plan. Such changes must be managed and controlled by the project management team, in order to prevent increased customer cost, delayed delivery schedule, and decreased quality of the overall solution.

Figure . Change Management Process

eFORCE Project Management Methodology

Change Control Process

The following describes the Change Control process (as outlined in the diagram above):

STEP 1: A project team member identifies the need for a change in an area where the requirements, approach, or plan has already been approved (i.e., 'signed off') by the project management team. He/she (i.e., 'Change Originator') completes a 'Change Request Form' (Annex) and forwards it to his/her project manager-either the Client Project Manager or Softwin Project Manager. The completed request describes the business, technical, or change management issue the request is trying to address, the desired outcome of the change, and detailed justification for the change.

STEP 2: The project manager analyzes the initial change request. If it is valid, he/she submits the request to the Project Manager, who logs the request in the Change Control Log. The Project Manager evaluates the priority of the request and arranges a meeting (via PM Review, Issue Management, or ad-hoc meeting) for the entire project management team to discuss and analyze.

STEP 3: The entire project management team analyzes the request and agrees to approve or disapprove. If the request is disapproved, the originating team member's project manager communicates the outcome, and reviews options/workarounds (as discussed in the project management review of the request). The Softwin Project Manager logs the request as is approved on the Change Control log. If the request is approved, the project management must thoroughly evaluate any impacts to the project scope, schedule, and cost. If there are any impacts to these stated areas, the request must be presented to the Steering Committee for approval. If there are no impacts to project scope, schedule, or cost, the change is communicated to the originating team by their respective project manager. The Software Project Manager logs the request as approved on the Change Control Log, and communicates it on the weekly status report.

STEP 4: If the request is approved, and there is an impact to scope, schedule, or cost, the Softwin Project Manager arranges for a Steering Committee review. The Steering Committee evaluates the request and makes a decision to approve or disapprove. If the decision is disapproval, the originating team's project manager communicates the outcome to his/her respective team members, and reviews options/workarounds (as discussed with the Steering Committee members). The Softwin Project Manager logs the request as disapproved on the Change Control Log. If the request is approved, the respective project manager communicates the change to their originating team. The Softwin Project Manager logs the request as approved on the Change Control Log and communicates on the weekly status report. The project plan is revised to reflect the change in scope and delivery dates, and the client authorizes the additional funding as necessary, often via a purchase order.

Change Analysis Framework

Listed below are the criteria that should be used to determine whether or not the change request should be approved or disapproved:

1. Does the change include valid justification?
2. Is the change essential at this point in the project, or can it be deferred to post-production efforts?
3. Is the change outside the agreed-upon scope of this stage of the project?
4. What tasks will be impacted by this change? Are there any critical path tasks?
5. What is the work effort estimated to implement this change?
6. What is the impact to the project schedule?
7. Are additional resources required to implement this change?
8. Are any other applications or projects impacted by this change?
9. Are there any risks associated with implementing this change?
10. Are there any costs associated with this change?

Risk Management Plan

Risk Management Plan

Purpose of Risk Management

Risk management is the systematic process of identifying, analyzing, and responding to project risk. It includes maximizing the probability and consequences of positive events and minimizing the probability and consequences of adverse events

Project risk includes both threats to the project's objectives and opportunities to improve on those objectives. It has its origins in the uncertainty that is present in all projects. Known risks are those that have been identified and analyzed, and it may be possible to plan for them.

The Risk Management Plan documents the procedures used to manage risk throughout the project. In addition to documenting the results of the risk identification and analysis phases, it must cover who is responsible for managing various areas of risk, how risks will be tracked throughout the life cycle, how contingency plans will be implemented, and how project resources will be allocated to handle risk.

Risk Management Process

Risk management deals with the following risk phases:

Risk identification

Risk analysis, quantification and prioritization

Risk mitigation planning

Risk response

Risk Identification

Project risks are identified and carefully managed throughout the life of the project.. Risk identification is a recurring event at occurs at all stages of the project

Risk identification consists of determining risks that are likely to affect the project and documenting the characteristics of those risks. Not all possible risks that might affect the project are idenytified, but only those likely to affect the project's success.

All members of the project team can identify risk, but the project manager has overall responsibility

A Risk Management Worksheet (shown later in this section) is used to manage risks. The worksheet is updated to reflect further risks identified. Also during the project, risks identified earlier may be removed.

Risks are documented so that contingency measures can be taken to mitigate their effects. Risks to both the internal and external aspects of the project should be tracked. Internal risks are those items the project team can directly control (e.g., staffing), and external risks are those events that happen outside the direct influence of the project team (e.g., legislative action).

Risk identification, management, and resolution continues throughout the life of the project. New risks are developed as the project matures and external and internal situations change. Old risks may go away or decrease in likelihood

Contingency plans are developed as a result of a risk being identified. Contingency plans are pre-defined action plans that can be implemented if identified risks actually occur. If a problem actually occurs, the contingency plan must be implemented and reserves must be allocated.

As a guideline, contingency plans are developed for the top five risks associated with a project. To properly implement a plan, a reserve is usually required where dollars and/or time are held by a project manager to apply to the execution of a contingency plan

Risk Identification Summary (Top Five Risk)

Legend: Prob = Probability of Occurence

Annexes

Annexes

Tools and techniques for developing WBS. Decomposition

Decomposition involves subdividing the major project deliverables or sub deliverables into smaller, more manageable components until the deliverables are defined in sufficient detail to support development of project activities. Decomposition involves the following major steps:

Identify the major deliverables of the project, including project management.

Decide if adequate cost and duration estimates can be developed at this level of detail for each deliverable. The meaning adequate may change over the course of project. Decomposition of a deliverable that will be produced far in the future may not be possible at this time.
For each deliverable, proceed to step 4 if there is adequate detail, or to step 3 if there is not. (Different deliverables may have differing levels of decomposition)

Identify constituent components of the deliverable. Repeat Step 2 on each constituent component

Verify correctness of the decomposition:

a.        Are the lower level items both necessary and sufficient for completion of the decomposed item? If not the constituents components must be modified (add, delete, redefine)

b.       Can each item be appropriately scheduled? Budgeted? Assigned to a specific organizational unit (department, team, person) who will accept responsibility for satisfactory completion of item? If not, revision are nodded to provide adequate management control

Role Description

Project Sponsor Role

One of the important project stakeholders is the project sponsor. The project sponsor should have the influence to ensure that the project has sufficient priority to enable success. The sponsor along with the Steering Committee is also responsible for providing the funding and staffing resources to complete the project successfully.

The project sponsor usually represents the recipient of the project's end result. A good project sponsor is a prerequisite for a great project manager. The sponsor is usually head of a program area and not normally a day-to-day user. The project sponsor is typically part of the organization's management and should be a strong advocate for the project.

Project Sponsor Responsibilities

Steering Committee Role

The management or the Steering Committee identifies the need of project, assesses project risk, and approves project commitments.

They are responsible for ensuring that project is consistent with organization strategic plan.

They are also responsible for developing the procedures to ensure that policies are followed.

The Steering Committee assists the project manager in planning the development effort and makes commitments to complete the project within established schedule and budget constraints.

Steering Committee Responsibilities

Project Manager Role

The project manager has primary responsibility for the quality of a project's deliverables and its successful completion.

To succeed the project manager must work closely with the project sponsor to ensure that adequate resources are applied.

The project manager also has responsibility for planning and ensuring that the project is successfully completed on time and within budget. The project manager is assigned early in the conceptual and planning processes so the plan can be owned by the person responsible for its execution.

Project Manager Responsibilities

Development Team Role

The Development Team has responsibility for conducting project activities defined by the project life cycle.

The development team includes the specialists responsible for implementing the project solution. Stakeholders should interact with the development team to ensure that requirements are correctly implemented.

Development Team Responsibilities

End User

End users are responsible for ensuring that their needs are expressed and for verifying that a completed project meets those expressed needs.

End User Responsibilities

Change Request Form (Cerere de Modificare)

Cerere de Modificare

Risk Management Worksheet

A description of all risks identified for the project, the probability of the risk occurring, the impact of the risk on the project, and the suggested mitigation activities.

Last Risk Assessment Date: Prepared by:

Risk Reserve:

Suggested Preventive and Contingency Measures

Provide appropriate training.

Hire trained specialists.

Purchase additional equipment.

Implement product functionality in a phased manner.

Get agreement on who has decision authority; designate key user responsibility.

Negotiate better environment.

Ensure that all the resources are provided.

Adjust deadline and get our customer buy-in.

Do not commit to third-party performance.

Get third party commitment at least equal to (if not more than) our commitment.

Get customer commitment to participate in the project.

Increase estimates for the related tasks.

Do not commit to response time unless absolutely necessary and, then only if a study is done by knowledgeable persons.

Establish access to product support personnel.

Hold regular meetings with customer.

Maintain constant written and oral communication with remote personnel.

Demonstrate incremental results.

Divide staff into teams and assign team leaders.

Dedicate our management resources.

Establish final authority of our project manager.

Use proven hardware for development if possible.

Reduce functionality to meet deadline.

Document our assumptions and understandings and get Customer's sign-off before investing substantial resources.

Design an alternate (contingent) solution strategy.