fospm ref project change control

8/3/2019 FoSPM Ref Project Change Control

http://slidepdf.com/reader/full/fospm-ref-project-change-control 1/11

Project Change Control

Change Control is a critical component to the successful development of Viking. It

is the means by which we will control the scope of the program and make

adjustments to the expectations of the program due to the impacts of unforeseenor unmitigated risks. The intent is to control the integrity of the baseline

schedule, products, and avoid unnecessary impacts to cost, risk, quality, and

staffing.

Several triggers can result in the submission of a Change Request:

• Analysis of Performance Metrics may drive CR’s that adjust scope, schedule,

resources etc.

• Defects in code or requirements that requires additional effort to resolve

All project deliverables are subject to control under the Change Control

Processes. In addition, anything that may impact scope, cost, or schedule must go

through the Change Control Process.

Change control in the Viking program will consist of a Change Control:

Plan – Comprised of the following processes

o Change Request submission

o Change Request evaluation

Benefit Analysis

Cost Analysis

Development

Maintenance

Program Impact Analysis

Prioritization

o Escalation

Request and Tracking Metrics

Change Board



Change Request Implementation

Communication

4.1 Change Control Plan

The Change Control Plan establishes the Change Control processes of the Viking

program, covering Change Requests any Viking Team Members or ABC Systems

executives. These processes establish the programs expectations for handling

change within the development lifecycle. The Change Control Plan governs the

following work products:

• Change Control Plan and its processes

• Work Breakdown Structure and all work products defined therein

• Program Scope



Figure 4 : Change Management Process

4.1.1 Change Request Submission

A Change Request (CR) can be entered by anyone within the Viking program. The

individual enters the CR into the Request and tracking system, see Change



Management. The individual is responsible for providing the required information

including a clear description of the change. The description should be written in a

manner that is understandable by the Change Board. If the description is unclear

or ambiguous it will be returned to the submitter for clarification. If the CR is

created by a developer or tester it must be reviewed by the functional lead before

being sent to the Steering Committee for evaluation.

4.1.2 Change Request Evaluation

The Change Request evaluation step ensures that the CR’s impact to the program

and product has been thoroughly analyzed. The author of the CR may draw on

other resources such as the Architects, and Program or Project Management to

aid in the analysis. The evaluation is the responsibility of the CR’s author and is

comprised of the following four areas:

Benefit Analysis: The CR must include a Benefit Analysis when the change type is

a functional or technical enhancement to the existing requirements. The costs

should evaluate the benefit from at least one of the following perspectives:

Usability, Maintainability, Performance, and projected value in dollar sales. If the

CR is for a work product that has been found deficient after it has been released

by the developer to the testers the requestor should document the risk of not

fixing the bug and include it in the benefit analysis as cost avoidance.

Cost Analysis: Cost analysis will include the determination of the person hours

required to develop the requirement including; inception, elaboration,

construction, and transition.

Estimate the number and type of additional resources needed to develop the

functionality. In addition, a projected cost of maintenance should be created that

takes into consideration the complexity and size of the proposed functionality.

Program Impact Analysis: Program Impact Analysis needs to look at both the

benefit and cost to of the CR to the program. Estimate the benefit or cost due to

reducing or increasing overall labor effort for development. Document the impact

to the schedule and when appropriate any risks that the CR introduces or



removes. Should a risk be introduced the author must document a risk mitigation

plan.

Prioritization: The author should propose a relative priority to the rest of the

work for the change along with a rationale for the priority.

Once the analysis is complete the CR should be submitted for review by the ABC

Systems Architecture and Project Management team to evaluate. The author

should be prepared to discuss the CR should further clarification be required. The

purpose of this review is to ensure that the analysis and rational is consistent with

the program’s direction. The team will meet once a week for one hour. The

results will be compiled and sent to the Change Board for their review once every

two weeks.

4.1.3 Escalation

Should a change request require escalation due to immediate impacts on the

program the CR will be routed to the Architect and Project Management team for

immediate evaluation. Immediate impacts are those impacts that will place an

immediate constraint of current activities including major schedule impacts,

testing that uncovers either an architecture or design flaw that impacts a major

module or has collateral impacts to other significant modules. The CR must have aFunctional or Technical lead approval to be escalated prior to sending it to the

Architect and Project Management teams. If warranted, it will be forwarded to

the Change Board for their approval via Email or by having a special Change Board

meeting.

4.2 Request and Tracking Metrics

For the purpose of supporting Change Management performance metrics the

following data will be tracked:



Table 10 : Change Request & Tracking Metrics

4.3 Change Board

The Change Board is comprised of the ABC Systems Stakeholders including as

voting members: the President, and the VP of Marketing. In addition, the ProjectManager and ABC Systems Sr.

Architect attend to support any questions or discussions requested by the voting

members. The Change Board meeting is chaired by a member of the Viking



Project Management Team and is conducted twice a month for two hours. The

following agenda outlines the Change Board Meeting:

Review New CR’s submitted to the Change Board the prior week for their

consideration.CR’s will be reviewed in the priority order recommended by the Viking PM

and Architect.

Any voting member can request that another CR be discussed out of order.

Each CR is presented to the Change Board and they can request to discuss

any point of the CR including its scope, priority Cost Benefit analysis etc.

The Change Board then Approves, Rejects or requests additional analysis to

be done on the CR. If the CR is rejected, the PM notes the rationale in the

CR Tool.

The Change Board then Approves or requests modification to the CR’s

priority. At this point all of the Approved and new CR’s will be presented in

one view so that their relative priority can be seen by the voting members.

If they agree with the priority of the new CR, the review is complete and

the Change Board moves onto the next CR. If they disagree with the priority

the CR sent back for reevaluation and the Change Board moves onto the

next CR.

The Change Board will continue to discuss CR’s until all new CR’s have been

discussed or until the meeting duration is exceeded. Any CR’s not discussed

will be deferred until the next Change Board meeting.

4.4 Change Request Budget

20% of total project costs has been set aside as a change budget. The project

stakeholders shall be notified weekly of the costs to administer and implement

changes, and the amount of change request budget remaining.

4.5 Change Request Implementation

Approved CR’s are implemented by incorporating their activities into the master

(baseline) schedule. After they are added to the schedule all changes are sent out

to the impacted personnel.



The personnel are notified of any changes in priority or schedule start/end dates

for items they are currently working. They will also see the updates on their

weekly activity report. The CR’s progress is then tracked through the master

schedule.

The same process is followed for cancelled CR’s except a request for incomplete

actives is sent to the assigned resources. Those resources are requested to

provide back an unfinished work and that work is placed in an archive folder.

Should a request to re-activate the cancelled CR be made, the original work will

be sent out to the newly assigned resources.

4.6 Communication

Communication is one of the most important aspects of the Change Control Plan.

Keeping the stakeholders and team members up to date on the changing aspects

of the project is imperative to maintain a sense of control and ownership. The CR

initiation meetings will introduce the team members to the CR and allow them to

ask questions. The CR will be presented by the Project Manager and supported by

an Architect and the Change Request’s author.

fospm ref project change control

Documents