Enhancing the Project Rescue Framework
We explained how to recognize a project in need of rescue and determine the actions required to rescue it. This section will focus on the relationships between the various activities (threads) and the deliverables the rescue needs to produce. The reason for doing this is our tendency to focus on the 'how' of doing the work instead of the 'what' we're trying to achieve. The 'how' focuses us on what activities to choose, which order to do them in, and who to assign to them. The 'what' focuses on producing the deliverables. Project Rescue: Avoiding a Project Management Disaster explains how to accomplish this with Threads and Deliverables.
ThreadsThreads relate activities across the entire project life cycle. There are 7 threads: Communication, Resources, Suppliers, Quality Assurance, Risk Management, Scope & requirements, and Planning. You can read more about these threads in the following pages.
Deliverables"Deliverables can be an area of much discussion on projects, and the discussion often focuses on the following types of questions: What is the appropriate format of the deliverables? What is the appropriate content? What is the optimal number of deliverables required to properly manage a project using a generic development methodology? How about for a project rescue?"
"The project rescue framework identifies a minimum set of deliverables that is required to support the rescue process. These deliverables provide the level of detail that is required to track and adjust to events that occur during a project rescue." Project Rescue: Avoiding a Project Management Disaster provides you with some standard templates as examples of what deliverables should look like. To access these you'll have to purchase the book and download them from the publisher's web site (directions for this are contained in the Preface to the book).
"Of course the deliverable formats shown in this chapter are not the only correct versions. Many other formats are just as effective. Some may be more effective in a given environment. When deciding on a consistent format for the set of deliverables for you organization, keep the following principles in mind:
- Ease of processing The deliverables must be easy to create and, more importantly, must be easy to modify. A project rescue initiative demands that the deliverables are frequently updated - perhaps several times in one day. Consequently, the deliverables should be designed so that they can be changed easily. In practice, this means avoiding fancy layouts and constructs until the end of the project cycle. For example, you want to minimize complex documents that contain embedded links to different software packages (such as spreadsheets embedded directly into word processing documents) and the use of extensive colors.
- Readability A deliverable that is clear crisp, and readable means that it is ready to be considered as a corporate standard. Instead of rearranging the contents of a deliverable to suit a previous notion of how it should appear, be objective and assess whether it is readily readable in the current format. Working to build a consensus on degrees of readability and clarity will consume more time than the benefits.
- Standardization Based on the two preceding criteria, standardize on a single format for all the deliverables used during the project rescue. Some or all of these may have already been established during the project before the rescue was invoked. The ones that satisfy these requirements can be adopted as standards. Empty templates and a working sample should be centrally located and shared to ensure that the standards are known to the extended team.
- Access The deliverables need to be centrally located on an intranet, extranet, and in paper files. Instructions for access also need to be distributed to the extended project team. Remember to mark each deliverable as 'confidential and proprietary' to protect the intellectual property. It may take some members some time to become familiar with the new formats/standards, but it will save a great deal of time later in the process if all the documentation fits neatly together.
- Content Deliverables need to be judged by the value of the content they provide. Focus on this when evaluating the effectiveness of a deliverable."
Key Threads"The importance of activities such as 'risk management' and 'communication' to project management efforts has been well documented for decades. What is often overlooked, however, is how these activities transition from one phase to another. A risk assessment that is completed in the first phase needs to be revisited in the other phases. Producing and storing it is not enough. This section explains the key threads that are required by managers to stay on top of a rescue initiative. Note that the project rescue was probably initiated due to a problem in one or more of these threads. The early part of the assessment phase needs to focus on trying to identify the sources of these problems."
Key Project Rescue Deliverables"This section identifies the key deliverables belonging to each of the four phases in the project rescue framework. The subsections describe the important information on each deliverable and any special items you should be looking for."
"These deliverables are inherited from the project that is being rescued, reviewed, updated, and transformed. They can also be created using any number of different techniques such as iterative development, parallel development, or agile technologies."
The above is an excerpt from a book written by Sanjiv Purba and
Joseph Zucchero, published by McGraw-Hill/Osborne, 2100 Powell Street,
10th Floor, Emeryville, California 94608 U.S.A. Sanjiv has over 20
years of experience managing large projects and many years engaged in
rescuing ailing projects.