I wanted to create this picture to show you clearly the transition of deliverable to final

product, service or result within the project management context.

1.

Deliverables are created as part of the "Direct and Manage Project Execution"
process. As you would expect, the deliverables are outputs of the Execution process
group.

2.

The deliverable, thus created during project execution, is fed as input to the "Perform
Quality Control" process in Monitoring & Controlling process group. Necessary quality
control checks are carried out to ensure that the deliverable meet the requirements. At
the end of the process, we get the Validated deliverable as an output.

3.

The validated deliverable is sent as an input to the "Verify Scope" process. Here, the
client/ customer inspects the deliverable and accepts them. As such, the output of this
process is the accepted deliverable. The major difference between "Perform Quality
Control" and "Verify Scope" is that generally quality control is performed internally
within the performing organization while verify scope is performed with the client/
customer. They may be done sequentially or sometimes concurrently.

4.

Finally, the accepted deliverable is sent as an input to the "Close project or phase"
process in the Closing process group; and the output is Final product, service or result
transition. This refers to the acceptance of the final product, service, or result and the

turnover of the product to the organization. This usually requires a formal sign-off to
indicate that the product is accepted by the customer.
Hope the above picture helps you to remember the flow of deliverables better. What do you
think? Please leave your comments.

Integrated Change Control Sequence of Change

Request
APRIL 7, 2014

Homepage > Blog > PMP > Project Integration Management > Integrated Change Control
Sequence of Change Request

Most of the times, I receive lots of queries on Sequence of Change Request by several PMP
aspirants preparing for the certification exam.This blog is a step towards addressing queries
related to Integrated Change Control Sequence of Change Request.
Irrespective of the reason, intensity or size of change, a formal change request is required to take
forward the change to be a part of the project activities or project baselines.And, how the change
request need to documented, managed, monitored and controlled in the project is defined in the
Change Management Plan.
Let us begin by answering what is a Change Request?
As per PMBOK Guide Fifth Edition,

Change Request is a formal proposal to modify any project document, deliverable or

baseline.
The reasons for a change request can be:

Preventive actions How to prevent potential non-conformities in the project, e.g.

training the team members on new technology required in the project. For this training, a change
request is required as it may impact the schedule baseline (for the days of training) and cost
baseline (for training cost). The proposed training may prevent some amount of rework in the
project.

Corrective actions How to correct non-conformities in the project, e.g. Noncompliance

points reported post audit which can refine the projects process. A change request is required to
implement these corrective actions in the project as it may change the schedule and scope of the
project.

Defect repair, e.g. rework which is required to rectify the points identified as defects
while inspection will be logged as change request (s)

An update request for any change in the project, e.g. change in project scope or some
compliance related work needed to be done via following a change control process of the project.
Now, we come to our next segment WHY formal change management process?
It is a common perception that why follow so many formal steps for very small changes in the
project, which may not even impact the project baselines or project plans. It is important to
understand that the impact of any change shouldnt be assumed. The formal change control
process is required to analyze the impact of change so that the respective planning can be done in
advance.
Lets exemplify it Ray is the project manager of a website development project. His client sent
a scope change for the website and requested Ray to implement the change in the project
deliverable which is due after 2 days. As per client,the change is small and can be sent with due
deliverable.
Ray and his team conducted a meeting to discuss the change and decided to implement the
change without following formal change control process. As they assumed that change is quite
small and no need for so many formal steps. They implemented the change on project deliverable
without doing even any impact analysis.
The deliverable was not accepted by the customer, as the new scope added was not working as
desired. This failure of new scope added, ended in several defects from the customer.
Ray realized that the defect repair will take 5 days and that he needs to review the schedule
baseline and add the new scope in scope baseline as well. The mistake what Ray and his team did
was that they just added the scope without doing any impact analysis. Since, impact analysis not
done, scope baseline doesnt contain the information regarding the new scope added recently.
The quality control team while doing the inspection of the deliverable missed to inspect the new
functionality added since it was not the part of requirements and scope baseline against which
they were checking the deliverable. So, here we can see a small change in the scope of the
product has cascaded into a large amount of rework afterwards.
If Ray had followed the formal change control process for the scope change received from the
customer irrespective of what the client is saying or without any assumption about change, all the

impacted documents/ plans/baselines would have been updated. And, at the time of quality
control of the deliverable, all the non-compliance with the requirements must have been captured
before deliverables sent to the customer for acceptance.
Sequence of Change Request-

Whenever a change request is received or suggested or identified, itneeds to be logged in

the Change log of the project. Irrespective of the size of the change or the impact of the change,
each and every change need to be logged in the change log

Project manager alone cannot do the impact analysis, inputs from the project team and if
required, from stakeholders are needed. In impact analysis, the impact of the proposed change is
analyzed on all project constraints like on scope, schedule, quality, risk, cost or any other project
dimension. This is a very important step in integrated change control as impact analysis will be
considered as input for the Change requests approval or rejection.

Once the impact analysis done, it is provided to CCB along with change request for the
decision of Approval/Postponed/Rejection. In several organizations, authority to take decision on
change request lies with Project Manager also, depending on the level/impact of change. And if
the impact of change is bigger than that, change request goes to CCB for further decision. A
point to remember here Before Change request is reviewed by the CCB; Impact analysis must
have done by the project team as it is the input to CCB for taking decision on change request.
OnceCCB takes the decision, it needs to be registered in the change log.

If Change request gets approved, the work related to change request becomes part of the
project and all related project documents, plans and baselines got updated. For these updates
impact analysis is referred to get the information what all need to be reviewed/updated.

If Change request gets Rejected or Postponed, the communication is sent torequestor /

stakeholder withthe reasons of rejection or postponed.

Record of Change request in the change log need to be updated for all details regarding
change request like what decision has been taken on it, the reasons for rejection/postponed, and
if accepted then what are the follow up steps.
Now, you must have understood what all Integrated Change Control is all about and how it
impacts the entire performance of the Project and project team. Thus, not only the presence of
change control process is needed in the project, but it has to be followed in the project
consistently too. Change control process prevents unnecessary risks to the objective or the
success of the project.
You can join the discussion on the same and do post follow up questions here on
our DISCUSSION FORUM. You may also want to check our other blogs on PMP Trainings