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. NoteDepending on the type of work products you have, and the type of configuration management tools that you are utilizing, you might have more than one project repository, such as one for all digital documents and another for software modules.
• 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. NoteSome configuration management tools and project collaboration tools automatically index all contents (think Google). In this case, the need for predefining keywords is greatly reduced, if not eliminated.
• 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. TipExecute a test of your backup recovery procedures to verify they are working correctly—before you actually need them.

TABLE 12.1 Deliverable Tracker Recommendations

• 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. NoteConfiguration management tools include document management tools, software configuration management tools, enterprise project management tools, enterprise (and web) content management tools, records management tools, and workflow/collaboration tools.
• 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. TipEnsure appropriate team members are properly educated and trained on the configuration management tools and procedures.Use archive folders to maintain access to previous versions and improve organization.
• 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. NoteTo be compliant with most digital system security standards, this separation of duties is now a requirement.
• 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.