Project Issues

Issues are events that have occurred or situations that exist which will adversely affect the project outcome if not resolved. In a typical project life cycle, circumstances are going to change, misunderstandings occur, assumptions don’t hold, political agendas collide, problems arise, and risk events happen. These situations are categorized as project issues, and they all have the potential to adversely affect the project’s ability to accomplish its objectives.

To minimize the potential effect of these obstacles on our project objectives, we need to have a proactive plan for effectively managing project issues. Managing project issues is an example of proactive project management. Through solid planning, effective stakeholder management, and insightful risk management, we can reduce the number of issues our project will encounter, but we cannot eliminate them. The goal of project issue management is to detect issues as early as possible. The earlier an issue is identified, the greater the chance of resolving the issue before it can affect any of the project’s critical success factors.

The objective of project issue management is to identify, record, track, resolve, and communicate all issues that might adversely impact the project. To accomplish this objective, we need to review the associated principles. The principles of issue management fall into two main categories:
an administrative process and a project manager mindset.

• Administrative process principles: To properly manage project issues, there are a few  administrative fundamentals to adhere to:

1. Document the issues—We need to log the issues somewhere as they are identified.
2. Track until closure—Use the log to make sure issues remain visible until they are resolved.
3. Align with project needs—Ensure the overall process matches the communication and workflow needs of the project.
4. Cost-effective approach—Keep things in perspective. Don’t buy a BMW when a Chevrolet is all you need.

• Project manager mindset principles: More than anything, effective issue management is an attitude and an approach. The following terms describe the mindset principles that a project manager needs to have in this arena:

1. Ringmaster—As the project manager, you operate as the focal point for tackling project issues. You are the one who must get the right people involved at the right time to make sure issues are resolved. In addition, some issues require the input of several different parties to resolve. You need to facilitate this process.
2. Smiling bulldog—Your goal is to resolve issues as quickly as possible and to stay with them until they are resolved. Be persistent. This is the “bulldog” mentality. However, you need to do this with a smile. Leverage your interpersonal strengths to do this, while still building relationships.
3. Swivel-head—Just as with risks, you need to constantly be looking for trouble. That is, trouble for your project. Sometimes issues come disguised as questions or non-verbal communications. When in doubt, ask questions and verify. The effect of most issues can be mitigated if they are detected early and resolved quickly with the right buy-in.
4. Goaltender—Just as a good goaltender does not let anything get by him, a good project manager lets no issue go unnoticed or unresolved. In addition, the subtle intensity displayed by the project manager here helps to set expectations with the project team and signals to all stakeholders that they will be held accountable for getting issues resolved.
5. Disciplined—To be effective, you need a fair amount of discipline. You need the discipline to log the issues and follow the process. In the whirlwind of most project environments, it is easy to let this slip.

Features of Issue Management Systems

The actual details of the issue management system are not complicated, and in most situations they share many similarities with your change control system and risk tracking system. Although issue management systems vary in complexity and sophistication depending on your organization and the needs of your project, there are key features that all issue management systems should possess.

Clear process—Clearly define and communicate how issues are submitted, how they will be resolved, how and when outstanding issues will be reviewed, and what is needed to officially close an issue.

Escalation procedures—This is part of the overall issue resolution process, but not always thought about in advance. Define the types of issue that warrant escalation to higher levels of management. Generally, there is a single escalation process for a project that is leveraged for anything affecting the critical success factors (issues, changes, or risks).

Issue log—This is the mechanism used to document and track project issues. The most common mechanism is a spreadsheet, but there are limitations to this method. Other options include database systems and collaboration tools. There are pros and cons to each choice. The important thing is to use a tool that matches the needs of your project.

Issue Log Administrator—Someone needs to serve as the central control point for the Issue Log. Usually, this will be you, the project manager.

Issue Data Points—Although the specific mechanism used for the Issue Log and the exact  information needs vary across projects, there are a core set of data points that should be considered for any issue logged. The recommended data points are listed in the table shown below:

In the next post we shall look at the available tool options for your Issue Log and certain best practices that  help you avoid the common mistakes in this aspect of project control.

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.

The following table lists the minimum topics/ recommended Sections that should be covered in a CM
Plan:

Even with a CM Plan, there are still some remaining pitfalls that you need to be on the lookout for:

1. 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.

2. 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 to verify that the tool works correctly (not that this is ever an issue or anything).

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 control who has access to the work product, what changes can be made by each person, and that you can 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 and network access. In addition, this means protecting any contractually significant approvals or sign-offs.

Track—The ability 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 should be considered for your configuration management process:

1. 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.

2. 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.

3. 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.

4. 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.

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

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

7. 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 used of keywords. This can be especially helpful if the project repository directory structure is large or has multiple layers, and it can be a tremendous timesaver if it is “less than obvious” where a given work product would be found.

8. 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.

9. Establish baselines—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.

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

• Title page
• Revision history page
• Approval page
• Standard header and footer formats/data

11. Use a deliverable tracker—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.

12. Back it up—Make sure that your project repositories have proper backup procedures in place and that they are actually working.

13. 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.

14. 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.

15. 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.

16. 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.

17. 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. 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.

Managing Project Deliverables

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.