Download - 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
8/3/2019 FoSPM Ref Project Change Control
http://slidepdf.com/reader/full/fospm-ref-project-change-control 2/11
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
8/3/2019 FoSPM Ref Project Change Control
http://slidepdf.com/reader/full/fospm-ref-project-change-control 3/11
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
8/3/2019 FoSPM Ref Project Change Control
http://slidepdf.com/reader/full/fospm-ref-project-change-control 4/11
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
8/3/2019 FoSPM Ref Project Change Control
http://slidepdf.com/reader/full/fospm-ref-project-change-control 5/11
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:
8/3/2019 FoSPM Ref Project Change Control
http://slidepdf.com/reader/full/fospm-ref-project-change-control 6/11
8/3/2019 FoSPM Ref Project Change Control
http://slidepdf.com/reader/full/fospm-ref-project-change-control 7/11
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
8/3/2019 FoSPM Ref Project Change Control
http://slidepdf.com/reader/full/fospm-ref-project-change-control 8/11
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.
8/3/2019 FoSPM Ref Project Change Control
http://slidepdf.com/reader/full/fospm-ref-project-change-control 9/11
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.
8/3/2019 FoSPM Ref Project Change Control
http://slidepdf.com/reader/full/fospm-ref-project-change-control 10/11