An excellent indicator to the experience level, professionalism, and
overall project management maturity of an individual is how much effort
and thought he/she gives to the management of the actual project work
products (deliverables). This area of project management is one of the most neglected, yet it is a
foundational element of managing risk, quality, and stakeholder
expectations on any project. Without it, you will inevitably incur
additional work efforts, lower quality, and more costs—which generally
leads to missed project objectives and disappointed stakeholders.
By managing project deliverables, we mean the process by which the project work products are controlled. The work products can include anything resulting from project activities, including any deliverable, document, or project management item. And by control, we mean managing the changes to the actual work products themselves. The most common term for this process is configuration management. The change control system manages changes to a critical success factor (time, cost,
scope, and quality) for the project. The exact nature and details of this process will vary by project and the types of deliverables involved. The project planning document that defines this process is
generally called the configuration management plan.
Configuration management is often neglected because it is a non-glamorous, mundane aspect of project management that requires a certain discipline to carry out. In addition, this area of project management tends to fall victim to many ill advised assumptions and to the notion that this is just common sense and it will just happen automatically. Real-world experience would say otherwise.
Especially in the digital age, if you do not think about where your project files will be stored, who has access to them, how they will be protected, how changes will be made, and how changes will be tracked, your project is carrying a significant risk—and in most cases, an unidentified risk.
In many organizations today, enterprise configuration management tools are being implemented to better protect and control all digital assets of the organization, especially documents. In a work environment where configuration management is an integral part of the project management approach there isn't any issue but otherwise it is often tempting. A question which might trigger your mind is Why should we plan out the details for how specific work products are going to be managed?
Here are a few reasons why:
Where is that file?—The ability to quickly locate project information for a key stakeholder or to help resolve an important issue.
Lost productivity—Avoid instances of lost productivity when the work of one team member is overwritten by another team member, or when the product configuration you are testing does not have the latest versions of all components—thus making the test run invalid.
Baseline? What baseline?—Avoid instances where you cannot “go back” or “restore” previous versions of work products.
Who made that change?—Avoid instances where you cannot clearly tell (or explain) when changes were made and who made them.
Who approved that change?—Avoid instances where changes are made to work products that are not properly reviewed and approved. To say the least, this can lead to quality and customer satisfaction issues.
That will never happen to us—A major or minor disaster occurs that wipes out one or more work products. Where is your backup copy? Can you recover?
We said we would do what?—On projects with numerous deliverables and work products, it is easy to lose sight of the minor or auxiliary work items. A basic deliverable tracking mechanism can go a long way to prevent this from occurring.
I’ve got your official sign-off right here...now where did that go?—Assuming you have official client acceptance of your key deliverables, make sure you have a way to protect this evidence going forward.
You have no choice—In many environments, there are legal, regulatory, or process compliance requirements that must be met. In each of these cases, having control over work product changes is an absolute must. Most of this activity is focused on protecting the integrity of the work product and providing associated audit trials (evidence).
The ultimate reason: negotiating power—There is tremendous political power in having tight control over project work products. If targeted work products are officially approved, you have a clear audit trail on any changes to those work products, and those official sign-offs are protected, you are well-positioned to deal with any scope or requirements dispute. In addition, a historical record of all project management work products, such as project schedules, issue logs, status reports, and meeting minutes can be very valuable in negotiating new issues.
By managing project deliverables, we mean the process by which the project work products are controlled. The work products can include anything resulting from project activities, including any deliverable, document, or project management item. And by control, we mean managing the changes to the actual work products themselves. The most common term for this process is configuration management. The change control system manages changes to a critical success factor (time, cost,
scope, and quality) for the project. The exact nature and details of this process will vary by project and the types of deliverables involved. The project planning document that defines this process is
generally called the configuration management plan.
Configuration management is often neglected because it is a non-glamorous, mundane aspect of project management that requires a certain discipline to carry out. In addition, this area of project management tends to fall victim to many ill advised assumptions and to the notion that this is just common sense and it will just happen automatically. Real-world experience would say otherwise.
Especially in the digital age, if you do not think about where your project files will be stored, who has access to them, how they will be protected, how changes will be made, and how changes will be tracked, your project is carrying a significant risk—and in most cases, an unidentified risk.
In many organizations today, enterprise configuration management tools are being implemented to better protect and control all digital assets of the organization, especially documents. In a work environment where configuration management is an integral part of the project management approach there isn't any issue but otherwise it is often tempting. A question which might trigger your mind is Why should we plan out the details for how specific work products are going to be managed?
Here are a few reasons why:
Where is that file?—The ability to quickly locate project information for a key stakeholder or to help resolve an important issue.
Lost productivity—Avoid instances of lost productivity when the work of one team member is overwritten by another team member, or when the product configuration you are testing does not have the latest versions of all components—thus making the test run invalid.
Baseline? What baseline?—Avoid instances where you cannot “go back” or “restore” previous versions of work products.
Who made that change?—Avoid instances where you cannot clearly tell (or explain) when changes were made and who made them.
Who approved that change?—Avoid instances where changes are made to work products that are not properly reviewed and approved. To say the least, this can lead to quality and customer satisfaction issues.
That will never happen to us—A major or minor disaster occurs that wipes out one or more work products. Where is your backup copy? Can you recover?
We said we would do what?—On projects with numerous deliverables and work products, it is easy to lose sight of the minor or auxiliary work items. A basic deliverable tracking mechanism can go a long way to prevent this from occurring.
I’ve got your official sign-off right here...now where did that go?—Assuming you have official client acceptance of your key deliverables, make sure you have a way to protect this evidence going forward.
You have no choice—In many environments, there are legal, regulatory, or process compliance requirements that must be met. In each of these cases, having control over work product changes is an absolute must. Most of this activity is focused on protecting the integrity of the work product and providing associated audit trials (evidence).
The ultimate reason: negotiating power—There is tremendous political power in having tight control over project work products. If targeted work products are officially approved, you have a clear audit trail on any changes to those work products, and those official sign-offs are protected, you are well-positioned to deal with any scope or requirements dispute. In addition, a historical record of all project management work products, such as project schedules, issue logs, status reports, and meeting minutes can be very valuable in negotiating new issues.
No comments:
Post a Comment