This action might not be possible to undo. Are you sure you want to continue?
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 firstname.lastname@example.org 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.
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. Worse still. Change will inevitably occur during the project lifecycle. Imagine having to write off a . 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. 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. The result is that this approach to developing software almost always fails to mitigate risk.Figure 2: Waterfall Development Lifecycle Waterfall processes may appear at first glance to be a reasonable and common sense approach. the actual software code. waterfall processes have a late feedback cycle for the part that really counts. and this is usually the result of feedback. As we see in figure 3.
Iterative Development Project risks are associated with the unknown. is inappropriate for software development. such as: 1. By assuming that the development lifecycle will be predictable.. Do the system requirements actually reflect the true needs of the users? 4. organisational or business oriented in nature. Adaptive software development processes realise that producing software is a risky business and highly unpredictable in nature. you are admitting that a high degree of risk cannot exist within a project. after having already spent 95 man-years of the budget. A Lower Risk Approach . How will my system communicate with system A? 2.100 man-year project. as shown in figure 4. and that a reliable completion date can be derived from this. How do I manage my offshore development group? 3. This is a fools paradise! The Waterfall process is the wrong approach for software development. They also recognise that the best mechanism for achieving successful delivery is to contain and mitigate risk by means of the regular and . These can be technical.. 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. because of a fundamental misunderstanding in the user's requirements! The risk profile for waterfall processes.
A high level of communication between all project team members 4. The iterative cycle continuously mitigates risk from the early project stages as a result of regular feedback from users. . is that it forces the team to address the most important aspects of functionality and to resolve high risk issues at an early stage. 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. The adoption of an Iterative Risk Driven Approach 2. One of the users' requirements meant that the system had to process one million financial trades within an eight hour window. Key Principles There is no single overriding rule that guarantees project success but the following key principles will greatly increase your chances: 1. An iterative approach will continuously reduce project risk from the outset. A highly skilled development team 5. 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. Result .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 client was adamant that this was a key requirement and that the application must be capable of running on low cost hardware. Figure 5 provides a comparison of typical risk profiles between iterative and waterfall development lifecycles. This major risk was thus mitigated within the first three weeks of the project.the users reassessed their objectives and realised that a lower processing target was indeed adequate. The adoption of a comprehensive and rigorous system of change control 7. The reason why. The commitment and involvement of senior management 3. We recognised that there was a major risk that we might not be able to meet these performance objectives. The adoption of a Use Case driven approach 6. 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). the software should be demonstrated to the users to obtain feedback on its functionality and suitability.
If you haven't already got the right mix of skills (technical and process). waste time and money with off-the-shelf 'one size fits all' training courses.Keep Talking! First and foremost projects are about people. Your end goal should be to make all these groups part of the project team.not just verbal. Aim to keep documentation lightweight by adopting a 'just enough' policy. Consider supporting your project team with expert mentors to assist and accelerate process adoption. and includes producing good documentation. people will naturally want to be associated with it. Communication is paramount within the team and more importantly with your users and sponsors. They will be very efficient and productive. Do not. Iterative development will greatly increase communication with the users. High Level of Communication . and at least weekly with the users and sponsors. however. This has to be on a regular basis. then invest in training focused on meeting your project's needs. Use Case Driven Approach . Use visual modelling (key principle) whenever possible to raise the level of communication.but once the process starts working. Communication comes in many forms . daily with the team.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. Highly Skilled Development Team A highly skilled group of individuals that understands how to work together should form the nucleus of your team. Without everybody working together you haven't got a team and the project will fail. It is important to ensure you have full executive support for any type of process change. You will need backup to drive through changes in the early stages .
does a new request mean that an existing requirement has to be removed from the live release. What is delivered at the end of each iteration? The answer should be a demonstration of some actual working software to the users. . 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. If the answer is documents for sign-off. You will come across the same situations.'A picture is worth a thousand words' Visual modelling is the modern equivalent of the "flowcharts" used in the early days of software production.human or otherwise) shall interact with the system. To drive a project forward. They bind together the whole development process from the capturing of user requirements through to the testing of the application software. For example.Use Cases are highly effective because they provide a contextual representation of the system requirements. There is no excuse for not using it. Demand that all roles use the same modelling notation. Change Control This is very different from stopping change from occurring to your project. during which they will have the opportunity to provide feedback. if the delivery date is fixed. and Use Cases are the best way do this. The value of visual aids remains valid and diagrams should be used throughout the project. from business analysts to designer and coders through to testers. So many times I have seen documents that purport to contain the complete system requirements. then they are missing the point. Instead the emphasis is on the careful consideration of new requests and deciding (with the users) how these should be accommodated. you need objectives and goals to aim for. 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. 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. or that a further system release should be considered? Visual Modelling . 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. when in fact they are just a set of business rules and a list of user needs. Simplicity is the key strength of use cases. 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 .
When do you the users see what they are going to get? The answer should be at the end of every (short) iteration. An answer of "only during acceptance testing prior to delivery" is just not acceptable. The project manager should maintain a running risk list. quantified in terms of probability and impact to the development schedule along with proposed mitigation strategies. . Figure 6: Software Cost Breakdown Adopting these good practices. How do you manage risk? The answer should be that there is a regular assessment of risk. This typically results in systems that are easier to maintain and revise and thereby reduce the long term operational costs and associated risks. with the focus on developing systems that deliver what the users actually want. will usually produce systems that are of a higher build quality and are 'fit for purpose'. when the system enters the support and maintenance phase of it lifecycle. available for inspection by all people associated with the project. When do you intend to start integration testing? The answer should be that integration testing is a continuous activity that occurs during each iteration. effort and money. 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. But the greatest costs occur long after the initial development is over.
Some projects use no approach whatsoever to risk management. Some people blindly trust the project manager. Also the big pile of literature available on the subject has been condensed in this article. This article gives you the 10 golden rules to apply risk management successfully in your project. 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. People are your team members . Professional companies make risk management part of their day to day operations and include it in project meetings and the training of staff. They are based on personal experiences of the author who has been involved in projects for over 15 years. 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. They are either ignorant. The result will be that you minimise the impact of project threats and seize the opportunities that occur. you can not reap the full benefits of this approach. 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. running their first project or they are somehow confident that no risks will occur in their project (which of course will happen). on budget and with the quality results your project sponsor demands. You can encounter a number of faulty approaches in companies. 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.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. Rule 1: Make Risk Management Part of Your Project The first rule is essential to the success of project risk management. If you don't truly embed risk management in your project. This requires an open mind set that focuses on future scenarios that may occur. Two main sources exist to identify risks. This allows you to deliver your project on time. people and paper. You can gain a lot of money if you deal with uncertain project events in a proactive manner.
These "good guys" make your project faster. Interviews and team sessions (risk brainstorming) are the common methods to discover the risks people know. you have enough time left for the unexpected risks that take place. better and more profitable. Another categories are old project plans. because usually some of them exceed the mandate of the project manager. being overloaded with work that needs to be done quickly. However modern risk approaches also focus on positive risks. 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.that each bring along their personal experiences and expertise. you better pay attention to risk communication. Unfortunately. A good approach is to consistently include risk communication in the tasks you carry out. but didn't inform the project manager of its existence. 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. lots of project teams struggle to cross the finish line. but someone who reads carefully (between the lines) will find them. you are likely to find the large majority. the project opportunities. This shows risks are important to the project manager and gives team members a "natural moment" to discuss them and report new ones. Make sure you create some time to deal with the opportunities in your project. The project plan. . They may not always have that name. Rule 4: Consider Both Threats and Opportunities Project risks have a negative connotation: they are the "bad guys" that can harm your project. Paper is a different story. If you have a team meeting. Are you able to identify all project risks before they occur? Probably not. This creates project dynamics where only negative risks matter (if the team considers any risks at all). business case and resource planning are good starters. If you deal with them properly. These are the uncertain events that beneficial to your project and organisation. However if you combine a number of different identification methods. Projects tend to generate a significant number of (electronic) documents that contain project risks. 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. 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 frightening finding was that frequently someone of the project organisation actually did see that hammer. your company Intranet and specialised websites. even if it is only half an hour. make project risks part of the default agenda (and not the final item on the list!). 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. If you don't want this to happen in your project.
someone has to pay the bill. departments and suppliers are involved in your project. However.Rule 5: Clarify Ownership Issues Some project managers think they are done once they have created a list with risks. The ownership issue is equally important with project opportunities. A more detailed analysis may show the order of magnitude effect in a certain effect category like costs. it doesn't deliver the best results possible. 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. Looking at the effects. these are your number 1 priority. lead time or product quality. 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. but as time passes they will act and carry out tasks to decrease threats and enhance opportunities. 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. Another level of risk analysis is investigate the entire project. you better spend your time on the risks that can cause the biggest losses and gains. The criteria most project teams use is to consider the effects of a risk and the likelihood that it will occur. Rule 6: Prioritise Risks A project manager once told me "I treat all risks equally. If so. Rule 7: Analyse Risks Understanding the nature of a risk is a precondition for a good response. The risk owner is the person in your team that has the responsibility to optimise this risk for the project. This sounds logical. Risk analysis occurs at different levels. Therefore. Especially if different business units. If a project threat occurs. on a set of criteria. Some risks have a higher impact than others. Another angle to look at risks. An important side effect of clarifying the ownership of risk effects. the risk causes. use it consistently and focus on the big risks. Fights over (unexpected) revenues can become a long-term pastime of management. The trick is simple: assign a risk owner for each risk that you have found. it becomes important who bears the consequences and has to empty his wallet. Check if you have any showstoppers in your project that could derail your project. However this is only a starting point. Whatever prioritisation measure you use. 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. 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. is that line managers start to pay attention to a project. The effects are really positive." This makes project life really simple. List the different causes and the circumstances that decrease or increase the likelihood. more objectively. The other risks can be prioritised on gut feeling or. Each project manager needs to answer the usual questions about the total budget needed or the date the project will . Ownership also exists on another level. especially when a lot of money is at stake. is to focus on the events that precede a risk occurrence.
This could mean changing supplier or adopting a different technology or. Execution is key here. If you take risks into account. Spending more money on a doomed project is a bad investment. time consuming or relatively expensive. risk avoidance. Some project managers don't want to record risks. risk minimisation and risk acceptance. terminating a project. You prevent a threat occurring or minimise negative effects. A final response is to accept a risk. If you record project risks and the effective responses you have implemented. maximising them or ignoring them (if opportunities prove to be too small). They will focus on seeking risks. Maintaining a risk log enables you to view progress and make sure that you won't forget a risk or two. Responses for risk opportunities are the reverse of the ones for threats. Just make sure that it is a conscious choice to accept a certain risk. If you deal with threats you basically have three options. but doing your bookkeeping with regards to risks pays off. you create a track record that no one can deny. 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. because they feel this makes it easier to blame them in case things go wrong. prioritise and understand risks. Even if a risk happens that derails the project. The other rules have helped you to map. A good risk log contains risks descriptions. If you have carried out rule 7 properly (risk analysis) you will have plenty of opportunities to influence it. clarifies ownership issues (rule 5) and enables you to carry our some basic analyses with regard to causes and effects (rule 7). This is a good choice if the effects on the project are minimal or the possibilities to influence it prove to be very difficult. Avoiding risks means you organise your project in such a way that you don't encounter a risk anymore.finish. The biggest category of responses are the ones to minimise risks. It is also a perfect communication tool that informs your team members and stakeholders what is going on (rule 3). Most project managers aren't really fond of administrative tasks. However the reverse is true. This will help you to make a sound risk response plan that focuses on the big wins. You can try to prevent a risk occurring by influencing the causes or decreasing the negative effects that could result. A similar exercise can be done for project costs. Doing projects is taking risks. especially if the number of risks is large. if you deal with a fatal risk. Rule 10: Track Risks and Associated Tasks . Rule 8: Plan and Implement Risk Responses Implementing a risk response is the activity that actually adds value to your project. Rule 9: Register Project Risks This rule is about bookkeeping (however don't stop reading). 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.
training and sells its own easy to use risk management software. 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. financial. Tracking tasks is a day-to-day job for each project manager. frameworks. Integrating risk tasks into that daily routine is the easiest solution. such as operational. Failing to practice it right can have fatal consequences on projects and programmes.The risk register you have created as a result of rule 9. PMP 26 Sep 2010 Risk management is the heart and soul of project management. Disregarding Enterprise Risk Management Enterprise Risk Management (aka ERM) specifies the processes. A free demo is available at ProjectFuture. Concilio offers consultancy. select and implement responses. Tracking risks differs from tracking tasks. planning alone is not enough if monitoring risks is not handled seriously. It focuses on the current situation of risks. These are seven deadly sins of risk management and how to take preventive actions to avoid them. keep in mind that you can always improve. Success with your project! Bart Jutte is a founder and consultant at Concilio. compliance. and methodologies an organisation uses to identify and manage enterprise risks of all types. 1. However. etc. Risk tasks may be carried out to identify or analyse risks or to generate. a NL based company specialising in project risk management. Doing real effort in the planning stage can save the entire investment and will increase the likelihood of project success. The Seven Deadly Sins of Risk Management Get the PDF Version By Kareem Shaker. The project manager has to . 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. The 10 golden risk rules above give you guidelines on how to implement risk management successfully in your project. However. strategic. will help you to track risks and their associated tasks.
The project risk management has to be congruent with ERM. Every industry has its own associated risks. I believe that identifying risks will always get 60% of the job done. Project Management Institute refers to those as Enterprise Environmental Factors (EEF). The ownership of risks has to be communicated to the risk owners. 2. a financial risk may not grab a technical manager's attention. The risk management team has to set clear expectations and inform subject matter experts. RBS highly depends on the project domain. Subjectivity can be avoided by using the Delphi Technique. RBS can be developed by listing all the root causes of potential risks. The perpetual problem of risk management information is subjectivity. fearing that they may be responsible for the risks they will be identifying. as it keeps the views of different subject matter experts anonymous. and the risk owner has to report risk status updates on a frequent basis. 3. Risk management teams use it to identify risks and stimulate the minds of the stakeholders who will be participating in the risk identification stage. customers. You will find that risk averse stakeholders will identify large numbers of risks. and the rest is sort of "Just Do It!" There are different information gathering techniques to solicit stakeholders' input. risk takers may be oblivious to real risks. stakeholders. Assigning All The Risks to The Project Manager Successful risk management can never be a one-man army. The risk identification process is substantial for successful risk management. probability/impact scales. For instance. Potential risk owners may be reluctant during risk identification stage. in contrast. . The project manager has to follow up on the status of assigned risks. Ignoring Subjectivity Subjectivity can make risk management lose its essence. 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.consider the enterprise-wide risks and study what threats the organisation is likely to encounter during the projects' lifetime. The project manager should not be the only individual who owns risks. Different people will perceive risks in different ways. and risk management software to be used. Accountable. and a technical risk is very unlikely to be deemed as a risk by a financial manager. team members of what is expected from them. risk appetite. Creating a risk management RACI Matrix (Responsible. 4. It is the responsibility of the risk management team to remove subjectivity and ensure quality of risk information. even after finishing the identification phase. since the ERM governance can impose certain documents to be delivered. 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. 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. Risks that are valid to a software project may not be applicable to a construction project.
first is unfeasibility of the first three response strategies. he has over 10 years of experience in IT projects. It is also important to put risk management on the agenda of frequent progress and status update meetings. It is also not right to use the contingency quota of one risk at the expense of another risk. and shelve risks until they turn into issues. The project manager should elevate the culture of risk management and ask team members to report new risks. Mitigate. The new risks have to go through the process of analysis and response strategy planning.Consulted. there are positive risks. those are known as opportunities) are Avoid. Many project managers conduct risk identification at the beginning of the project. and pre-sales. some risks just need to be accepted. Contingency reserve should only be used when a planned risk (aka known unknown) materialises. due to implementing a control. from inception to closure.KareemShaker. Misusing Contingency Reserve Contingency reserve can only be determined after the project manager has had multiple revisions of the project management plan. and Accept. consulting. but oftentimes the acceptance strategy is never considered. It is not right to do it during the planning stage only. otherwise you would be paying $100 to save a $60 risk. Neglecting Risk Management Benefit Cost Analysis Not all risks have to be managed. Doing it Once Risk management is an iterative process and should be practiced in all project stages. if the loss value is much smaller than the benefit gained. 5. Response strategies of negative risks (yes.com Project Risk: Is It All Bad? Get the PDF Version By Paul Slater . Risks have to be accepted for two main reasons. For instance. The contingency reserve should not be used for any unplanned risk (unknown unknown). These are the seven deadly sins of project risk management as I could identify them. Informed) will ensure roles and responsibilities are clearly identified and communicated. Read his blog atwww. 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. Kareem Shaker. PMP is a project manager at Dubai World. and second is due to unfavourable benefit cost analysis. 7. unless the latter has already become void. The project manager has to visit the reserve balance and make sure that no risk will have no contingency. it would be rational to accept the risk. Transfer. nor is it right to stop looking for new risks during the execution phase. 6. The unplanned risk can only be handled by the management reserve.
Risk Management is an essential part of any programme or project and can vastly contribute to successful delivery. but is not the be all and end all of it as it sometimes becomes in more risk averse organisational cultures. complex programmes covering numerous disciplines. There may well be a Risk Manager and team to assist that individual in collating the requisite management information. 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. the risk process starts to drive the programme and stops providing a benefit. software. say construction. The reason for this? Well. Appropriate Monitoring and Mitigation The most important aspect here is the word 'appropriate'. Matches and is appropriate. make them aware of it. The difficulties arise however when the scale of programme or project is much reduced. More Risks Recorded. think about it. The more risks you identify and manage within a project the greater the chance the project might not come in on time. it's . the Longer the Project will Take Strange but true. When this happens. 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. 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. 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. and telecommunications and running for a number of years it is entirely appropriate to have a risk set-up that matches that complexity. If other projects or a higher level programme need to be aware of it that is fine. but make sure you don't start double or triple scoring the same risk.30 Jan 2010 No one would disagree that managing risk within a project is not a good idea. Even with sophisticated risk software the potential for confusion is great with different scores being applied to probabilities and impacts. 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. For large. The management of risk is part and parcel of project management.
All this takes valuable time and effort away from the main job of project delivery itself. Opportunities Arise Risks happen in any project and some may have been predicted and planned for while others may not have been.very easy to identify lots of risks for any project. but that's just the way it is. 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. 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. but it's how far you go that really matters. Opportunities can be anywhere within a project space. Paul Slater owns and runs Mushcado Consulting in the UK. Get right down 'in the weeds' and you will still have to identify risk owners and people to investigate mitigation strategies etc. advising businesses and organisations on how best to employ project management techniques to improve project delivery. but just remember to think about them as you go through the risks. the ultimate might mean cancelling the project altogether. You aren't ignoring the risk you are making a conscious decision to accept that it may happen. But. are all risks bad? Of course not. he works with individuals and organisations to bring out the potential inherent in people. 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. You can follow Paul on Twitter @Mushcado The Principles of Risk Management Get the PDF Version By Simon Buehring . 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. never an easy decision for anyone. As a leadership coach. make sure you have the important risks identified and managed and keep reviewing to ensure your list is up-to-date. that's what everyone accepts as the truth. Putting in place some form of mitigation may be necessary and add cost to the budget. it starts to make that risk review meeting far more meaningful. So. The project is the project with its set requirements. etc. So.
Understanding how to identify and treat risks to an organisation. legal and environmental backdrop of an organisation. processes. Stakeholders should. which are intended "not . short-term projects and businesswide change programmes. social. be made aware of risks to a project or programme. 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. a positive risk for drought-ridden farmland and a non-risk for the occupants of a submarine. Organisational Objectives Risks exist only in relation to the activities and objectives of an organisation. probability and potential impact of the risk. The term 'organisational context' encompasses the political. Within the context and stakeholder involvement. "appropriate" concerns: the identity and role of the stakeholder.. the level of investment that the stakeholder has in the organisation. the level of influence that the stakeholder has over and outside of the organisation. and will prepare managers and team members for any unavoidable incidences or issues. including PRINCE2 and MSP as well as M_o_R. Stakeholder Involvement It is easy for a management team to become internalised and forget that stakeholders are also key participants in everyday business procedures. a programme or a project can save unnecessary difficulties later on. Project managers. strategies and plan.. .21 Jul 2009 Every project manager and business leader needs to be aware of the practices and principles of effective risk management." Organisational Context A fundamental principle of all generic management methods. economic. as far as is appropriate. and the type. technological. Understanding the roles of individual stakeholders and managing stakeholder involvement is crucial to successful. to be prescriptive but [to] provide supportive guidance to enable organisations to develop their own policies. Rain is a negative risk for a picnic. is that all organisations are different. The OGC M_o_R (Management of Risk) framework identifies twelve principles.
and the transmission of this data to the appropriate staff members. Individual functions and accountability must be transparent. This establishes the regular review of identified risks and ensures that risk managers remain sensitive to new risks. This is important both in terms of organisational governance. Following best practices ensures that individuals involved in managing the risks associated with an organisation's activity are able to learn from the mistakes. Early Warning Indicators Risk identification is an essential first step for removing or alleviating risks. Roles and Responsibilities Fundamental to risk management best practice is the clear definition of risk management roles and responsibilities. Early warning indicators are predefined and quantified triggers that alert individuals responsible for risk management that an identified risk is imminent. Reporting Accurately and clearly representing data. Review Cycle Related to the need for early warning indicators is the review cycle. the project/programme manager or a specialist risk manager) understands the objectives of the organisation. In some cases. is crucial to successful risk management. and to the effectiveness of current policies. The M_o_R methodology provides standard templates and tested structures for managing the frequency. strategies and plans within the M_o_R framework provide generic guidelines and templates within a particular organisation.It is imperative that the individual responsible for risk management (whether that is the business leader. and to ensure that all the necessary responsibilities are covered by appropriate individuals. . it is not possible to remove risks in advance. however. a standard risk management approach and best-practice guidelines for reporting and reviewing organisational risks. training and funding for individuals managing risks that may arise in any specific area or project. This enables the most thorough and prepared approach to handling the situation. in order to ensure a tailored approach. This can include a centralised risk management team. Support Structure A support structure is the provision within an organisation of standardised guidelines. information. policies. These guidelines are based on the experience and research of professional risk managers from a wide range of organisations and management backgrounds. M_o_R Approach The processes. experiments and lessons of others. content and participants of risk communication. both within and outside an organisation. managers and stakeholders.
Simon Buehring is a project manager. An effective risk management policy includes the capacity for re-evaluation and improvement. as well as the establishment of regular review cycles of the organisation's risk management approach. Continual Improvement In an evolving organisation. tools and techniques. Common issues include: • • • • • Established roles. discussing and managing risks. An appropriate budget for embedding approach and carrying out activities. consultant and trainer. accountabilities and ownership. 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. Regular assessment of M_o_R approach (including all of the above issues. At a practical level. A supportive risk management culture will also include evaluation and reward of risk management competencies for the appropriate individuals. nothing stands still. induction and training processes. 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.Overcoming Barriers to M_o_R Any successful strategy requires thoughtful consideration of possible barriers to implementation. Risk management orientation. Is Software Development Risk Costing You Money? Get the PDF Version By ExecutiveBrief . Adequate and accessible training. He works for KnowledgeTrain which offers management of risk training in the UK and overseas. responsibilities. He can be contacted via the M_o_R Practitioner training website.
According to The Standish Group's 2006CHAOS Report. • Scope. The most frequently cited factors that contribute to the challenge include: • Poor communication. budget. exceed allotted costs. Poor communication. 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. And 19 percent were considered outright failures or cancelled prior to completion. the more likely it will be that the software will fail to meet the current needs of users. or did not support all of the features originally required. cost overruns or even outright failure of the project. they met all requirements and were completed on time and within budget. 41 cents of every dollar spent on software development was considered wasted.Poor software project management often means missed deadlines. • Time. development. According to the same report. and at such a fast pace. testing." meaning that they were completed and operational. or schedule. How can your company avoid this industrywide problem? In our brief you'll learn best practices for successfully completing software projects. Requirements and priorities can change multiple times as projects progress through planning. Anyone involved with software development projects knows why bringing them to successful completion can be so difficult to achieve. Almost half (46 percent) were reported to be "challenged. Software development projects are plagued with risk and impending failure. overrun schedule. The legendary communication gap between developers and business clients or stakeholders often leads to poorly defined requirements." that is. time creep. and ultimately fail. and production. but were delivered late. went over budget. A project whose scope is too broad will become too complex. which in turn will lead to inadequately designed software that doesn't provide the functionality needed by the customer. the longer a development project takes to get off the ground and cycle through to completion. A . Because market forces today are continually changing. only about one-third (35 percent) of the researched software development projects undertaken in the previous two years were considered "successful.
director of Risk Doctor and Partners. inadequate resources. many development departments don't follow a coherent development methodology. and limited time. such as the U. Software Engineering Institute's (SEI's) Capability Maturity Model Integration (CMMI). when it came to the quality of their development processes. Software development is rife with unrealistically low budgets. . risk was defined almost exclusively in negative terms.S. new hires can bring new expertise that takes a project in a positive new direction. But most approaches to risk management follow steps similar to those outlined below. considered by many to be the project management bible. "Risk can be defined as uncertainty that matters. For example. "You can either rely on good luck or be proactive and seek out those opportunities.project whose scope has been defined too narrowly may finish on time. Including stakeholders in this process is essential for fostering good communication and gaining a true understanding of the business risks associated with the project. can damage a project. a well-known global consulting firm specialising in project risk management. Success for any IT project. both early on in the project and throughout its lifespan. A company could discover reusable code that it didn't know it had. 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). when they happen. Despite the availability of established best practices in software development. and schedule." For example. resources. A study by the SEI in 2005 found that. is very much dependent on effective management of risks. the PMBOK Guide has its legions of followers as well as its fervent detractors. Like any religious text. "Uncertainties. Not long ago. almost 40 percent of companies gave themselves a low rating of 1 or 2 out of a possible 5 on the CMMI scale. Step #1: Identify Identification of project risks is usually accomplished via a brainstorming session that includes the development team and the stakeholders. • Budget. the company's financial calendar may influence when certain accounting or other financial-related systems must be in place. risk management philosophy has expanded to include unexpected opportunities. but likely will fail to perform according to customers' real requirements. Certain parts of a project could finish early." There is more than one approach to risk management. but in the past seven years or so. but some uncertainties can help." says David Hillson. particularly in software development. opening up possibilities that seemed impossible at first. • Risk. and alternative methodologies abound. • Unorganised development processes.
Some ways to minimise risks include lining up contingency plans and funding. "My problem with this process is that people often go through the steps without any real thinking. • Minimise it. and authority to make decisions for their part of the project. free-for-all discussion. The PMBOK Guide includes a risk breakdown structure (RBS) that can help the team to map out risks in a very detailed. they should be assigned a high priority. it may be possible to use a different supplier. Risks that have low impact and low probability often can be ignored. This is also a good time to map out specific early warning signs for each of these risks. or nurturing a positive relationship with people outside of the team whose co-operation is essential for success. if there's a risk that a certain supplier will deliver an essential item too late to meet your deadline. These factors should not be ignored." says Hillson. In the case of software development. 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.e. "No one person should be so indispensable that losing this resource would mean a significant delay for the . many of the risks analysed will stem from the factors outlined above (i. Sometimes it's possible to find a strategy for avoiding a risk completely." Step #2: Quantify and Prioritise Once the identified risks are mapped out. opportunities.Including stakeholder representatives is also a great way to gauge their skills. communications. Certain risks can kill a project all by themselves. but missing the real substance. Step #3: Address The next step is to develop strategies for addressing each risk. Hillson agrees. scope)." says Gartner analyst Donna Fitzgerald. bringing in team members who have the expertise to take over a key task if other members quit. the team should prioritise them based on probability and expected impact." 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. "The meeting really must be facilitated and structured. time. For example. weaknesses. "They end up filling out the forms. hierarchical fashion. and threats) analysis. It's also helpful to generate and repurpose checklists of risks from similar past projects to help map out risks for the current one. "The whole idea of this process is to be innovative and think outside the box. The first is to avoid an unfocused. Risk experts cite two principles for the success of this step. Real risk management is about exceptions to the normal day job. Some of the classic strategies include: • Avoid it. even if the probability of such risks is low. availability. Another useful tool for gauging internal and external treats and opportunities is the SWOT (strengths.
including a high number of unresolved issues." says Fitzgerald. which didn't. Consider Agile Development Techniques In recent years. and early slippage in the schedule. Frequent risk reviews should be conducted to continually monitor for early warning signs of risks. or even a stakeholder. scope. This is also the time to assess whether the project may be in real trouble. If the impact and probability are minimal. Compare the risks that you originally identified with the real risks that you ultimately needed to address. Step #5: Record Post-mortem reviews can be extremely valuable in planning for successful future projects. Fitzgerald had to add $80. 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. an outside consultant.project. This is also the time to assign each risk to an owner who will be responsible for detecting and addressing it. from conception to delivery. Ongoing communication with stakeholders about a project's progress and shifting risk profile is important as well. Which strategies worked." 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. Sometimes you can hand over responsibility for certain risks to a vendor. Conduct an end-to-end evaluation of the project. agile development has risen in popularity as a way to minimise risks related to time. agile development methods promote development of one small complete . Fitzgerald points out some key early warning signs. and communication.000 to the budget in order to hire a consultant who could take over if an unhappy critical team member quit. persistent disagreements about what should be done. In one of her projects." says Fitzgerald. Again. "In every organisation. it may not be worth addressing the risk at all. assess progress in addressing identified risks. • Accept it. Rather than undertaking massive software projects in their entirety. 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. "Build your team so that you are tied into that network from the start. Any of these circumstances may indicate a need to reassess your entire risk management and project implementation strategy. and discover new risks that have cropped up. close out some risks. Step #4: Monitor Murphy's Law reigns in just about every project. • Transfer it. there's an off-org chart network of people who get things done.
"Software is evolutionary by nature." On the other hand.executivebrief. please visit: http://www. 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. risk is often used synonymously with the probability of a known loss. detailed approach to managing risk.com © ExecutiveBrief 2008 Ranking Risks: Rare to Certain." says Fitzgerald. the technology management resource for business leaders. In everyday usage. but it's also important to align the structure to the size and type of project and to your company philosophy. do something else.piece at a time. 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." says Hillson. "A small project probably requires a light touch. "Get in. "Your risk process should be scalable. which is why projects that last longer than six months have a very high failure rate. processes and tools ." Get Real A structured risk-management process is vital to success." ExecutiveBrief.the keys to improving their business performance. and get something done in less than six months. and action plans that companies can use to better manage people. offers proven tips. Since risk is directly correlated to loss. is to cultivate an organisational culture in which everyone understands and lives the concepts of risk management instinctively. techniques. Risk is measured in terms of impact and likelihood. perhaps an hour-long meeting every couple of weeks. when the state of affairs changes. it is important to be able to . To learn more. Then. Fitzgerald offers this suggestion: "Your company should adopt an attitude that likens risk management to breathing. however. a large project at a large company with many players and stakeholders very well could require a highly structured. Perhaps more important.
costs. It can help a manager visualise. Risk management is a modern buzzword. Depending on the intended use of the matrix. Some businesses actually go by without a formal risk assessment policy. 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. effective risk management carries with it some costs. which. A risk matrix shows the manager and the decision maker a clearer view of what the risk is. facility siting studies. Identify what the risk matrix is to be used for Normally a risk matrix is called for during exercises involving hazard analyses. but in no means a new science. It is important to exercise risk mitigation when it affects people. to name a few. and what amount of time can be afforded given the severity and probability of the risk event. How does one construct an effective risk matrix? 1. On the Y (vertical) axis is the "probability/likelihood" description range while on the X (horizontal) axis is the "consequence" range . the risks he or she faces in quantitative and qualitative terms and plan and make a more informed decision when the situation arises. Needless to say. one may need to establish tolerance or risk acceptability levels and a means of assessing the effectiveness of risk mitigation measures. how would I know which particular sets of risks need a special level of attention? Given limited resources. The matrix has ranges of consequence and likelihood as axes. and safety audits. 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. as a manager. and one's business. inattention to risks can definitely affect a company's bottom line. behavioural adjustments. nor is there a unit that directly assesses the impact of risks in the organisation. The question is. naturally would lead to questions on how the costs could be justified. Define consequence and likelihood ranges A typical risk matrix is a four by four grid. More and more businesses and organisations recognise the need to identify risks within them so that they can be controlled and mitigated. and the like). in an organised manner. when presented to stakeholders. what is involved (in terms of procedural changes.assess risks in one's business and to address them. Moreover. 2. the environment. Risk avoidance cannot make the potential of even greater loss from happening go away.
as well as some qualitative characteristics of the consequence being described.000 and could result in minor illness or injury to employees not exceeding a day. Critical. Results in partial permanent disability. injuries or illness of 3 employees or more. . • • Irreversible environmental damage. Rank Range Amount of Loss Description of Loss in USD • 4 Catastrophi 1M or more c Results in death or permanent disability of employees. catastrophic risks are those that would be first in the severity ranking. could result in death or permanent disability. 3 Critical 200. For example. Negligible risks are the least severe and would be assigned the lowest rank. Determine tolerance by assigning dollar values to each severity ranking. or has little or minimal environmental damage and will be assigned Rank 1 in the matrix. and Catastrophic. Inversely. Negligible Risks are those that involve USD 2. and will be assigned Rank 4 in the matrix. does not violate laws.000 but less than USD 10. Closure to business.000 but less than 1M • • Reversible environmental damage. Marginal. result in irreversible environmental damage or permanent closure to business. Catastrophic Risks are those that involve USD 1M.Figure 1: Sample Risk Matrix Consequences of risks as laid down in the grid use descriptive words and are ranked according to severity: Negligible.
• • Does not violate laws. or Improbable. Little or minimal environmental damage. Likely.000 but less than 200. 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 . 1 Negligible 2. Again. it would be helpful to state the likelihood criteria in numeric terms (example. 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.000 • Minor illness or injury to employees resulting in one day's absence. Occasional. Injury or illness of resulting in one or more work days lost. Remote. or simply Certain.000 • • Mitigable environmental damage where restoration activities can be done. Probable. or Rare. "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. Unlikely. Possible.Rank Range Amount of Loss Description of Loss in USD • Violation of law/regulation. 2 Marginal 10.
Example of an incident in the office would be "burst pipes and leaks" . which. 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. but can be reasonably expected to occur 2 Unlikely 1 Once in 24 years Unlikely to occur. with a simple change or adjustment in organisational policy.this could be assigned in the block Rare (Rank 5 Likelihood) and Negligible (Rank 1 Consequence). 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. For example. proceed to determine specific incidents. a Possible (Rank 3 Likelihood) intersecting with a Catastrophic (Rank 4 Consequence) would be intolerable for any business. when applied. events or conditions that pose risk for the business and assign them along the blocks in the matrix. As in all planning and risk management . brings down the risk a level lower. one has to be careful in assigning values. given the description and values you have previously assigned. Figure 4: Determining Tolerance Points in the Matrix Care in assigning values Risk matrices are fairly easy to construct and understand. However.Rank Range Probability (over the life of Description a business) Once in 12 years Unlikely. taking care not to be overly quantitative and not affording to include what is called a "layer of protection" approach. say. 3. but possible Figure 3: Sample Probability Ranking Once the criteria for consequence and likelihood has been laid down.
Risk management (or more precisely risk avoidance) is a critical topic. In short. processes and tools . Waltzing.com © 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. Timothy Lister..efforts. exercise conservatism in its design as well as point out areas of alarm. This post provides a useful summary of their top 5 software project risks.executivebrief. even the manager. authors of the ever popular "Peopleware" . . offers articles loaded with proven tips. please visit: http://www. all have suggested solutions rooted in agile methods. 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.. is inherently difficult to estimate and schedule. I find it interesting that of the top five software project risks identified in Waltzing with Bears. 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. To learn more. giving feedback to the stakeholders.the keys to improving their business performance. 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.Solution: Get the team more involved in planning and estimating. it is recommended that the risk planner or analyst. Risk 1: Inherent schedule flaws Explanation: Software development. the technology management resource for business leaders. and action plans that companies can use to better manage people. While not an agile focussed book.. One of the few useful and entertaining books on the subject is "Waltzing with Bears: Managing Risk on Software Projects" by Tom Demarco. ExecutiveBrief. the true progress is hard to hide and quickly revealed. Get early feedback and address slips directly with stakeholders. Demarco and Lister rate the top five risks and their mitigation strategies as. given the intangible nature and uniqueness of software. but one that is often dull to read about and therefore neglected..
or customer proxy to play the product manager role. . people are far less likely to want to move elsewhere so the risk is often avoided as well as reduced.. rewarding. collaborative environment such as agile projects. Agile Practice: Agile projects practice information sharing techniques such as pair programming..Solution: Increased collaboration and information sharing on the team. It has never been possible to squeeze a pint into a quart cup. the sense of urgency to work in earnest is often absent resulting to time lost in early project stages that can never be regained. Waltzing. Also.. 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. Risk 4: Specification Breakdown Explanation: When coding and integration begin it becomes apparent that the specification is incomplete or contains conflicting requirements.. subject matter expert. Rather than utilising change-suppression mechanisms.Solution: Use a dedicated Product Manager to make critical trade off decisions. often overlooked. Agile Practice: Agile projects plan in the regular trade-off discussions about features and estimates at every iteration boundary.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. and frequent reporting at daily stand-ups specifically to reduce the "bus-factor". Agile Practice: Agile projects utilise the concept of an ambassador user. Waltzing. 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. Agile projects have some form of product owner role central to their core team composition to ensure decisions are made in a timely fashion. is the fact that when working in an engaging. Risk 5: Poor Productivity Explanation: Given long project timelines. The idea is that someone (or some group) need to be readily available to answer questions and make decisions on the project. common code ownership.. empowered. Traditional projects suffer specification breakdown when no one will own the role and conflicting assumptions or decisions are made.. Changes and requirements inflation are accepted as a fact of software projects. Risk 3: Employee Turnover Explanation: Key personnel leave the project taking critical information with them that significantly delays or derails the project. prioritisation sessions are scheduled that allow worthwhile changes to proceed and initially envisioned features to be superseded if the business gives their authorisation.Solution: Constant involvement of customers and developers. Waltzing.
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.com The Risky Business of Project Management Get the PDF Version By MA&A Group. Undertaking any project. whether in-house or in partnership with a professional services firm. He maintains a leadership and agile project management blog at http://www. Parkinson's Law says that: "Work expands to fill the time available" and Student Syndrome: "Given a deadline. Mike Griffiths is an independent consultant specialising in effective project management. 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. Mike was involved in the creation of DSDM in 1994 and has been using agile methods (Scrum.Waltzing. coaching and team development. people tend to wait until the deadline is nearly here before starting work. Project risk is defined as any area of concern that could prevent a project from achieving all of its benefits. but these are core leadership roles applicable to both agile and traditional projects.LeadingAnswers.Solution: Short iterations. FDD. right people on team. They were created out of the experience of what worked well for practical software development. Waltzing with Bears brings the subject to life with valuable pointers for software project managers and is a recommended read. So. while risk management is a dry and dull subject to many.." By having short iterations. XP. . assessment.. and mitigation. coaching and team development. 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. Project risk requires careful management and involves identification. work is timeboxed into a manageable iteration (typically 1-4 weeks) and there is always a sense of urgency. DSDM) for the last 13 years. Agile methods do not specifically address getting the right people on team. Inc. entails risk.
(3) estimated timing of the risk. The assessment process should determine the (1) likelihood of the risk occurring. For example. assume that required key policy changes are a high risk. Inadequate resources 4. The prioritised risks provide the basis for establishing Project Success Factors (PSFs). 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 . Insufficient preparation 3. Insufficient or unreliable data 2. Specific action plans are developed to address each PSF. When identifying risks. It should also determine the warning signs of the risk that will forecast that the occurrence of the risk is imminent. 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. Not all project risks are obvious. and (4) the frequency with which it will occur. (2) range of outcomes. 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. look for areas in the project that are based on: 1.
The plans document what the response will be when a risk event occurs. These processes need to occur throughout the life of the project. mitigation plans should be developed. assessing. The need is to accept that a risk exists and be prepared to deal with the consequences when and if it happens. • • • Who cares? What do they care about? What am I going to do about it? . and mitigation planning processes need to be updated. As the project progresses and project risk changes occur. documentation resulting from the identification. A mitigation plan should outline plan B for the project area impacted by the risk. 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. This type of action plan typically applies to low priority/minimal project impact risks. An effective risk project management process means choosing and implementing riskcontrol strategies that work. Identifying. Canadian Management Centre has earned the reputation as a trusted partner in worldwide professional development. You'll find some tips and other resources for optimising stakeholder involvement in your project. The risk management process must be continuous. project management and management education. 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. Keep in mind a mitigation plan might be to do nothing to mitigate the risk.• Identify training needs early Once risks have been identified and assessed. and developing mitigation plans are not one-time events. assessment.
" We think he's right. and internal support staff such as accounting or procurement. Analyse and quantify the risk. Step Two: Analyse and Quantify the Risk (What do they care about?) Risk management calls for prioritising the risks according to probability and impact. not organisations. Interest means "how much do they care?" and authority equates to their ability to affect the project. Stakeholders can be project adversaries just as easily as advocates. So on your next (or current) project consider treating your stakeholders as opportunities or threats. You won't be able to quantify your stakeholders as much as your project risks. Stakeholders are people. might. Cast your net wide and consider all those stakeholders that won't make a peep unless you step on their toes. 3. so be creative and energetic in identifying stakeholders. your customer's customers. put all the pieces together when he said. we can only manage stakeholders that we are aware of. "That's just risk management for people. who runs the department. Now analyse the high priority stakeholders.Those are the three simple questions a project team can ask to understand their stakeholders and develop a strategy for keeping them happy. but Cindy. Identify risks. don't forget about the obvious ones: your team. Too many project managers don't include these secondary stakeholders in their normal communication plans yet get indignant when they obstruct the project. and the people who will be approving the funding. "Facilities" isn't going to sign off on your change request. endusers. Step One: Identify Risks (Who cares?) Just as with risk management. Can you see the parallel? 1. Tip: Make sure your stakeholders have a name and email id. In risk management we identify threats and opportunities. your sponsor. Develop a risk response. While you are trying to uncover the hidden stakeholders. We can prioritise stakeholders similarly . 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?) . Review this classic risk management process.by authority and interest. As we developed a workshop on stakeholder management built on those three questions one of our project management experts. Regulators. 2.
and influence them before they influence you. but that doesn't necessarily make us effective communicators. but it does have to be disciplined. develop. The Secret to Success What's the secret to risk management? Do it. One thing is certain: ignoring them will sap their support and inflame their opposition. The key is to be proactive. the better we can plan to work with them. Risk management doesn't have to be complex. Use two or more mediums of communication for every stakeholder. As you develop your communication plan remember these two tips: 1. Positive personal relationships are the foundation of effective communication. . Rapid changes in information technology continue to bring us new ways to flood our stakeholders with data.LSAGlobal. structures. The more we know about our stakeholders. Since 1995. to reach out. Proactive. so plan for communication. 2. systems. All Rights Reserved. Risk Management Options Get the PDF Version By Paul Bower . meetings should be accompanied by documentation. LSA has helped organisations create and maintain distinct competitive advantages through human capital. systematic risk management means finding the problems before they find you. For example. and retain top talent. and processes that attract. We work with leading organisations to drive success through their people and the strategies. Know more about Project Planning and Project Risk Management at www. inspire.What we do to leverage our supporters and minimise the effect of our opponents will depend upon the answers to the questions above. The same holds true for our stakeholders. Copyright © 2008 Learning Alliance Corporation DBA LSA Global.com. Personal relationships magnify the value of the technology we use to deliver information. Understanding who they are and what they want often isn't that difficult. Who needs information? What information? How often? In what format? These questions form the basis of your communication plan.
The plan itself may involve parallel development programmes. From an organisation's perspective a failure is anything accomplished in less than a professional manner and/or with a less-than-adequate result.) Avoidance: Use an alternate approach that does not have the risk. risk transfer. if experienced personnel are given the facts. acceptably. (The practicality of any option is usually just an issue of schedule and funding. It is possibilities that are being accommodated. The key words in risk management are: proactive. The need for new risk assessment and management techniques is required to continuously track down potential and critical risks. there can be a tendency within organisations to gradually let the assumption of a risk take on the aura of a controlled risk. and resources. Liability among construction or other contractors is often transferred this way. Control: Controlling risks involves the development of a risk reduction plan and then tracking to the plan. typically by contract or by hedging. The customer is the final judge. this is the most effective risk management technique if it can be applied. However. management. It is management's job to do the planning that will accommodate the possibilities. assumption. There are programmes that deliberately involve high risks in the expectation of high gains. assess the options for accommodating the risks. the assessment of management options is a hip shot since the necessary decisions must occur early in a programme when things are still fuzzy. However. Assumption: Simply accepting the risk and proceeding. develop risk management plans. Risk Management Options Risk management options are usually cited as risk handling options subdivided as: avoidance. Knowledge & Research: This mode is not "true" risk handling. 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. authorise the implementation of the risk management plans. and knowledge and research. The key aspect is the planning by experienced persons.Risk management as a shared or centralised activity must accomplish the following tasks: identity concerns. Risk Transfer: Means causing another party to accept the risk. for example: during product development. identify risks & risk owners . a company will waste time. etc. track the risk management efforts and manage accordingly. and will fail to manage their projects correctly. Generally. one can expect very good decisions since there is seldom any real mystery about the practicality of options available. but internal goals should be to a higher level than customer expectations. It is obvious that without a strong risk management plan as part of the process. money. accommodate. prioritise the risk management efforts.evaluate the risks as to likelihood and consequences. but rather a technique for strengthening other techniques. possibility. control. This mode is not always an option. This approach can best be viewed as an adaptation of the . professional. However. and to develop strategies for handling these risks.
at their core. 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. and is a combination of proactive management directed activities within a programme that are intended to accommodate the possibility of failures. Such a process can also help with problem resolution when changes occur. Project risks as defined from a PMI perspective are. so that the word . Practice. and keeping open the lines of communication. Paul Bower wrote the article "Risk Management Options" and recommends you visitwww. and actual loss results will dictate changes in the plan to allow different decisions to be made in dealing with the risks being faced. experience. so they can fulfill their own and their customer's goals. one must have a solid understanding of some key definitions.in other words doing your homework. Conclusion Risk management is an on-going process.com/training_m_o_r. or unexpected project risks. they need to excel in all aspects of their business. These events can be positive or negative. Your Risk Management Process: A Practical and Effective Approach Get the PDF Version By Vicki Wrona. incorporating input from the appropriate stakeholders. Defining "Risk" Before one can embark on a risk management process. because now those changes are anticipated and actions have already been reviewed and approved. for more information on MoR management of risk training courses in London. having a well-defined scope.afaprojects. avoiding knee jerk reactions.approach used by a student writing a thesis: intensive study with specialised testing . a good risk management process is critical in cutting down on surprises. which includes risk management. Never expect initial risk management plans to be perfect. following a good change management process. In order for companies to succeed in the twenty-first century. In combination with solid project management practices.asp. unknown events.
This keeps the risk management process manageable. and therefore do not need to be listed. However. It may seem that project risks cannot be managed without taking away from the actual work of the project. the impact (or consequence) and the detectability of each item on the master list. 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 . then it's a riskier item. such as with scope creep.if a risk is harder to see. a team's awareness of what to look for is increased. team members will assume that certain project risks are already known. or "threats. 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. . most of the time and focus is spent handling negative project risks. If it's easier to catch early. This plan will be created for those risks scoring above a certain cut-off point. Normally there will be at least three triggers for each risk.a plan that includes the actions one would take if a trigger or a risk were to occur. this can effectively be accomplished with a seven-step risk management process that can be utilised and modified with each project. scope creep is a typical problem on most projects. Detectability is optional. 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. then it's lower risk. With a high number of project risks identified early on. That said. which is determined after looking at the total scores for all risks. 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. 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. that number should in fact be much higher. medium."risk" is inherently neutral. The risk management process is not effective if it is so time-consuming that it is never done. 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. However. For example. Therefore it should be addressed rather than ignored." Often. Each sub-group can then identify the triggers (warning signs) for its assigned list of project risks. Often with this step. it could still occur and cause problems on a project over time. All triggers should be noted. 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. Step three of the risk management process is to assess the probability (or likelihood). Yet it still must be listed because even with the best practice management processes in place. but it can be simple to assess . or "opportunities. or low. so that potential problems are recognised earlier and opportunities are seen more readily." rather than positive project risks. even minor ones. such as loss of management support or loss of a key resource.
Of course . 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. it is easy to maintain. preventive actions. They could also ignore a seemingly overwhelming list of project risks. and detectability for each risk. This will ensure that the list is continually seen as relevant and useful throughout the life of the project. saving a great amount of time and helping to ingrain a risk mentality into your project culture. simply implementing a contingency plan for each risk after that risk catches them by surprise. because it will allow a great deal of information to be conveyed in a few pages. The most effective format for this document is a table. if any risks have increased or decreased in value. After a team has completed this exercise once. Conclusion A risk management process does not have to be complicated or time consuming to be effective. a master document. Then. and if there are any new project risks to add. triggers. such as quantitative value. the team can find themselves in constant reaction mode. Creating a Risk Register or Risk Matrix Upon completion of the risk management process. Other columns. 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. these are vital to the entire risk management process. but it is always in the best interest of the project for all team members to watch for triggers while working on the project. can also be added as appropriate. If these steps in the risk management process are skipped. the project team can prepare itself for whatever may occur. is created. and contingency plan. 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. Determine if any project risks can be closed (but not removed completely).Step seven. is to determine the owner of each risk on the list. Often. skipping step three. Rather than start this risk management process from scratch for every new project. 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. it may not be read by people and will be rendered ineffective. the final step in planning the risk management process. impact. By following a simple. probability. known as a risk register or risk matrix. detectability. Important Things to Remember Often. impact. 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). the owner of the risk is the project manager. with as little as 15 minutes spent making sure the list is still current. tested. It can be reviewed during regular status meetings. The columns in the table can include risk description. However. it can be followed once to establish a list of generic project risks and triggers. If the information is instead presented in paragraph form.
LLC. since we were focusing on reasons that the project could not be done. Project Risk Management: It's Either Contingency Planning Now or Emergency Relief Later Get the PDF Version By Chris Wright Several years ago. 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. that it is either contingency planning now or emergency relief later for our projects. not events that may or may not occur. and has authored multiple white papers. As a seasoned project management professional. I went to Jim's office where he launched into a lecture about the need to cultivate a "positive environment" for the project team. has mentored individuals and organisations. The competitive market and stakeholder risk tolerance levels exacerbate the myth that risk management initiatives are a waste of project resource time. 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. that the team feels prepared and that the project is not taken off course. I was concluding a project risk review meeting. that time should be focused on the actual work of the project. She has 20 years of project management experience. 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. Vicki Wrona. has trained over 3. As soon as the meeting concluded. After a few minutes of his diatribe.800 people. an 8(a) consulting and training company. and I received a text page from my project's executive sponsor ("Jim") summoning me to his office.there will always be changes and there may still be surprises. I explained to Jim that I did not know what triggered this discussion. but the end result is that they are fewer. however. is the president of Forward Momentum. . PMP. The fact is. and an instructor with Westlake Training and Development . Jim then explained the regular risk review sessions I was facilitating had created a "negative vibe" throughout the project team.
the more likely you will lose team members to other efforts. Plus. For instance. the impact of poorly defined requirements will typically have a greater impact on project success in the latter stages of the project. and response planning efforts are rarely integrated into the overall project plan. the project team may not be prepared to respond to new uncertainties and issues that have not been identified. Uncertainties can be discovered at any time. the farther along a project goes into the schedule. scope. Depending on the size. Risk management is not prioritised The risk planning. "We have a group that handles our risk management. Either way. risk management is not a priority for the project team. 2. risk management initiatives either do not occur at all or are done as a mere checklist formality early in the project.The Common Constraints In most cases. Risk management is applied inconsistently Even when potential risk events are identified for a project. and complexity of the project. hearing the phrase risk management. analysis. Risk management earns limited buy-in and support In many cases. They include: Project Risk Management Tenet #1: Assess Early and Often Project risk management must occur throughout the life cycle of the project. senior management. There are three basic tenets you can incorporate that can turn your risk management efforts into a consistent and proactive process. and adequate resources (budget and people) are not allocated to address issues caused by risk events. risk reviews can either be an agenda item on the weekly review meeting or a bi-weekly review by itself. while the relative probability and consequence of identified risks can change over time. As a result. Project Risk Management Tenet #2: Build It into the Schedule In order to adequately deal with uncertain events. the . the challenges present in project risk management are just another element to worry about as a project leader. so why do we need to have a separate effort on the project. The project manager must ensure that risk assessment (identification and analysis) and response planning initiatives are a regular occurrence. As a result. It is imperative that the project team address uncertainty early and often. Additionally. 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. In addition. The three most common constraints with project risk management are: 1. 3. This "we will deal with those events if and when they occur" mentality leaves little or no room for error on the project. might say. this process typically occurs early in the project and is never revisited. project sponsors and senior management discount risk management efforts for their projects because the benefits are unclear. throughout the entire term of the project.
This article was originally published in Global Knowledge's Management in Motion e-newsletter (now named Business Brief). it is up to the project manager to employ effective communications and clear ownership of risk elements. Project Risk Management Tenet #3: Communicate and Illustrate Ownership The inherent uncertainty of risk events tends to make key stakeholders avoid the subject altogether. and clearly communicated throughout the life cycle of the project. clear communication is better facilitated. risk response strategies need to function as a rifle. Visit our online Knowledge Centre for free white papers. webinars. the project leader must ensure that team members are properly aligned as owners for specific risk events. and more. and accompanied by targeted. Also. Potential risks need to be clearly identified and assessed. Therefore. response strategies. All rights reserved. When key stakeholders know who to contact regarding a critical uncertainty.globalknowledge. not a shotgun. Proper project risk management entails more than simply identification and analysis at the beginning of a project. consistently applied. Global Knowledge. and professional skills training. Simply put. . business process. yet realistic. Copyright © 2007.project manager must incorporate consistent risk management mechanisms into the project schedule. Global Knowledge (www.com ) delivers comprehensive hands-on project management. Risk management must be integrated into the project plan.
This action might not be possible to undo. Are you sure you want to continue?
We've moved you to where you read on your other device.
Get the full title to continue reading from where you left off, or restart the preview.