More posts in Risk Management
Here are five ways agile and Scrum techniques can curtail project quality risks:
1. All practitioners must review project requirements with the client.
In agile, the "user story" is the basic building block for agile requirement lists. A formal "acceptance test" is an integral part of that user story, as is explicitly reviewing it with the client to verify you have customer concurrence on the deliverable.
2. Agile teams collaborate while creating project components.
Inspections or pairing can prevent up to 50 percent of possible defects, according to research I conducted with colleagues. In addition, collaborating helps team members share other knowledge about the product or tools used to meet project needs at a critical stage.
3. Authors create a consistent set of verification measures.
Ideally, this takes the form of automated verification tests designed to catch missing functions or incorrect product behavior. These tests are run by the original author, as a sort of control against variables, and also used for regression testing by other team members. Yet even if a project passes these tests, it's also crucial that the product components are streamlined from the get-go so they can be easily maintained or extended in the future. This is called "refactoring."
4. Quality teams test small project deliverables as they are written.
Since the deliverables have been inspected or pre-tested, at this point you should expect few errors.
5. Feedback from a demonstration.
Agile teams hold demonstrations for their stakeholders, showing items completed since the last demonstration. The key is to elicit feedback from stakeholders and use it to improve the product. This provides one final chance to confirm that what the team produced was what the customer wanted. In this way, ideas and changes can be addressed before the completion of the project.
In addition to the following checklist for agile and Scrum risk reduction, it never hurts for teams to employ risk lists to further improve project performance:
- Client review of each acceptance test
- Team collaboration in inspection or pairing
- Test automation by the author and refactoring cleanup
- Independent testing by the quality team
- Demo to the client
How else do you think agile helps mitigate risk? What steps do your teams take to mitigate risk?
Read the Organizational Agility report for an in-depth look at how agile organizations increase their success rate on new projects, even in a volatile global economy.
These signals sometimes go unheeded because the ability to act on them can typically be constrained. For example, there is fear of making project customers unhappy if you raise objections, unrealistic expectations and a false belief that these types of messages will somehow motivate the project team.
In my experience, here are some of the signals that have pointed to a project headed down the wrong path:
1. "We'll start the project at the kickoff meeting."
Many times, important project mobilization activities tend to be ignored in the haste to begin a project with a large group meeting. This fixation on the kickoff meeting causes key mobilization tasks to fall behind. Early action on staffing plans, on-boarding processes and communication mechanisms before the kickoff meeting are more important than making sure the chocolate chip cookies arrive in time.
2. "This project WILL finish on time and budget."
This signal typically appears at the first sign of progress or cost slippage. As opposed to dealing with the root cause of the slippage, many times project managers will shrink scope to meet time and budget. Reducing scope has the effect of reducing the overall value proposition for the project. Address this tendency by allocating sufficient time early in the project to identify business success criteria independent of schedule and costs.
3. "The CEO is the sponsor for this project or program."
Name-dropping typically emerges when there is a conflict over resources needed by multiple projects. Project managers hope that by presenting the CEO or other executive as a sponsor, it will create commitment to the project. However, CEO's and other executives usually do not have the luxury of time to serve as a sponsor on a project. Leverage stakeholder management activities such as a level of funding approval list to confirm the primary sponsors for the project.
4. "We are four weeks behind schedule, but we'll make it up in the next phase."
Unless there is a large change of scope, one of the more the unfortunate laws of physics for projects is that any schedule slippage is likely to carry over to the next phase. The best approach is to be transparent about the schedule delay. By making the slippage transparent, you enable leadership team attention and corrective actions.
5. "I feel green."
A green status indicator in a project report typically means that no issues are present. However, a green status indicator does not always tell the complete story.
For example, despite deliverable dates that were slipping on one project, the project manager continued to declare a green status indicator. In an executive steering committee meeting, the leadership team challenged the project report. The project manager said, "I know the deliverable dates are slipping but I'm still feeling green." To promote project team and leadership confidence, employ objective project metrics such as planned vs. actual deliverable dates or earned value analysis to show the true status of the project.
While tools, approaches and processes help manage delivery risk, recognize these signals and take the right steps to act on them.
What have you found to be good examples of signals that point to risks on projects?
As professionals who constantly strive to improve, we study, read, take courses, attend seminars, listen to podcasts and more -- all to become better project managers. Ironically, sometimes this desire to learn causes us to lose focus on the fundamentals.
Instead, we look to novelty, the latest trends and perhaps even the latest fads in the interest of improving.
Likewise, we might embrace sophisticated techniques without ensuring that we've properly implemented the basic things on which the sophisticated techniques depend.
I've often heard great sports figures and musicians emphasize the importance of fundamentals in their success. Project managers would do well to place similar emphasis on the basics of our profession. I'd go even further to suggest that before we embrace any new or sophisticated technique, we should first look at how well we are implementing the fundamentals.
For example, what good does it do us to implement the latest agile techniques on a project where we haven't adequately implemented rudimentary change management disciplines? Similarly, what good would it do to implement Monte Carlo simulations in a context where we haven't adequately identified basic risks?
In my estimation, our success depends almost entirely on how well we have implemented fundamental risk and change management processes.
Things go wrong and plans change -- yet we often charge ahead without adequately planning and preparing for those realities. Certainly, our intuition tells us this is true, and our experience validates our intuition. Yet it still often happens that we lose sight of the obvious fact that the basics matter and matter most.
If you should ever waiver in your conviction, look no further than PMI's 2012 Pulse of the Profession. The report notes that change management and project management basics are among the most critical project success factors.
New and sophisticated techniques have their place, but the best thing to do in any profession is to go back to basics. Don't let the allure of the sophisticated or the novel, distract us from the value of fundamentals.
To discuss Pulse of the Profession on Twitter, please use #pmipulse.
See more on the Pulse of the Profession.
PMI's recent 2012 Pulse of the Profession report found that more than 70 percent of respondents always or often use risk management techniques to manage their projects and programs and these practices lead to higher success rates.
Here's an example of how risk management could have saved a project:
A project manager oversees an electrical team that is responsible for installing electrical and audio-visual equipment. The construction and civil engineering teams hand over the completed and decorated site, ready for the final phase of the project. To the project manager's dismay, the projectors do not align with the screens, rendering them not fit for the purpose.
What went wrong?
The civil and construction teams had altered the dimensions of the rooms; the customer failed to communicate the changes to the electrical team. Assuming the project was executed according to plan, the project manger planned and submitted the electrical drawings based on the original dimensions of the room. These plans were made redundant when the room dimensions changed, which upset the equipment's position.
To correct the situation, the project manager drew and submitted new electrical drawings. The site's walls and ceilings had to be reopened to accommodate the changes, which caused delays and increased cost, rework -- and frustration.
Had there been a robust risk identification and implementation plan, they would not be in this situation. Too many assumptions were left unchallenged and risks pertaining to the many external dependencies were overlooked.
As part of this risk management, proactive communication with the customer and other teams should have been planned. For example, the project manager should have considered and asked questions about how the contractors and sites would be monitored and controlled. What would the frequency and type of communication be like with stakeholders?
There should have been an assessment of 'what if' scenarios. What happens if the deliverables are not as expected? What are the risks if there are problems with contractors? What is the impact of not having dedicated resources on the team?
These types of discussions and questioning would have alerted the project manager and team to proactively plan to manage the quality of contractor work and employ the necessary resource on the project team.
Do you practice risk management? How does risk management planning make your projects successful?
To discuss Pulse of the Profession on Twitter, please use #pmipulse.
See more on the Pulse of the Profession.
Never assume that because a solution is smaller in size, you can take a relaxed approach to risk management. With enterprise resource planning (ERP) solutions, success requires collaboration between the project manager and the software provider to manage risks.
Here are some successful tactics for risk collaboration with specialty software providers:
1. Encourage leadership engagement.
While it is rare to meet a company CEO, it is likely you will work with the CEO of a specialty software provider. Early in the project, create a deep level of engagement between the leadership teams. For example, connect someone from your leadership team with the head of product development. An early leadership engagement will create a quicker path to resolve any issues.
2. Gain high visibility during analysis and design phases.
During the early phases of a project, a high level of visibility will help you to avoid costly errors in later phases. Early visibility also results in a quicker path to understanding the overall solution. For example, conduct design sessions at the specialty software provider's office.
3. Align methods and terminology.
Invest effort early on in the project to harmonize methods, phases, deliverable formats and milestones. Agree on the terms for completing a project phase, as well as common terminology. For example, define the difference between a customization versus configuration. When you agree on these things early on, it's less likely any confusion or miscommunication will pop up.
4. Make site visits.
Nothing is more effective than talking with a current customer about their experiences with a specialty software provider. These discussions create visibility to both best practices and challenges. Utilize this outside view to refine your project risk approach.
5. Don't underestimate contingency.
Even if a specialty software provider is smaller than an ERP company, it will still have the same fundamental delivery risks. Using a straight percentage for contingency may not be sufficient. Discuss with the specialty software provider a special contingency allocation to manage risks.
Do you have any tactics for risk collaboration?
Some of the most common problems of cross-cultural working arise from three main misconceptions:
1. Assuming your way is the correct way
In my experience working in the West, it's generally considered a positive trait to be able to communicate assertively, directly and voice an opinion.
But for Far East and Arab cultures, communicating in this manner is largely considered rude and aggressive. Emphasis is placed more on honor, pride, politeness and relationship building as a means for successful collaboration.
2. Assuming everybody understands your language
When I began working in the Middle East, I wrongly assumed that my strong British accent and articulation of the English language was clear for everyone. But just because I spoke clearly did not automatically mean that everyone understood me.
In fact, politeness prevented people from telling me truthfully that they didn't understand what I was saying. Though English is spoken around the world, it is still a second or third language for others. Allow time for others to process what is being said.
Additionally, the word "no" does not exist in some cultures. These cultures breed an optimistic disposition, and the answer to everything is a nod of the head, whether it's impossible deadlines or difficult requirements. If left unchecked, the end results will lead to frustration, misunderstandings and differences in quality expectations.
3. Selecting organizations or individuals on language abilities
When selecting suppliers, implementation teams or project staff, it seems more reassuring to recruit based on English language skills. The assumption is that communications will be easier and mitigate risks associated with translation.
This can actually backfire as the ability to communicate in English does not necessarily mean a person or organization is suitable for the job.
Based on personal experiences and lessons learned, here are my suggestions for good practices for project managers who work across cultures on projects:
- Begin conversations with a warm and engaging welcome. If you can learn the greeting in the local language, this immediately breaks the ice and leaves a good impression.
- When speaking English, speak slowly and use simple words.
- Limit professional jargon and unfamiliar terms until you are sure they are understood.
- Ask questions and politely request the other party to share their understanding.
- Never show frustration at having to explain something more than once.
- Insist on an opinion or clarification if one is required.
- Listen to everyone's opinion. It may be the person who is not speaking or is not the most articulate has the most valuable input.
- Be patient and tolerant in accommodating others' styles of making a point.
- Be astute as to what is being said and why.
- Follow up meetings with appropriate written communications to confirm times, dates, costs, and any other agreements or actions. Insist on a reply confirmation.
- Ask, request and check for constant feedback
- Smiling, relaxing and showing personality helps build relationships faster.
- Deliver on your commitments. This builds trust and respect. It sets a standard and makes it easier to hold others accountable.
- Employ multilingual people who can advise on cultural norms.
- Spend time building communication networks.
- Consider cultural training, guidebooks or manuals for all team members working on cross-cultural projects.
Read more posts on risk.
Read more posts on best practices.
For example, stakeholders in infrastructural development projects, like members of a surrounding community, make certain choices about project execution, such as location, quality and schedule. But, this doesn't always happen. If residents, say, are denied vehicular access to their homes because of an ongoing road re-construction, it's clear there was no stakeholder representative during the execution planning of the project.
African governments often rely on public private partnerships (PPPs) for utility and infrastructure projects. But most proponents of PPPs settle for a design-bid-build business arrangement, in which a single vendor may win concessionary bids to develop, operate and transfer utility infrastructure schemes. In this instance, a concessionary bid is a solicitation process for PPP projects.
This kind of business arrangement increases the risk of eroding the values and interest of that community. Sponsors and vendors could decide to satisfy themselves to the detriment of the residents or other project beneficiaries.
One way to mitigate the risk of communities rejecting infrastructure projects could be to use project advocacy consultancies, which are composed of community and government representatives. The committees ensure that infrastructure projects address the needs of the communities and are accepted by them.
In Africa, it would be a major stride in project management if stakeholders approved of the deliverables of PPP infrastructure projects. Of course, projects would be more widely accepted if communities were involved during the planning and execution of deliverables.
In my opinion, highly leveraged infrastructure projects that are initiated under concessional business arrangements and executed without the involvement of the would-be users should be discouraged. In turn, profits made by promoters and vendors from infrastructure projects could be better justified vis-à-vis community acceptance of the deliverables.
If communities approve of infrastructure projects, post-project operations and facilities management, it would benefit everyone. Promoters would smile at the projected cash flows, vendors would satisfy both contractual and project obligations, and ultimately, the project would be successfully completed.
Do you think involving stakeholders at the outset eliminates project risks? If so, how? What do you think about using a project advocacy consultant?
Read related posts:
"Different Perceptions of Risk on Projects" from Lynda Bourne.
"Use Project Management Tools in the Right Context" from Saira Karim.
1. Risks as facts: Risks are treated as objective, technical, neutral events that can be managed based on the knowledge produced by objective analysis using probabilities and expected values. The outcome is rational decision making.
2. Risks as subjective constructions with multiple dimensions: Risk managers choose the context and perspective they adopt. This allows multiple rationalities to coexist, depending on the values and perspectives of the observers. (This explains why some people find jumping out of an aircraft fun.)
From a project perspective, risks are uncertainties that matter. All estimates about future project outcomes incorporate a degree of uncertainty. This includes the three key dimensions of project management: timing, cost and quality of future project deliverables.
The project manager cannot be certain that the estimates that make up the project schedule or cost plan will prove to be correct, or that the project team will create deliverables to the appropriate quality standards. The rational management approach is to assess the risk factors and develop appropriate time and cost contingencies, backed by appropriate reviews and tests to ensure optimum quality. This approach is highly objective and rational.
However, you cannot rely on your stakeholders having the same view as you. If a stakeholder sees your project in a different context, their perspective on risk will be different.
For example, if you created a contingency plan using a Monte Carlo analysis, an executive may interpret the plan as a sign you don't understand the project because he or she expects a single definitive result. From this stakeholder's perspective, the precise calculation of a critical path method schedule offers certainty and minimum risk.
The authors of A Guide to the Project Management Body of Knowledge (PMBOK® Guide) have a different perspective, which understands the benefits of 'three-point estimating.' You cannot assume your stakeholder will have the same view.
The challenge is to accept that a range of stakeholder perspectives will occur. Stakeholders may derive completely different opinions from the same data.
You should anticipate this possibility and adjust the way you package your project information to communicate more effectively and ensure both you and your key stakeholders have a common understanding of the risks and issues confronting you project.
How do you deal with the challenge of managing different stakeholder perspectives on risk?
Read more on risk management.
Read more on stakeholder management.
Advance payments are meant to provide financial aid to the vendor by providing initial funding for jump-starting the project. It also shows financial commitment and project approval from the client.
Advanced payments are beneficial to the supplier, but are very risky for the client because the prepaid goods or services may not get delivered as planned. What if the vendor disappears with the advance payment? This would attack and distort the project's time and cost objectives.
In order to mitigate this project risk, the project manager may request a sort of surety before supplying the required advance payment. Most project managers would settle for an Advance Payment Guarantee (APG) from a reputable bank.
But banks often confuse the main goal of an APG on projects. Many times, the banks take care of operational risk while ignoring the aspirations of managing project risk.
For instance, banks in Nigeria, where I work, may request a 100 percent cash backed prerequisite for an APG. The insistence of 100 percent cash backup connotes seizure of the funds, which are meant for the project (as provided by the client).
It's good risk management on the bank's part. If the vendor flees with the advance payment, the bank would live up to its guarantees by taking the seized funds back to the client.
To a discerning mind, this antagonizes the essence of project risk management. The funds from an advance payment are primarily meant to be an inflow into the project to mitigate the initial funding challenges of the project. But the vendor would be exposed to sourcing the same funds that had been provided by the client, which would delay the project.
Any bank that is familiar with risk management should be willing to cater to the peculiar needs of the project objectives. There could be other ways of monitoring advance payment disbursement to the vendor as opposed to seizure of the entire funds while still expecting performance with the seized funds.
What do you think? Do you use APGs on your projects? What issues do you face? How do you mitigate the risks of advance payments?
Read more about risk management.
Check out PMI's Communities of Practice for more information about Financial Services Industry and Project Risk Management.
Such a big project brings some very big potential risks. My project delivery team and I made a list of possible risks plus a list of planned responses. Should one of the risks actually manifest, we knew exactly what to do.
As you may have guessed by now, this huge project that couldn't go wrong went very, very wrong.
Our team realized one thing while planning: We know that we don't know. Irritating as that phrase is, it may keep you from ruining what would be an otherwise successful project.
We knew that even our collective genius may not be enough to avoid disaster. But rather than spend the time creating mitigation plans for unpredictable risks, we created a mitigation plan for the actual risk of not knowing what could happen.
The plan included an eight-step process tailored to how the project team operates and how we run our projects. This gave us a standard procedure to follow if trouble arose. And when it did, we used that mitigation plan. There was no need to worry. Everything was under control, even for a risk we hadn't specifically planned for.
Because of this project, my team and I still always assume an "unplanned for" risk is on the horizon. We always give our due diligence to risk management and create responses for risks we can specifically identify. But then we review our eight-step plan to ensure we're all prepared for the unknown.
Do you have a risk-management response-mitigation plan in place for risks you know you don't know?
Let's start with two very basic risks that can occur with any IT project:
1. Critical project worker goes on emergency leave
2. Database server goes down one week before the release
How would you simulate and manage those risks?
In the first scenario, the best option could be just asking the worker to go on leave and see how you manage the work and team. Ask your team members to take leave on alternate schedules so you can measure the impact of each one of them.
In the second situation, ask your team to shut down the server and verify your mitigation plan. It may seem foolish, but this is best way you can determine the effectiveness of your mitigation plan if the risk actually occurs.
What do you say?
If PMI ever invites me to rewrite the risk section of A Guide to the Project Management Body of Knowledge (PMBOK® Guide) I think there are two things I would change.
The first deals with the inclusion of "upside risk," or opportunity, as part and parcel of risk management. I don't think it belongs. As my exhibit A, I cite the Oxford English Dictionary definition of risk: 1 a situation involving exposure to danger. 2 the possibility that something unpleasant will happen. 3 a person or thing causing a risk or regarded in relation to risk: a fire risk.
As author Mark Twain said, "Beware the man who would win an argument at the expense of language." Beyond the semantics, though, let's consider the three most prevalent ways of analyzing risk and see if they apply in managing a proposal backlog (a listing of an organization's outstanding and upcoming job bids -- or opportunities).
The simplest (and crudest) risk analysis technique is classification, in which you basically go through your work breakdown structure at whatever level and assign high-, medium- and low-risk classifications to the tasks. Associate each classification with a percent, e.g. high may mean 50 percent, medium 25 percent and low 5 percent.
Multiply the percentages by the original budget/time estimate, and you've done a risk analysis (of sorts). Try this with the proposal backlog, and you'll inevitably look astonishingly inept.
Then there's decision tree analysis. For each activity, assign alternative endings, with their impacts and odds of occurrence. Unfortunately for "opportunity" management, the only two possible outcomes of a submitted proposal are that you either win the work or you don't. Data on the gray middle is pretty useless when there's no gray middle.
Finally, Monte Carlo analysis is essentially a decision tree on steroids, with lots of statistical chicanery thrown in.
My second objection has to do with the use of risk management after the cost and schedule baselines have been set. I agree that prior to the finalization of the baselines, risk analysis is crucial to identifying and quantifying cost and schedule contingency amounts. The risk analysis can lead to informed decisions on how much and what type of insurance to buy, and what sort of alternative plans should be in place if a contingency event occurs.
But once the baselines are final, persisting in risk management strikes me as institutional worrying expressed in mind-numbing statistical jargon. To what end? Unless the response to a contingency event (in-scope, uncosted) was to significantly change from how the project team would have reacted normally, what difference does it make if it was anticipated?
I'm looking forward to the responses to this, and not necessarily from just the risk management aficionados.
Update: Risk management experts and enthusiasts are encouraged to join PMI's new Project Risk Management Community of Practice.
The majority of those that left a response said they would choose "option one." If you selected "option one" and well managed your relationship development and engagement processes, then helping "Mary"--the stakeholder in question--and her team contribute to the change should be beneficial. Why?
The first thing to consider is that Mary would be a key stakeholder at several different levels in the overall change management program.
As a long-term employee leading a group of workers, she is a stakeholder in the overall organization and is likely to have many unofficial contacts and significant influence.
As the leader of a group of workers who will be disadvantaged by a planned reorganization, she and her team are critically important stakeholders for the change manager. The group will never like the consequences of the change, but they need to be included so they at least cooperate for the good of the overall organization.
Because they can contribute knowledge and support, Mary and her team are also stakeholders of the program and particularly your project. The assumption that your team has enough knowledge to bypass her people is risky. You don't know everything that happens in Mary's section on a day-to-day basis.
The second important consideration is where the value is created. Ultimately, there is no value to the organization unless the change is successfully implemented.
Your project may deliver a key component needed for the reorganization but if it is not used, there is no value. This is something IT people in particular need to remember; 99 percent of IT projects require changes to business processes and are a complete waste of time if the business people reject the new processes.
If you selected "option two" and chose to ignore Mary, she is likely to become an active opponent of the change (no involvement equals no commitment and no support). This puts your most important stakeholder at a disadvantage: the overall change manager.
Myth 4: Using Monte Carlo simulations to generate contingency budgets or schedules is an appropriate approach and should be more widely adapted.
Truth: Monte Carlo simulations are needlessly complex and shouldn't be used.
Of the three most common risk analysis methods used in creating a contingency schedule or budget--risk classification, decision tree analysis or Monte Carlo analysis--the latter is by far the most complex, so naturally it has the reputation for being the most robust.
But is it really?
Consider the data points your Monte Carlo simulation driver asks of you: original budget (or duration), one or two "things-going-wrong" alternatives, their odds and costs, and at least one "things-go-great" scenario, with its odds and estimated costs.
This is the exact same data set that would support a single-tiered decision tree analysis, except that the Monte Carlo version invokes a random-number generator to fill in hundreds (or even thousands) of other data points, which can then be used to analyze confidence intervals--at least supposedly.
But all of these other data points are artificial! The ensuing confidence intervals are far from reliable, hoopla notwithstanding.
Myth 3: Risk management is so important to project management that it should be employed throughout the project's life cycle.
Truth: After the baseline is set, formal risk management is pretty useless.
This last assertion is guaranteed to invoke a passionate debate, but consider your personal performance. Do you function better when you are confident or when you are worried? And what does formal risk management bring to the table once the project is underway, other than institutional worrying?
Analyzing ominous trends or performance information indicating a problem in order to head off threats to project success is what project managers do on a daily basis. Spending excess time quantifying those threats doesn't improve your odds of success.
There are a few risks that don't involve people--inclement weather, for example--but 90 percent of the risks on most projects are caused by one or more people:
• Quality risks almost always occur because people do not follow or not understand processes.
• Design risks are usually the result of people not communicating.
• Time and cost risks typically tie back to the performance of people doing the work.
• Even inclement weather is influenced by people's perceptions--what's deemed "too wet to work" in a temperate climate may be seen as okay in a tropical monsoon climate.
People also determine if a risk is acceptable or not. Whether a risk is perceived as acceptable or not is 100 percent inside a person's mind.
As project managers, our job is to reduce risks to a level that gives the project the best overall chance of success. Yet extreme risk aversion will kill a project more effectively than a gung-ho attitude.
Of course, what constitutes a sensible level of risk is totally dependent on the perceptions and risk attitude of your key stakeholders.
That's why a central part of effective stakeholder management is ascertaining the risk attitude of your stakeholders. And then you must either adapt the project to fit within these parameters or provide the necessary information to help the stakeholder change his or her perceptions of what is acceptable.
The more that people feel they understand a situation, the more willing they are to accept risks.
Similarly, if you have a trusting relationship with someone, you're more likely to rely on their capability to safely manage risks on your behalf.
The most useful risk management strategy you can use on your project is effective stakeholder management supported by good communication. What has your experience been?
Carrying around these unsolved issues creates several risks.
1. Schedule risks: The project isn't completed on time because the issues left unresolved have caused delays in project activities or phases.
2. Budget risks: An unresolved issue creates a requirement to redo the work. If this work isn't done within the allocated timeframe--when it's still possible to refine requirements and while keeping the changes within the scope of the project--any changes would require additional funding.
3. Staff risks: The issue, if not dealt with by the project team, may be passed on to the baseline/production support team. This would impact other departments--and their time and money.
So how can you make sure the issues bag is empty at the end of the project? Here's what I suggest:
• Keep track of the issues.
• Maintain a list of the risks involved with these issues.
• Keep a list of assumptions about what? and validate them.
• Maintain a list of all changes executed during the project.
• Perform quality assurance and close-out any outstanding quality? issues.
• Ensure appropriate user-acceptance testing phases and garner signoff on the testing.
• Pay attention to the organizational and business environment your project is impacting and any issues that arise.
• Notify systems support teams of any impacts that may be caused by your project, directly or indirectly.
Now, as the firestorm I've just ignited races to engulf me, let me be crystal clear about what I'm asserting. I am not saying that risk management is without value. What I am saying is, once the contingency budget and/or schedule have been baselined, the value of the information produced from risk-analysis techniques drops off dramatically.
U.S. General Dwight D. Eisenhower believed that once you're on the battlefield, all plans were out the window. And, while (most) projects don't approach the level of chaos and mayhem associated with a battlefield, I think his ideas are highly applicable in our works. That's what project managers do; they respond to the changes in circumstances, resources, demands, and hundreds of other parameters, every single working day.
The notion that project management decisions can be quantified and reduced to formulaic responses in most circumstances is absurd, and furthering that approach using excessive statistical jargon does not automatically make it legitimate.
As for the assertion that risk management includes an "upside risk" component--a.k.a. opportunity management--I would like to point to the Unabridged Webster's New International Dictionary, Second Edition. Its definition of "risk" reads, in part, "Hazard; danger; peril; exposure to loss, injury, disadvantage or destruction."
Indeed, nowhere in the definition will you find any reference to any possibility of a positive outcome or environ, much less opportunity. And yet, you see people make the comparison risk management equals opportunity management.
I know the risk management aficionados have had a lot of success re-defining the verbiage associated with their area of expertise in A Guide to the Project Management Body of Knowledge (PMBOK® Guide) space, but isn't there another way of furthering risk management notions without pounding away at the lexicon?
Oh, there are certainly those cases where a project manager insists that no cost or schedule management systems be used, and it doesn't take long to drive that project into the ground. But in most other areas the link between act and consequence is not nearly so stark.
Renowned psychologist, B.F. Skinner, wrote that a variable rate of reinforcement virtually guarantees a behavior will continue. If that is so--and I believe it to be--then it follows that a practitioner who has experienced success using a particular technical approach may be inclined employ that approach over and over--even when it fails over half the time. That same practitioner might also be inclined to join with like-minded project managers to advance a new model or structure for success.
Their assertions may be correct and insightful universally, in some specific environs, or completely off base.
I entitled this post "Part 1" because I intend to take a close look at some conventions that may have been adapted in that spirit and without the scrutiny of an iconoclastic wise guy such as me.
Next up: Does risk management really help bring in projects faster, cheaper or with higher quality?
See relevant research from Project Management Journal® as reported in PMI Community Post: Avoiding Project Failure by Managing Organizational Culture
It takes the IT team a day to get everything working again, which may push back an already delayed schedule. How do you prepare the mitigation/contingency plan for this kind of risk? It may seem minor, but how many of us even identify these types of little things as risks? We should.
In this instance, I suggest the project manager keep a backup machine with the required software and hardware ready for the team. I know it will cost more money, but if you are able to save a day's effort every month then it would be justifiable.
How do you prepare for these seemingly "little risks"?
See the article, Plan for Everyday Risks, Brace for the Ordinary, by Carl Pritchard, PMI-RMP, PMP, published in April in PMI Community Post.
I am a strong believer in integration. Therefore, risk management must be an integral part of any organization's project management methodology.
Risks are generally identified, assessed and quantified. Risk is then monitored until it is no longer a risk or to ensure that any events identified as a risk do not actually go unanswered. That's where risk response comes into the picture.
Response to risks comes in the form of:
Organizations must ensure they:
- Identify key risk-management processes to map them out to the organization's processes for project delivery
- Identify risk factors (i.e., elements that cause probability of risk occurrence to increase)
- Standardize risk identification, assessment and quantification, and documentation across the organization
Think of it this way: Risk equals money. It's the amount of money we are going to spend (or not spend) on either activity A or B. If we identify a risk of executing activity A for a price of X, but have a moderate to high level of confidence in success of this activity, we may choose to forgo doing anything else or delay the activity to remove or reduce the risks.
If risks end up being realized and we end up facing the results of it, the cost of it would be linked to loss of revenue and added support to resolve the issue that was created by unresolved (but accepted) risk.
And if it is less expensive for an organization to actually accept the risk and deal with its impacts rather than continuously applying resources to making things perfect, then the justification of taking risk from financial standpoint can be very convincing.
How do you work with risk?
The U.S. Navy has four of these battleships, but, fortunately for enemies of the United States, only one is in the reserve fleet, while the others have been converted to museums.
Why is such a clearly effective weapon not in use? It may be because of the relative ease with which aircraft carriers sank battleships during World War II, leading to the conclusion that the carriers were superior naval vessels in all respects.
In the epic struggle to advance project management capability within our organizations, I think it's important to recognize that we are in competition with other management approaches and information streams. And in this competition, we may be failing to use the most powerful weapon in our arsenal: the capability of an Earned Value Management System (EVMS) to predict the future.
Accurate prediction of the future is obviously a very useful capability. In the project management world, the key pieces of future information include: How much will this project end up costing, and how long will it take?
These twin brass rings of project management information are hotly pursued in a variety of ways--most of them incorrectly, in my opinion. The most common approach is to re-estimate the remaining costs and duration of an on-going project, and to then add that amount to cumulative costs or duration.
This method, despite being notoriously inaccurate and injecting hundreds (if not thousands) of purely subjective data elements into the mix, is often defended as the only appropriate approach.
Conversely, the best approach--calculating the estimate at completion (EAC)--is commonly derided by so-called project managers, even though it's faster, easier and demonstrably more accurate than its re-baselining counterparts.
The most familiar EAC formula, the Budget at Completion (BAC) divided by the Cost Performance Index (CPI), can be algebraically reduced to dividing the cumulative actual costs by the project's percent complete. This formula works with durations as well: Divide the cumulative duration by the percent complete, and you have an accurate idea of how long a given task will take.
With such an easy, simple and powerful weapon in our arsenal, why aren't we using it more?
What's a project manager to do? In some cases, the decision has been made for you.
Take Aspen, Colorado, USA--city law prohibits construction within the city limits for eight days, from 25 December to 1 January.
"It's really messing my schedule up, and at this time of the year, we need to take advantage of every good day," Gary Wesley, superintendent of a construction project in Aspen, told The Aspen Times. "I had a lot that was going to happen that week."
Project managers and construction workers interviewed by The Aspen Times and Aspen Public Radio this week seem to view the construction prohibition as a recent development. But the city's Construction Management Plan Requirements Manual, which was revised 19 September 2007 and dated December 2007, clearly states: "No construction is permitted on ... federally designated holidays including: Christmas week (Dec. 25 - Jan. 1)."
The situation highlights the need to exercise due diligence in the initial stages of project planning. It must may prevent a lot of headaches once delays such as the holiday season strike--and mean one less source of stress.
How do you plan for the holiday seasons? Does work slow or just stop completely?
Those who were directly responsible for the security failure have been shown the door either willingly or under pressure from a combination of higher command, media and public anger.
I would like to discuss it as a project failure and conduct (with reader participation) the post mortem analysis on what went wrong and how it could have been avoided. The discussion should be based upon information available from news analysis.
Let me start with lessons learned that translate to projects:
Issue #1: The Indian Intelligence Bureau (IB) is claiming it had informed the government about a possible attack from seaside but no action was taken. There was a risk identified but no mitigation plan was prepared for it. It is important to monitor risk areas and take preventive action before it gets too late.
In projects, it is the responsibility of project managers to spread awareness about the risks in their projects and their mitigation plans. Don't take even a minor issue casually. If you don't have time to look into the issue, then assign it to someone else and track it to closure.
Issue #2: India had a couple of terror incidents in the past but no measure was taken to prevent them in the future. It is a universal truth that prevention is always better than correction so it's good to have check points and preventive measures in place before you lose money and resource time.
Document lessons learned from previous mistakes and ensure everyone is aware of them. It's better to review the learning database periodically and update it if required.
Let's keep the conversation going. What other lessons learned can you find in these events?