By Kevin Korterud
I’m amazed at how often I receive requests for help creating an effective risk management process. These inquiries usually come from organizations with a risk management process that hardly anyone uses. Stakeholders, program managers, department heads and executives are mystified about why nobody is declaring risks on their projects, which can create the false perception that everything is going fine.
Why does this happen? One reason is that project managers believe making risks visible to leadership could impair their efforts. Another reason is an organizational culture that creates a negative perception of risks. For example, I have seen some highly entrepreneurial companies foster a mindset of rugged heroism, which causes project managers to think they have to fix everything themselves. In this project environment, project managers worry that escalation to leadership will be seen as a sign of weakness.
In fact, there’s no use pretending any project is risk-free. Risk management is an essential part of any project: Whether you’re climbing a mountain or changing a light bulb, there are always risks. For anyone who’s ever been leery about flagging risks, or is just looking for some new approaches, here are five tips.
1. Think of risk management as a way to get what you need, when you need it.
Project managers rarely have the financial or command authority to change schedules or release additional funding—that’s leadership’s job. For this basic reason, declaring and escalating risks enables leaders to provide risk mitigation assistance.
Making risks visible to your leadership gives them enough lead time to provide relief when it is needed, not weeks or months later when unmitigated risks turn into project problems.
2. Don’t forget: People can be risks, too.
I have seen many risk management plans focus entirely on things: systems that might not be ready, processes affected by outside regulatory bodies, estimates that were done in a hurry at year-end budget cycles, etc.
What project managers often fail to consider in their risk planning is that people can also be risks.
For example, let’s say your project sponsor is replaced by someone who has no experience in the subject areas of your project. This lack of experience initially will cause longer decision-making cycles as the new sponsor comes up to speed in the subject areas.
So be sure to include people risks in your risk register—they can affect your progress as much as more inanimate factors.
3. Create guiding principles for risk management.
While there may be a process in place for managing risks once they appear, quite often it is unclear to project managers when and how to escalate risks to higher levels in an organization based on their potential impact.
To create clarity and promote transparency around risk management, the best approach is to set guiding principles that govern the process. The rules should be simple and broadly communicated throughout an organization.
Examples of guiding principles include:
· Declaring project risks demonstrates professional discipline that will be recognized by leadership.
· A potential mitigation approach should be prepared for every identified risk.
· Risks with greater potential impact need to be made visible at higher levels in the organization.
4. Use the 30/20/10 rule of thumb.
In my experience, the most frequent question asked by project managers is how many risks should be identified on a project. For example, a person might feel that a small project should have a small number of risks. But that’s not necessarily true, especially if a small project impacts a large population of people.
One risk management approach I recommend to project managers is the 30/20/10 rule, which starts with a broad slate of risks and narrows them down throughout the life of the project.
Here’s how it works: Identify risks at the beginning of the project that, if realized, would affect 30 percent of the schedule, budget or results. Midway through the project, the goal is to lower the potential impact of risks to 20 percent of the schedule, budget or results. By the end of the project, the project should carry risks containing no more than a 10 percent impact.
5. Don’t forget the bigger picture.
Project managers frequently tell me they would have finished a project on schedule, but team members were pulled into another project. Translation: another project was more important. And the strategic relevance of your project matters just as much as how you manage that project on a day-to-day basis.
To manage the risk of irrelevance, conduct an assessment on a recurring basis of how your project fits into your organization’s strategy and portfolio. Validate the relative priority of the project against other active and pending projects, and check on potential scheduling dependencies that may impact your plans, as well as any resource conflicts that may be triggered by other projects.
What techniques do you use to identify and mitigate risks on a project? If you’ve worked at an organization where flagging risks attracted negative attention from higher-ups, how did you deal with this challenge?
Seattle's Troubled Tunnel: 3 Communications Tips for Regaining the Public's Trust
Human Aspects of PM,
PM & the Economy,
PM Think About It,
Categories: Best Practices, Change Management, Communication, Complexity, Ethics, Generational PM, Government, Human Aspects of PM, Leadership, Lessons Learned, PM & the Economy, PM Think About It, Program Management, Project Delivery, Project Failure, Project Planning, Social Responsibility, Stakeholder, Strategy, Teams
One of the biggest public works projects in the United States right now has some major problems. It’s a more than $3 billion effort in Seattle, Washington to replace the Alaskan Way Viaduct, an aging elevated highway on the city’s waterfront, with a 2-mile-long tunnel. If you’ve been keeping an eye on the project, you know that the tunnel-boring machine (dubbed “Bertha”) broke down more than a year ago, creating various challenges and overruns. Public outcry is mounting.
Now, if you’re like me and believe in the power of communication to ensure that projects run more smoothly, the tunnel project has highlighted the need for more openness, better stakeholder management and speaking to your audience in understandable ways, instead of falling into buzzwords or corporate speak.
If I were working on the project right now, here are three things I would look at to regain the public’s trust and help everyone in Seattle and the state of Washington understand exactly where the project is.
1. Be willing to convey incomplete information. The project’s big challenge is that the machine built specifically for drilling the tunnel encountered a setback when it struck a metal pipe during the excavation process. Unfortunately, it took project leaders over a week to convey the extent of Bertha’s problem, the course of action and any sort of timeline to get things back on track. Since Bertha stopped working in December 2013, information has trickled out to stakeholders.
The project’s leaders could have set a much different tone early on by stating what they know and what it means to the project—along with an acknowledgement that they really aren’t 100 percent sure what the solution is, and a clear statement that they will work to provide status updates to all stakeholders as often as possible.
Instead, it’s been “hard to get straight answers,” as the Seattle radio station KUOW put it.
2. Be honest. This really goes hand in hand with the first point about having the confidence to convey information that is accurate, even if it is incomplete. The public has begun to doubt that project leaders are being honest about the tunnel’s current status and future. This is partly because when the city’s department of transportation (DOT) or the state government has updated the community about the project, they have given information that seems farfetched and is tough to believe in light of Bertha’s lack of progress.
Case in point: A DOT official recently toldSeattle’s City Council that the project was “70-percent complete.” That claim was met with a great deal of skepticism by journalists and members of the community.
The lesson for project managers is: Don’t fudge information to avoid blowback. In the long run, you are putting your project at a strategic disadvantage because you may lose funding or you may come under heavier oversight…or worse. So just explain things in an honest and forthcoming manner.
3. Be consistent in the delivery of information. A lack of consistent communications has been one of the big failings for the Seattle project team. And when there’s an information void, it will usually be filled by something you aren’t going to like. In this instance, the lack of communications has led to a real breakdown of trust.
That’s why you need to make a plan for communicating consistently with stakeholders. It should include the best ways to communicate with specific stakeholder groups, and a plan for gathering accurate, up-to-date information from the project team. To ensure timely gathering, build the consistent delivery of information into day-to-day project activities. Set a schedule of when you want your team members to communicate information to you, and hold them accountable.
In turn, you need to inform key stakeholders of when and how you’ll communicate information to them, and then stick to that plan.
In most cases, communications comes down to recognizing the importance of clarity in effective project leadership. In Seattle, you can see what a lack of a clear process can do to the trust between stakeholders and the project team. I’m confident that most unsuccessful projects began to unravel when communications stopped being clear and consistent.
What do you think?
My father spent decades working for a telephone company. When I was quite young, he took me to see a large centralized telephone switching facility. I was amazed and enthralled at seeing all the technology it took to carry a person’s voice over a telephone line between houses on a street or across oceans. Leaving the facility, he told me, “You know, all of what you saw here doesn’t matter unless we can get the last 100 feet of a person’s phone line right.” Although the end-user experience back then consisted of selecting numbers on a rotary dial, there were still many technological considerations in getting things to work in the last 100 feet from a telephone pole to a house.
Over the span of my project management career, I’ve realized the wisdom in getting those “last 100 feet” right for an end user — and how doing so is an essential part of the success of a project. Here are important components for getting those last details right:
1. Find end-user stakeholders. It is very common to have one or more stakeholders who are leaders in an organization. Stakeholders who are leaders provide essential strategic direction to a project. However, it is equally important to get the perspective of the people who will eventually use the outputs of a project. In addition to leadership stakeholders, create a group of end-user stakeholders that can provide a detailed perspective on these outputs. This balance of stakeholders between leadership and end users will give an all-encompassing view to help the project meet objectives.
2. Mind location. Quite often, a project manager is physically located near the project’s leadership stakeholders. However, certain types of projects that involve the creation of new processes and products would be better served if the project manager were located closer to the team serving end users, or the end users themselves. Doing so provides additional visibility to factors affecting the project that may come up in formal meetings. For example, the president of a global automobile company prefers to be located out on the design floor so he can have clearer communications with his designers, which results in higher-quality automobiles.
3. Develop functional success criteria. Much of our project management time and efforts focus on meeting functional requirements. But it’s also valuable to know how well we are meeting these requirements. To improve the quality of the outputs of a project, document functional success criteria for each requirement. For example, if a requirement states that a process is intended to produce a certain product, also specify performance criteria for the product. This can include functional success criteria such as: “Billing information must be displayed within two seconds for a customer inquiry 99 percent of the time.” Adding functional success criteria will promote end-user satisfaction and overall project quality.
4. Measure outcome-based metrics. We all know the value of measuring our project performance with A Guide to the Project Management Body of Knowledge (PMBOK® Guide)metrics such as schedule performance index (SPI) and other useful progress indicators. While these measurements are important, we also need metrics that measure the performance of the outcomes of the project. These can include adoption rates of a new process, evaluating end-user satisfaction with a survey and analysis of labor costs to complete a task. As these measurements typically occur near the close of the project, they can be conducted by someone other than the project manager.
It has been many years since my father took me into the telephone switching room. However, his comments about the importance of getting it right to the very end have stayed with me throughout my own decades-long career.
Do you have any tips on managing the “last 100 feet”?
You want your projects to get off to a good start and end without major glitches. However, what typically happens is that projects begin with many unknowns and continue to progress with more unknowns. Not only that, projects hit many bumps along the way — and you are constantly addressing problems, attempting to resolve issues and rallying to minimize risks.
Faced with this, I recommend approaching projects with a “project network diagram” mentality. (A network diagram is a planning tool that shows sequences of tasks, dependencies on tasks and impacts on a project.) Here are tips on using a network diagram mentality for managing project schedules:
1. Count backward. There are tasks that inevitably depend on each other and have specific time frames. For example, it might take 10 days for one task to be done and 15 days for dependent tasks to be complete. So right away, you know you already need 25 days for that project. So these start-to-finish and other connecting relationships matter when building a schedule, as do float, slack and critical path times. These are all time factors you consider when doing backward counting. The technique of counting backward helps define the schedule because you focus better so as not to miss a number or a task.
2. Look in other directions. A horse can see in one direction with one eye and in the other direction with the other eye. A project manager needs to do the same and constantly be aware of the surroundings. A network diagram offers this peripheral vision by encompassing all the aspects that matter to the project — and helps you set boundaries. A view in one direction can focus on what’s happening in the project. The other direction could be the bigger picture of your project. Let the boundary be what could potentially surface from either of those directions. For example, say your company has a portfolio of projects it has to complete. So at the same time you’re keeping an eye on the spending on your project, you also want to be aware of whether the company will be able to maintain your resources over the length of the project, especially in an economy in which layoffs happen all the time. If your company has to release some of your resources, what then would be your contingency plan to still make sure your project can be completed?
3. Keep the end in mind. Have an idea of the goal the project should achieve. Encourage team members to maintain a layout of their tasks in a way that identifies and prioritizes what must be done and can be done to reach that goal. Then, inspire your team to approach all tasks with confidence. In a network diagram, after having laid possible connections together, the project manager sets controls in place, giving him or her the capability for more optimal opportunities of project success. Manage your time and your project team’s time based on making it to the finish line.
What method do you use to help you prepare for and better manage project schedules?
6 Obvious Budget Overruns to Avoid
Categories: Project Planning
Nowadays, we rarely hear about projects that finish below a given budget. On the contrary, we hear about projects that need more people, more material resources and more time, which ultimately translates into additional costs that strain the project budget.
Although it is clear that project costs can be influenced by external factors beyond the project manager's control, there are at least as many factors that can be controlled from within the project, through appropriate project cost planning.
Here are six simple reasons that projects incur cost overruns -- and how to prevent them:
1. Underfinancing. You've probably heard about projects that start with an undersized budget ("We could only allocate that much for this project..."). Such projects will have a high risk of overrunning the initial budget, as well as a high risk of failure.
Mitigation: Clarify with the project sponsor from the very beginning how cost overruns, which are very likely to occur, will be handled -- for example, through scope reduction or additional funding.
2. Unrealistic costs estimates. Projects that have costs estimated based on gut feelings or inexperienced personnel are poised to face budget overruns. Biased and inaccurate cost estimates are likely to look unrealistic at a later stage in the project.
Mitigation: Break down the work into smaller and more assessable packages. Get help from subject matter experts and experienced personnel when estimating costs. Make the cost estimations comprehensible, by applying different estimation techniques (e.g., three-point estimates, parametric estimating or bottom-up).
3. Underestimated complexity. Many projects nowadays, especially larger ones, have constantly growing complexity. The Berlin Brandenburg Airport and Terminal 1 of Munich Airport, for example, were quite similar in scope, but conducted at different times (25 years apart). Yet Berlin Airport, the more recent project, continues to have considerable budget overruns and delays. One of the reasons: the underestimated complexity concerning the financing of the project, the construction of futuristically designed facilities and newer regulations.
Mitigation: Split the project in smaller work packages or phases. Avoid planning everything extensively from the very beginning (the planning alone of the Berlin airport project took 15 years). Plan iteratively -- per work package or phase -- and throughout the project.
4. Extended project schedule. Just because the project schedule is met doesn't necessarily mean the budget will be met as well. On the other hand, it is highly likely that if the project schedule is not met (for example, due to a project time extension), then the project budget will be blown thanks to additional costs that may pile up, since the project team and resources will be needed for longer.
Mitigation: Manage the project time and schedule well. Focus especially on the tasks on the critical path, which can have the most impact on both project schedule and costs. If you get asked to extend the project time, explain to your stakeholders that this probably will cost more. Remember the scope-time-budget project triangle. Time is money!
5. Improper buffer planning. If you don't plan (or plan improperly) for a budget buffer, the smallest deviation in scope or schedule will cause an overrun.
Mitigation: A budget comprises estimated cost and some contingency. Plan the contingency for unexpected scope changes, unusual weather changes or possible problems with suppliers. Consider a buffer for the costs that cannot be accurately or predictably estimated. Some of the cost estimates will be more accurate than others -- for example, commodity prices will be more predictable than labor costs for a specific service.
6. Improper resource planning. Labor resource costs could be one of the project's biggest expenses. If the project lacks labor resources, a later labor force acquisition will be an unexpected project cost. It can also mean a higher cost since the contracting conditions might not be the same as when initially planning the project. Similarly, resources allocated in excess will mean unnecessary allocated costs, plus unnecessary blocked resources that could have been useful on other projects.
Mitigation: First plan the scope, then the required work to be done, and then the related assumptions, dependencies and risks. This will facilitate a better understanding of the work needed to be done and hence will help better assess the right equipment, amount of resources and required skill sets.
How do you manage costs on your projects, and which measures do you apply to avoid cost overruns?