|
Basic Rescue Management Toolkit“Certain facts, objectives, and information must be immediately available to the rescue manager at all times. Just as importantly, it must also be clear to the entire extended project team that this is the case – otherwise team members will lose faith in the turnaround prospects. These specific tools are: · One page dashboard · Detailed status report · Issue log · Test bed · Business requirements summary These tools are discussed in the sections below. This section also provides recommendations on how long it is likely to take to update the deliverables for the next session.” “The management process during a project rescue is operating at an intense and rapid pace. This requires the rescue manager to keep the toolkit up-to-date at all times and to present it to different combinations of the project team on a daily basis. There will be times when some of these specific tools will need to be updated and shared several times a day to keep the forward momentum. This is in addition to their electronic availability over an intranet or Web site. Availability is simply not enough because these tools will not generate the necessary personal attention to detail unless there are physical walkthroughs by the rescue manager with individual team members.” Dashboard
“It might appear that everyone on the extended project team is involved in the details. This just is not the case for some of the key members, especially the business stakeholders and sponsors. They may be emotionally involved and heavily invested in the project. They may be thinking about it all the time, worried about it constantly, but this is not the same as understanding the intricate details. This group needs a simple way to understand status and whether they need to take an action.” “Furthermore, even the team members who are heavily involved in the details of the project can benefit from a visual tool that highlights the important things they need to know, what danger the project is in, and when an action needs to be taken.” “This should take about 30 to 60 minutes to update in every cycle. Much more time than this implies that the best structure has not been selected for the dashboard.” “The dashboard and the detailed status reports must show progress relative to the project plan. Without contrasting them to a time-phased project plan, the report does not tell how close you are to the finish line. Earned Value Management (EVM), Cost Performance Index (CPI) and Schedule Performance Index (SPI) are useful measurements to include here.”Detailed Status Report“As mentioned previously, the detailed status report needs to identify all the work that has been done in the reporting period and the work to be done in the next reporting period. It should also capture the essence of conversations and decisions that are being made throughout the day. These types of decisions are often forgotten, misinterpreted, or contradictory. Knowing that they are being recorded keeps everyone in the project on their toes.” “Status reports get a substantial amount of bad press – some believe that they waste time that could be spent doing actual work. Do not give in to this propaganda. It certainly takes work to keep detailed status reports, but they are always useful and relevant on projects – especially ones that are complex enough to require a project rescue.” “A good detailed status report can take one to two hours to update in every cycle. You may not want to update it for every meeting. The important thing is to have a schedule and stick to it. During tense times on the project, this could be done every day or every other day, depending on how much new information needs to be shared.”Project Rescue Plan“The project rescue plan should be used for tracking progress and should be appended to the status report to support the regular walkthrough sessions. Whatever management tool you have selected should allow you to move the percent complete forward at the task level. This gives the rescue manager a good reason to call every deliverable or task owner every day, or several times a day, to get an accurate update for this figure.” “A lack of progress requires the rescue manager to investigate further and to bring the task back on track. In a project rescue, time is not available to allow the task to be corrected at the mercy of team members. A late task for a second reporting period requires emergency action.” “Special attention needs to be paid to the dates applicable to completion of milestones and deliverables. These are the major warning flags that should terrify the rescue manager and require deep intervention if they are passed.” “The rescue manager needs to make it clear to everyone on the project team that there is going to be an extraordinary emphasis on hands-on involvement during this period. You are going to be in everyone’s face to ask the really difficult questions to bring and keep the project on track. No offense or misunderstanding is intended in the degree of micro-management that they will be subjected to when the planned dates are in jeopardy.””It takes about 30 to 60 minutes to update the project rescue plan for each reporting period.” Issue Log“The issue log should also be appended to the project plan. It should be used to record every single item that is raised by anyone on the project team so that nothing is forgotten. Each item then needs to go through a process that allocates next steps – which may or may not impact the project plan. Changes need to go through an approval and change management process that absolutely must involve the executive sponsor who may decide to put all of these on hold until the existing rescue initiative is completed.” “At first, a lot of issues will be identified when the process starts. This tends to taper off as time goes by. Note that the issue log is not the same as the bug log that is produced during the testing processes, and which is discussed later in the chapter.” “It should take 15 to 30 minutes to update the issue log for each reporting period. Rescue managers who are collating issues from other team members should also try and solicit them through e-mail to reduce misunderstandings and repetition.”Test Bed“A test bed is probably one of the most important tools in a project rescue and the ultimate fact checker. Team members can sometimes present their personal preferences and their wishful thinking about progress as facts. Because most team members want to see progress, they are likely to give the benefit of the doubt and see more progress than there actually is. The test bed becomes the reality check.” “A process needs to be defined to integrate everything that is being reporteed as completed into the test bed and to run some routine tests while construction is still being done. The extra effort to integrate deliverables as they are being built and test them at a high level in the test bed is mandatory value-added investment.” “This is the only confirmation that a project rescue manager can have confidence in. It also sets a standard of quality and delivery so that the project team knows that it needs to deliver today, right now, and to receive feedback, rather than having a false sense of security and the crutch of waiting until a later phase.” “The test bed does not replace the other testing phases. Test results should be documented on an ongoing basis, but they do not replace the results of the normal unit, functional, and acceptance testing.” “A bug list, similar to the issue log, but one that can remain online for the most part, needs to be maintained for the results of the testing. It also needs to be examined one-on-one with the leaders of the group owning the bugs that are being reported. There are some open source products, or low cost products, available over the Internet to maintain bug and issue lists.” “A test bed that can be quickly refreshed is an invaluable tool. During a project rescue, anything that can reduce delays, waiting time, and other changes should be instituted immediately.”Business Requirements Summary“Given the continuing discussions with different stakeholders, and ongoing compromises that will need to be made to keep the project on track, it is a good idea to maintain a clean set of business requirements and keep them readily accessible. When changes are made, updated versions of this document should be sent directly to the stakeholders, as oppossed to being posted on a board somewhere that they may not visit anyway.” “The format of the business requirements document should be kept simple. English constructs are fine. Things such as changes to the budget can also be tracked in this document.” “Once built, th is document requires a relatively modest amount of time to maintain. It needs to be changed only when the business requirements are renegotiated. For budgeting purposes, assume about 90 minutes a week or 18 minutes a day.” “One way to implement a requirements management process is through the use of a requirements traceability matrix that shows each requirement as a row. Some information to include as attributes in the matrix are date-entered, requesting party, schedule release phase, and ultimately the physical implementation module. The matrix is supported by the source documents that can be hyperlinked to the appropriate requirement log.”Taken Together“The recommended time to maintain the project rescue management toolkit for regular meetings is in the range of 105 minutes (just under two hours) to 210 minutes (just over three hours). This is a substantial amount of time, but certainly doable. It also does not include the modest time to maintain the business requirements document.” “Coupled with about one or two hours to walk through the tools with the appropriate team members, this time commitment is still manageable. The average workdays during project rescues, which are significantly longer than this sum, still leave the rescue manager with enough cycles to accommodate a lot of other work.” |
 |
|
