“Managing Project Deliverables” Means What, Exactly?

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. As discussed in Chapter 10, “Controlling a Project,” this process is related to the project change control system, yet it is different. 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 an unglamorous, 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 the notion that this is just common sense and 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. However, this movement is not universal across all industries or organizations yet, so you may likely still need to develop your own project-specific procedures to address the needs of your project.

“Why Do This? It’s Too Much Work!”

You might work in an environment where configuration management is an integral part of the project management approach, so this is not even an issue for you. For others, it is often tempting, as previously mentioned, to not give this area proper attention. So let’s answer the question, “Why should we do this?” Why should we plan out the details for how specific work products are going to be managed? From the collective experience of project managers across the land (not that any of these have happened to me or anything), 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 to 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 in preventing 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.

Identify, Protect, and Track: The Principles of Managing Work Products

Managing project work products is a strong example of the preventative aspects of project control. If you have a solid process in place, and you are using it, everything rolls along as expected. It’s only when you have a gap in this area that it attracts attention from stakeholders—generally unwanted attention. The principles of managing project work products are simple and can be boiled down to three management fundamentals:

• Identify—Define all the work products that need to be managed. Make sure all the work products are identified, not just the major ones and not just the product deliverables. For each deliverable type, you might need a different configuration management process. This is often true when dealing with both digital and tangible deliverables and when dealing with documents and software components. This can also be true when there are limitations with the configuration management tools that are available.

• Protect—Protect the integrity of the work product. This means that you need to be able to control who has access to the work product, control what changes can be made by each person, and recover the work product in the event of an unexpected accident or disaster. The access control can have several layers, but the most common aspects are facilities access, network access, and a separation of duties between development and operational roles. In addition, this means protecting any contractually significant approvals or sign-offs.

• Track—Be able to trace your steps and track the changes that are made to a work product. Common terms associated with this principle are “version control” and “revision history.” The other important aspect of this principle is the ability to provide status on the current state of all managed work products.

Best Practices

Whether you utilize manual or automated processes, here is a list of techniques that you should consider for your configuration management process:

• Establish central repository—First and foremost, define a central repository for the project where all project work documents will be stored. Make sure access to the repository can be controlled and that the appropriate stakeholders have access to it.

• Define review/revision/approval process—Define which work products need to be reviewed and approved when any change is made, who can make those changes, who needs to approve those changes, and the associated workflow that needs to be followed.

• Define a “gatekeeper”—Experience has shown tremendous value in establishing someone as the official librarian for the project repository. This person is responsible for controlling access to the repository, updating the repository, and ensuring that the configuration management procedures are being followed.

• Implement access controls—Ensure that the project repository is only accessible to authorized stakeholders and the granted access level is aligned with their role on the project. This becomes more important every day as the need to protect digital assets increases.

• Establish a common directory structure—To better organize work products and to make it easier to find them when you need them, it is recommended to define a directory structure that is aligned with the project phases and workflow process.

• Establish file-naming conventions—Also in the spirit of better organization of work products, it is recommended to define a common convention for naming project work products. The conventions provide consistency and help improve project communications and stakeholder expectations as well.

• Establish search keyword conventions—Given the growing popularity and use of Internet search engines, people are more accustomed to searching for what they need by the use of keywords. This can be especially helpful if the project repository directory structure is large or has multiple layers, and search capability can be a tremendous timesaver if it is less than obvious where a given work product can be found.

• Establish version numbering scheme—If these guidelines do not exist for your organization already, determine the rules that will govern the versioning scheme for each category of work product. Common elements to consider include version number format, differences between major and minor versions, and conventions to be followed.

• Establish baselines—This is a key best practice, especially before any milestone-type event on the project, such as phase end, tollgate, start of a testing phase, or releasing work product to a client. To effectively deal with any quality issues and client expectations, you must be able to clearly define (and maintain) the configuration of a work product at a given point in time.

• Use standard document sections—To help encourage effective configuration management practices, it is recommended to develop work product templates that contain standard document sections. Recommended document sections include the following:

  • Title page

  • Revision history page

  • Approval page

  • Standard header and footer formats/data

• Use a deliverable tracker—This is a powerful technique that can be utilized regardless of the sophistication of your process. Develop a mechanism to identify and track the status of your project work products. For lack of a better term, I will call this your deliverable tracker. This can be done with a simple spreadsheet program. Table 12.1 summarizes the key recommendations for your deliverable tracker.

• Back it up—Make sure that your project repositories have proper backup procedures in place and that they are actually working. You will be glad you did.

• Address needs of different work product types—A single configuration management process might not be adequate for your project. You should develop specific configuration management procedures for each type of work product you are managing.

• Leverage configuration management tools—Although effective configuration management procedures can be executed using clearly defined manual procedures—and a fair amount of discipline and a central control point—the process is much easier with configuration management tools. The tools enable you to control access to the repository, control the revision process (only one person can check out the work product for edit at a time), and provide an automatic audit trail.

• Define product configuration build/release process—On any project that deals with a product that is composed of multiple components, a process is needed that properly integrates the components into a final product. This is especially true for any product that represents a system. This process enables you to establish a baseline configuration.

• Define product/system release deployment process—Similar to the previous best practice, but this is focused on moving (promoting) project work product through the development life-cycle process. Specifically, this practice occurs when deploying a new work product into a test environment and the production environment. For many digital work products/systems, there are setup aspects that need to be manually configured and/or environment preparation tasks that must be performed by authorized system administrators. It is imperative that all these tasks and dependencies be clearly understood and communicated.

• Separation of duties between development and operations—Closely related to the previous best practice, this one is focused on the actual team members involved in the deployment process. Whenever possible, it is best to have a different set of people responsible for the deployment, setup, and management of IT services/resources into a production environment versus the development and testing of those services/resources. This separation forces all needed steps and changes to support the release deployment to be documented and communicated; it keeps the responsibility for management of the production environment with a team that is independent of the development groups; and it improves the integrity and security controls of the production environment.

• Develop configuration management plan—This is where you document all of the configuration management best practices you are going to utilize for your project. The configuration management plan enables you to communicate the procedures and rules that the project will follow and to gain agreement on the plan. We discuss some recommended sections for the configuration management plan in the next section.

• Leverage archive folders—A simple but powerful technique to help you manage (and not lose) project information is to always create an archive folder within a specific project directory to hold any previous versions, as illustrated in Figures 12.1 and 12.2. This is especially useful for digital work items that are not managed by a configuration management tool. This practice also has the added benefits of better organization and better visibility of the most current work items.

Configuration Management Plan

The Configuration Management Plan (CM Plan) is first defined during the project planning process and is part of the overall project plan. Like all planning documents, the level of detail included in the CM Plan should be consistent with the risk levels, compliance requirements, and composition of the project team. As a guide, Table 12.2 lists the minimum topics that should be covered in a CM Plan.

Common Challenges and Pitfalls

We’ve addressed the challenges you will have on your project if you do not have a CM Plan, but even with a CM Plan, there are still some remaining pitfalls that you need to be on the lookout for:

• Not following the plan—One of the first things to go when the realities of the project hit is execution of the CM Plan. There are two things you can do to help make sure the CM Plan is executed:

  • Use an independent auditor (such as a QA Lead) and include the CM activities as part of the quality review process.

  • Make sure to include the CM activities in the WBS and project schedule.

• Tool difficulties—As stated before, configuration management tools should be leveraged whenever possible, and in some cases, they are absolutely mandatory. That being said, the proper use of these tools is not automatic. If you are going to use a tool, you need to make sure the right team members are trained on how to properly use the tool, and you need to verify that the tool works correctly.

The map in Figure 12.3 summarizes the main points reviewed in this chapter.