Project Management Lecture 11-12
Project Management Lecture 11-12
Management
Credit Hours: 3.00
BRAC University
SL Topic Week/Lecture
3 Investment Appraisal 03
Course
5 Project Management Plan, Work Breakdown Structure 05
9 Risk Management 09
12 Cost Management 12
13 Project Closing 13
Project
Configuration
Management
Project Configuration
Management
• Project configuration management (PCM) is the
collective body of processes, activities, tools and
methods project practitioners can use to manage
items during the project life cycle. PCM addresses the
composition of a project, the documentation defining
it, and other data supporting it.
• They help maintain the integrity of the products being
developed and prevent scope creep and unintended
changes.
• Configuration management can be regarded as an
asset control and it is essential whether one or more
versions of a deliverable is created.
History
• Configuration Management originated in the United States Department of Defense in
the 1950s as a technical management discipline for hardware material items.
• The CM process became its own technical discipline sometime in the late 1960s when
the DoD developed a series of military standards called the "480 series”.
• Now Technical Standards are developed by Standards Developing Organizations
(SDO). Three main SDOs are:
• International Organization for Standardization (ISO)
• International Electrotechnical Commission (IEC)
• International Telecommunication Union (ITU)
• Some other organizations also set up Standards.
• American Society of Mechanical Engineers (ASME)
• American Society for Testing and Materials (ASTM)
• IEEE
• World Wide Web Consortium (W3C)
Configuration
Management Activities
Source: PMI - Practice Standard for Project Configuration Management (2007, Project Management Institute)
Configuration Change Control
• The change control process includes the following steps:
• Baseline: This is the latest baseline released by CM.
• Submit Change Request: This step prepares the request,
ensuring that adequate
• information is supplied to allow proper assessment of the
impact of the change.
• Verify Change Request: This step ensures that all the
information needed to carry out an evaluation has been
provided. It establishes relationships between the proposed
changes and the items that will be impacted by the change.
• Evaluate Impacts: This step evaluates the impact of the
proposed change. Technical, cost, schedule, security, and
contract impacts are all evaluated. Identifying the appropriate
people to carry out the evaluation may be challenging. The
need to ensure that all impacts are identified must be
balanced with the need to executing the process efficiently by
doing only the necessary evaluations.
Source: PMI - Practice Standard for Project Configuration Management (2007, Project Management Institute)
Configuration Change Control
• Review Decision and Plan: This step considers the
proposed change in light of the evaluated impact. The
authority required to approve a change will vary according
to the type and status of items affected. A proposed
change may, of course, be rejected. Items which actually
need to be changed are confirmed and work packages are
established and/or adjusted.
• Implement Change if Approved: This step makes the
change, tracks the progress, and reports status to the
tracking system. Relationships between the change
record and the item(s) actually affected by the change are
established and updated.
• Conclude Change Process: This step ensures that the
CCM process has been correctly followed and that there
is appropriate evidence that changes have been
satisfactorily implemented (typically a review process for
documents, testing for code). Authority to conclude a
change is the same as the authority to prove it. Status is
reported to the tracking system.
Source: PMI - Practice Standard for Project Configuration Management (2007, Project Management Institute)
Configuration Status Accounting
Configuration Status Accounting
• Configuration status accounting involves tracking and reporting on the
status of configuration items throughout the project lifecycle. The goal
is to maintain accurate records and details about each Configuration
Items.
• You should be able to see that an item is Open, Closed, In Progress,
Checked Out (and to whom) or any other status that you’ve decided to
give it.
• Every time the item is changed or being worked on, the matrix should be
updated so that it’s clear what is happening to the item. Then the latest
version is logged too, so that you can always refer to the current version.
Configuration Status Accounting
• A configuration management database (CMDB) is used to
store configuration records for each item. Details include:
• Item name/identifier
• Version number
• Description
• Status (development, testing, production, retired)
• Changes made
• Change History
• Relationships and dependencies
• Owner, approvers
• Storage location
• Baselines associated
Configuration
Verification and Audits
Configuration Verification and Audits
• Formal Audits
• Functional configuration audits – Verify that a CI’s design is aligned
with requirements. Done at major milestones.
• Physical configuration audits – Verify that versions and configuration
documentation match the actual physical configuration. Done before
major releases.
• In-depth audits – Validate CIs against test baselines and configuration
documentation. Trace changes end-to-end.
Configuration Verification and Audits
• Informal Audits
• Peer reviews of configuration items and documentation
• Spot checks of baselines, documentation, and physical
configurations
• Sample testing to check for consistency and accuracy
Any discrepancies found during verification are logged and change
requests are submitted to correct them.
Configuration Verification and Audits