Author: Praveen Malik
Praveen Malik, PMP, has two-plus decades of experience as a project management instructor and consultant. He regularly conducts project management workshops in India and abroad and shares his project management thinking in his blog, PM by PM.
Can Project Duration Estimation be done without Assumptions?
One of the most frequently asked questions when someone is about to start a new task is likely, “how much time will it take?” Time is limited. Our lives are limited, and unfortunately, we just cannot wish away time limitations. That is why duration estimation is one of the most important aspects of project management. Sometimes, the above question is not directly asked; however someone still imposes a deadline. Your client or manager might direct you to finish a given task by a certain date. Now, even if you have to move mountains, you will try to complete the task in the designated timeframe. In most real life scenarios, clients and mangers are reasonable, giving us some freedom to determine duration estimates for doing our tasks, but this can create other problems. Let’s take a look at one such real life scenario. The Estimation Problem Imagine your company has been in discussion with a prospective client. You’ve provided a proposal for a new project and are at the stage of hashing out the finer details. You might hear from the client that the estimates look high. You might explain why you believe the estimates are reasonable based on underlying assumptions. But then, the whole discussion may veer towards the topic of project assumptions. Your client wants to know why you are making assumptions and why you can’t provide exact estimates. Hmmm…. Can there be “exact estimates”? According to Merriam Webster, the meaning of estimate is “to judge tentatively or approximately…” or “to determine roughly…” “Exact estimates” sounds to me like an oxymoron. Nonetheless, let’s discuss it further. Exact Estimates Humoring our client for a moment, let’s assume that exact estimates are possible and that we can determine exact duration before starting a task. We want to know how long it will take to make a trip from New York to Washington DC by bus. We start by talking to a Greyhound bus driver. Our hypothetical conversation might go on like this: Me: Sir, how much time will it take to go from New York to Washington DC? Driver: It will take 4 hours and 50 minutes. Me: How can you be so sure? Driver: Hey! Are you doubting my ability? I have been driving between New York and Washington DC for donkey years. I am an expert driver. Me: Ah! OK. Is that the exact duration? Driver: Yep. More or less. Give or take 10 minutes. Me: Why can’t you give me an exact figure? Driver: Well, it depends on a lot of factors like traffic, weather, time of the day, etc. Me: Can you confirm that if I take your bus, I will be able to reach Washington DC in 5 hours or less. Driver: Most likely, yes. Me: Why are you saying most likely? Driver: Like I said, the journey time depends on a lot of factors. On most days the journey will take less than 5 hours, but on some days you might need a few more minutes. Me: So, 5 hours is just an estimate? Driver: If you say so. Me: Did you make any assumptions to arrive at this estimate? Driver: Like I said, I am an expert driver. No assumptions here. You can see the circular reasoning of exact estimates, can you not? The driver might say he is not making any assumptions. However, he is assuming that the journey will be done using his bus (not any bus, but his bus), that he will start at a certain time of day, that he will make one rest stop on the way, that the traffic conditions will be normal, and that there would be no events like a breakdown, etc. The driver’s estimation might be very good, but it is not exact. Accurate Estimates You might be thinking now that there are better methods for estimating the time of such a journey. There are. Let’s take a look at a more scientific method. We could use a popular mapping tool to find the duration estimate. Just open your favorite app and enter the journey details. Viola! It will immediately show you a duration estimate. The mapping app will take mode of transport, route, current traffic, and current weather into consideration before giving you an estimate. Let’s say it shows 3 hours and 50 minutes. Is that an exact estimate? Hardly. You can never be sure that the journey will take exactly 3 hours and 50 minutes. It is; however, a more accurate estimate. The traffic conditions can change while you are driving. You may feel tried and drowsy while driving. You may want to drive slower or faster than the app’s speed estimate. You may be forced to take a break. What if your car breaks down? Even after using modern technology, you still cannot determine an exact estimate. Your estimate will still be based on a host of assumptions. These assumptions are called “basis of estimate.” The exact duration is determined only after a task is complete. How to Find Assumptions Let us revisit the project example that I mentioned at the beginning of this article. The client wants to exploit the power of the search engines and social media to increase its ecommerce sales. Your company has already given task estimates to the prospective client for this digital marketing project, but the client has not yet agreed to them. You may have started with the scope of the project and listed the factors that could influence the estimation. Following is a partial list of some general factors that would be considered when sizing the project and doing the estimation: Periodic communication with the client Start of engagement and initial hand-holding Total duration of the engagement Training of team members on the client’s ecommerce platform Design and aesthetics of client’s website and mobile app Proposed contractual terms and conditions This is not a complete list, but when analyzing these, one would have come up with a number of assumptions. The bottom line is that the estimates outlined in a proposal would be heavily influenced by these assumptions. You, too, can list project assumptions in a similar manner. Start by understanding the scope. Then, list factors that can impact the duration, and you’ve made your list of assumptions. You should reduce the number of assumptions as much as possible. The higher the number of assumptions, the greater the risk to the project. This can be done by defining the project requirements in detail. You can reduce the number of assumptions, but you can never eliminate them. Of course, extra time is required to define requirements in greater detail. Even if you define project requirements in minute detail, there will always be some assumptions. You will need to find a balance between the time you are willing to spend on the requirements and risk that you are willing to take because of the number of assumptions. Take care of the assumptions and reduce the business risk by adding appropriate buffers to your estimation. Project Tasks and Assumptions The journey from New York to Washington DC was an example of an operational task. Such tasks have very few unknowns. An estimate for such tasks can be very accurate, but it will still not be exact. On the other hand, most project tasks have a lot of unknowns. The number of project task assumptions far exceed that of an operational task. It is extremely difficult to find an accurate estimate for such tasks, let alone an exact estimate. Conclusion Bottom line? Task estimation cannot be done without making assumptions. The number of assumptions can be reduced if the requirements are clear and there are only a few unknowns. The accuracy of estimation depends on the number and nature of assumptions. What is your take on assumptions? Have you estimated anything without making any assumptions? If yes, how? Have you been forced to provide best case estimates without considering the assumptions? What happened as that project played out? I would love to hear your comments below.
Why Most Project Managers Fail to Differentiate Between Risks and Issues
Jason’s face was totally blank and his eyes were still. He looked completely disinterested in the proceedings. Jason (name changed) is a senior project manager with a small IT services company based in Canada. Jason was a well-respected figure in his company. His subordinates loved him, and his seniors had a very high regard for him. He had a reputation for successfully delivering his projects. I had often wondered if Jason’s another name was “Problem Solver.” He loved to take on projects that were on the brink of disaster. And, almost always, he single handedly turned them around and delivered them. I was hired by Jason’s company as a consultant to setup their PMO. Jason and I were participating in a weekly PMO meeting when I observed an expression on his face indicative of his losing his patience. From past experience, I knew he never liked these type of meetings. On this day in particular, I had a funny feeling that Jason was ready to explode. I asked, “Jason, what is the most critical risk in your project?” Even before I asked the question, I knew it may have been the right question, but that I’d asked it to the wrong person. Or maybe, it was the wrong question to ask to the right person. Regardless, since I was chairing the meeting, I had to ask. Jason seldom differentiated between risk and issues (aka problems), so his answer was, “One of the senior team members has left the organization.” “But Jason,” I responded, “that is not a risk. It is an issue.” Jason’s reply was “Risk. Issue. You call it what you like, but it has to be solved.” Now, most of us understand what is a risk and issue, but very few people use these terms in the correct context. Let me throw some light on the issue (no pun intended). Project Risk vs. Issue The PMBOK Guide tells us that a risk is an uncertain event or condition that, if it occurs, has a positive or negative effect on one or more project objectives, whereas an issue is a current condition or situation that may have an impact on the project objectives. It is clear from the definitions provided to us from The PMBOK Guide that an issue is current, whereas a risk may occur in the future. Since an issue has already occurred, it should be tackled and resolved. However, a risk may or may not be resolved based on many factors like probability, urgency, and severity. You can look also at these PMI (https://www.pmi.org/learning/library/risks-vs-issues-project-failure-2328) and Simplicable (https://simplicable.com/new/risk-vs-issue) articles that succinctly explain the difference between these terms. Let’s take a look at the Jason’s statement again: “One of the senior team members has left the organization.” Is it an issue? Obviously, yes. The event has already happened. Let’s consider if Jason had made another statement: “One of the senior team members is likely to resign from the job.” This would be a risk. The event is likely to occur in future, but has no happened so far. Both risk and issue have an impact on the project. This impact can be estimated. Issues and risks are resolved (managed) in order to reduce this impact. Since issues are current, they should be resolved immediately. On the other hand, the resolution of a risk can be postponed. How Are Risks and Issues Handled in the Corporate World? Do you think the resolution of a risk or an issue ends up providing “bigger bang for the buck”? Consider this. A project is on fire because of a severe issue. The project manager, with all his skills and experience, resolves the issue and douses the fire. Will senior management appreciate the effort of the project manager? Of course. The project manager will be appreciated, even if he himself (or his team) was responsible for causing the issue in the first place. Consider the alternative. There is risk that is likely to cause an issue in a month or so. The project manager highlights and escalates it to the senior management. He asks for more time and money to plan for and resolve the risk. What will happen? Most likely project manager’s request will be denied. Sponsors, customers, and senior managers don’t like to tackle risks proactively. They categorically tell the project manager to concentrate on “Issues at hand.” They say that we can take care of the risks later. Why Do Most Project Managers Ignore the Difference Between Risk and Issue? Let us take a look at two hypothetical projects (X and Y). Let’s assume that both the projects are similar in size (effort and cost) and land in the middle on the basis of complexity. Project X The first project was assigned to project manager, Alpha. He is a proactive project manager. Alpha plans the project carefully. He meticulously understand the requirements, defines the scope, creates WBS, and lists the tasks. He estimates the duration and cost of each task before assigning it to an appropriately skilled resource. Alpha also prepares a proper risk management plan and risk register. He proactively resolves the risks and regularly monitors the health of the project. In the end, the project is completed successfully within the allotted time and budget. During the course of the project, Alpha did not report any major issues. Since the project ran smoothly, senior managers presumed that the project was really simple. Project Y The second project was assigned to project manager, Beta. He is an action oriented person, always full of energy and passion. Beta’s motto is “doing is more important than planning.” He believes that execution is paramount, and planning is not as important. Beta creates a sketchy plan and pre-empts the project execution. He does not bother to consider a risk management plan or risk register. To his credit, he regularly monitors how the project is proceeding. Due to lack of planning, the project repeatedly encounters a lot of issues. Beta reacts to the issues and manages them as they come. The team must expend extra effort to overcome these issues that could have been avoided. In the end, the project is completed successfully albeit a bit late and over-budget. During the course of this project, Beta makes a lot of noise about the issues. Everyone in the company is aware of what’s coming up. Senior managers think that the project was extremely difficult, but that Beta overcame the odds through persistence and hard work. They believe that the project was really complex, and that Beta did an excellent job. Which project manager do you think would be rewarded at the year-end appraisal? Conclusion The truth of corporate life is that execution is given more importance over planning. Risk identification, analysis, and resolution are an important part of planning, but isn’t given due importance in the corporate world. Instead, no one wants to spend time or money on probable future problems (aka risks). Senior managers reward project managers who overcome the issues, even if they came about because of the project manager’s goof-ups. Somehow, meticulous planning and proactive risk management goes unrecognized. The project manager in me does not support the current situation. Even though I know Jason’s approach to project management is wrong, I can understand what he is doing. Whenever I take up project consultancy assignments, I always take note of the project risks before doing anything else. During my training sessions, I tell my students to identify, analyze, and resolve risks proactively. What are your thoughts about the current corporate world scenario? Who do you think follows the right approach for managing projects? Alpha or Beta? And, how do you deal with risks and issues in your job? I welcome your comments below.
Why You Should Add Microsoft Project Visual Reports to Your PM Toolkit
Do you understand how to use Visual Reports in Microsoft Project? In my experience, seldom do project managers use any kind of Project reports — let alone the visual ones — even when they understand how to. To help PMs cross this chasm, I’m going to provide a quick and painless introduction to Visual Reports that goes a bit beyond the basics. Most books on Microsoft Project cover scheduling and tracking inside out with, perhaps, the odd chapter on reporting. Does this mean that reporting isn’t important? Hardly. It only means that reporting features are easy to understand, so there’s not much to say. Yet, reports are absolutely critical to the success of a project. They help in analyzing project status and providing intelligence to the project manager, for example. Project managers can fine-tune their approach to keep the project on track by analyzing reports. They can find the right balance between the project management triple constraint — scope, time and cost. However, good project management is about more than regular planning, tracking and balancing the triple constraint. It involves communication and presentation skills to engage the stakeholders. Reports provide a good mechanism for communication, presentation and negotiation. Using the appropriate reports, a good PM can negotiate with stakeholders and influence important decisions in the team’s favor. For example, given a moment’s reflection, who wouldn’t understand the following resource work availability report? Now that you’ve given consideration to the strategic importance of reports, let’s look at Visual Reports, which offer many benefits over the traditional variety. It’s difficult and time-consuming for most of us to analyze textual data (dates, duration, variances, etc.) to determine the status of the project. On the other hand, a picture is worth a thousand words. it’s easy to grasp the intelligence from colorful graphs, charts and pictures. Visual Reports are generated as regular Microsoft Excel files because the Project data is exported to an Excel file. The Excel data can be easily sliced, diced and transformed to generate beautiful reports, which isn’t as easily accomplished in Project. Many people in an organization may not have access to a Microsoft Project license. But almost everyone has an Excel license. So it’s easy to share Excel files with a broad range of stakeholders. While it’s difficult to customize the traditional reports without a bit of Project knowledge. Visual Reports can be easily customized using Excel. Traditional reports can be shared with others as printed copies or PDF files (or some other format). These are not the optimum ways of sharing the reports. Generating Visual Reports In the previous section, I said that the Visual Reports are generated as Excel files. That’s only partially true. Some of the reports are generated as Excel files while others are generated as Microsoft Visio files. Visio is another powerful tool that comes as part of Microsoft Office. As the name suggests, all the reports are visually appealing. The following is an example of a critical task status report put together in Visio. You can generate Visual Reports by going to the Project ribbon and clicking on Visual Reports to get the following dialog box: You’ll notice that Project provides many out-of-the-box Visual Reports templates. You can select any one of them to generate a report as either as an Excel or Visio file, depending on the chosen template. Project data is exported as a pivot table when you generate a Visual Report using an Excel template, allowing you to “play” with the data to get it looking just the way you want. You can modify: Colors in the charts; Chart types; What data is included in the chart; and What timeline and period is reflected. Plus, you can set up a visual comparison of different data values. The modification and customizations of Visual Reports is limited by your imagination and Excel knowledge. You can also generate a new template by clicking on the New Template button (shown in the first screenshot below), or you can edit an existing template by clicking on “Edit Template” button (shown in the second screenshot below). I hope you’ll consider adding Visual Reports to your project management toolkit. They can really help you improve project performance and communication to influence decisions in your team’s favor. Have a unique use for Visual Reports? Share your story with the MPUG community in the comments below. Image Source
6 Practical Scenarios Where Excel Import is Useful
I’m a software engineer by education. In 1997 I was working for a software development company, managing small software projects with the help of a small team. In the same year, I was introduced to Microsoft Project. In 1997 Project wasn’t particularly popular, even though it had been around for a few years. It had a limited set of features, but I found it useful. In fact, I instantly got hitched to it. It was a great tool then and it has become immensely better over the years. Today, it is much more intuitive to use and has more powerful features. Throughout my career, I have met project managers who show reluctance in using Project. But there are also many who regularly use it. Yet somehow, they don’t take full advantage of its power. Even after so many years of being around, Project has many helpful features that are seldom used. One such feature was mentioned in my previous article, “8 Places where Microsoft Excel Scores for Project Management.” In that article I talked about four features of Project that help in using Excel and Microsoft Project together, including importing Excel data into Project. Let’s drill down on that topic to solve some project management use cases. Pick up more great integration advice during MPUG’s upcoming “Project Integration Month” taking place all through July. Check out the online MPUG member training sessions and free vendor showcase sessions here. Import Excel Data into Microsoft Project If you’re not acquainted with the basics of Excel import, then take a few minutes to read Ellen Lehnert’s excellent article, “Ask the Expert: Import Excel Data into Project — Tips & Troubleshooting,” which provides a good introduction of the Excel Import feature. If you have already used Excel Import, then skip the following section and jump to the “Use Cases” section. A Brief Overview of Excel Import You can import Excel data by going to File | Open in Project. When you choose File Type as Excel and select an Excel data file, Project’s Import Wizard starts. The Import Wizard runs through several screens. These screens are shown in the following figures. Figure 1 Figure 2 Figure 3 Figure 4 Figure 5 Figure 6 In Ellen’s article, which provides details of importing task data into a new Project file, you’ll find a basic introduction to all the wizard screens. But to fully exploit Excel Import, you need to do more. The power of this feature comes when you import data on an ongoing basis and merge it with an existing Project file. Let’s discus how to take advantage of Excel Import to solve some practical problems. Use Case #1: Integrating Excel Schedule Data into a Project Schedule As a project manager you want to make a Project work breakdown structure (WBS) but leave the detailed scheduling to the team members, who don’t have access to the Project. You have been made a project manager for a project named “Universe” by your sponsor. He has assigned you a team of two dedicated team members: “Superman” and “Spiderman.” You’ve decomposed the project into four major work packages: “Milky Way,” “Andromeda,” “Black Eye” and “Cartwheel.” You have asked your team members to develop a detailed schedule of work packages. The team members have come back with four Excel sheets with detailed work schedules (one for each work package), as shown in the following figures: Figure 7 Figure 8 Figure 9 Figure 10 You want to integrate schedule data available in the Excel sheets with your Project schedule. A simple solution is copy and pasting Excel data into Project. But that’s not an elegant solution. Moreover, it’s time consuming and prone to errors. So, let’s do the Excel import. Step 1. Create a Project file that looks like the following figure. This is our original project schedule. Notice that, I have intentionally left blank rows after each work package. These blank rows will be populated by Excel data. As such blank rows don’t affect Project. Figure 11 Step 2. Import the first Excel file. In the Import Wizard choose New Map (figure 3 above), Merge… (figure 4) and Tasks (figure 5). You’ll notice that Project automatically maps the Excel column names to Project (Gantt Chart) column names. This only happens if the Excel file column names are the same as that in Project. Otherwise, you would need to map the columns yourself. Step 3. Use ID as the “Merge Key” and click Finish. Voila! You have imported the data. Figure 12 You’ll notice a few important things: Imported data comes in the correct order; Since we didn’t have date-related data in the Excel file, the Project Start Date is automatically copied to the Start Date of the first task; All the other dates (Start and Finish) are automatically calculated; All the tasks are properly outlined; and The data for summary tasks is automatically calculated. If you go to the Resource Sheet in Microsoft Project, you’ll notice that a new resource has been added: Figure 13 Now you know the power of Excel Import. The Excel data was imported as desired without any significant effort. You can play around with it by importing different fields as required for your project. Step 4. Repeat steps two through four and import other Excel files. Refer to the following figures for the final Microsoft Project schedule. Figure 14 Figure 15 Use Case #2: Integrate a Client Schedule into Your Project File To integrate a client or vendor’s schedule into your Project file, follow the same steps that you followed in use case #1. The data given to you by your client or vendor might be different, but the procedure for import will remain same. Use Case #3: Share Resources with Other Departments Say you want to share resources with other departments in your company. The organization’s resource manager has assigned you two more team members, but their availability is limited to 50 percent. Their names are “Batman” and “Ironman.” The resource manager has also given you an Excel sheet with resource data, which you want to add to your project schedule: Figure 16 Once again, the simple solution of copy and paste will work. But in reality resource data might be huge and much more complex. So let’s do another Excel Import. Step 1. Open your old Microsoft Project file. Step 2. Import the Excel file, which was given to you by your organization’s resource manager. In the import wizard choose New Map (figure 3), Append… (figure 4) and Resources (figure 5). You’ll notice that Project automatically maps the Excel column names to Project (Resource Sheet) column names. This only happens if the Excel file column names are the same as the ones in Project. Otherwise, you would need to map the columns. Step 3. Click Finish. The new resources will be added at the bottom of the resource sheet. The following figure shows the final Project schedule. Figure 17 Once again no manual effort was required and the Excel data was imported seamlessly. Use Case #4: Assigning Shared Resources to Project Tasks In this scenario you want to assign shared resources to the project tasks. Batman and Ironman have been added to the project schedule, but now they need to be assigned tasks. You want to assign work packages Black Eye and Cartwheel to these resources. Superman (your senior resource) prepares tasks assignments in an Excel sheet and gives it to you. You want to import this sheet into your Project schedule. You’ll follow the same basic steps to import assignments from the Excel sheet with one minor difference: In the import wizard you’ll choose New Map, Merge… and Assignments. Use Case #5: Sharing Cost Data There are four resources assigned to your project, but you haven’t added their hourly rates. Your accounting department maintains a strict control over cost-related data of the resources. They share the relevant data in Excel files. You want to import hourly rates from the Excel sheet into your Project file. In this case you’d choose New Map, Merge… and Resources in the import wizard. When you complete this import, you’ll see the updated costs for each task in the Gantt Chart view. Use Case #6: Tracking the Schedule with Actual Data Your team shares timesheets and tasks statuses on a weekly basis. Since they don’t have access to Project, they share the actual data with you in Excel sheets. You want to import this data and track the project on a weekly basis. By now, you’re an expert in Excel Import. You know how to handle this situation. So, I don’t want to say anything here. When you complete this import, you should open the Tracking Gantt Chart View and notice the changes. The Practical Outcomes of Excel Imports There are many features in Project that are either little used or ill-understood. Excel Import is one of them. In this article I’ve covered six possibilities where Excel Import can be used for practical purposes. I’m sure there are many more you can come up with yourself. I encourage you to keep exploring Microsoft Project features you haven’t given much attention to. As I learned back in 1997, Project is a wonderful tool with a great set of features that will increase your productivity. Do you use Excel Import in your projects? Share your experiences in the comments below. Image Source
8 Places where Microsoft Excel Scores for Project Management
Which tool would you use for project scheduling — Microsoft Project or Microsoft Excel? I’m guessing your answer (like mine) would be Project. It has many inherent advantages over Excel. (If you’re not convinced, then consider reading this MPUG classic in which author Keith Wilson provides compelling reasons why Project is better at scheduling projects.) Does that mean Project is a perfect tool? Hardly. So how do you decide when Project is the right tool to use and when Excel is more appropriate? To answer that question, let’s consider a different kind of everyday tool — the knife. Which knife would you choose to cut the vegetables — a kitchen knife or a butter knife? Probably you’d go for the kitchen knife. No one can stop you from choosing a butter knife for the job, but it does serve a different, also vital, purpose. In the same way, even though Project is meant for scheduling. Excel has its merits too. The advantages of using Excel over Project are these: It’s ubiquitous and requires very low investment. It’s the best tool out there for number crunching. You can slice and dice the data using Excel for doing project analysis. You can use Excel to create good visual graphs and reports. Above all, it’s a “generalist” tool — everyone understands how to use it. It doesn’t require any special training. Given these advantages, let’s look at use cases where Excel is better for scheduling than a project management tool. 8 Situations where Excel Excels for Project Management Your accounting department wants to maintain and manage cost-related data. Your client and senior management want to see beautiful reports. You want to share part of your scheduling data with your client, but not all of the data. You want to share only assigned tasks with your team who don’t have access to Project. You want your team to fill weekly timesheets as per the assigned tasks. You want to make work breakdown structure (WBS) to the planning package or work package level and leave the detailed scheduling to team members (who don’t have access to Project). You want to integrate your vendor’s schedule into your Project file. You want to use data on shared resources from other departments in your company. In these scenarios Excel and Project can be used together. They complement each other well. There are four features in Project that help in using Excel and Project together: Export data from Project to Excel. For this, you can use: File | Save As and select the file type .xlsx. Import data from Excel to Project. For this use: File | Open and select the file type .xlsx. Just copy data from Excel and use Paste Special in Project. Generate a visual report. For this, use Project | Visual Reports to generate a report in Excel. Project is a good tool for managing project schedules. It should be used as a primary tool for creating and maintaining project schedules. However, Project can’t be used everywhere. It’s an expensive tool that requires training. (Enterprise Project Management is even pricier and harder to become expert at.) Excel comes in handy and becomes useful in some situations, such as when integrating with Project for better management of projects. However, Excel should not be used as a primary scheduling tool. Have I left out your favorite reason for using one tool over the other? Add it to the comments below. Before I go, one more piece of advice: Don’t use a blade to cut the vegetables.
Rethink Your Project Risk Management Strategy
If I were to ask you what your project management risk strategy was, would you respond something like this? “Duh! We will deal with the problem when it comes.” In my experience, that is the most common approach to project risk management or response strategy. However, that doesn’t make it a good strategy. I believe risk management (otherwise known as “project management” in my book) should be proactive and preemptive rather than reactive. In this article I offer guidance on how to develop a project risk strategy based on the different kinds of threats projects face and then explain how to evolve project risk response into opportunities. The Four Risk Management Strategies Why do most project managers follow a reactive risk response strategy? The answer is simple. If a PM identifies and reports project risks, it somehow characterizes that person as inefficient, feeble and incompetent. It’s like any really tough endeavor — ice skating, bicycling up hill, writing novels. Professionals make it look easy. When a PM manages risks well by identifying, prioritizing, planning, responding and controlling projects and is therefore successful, there isn’t necessarily appreciation or rewards for a job well done. Other people may simply believe that the PM succeeded because the project was very simple. On top of that, if the PM overcomes innumerable problems against all odds (that may have been partially caused because he or she wasn’t being proactive), he or she is treated as a superhero or a miracle worker. Project Management Institute (PMI)®’s PMBOK® Guide defines four risk management strategies that deal with project threats as well as concomitant opportunities: Avoid and exploit; Mitigate and enhance; Transfer and share; and Accept and accept… There are two important components of any risk event — probability and impact. In order to deal with the project threats, you can act upon one or both of these components . Let’s examine each strategy in the context of probability and impact. Avoidance and Exploitation Adopt this strategy if you want to completely remove the possibility of a project threat. This absolute risk response strategy eliminates the uncertainty (probability) associated with the negative risk event. By adopting this strategy, you make sure that the threat event won’t occur because you take steps to reduce the probability of the negative risk event as low as it can go. How do you do this? By extending the project schedule to ensure timely completion; By reducing project scope to isolate the threat; or As an extreme case by terminating the project. Exploitation is the opportunity side of the coin. By removing all uncertainty, you’re also guaranteed a positive risk event by absolutely making sure the project opportunity is realized. This is the approach you take when you buy an off-the-shelf product instead of developing one or use a new technology to reduce cost of development. Mitigation and Enhancement As the word suggests, this strategy is adopted when you want to reduce the probability (or uncertainty) or impact or both associated with a negative risk event. By employing this strategy one of three things might happen: The probability of the negative risk event will decrease; The impact of the negative risk event will decrease; or Both will decrease. You can accomplish this by: Developing prototypes early to reduce rework; Assigning work to more skilled people to reduce duration; and Regularly taking feedback from customers to reduce chances of rejection. If your risk response strategy is mitigation, use enhancement to increase the likelihood of a positive risk event. By employing this strategy one of the following three things might happen: The probability of the positive risk event will increase; The impact of the positive risk event will increase; or Both will happen. You can achieve this by adding more resources to reduce project time and training people to improve quality. Transference and Sharing This strategy is usually adopted if the project team lacks the capability or capacity to deal with a project threat. In this strategy part or all of the impact is shifted to an external organization. The responsibility and ownership of the response is transferred to the external organization. It’s important to note that the external organization just takes the management responsibility for the threat; the threat itself isn’t eliminated. In this strategy the project team may pay a premium to the external organization assuming the threat. As a result of this strategy, the impact of the negative risk event is transferred but the probability might not change. One example of this is buying insurance and transferring the cost impact to the insurance company. Another example is hiring a sub-contractor. The opportunity strategy that goes hand in hand with transference is sharing. In this strategy complete or part of the ownership of the project is shared with an external organization that has similar objectives. The project team and the external organization may share costs, resources and knowledge in order to pursue the opportunity. If the approach works, the benefits are also shared. The forms it takes are typically: A technology partnership; A joint company; or A jointly launched product. Acceptance and Acceptance This strategy is adopted if the project manager doesn’t want to deal with a project threat actively. This is really a “do nothing” strategy. The impact of the negative risk event is accepted and dealt with if and when it comes. By employing this strategy, the project plan is left unchanged, which means there’s no change to the probability or impact of the negative risk event. The other side of the “do nothing” approach is to accept the benefits of the opportunity if and when they come. By employing this strategy the project plan doesn’t change and no change happens to either the probability or impact of the positive risk event. My suggestion is to embrace the idea of developing project risk strategies and then examining what opportunities they also incorporate. You may find that the opportunities make the risks that much more palatable. Photo by Graeme Maclean under CC 2.0