Change Control Process
04/07/20 13:57
Controlling Project Changes
Introduction
• It’s a fact - project changes are inevitable!
• A project will undergo changes during some point in
the software development life cycle (SDLC).
• The key is controlling the changes to manage the
impact to the project plan, budget, and
implementation schedule
04/07/20 13:57
Controlling Project Change - Introduction
• Some changes will be unavoidable – instances
where changes have to be made to comply with
legal, federal / state regulations, policy changes,
compliance with changes in the business direction
of the enterprise, or where technology may dictate
change
• Other non-essential changes can be avoided
through management of a formal change control
process.
04/07/20 13:57
Controlling Project Changes
• The number one cause of project schedule and cost
overruns is project scope change.
• If scope changes are not controlled the project
schedule and budget will be destroyed before the
anyone recognizes that anything has happened.
• A well thought out change control process will assist
the project manager and team in controlling this
“scope creep” nemesis.
04/07/20 13:57
How to manage Requirement
• The formal, approved requirements document is
the first task that a project undertakes to start out
in control of the project.
• Placing the agreed-to requirements document
under strict change control (configuration
management) helps a project stay in control.
04/07/20 13:57
Steps to Controlling Scope Changes
• Three (3) steps are necessary to control scope
changes:
• Establish the baseline product.
• Obtain agreement from the project “approvers”.
• Enforce a formal change control process.
04/07/20 13:57
Establish the baseline product
Establishing the baseline product means describing
the product (business functional requirements) in
detail early in the software development process.
The product specifications define the product to the
level of detail that allows all project groups to
perform their activities productively.
The product specifications define what the product
being built looks like. When the product is properly
defined the project manager and team members
know “what is in and what is out of the project
scope.
04/07/20 13:57
Agreement from the project “approvers” or sponsors
• Get the agreement from the right people, or
organizations, on the business functional
requirements of the product being built.
• All groups dependent on complete and accurate
product specifications must approve the document
to ensure that it meets their needs. When the
product being built meets the needs of the users
fewer changes need to be made.
04/07/20 13:57
Enforce a formal change control process
• The software development process is never
static. Some changes are to be expected
during the product build, and a formal
process must be defined and followed to
make sure all changes to the product are
made in an orderly manner.
04/07/20 13:57
• As scope change requests are made, a change
control process is necessary to insure that the
following occurs:
• Only necessary changes are made,
• Changes are communicated to all affected
parties, and
• Changes are implemented in an orderly
fashion.
04/07/20 13:57
Defining a Change Control Process
• Any good change control methodology will have
four (4) components or subsystems. These
subsystems are:
• Change Request Form
• Change Review and Evaluation
• Change Priority and Classification
• Change Approval
04/07/20 13:57
Important Note
• Please note that there are two (2) separate
reviews that occur during the change control
process. These reviews are:
• First, to validate the change proposal is justified,
and
• Second, to access the impact of the change on
the project.
04/07/20 13:57
Change Request Form
• A project change request form should be
created and approved prior to the project’s
startup. At a minimum, the change
request form should contain the following
information…..
04/07/20 13:57
Change Request Form
• Originator’s name and phone number,
• Submission date,
• Description of the problem that the change
addresses,
• Description of the change,
• Justification for the change,
• Date the change is needed (if applicable),
• Change category (type of change or reason for
change)[1],
• Impact write-up addressing the affect the change
has on project schedule and budget,
• Approval disposition (accepted or rejected boxes),
• Project Manager’s signature and date,
• Project Sponsor’s approval, signature, and date,
and
• Date change is updated into the Change Request
04/07/20 13:57
Log and updated into the project plan.
Change Review or Evaluation
• A change review committee, or board, must be
established to evaluate all change requests. The
number of participants on the committee, or board,
is dependent upon the project size and complexity.
On a small project, the project manager may review
and approve change requests. On larger complex
projects, a review committee or board may be more
appropriate.
04/07/20 13:57
Change Review or Evaluation
• The change review committee or board is made up
of a cross selection of technical team members.
Review committee members should be selected
who have the expertise to truly assess the impact
of the change request on the project’s scope.
• A set turnaround time must be established for the
review process from submission to acceptance or
rejection. This ensures that an “approved” change,
along with the appropriate activities or tasks, is
entered into the Project Plan in a timely manner.
04/07/20 13:57
Change Priority and Classification
• P1 – Critical: A critical priority change request is
considered to be imperative to the success of
the project, and likewise, may have a detrimental
impact to the project if not addressed promptly.
This type of change request is mandatory and
must be completed. The timeframe for
estimating the effort and cost required to
implement a critical change request should be
one (1) week or less. Examples of critical
change requests are legal mandates,
functionality to meet core business process
requirements, or data integrity with respect to
database content.
04/07/20 13:57
Change Priority and Classification
• P2 – High: A high priority change request is
considered to be important to the success of
the project. The timeframe for estimating the
effort and cost required to implement a high
priority change request should be two (2) to four
(4) weeks. Examples of high priority change
requests are issues and problems resulting from
data integrity, legal mandates, and add-ons to
improve data quality.
04/07/20 13:57
Change Priority and Classification
• P2 – Medium: A medium priority change request has
the potential to impact successful completion of the
project but is not an immediate help nor hindrance.
The timeframe for estimating the effort and cost
required to implement a medium priority change
request should be four (4) to six (6) weeks. Examples
of medium priority change requests are requests that
improve workflow processes
04/07/20 13:57
Change Priority and Classification
• P3 – Low: Low priority change requests need to
be addressed if the time and budget permit. Low
priority changes requests are managed, as
resources are available. The timeframe guideline
for estimating the effort and cost required to
implement a low priority change request is more
than six (6) weeks. Examples of low priority
change requests are cosmetic changes or “fixes”
that do not affect business functional
requirements or deliverables.
04/07/20 13:57
Change Approval
• The change control criteria that was set
forth in the Statement of Work (SOW) or
Requirements document is used to
measure the acceptability of the proposed
change.
• The change control criteria defines the
boundaries, or range, within which
changes will be accepted, and at what
level the change request gets escalated to
higher management for the final decision.
Remember: All change requests alter the scope of the project in some
manner; thereby effecting the project completion date and the project
budget.
04/07/20 13:57
Change Approval
• The following are examples (samples) of
boundaries or ranges for change requests are:
• The change does not alter the completion date or
increase the project budget.
• Executing the change request takes a maximum of
“h” hours of staff time to complete.
• The cost of the change is less than “$$$” dollars.
• The benefit of the change must always exceed
the projected cost of the change
Caution: The project should be careful when specifying a “specific”
dollar amount as change criteria. Each dollar amount adds up and
before the project manager and sponsors realize it,
the project budget has been significantly enhanced.
04/07/20 13:57
Recognizing Scope Change
• In order to manage scope changes, you
must be able to recognize the forms
that scope changes can take. They
come in many disguises – some are
easy to recognize, some are not. Scope
changes may be….
04/07/20 13:57
Recognizing Scope Change
• Overt client requests. These are the easiest to
identify. The client makes a formal request for an
additional function to be incorporated into the
product.
• Covert client requests. These scope changes
sneak in when the project manager isn’t looking.
Someone on the client team makes an informal
request of someone on the project team (e.g., one
more report, one more inquiry view, or a new area
of functionality
04/07/20 13:57
Recognizing Scope Change
• Smuggled requirements. These scope changes
need a sharp ear to catch. The changes are
introduced as part of normal information gathering /
status reporting processes and usually reflect
overlapping areas of the software project. “For
example, your team is conducting a workshop to
determine detailed requirements for a purchasing
system and among the requirements discussed is a
set of requirements for calculating vendor payables.
The scope of purchasing has just been expanded
to encompass accounts payable.”
• Project team enthusiasm (design changes).
These scope changes represent the “Wouldn’t it be
nice if….” things or functions introduced by the
enthusiasm of the project team that involve “over
design”, “over build”, or unapproved testing of new
design techniques
04/07/20 13:57
Recognizing Scope Change
• Problem Reports. These changes are the result of
system incident reports (SIR) or problem resolution
reports that identify a non-compliance to the
business functional requirements or the detailed
design document. Problem reports will usually
result in a change request.
• Issues. System issues will be created during the
entire system development life cycle. Issues must
be reviewed, estimated, and approved by
management. Some issues may result in a change
request. Other issues may be deferred to future
releases or rejected outright
Primary emphasis: If the activity is not listed in the business functional
requirements document, the baseline project plan, or the detailed work
breakdown structure (WBS),
04/07/20 13:57
the activity is a scope change.
How to find Scope Changes
• Repeat, repeat, and repeat again the project
scope. Make sure everyone on the team
understands and accepts the project scope. Make
it a habit to reiterate the project scope at
meetings. The more the project scope is etched in
the team’s and customer’s minds, the easier it is
for them to recognize a “scope change” when it
comes up.
• Make sure the project scope is visible to everyone
on the team. Use mottoes, posters, or other
advertisements to ingrain the scope into the team
mindset.
• Ensure the project scope is included in any
04/07/20 13:57 orientation materials given to new team members
• During weekly team meetings, conduct a separate
roundtable to review scope change requests.
• Whenever you or any technical leaders need to
make a project decision, make sure the project
scope is included as one of the factors contributing
to the decision.
• During periodic reflections on the project, include
the project scope as a subject for review
04/07/20 13:57
Tracking Change Requests
• Two (2) things need to happen after the change
request has been accepted
• Update the project plan with the new activities and
tasks created by the change request and adjust
the project schedule, plans, dates, deliverables,
and dependencies.
• Log the change request into the project’s Change
Request Log and tracks the change through task
completion
04/07/20 13:57
Reviewing Scope Changes Considerations
• The number one consideration as the project
manager and change review committee assess the
proposed change request is:
• “What effect will this change have on the
project’s outcome?”
• The bottom line to every change request is that
it adds additional overhead to the project.
04/07/20 13:57
Reviewing Scope Changes Considerations
• The Change Request Log as well as the Change
Request Form become part of the documentation
and are used to indicate the state of the scope
change – approved or rejected.
• Key information the Change Request Log tracks
is:
• Change request number,
• Date submitted,
• Short description of the change,
• Priority for change (high, normal),
• Estimated Cost,
• Approval or Rejection column,
• Date approved/rejected,
• Date project schedule plan updated, and
• Comments (options).
04/07/20 13:57
[Department/Agency Name]
[Project Name]
Project Change Request
SECTION A: CHANGE REQUEST DESCRIPTION
Request Date: mm/dd/yyyy Change #: nnnn
Type of Change: Priority: P-n
Non-Compliance ____ Functional/Design Change
____ Requirements’ Change ____ Regulatory
Requestor: _______________________________
Description of the Requested Change (Long Description):
Reason for Change:
04/07/20 13:57
SECTION B: IMPACT ASSESSMENT
Change Request (Short Description):
Workgroup(s) Impacted by the Change:
Estimated Impact to budget, work effort and schedule:
Total Estimated Cost: Estimated Revised Completion
Date: .
SECTION C: PROJECT MANAGEMENT APPROVAL
Status: Open / Closed
Reviewer: _____________________________________________
Comments:
__________________________________________________________ _________
[Requestor] Date
__________________________________________________________ _________
[Project Manager] Date
__________________________________________________________ _________
[Project Sponsor or Approver] Date
04/07/20 13:57
Change Request Status Report Cumulative Change Request Summary Report
As of MM/DD/YYYY
Severity New Open Deferred Duplicate Closed Total
Critical
High
Medium
Low
Total
%
04/07/20 13:57
Change Request Log (sample)
[Department / Agency Name]
[Project Name]
Project Change Request Log
CHANGE DATE DESCRIPTION Priority ESTIMATE REVISED APPROV DATE COMMENTS
REQ. SUBMITTE OF (Normal D COMPLETIO ED
NO D CHANGE or Urgent) COST N DATE
. REJECT
ED
04/07/20 13:57
Impact Analysis Checklist for Requirements Changes
• Implications of the Proposed Change
• Identify any existing requirements in the baseline
that conflict with the proposed change.
• Identify any other pending requirement changes
that conflict with the proposed change.
• What are the consequences of not making the
change?
• What are possible adverse side effects or other
risks of making the proposed change?
04/07/20 13:57
Impact Analysis Checklist for Requirements Changes
• Will the change affect any system component
that affects critical properties such as safety and
security, or involve a product change that
triggers recertification of any kind?
• Is the proposed change feasible within known
technical constraints and current staff skills?
• Will the proposed change place unacceptable
demands on any computer resources required for
the development, test, or operating
environments?
04/07/20 13:57
Impact Analysis Checklist for Requirements Changes
• Is the proposed change feasible within known
technical constraints and current staff skills?
• Will the proposed change place unacceptable
demands on any computer resources required for
the development, test, or operating environments?
• Must any tools be acquired to implement and test
the change?
• How will the proposed change affect the sequence,
dependencies, effort, or duration of any tasks
currently in the project plan?
04/07/20 13:57
Impact Analysis Checklist for Requirements Changes
• Will prototyping or other user input be required to
verify the proposed change?
• How much effort that has already been invested
in the project will be lost if this change is
accepted?
• Will the proposed change cause an increase in
product unit cost, such as by increasing third-
party product licensing fees?
• Will the change affect any marketing,
manufacturing, training, or customer support
plans?
04/07/20 13:57
System Elements Affected by the Proposed Change
• Identify any user interface changes, additions, or
deletions required.
• Identify any changes, additions, or deletions
required in reports, databases, or data files.
• Identify the design components that must be
created, modified, or deleted.
• Identify hardware components that must be added,
altered, or deleted.
04/07/20 13:57
System Elements Affected by the Proposed Change
• Identify any changes required in build files.
• Identify existing unit, integration, system, and
acceptance test cases that must be modified or
deleted.
• Estimate the number of new unit, integration,
system, and acceptance test cases that will be
required.
• Identify any help screens, user manuals,
training materials, or other documentation that
must be created or modified.
• Identify any other systems, applications,
libraries, or hardware components affected by
the change.
• Identify any third party software that must be
purchased.
04/07/20 13:57
System Elements Affected by the Proposed Change
• Identify any impact the proposed change will have
on the project’s software project management
plan, software quality assurance plan, software
configuration management plan, or other plans.
• Quantify any effects the proposed change will
have on budgets of scarce resources, such as
memory, processing power, network bandwidth,
real-time schedule.
• Identify any impact the proposed change will have
on fielded systems if the affected component is
not perfectly backward compatible
04/07/20 13:57
Effort Estimation for a Requirements Change
Effort (Labor
Hrs.) Task
Update the SRS or requirements database with the new requirement
Develop and evaluate prototype
Create new design components
Modify existing design components
Develop new user interface components
Modify existing user interface components
Develop new user publications and help screens
Modify existing user publications and help screens
Develop new source code
Modify existing source code
04/07/20 13:57
Effort Estimation for a Requirements Change
Purchase and integrate third party software
Identify, purchase, and integrate hardware components; qualify vendor
Modify build files
Develop new unit and integration tests
Modify existing unit and integration tests
Perform unit and integration testing after implementation
Write new system and acceptance test cases
Modify existing system and acceptance test cases
Modify automated test drivers
Perform regression testing at unit, integration, and system levels
Develop new reports
Modify existing reports
Develop new database elements
Modify existing database elements
Develop new data files
Modify existing data files
04/07/20 13:57
Procedure:
• Identify the subset of the above tasks that will have
to be done.
• Allocate resources to tasks.
• Estimate effort required for pertinent tasks listed
above, based on assigned resources.
• Total the effort estimates.
• Sequence tasks and identify predecessors.
• Determine whether change is on the project’s
critical path.
• Estimate schedule and cost impact.
04/07/20 13:57
Impact Analysis Report Template
• Change Request ID: ______________
• Title: ______________________________________________________
• Description: ______________________________________________________
• ______________________________________________________
• Analyst: __________________________
• Date Prepared: __________________________
• Prioritization Estimates:
• Relative Benefit: (1-9)
• Relative Penalty: (1-9)
• Relative Cost: (1-9)
• Relative Risk: (1-9)
• Calculated Priority: (relative to other pending requirements)
• Estimated total effort: ___________ labor hours
• Estimated lost effort: ___________ labor hours (from discarded work)
• Estimated schedule impact: ___________ days
• Additional cost impact: ___________ dollars
• Quality impact: _______________________________________________
_______________________________________________
• Other requirements affected: ____________________________________________________
• ____________________________________________________
• Other tasks affected: ____________________________________________________
• ____________________________________________________
• Integration issues: ____________________________________________________
• Life cycle cost issues:____________________________________________________
• Other components to examine ____________________________________________________
• for possible changes: ____________________________________________________
04/07/20 13:57
Impact Analysis Report Template
Modify various project plans
Update other documentation
Update requirements traceability matrix
Review modified work products
Perform rework following reviews and testing
Recertify product as being safe, secure, and compliant with standards.
Other additional tasks
TOTAL ESTIMATED EFFORT
04/07/20 13:57
• Thank you 4 your time.
• Q/A Session
15 minutes.
04/07/20 13:57
