Scope and time have decreased, costs have increased, and quality remains the same. The following illustration shows an example of the new project constraints and their proportions. In the previous example, the project end date was shortened. Although your own experience with project management techniques and your exposure to projects of similar size and scope to your current project will prove invaluable, you need to include the expertise of others as well. Each team member and stakeholder brings a unique view to the project, and their perspective on what can happen is exactly what you want to tap.
Who to Ask So, you ask, who do you ask? The following are most of the key folks you should consider including in your risk identification activity and the value they bring to this process: Project sponsor Other participants may not have the strategic vision the sponsor has, so this person is in a unique position to identify risks others may not know. Stakeholders Stakeholders understand the risks associated with their own business units and the business aspects of the project, which gives them a unique perspective. Technical experts These folks have specific knowledge related to the technical aspects of the project.
Information technology experts, engineers, researchers, construction specialists, policy makers, and business process experts are a few examples. Vendors Vendors likely have experience working on projects of a similar nature and have insight to risks that may occur in all stages of the project.
Involving others gives you a broader perspective of the answers to the what if…? Before you invite these folks to the identification party, start by reviewing your risk categories. Gathering Information Probably the biggest how-to of the risk identification process concerns gathering the information. The purpose is to derive accurate, reliable information regarding project risks that you can further analyze and prioritize.
Identifying and Documenting Risks You should know a few pointers before you get into the how-to techniques themselves. The goal here is to identify the risks—not discuss them, define plans, or figure out their impacts. Act quickly, and get the risks written down in list form. The best ideas usually occur early in the meetings but not always. One idea leads to another and another, which is one of the benefits of involving more than one person in the risk identification process. Develop an action plan before meeting with folks or calling them together so you can finish the process quickly and remain productive as possible during the meeting.
Understand the differences in these techniques and when to use them. Funny thing is—they sound a lot like constraints. Since constraints limit or dictate project team actions, it makes sense that risks may be lurking in these areas. Pose questions and guide the risk identification team to examine these four constraints when developing your risk list.
Keep in mind that these techniques are useful for any process where information is needed from several people such as gathering requirements, defining assumptions, identifying quality measures, and so on. I recommend you limit the number of participants in group meetings. Interviews The interviewing technique involves question-and-answer sessions with experts, stakeholders, managers, project team members, or others who can 47 48 Risk Management assist you with identifying risks.
Be prepared with questions and some documentation before starting the interview. Or, what would happen if the product was completed by the due date but was missing key features? This should help get their imaginations rolling. Interviewing is a technique you can apply to any project. Small, medium, and large projects will benefit from the expert opinions of others.
Brainstorming Brainstorming is a facilitated exchange of information. A group of stakeholders, project team members, and others are asked to meet and identify possible risk events. I also recommend you have someone else besides yourself recording the risks and ideas on a notepad or laptop. This way, the pressure to facilitate and record everything is shared instead of resting solely on your shoulders.
Check the room before the meeting, and make certain it is equipped with a whiteboard or a flip chart and fresh markers. Ask each of the participants to think about project risks before arriving. Coach them to think about scope, time, quality, and cost issues as well as risks that may concern their business unit or business processes that only they would know. Once everyone is in the room together, lay down the ground rules: All participants have equal say. Think outside the box.
This process facilitates leapfrog ideas, which is exactly what you want. Brainstorming is useful when project participants work at the same location or are able to easily meet at a central location. The drawback to brainstorming is coordinating all those schedules and finding a meeting time that works for everyone. In addition, domineering group members can tend to squash the more timid group members.
You may not get all the information in a group setting such as this because not everyone feels free to speak. The ground rules and the premise are the same, but the technique is slightly different.
Participants gather in a meeting room and are given a sticky pad of paper and markers or pens. The facilitator starts asking everyone to write the most significant risk they see on this project on the first slip of paper. The sticky notes are handed forward and posted on a whiteboard or flip 49 50 Risk Management chart. You could post them by category of risk or type of risk. The questions continue, and the notes are posted every round until everyone is out of ideas. All the rules of brainstorming apply here.
The main purpose is to get all the risks of the project fleshed out and written down. This process works well for participants who are located together geographically. It allows for the discovery of a great deal of information in a short amount of time and eliminates some of the bias in the process because the ideas are written instead of spoken. Delphi Technique The Delphi technique uses questionnaires aimed at participants who have project or subject matter expertise.
Questions should be posed in an open-ended format. You want the participant to generate information and knowledge without limiting their input. Now everyone who has participated in this process will get to see other comments, which may generate more ideas.
Identifying and Documenting Risks The Delphi technique is ideal for project participants who are not located together geographically or for those who find it difficult to set aside time for a meeting or an interview session. It eliminates bias in the process because participants are separated.
Status Meetings Status meetings are ideal settings for uncovering new risks and reviewing the list of risks developed during this process. You should consider setting aside a portion of each status meeting for risk review. This is the place to do the following: Discuss the impacts of those risk events that have occurred. Determine if new risk events are possible as a result of past risks or response plans put into action. With all these techniques, make certain you put the right group of people together in the room. The processes will only be as good as the knowledge and participation level of the group.
Brainstorming Good for group members who are located centrally. Domineering group members can sway the group or keep others from participating. Allows for a great amount of information gathering in a short amount of time. Not suitable for groups that are geographically separated. Eliminates bias in the process, as no opinions are shared until the end. Time consuming for the facilitator to develop the questionnaire and compile results. Status meeting Ideal time to discuss risks, as many experts are present. Diagramming Techniques Diagramming techniques are useful for showing the logical steps in a process or a program, such as a flowchart, or for diagramming cause and effect.
Ishikawa diagrams, for example, show the relationship between the effects of problems and their causes. These are also known as fishbone diagrams. Fishbone diagrams help you get at the root cause of problems or issues. Since your goal is to stay proactive, you want to identify risks before they become problems. The following illustration shows a fishbone diagram of a potential risk dealing with inadequate skills and training of key project team members. For example, what schedule issues could cause or create the inadequate skills or training risk event? One possible trigger is a critical path task that requires specialized skills.
Asking the same question of the cost category reveals that lack of funds would impact the availability of training for team members. Scope changes are another possible trigger as identified under the Scope category. Use some of the information-gathering techniques you learned earlier in this chapter for identifying risk triggers as well.
Identifying risks is half of the job—the other half is documenting them for easy reference throughout the project and beyond. And deliverables with a high probability of risk events occurring may need more time built into the schedule. You also want to provide a way for folks to report new risks as they think of them. First, gathering and sorting the risks in a logical order will allow for easy review as you progress through the project.
Status meetings are an example of where you could put this risk list into use. Instead of the new project team members having to start from ground zero, they can review the risks documented during this project and get a jump start on their risk identification activities.
You can devise whatever method works best for you to list and document the project risks. At a minimum, I recommend the risk list contain at least the following information: Identification or tracking number This is a unique identifier for the risk. I recommend using a tracking number no matter how many risks you have. Description This is a description of the risk with enough detail to determine the probability and impact.
Or if the description is too long, include the location or a link where team members can find the risk description. You could also add columns for risk category and risk type if you want to further classify the risks. Columns for life-cycle phases may also prove useful if you want reminders of where the risk events are likely to occur and during which phases the risk list should be revisited.
You can collect this information in spreadsheet format, in a database, or in a table in a word processing program. The project manager is usually the one responsible for maintaining the list and keeping it current, reporting on the status of the risks at status meetings, and closing out the risks. Submitting New Risks Since identifying risks is an ongoing process throughout the project, you should have a formalized process for team members and project participants to submit new risks.
All risks should be incorporated into the risk list and examined later in the process for probability and impact. The process for submitting new risks should be straightforward and easy for the person reporting the risks. Ideally, you should create a process that automatically updates the risk database when a new risk is submitted. Short of that, you could use the Risk Submission template on the Sybex website www.
The folks reporting risks should think about impacts on the following: Originators and Owners Risk originators, as the name implies, are the folks who tell you and the team about new risks. This can occur in status meetings, in the hallway, or via the risk submission form. Risk owners are responsible for tracking the risk, monitoring the project and other events for risk triggers, carrying out the risk response plan once the risk event occurs or is about to occur, and monitoring the effectiveness of the response plans.
This responsibility is shared among project participants, including the project manager. The last thing you want to do is scare project participants away from reporting new risks by assigning them as the owner of the risk. The reason for that is the person who reported the risk may not be the correct person to assign as the owner of the risk.
Risk owners monitor the project and other events for risk triggers and implement the risk response plan once the risk event occurs. For Identifying and Documenting Risks example, if a project participant who works at the front counter interfacing with customers all day reports a financial risk, someone from the accounting or finance team would likely make a better risk owner because they have the specific knowledge needed to address and monitor a financial risk.
This will create an open atmosphere and assure communication concerning risk events remains active and ongoing. Checklist The goal of this chapter was to develop a list of risks that you could easily review and build on throughout the remainder of the project. You followed along with me through several steps to reach that goal.
It should occur throughout the life of the project. Review project planning documents and prior projects that are similar in scope and complexity to the current project. Constraints restrict or dictate the actions of the project team and may have inherent risks associated with them.
Review assumptions for validity. Create risk categories, or use organization- or industry-defined categories. Determine the best method for identifying risks, and conduct process. Document risks with an ID number, category, risk name, and description number. Case Study Emily Lewis devised her risk list using the techniques she learned in this chapter. First, she and her team reviewed the goals of the project. The main goal is to purchase a new Customer Relationship Management CRM package that will perform at least the same functions as the current program performs. Second, they reviewed the critical success factors for this project.
Project Manager's Spotlight on Risk Management by Kim Heldman
The driving constraint on this project is time. Bill Olsen, the CIO, wants this project completed by the end of the fiscal year, which is just shy of 11 months away. Emily used brainstorming techniques and invited key project participants and stakeholders to the meeting, including representatives from customer care, representatives from information technology, a database Identifying and Documenting Risks analyst, someone from network operations, and the contractor working on the project.
Two key stakeholders were unable to attend the brainstorming session, so Emily interviewed them separately prior to the brainstorming session. It proved a good exercise because she was able to kick off the brainstorming session with the risks the two stakeholders identified. Emily compiled her risk list, and Table 2. Emily also assigned owners to most of the risks.
The others require more research on her part to find the appropriate person to assign as owner. She also intends to set aside time at every project status meeting to review this list. Information technology 5 Human resources Key personnel Subject matter expert on the existing CRM system leaves prior to design of the new system. I also discussed some of the common project risks that can occur on any project.
In keeping with the risk identification theme, this chapter will focus on risks that have more of an organizational or project management impact. These risks can be just as detrimental to your project as the specific risks identified in the previous chapter. Many times these risks are brewing just below the surface of your project. And you thought the president was the only one who is a figurehead.
By that I mean they have no authority to make project decisions, assign tasks, take corrective action, or perform any of the other necessary activities project managers normally perform. Support groups are popping up all over the United States to help project managers cope with this syndrome—check your local listings to find one near you.
They are as follows: Meetings held without the project manager present Vendors run amok Lack of project management guidelines what project management guidelines? The Security Access Project The big boss walks into your office. You know—construction and revamping the elevators and such. The executive team wants this project completed within the next 90 days. Let me know if you need anything, and keep me updated on status. After getting sign-off on the project documents, you go back to your office and find an e-mail waiting.
It appears that the big boss and the vendor have been meeting off-site every Thursday morning for coffee without including you. From the gist of the e-mail, you conclude that some important decisions have been made without you. She also wants to approve all project communication before you distribute it. All the names and important details have been changed to protect the innocent. Accountability and Authority I wish I knew who coined the phrase accountability without authority.
Accountability, in project management terms, concerns assuring that the project is completed to the satisfaction of the stakeholders, on time, and within budget. This means the project manager must assure all the project team members are working cooperatively toward completing the goals of the project and completing their tasks satisfactorily and on time. Think of accountability in this instance as a hierarchy, or tiered levels, of responsibility. The first tier concerns the overall success of the project—the project manager is solely responsible for this one.
The second level of accountability belongs to team members who are responsible for completing their respective tasks. For example, in the previous sidebar example, Melissa is responsible for the facilities aspect of the project. She will coordinate with the elevator contractors and the building maintenance crew to install the new system. Harry is responsible for integrating the software that runs and monitors the security system into the corporate network.
Each of these folks is accountable to the project manager for completing their tasks satisfactorily and on time. The accountability for this project looks like the following graphic. Authority means having the ability to make and enforce decisions and to administer consequences and rewards to team members for completing—or not completing—project tasks. Authority consists of several elements, including the following: You want to know up front what types of decisions you can make on your own without input and what the escalation process is. For example, the project manager usually makes project decisions of a day-to-day nature.
And I strongly recommend the project manager be given the authority to do so. Someone must be in charge of the everyday activities who is ready and willing to make decisions. Otherwise, every decision has to wait for the project manager to get with the project sponsor, who may have to consult with someone else, which can potentially cause serious delays. On page , he quotes Col. At a minimum, they should have significant influence on the final decision maker because an incorrect decision made without the benefit of understanding the project as a whole could impact that event, which impacts another, and so on, like dominoes throughout the project.
You should agree with the project sponsor on what types of decisions require their input or escalation. Perhaps you may not have direct authority to remove troublesome team members from the project, but you can recommend their removal. In any case, make certain you communicate with your project sponsor or manager regarding the level of authority you have on the project. Know your limits, and escalate decisions appropriately. Why Projects Fail—More Risks and How You Can Prevent Them Creating Accountability If you find yourself in a situation where you have accountability without authority, the first thing you should do is talk with your project sponsor.
Clearly outline what decisions you have the authority to make and when you should escalate. For example, if you have past experience working on projects with large budgets or projects that involved multiple departments and vendors, tell the sponsor about that experience so you can put them at ease. Successful past experiences helps them establish boundaries for the current project.
Project Manager's Spotlight on Risk Management
Project managers need some teeth behind their bark. Consequences are the bite in this scenario. The ability to reward or disapprove an action sends the message that you indeed have the authority to hold folks accountable. If they choose not to cooperate and are unconcerned about due dates or the quality of their work, you suddenly have a project in danger. Executive Champion The executive sponsor of the project is typically someone in upper management who has the authority to approve the project and dedicate company resources to completing it.
The project sponsor may also serve as the executive champion of the project. A champion rallies support from their peers in executive management and keeps them focused on the benefits of implementing the project. The champion is the visionary for the project, but the project manager shares this role.
The project sponsor assigns the Why Projects Fail—More Risks and How You Can Prevent Them project manager to the project and is the one who should communicate the level of authority the project manager has to all the project participants. While most project sponsors willingly delegate authority to the project manager, beware of the project sponsor who insists on being involved in every minute detail of the project. Micromanagers, at any level of the organization, rarely ever assign one ounce of authority to anyone else, project managers included.
I once reported to a micromanager who was so controlling I actually had to get permission before joining a project management users group during my own lunch hour! I could probably write a whole book on micromanager stories. Do a little reference checking of your own regarding your project sponsor.
And a large part of that game plan consists of communicating expectations with them at the beginning of the project. Keeper of the Risks What does all this have to do with project risk? As the project manager, you are the keeper of the risks. If your role has been undermined by an overly enthusiastic manager or sponsor, chances are they will ignore you when it comes to project risks as well.
There will be a time or two in your career where voting with your feet is your best option. Absentee Sponsor Speaking from personal experience, an absentee project sponsor historically ranks as one of the top reasons for project failure. An absentee project sponsor is a pretty obvious risk to spot.
Although those issues are worrisome in and of themselves, the problems this causes can seriously impact the project. The project manager is responsible for all the ins and outs of completing the goals of the project. But when the sponsor holds little interest in their own role on the project Since most of the time the project sponsor is a manager or executive in the organization, they think they have other tasks to do that are much more important than overseeing the project.
Although you are the expert, an absentee sponsor, as you saw in the previous section, is a serious risk to the project. Early in the project, along with discussing the level of authority, you should also talk to your sponsor about their role on the project and the expectations you have about their level of involvement. However, you have to do more than simply communicate. You have to convince. The art of influencing others is closely coupled with communication. Using a combination of your charming influencing skills along with a few well-placed facts should get you the results you want.
You can increase the retrieval of inventory records by more than a hundredfold. Imagine how well your department is going to perform once this project is implemented. You and I have worked together before, and I trust you implicitly. Go out, and make-go. But let me explain the value of your participation on this project. You know this project also helps out the accounting department, and their participation is needed in a later phase. Sponsor nods her head. Executives are always looking for ways to improve business processes, operate more efficiently, increase production, decrease errors, and so on.
Find out how your stakeholder can benefit by helping you, and then actively communicate those benefits. You should discuss the role of the sponsor in concrete terms. This will help you in future discussions with the project sponsor and when making recommendations to them regarding the action to take. For example, if time is the primary constraint and a risk occurs that has the potential to impact the project schedule, your recommendations on courses of action may include increasing the budget to bring on more resources , decreasing project scope to keep the schedule intact , or decreasing quality standards.
Regardless of the constraint, make certain whenever you approach the sponsor with a problem that you also have a recommended solution. When you present a problem to the sponsor, also present alternative courses of action and a recommended solution. Make certain you have the facts together, and check them beforehand. Last but not least, discuss the expectations you have of the sponsor throughout the project, and get a list of expectations they have of you. In keeping with the previous note, go into this with a few discussion points already in hand. Here are some PM expectations of the project sponsor: Set clear expectations Establish meaningful, concise project goals.
Publish a project charter that outlines these specifics. Communicate authority Establish and communicate authority levels of the project manager to all project parties. Clear the path of obstacles Remove roadblocks, assist the project manager in dealing with uncooperative vendors and stakeholders, and gain senior management buy-in of project goals. Secure resources Establish a project budget, and assure availability of qualified resources.
Work with the project manager to establish an escalation path for problems and issues. Resolve conflicts Quickly resolve issues brought to their attention by the project manager. Note that all conflicts should first be brought to the attention of the project manager. The project sponsor will agree—or make suggestions—to your proposed procedures. Here are some project sponsor expectations of a PM: Successful delivery of the project Satisfactorily meet the goals of the project on schedule and on budget. Effective use of authority Administer consequences appropriately, maintain a customer service focus, and escalate issues appropriately.
Problem-solving and conflict-resolution skills Maintain an effective problem-solving skill set, and escalate irresolvable issues or those issues with a significant impact to the project. Team building skills Establish and maintain a cooperative, motivated team. Keep the team focused on the goals of the project.
Liaison between sponsor and team Serve as the liaison between the project sponsor, stakeholders, management, and the project team. Impart the vision the project sponsor has for the project to the project team. Remain flexibile Maintain flexibility—go with the flow, as the saying goes. Understand how and when to pick your battles. When the Sponsor Leaves Sponsors come and sponsors go. But an active, engaged project sponsor who leaves the organization in the midst of the project can be as equally devastating to the project as a disengaged sponsor.
Will your project survive? Conversely, if the project was greatly supported with plenty of management backing, chances are the project will survive. It sounds fairly simple, but you and I both know lots of issues are at play here. So what does a project manager do? Keep the team focused. Communicate, communicate, and communicate some more. Meet with key stakeholders. In the meantime, hold on for the ride. Focus and pay attention to your project until that happens. Meanwhile, keep the team on track and focused on the project goals.
Stay the Course When a sponsor departs for greener pastures, your short-term action plan is to stay the course. Focus on meeting those deliverables and keeping your commitments.
Account Options
The last thing you want to do at this point is provide good reasons to the stakeholders to kill the project. Delay any significant project decisions if at all possible until the new sponsor is named. Keep the Team Focused Next, keep the team focused on the goals of the project. Your attitude, the inflection in your voice, changes in your behavior, and anything that gives them telltale signs regarding your thoughts on the project can lead to low morale and lots of unproductive time spent doing nothing but speculating. I recommend you even lean toward over communicating. Meet with Key Stakeholders Meet with other key stakeholders and your management team to determine the course of action.
Sometimes, it will be evident who the next sponsor will be. Wrap up the project professionally. Document lessons learned, archive project information you never know, it could be revived at a later date , and talk to your team members about their next assignments. Key Stakeholders Project sponsors are not the only ones who can play the part of a micromanager or do the disappearing act when it comes time for project participation.
Key stakeholders are also important to the success of your project and may engage in the same behaviors. During your discussion with the project sponsor, make certain to talk about the roles and responsibilities of the other key stakeholders. Use your influencing and communication skills with stakeholders at appropriate times during the course of the project. One more piece of prep work you can prepare prior to meeting with the sponsor is a roles and responsibility chart or matrix.
You want the sponsor to understand all the roles on the project so that when problems or issues arise, you have a foundation already laid for who does what. For example, decision making is the responsibility of the project manager and project sponsor. However, all other parties are responsible for making recommendations about those decisions.
Team members may or may not state a host of reasons for giving you less than their best on the project. For example, team members who are overloaded with responsibilities may need help prioritizing their tasks or need you to off-load some of those duties to others. Team members may call in sick more frequently than usual or exhibit changes in their personality. For example, team members who are usually jovial and easygoing snap at other team members without reason or become extraordinarily quiet or vocal.
A lack of trust in the project manager is another sticky problem. Then hold a meeting with the team as a whole, and ask them to put their cards on the table. When issues are brought to your attention, make certain you set straight any misunderstandings and correct the issues they pointed out that are within your control and ability to fix. Bad attitudes spread like the common cold, and your best course of action is prevention.
The following are some of the risks and risk triggers. Even just one or two of these items together can cause the project to take a nosedive. This is when people appear busy, even to the point of being harried, but nothing is getting done. There are three types of organizational structures.
Functional organizations are the most common form of structure in business. This is a traditional, hierarchical approach where reporting structures and types of work are clearly defined. For example, all accounting functions report to an accounting manager who reports to an executive manager. Employees have one supervisor. A clear chain of command exists. Multiple projects compete for limited resources. Project team members are loyal to their functional manager. The two biggest downsides of this type of organization are that the project manager has a minimal amount of authority and project team members tend to remain loyal to their functional manager.
I discussed earlier in this chapter how to address the authority problem. This approach will work, even in a functional organization, provided your sponsor backs you. The employee, however, knows their functional manager is the one who gives their performance review at the end of the year. Therefore, the priorities the functional manager has will almost always take precedence over the project tasks. The sponsor should work with their peers who are other stakeholders on the project to establish that you will be part of their review and how to coordinate the exchange.
A matrix organization is a hybrid organization. The twist in the matrix organization is that project managers also report to a program manager, who reports to an executive. The project managers have access to the resources in the functional areas accounting, marketing, information technology, and so on. During the course of the project, employees report to at least two managers—a project manager and their functional manager.
Project team is freed up from functional duties when working on the project. Employees may report to more than one project manager in addition to their functional manager if they are working on more than one project at a time. In other words, you could ask the sponsor to allow you to establish a special project team whose sole responsibility is working on the project until the project is completed. You make arrangements with the functional managers to return these employees to their departments at the conclusion of the project.
Projectized organizations are not as common as functional organizations. The structure of a projectized organization, as its name implies, is project focused. All duties and functions revolve around projects. Consulting firms are usually projectized in that project team members are assigned to a client who has contracted them for a specific project. Supporting functions report to the project or program manager.
Project managers have the ability to select resources. Loyalties are formed to the project, not a functional manager. Team members especially those with specialized skills may have idle time between project tasks. Lack of Processes Project management processes are the foundation for all successful projects. Communication, change management, scheduling, budgeting, and scope planning and management are a few of the other aspects of project planning. The Project Management Institute does an outstanding job of providing the framework for project management processes.
Clearly defined processes and procedures give your project team and stakeholders level ground from which to operate. For example, instead of wondering what to do when a risk trigger is present, they can use the process in place to inform the project manager of the event. By the time the director was brought up to speed, the project Why Projects Fail—More Risks and How You Can Prevent Them manager had spent weeks compiling information, meeting with the team members and the director, reviewing contracts, and reviewing original requirements, all to show that the project deliverables were indeed correct and satisfactorily completed.
In the end, this activity caused the overall project a three-month delay. Establishing project management guidelines and processes is essential for successful project communication. It provides a safety net for all team members. They know what to do and how to do it. They also know what to report and how to report it. Established processes along with a good dose of open communication will prevent the tendency to overthink.
Speaking of better decisions reminds me of one last point I should cover. Insufficient information does pose a risk to your project. But so does indecision. Of course, sometimes no decision is the right decision. When you find yourself not able or willing to make a decision, seek advice from your project sponsor and other key stakeholders if appropriate. In either case, my recommendation is that you document your assumptions and knowledge of the situation when you make your decision.
That way, when things change later and the decision has to be changed or modified, everyone involved will understand—and remember—the reason for the first decision because you documented it. I recommend you deal with these issues head on and resolve them as quickly as possible. The approach I use is simple and effective. First, speak with each of the parties individually and find out the core of the problem. Second, the next step is a meeting with all the parties. State the problem or issue as you understand it, and get the parties talking. Keep the meeting focused and on track.
Ask each of the parties to recommend solutions. Chances are one, if not both of them, have to go. This is why you need the authority to remove or recommend the removal of team members. Wrong People, Wrong Time If I were allowed to write only one sentence in this section it would be this: Available does not equal qualified. Henry may be available, for example, but Terri is the one with the knowledge and skill level needed to complete the tasks.
Think of it this way: If you can negotiate or work your project schedule around the availability of qualified resources, by all means do so. However, sometimes you may be forced to take a Henry over a Terri. In that case, try to get someone who has at least some required knowledge and skills, and be ready to provide them training to help bridge the gap.
Sending critical project team members to training takes time and money. You may need to adjust the project schedule and the budget to allow for the employee to get up to speed.
This could include vendors, meaning suppliers of goods or services, who supply the hardware or equipment needed to complete the project. Here are a few of the situations that can cause this: No escalation path is provided for the vendor to report issues. When the organization allows the vendor to take control of the project, strange things will go bump in the night.
As a result, they may make decisions that are contrary to company goals, business policies, and corporate culture. The vendor has the best interest of…you guessed it, the vendor at heart—not your organization. Think about it this way: Who knows the state of your personal checkbook better than you? Does the bank have a better feel for your checkbook than you do?
The bank wants to make money on your money, and you want to put your money to the best use possible. The same is true with vendors. Always appoint a project manager for the organization who will keep the best interest of the organization at heart when completing the work of the project.
Be certain you assimilate them into the project team as though they were employees. Conflicts could arise that drag out much longer than they would have if the team were united. You may also find that information is withheld and exchanged only out of necessity.
To reach a state of high performance, vendors and project staff should work together as one team. Just as the project team needs an escalation path to bring risks, risk triggers, and other issues to the attention of the project manager and other stakeholders if needed , the vendor also needs an escalation path. Escalation is a two-way street. The vendor may inform you of a risk trigger and expect a response or decision from you on how to handle that trigger.
The vendor needs a way to properly escalate to the project manager and to the management team or sponsor so that decisions are made in a timely manner and the communication lines remain open. Case Study Emily Lewis wants to make certain her level of authority is clearly established. While this project is larger and a little more complex than others she has experience with, Emily does have a successful track record and a crack project team.
Susan Gilbert, vice president of client services, is the project sponsor. That should save us some time. And I appreciate you allowing me to help choose the team members. Also, two vendors are involved. I believe it makes the most sense for all project team members to report to me for project tasks. Project team members should report to me for all their project tasks. A few of them work full time on the project, so they should report to me directly for the duration of their time on the project.
I will have input on their performance reviews as far as project tasks are concerned. Scope defines elements such as the goals, deliverables, and requirements of the project. Schedule risks are associated with elements such as incorrect estimates, unqualified personnel, and lack of resources, to name a few. In my opinion, the two most important elements of the project plan include scope and schedule.
Wait, I have to take that back. Budget is an important element as well. In my experience, scope and schedule tend to undergo more fluctuations and change during the project than the budget does. This means you should also have a solid change management plan in place so that you can formally address the changes scope and schedule risks may pose to the project. And that leads us to the topic of this chapter, which is watching for and reducing scope and schedule risks. Scope Risk A scope statement, prepared during the project planning iteration, documents the project goals, deliverables, and requirements of the project.
The scope statement, in theory, documents all the work of the project and is used as a baseline for future project decisions. They are the accomplishments you set out to achieve.
Goals should be realistic, should be measurable, and should have a time element. They should also include criteria such as cost and quality measures. Deliverables Deliverables are an output that must be produced to bring the project to completion. Deliverables are usually tangible and can be measured or easily proved. Requirements Requirements are the specifications of the deliverable. They describe the characteristics of the deliverable and may include elements such as dimension, ease of use, color, ingredients, and so on.
The project plan is the step-by-step approach that details how the goals of the project will be accomplished. The goal of the party is to bring good friends together, learn new facts about wine, and teach them a few basics about the art of wine tasting. Some of the deliverables of this project include the following: Deliverables are relatively easy to spot. But requirements are a little tougher to define and thus pose more potential for risk. All wines must be from the same vintage year.
Now multiply this scenario times two or four or six friends. You can see that when you have a multitude of stakeholders involved, reaching consensus on requirements can be difficult. But not reaching consensus can be the death of your project. You must spend sufficient time defining the requirements of the project and getting as many stakeholders as feasible to participate in this exercise. And of course it goes without saying, you want to document the requirements so that everyone involved on the project knows what they are. This deliverable standing alone could be misconstrued.
Maybe this stakeholder happens to be a white wine lover. When they see the deliverable listed without the requirements, they automatically jump to conclusions thinking that the wine served will be white. A disconnect exists between this stakeholder and the rest of the project team. You all know you meant red wine; this stakeholder assumes you meant white.
A detailed list of requirements that are linked to their deliverables gives you a much better ability to manage change. As stated earlier, the scope statement becomes the baseline for future project decisions. If changes are needed, they can easily be weighed against the original requirements to determine their need and impact. Some other advantages of well-documented requirements include better estimates and a better ability to monitor the work and status of the project. As requirements are met and completed, deliverables are completed because requirements are the building blocks of deliverables.
Both of these advantages—better estimates and closely monitored project status—work well to keep scheduling risks in check. And you want all the advantages you can get because advantages help keep risks at bay. Measuring Requirements Requirements, whenever possible, should be measurable. The same is true for deliverables. For example, you can prove that the wine for your party is red by looking at it, smelling it, and tasting it. Measurable or provable criteria provide a way to determine successful completion or fulfillment of the requirement and ultimately the deliverable.
It also provides a way to determine if risk events are likely to occur. Vague, unclear requirements are a sure guarantee of risks, including some like these: Remember our friend, Ned, the photojournalist? One of the deliverables for his photo-shoot project is photos of Paris imagine that. To take the photos, he has to take his camera equipment with him.
Therefore, one of the requirements for the photo shoot is transporting the camera equipment to Paris. So how about this: This requirement is easily measurable and verifiable. If the project plan is properly executed, they have time to order the cases, test them, and verify that everything fits prior to leaving for the trip. This may seem a rather obvious example, but what if one of the stakeholders on this project knows nothing at all about camera equipment?
Bear with me on this one—maybe this stakeholder has never seen a camera. The answer to that requires documenting assumptions and making certain requirements are as well defined as possible. Assumptions are events or actions believed to be true.
What is Kobo Super Points?
Again, the camera equipment scenario is an extremely obvious example, but carry this out a few steps and you can see how one or two technical Preventing Scope and Schedule Risks experts on a project may assume others know what they know and not take the time to define requirements correctly. Stakeholders can make this mistake and so can team members and project managers. Take the time to define your requirements and document your assumptions about the requirements. Critical Success Factors Critical success factors are those requirements or deliverables that must be completed and completed satisfactorily to consider the project a success.
Ned buying special cases for the camera equipment may not be a critical success factor for the project, but having up-to-date passports certainly is. Obtaining Agreement Obtaining agreement on the deliverables and requirements of the project is paramount to obtaining cooperation and participation from the stakeholders. They may openly disagree with the goals of the project, or they may go along to get along while privately seething back in their offices.
The stakeholders who tell you straight up about their feelings on the project are the easiest to work with. The ones seething behind your back are another story. Getting the right information in their hands will help avert this problem before it begins. Another approach you can try is to negotiate for one of their senior staff members to fill their place on your project.
If they truly are too involved in their own project, perhaps they could assign a senior staff member or someone else to your project. Uncertainty In the previous chapter, I talked about inadequate information. The reality is many project decisions are made in uncertainty. Time, cost, resources, and any number of important pieces of information are missing.
Do Stakeholders Go to Kindergarten? Taking on another project is the last thing I planned to do. Robbins rubs his chin and looks directly at you. Well, here I am. If you have decisions to make, my answer is no. Take him out for a cup of coffee or lunch. Explain that you understand his frustrations and challenges. Offer to help him with Project Run-About in exchange for a higher commitment level to your project. Make sure you squeeze in some of the benefits his department will see as a result of this project to help influence a more cooperative mood. Will your insurance cover hospitalization?
Will you have insurance? Will the dementia subside when you find a new job? Yes, all the answers to these questions are uncertain. What if your position is targeted? Each of these possibilities helps eliminate a tiny bit of uncertainty. Preventing Scope Creep Scope creep, that slimy little green creature that eats your tomato plants…oh sorry, there are no tomatoes in this story. But tomato hornworms do remind of me scope creep, now that I think about it.
Just like the tomato hornworm, scope creep slowly inches along the length of the project, not really drawing too much attention to itself until the next thing you know, a lot of damage is done. Hornworms deposit tiny black squares of waste on the leaves of the plant. They chew away at the leaves and leave ragged edges, rather than holes, as they progress.
Otherwise, all of sudden one day the leaves and the tender part of stems are gone! In my experience, scope creep on projects happens the same way. Slowly over time so many changes are made that the project no longer resembles the original goals and plans. I just had to do say that. Your first, and best, proactive response to scope creep is communication. Spending the time to document requirements will save you many headaches later when the work of the project begins and the change requests start flying. I urge you to refrain from this game at all costs. This practice renders almost everyone incapable of making a good decision.
I read this book for my risk management class. I recommend this book for any project manager who wants to revisit how they identify and manage risk. Its a small, yet powerful book. Dec 10, Shannon rated it it was ok. Keyuri Shah rated it really liked it Jul 07, Rima Massabni rated it liked it Sep 26, Jenny John rated it it was amazing Nov 19, Supreet Sandhu rated it really liked it Dec 10, David rated it really liked it May 18, Valerie Snow rated it really liked it Aug 04, Giorgi Burduli rated it liked it Jan 30, Sadiq rated it really liked it Jun 06, Mohammed Al Sadiq rated it it was ok Dec 27, Bruce Falcon rated it liked it Jul 01, John rated it really liked it Feb 15, Cheri Walsh rated it really liked it Apr 09, Coolgirl rated it it was amazing Jun 09, Cheri Walsh rated it it was amazing Apr 09, Mahfud Achyar rated it liked it Apr 01, Krainfo rated it it was amazing May 07, Fajar rated it it was ok Feb 25, Kofakis rated it liked it May 18, Augustine rated it did not like it Oct 08, Kevin Cooper rated it it was amazing Jan 07, Deneen Angela Snyder rated it it was amazing Apr 03, Rocky added it Apr 07, Diana L added it Aug 25, Abdullah Aloseimi marked it as to-read Feb 17, Pavel marked it as to-read Sep 08, Raluca added it Mar 21, Osama Wahab marked it as to-read Apr 07, Danie Matthys marked it as to-read Jul 06, Christina Mtega added it Jul 08, Homan marked it as to-read Aug 19, Darpan marked it as to-read Aug 21, Dr-mohannad El-zayyat added it Sep 13, Ren marked it as to-read Sep 27, Ravinder marked it as to-read Oct 17, Omar Hatem added it Nov 01, Ahmed Elkharat marked it as to-read Nov 29, Arunas Gv marked it as to-read Dec 02, Safwan marked it as to-read Dec 04, Walid marked it as to-read Jan 22, Ahmed Ismail marked it as to-read Jan 25, Javaid marked it as to-read Apr 18, Faith marked it as to-read May 12, Bobica Tatic added it May 16, Goldenwalden marked it as to-read Jul 15, Laura marked it as to-read Aug 14,