Project Management: Risk Management

Get the PDF Version By CJ Williams

In many projects, risks are identified and analysed in a random, brainstorming, fashion. This is often fatal to the success of the project, as unexpected risks arise, which have not been assessed or planned for and have to be dealt with on an emergency basis, rather than be prepared for and defended against in a planned, measured, manner. Very early in the preparation and planning stage, it is essential that potential risks are identified, categorized and evaluated. Rather than look at each risk independently and randomly, it is much more effective to identify risks and then group them into categories, or, to draw up a list of categories and then to identify potential risks within each category. This way, common influences, factors, causes, potential impacts and potential preventative and or corrective actions, can be discussed and agreed on. Categorising risks is a way to systematically identify the risks and provide a foundation for awareness, understanding and action. Each project will have its own structure and differences, but here are some categories that are common to most projects (to which you can add your own local, sector, or project specific, categories). I have not given deep detail here, but your project team and sponsors should be able to relate to these categories and use them in the risk assessment process. For example, with "operational resources" your team can discuss issues such as, availability, delivery timing, cost, capability, necessary conditions for operation (eg. ground, weather, light); with "stakeholder resources" your team can identify all stakeholders and list potential risks that these stakeholders may generate, such as bad publicity from the media, delays caused by community or environmental groups, delays caused by utility companies, problems with trade unions. Related risks and potential actions, must then be documented in the risk management plan and discussed at all the key stages as the project progresses. All the details and the actual action taken and the outcomes, must then be recorded and reviewed during the closure and review stage, for lessons to be learned and applied to future projects. Here the question that most project managers ask: "how do we know if we can manage the risk, if it arises?" Often, sadly, no evaluation is carried out to determine the expertise, experience, capabilities of the team, individuals, organisations that would be required to deal with, manage that risk, if it occurred. As a result, if it did, the team may not be able to deal with it effectively, even though the initial forecast was that the risk could be managed.

This happens frequently when the planning team is not the project team that manages the project and/or when key individuals in the original project team leave the team during the project and are replaced by individuals with different skills, experience and capabilities. The clear message here is that setting a risk tolerance level is a dangerous business. Each potential risk needs to be carefully, rigorously, analysed and the project team, the supporting teams and individuals, the organisation(s) involved in managing the project, all need to be evaluated to determine whether there is the capability to manage that risk successfully, should it arise. Where gaps in capability are identified, then appropriate corrective action must be taken. During the project itself, this capability must be constantly monitored and, where necessary, action taken to return the level of capability to the required level. Conflict over resources often arise during the middle to later stages of a project, because, often unexpected other, newer demands arise which are seen as being of higher priority. This can lead to resources that were originally allocated to the project being taken away, or reduced in quantity or quality, almost certainly to the detriment of the project. The answer to this dilemma is not easy, but in essence, the project management team must include "conflict over resources during the life of the project" as a major potential risk and plan for it accordingly by securing agreements and then monitoring the situation continuously. If a dispute does arise, there is a role here for the project champion and or the client to ensure that the allocated resources are not taken away. Fundamental to many of the issues that we discuss here is the question of who should be responsible for risk assessment and management. Too often the responsibility for risk identification, assessment and management, are left to the project team, especially once the project has started. But there are other individuals and groups, including some external stakeholders, who should be continuously monitoring particular activity and feeding back regularly to the project team leader. Some are easy to identify. They include of course, the client, the sponsor, key specialists in the project team's organisation, or organisations, the major external participants, such as emergency services, local authorities and contractors. The easy way to identify other individuals and groups is to look at your list of stakeholders. Each one has a responsibility, to a greater or lesser degree, to help identify potential risk and give information on this to the project team. Again, the answer to managing the question of risk responsibility is to build discussion, planning and action, on this into the project planning and operational activity. CJ Williams is a tutor and management consultant currently working with Brighton School of Business and Management in the UK, specialising in Business and Management courses taught via distance learning. The writer, CJ Williams, can be contacted or via Brighton School of Business and Management

Reducing Risk and Increasing the Probability of Project Success

IT Software Development Just Isn't Working!
Get the PDF Version By Cliff Murphy

IT systems are at the heart of modern business and the development of new software applications and maintenance of existing systems are critical to productivity and profitability. Advances in software technology over the last 20 years have allowed progressively more complex business solutions to be created enabling companies to offer their customers exciting new services and products. And yet, software development projects still suffer from similar problems and characteristics, regardless of the technologies being used, that they suffered from more than ten years ago. A report from the Standish Group clearly shows that the reliability of delivery of IT software applications has not improved over the years. Figure 1 is for 2001 and this looks remarkably similar to a diagram from the same source in the early 1990's.

Figure 1: Software Projects The important question that needs to be addressed is why is software development so risky?

Change Is Inevitable
All software projects implicitly have associated risks. One of the major sources of risk results from changes that occur during the project's lifecycle. In its most common form, this is seen as changing user requirements. It is, however, not just confined to this area. For example the following changes all present real risk to projects: 1. Changes to the makeup of the project team or in stakeholders 2. Changes in the technology being used 3. Changes to any external systems with which the new software must work How you deal with changes to the project is the key to reducing your development risks, and to increasing the overall chances of success of your project. But what is the best way to do this? The major influence lies in the development process you choose and not the technologies being used.

Picking The Right Process
As a project manager you may be tempted to try and eliminate change in your project through a rigid policy of no change. This is the case for waterfall processes where the major assumption is that development can proceed in an orderly, linear and predictable fashion. Waterfall processes have a clearly defined sequence of stages, each of which must be completed and signed off before progressing to the next stage. For example Requirements (capturing) is completed before Analysis is started. Design cannot then be started until Analysis is complete and signed off...and so on. Figure 2 shows the typical lifecycle of a waterfall development process.

Change will inevitably occur during the project lifecycle. Figure 3: Coping with Change The result is that changes often need to be made to the system during the later project stages such as integration (when the different modules of software code are assembled into one application system) and the testing of the system proper.Figure 2: Waterfall Development Lifecycle Waterfall processes may appear at first glance to be a reasonable and common sense approach. waterfall processes have a late feedback cycle for the part that really counts. Imagine having to write off a . As we see in figure 3. The result is that this approach to developing software almost always fails to mitigate risk. Worse still. By adopting a rigid sign off strategy for each activity in the project. The problem is that developing software is inherently unpredictable and this type of process does not cope effectively with change. you may all too often be lulled into to a false sense of security as the project progresses. with this type of process. it is all too easy to believe that the project is getting easier and risk is reducing as you get nearer to the go live date. and not the signed off paperwork. and this is usually the result of feedback. the actual software code.

They also recognise that the best mechanism for achieving successful delivery is to contain and mitigate risk by means of the regular and . How will my system communicate with system A? 2. after having already spent 95 man-years of the budget. By assuming that the development lifecycle will be predictable. This is a fools paradise! The Waterfall process is the wrong approach for software development. A Lower Risk Approach . and that a reliable completion date can be derived from this. such as: 1.Iterative Development Project risks are associated with the unknown.. organisational or business oriented in nature. you are admitting that a high degree of risk cannot exist within a project. is inappropriate for software development. as shown in figure 4.. because of a fundamental misunderstanding in the user's requirements! The risk profile for waterfall processes. These can be technical. Adaptive software development processes realise that producing software is a risky business and highly unpredictable in nature. How do I manage my offshore development group? 3. Do the system requirements actually reflect the true needs of the users? 4.100 man-year project. etc. Figure 4: Waterfall Risk Profile The fundamental problem with waterfall processes is that they rely on the assumption that the progress of a software project can be predicted with reasonable accuracy from the outset.

The reason why. We recognised that there was a major risk that we might not be able to meet these performance objectives. One of the users' requirements meant that the system had to process one million financial trades within an eight hour window. A high level of communication between all project team members 4. A highly skilled development team 5. The adoption of an Iterative Risk Driven Approach 2. is that it forces the team to address the most important aspects of functionality and to resolve high risk issues at an early stage.controlled delivery of testable software code to provide a reality check on progress and to give feedback to the users throughout the entire lifecycle of the project. The adoption of a Use Case driven approach 6. . so we built a basic working system within three weeks and provided critical feedback to the users that we could only achieve 10% of the performance required. Key Principles There is no single overriding rule that guarantees project success but the following key principles will greatly increase your chances: 1.the users reassessed their objectives and realised that a lower processing target was indeed adequate. Figure 5 provides a comparison of typical risk profiles between iterative and waterfall development lifecycles. The commitment and involvement of senior management 3. The adoption of a comprehensive and rigorous system of change control 7. The use of Visual modelling Iterative Risk Driven Approach This will reduce risks by developing small pieces of the system over a short timeframe (a maximum of four weeks for large projects). A real example of how an iterative approach reduces risk occurred in 2001 when I was working on developing an application to monitor financial transactions. At the end of each development cycle. The iterative cycle continuously mitigates risk from the early project stages as a result of regular feedback from users. the software should be demonstrated to the users to obtain feedback on its functionality and suitability. This major risk was thus mitigated within the first three weeks of the project. The client was adamant that this was a key requirement and that the application must be capable of running on low cost hardware. An iterative approach will continuously reduce project risk from the outset. Result .

Without everybody working together you haven't got a team and the project will fail. however. This has to be on a regular basis. then invest in training focused on meeting your project's needs. and at least weekly with the users and sponsors. It is important to ensure you have full executive support for any type of process change.not just verbal. Iterative development will greatly increase communication with the users. and includes producing good documentation. Highly Skilled Development Team A highly skilled group of individuals that understands how to work together should form the nucleus of your team. High Level of Communication . Use Case Driven Approach . waste time and money with off-the-shelf 'one size fits all' training courses.Figure 5: Risk Profile Comparison Between Iterative and Waterfall Processes Senior Management Commitment Changing the way people work is probably the hardest thing to do in any business and when it involves technologists it can be an even harder challenge. Do not. daily with the team. Aim to keep documentation lightweight by adopting a 'just enough' policy. They will be very efficient and productive. You will need backup to drive through changes in the early stages .Keep Talking! First and foremost projects are about people. Consider supporting your project team with expert mentors to assist and accelerate process adoption. Use visual modelling (key principle) whenever possible to raise the level of communication.but once the process starts working. Communication comes in many forms . Communication is paramount within the team and more importantly with your users and sponsors. people will naturally want to be associated with it. If you haven't already got the right mix of skills (technical and process). Your end goal should be to make all these groups part of the project team.

So many times I have seen documents that purport to contain the complete system requirements. You will come across the same situations. Simplicity is the key strength of use cases. so how do you know if your IT group is really doing risk based iterative development? Ask a few telling questions: How long is an iteration? The answer should be anywhere from a few days to a maximum of about four weeks. Answers of three months or more should indicate the process is still waterfall with long feedback cycles with the associated high risk of getting it badly wrong before being able to rectify the situation. when in fact they are just a set of business rules and a list of user needs. during which they will have the opportunity to provide feedback.Use Cases are highly effective because they provide a contextual representation of the system requirements. or that a further system release should be considered? Visual Modelling . If the answer is documents for sign-off. Change Control This is very different from stopping change from occurring to your project. There is no excuse for not using it. does a new request mean that an existing requirement has to be removed from the live release. The UML (Unified Modelling Language) is the de facto standard for the visual modelling of systems and should be used to communicate consistently and concisely across the project. Are You Really Risk Focused? I have worked with many clients and spoken to senior managers and technical specialists who swear that they are risk focused and follow an iterative approach. One of the main reasons why they should be used is that they are non-technical in nature and provide a written step by step description of how the actors (system users . They bind together the whole development process from the capturing of user requirements through to the testing of the application software. .human or otherwise) shall interact with the system. you need objectives and goals to aim for.'A picture is worth a thousand words' Visual modelling is the modern equivalent of the "flowcharts" used in the early days of software production. The value of visual aids remains valid and diagrams should be used throughout the project. To drive a project forward. if the delivery date is fixed. Demand that all roles use the same modelling notation. For example. and Use Cases are the best way do this. then they are missing the point. What is delivered at the end of each iteration? The answer should be a demonstration of some actual working software to the users. Instead the emphasis is on the careful consideration of new requests and deciding (with the users) how these should be accommodated. from business analysts to designer and coders through to testers.

available for inspection by all people associated with the project. quantified in terms of probability and impact to the development schedule along with proposed mitigation strategies. When do you intend to start integration testing? The answer should be that integration testing is a continuous activity that occurs during each iteration. . with the focus on developing systems that deliver what the users actually want. when the system enters the support and maintenance phase of it lifecycle. will usually produce systems that are of a higher build quality and are 'fit for purpose'. But the greatest costs occur long after the initial development is over. This typically results in systems that are easier to maintain and revise and thereby reduce the long term operational costs and associated risks. The project manager should maintain a running risk list.When do you the users see what they are going to get? The answer should be at the end of every (short) iteration. How do you manage risk? The answer should be that there is a regular assessment of risk. effort and money. Figure 6: Software Cost Breakdown Adopting these good practices. An answer of "only during acceptance testing prior to delivery" is just not acceptable. as shown in diagram 6. Longer Term Business Continuity So if I adopt all these good practices what does this really mean to my business? We know that software development is a highly risky business that costs a lot of time.

They are based on personal experiences of the author who has been involved in projects for over 15 years. especially if he (usually it is a man) looks like a battered army veteran who has been in the trenches for the last two decades. This requires an open mind set that focuses on future scenarios that may occur. you can not reap the full benefits of this approach. This article gives you the 10 golden rules to apply risk management successfully in your project. Some people blindly trust the project manager. on budget and with the quality results your project sponsor demands. Two main sources exist to identify risks. Also the big pile of literature available on the subject has been condensed in this article. Some projects use no approach whatsoever to risk management. They are either ignorant. The result will be that you minimise the impact of project threats and seize the opportunities that occur. Rule 1: Make Risk Management Part of Your Project The first rule is essential to the success of project risk management. people and paper. Also your team members will be much happier if they do not enter a "fire fighting" mode needed to repair the failures that could have been prevented. If you don't truly embed risk management in your project.Cliff Murphy is a founder and director of Liemur Limited Liemur is a UK based company providing a range of specialised services to optimise software development and maximise business return on investment in IT. running their first project or they are somehow confident that no risks will occur in their project (which of course will happen). Copyright: Liemur Limited 10 Golden Rules of Project Risk Management Get the PDF Version By Bart Jutte The benefits of risk management in projects are huge. People are your team members . This allows you to deliver your project on time. Professional companies make risk management part of their day to day operations and include it in project meetings and the training of staff. You can encounter a number of faulty approaches in companies. Rule 2: Identify Risks Early in Your Project The first step in project risk management is to identify the risks that are present in your project. You can gain a lot of money if you deal with uncertain project events in a proactive manner.

Focus your communication efforts on the big risks here and make sure you don't surprise the boss or the customer! Also take care that the sponsor makes decisions on the top risks. the project opportunities. even if it is only half an hour. business case and resource planning are good starters. If you deal with them properly. However if you combine a number of different identification methods. This shows risks are important to the project manager and gives team members a "natural moment" to discuss them and report new ones. being overloaded with work that needs to be done quickly.that each bring along their personal experiences and expertise. Projects tend to generate a significant number of (electronic) documents that contain project risks. This creates project dynamics where only negative risks matter (if the team considers any risks at all). Are you able to identify all project risks before they occur? Probably not. you are likely to find the large majority. your company Intranet and specialised websites. Rule 3: Communicate About Risks Failed projects show that project managers in such projects were frequently unaware of the big hammer that was about to hit them. because usually some of them exceed the mandate of the project manager. make project risks part of the default agenda (and not the final item on the list!). Interviews and team sessions (risk brainstorming) are the common methods to discover the risks people know. you better pay attention to risk communication. They may not always have that name. The project plan. Chances are that you see a couple of opportunities with a high pay-off that don't require a big investment in time or resources. you have enough time left for the unexpected risks that take place. Unfortunately. These are the uncertain events that beneficial to your project and organisation. Other people to talk to are experts outside your project that have a track record with the type of project or work you are facing. However modern risk approaches also focus on positive risks. better and more profitable. Paper is a different story. . but someone who reads carefully (between the lines) will find them. They can reveal some booby traps you will encounter or some golden opportunities that may not have crossed your mind. Another important line of communication is that of the project manager and project sponsor or principal. Another categories are old project plans. If you have a team meeting. A good approach is to consistently include risk communication in the tasks you carry out. These "good guys" make your project faster. but didn't inform the project manager of its existence. If you don't want this to happen in your project. lots of project teams struggle to cross the finish line. Make sure you create some time to deal with the opportunities in your project. The frightening finding was that frequently someone of the project organisation actually did see that hammer. Rule 4: Consider Both Threats and Opportunities Project risks have a negative connotation: they are the "bad guys" that can harm your project.

use it consistently and focus on the big risks. The next step is to make clear who is responsible for what risk! Someone has to feel the heat if a risk is not taken care of properly. The other risks can be prioritised on gut feeling or. If you want to understand a risk at an individual level it is most fruitful to think about the effects that it has and the causes that can make it happen. If a project threat occurs. is to focus on the events that precede a risk occurrence. someone has to pay the bill. Another angle to look at risks. on a set of criteria. An important side effect of clarifying the ownership of risk effects. it becomes important who bears the consequences and has to empty his wallet. departments and suppliers are involved in your project. The trick is simple: assign a risk owner for each risk that you have found.Rule 5: Clarify Ownership Issues Some project managers think they are done once they have created a list with risks. Therefore take some time to have a closer look at individual risks and don't jump to conclusions without knowing what a risk is about. is that line managers start to pay attention to a project. List the different causes and the circumstances that decrease or increase the likelihood. Fights over (unexpected) revenues can become a long-term pastime of management." This makes project life really simple. you can describe what effects take place immediately after a risk occurs and what effects happen as a result of the primary effects or because time elapses. it doesn't deliver the best results possible. Each project manager needs to answer the usual questions about the total budget needed or the date the project will . Some risks have a higher impact than others. Looking at the effects. Check if you have any showstoppers in your project that could derail your project. Rule 6: Prioritise Risks A project manager once told me "I treat all risks equally. The risk owner is the person in your team that has the responsibility to optimise this risk for the project. Risk analysis occurs at different levels. the risk causes. more objectively. but it is an issue you have to address before a risk occurs. At first people usually feel uncomfortable that they are actually responsible for certain risks. The ownership issue is equally important with project opportunities. The effects are really positive. Rule 7: Analyse Risks Understanding the nature of a risk is a precondition for a good response. This sounds logical. If so. lead time or product quality. Ownership also exists on another level. these are your number 1 priority. However. Whatever prioritisation measure you use. Another level of risk analysis is investigate the entire project. Especially if different business units. Therefore. The criteria most project teams use is to consider the effects of a risk and the likelihood that it will occur. but as time passes they will act and carry out tasks to decrease threats and enhance opportunities. However this is only a starting point. especially when a lot of money is at stake. you better spend your time on the risks that can cause the biggest losses and gains. A more detailed analysis may show the order of magnitude effect in a certain effect category like costs.

Spending more money on a doomed project is a bad investment. Rule 8: Plan and Implement Risk Responses Implementing a risk response is the activity that actually adds value to your project. A final response is to accept a risk. It is also a perfect communication tool that informs your team members and stakeholders what is going on (rule 3). If you have carried out rule 7 properly (risk analysis) you will have plenty of opportunities to influence it. maximising them or ignoring them (if opportunities prove to be too small). risk avoidance. This will help you to make a sound risk response plan that focuses on the big wins. This could mean changing supplier or adopting a different technology or. Doing projects is taking risks. especially if the number of risks is large. time consuming or relatively expensive. Rule 9: Register Project Risks This rule is about bookkeeping (however don't stop reading). You can try to prevent a risk occurring by influencing the causes or decreasing the negative effects that could result. The biggest category of responses are the ones to minimise risks. However the reverse is true. If you record project risks and the effective responses you have implemented. Most project managers aren't really fond of administrative tasks. risk minimisation and risk acceptance. Just make sure that it is a conscious choice to accept a certain risk. clarifies ownership issues (rule 5) and enables you to carry our some basic analyses with regard to causes and effects (rule 7). Even if a risk happens that derails the project. prioritise and understand risks. Responses for risk opportunities are the reverse of the ones for threats. Some project managers don't want to record risks. you can do a simulation to show your project sponsor how likely it is that you finish on a given date or within a certain time frame. terminating a project. The information you gather in a risk analysis will provide valuable insights in your project and the necessary input to find effective responses to optimise the risks. You prevent a threat occurring or minimise negative effects. The other rules have helped you to map. A good risk log contains risks descriptions. Maintaining a risk log enables you to view progress and make sure that you won't forget a risk or two.finish. They will focus on seeking risks. Avoiding risks means you organise your project in such a way that you don't encounter a risk anymore. because they feel this makes it easier to blame them in case things go wrong. A similar exercise can be done for project costs. you create a track record that no one can deny. but doing your bookkeeping with regards to risks pays off. Execution is key here. If you deal with threats you basically have three options. Rule 10: Track Risks and Associated Tasks . This is a good choice if the effects on the project are minimal or the possibilities to influence it prove to be very difficult. If you take risks into account. if you deal with a fatal risk.

The project manager has to . Which risks are more likely to happen? Has the relative importance of risks changed? Answering this questions will help to pay attention to the risks that matter most for your project value.The risk register you have created as a result of rule 9. training and sells its own easy to use risk management software. Integrating risk tasks into that daily routine is the easiest solution. PMP 26 Sep 2010 Risk management is the heart and soul of project management. select and implement responses. etc. The Seven Deadly Sins of Risk Management Get the PDF Version By Kareem Shaker. These are seven deadly sins of risk management and how to take preventive actions to avoid them. Tracking risks differs from tracking tasks. Therefore rule number 11 would be to use the Japanese Kaizen approach: measure the effects of your risk management efforts and continuously implement improvements to make it even better. such as operational. The 10 golden risk rules above give you guidelines on how to implement risk management successfully in your project. strategic. Success with your project! Bart Jutte is a founder and consultant at Concilio. a NL based company specialising in project risk management. planning alone is not enough if monitoring risks is not handled seriously. 1. financial. Risk tasks may be carried out to identify or analyse risks or to generate. and methodologies an organisation uses to identify and manage enterprise risks of all types. compliance. frameworks. Failing to practice it right can have fatal consequences on projects and programmes. However. Tracking tasks is a day-to-day job for each project manager. Concilio offers consultancy. Disregarding Enterprise Risk Management Enterprise Risk Management (aka ERM) specifies the processes. keep in mind that you can always improve. will help you to track risks and their associated tasks. However. It focuses on the current situation of risks. Doing real effort in the planning stage can save the entire investment and will increase the likelihood of project success. A free demo is available at ProjectFuture.

as it keeps the views of different subject matter experts anonymous. Different people will perceive risks in different ways. RBS can be developed by listing all the root causes of potential risks. The project manager can start with a template from a known body and customise it based on previous project history and project-specific risk categories. Using Incomplete Risk Breakdown Structure Risk Breakdown Structure (RBS) is the catalyst to identify large numbers of risks. It is important to mediate these conflicts during risk identification. and the rest is sort of "Just Do It!" There are different information gathering techniques to solicit stakeholders' input. even after finishing the identification phase. since the ERM governance can impose certain documents to be delivered. fearing that they may be responsible for the risks they will be identifying. Consulting the Chief Risk Officer (CRO) before and while building the risk management plan can have a mammoth impact on the way the project management plan will be developed. The risk identification process is substantial for successful risk management. Project Management Institute refers to those as Enterprise Environmental Factors (EEF). The project manager has to follow up on the status of assigned risks. Potential risk owners may be reluctant during risk identification stage. The project manager should not be the only individual who owns risks. Creating a risk management RACI Matrix (Responsible. 3. and a technical risk is very unlikely to be deemed as a risk by a financial manager. Every industry has its own associated risks. RBS highly depends on the project domain. and the risk owner has to report risk status updates on a frequent basis. For instance. Accountable. Risk management teams use it to identify risks and stimulate the minds of the stakeholders who will be participating in the risk identification stage. You will find that risk averse stakeholders will identify large numbers of risks. It is the responsibility of the risk management team to remove subjectivity and ensure quality of risk information. customers.consider the enterprise-wide risks and study what threats the organisation is likely to encounter during the projects' lifetime. 2. I believe that identifying risks will always get 60% of the job done. 4. risk takers may be oblivious to real risks. Risks that are valid to a software project may not be applicable to a construction project. Subjectivity can be avoided by using the Delphi Technique. in contrast. The project risk management has to be congruent with ERM. probability/impact scales. stakeholders. Assigning All The Risks to The Project Manager Successful risk management can never be a one-man army. The perpetual problem of risk management information is subjectivity. . Ignoring Subjectivity Subjectivity can make risk management lose its essence. The risk management team has to set clear expectations and inform subject matter experts. and risk management software to be used. a financial risk may not grab a technical manager's attention. team members of what is expected from them. risk appetite. The ownership of risks has to be communicated to the risk owners.

The project manager should elevate the culture of risk management and ask team members to report new risks. Transfer. It would be great if you can share your experience and articulate what could be a sin in risk management from your perspective and how to avoid it. if the loss value is much smaller than the benefit gained. and second is due to unfavourable benefit cost Project Risk: Is It All Bad? Get the PDF Version By Paul Slater . Misusing Contingency Reserve Contingency reserve can only be determined after the project manager has had multiple revisions of the project management plan.KareemShaker. The unplanned risk can only be handled by the management reserve. nor is it right to stop looking for new risks during the execution phase. and shelve risks until they turn into issues. otherwise you would be paying $100 to save a $60 risk. Response strategies of negative risks (yes. Kareem Shaker. The new risks have to go through the process of analysis and response strategy planning. 7. due to implementing a control. Read his blog atwww. Neglecting Risk Management Benefit Cost Analysis Not all risks have to be managed. These are the seven deadly sins of project risk management as I could identify them. and Accept. unless the latter has already become void. Risks have to be accepted for two main reasons. It is not right to do it during the planning stage only. and pre-sales. first is unfeasibility of the first three response strategies. some risks just need to be accepted. consulting. he has over 10 years of experience in IT projects. PMP is a project manager at Dubai World. but oftentimes the acceptance strategy is never considered. Doing it Once Risk management is an iterative process and should be practiced in all project stages. Mitigate. Many project managers conduct risk identification at the beginning of the project. Contingency reserve should only be used when a planned risk (aka known unknown) materialises. It is also important to put risk management on the agenda of frequent progress and status update meetings. The project manager has to visit the reserve balance and make sure that no risk will have no contingency. It is also not right to use the contingency quota of one risk at the expense of another risk. those are known as opportunities) are Avoid. 5. it would be rational to accept the risk. For instance. 6. The contingency reserve should not be used for any unplanned risk (unknown unknown).Consulted. there are positive risks. Informed) will ensure roles and responsibilities are clearly identified and communicated. from inception to closure.

When this happens. think about it. Make sure you identify the one true risk and record it and track it within the correct project. but the risk processes of large complex programmes are applied. Where it can and does go wrong is when there is an over-reliance on the risk aspects of the project and they in themselves start driving the way the project moves forward. but is not the be all and end all of it as it sometimes becomes in more risk averse organisational cultures. and telecommunications and running for a number of years it is entirely appropriate to have a risk set-up that matches that complexity. but make sure you don't start double or triple scoring the same risk. the risk process starts to drive the programme and stops providing a benefit. make them aware of it. complex programmes covering numerous disciplines. say construction. If other projects or a higher level programme need to be aware of it that is fine. More Risks Recorded. Even with sophisticated risk software the potential for confusion is great with different scores being applied to probabilities and impacts. The more risks you identify and manage within a project the greater the chance the project might not come in on time. it's . Matches and is appropriate. There may well be a Risk Manager and team to assist that individual in collating the requisite management information. Appropriate Monitoring and Mitigation The most important aspect here is the word 'appropriate'.30 Jan 2010 No one would disagree that managing risk within a project is not a good idea. The management of risk is part and parcel of project management. Record Once not in Multiple Related Projects Far too often the same risks are identified across multiple related projects or within a programme of projects. For large. The difficulties arise however when the scale of programme or project is much reduced. The reason for this? Well. To help understand how risk within projects can be better managed it is worth considering a number of aspects of the risk identification and mitigation processes involved. the Longer the Project will Take Strange but true. Risk Management is an essential part of any programme or project and can vastly contribute to successful delivery. a set-up that identifies risks in the disparate areas of the programme and allows judgments to be made across the programme as a whole. software.

You aren't ignoring the risk you are making a conscious decision to accept that it may happen. As a leadership coach. but it's how far you go that really matters. it starts to make that risk review meeting far more meaningful. he works with individuals and organisations to bring out the potential inherent in people. But. advising businesses and organisations on how best to employ project management techniques to improve project delivery. Opportunities Arise Risks happen in any project and some may have been predicted and planned for while others may not have been. Putting in place some form of mitigation may be necessary and add cost to the budget. that's what everyone accepts as the truth. Having said this there could well be risks that you decide simply to accept as they are because either the probability of them occurring is so low and/or the cost of putting in place some mitigation is so high. never an easy decision for anyone.very easy to identify lots of risks for any project. The project is the project with its set requirements. make sure you have the important risks identified and managed and keep reviewing to ensure your list is up-to-date. So. So. are all risks bad? Of course not. the ultimate might mean cancelling the project altogether. You can follow Paul on Twitter @Mushcado The Principles of Risk Management Get the PDF Version By Simon Buehring . but that's just the way it is. Get right down 'in the weeds' and you will still have to identify risk owners and people to investigate mitigation strategies etc. but just remember to think about them as you go through the risks. etc. All this takes valuable time and effort away from the main job of project delivery itself. Opportunities can be anywhere within a project space. Paul Slater owns and runs Mushcado Consulting in the UK. what if a risk occurs which starts to make you think seriously about the validity of the project or the direction in which it's going? When reviewing the project risks and looking at those that have occurred ask yourself the question "Does this project still need to go in this direction or should we consider altering it?" Of course. Accept the Risk as is Once you have identified your set of appropriate risks for your project you need to decide what to do about each and every one of them. Make sure you are managing the risks that are appropriate to the project and make related programmes and projects aware of them and you are most of the way there.

which are intended "not . social. Understanding how to identify and treat risks to an organisation. "appropriate" concerns: the identity and role of the stakeholder. programme managers and risk managers need to consider the specific context of the organisation in order to ensure thorough identification of risks and appropriate risk treatment procedures. be made aware of risks to a project or programme. and the type.21 Jul 2009 Every project manager and business leader needs to be aware of the practices and principles of effective risk management. probability and potential impact of the risk. legal and environmental backdrop of an organisation. Rain is a negative risk for a picnic. to be prescriptive but [to] provide supportive guidance to enable organisations to develop their own policies. short-term projects and businesswide change programmes. Within the context and stakeholder involvement. . economic.. Project managers. the level of influence that the stakeholder has over and outside of the organisation. the level of investment that the stakeholder has in the organisation. Stakeholder Involvement It is easy for a management team to become internalised and forget that stakeholders are also key participants in everyday business procedures. technological. Understanding the roles of individual stakeholders and managing stakeholder involvement is crucial to successful.. a positive risk for drought-ridden farmland and a non-risk for the occupants of a submarine. is that all organisations are different. The term 'organisational context' encompasses the political. The OGC M_o_R (Management of Risk) framework identifies twelve principles. Stakeholders should. and will prepare managers and team members for any unavoidable incidences or issues. Organisational Objectives Risks exist only in relation to the activities and objectives of an organisation. as far as is appropriate. a programme or a project can save unnecessary difficulties later on." Organisational Context A fundamental principle of all generic management methods. including PRINCE2 and MSP as well as M_o_R. strategies and plan. processes.

. Support Structure A support structure is the provision within an organisation of standardised guidelines. strategies and plans within the M_o_R framework provide generic guidelines and templates within a particular organisation. Reporting Accurately and clearly representing data. This can include a centralised risk management team. This establishes the regular review of identified risks and ensures that risk managers remain sensitive to new risks. managers and stakeholders. the project/programme manager or a specialist risk manager) understands the objectives of the organisation. content and participants of risk communication. Roles and Responsibilities Fundamental to risk management best practice is the clear definition of risk management roles and responsibilities. This is important both in terms of organisational governance. however. Individual functions and accountability must be transparent. in order to ensure a tailored approach. Following best practices ensures that individuals involved in managing the risks associated with an organisation's activity are able to learn from the mistakes.It is imperative that the individual responsible for risk management (whether that is the business leader. policies. Review Cycle Related to the need for early warning indicators is the review cycle. These guidelines are based on the experience and research of professional risk managers from a wide range of organisations and management backgrounds. experiments and lessons of others. The M_o_R methodology provides standard templates and tested structures for managing the frequency. M_o_R Approach The processes. Early Warning Indicators Risk identification is an essential first step for removing or alleviating risks. and to ensure that all the necessary responsibilities are covered by appropriate individuals. both within and outside an organisation. This enables the most thorough and prepared approach to handling the situation. it is not possible to remove risks in advance. training and funding for individuals managing risks that may arise in any specific area or project. information. Early warning indicators are predefined and quantified triggers that alert individuals responsible for risk management that an identified risk is imminent. In some cases. and to the effectiveness of current policies. and the transmission of this data to the appropriate staff members. is crucial to successful risk management. a standard risk management approach and best-practice guidelines for reporting and reviewing organisational risks.

At a practical level. this will require the nomination of an individual or a group of individuals to the responsibility of ensuring that risk management policies and procedures are up-to-date. A supportive risk management culture will also include evaluation and reward of risk management competencies for the appropriate individuals. Common issues include: • • • • • Established roles. as well as the establishment of regular review cycles of the organisation's risk management approach. He works for KnowledgeTrain which offers management of risk training in the UK and overseas. A supportive culture is essential for ensuring that everybody with risk management responsibilities feels confident raising. Supportive Culture Risk management underpins many different areas and aspects of an organisation's activity. Risk management orientation. An effective risk management policy includes the capacity for re-evaluation and improvement. accountabilities and ownership. Simon Buehring is a project manager. induction and training processes. discussing and managing risks. responsibilities.Overcoming Barriers to M_o_R Any successful strategy requires thoughtful consideration of possible barriers to implementation. Regular assessment of M_o_R approach (including all of the above issues. Adequate and accessible training. He can be contacted via the M_o_R Practitioner training website. Is Software Development Risk Costing You Money? Get the PDF Version By ExecutiveBrief . consultant and trainer. Continual Improvement In an evolving organisation. nothing stands still. tools and techniques. An appropriate budget for embedding approach and carrying out activities.

" meaning that they were completed and operational. exceed allotted costs. only about one-third (35 percent) of the researched software development projects undertaken in the previous two years were considered "successful. Because market forces today are continually changing. the more likely it will be that the software will fail to meet the current needs of users. budget. and production. • Time. Poor communication. they met all requirements and were completed on time and within budget. Requirements and priorities can change multiple times as projects progress through planning. or schedule. 41 cents of every dollar spent on software development was considered wasted. And 19 percent were considered outright failures or cancelled prior to completion. went over budget. Almost half (46 percent) were reported to be "challenged. Anyone involved with software development projects knows why bringing them to successful completion can be so difficult to achieve. but were delivered late. cost overruns or even outright failure of the project. The legendary communication gap between developers and business clients or stakeholders often leads to poorly defined requirements. A project whose scope is too broad will become too complex. Software development projects are plagued with risk and impending failure. and ultimately fail. or did not support all of the features originally required. According to the same report. and intense market competition lead to scope creep. where requirements are frequently changed and added to the project without a proper evaluation of their true importance and without corresponding increases in resources. How can your company avoid this industrywide problem? In our brief you'll learn best practices for successfully completing software projects.Poor software project management often means missed deadlines. According to The Standish Group's 2006CHAOS Report. A . and at such a fast pace. the longer a development project takes to get off the ground and cycle through to completion. time creep. which in turn will lead to inadequately designed software that doesn't provide the functionality needed by the customer. • Scope. The most frequently cited factors that contribute to the challenge include: • Poor communication. development. overrun schedule." that is. testing.

and schedule. considered by many to be the project management bible.S. "Risk can be defined as uncertainty that matters. when they happen. Success for any IT project. A study by the SEI in 2005 found that. Software Engineering Institute's (SEI's) Capability Maturity Model Integration (CMMI).project whose scope has been defined too narrowly may finish on time. a well-known global consulting firm specialising in project risk management." says David Hillson. risk was defined almost exclusively in negative terms. particularly in software development. Step #1: Identify Identification of project risks is usually accomplished via a brainstorming session that includes the development team and the stakeholders. when it came to the quality of their development processes. both early on in the project and throughout its lifespan. the PMBOK Guide has its legions of followers as well as its fervent detractors. The most widely known is probably the one detailed in A Guide to the Project Management Body of Knowledge (PMBOK Guide) published by the Project Management Institute (PMI). but in the past seven years or so. Including stakeholders in this process is essential for fostering good communication and gaining a true understanding of the business risks associated with the project. opening up possibilities that seemed impossible at first. such as the U. many development departments don't follow a coherent development methodology. and limited time." There is more than one approach to risk management. is very much dependent on effective management of risks. • Budget. but likely will fail to perform according to customers' real requirements. A company could discover reusable code that it didn't know it had. resources." For example. can damage a project. Despite the availability of established best practices in software development. "You can either rely on good luck or be proactive and seek out those opportunities. • Unorganised development processes. risk management philosophy has expanded to include unexpected opportunities. "Uncertainties. But most approaches to risk management follow steps similar to those outlined below. but some uncertainties can help. Certain parts of a project could finish early. For example. inadequate resources. almost 40 percent of companies gave themselves a low rating of 1 or 2 out of a possible 5 on the CMMI scale. Not long ago. . Software development is rife with unrealistically low budgets. and alternative methodologies abound. Like any religious text. new hires can bring new expertise that takes a project in a positive new direction. the company's financial calendar may influence when certain accounting or other financial-related systems must be in place. director of Risk Doctor and Partners. • Risk.

• Minimise it. Certain risks can kill a project all by themselves. but missing the real substance. "The whole idea of this process is to be innovative and think outside the box." says Gartner analyst Donna Fitzgerald. and authority to make decisions for their part of the project. availability. if there's a risk that a certain supplier will deliver an essential item too late to meet your deadline. even if the probability of such risks is low. "No one person should be so indispensable that losing this resource would mean a significant delay for the . For example. many of the risks analysed will stem from the factors outlined above (i. It's also helpful to generate and repurpose checklists of risks from similar past projects to help map out risks for the current one. they should be assigned a high priority.e. free-for-all discussion. Real risk management is about exceptions to the normal day job. This is also a good time to map out specific early warning signs for each of these risks. it may be possible to use a different supplier." Fitzgerald points out that company politics play a big role in project risk and that risk mitigation often entails measures that lie outside the original project. Another useful tool for gauging internal and external treats and opportunities is the SWOT (strengths. bringing in team members who have the expertise to take over a key task if other members quit. hierarchical fashion." Step #2: Quantify and Prioritise Once the identified risks are mapped out. "They end up filling out the forms. and threats) analysis. "My problem with this process is that people often go through the steps without any real thinking. These factors should not be ignored. Risks that have low impact and low probability often can be ignored. weaknesses. Hillson agrees. time. opportunities. Some of the classic strategies include: • Avoid it. scope). The first is to avoid an unfocused. In the case of software development. "The meeting really must be facilitated and structured. or nurturing a positive relationship with people outside of the team whose co-operation is essential for success. Some ways to minimise risks include lining up contingency plans and funding. Risk experts cite two principles for the success of this step." says Hillson. Sometimes it's possible to find a strategy for avoiding a risk completely. the team should prioritise them based on probability and expected impact. The PMBOK Guide includes a risk breakdown structure (RBS) that can help the team to map out risks in a very detailed. The second principle for success in the identification step is to ensure that the meeting doesn't become an empty exercise done solely to comply with company policy. communications.Including stakeholder representatives is also a great way to gauge their skills. Step #3: Address The next step is to develop strategies for addressing each risk.

and what would you do differently next time? Record this information and use it to create checklists that can be referenced during your next initiative." says Fitzgerald. persistent disagreements about what should be done. In one of her projects.000 to the budget in order to hire a consultant who could take over if an unhappy critical team member quit. Fitzgerald had to add $80. including a high number of unresolved issues. Consider Agile Development Techniques In recent years. Sometimes you can hand over responsibility for certain risks to a vendor.project. there's an off-org chart network of people who get things done. Any of these circumstances may indicate a need to reassess your entire risk management and project implementation strategy. assess progress in addressing identified risks. Which strategies worked. Again. "In every organisation." says Fitzgerald. and communication. "Build your team so that you are tied into that network from the start. Frequent risk reviews should be conducted to continually monitor for early warning signs of risks. it may not be worth addressing the risk at all. or even a stakeholder. Conduct an end-to-end evaluation of the project. and discover new risks that have cropped up. from conception to delivery. and early slippage in the schedule. Step #5: Record Post-mortem reviews can be extremely valuable in planning for successful future projects. • Transfer it. agile development has risen in popularity as a way to minimise risks related to time. Ongoing communication with stakeholders about a project's progress and shifting risk profile is important as well. This is also the time to assess whether the project may be in real trouble. an outside consultant. it's always a good idea to keep records of successful strategies from past projects that could be useful for addressing the risks of a current one. • Accept it. agile development methods promote development of one small complete . Compare the risks that you originally identified with the real risks that you ultimately needed to address. This is also the time to assign each risk to an owner who will be responsible for detecting and addressing it. scope. which didn't. Step #4: Monitor Murphy's Law reigns in just about every project. close out some risks. Rather than undertaking massive software projects in their entirety." Fitzgerald also points out the importance of putting together a team of people who are known to be flexible and eager to adjust to new circumstances. If the impact and probability are minimal. Fitzgerald points out some key early warning signs.

processes and tools ." ExecutiveBrief." Get Real A structured risk-management process is vital to success. Negligible to Catastrophic Get the PDF Version By ExecutiveBrief Risks your project or business is exposed to may be worth reviewing now more than ever to see which ones need more attention than others. "A small project probably requires a light touch. detailed approach to managing risk. however. it is important to be able to ." On the other hand. perhaps an hour-long meeting every couple of © ExecutiveBrief 2008 Ranking Risks: Rare to Certain.the keys to improving their business performance. when the state of affairs changes. To learn more." says Hillson. In everyday usage. which is why projects that last longer than six months have a very high failure rate. and get something done in less than six months. but it's also important to align the structure to the size and type of project and to your company philosophy. techniques." says Fitzgerald. Perhaps more important. risk is often used synonymously with the probability of a known loss.piece at a time. a large project at a large company with many players and stakeholders very well could require a highly structured. and action plans that companies can use to better manage people. do something else. "Software is evolutionary by nature. Since risk is directly correlated to loss. Then. the technology management resource for business leaders. "Your risk process should be scalable. is to cultivate an organisational culture in which everyone understands and lives the concepts of risk management instinctively. please visit: http://www. Fitzgerald offers this suggestion: "Your company should adopt an attitude that likens risk management to breathing. Risk is measured in terms of impact and likelihood. "Get in. Risk is a concept that denotes a potential negative impact to an asset or some characteristic of value that may arise from some present process or future event.executivebrief. offers proven tips.

On the Y (vertical) axis is the "probability/likelihood" description range while on the X (horizontal) axis is the "consequence" range . costs. and the like). A risk matrix shows the manager and the decision maker a clearer view of what the risk is. Depending on the intended use of the matrix. It is important to exercise risk mitigation when it affects people. when presented to stakeholders. Some businesses actually go by without a formal risk assessment policy. in an organised manner. effective risk management carries with it some costs. which. to name a few. The question is. the risks he or she faces in quantitative and qualitative terms and plan and make a more informed decision when the situation arises. but in no means a new science.assess risks in one's business and to address them. Needless to say. How does one construct an effective risk matrix? 1. Risk management is a modern buzzword. behavioural adjustments. facility siting studies. and safety audits. how would I know which particular sets of risks need a special level of attention? Given limited resources. as a manager. Define consequence and likelihood ranges A typical risk matrix is a four by four grid. and what amount of time can be afforded given the severity and probability of the risk event. one may need to establish tolerance or risk acceptability levels and a means of assessing the effectiveness of risk mitigation measures. Moreover. nor is there a unit that directly assesses the impact of risks in the organisation. naturally would lead to questions on how the costs could be justified. what is involved (in terms of procedural changes. and one's business. how would I know which particular types of risks need to be prioritised and addressed? A risk matrix is a risk assessment tool which exposes aspects of risks that could be subjected to some form of ranking. Identify what the risk matrix is to be used for Normally a risk matrix is called for during exercises involving hazard analyses. the environment. We have been so accustomed to risk in our everyday lives that the tendency is to ignore minor ones and react when major ones occur. 2. inattention to risks can definitely affect a company's bottom line. The matrix has ranges of consequence and likelihood as axes. More and more businesses and organisations recognise the need to identify risks within them so that they can be controlled and mitigated. Risk avoidance cannot make the potential of even greater loss from happening go away. It can help a manager visualise.

does not violate laws. Negligible Risks are those that involve USD 2. Closure to business. and Catastrophic.000 but less than USD 10. Rank Range Amount of Loss Description of Loss in USD • 4 Catastrophi 1M or more c Results in death or permanent disability of employees.000 and could result in minor illness or injury to employees not exceeding a day. could result in death or permanent disability. Marginal. as well as some qualitative characteristics of the consequence being described. . 3 Critical 200. Results in partial permanent disability.000 but less than 1M • • Reversible environmental damage. • • Irreversible environmental damage. Catastrophic Risks are those that involve USD 1M. Determine tolerance by assigning dollar values to each severity ranking. Negligible risks are the least severe and would be assigned the lowest rank. catastrophic risks are those that would be first in the severity ranking. Inversely. result in irreversible environmental damage or permanent closure to business. For example. or has little or minimal environmental damage and will be assigned Rank 1 in the matrix. and will be assigned Rank 4 in the matrix.Figure 1: Sample Risk Matrix Consequences of risks as laid down in the grid use descriptive words and are ranked according to severity: Negligible. Critical. injuries or illness of 3 employees or more.

it would be helpful to state the likelihood criteria in numeric terms (example. Injury or illness of resulting in one or more work days lost. Little or minimal environmental damage. Possible. • • Does not violate laws.000 • • Mitigable environmental damage where restoration activities can be done. 1 Negligible 2. Rank Range Probability (over the life of Description a business) Once in 2 years Once in 4 years Once in 6 years Continually experienced Will occur frequently Will occur several times 5 4 3 Certain Likely Possible . Figure 2: Sample Consequence Ranking The Probability axis describes the likelihood of the risk happening and can be assigned either Frequent.000 but less than 10. or simply Certain. Remote. Again. or Rare. or Improbable.000 • Minor illness or injury to employees resulting in one day's absence. Unlikely. Probable. "Possible" means the risk will occur several times in a lifetime but not less than 10 times nor over 100 times in that lifetime) and to assign logical rankings. 2 Marginal 10.Rank Range Amount of Loss Description of Loss in USD • Violation of law/regulation. Occasional. Likely.000 but less than 200.

Rank Range Probability (over the life of Description a business) Once in 12 years Unlikely. events or conditions that pose risk for the business and assign them along the blocks in the matrix. Example of an incident in the office would be "burst pipes and leaks" . when applied. with a simple change or adjustment in organisational policy. Translate the tolerability criteria into the matrix The design of the matrix should be able to show clearly which of the blocks are intolerable or tolerable.this could be assigned in the block Rare (Rank 5 Likelihood) and Negligible (Rank 1 Consequence). For example. given the description and values you have previously assigned. taking care not to be overly quantitative and not affording to include what is called a "layer of protection" approach. but can be reasonably expected to occur 2 Unlikely 1 Once in 24 years Unlikely to occur. proceed to determine specific incidents. 3. However. say. This block is a clear subject of risk mitigation efforts in the organisation compared to a block (risk) pertaining to a Negligible (Rank 1 Consequence) intersecting with a Certain (Rank 2 Likelihood) which could be addressed. a means of including protective measures. Figure 4: Determining Tolerance Points in the Matrix Care in assigning values Risk matrices are fairly easy to construct and understand. but possible Figure 3: Sample Probability Ranking Once the criteria for consequence and likelihood has been laid down. As in all planning and risk management . a Possible (Rank 3 Likelihood) intersecting with a Catastrophic (Rank 4 Consequence) would be intolerable for any business. one has to be careful in assigning values. brings down the risk a level lower. which.

processes and tools . Risk management (or more precisely risk avoidance) is a critical © ExecutiveBrief 2008 The Top Five Software Project Risks Get the PDF Version By Mike Griffiths I recently posted an entry on a risk assessment tool you can download and use. the technology management resource for business leaders. authors of the ever popular "Peopleware" . even the manager.Solution: Get the team more involved in planning and estimating. In short. is inherently difficult to estimate and schedule.. Decision makers are recommended to use this tool in policy formulation and include budgetary allocations to address not only persistent risks but also be ready for potentially catastrophic ones. please visit: http://www.. This post provides a useful summary of their top 5 software project risks. . While not an agile focussed book. techniques. Agile Practice: On agile projects the team is heavily involved in planning and estimating through activities such as XP's planning game and Wideband Delphi workshops. giving feedback to the stakeholders. Get early feedback and address slips directly with stakeholders. offers articles loaded with proven tips. Demarco and Lister rate the top five risks and their mitigation strategies as. I find it interesting that of the top five software project risks identified in Waltzing with Bears.. One of the few useful and entertaining books on the subject is "Waltzing with Bears: Managing Risk on Software Projects" by Tom Demarco. given the intangible nature and uniqueness of software. ExecutiveBrief. Risk 1: Inherent schedule flaws Explanation: Software development.efforts.the keys to improving their business performance. exercise conservatism in its design as well as point out areas of alarm. Waltzing. By working in short increments the true velocity of the team quickly emerges and is visible to all stakeholders who are now more closely involved in the project..executivebrief. and action plans that companies can use to better manage people. To learn more. the true progress is hard to hide and quickly revealed. all have suggested solutions rooted in agile methods. but one that is often dull to read about and therefore neglected. it is recommended that the risk planner or analyst. Timothy Lister.

Risk 2: Requirements Inflation Explanation: As the project progresses more and more features that were not identified at the beginning of the project emerge that threaten estimates and timelines. Risk 4: Specification Breakdown Explanation: When coding and integration begin it becomes apparent that the specification is incomplete or contains conflicting requirements.Solution: Constant involvement of customers and developers. is the fact that when working in an engaging. subject matter expert. and frequent reporting at daily stand-ups specifically to reduce the "bus-factor". empowered. When this "bus factor" (the impact to the project of a key member being hit by a bus) is reduced multiple team members share key information and the risk due to employee turnover is small.. Changes and requirements inflation are accepted as a fact of software projects. but now at least we anticipate the likely issue and have mechanisms in place to address the matter as part of the project from its early stages. Rather than utilising change-suppression mechanisms. prioritisation sessions are scheduled that allow worthwhile changes to proceed and initially envisioned features to be superseded if the business gives their authorisation. . collaborative environment such as agile projects.. Agile Practice: Agile projects plan in the regular trade-off discussions about features and estimates at every iteration boundary. people are far less likely to want to move elsewhere so the risk is often avoided as well as reduced. common code ownership. It has never been possible to squeeze a pint into a quart cup. rewarding. Waltzing. Agile Practice: Agile projects practice information sharing techniques such as pair programming.Solution: Use a dedicated Product Manager to make critical trade off decisions. often overlooked. The idea is that someone (or some group) need to be readily available to answer questions and make decisions on the project..Solution: Increased collaboration and information sharing on the team. Risk 5: Poor Productivity Explanation: Given long project timelines... or customer proxy to play the product manager role. Risk 3: Employee Turnover Explanation: Key personnel leave the project taking critical information with them that significantly delays or derails the project. Also. the sense of urgency to work in earnest is often absent resulting to time lost in early project stages that can never be regained.. Agile projects have some form of product owner role central to their core team composition to ensure decisions are made in a timely fashion. Waltzing. Traditional projects suffer specification breakdown when no one will own the role and conflicting assumptions or decisions are made. Waltzing. Agile Practice: Agile projects utilise the concept of an ambassador user.

. whether in-house or in partnership with a professional services firm." By having short iterations. coaching and team development. FDD. Inc. and mitigation. They were created out of the experience of what worked well for practical software development. people tend to wait until the deadline is nearly here before starting work. On Agile Solutions It should really be no surprise that agile methods have techniques built right into them to address each of the top software project risks.LeadingAnswers. Given that these problems occur time and time again on software projects it is natural that their solutions should become baked into the DNA of agile methods.Waltzing. Waltzing with Bears brings the subject to life with valuable pointers for software project managers and is a recommended read. Parkinson's Law says that: "Work expands to fill the time available" and Student Syndrome: "Given a deadline. . Agile methods do not specifically address getting the right people on team. while risk management is a dry and dull subject to many. Project risk is defined as any area of concern that could prevent a project from achieving all of its benefits.Solution: Short iterations. Mike Griffiths is an independent consultant specialising in effective project The Risky Business of Project Management Get the PDF Version By MA&A Group. Mike was involved in the creation of DSDM in 1994 and has been using agile methods (Scrum. DSDM) for the last 13 years.. coaching and team development. He serves on the board of the Agile Alliance and the Agile Project Leadership Network (APLN). Agile Practice: Agile methods recognise Parkinson's Law and the Student Syndrome apply to software projects. He maintains a leadership and agile project management blog at http://www. assessment. right people on team. work is timeboxed into a manageable iteration (typically 1-4 weeks) and there is always a sense of urgency. entails risk. Undertaking any project. Project risk requires careful management and involves identification. XP. So. but these are core leadership roles applicable to both agile and traditional projects.

Inadequate resources 4. look for areas in the project that are based on: 1. It should also determine the warning signs of the risk that will forecast that the occurrence of the risk is imminent. Not all project risks are obvious. (2) range of outcomes. The prioritised risks provide the basis for establishing Project Success Factors (PSFs). When identifying risks. Specific action plans are developed to address each PSF. Insufficient preparation 3. The assessment process should determine the (1) likelihood of the risk occurring. assume that required key policy changes are a high risk. and (4) the frequency with which it will occur. Insufficient or unreliable data 2. For example. An action plan must be developed to: • • • • Focus on thorough and frequent communications Implement a steering committee structure Obtain strong support for the project team from executive management Stress the benefits of the project . (3) estimated timing of the risk. Risks need to be assessed to quantify and prioritise them according to their impact on the project. Lack of control Some areas to pay close attention to are: • • • • • • • Requirements identification Involvement of project sponsorship Level of project management experience Third-party involvement Political/cultural environment Change control procedures and management Complexity of the technology Risk identification is only the first step. Keep in mind significant professional judgment is required during the assessment process to quantify the magnitude of potential negative impact and to develop risk control measures.It is important at the beginning of any project to go through the risk identification process.

A mitigation plan should outline plan B for the project area impacted by the risk. assessment. As the project progresses and project risk changes occur. Canadian Management Centre has earned the reputation as a trusted partner in worldwide professional development. and mitigation planning processes need to be updated. The risk management process must be continuous. documentation resulting from the identification. • • • Who cares? What do they care about? What am I going to do about it? . and developing mitigation plans are not one-time events.• Identify training needs early Once risks have been identified and assessed. assessing. The need is to accept that a risk exists and be prepared to deal with the consequences when and if it happens. Keep in mind a mitigation plan might be to do nothing to mitigate the risk. These processes need to occur throughout the life of the project. The plans document what the response will be when a risk event occurs. Project Management: Stakeholder Risk Management Get the PDF Version By Tris Brown In this article we'll address the people swirling around your project: stakeholders. project management and management education. mitigation plans should be developed. This type of action plan typically applies to low priority/minimal project impact risks. Knowing what plan B is prior to having to execute it will greatly reduce the probability of increasing the negative impact of the risk event or causing other unknown risks to occur. You'll find some tips and other resources for optimising stakeholder involvement in your project. Identifying. An effective risk project management process means choosing and implementing riskcontrol strategies that work.

but Cindy. your sponsor. So on your next (or current) project consider treating your stakeholders as opportunities or threats. endusers. Stakeholders are people. and the people who will be approving the funding. As we developed a workshop on stakeholder management built on those three questions one of our project management experts. We can prioritise stakeholders similarly . put all the pieces together when he said. not organisations. your customer's customers. Analyse and quantify the risk. "Facilities" isn't going to sign off on your change request. You won't be able to quantify your stakeholders as much as your project risks. might. "That's just risk management for people. Cast your net wide and consider all those stakeholders that won't make a peep unless you step on their toes. Stakeholders can be project adversaries just as easily as advocates. Step Two: Analyse and Quantify the Risk (What do they care about?) Risk management calls for prioritising the risks according to probability and impact. Develop a risk response. 3. 2. Can you see the parallel? 1. Step One: Identify Risks (Who cares?) Just as with risk management. who runs the department. Now analyse the high priority stakeholders. Review this classic risk management process. so be creative and energetic in identifying stakeholders. but you can organise some key information: What do they care about? How will the project affect them? How does this project fit into their priorities? What do you need from them for the project to run smoothly? Step Three: Develop a Risk Response (What are you going to do about it?) . authority and interest. In risk management we identify threats and opportunities. Too many project managers don't include these secondary stakeholders in their normal communication plans yet get indignant when they obstruct the project." We think he's right. Interest means "how much do they care?" and authority equates to their ability to affect the project.Those are the three simple questions a project team can ask to understand their stakeholders and develop a strategy for keeping them happy. Identify risks. Tip: Make sure your stakeholders have a name and email id. we can only manage stakeholders that we are aware of. and internal support staff such as accounting or procurement. While you are trying to uncover the hidden stakeholders. don't forget about the obvious ones: your team.

structures. Proactive. Risk Management Options Get the PDF Version By Paul Bower . Risk management doesn't have to be complex. to reach out. and influence them before they influence you. systems. The Secret to Success What's the secret to risk management? Do it. LSA has helped organisations create and maintain distinct competitive advantages through human capital. 2. and retain top talent. develop. The key is to be proactive. the better we can plan to work with them.LSAGlobal. The more we know about our stakeholders. We work with leading organisations to drive success through their people and the strategies. systematic risk management means finding the problems before they find you. meetings should be accompanied by documentation. Understanding who they are and what they want often isn't that difficult. One thing is certain: ignoring them will sap their support and inflame their opposition. but that doesn't necessarily make us effective communicators. Rapid changes in information technology continue to bring us new ways to flood our stakeholders with data. As you develop your communication plan remember these two tips: 1. For example. Since 1995. Who needs information? What information? How often? In what format? These questions form the basis of your communication plan. All Rights Personal relationships magnify the value of the technology we use to deliver information. Positive personal relationships are the foundation of effective communication. and processes that attract. Use two or more mediums of communication for every stakeholder. but it does have to be disciplined. The same holds true for our stakeholders. inspire. so plan for communication. . Copyright © 2008 Learning Alliance Corporation DBA LSA Global. Know more about Project Planning and Project Risk Management at www.What we do to leverage our supporters and minimise the effect of our opponents will depend upon the answers to the questions above.

) Avoidance: Use an alternate approach that does not have the risk. identify risks & risk owners . This approach can best be viewed as an adaptation of the . The customer is the final judge. assess the options for accommodating the risks. assumption. However. acceptably. Risk Transfer: Means causing another party to accept the risk. The plan itself may involve parallel development programmes.evaluate the risks as to likelihood and consequences. and knowledge and research. but internal goals should be to a higher level than customer expectations. authorise the implementation of the risk management plans. (The practicality of any option is usually just an issue of schedule and funding. control. However. The key aspect is the planning by experienced persons. but rather a technique for strengthening other techniques. The need for new risk assessment and management techniques is required to continuously track down potential and critical risks. and resources. management. a company will waste time. if experienced personnel are given the facts. Risk Management Options Risk management options are usually cited as risk handling options subdivided as: avoidance. However. The key words in risk management are: proactive. There are programmes that deliberately involve high risks in the expectation of high gains. there can be a tendency within organisations to gradually let the assumption of a risk take on the aura of a controlled risk. track the risk management efforts and manage accordingly. develop risk management plans. Risk management is the sum of all proactive management directed activities within a programme that are intended to acceptably accommodate the possibility of failures in the elements of a programme. for example: during product development. money. etc. the assessment of management options is a hip shot since the necessary decisions must occur early in a programme when things are still fuzzy. Liability among construction or other contractors is often transferred this way. risk transfer.Risk management as a shared or centralised activity must accomplish the following tasks: identity concerns. and will fail to manage their projects correctly. possibility. Generally. typically by contract or by hedging. Control: Controlling risks involves the development of a risk reduction plan and then tracking to the plan. one can expect very good decisions since there is seldom any real mystery about the practicality of options available. Assumption: Simply accepting the risk and proceeding. From an organisation's perspective a failure is anything accomplished in less than a professional manner and/or with a less-than-adequate result. this is the most effective risk management technique if it can be applied. accommodate. It is management's job to do the planning that will accommodate the possibilities. professional. prioritise the risk management efforts. It is obvious that without a strong risk management plan as part of the process. and to develop strategies for handling these risks. It is possibilities that are being accommodated. Knowledge & Research: This mode is not "true" risk handling. This mode is not always an option.

which includes risk management. because now those changes are anticipated and actions have already been reviewed and approved. one must have a solid understanding of some key definitions.approach used by a student writing a thesis: intensive study with specialised testing . Project risks as defined from a PMI perspective are. In combination with solid project management practices. following a good change management process. having a well-defined scope. and is a combination of proactive management directed activities within a programme that are intended to accommodate the possibility of failures. In order for companies to succeed in the twenty-first century. avoiding knee jerk and keeping open the lines of communication. they need to excel in all aspects of their business. Defining "Risk" Before one can embark on a risk management process. so that the word . or unexpected project risks. so they can fulfill their own and their customer's goals. incorporating input from the appropriate stakeholders. unknown events. experience. Practice. at their core. These events can be positive or negative. for more information on MoR management of risk training courses in London. Such a process can also help with problem resolution when changes occur.afaprojects. and actual loss results will dictate changes in the plan to allow different decisions to be made in dealing with the risks being faced. PMP Some experts have said that a strong risk management process can decrease problems on a project by as much as 80 or 90 percent. Never expect initial risk management plans to be perfect. a good risk management process is critical in cutting down on surprises. Your Risk Management Process: A Practical and Effective Approach Get the PDF Version By Vicki Wrona. Conclusion Risk management is an on-going process. Paul Bower wrote the article "Risk Management Options" and recommends you other words doing your homework.asp.

With a high number of project risks identified early on. companies that do perform a risk management process on a fairly typical multimonth project (no longer than 12 months) will identify and manage possibly five to ten easily recognised project risks. scope creep is a typical problem on most projects.a plan that includes the actions one would take if a trigger or a risk were to occur. or "opportunities. This can be done by assigning each item on the list a numerical rating such as on a scale from 1 to 4 or a subjective term such as high. It may seem that project risks cannot be managed without taking away from the actual work of the project. a team's awareness of what to look for is increased. Often with this step. this can effectively be accomplished with a seven-step risk management process that can be utilised and modified with each project. even minor ones. That said. which is determined after looking at the total scores for all risks. such as loss of management support or loss of a key resource. Step three of the risk management process is to assess the probability (or likelihood). but it can be simple to assess . Step five of the risk management process is for those same sub-groups to identify possible preventive actions for the threats and enhancement actions for the opportunities. The risk management process is not effective if it is so time-consuming that it is never done. Step two of the risk management process is to collect the lists of project risks and compile them into a single list with the duplicates removed. Step four of the risk management process is to break the planning team into sub-groups and to give a portion of the master list to each sub-group. Each sub-group can then identify the triggers (warning signs) for its assigned list of project risks. medium.if a risk is harder to see. . All triggers should be noted. the impact (or consequence) and the detectability of each item on the master list. However. Normally there will be at least three triggers for each risk. Yet it still must be listed because even with the best practice management processes in place. If it's easier to catch early. The Risk Management Process Step one of the risk management process is to have each person involved in the planning process individually list at least ten potential risk items. such as with scope creep. or "threats. it could still occur and cause problems on a project over time. This keeps the risk management process manageable. so that potential problems are recognised earlier and opportunities are seen more readily. Step six of the risk management process is for the sub-groups to then create a contingency plan for most but not all project risks . or low. then it's a riskier item." rather than positive project risks. then it's lower risk. For example. Therefore it should be addressed rather than ignored. most of the time and focus is spent handling negative project risks. that number should in fact be much higher. and therefore do not need to be listed. team members will assume that certain project risks are already known. This plan will be created for those risks scoring above a certain cut-off point. Detectability is optional. However." Often."risk" is inherently neutral.

If these steps in the risk management process are skipped. Often. these are vital to the entire risk management process. They could also ignore a seemingly overwhelming list of project risks. probability. Important Things to Remember Often. preventive actions. skipping step three. and if there are any new project risks to add. However. if any risks have increased or decreased in value. a master document. After a team has completed this exercise once. Determine if any project risks can be closed (but not removed completely). saving a great amount of time and helping to ingrain a risk mentality into your project culture. and proven approach that involves seven steps taken at the beginning of each project (fewer if a generic list of project risks has already been established). triggers. and detectability for each risk. it is easy to maintain. simply implementing a contingency plan for each risk after that risk catches them by surprise. It can be reviewed during regular status meetings. The most effective format for this document is a table. impact. detectability. it can be followed once to establish a list of generic project risks and triggers.Step seven. Conclusion A risk management process does not have to be complicated or time consuming to be effective. the project team can prepare itself for whatever may occur. because it will allow a great deal of information to be conveyed in a few pages. the final step in planning the risk management process. Rather than start this risk management process from scratch for every new project. the members will be better conditioned on what to pay attention to while managing the project so they are more proactive in catching changes or issues early. a team simply has to add project-specific project risks and triggers and assess the probability. the steps in which triggers and preventive actions are identified are overlooked. but it is always in the best interest of the project for all team members to watch for triggers while working on the project. Of course . impact. with as little as 15 minutes spent making sure the list is still current. Then. is to determine the owner of each risk on the list. the owner of the risk is the project manager. tested. This will ensure that the list is continually seen as relevant and useful throughout the life of the project. and contingency plan. By following a simple. If the information is instead presented in paragraph form. known as a risk register or risk matrix. it may not be read by people and will be rendered ineffective. is created. The owner is the person who is responsible for watching out for triggers and then for responding appropriately if the triggers do in fact occur by implementing the pre-approved and now established contingency plan. can also be added as appropriate. Other columns. The columns in the table can include risk description. the team can find themselves in constant reaction mode. such as quantitative value. Once the risk register is complete. which is why narrowing the list down to the most important risks is critical for making sure the list is used. Creating a Risk Register or Risk Matrix Upon completion of the risk management process.

there will always be changes and there may still be surprises. has mentored individuals and organisations. He went on to request that we limit our discussions on project risks and focus on the things we can control instead of those things we cannot. The fact is. is the president of Forward Momentum. that it is either contingency planning now or emergency relief later for our projects. As a seasoned project management professional. and an instructor with Westlake Training and Development . I went to Jim's office where he launched into a lecture about the need to cultivate a "positive environment" for the project team. that time should be focused on the actual work of the project. . I was admittedly stunned that our project sponsor advised his project manager to virtually eliminate our risk management efforts from the project! I have learned in the years since that this scenario is not that uncommon in the project management environment. I was concluding a project risk review meeting. since we were focusing on reasons that the project could not be done. After a few minutes of his diatribe. has trained over 3. an 8(a) consulting and training company. She is currently serving on the PMI's committee to write the PMBOK Guide 4th edition in general and a content reviewer specifically on the Communication and Procurement knowledge areas. She has 20 years of project management experience. and has authored multiple white papers. but the end result is that they are fewer. however. and I received a text page from my project's executive sponsor ("Jim") summoning me to his office. I explained to Jim that I did not know what triggered this discussion. not events that may or may not occur. Jim then explained the regular risk review sessions I was facilitating had created a "negative vibe" throughout the project team. Vicki Wrona. Project Risk Management: It's Either Contingency Planning Now or Emergency Relief Later Get the PDF Version By Chris Wright Several years ago. The competitive market and stakeholder risk tolerance levels exacerbate the myth that risk management initiatives are a waste of project resource time. PMP. that the team feels prepared and that the project is not taken off course. LLC. As soon as the meeting concluded.800 people.

The Common Constraints In most cases. Project Risk Management Tenet #2: Build It into the Schedule In order to adequately deal with uncertain events. There are three basic tenets you can incorporate that can turn your risk management efforts into a consistent and proactive process. Either way. Uncertainties can be discovered at any time. the more likely you will lose team members to other efforts. It is imperative that the project team address uncertainty early and often. this process typically occurs early in the project and is never revisited. hearing the phrase risk management. and complexity of the project. might say. The project manager must ensure that risk assessment (identification and analysis) and response planning initiatives are a regular occurrence. and adequate resources (budget and people) are not allocated to address issues caused by risk events. analysis. while the relative probability and consequence of identified risks can change over time. For instance. In addition. risk management is not a priority for the project team. As a result. Risk management earns limited buy-in and support In many cases. the impact of poorly defined requirements will typically have a greater impact on project success in the latter stages of the project. "We have a group that handles our risk management. the farther along a project goes into the schedule. This "we will deal with those events if and when they occur" mentality leaves little or no room for error on the project. we are not reducing project costs or delivery time so why should we invest in risk management?" As you have likely discovered. the project schedule must include risk management activities. Risk management is not prioritised The risk planning. project sponsors and senior management discount risk management efforts for their projects because the benefits are unclear. As a result. senior management. Plus. the challenges present in project risk management are just another element to worry about as a project leader. 2. scope. the project team may not be prepared to respond to new uncertainties and issues that have not been identified. and response planning efforts are rarely integrated into the overall project plan. throughout the entire term of the project. Additionally. so why do we need to have a separate effort on the project. 3. Risk management is applied inconsistently Even when potential risk events are identified for a project. The three most common constraints with project risk management are: 1. They include: Project Risk Management Tenet #1: Assess Early and Often Project risk management must occur throughout the life cycle of the project. Depending on the size. the . risk reviews can either be an agenda item on the weekly review meeting or a bi-weekly review by itself. risk management initiatives either do not occur at all or are done as a mere checklist formality early in the project.

Copyright © 2007. When key stakeholders know who to contact regarding a critical uncertainty. it is up to the project manager to employ effective communications and clear ownership of risk elements. not a shotgun. Visit our online Knowledge Centre for free white papers. yet realistic. risk response strategies need to function as a rifle. consistently applied. webinars. Global Knowledge (www. Global Knowledge. Simply put. clear communication is better facilitated. and accompanied by targeted.project manager must incorporate consistent risk management mechanisms into the project schedule. Proper project risk management entails more than simply identification and analysis at the beginning of a project. . business process. and professional skills training. Potential risks need to be clearly identified and assessed. the project leader must ensure that team members are properly aligned as owners for specific risk ) delivers comprehensive hands-on project management. Therefore. and more. Project Risk Management Tenet #3: Communicate and Illustrate Ownership The inherent uncertainty of risk events tends to make key stakeholders avoid the subject altogether. Also. All rights reserved. response strategies.globalknowledge. This article was originally published in Global Knowledge's Management in Motion e-newsletter (now named Business Brief). Risk management must be integrated into the project plan. and clearly communicated throughout the life cycle of the project.

Sign up to vote on this title
UsefulNot useful