| p>Threats to software development projects are | | | | team. Another will be the lack of redundancy in the |
| often minimized or overlooked altogether because | | | | skill sets which means that the illness of a team |
| they are not as tangible as risks to projects in other | | | | member cannot be absorbed without delaying the |
| industries. The risks are there though and just as | | | | schedule or getting outside help. |
| capable of derailing the software development | | | | Scrum |
| project as a project in any other industry. | | | | The distinguishing characteristic of this development |
| Most project managers in the information field have | | | | method is the lack of a project manager. This role is |
| had the experience of planning a software | | | | replaced by a team lead. The team lead may be a |
| development project down to the last detail, planning | | | | project manager, but it is unlikely that the performing |
| the effort for each of the tasks in the plan down to | | | | organization will seek out and engage an experienced |
| the last hour and then having some unforeseen issue | | | | project manager to fulfill this role. The method avoids |
| come along that derails the project and makes it | | | | management by a project manager to avoid some |
| impossible to deliver on time, or with the feature set | | | | of the rigors of project management best practices |
| originally envisioned. | | | | in an effort to streamline development. The risk |
| Successful project managers in any industry must | | | | introduced by this approach is that there will be a |
| also be skillful risk managers. Indeed, the insurance | | | | lack of necessary discipline on the team: change |
| industry has formalized the position of risk manager. | | | | management, requirements management, schedule |
| To successfully manage the risks to your software | | | | management, quality management, cost |
| development project, you first must identify those | | | | management, human resources management, |
| risks. This article was written to provide you with | | | | procurement management, and risk management. |
| some tips and techniques to help you do that. There | | | | The lack of project management discipline could |
| are a few terms that are not directly applicable to | | | | leave the project open to an inability to |
| the activity of identifying risks that are helpful to | | | | accommodate change properly resulting in changes |
| understand before studying risk identification. These | | | | being ignored or changes being incorrectly |
| are some of those definitions: | | | | implemented. Lack of experience in human resources |
| - Risk event - This is the event that will affect the | | | | management could result in an unresolved conflict, or |
| project if it should happen. | | | | inappropriate work assignments. |
| - Threat - A risk event that will have a negative | | | | Iterative Methods |
| impact on the scope, quality, schedule, or budget of | | | | The main iterative methods are RUP (Rational Unified |
| the project should it happen. | | | | Process) and Agile. These methods take an iterative |
| - Opportunity - Not all risks are threats, some are | | | | approach to design and development so are lumped |
| opportunities which will have a positive impact on | | | | together here. This method is intended to |
| scope, quality, schedule, or budget should they | | | | accommodate the changes to a project that a |
| happen. Threats should be avoided, or their impacts | | | | dynamic business requires. The cycle of requirements |
| diminished and opportunities encouraged, or their | | | | definition, design, build, and test is done iteratively |
| impacts enhanced. | | | | with each cycle spanning a matter of weeks (how |
| - Probability - The likelihood that a risk event will | | | | long the cycles are will depend on the methodology). |
| happen. This is what people in the gambling business | | | | Iterative development allows the project team to |
| call odds. | | | | learn from past mistakes and incorporate changes |
| - Impact - Usually refers to a comparative cardinal or | | | | efficiently. |
| ordinal rank assigned to a risk event. It may also | | | | Iterative methods all rely on dividing the system up |
| refer to an absolute monetary value, period of time, | | | | into components that can be designed, built, tested, |
| feature set, or quality level. | | | | and deployed. One of the advantages of this method |
| - Risk Tolerance - This refers to your organization's | | | | is its ability to deliver a working model early on in the |
| approach to taking risks. Is it conservative? Does | | | | project. One risk inherent in this method is the risk |
| your organization welcome calculated risks? | | | | that the architecture does not support the separation |
| - Risk Threshold - Your organization's risk tolerance | | | | of the system into components that can be |
| will usually be expressed as a cardinal or ordinal | | | | demonstrated on their own. This introduces the risk |
| comparator using the risk events probability and | | | | of not learning from a mistake that won't be found |
| impact to produce the comparator. Risks whose | | | | until the users test the system. |
| Probability/Impact score exceed this threshold will be | | | | There is a trade off implied in iterative development: |
| avoided or mitigated. Risks whose score is below the | | | | develop a core functionality that can be |
| threshold are acceptable. | | | | demonstrated first vs. develop the component that |
| - Risk Contingency - This is a sum allotted to the | | | | will yield the most learning. Choosing core functionality |
| project for the purpose of managing risks. It should | | | | to develop may introduce the risk of failing to learn |
| be split into two sums: one for managing identified | | | | enough about the system being developed to help |
| risks and one for managing unidentified risks, or | | | | future iterations. Choosing the most complex or |
| unknown unknowns. The sum can be either a | | | | difficult component may introduce the risk of failing |
| monetary amount or an amount of time. The project | | | | to produce the system the client needs. |
| manager of a software development project can | | | | Activity Specific Risks |
| look to several sources for help in identifying risks: | | | | Each activity in a development cycle has its own set |
| common risks (risks common to every software | | | | of risks, regardless of the methodology chosen. The |
| development project), risks identified with the | | | | requirements gathering activity has the following risks: |
| performing organization, risks identified with the SDLC | | | | the requirements gathered may be incomplete, the |
| methodology chosen for the project, risks specific to | | | | requirements gathered may be misstated, or the |
| a development activity, Subject Matter Experts, risk | | | | requirements gathering exercise may take too much |
| workshops, and surveys. | | | | time. |
| Common Risks | | | | The design portion of the cycle will have the |
| There are a number of risks that are common to | | | | following risks: the design may not interpret the |
| every software development project regardless of | | | | requirements correctly so that the functionality built |
| size, complexity, technical components, tools, skill | | | | will not meet the customer's needs. The design could |
| sets, and customers. The following list contains most | | | | be done in a way that calls for more complexity in |
| of these: | | | | the code than necessary. The design may be written |
| - Missing requirements - Requirements needed by the | | | | in such a way that it is impossible for a programmer |
| software system to be developed to meet the | | | | to develop code that will function properly. The |
| business goals and objectives of the project. | | | | design could be written in a way that is ambiguous or |
| - Misstated requirements - Requirements that have | | | | difficult to follow, requiring a lot of follow up |
| been captured but the original intent has been lost or | | | | questions or risking bad implementation. There may |
| misconstrued in the process of capturing them. | | | | be several stages of design from a Commercial |
| - Key or critical resources are lost to the project - | | | | Specification all the way to a Detail Design Document. |
| These resources are usually single contributors, or | | | | The interpretation of requirements through each |
| team members with skill sets in scarce supply for | | | | stage exposes the stated requirements to |
| which there is a strong demand in the performing | | | | misinterpretation. |
| organization. The potential impact of losing the | | | | Programmers may misinterpret the specifications, |
| resource for any period of time will be increased if | | | | even when those are perfectly written, risking the |
| they are assigned tasks on the critical path. | | | | development of an application that does not satisfy |
| - Bad estimation - The estimations for effort required | | | | requirements. The unit, function, and system testing |
| for developing the software are either significantly | | | | may be slipshod, releasing errors into the QA |
| understated (bad) or overstated (also bad). | | | | environment that consume extra time to resolve. |
| Underestimation is the most common event. Work | | | | Different programmers may interpret the same |
| tends to be prolonged until it takes up all the time | | | | specification differently when developing modules or |
| allotted by an overestimation. | | | | functions that must work together. For example, a |
| - Missing or incomplete skill sets - The results of this | | | | section of functional specification may deal with both |
| risk event will be the same as the results of bad | | | | the input of one module and the output of another |
| estimation, but the risk will be mitigated differently. | | | | that are given to two different programmers to |
| The result of a junior programmer being identified as | | | | develop. The risk is that the discrepancy will not be |
| an intermediate programmer may be a significant | | | | found until the software is integrated and system |
| increase in the amount of effort required to produce | | | | tested. |
| their deliverables, or a complete inability to produce | | | | Testing here refers to Quality Assurance testing and |
| them. - These risk events should be captured by the | | | | User Acceptance testing. While these two activities |
| project manager at the outset of any risk | | | | are different from a tester perspective, they are |
| identification exercise, even though they will probably | | | | similar enough to lump together for our purposes. |
| be identified by someone else on the team. Making | | | | Actual testing effort may exceed the planned effort |
| them visible to the team in advance of any risk | | | | because of the number of errors found. An |
| identification exercises will avoid time wasted in calling | | | | excessive number of errors found during testing will |
| them out and may stimulate thinking about | | | | cause excessive rework and retesting. Test script |
| associated risks (".....what if Jane were to be called | | | | writers may interpret the specifications they are |
| away to a higher priority project, might that also | | | | working from differently than analysts, programmers, |
| cause Fred to be lost to the project?"). | | | | or the clients. User Acceptance Testers come from |
| Organizational Risks | | | | the business community so are susceptible to the risk |
| These are risks that are unique to the organization | | | | of business demands reducing or eliminating their |
| performing the project. They may include some of | | | | availability. |
| the risks in the list of common risks, and other | | | | Subject Matter Experts (SMEs) |
| sources, but will also include risks that have no other | | | | Subject Matter Experts are key to the success of |
| sources. | | | | the project because of their knowledge. Subject |
| The project manager should consult the archives of | | | | Matter Experts can contribute to all areas of the |
| previous software development projects for the | | | | project but are especially important to requirements |
| common risks, where project records have been | | | | gathering, analysis of change requests, business |
| archived. Gather the risk registers of all the previous | | | | analysis, risk identification, risk analysis, and testing. |
| projects (or at least enough to provide you with a | | | | The key risk for SMEs is that the SMEs key to your |
| representative selection of risk registers) and try to | | | | project may not be available when they are |
| match risks in each register. It is highly unlikely that a | | | | promised. This will be especially harmful when the |
| risk will be common across all projects where there is | | | | SME is responsible for a deliverable on the critical |
| a good selection of registers but you should closely | | | | path. |
| examine risks that appear in two or more registers | | | | Risk Workshops |
| for applicability to your project. | | | | Risk workshops are an excellent tool for identifying |
| Survey the project managers responsible for past | | | | risks. The workshops have the advantage of |
| software development projects in your organization | | | | gathering a group of Subject Matter Experts in a |
| where archives are not available. It is possible that | | | | room so that their knowledge is shared. The result |
| these project managers may have archived project | | | | should be the identification of risks that would not |
| artifacts including their risk registers, in their personal | | | | have been discovered by polling the SMEs individually |
| space even if the organization does not have a | | | | and the identification of mitigation strategies that can |
| structured approach to archival. Getting the benefit | | | | address multiple risk events. |
| of seasoned project manager's experience from past | | | | Advice on how to conduct productive workshops is |
| projects will also be beneficial for deciphering the risk | | | | outside the scope of this article but there are a few |
| captured in archived risk registers. | | | | tips I'll give you that may help you get started: |
| Risks will not be stated in duplicate language across | | | | |
| different registers (or across different project | | | | 1. Invite the right SMEs - you need to cover all |
| managers for that matter). You will need to analyze | | | | phases and all activities of the project. |
| the risk event statement to determine where two or | | | | 2. Communicate all the details of the project you are |
| more risk events are identical, despite different | | | | aware of. These include deliverables, milestones, |
| descriptions. | | | | priorities, etc. |
| SDLC Specific Risks | | | | 3. Get the project sponsor's active backing. This |
| Your software development project will be exposed | | | | should include attendance at the workshop where |
| to some risks and shielded from others depending on | | | | feasible. |
| which SDLC (Software Development Life Cycle) | | | | 4. Invite at least one SME for each area or phase. |
| methodology you choose to use for your project. | | | | 5. Split the group into sub-groups by area of |
| Risk avoidance is a significant consideration when | | | | expertise, or project phase where you have large |
| choosing an SDLC for the project and your project | | | | numbers of SMEs. |
| should choose the SDLC which avoids or reduces the | | | | 6. Make certain the different groups or SMEs |
| impact of the risks most probable in your case. To | | | | communicate their risks to each other to encourage |
| that end the identification of risks and the choice of | | | | new ways of looking at their areas. The risk |
| an SDLC are like the chicken and the egg: it is difficult | | | | workshop does not end with the identification of |
| to determine which comes first. Here's a tip for | | | | risks. They must be analyzed, collated, assessed for |
| sequencing the two. Choose your SDLC based on the | | | | probability and impact, and mitigation or avoidance |
| type of software system being developed and the | | | | strategies devised for them. |
| organization you are developing it in (How | | | | Surveys |
| experienced is the organization with the tools and | | | | Surveys or polls are an acceptable alternative to risk |
| components involved? How experienced are they | | | | workshops where your Subject Matter Experts are |
| with each SDLC? What are the project priorities?, | | | | not collocated. The lack of synergy that you get with |
| etc.). Once you've decided on an SDLC you can | | | | a workshop must be made up by you, however. |
| identify the risks associated with it and if the level of | | | | You'll need to communicate all the information that |
| risk associated with it exceeds your organization's | | | | could be helpful to the Subject Matter Experts you |
| risk tolerance, you can re-visit your choice. | | | | identify at the outset of the exercise. Once that is |
| There are risks inherent with each different type or | | | | done, you can send out forms for the SMEs to |
| category of SDLC. We will talk about a few of the | | | | complete which will capture the risk events, the |
| most common risks for the most popular types or | | | | source of the risk, the way the risk event might |
| categories of SDLC. | | | | impact the project objectives, etc. |
| Waterfall | | | | Collate the risks after you receive them, and look for |
| Projects using the Waterfall methodology for | | | | risk events which are either different approaches to |
| development will be most prone to any risk event | | | | describing the same risk, which allow you to combine |
| impacting the schedule and that is because there are | | | | the two risk events into one, or can be addressed |
| no intermediate checkpoints in the method to catch | | | | by the same mitigation strategy. |
| problems early on in the build phase. Delays to any | | | | Lack of participation is another disadvantage of the |
| activity from requirements gathering to User | | | | survey or poll method. You may be able to get by |
| Acceptance Testing will delay the final delivery for | | | | with a single SME in one project phase or area of |
| the project. Risk events which fall into the "delay" | | | | expertise but will have to follow up on reluctant |
| category will include: delays due to unfamiliarity with | | | | contributors. Don't hesitate to ask for your project |
| tools or components (e.g. programming languages, | | | | sponsor's help in getting the level of participation you |
| test tools), delays due to underestimation of effort, | | | | need. You may even get them to send the invitation |
| delays due to inexperience, and delays due to | | | | and survey forms out initially. |
| requirements contributors missing deadlines. | | | | Team Meetings |
| Delays are not the only risk events a waterfall | | | | So far all the sources of identified risks we have |
| project is susceptible to. Waterfall projects are not | | | | discussed have been associated with the planning |
| well designed to propagate learning across the | | | | phase of the project. Executing properly during the |
| project so a mistake made in one area of | | | | planning phase will allow you to gather a |
| development could be repeated across other areas | | | | comprehensive list of risks, but they will tend to |
| and would not come to light until the end of the | | | | more accurately reflect risks to the earlier project |
| project. These mistakes could mean that | | | | phases than to later phases. Once you've created |
| development could take longer than necessary or | | | | your initial risk register you must keep that document |
| planned, that more re-work is necessary than was | | | | current as you learn more about the project by doing |
| initially allowed for, that scope is reduced as a result | | | | the work and risks become obsolete because the |
| of discarding bad code, or that product quality | | | | work exposed to the risk has been completed. |
| suffers. | | | | Team meetings are the ideal place to update your |
| The Waterfall method tends to be used on larger | | | | risk register. The issues that will be brought forward |
| projects which have a greater duration than other | | | | as the team discusses its progress towards |
| development methodologies making them prone to | | | | completing its deliverables are often related to the |
| change. It is the job of the Change Management | | | | risks of meeting the deadlines for the deliverable. You |
| process to handle all requested changes in an orderly | | | | may want to set apart a segment of your meeting |
| fashion but as the duration of the project increases | | | | for reviewing the impact and probability scores of |
| so too do the chances that the project will be | | | | existing risks to determine the impact the passage of |
| overwhelmed with requests for change and buffers | | | | one week has had on them. You should also monitor |
| for analysis, etc. will be used up. This will lead to | | | | the team for any new risks they can identify. Risks |
| project delays and budget overruns. | | | | that went unnoticed when the work was first |
| Rapid Application Development (RAD) | | | | planned may become visible as the start date for the |
| The intent of Rapid Application Development is to | | | | work gets closer, or more is learned about the work. |
| shorten the time required to develop the software | | | | The project may identify new work as the planned |
| application. The primary benefit from this approach is | | | | work is done which was not contemplated when |
| the elimination of change requests - the theory being | | | | risks were initially identified. |
| that if you provide a quick enough turn-around there | | | | You may want to conduct separate risk strategy |
| will be no necessity for changes. This is a double | | | | meetings with your SMEs in cases where the team is |
| edged sword though. The fact that the method relies | | | | insufficiently acquainted with project risks to make |
| on the absence of change requests will severely limit | | | | them active contributors to an up to date risk |
| the project's ability to accommodate them. | | | | register. You should use this approach in addition to |
| The risks that will be the most likely to occur on a | | | | your team meetings when your software |
| project using this methodology will have to do with | | | | development project is large enough to require |
| the software applications fitness for use. The market | | | | sub-projects. Review each active risk in the register |
| or business could change during the project and not | | | | and analyze it for the impact the passage of time |
| be able to respond to a resulting change request | | | | has had on it. Typically as work approaches the |
| within the original schedule. Either the schedule will be | | | | likelihood of the risk event and/or the impact will |
| delayed while the change is made, or the change will | | | | increase. As more of the work is done, the likelihood |
| not be made resulting in the build of a system that | | | | and impact will tend to decrease. |
| does not meet the client's needs. | | | | You should monitor the project plan for work that |
| The RAD method requires a relatively small team and | | | | has been completed. Risks to the work just |
| a relatively small feature set to support a quick | | | | completed will be obsolete and should no longer form |
| turn-around. One possible result of having a small | | | | part of the discussion of risk probability and impact. |
| team is a failure to have a needed skill set on the | | | | |