About Us
Site Map
PMP® Certification
PM Tips & Tricks
PM Tools & Techniques
Contact Us



Project Rescue Tip #6

Rescuing projects requires the correction of the problems that de-railed the project in the first place and there are 2 main sources for information about those problems: evidence provided by project artifacts and anecdotal evidence. We’ve already dealt with accessing and interpreting evidence from project artifacts in Tip #3; this tip deals with gathering and interpreting evidence from the project team and stakeholders. Combining these tips should provide you with as complete a picture of the reasons for the project’s failure as it’s possible to get.

Interviewing will be constrained by the amount of time you have available to turn the project around, or to present a plan for turning it around. As I’ve mentioned in past tips, your stakeholders will be anxious for you to turn the project around in the least amount of time possible, the key word here being "possible”; don’t commit to presenting a plan before you’ve got the information you need to identify the problem areas and solutions to those problems. You’ve only got one opportunity to turn things around; if the first attempt fails you won’t get another. That said you must balance the need to gather and interpret information against the need for speed. There’s a reason you’re being hurried and the reason usually has to do with the organization losing money as you’re planning your rescue. The trick here is to know how much information you need and to get it as quickly as possible.

The need for speed may influence you to use brain storming sessions to gather information; avoid the temptation. The information you are gathering will be sensitive, likely to involve some degree of finger pointing, which will mean that a group setting is likely to discourage most folks from speaking freely. There are 2 exceptions to this rule: where the stakeholders who represent the business units that will use or market the products of the project are of equal stature a group setting may be appropriate and where the need for a quick turnaround is so urgent that it outweighs the sacrifice in information. I recommend holding a one-on-one session with the executive sponsor(s) in any case.

Let’s dispose of the brain storming approach first. Do not attempt to combine your stakeholders with the project team members; the disparity between their statuses will have an overwhelming inhibiting effect on the team and they won’t thank you for exposing them to this experience. Since you’re doing this in response to an expressed urgency it’s fair for you to request the brainstorming session take place on short notice, 2 or 3 days at most. Your purpose is to probe stakeholder insight into the reasons for project failure and use this insight to identify the things that must be fixed to turn the project around. Communicate this information to the stakeholders with their invitation to the session along with any information you think might be helpful to them. Telling them how the information will be used and how quickly a rescue plan must be crafted are examples of things that might help to stimulate thought.

Review the objectives of your brainstorming session before starting. It may be helpful to be specific about the quantity and quality of information you expect to gather. Metrics such as 5 problems, 4 suggestions for solutions may help to focus the group’s efforts. The session should follow the same rules as any other brainstorming session: no personal attacks, everyone must contribute, don’t interrupt, and etc. There is one advantage to using brainstorming to elicit information from stakeholders and that is that the group setting should leverage the sum of the knowledge of the group to improve ideas. This happens when a problem identified by one stakeholder is discussed by the group and refined to reflect the group’s knowledge; the same principle applies to suggestions for solutions or improvements. Use the same approach for a brainstorming session with the project team.

Individual interviews will take much longer to conduct so you’ll need to be selective with your choice of people to interview. You may not be able to interview each stakeholder and you certainly will not be able to interview each team member. Interview as many as possible, in the time available and don’t allow yourself to become a bottleneck. During this period your key objective is to gather information from project artifacts and interviews to craft your rescue plan. Work your schedule for examining project artifacts around the interviews; you have total control over your own time but not over the stakeholder’s or team member’s time. Do your artifact investigation off hours if that’s necessary to meet a tight timeline for completion of the interviews. Make sure you communicate the urgency of completing the interviews as soon as possible to those you chose to interview. Choose a completion date for interviewing and then schedule the interviews to fit within that deadline.

Choosing your interviewees carefully is another means of limiting the time interviews will take. Start by identifying all the candidates. There are 3 sources for this information: the executive sponsor(s), the Project Charter, and the RACI/RASCI chart. Identify all the stakeholders using these sources. You may or may not have the time to interview each of the stakeholders. If not, choose stakeholders that represent the business owners that will be the customers of the project’s deliverables. Choose the stakeholder who has the most interaction with the project where more than one stakeholder per business unit is identified. You can ask your counterpart where the project is being performed for an external customer and business stakeholders work in the customer’s organization. The customer project manager or vendor manager will be one stakeholder that must be interviewed in this situation. Rely on their input for the identification of others. You may even be performing the rescue as part of a joint effort between your organization and the customer. Tread very carefully here if this isn’t a joint effort. There may be information that should not be shared with the customer even though it is highly unlikely they are unaware of the problems. Check the contract governing the project before interviewing the customer and don’t share any information that is deemed confidential by the contract or the executive sponsor.

There are 3 sources of information you can use to identify the project team members: the MS Project file, the RACI/RASCI chart, and the time tracking tool used to log time if one exists. You only want to interview team members who are currently working on the project or those who have finished working on it. Team members who are scheduled to work in the future won’t be of use to you. The MS Project file or time tracking tool are helpful here because they tell you who is working on the project currently or has worked on it in the past. You are unlikely to have the time to interview all your team members unless the project is a small one so refining the list of current and past members will be necessary.

Most projects will require more than one member with a skill set. Software development projects will have more than one business analyst, systems analyst, programmer, and tester. Construction projects will have more than one plumber, electrician, stone mason and glazier. You shouldn’t need all the members with a given skill set to gather sufficient information from their area of the project so select the member with the most experience and/or the most exposure to the project. You may also be able to eliminate entire groups of team members if the work they are responsible for is going smoothly. Be careful though; even though the work is being completed on time and to quality standards set for it the workers responsible may be experiencing problems that they may not be comfortable overcoming. Team members from one group may also have insight into problems occurring in other areas of the project they are not directly involved with. Business analysts may have insights into problems that systems analysts or programmers are having converting specifications into designs for example.

Now that you have the list of team members you want to interview, schedule the interview. Keep in mind that the team members are continuing to work on the project, probably under trying circumstances, so be sensitive to their time needs. They should also be sensitive to the rescue need for a speedy conclusion to the information gathering so make sure that you communicate a deadline for concluding the interviews. Communicate group deadlines if you’ve arranged to hold interviews in any particular order. You may also want to quote the authority you’ve been given by the executive sponsor and/or executive steering committee to conduct the interviews to encourage cooperation. One way to approach scheduling the interviews is to make your calendar available to the interviewees and have them choose a date within the deadline you set. One advantage of this method is the encouragement it gives to interviewees to pick a dates and times before all the desirable slots are booked. You shouldn’t need more than 1 hour to conduct an interview and most interviews should be shorter. Don’t forget to allow yourself a buffer to debrief. You’ll want some time at the end of the interview to make notes before beginning the next interview.

Choose a place to conduct the interviews that is both neutral and private. Small meeting rooms are best for this purpose as they provide the needed privacy and are neutral ground. The need for neutrality stems from your desire to make the interviewee as comfortable as possible; comfort will tend to make the interviewee more forthcoming. Conducting the interviews in your office with the door shut may have the unwanted effective of reminding the interviewee of your degree of authority over them and cause them to filter out information they perceive may not be favourably received.

Your meeting invitation or notice should identify the reasons for the meeting, the meeting objectives, and any ground rules that you wish to establish. Some ground rule suggestions: no cell phones, iPhones, blackberries, or other external distractions, no character assassinations. Include such information as you deem will help your interviewee produce the information you’re looking for; that information includes problems they have knowledge of and suggestions for addressing the problems. Remember that some folks are comfortable speaking "off the cuff” while it makes others uncomfortable. You’ll get good results from the spontaneous thinkers no matter what information you provide them with before-hand but you will get inferior results from others if they don’t feel prepared.

Try to gauge your interviewee before beginning the interview. Spending a couple of minutes at the outset of the interview to talk about weather, sports, or other social related topics will tend to make people who are "being oriented” more comfortable while getting straight to the point and conserving time will make "doing oriented” people more comfortable. Take your queue from the interviewee; if they offer an observation on the weather, sports, or social activities spend a minute or two pursuing this conversation before launching into the interview, otherwise get right down to business.

Your questions should be open ended; of the "what do you see as _________?” variety as opposed to the "why do you think ________ has been happening on the project?” Open ended questions will tend to extract the maximum amount of information from your interviewee whereas closed questions will limit the flow. Remember that despite all your efforts to make your interviewees more comfortable you may find that they are reluctant to address certain subjects because of a perception that you may be unreceptive to the information. This will be especially true if these folks are strangers and they suspect a hidden agenda. Make it clear that the purpose of the interview is simply to gather as much information as possible along with any recommendations and terminations will not happen as a direct result of the interview. Now this brings up an ethical question. You may very well find it necessary to terminate members of the team based on the information you uncover during an interview however a termination should never be made without further investigation and a determination that there are no other viable options.

Keep in mind that a fear of termination may not be the only hidden agenda item at play here. You may be dealing with someone with a political axe to grind who will "dish the dirt” on another team member in order to influence you to remove them from the project. Divert conversation away from discussion of a specific team member to a description of events. Respond with a "How do you know that happened?” or "What was it you observed that led to that opinion?” if confronted by a rant about another team member’s short comings. Discourage personalizing information and encourage sticking to facts. Opinions are fine when discussing suggestions for a solution but will obscure the facts when trying to identify the root cause of a problem.

Don’t be afraid to extend the session beyond the time limit if you the original time is insufficient to gather all the information and suggestions your interviewee has to offer. You can take a few minutes out of your buffer to cover anything not addressed within the time limit, or if the interviewee has a more information to offer than the time limit plus buffer will cover you can schedule an additional meeting. Just make sure that the additional time is used for uncovering facts and suggestions for improvement and not personal agenda items.

You should bring some background information into these meetings with you which will help you interpret the information you gather from your interview. Use your buffer time to make notes on the meeting based on what was said strained through the filter of your background information. I find that making notes on the spot, or reviewing and updating them immediately after the interview, provides me with more meaningful information than if I try to recall the information days after the interview took place. Review the notes from all your interviews after the last one has been completed and combine descriptions of the same problem gathered from several interviews into one description. Review the suggestions to identify similarities and combine those that are different descriptions of the same solution. You are the arbiter of how the information will be used so use it with the information you gather from an examination of the project artifacts to identify the root causes of project failures and the best solutions for rescuing the project.