Open any software management text, and you'll see long analyses of why software projects fail.  However, every cause of failure has something in common: They are all risks.  Every project failed because something went wrong -- after all, very few projects actually plan to fail.

The risks that caused a project to fail were either known in advance (and were not controlled) or they were unexpected.  In the previous article, we discussed tools you can use to identify hidden project risks.  Today, we'll discuss the areas of your project where those risks are likely to be hiding.  Apply the tools you've learned to these risk categories, and you'll be on your way to a comprehensive assessment of the risk in your project.

This list may appear at first to be overwhelming.  Remember that the goal of risk identification is to understand where your project's greatest risk exposures lie.  Yes, you should examine each risk category when looking for project risks, and you will probably identify several potential risks in each category.  But once you've identified your list, you need to understand the probability and impact of each, and focus your efforts on the risks with the highest exposure.

Quantitative versus Qualitative Risks

The first three groups of risks (Cost / Schedule, Scope, and Quality Risks) are the ones which immediately come to mind for most project managers, when analyzing risk.  These are the risks directly associated with the objectives of the project.  They're also the risks that can be assessed quantitatively, as you can directly measure whether or not the objective is being met.  Quantitative risks also involve more considerations for mitigation and tracking than qualitative risks (for example, by including a risk allocation in the schedule and using formal trigger points), but this is a topic for a future article.

However, quantitative risks have an important characteristic.  That is, quantitative risks are often symptoms of more fundamental, qualitative root causes.  An example could be a negative company culture, which could cause demotivated employees to drag their feet in completing tasks on time.  When analyzing quantitative risks, be sure to perform some level of root cause analysis (as we discussed last time).  Your chances of success will be much improved if you mitigate the risk's cause, rather than its symptom.

Here follows, in no particular order, the main categories of risks that you could encounter.

Cost and Schedule Risks

Cost and schedule risks could be considered separately, of course.  I've chosen to combine them here because of the close (albeit non-linear) relationship between the cost and schedule of a feature.  The core problem behind cost is whether a task will take more effort than expected to complete.  The core problem behind schedule is whether the necessary resources will be available at the right time to execute the task.

Some cost and schedule risks seem obvious.  Poor estimates of cost, time, and resources can lead to cost and schedule slips, as can unrealistic expectations (which are often influenced by the legitimate business need to cut costs and deliver early).  But for each of these risks, work to understand and target the root cause.  After all, you may be able to alleviate unrealistic expectations by improving the relationship with your customer, or improve your estimates by bringing in historical data from other projects.

Here are some other sources of cost and schedule risks that you should consider:

• Correct task sequencing: Do have a good understanding of the required task sequencing,  so that tasks can start on time?
• Unknown dependencies: Are there any internal or external dependencies that you have not yet identified, which may cause a task to start late?
• Critical path: Is your critical path understood and controlled?  Some tasks can slip with minimal impact, but slips along the critical path will affect your schedule.
• Resource dependency: It's very possible that a resource may not be available to start a task on time, as other tasks (possibly unrelated to the project) may slip.  Are you controlling this risk?
• Consider all resource types: Software managers often use the term "resources" when referring to people.  But there are a lot of pieces to delivering a successful project.  Make sure you have sufficient machines for builds, testing, and integration, sufficient software licenses, and adequate test data.
• Integration: Integrating and stabilizing external deliverables can be time consuming.  Are these adequately scheduled?  What are your plans if integration goes awry?
• Listen to your instinct: Does your intuition and experience tell you that something doesn't look right?  If so, dig deeper.

Scope Risks

Scope risks are indeed quantitative risks, as a project's requirements can be identified, counted, and the status of each can be independently reported (for example, how many features have been implemented, tested, and accepted by the customer so far?).  Viewing scope in a quantitative way also helps mitigate scope creep, as the binary nature of accepted versus not accepted avoids the trap of the feature stalling at "95% complete".

Scope risks generally involve how well the required features are understood and specified, and how prone they are to change.  It is important to remember that this includes implied requirements.  These are requirements that are unarticulated, but are assumed (by the customer) to be included in the project.  Be sure to recognize that implied requirements do exist, even if they are not obvious at first.  Work to identify these -- they could come back to haunt you in the future.

Every new change request is a change to the baselined scope of the project.  Understand how well managed your scope change control process is.  What change requests are you required to integrate?  Are these likely to appear?  Also, remember that the customer and the development team will often have different opinions of what is an enhancement and what is a bug.  A feature may be "working as designed", but if it doesn't meet the customer's (possibly implied) expectations, then they may expect it to be handled as a bug.  These large-scope defects can derail a project, so it is important that you identify and mitigate unplanned enhancements early.

Quality Risks

Quality risks are perhaps the most often quantified in a project.  Metrics such has the number of high severity defects in the product are common measures in a project.  However, quality risks are also the most likely to have underlying root causes that need to be mitigated.  After all, it is not simply a matter of telling people to add fewer defects.  The process, the culture, the individual, the technology, the project's dependencies, and many other factors all come together to cause potential quality problems.

The first question you need to ask is what is the required reliability of the product.  We all want perfect code, but quality also has a price.  The higher the quality and reliability requirements, the greater the associated risk, so scale the level of quality risk management appropriately to the requirements of the project.

The next question to ask here is when are problems found.  Are they found early in the project or are they found later?  Are you testing throughout or do you test at the end?  Remember that the earlier in the schedule that you find and fix a defect, the cheaper it is to find and fix.  At the extreme, the least expensive approach is to figure out how to avoid introducing the defect in the first place, which requires proactive mitigation of your quality risks.

Business Risks

The risk categories that follow are qualitative in nature.  This has a few implications.  The first is that they are the risks that are most likely to be ignored in your risk planning (perhaps, with the exception of technical risks and dependency risks).  The second is that they are the risks that are most likely to be the root causes of the quantitative risks you identified earlier.  This makes identifying and mitigating your highest exposure qualitative risks absolutely critical to avoid project failure.

The business risk category is quite broad, and of course, depends heavily on your market.  If your market is heavily regulated, is there a risk that a regulation may change, suddenly restricting where you can sell your product?  (I encountered this myself, in one project.)  As well, what are your competitors doing?  Is there a chance that they can beat you to market, or introduce similar functionality, so that you suddenly need to differentiate your product in another way?

Business risks require project managers to look beyond the confines of their project.  The project may have delivered within all its stated objectives, but if a change in the business environment has made that project obsolete, then the team should not be celebrating a victory.  To be successful, businesses need to stay in business, and projects which don't achieve their business goals will not help the company stay afloat.

Process and Environment Risks

Most groups recognize that their processes and other aspects of their environment (such as tools) impact their ability to successfully deliver a project.  Note that success does not directly correlate with the level of process.  You need to have the level and type of processes that are appropriate to your team and your project.

As an example, most agile development gurus will acknowledge that the agile approach is an ideal fit for new product, R&D-oriented projects.  Agile approaches integrate learning and uncertainty into the development process.  But at the other extreme, some projects are well defined, well understood contract engineering activities.  In these projects, a more traditional methodology may be a better match.  The point here is that one approach is not inherently better than the other -- they are best suited to different projects.  If your process is not a match for the needs of your project, then you have a risk that you need to track.

As well, regardless of the methodology you use, where are its weak points?  Do you spend too little time (or too much) doing documentation and reviews?  Is your tracking process sufficient, so that you identify project slips early?  Is your integration process appropriate to your supplier / dependency risks?

This also applies to the maturity of your tools.  Do you have a memory-intensive application?  If so, do you have good tools to profile your memory use and identify if you've introduced memory leaks?  Alternately, does your process dictate that you use these tools, even though they are not risk areas for your project?  If your development environment does not match the needs of your project, then your facing more potential risks.

The most important process risk that you need to be aware of is: Do you have a process in place to manage and mitigate your risks on an ongoing basis?  If your risk management process is still immature, then you need to spend extra personal effort to make sure it gets done.  Too often, risk planning is done at the start of the project (if it is done at all), and then it is ignored.  But when the project fails, it fails because of a risk that should have been identified and should have been mitigated.  Yes, the possibility that you don't follow up on your risks is probably the biggest risk you face.  Remember this, and act on it. 

Technical Risks

Fortunately, most project teams are fairly comfortable identifying technical risks.  I won't go into too much depth here, except to identify some possible candidates to help kick-start the conversation with your team.  These include:

• Size and complexity of the algorithms
• Size and complexity of the interfaces
• Size and complexity of the databases
• Performance requirements versus resource constraints
• Testing requirements versus testability of the product
• Product requirements versus capabilities of the technology
• Behaviours or limitations of any virtual machines versus physical machines

The challenge for technical risks is not in identifying the risks.  The challenge is following through on the mitigations you identify.  Once you've identified your highest exposure technical risks, make sure you allocate and track the tasks necessary to mitigate them. 

Human and Cultural Risks

I was speaking with Sandeep Naik at Varian about risk management, and he also observed that when teams identify their risks, the risks are often limited to objectives risks and technical risks.  However, as we've seen, the root causes of project failure are often qualitative risks.  And in software development, which is, first and foremost, an intellectual activity, those qualitative risks ultimately come down to human issues.  In spite of this, the only human risk that appears on many risk registers is "Attrition", and even then, it is only included as a checklist item, with no real follow-up.

Sandeep suggested a good list of human risks that you need to consider, and I've added some others as well:

The match between the individual team members' skills and their tasks: This is not only the match for their technical skills, but the match for their soft skills as well.  If the project requires a lot of collaboration and brainstorming, is the individual comfortable with that, or would they prefer to go off and work by themselves?  Are they able to remain focused on their tasks, or do they tend to go off on uncontrolled tangents?  Is this the kind of work that they enjoy doing?  If the project is a poor fit for the interests of the individual, then you need to be more aware of the risk that they may not perform as well as others.

The capabilities of the team leadership: This could require some self-awareness, if you are they key team leader.  Your management style is critical here.  Is it appropriate to the needs of the project and the individuals on the team?  A pace-setting management style can be appropriate for short bursts for aggressive targets, but it may cause team members to burn out.  Alternately, a more collaborative approach can be ideal for research-oriented projects, but may not be sufficient when deadlines get close.  Be honest with yourself about the strengths and risks of your leadership style, and mitigate the risks by adapting to the situation.

The experience that the team has had in working together: How much experience does the team have in working together?  Has the team had a chance to bond yet?  The dynamics of each team are different, and it takes time for a group of people to evolve from independent individuals to a smoothly operating, high performance team.  During this initial stage of "getting used to each other", personality conflicts may arise, or individuals may be scared to ask questions.  Activities like team-building exercises or engaging people at a personal level can go a long way to mitigating these risks.

The culture of the team: Once a team has bonded, there is still the risk that the team's culture may not be very positive.  Do they get along well?  Is the team solution-oriented or do they tend to seek blame (inside or outside the team).  Do they question each other or do they simply focus on their own work?  Can they speak openly and constructively to each other, without fear of looking bad?  If team members are not able to work comfortably together, then you have a problem which will probably interfere with your deliveries.

Co-location versus distributed teams: If the project team is distributed across multiple sites, do the individual teams work well together?  Are lines of communication in place and functioning well?  If the teams are in different cultures, this can also be a source of conflict, especially if this leads to communication problems.  Do the teams trust each other?  It is very easy to lose trust when you don't see people on a daily basis.  In fact, Human Resource Executive Online found that remote working relationships are almost 3.5 times more likely to encounter problems than relationships in the same location.  This applies even more strongly to remote suppliers, collaborators, and customers, as the team members have not had the opportunity to build close relationships and trust.  Be aware of this and mitigate it.

Cross-functional teams: Teams with members from different business functions can be very powerful, because it exposes the teams to different perspectives and challenges traditional assumptions.  However, it introduces additional risks, because the individuals now have different motivators, ways of thinking, and communication styles.  This can cause personality conflicts, especially if the individuals have not worked closely together before.  They may also have already formed their own preconceptions about team members from other departments ("Those salespeople only care about signing the deal, not about whether we can actually deliver!").  As with all human and cultural risks, keep your eyes open and mitigate early.

The level of communication required within and outside the team: Communication issues can arise any time, with any number of stakeholders.  A stakeholder is anyone who is affected by or who can influence the outcome of the project.  Stakeholders can be internal or external to the team and the organization.  They include senior management, the customers, the users, the team members, and often the public as well.  Good communication and mitigation of stakeholder risks go hand-in-hand.  Project stakeholders are often overlooked in project and risk planning, but they can often derail your project, especially in public, high profile activities.  But even in lower profile projects, if there are people in your organization whose buy-in throughout the project is critical, this is a risk you must mitigate.  Understand who your stakeholders are, and communicate with them effectively.

Dependency Risks

Dependency risks are analogous to supplier management risks, for those familiar with PMI's PMBOK terminology.  Project dependencies can be either internal or external to your organization, and could involve software (e.g. toolkits and libraries), hardware, and other forms of intellectual property (e.g. algorithms).  This also includes deliverables from non-development groups, such as marketing, sales, quality and regulatory, and documentation teams.  Any deliverable from another team which affects the successful delivery of your project is a potential dependency risk.

You also have to look beyond the release date(s) for deliverables you depend on.  Potential risks include the turnaround time for required changes, and the quality and scope of the deliverables.  Is the development model you are using appropriate for your project?  For example, is the interface very complex, possibly requiring a continuous integration approach, or is the interface and behaviour very straightforward, which would tolerate less frequent releases?  Also ask yourself if better suppliers are available.  Even if you are not able to change suppliers, knowing where your supplier's weaknesses are allows you to mitigate them.  For example, if you know your supplier typically delivers on time but sometimes has quality problems, then you know where you should focus your mitigation efforts.

Culture plays a large role for dependency risks as well.  How good is your relationship with your supplier?  Are you working to a common goal, or will the focus be on the letter of the contract?  Also, what type of contract do you have?  Fixed price contracts, time-and-materials contracts, and profit and risk sharing contracts all lead to very different project dynamics and behaviours.

Lastly, each of the risk categories above (cost and schedule, scope, quality, business, etc.) applies to your suppliers as well, so make sure you ask these questions.  For example, a business concern for your supplier may be the demands of another customer, threatening to pull resources off your deliverable.  Dependency risks can be critical to your project, and must be understood.

What Next?

This list can certainly appear overwhelming.  That's understandable -- you can't effectively mitigate every risk!  There simply is not enough time in the day.  Identify your risks, analyze their probability, impact, and exposure, and use the exposure to evaluate the priority of each risk.  Plan your mitigations can contingencies for your top priority risks, and simply monitor the others to make sure their exposure doesn't suddenly increase.

Risk mitigation is critically important for successful project delivery.  Despite this, teams routinely ignore their risks, or at best, fail to follow through on their list of mitigations.  Be honest in identifying risks, solution-focused in developing mitigations and contingencies, and follow through on managing your risks.  If you are prepared for the risks that materialize, then nothing stands to prevent you from a successful delivery.

Lastly

What types of risks do you typically encounter?  How do you mitigate them?  Let me know!  Of course, if you have any questions, or if you would like more information on how to implement these or other software development processes in your organization, please feel free to contact me at Charles@CharlesConway.com.

If you know of someone who may find this article of interest, please forward it on!

Good luck!
Charles