The uncomfortable truth is that not enough attention is given to identifying the risks that can occur on any IT project. What is that euphoric sense of optimism at project inception that resists even the discussion of risk; or, if risk is discussed, to pay it lip service only?
Isn’t our industry plagued with examples of failed projects and projects that have not lived up to their expectations? Risk planning, when done well and given proper focus, offers one of the greatest tools for success for any IT project.
In a previous tip, “This is Why a Risk Management Plan is Important”, I discussed the technical and process aspects of risk management planning. I also noted that this exercise has great ramifications to the people aspects of project management as well. I have participated in projects in which the lack of risk management planning has resulted in CLMs (what we in consulting refer to as “Career Limiting Moves”) for team members, and poor outcomes for the end-users of the eventual system.
I speak from experience when I say that from a contracting organization’s perspective, more effort is often put into risk management planning for it will price the project, than in anticipating risks during project execution. That’s not all wrong; after all, the contractor has shareholder value to protect. On the other hand, our clients voted for us with their dollars and deserve no less focus on risk management for their projects.
To my mind, detailed risk management planning begins with the risk identification. This is not a trivial exercise, in that risks that may affect the project must be determined early. Equally important is the unambiguous, clear documentation of those risks such that they remain visible to the entire project organization during project execution.
The identification of risks is nothing more than the anticipation of events that can occur that may have detrimental effects on project timelines and budget, or opportunities to improve upon planned timelines and budgets.
Imagine a world in which there are no project risks. That, my project management sisters and brothers, is a world that does not need Project Managers.
I firmly believe that participation in risk identification activities should begin with the project team itself. This includes the Project Manager, project team members, and the client staff assigned to the project.
But it need not stop there. Each project has the perspective of stakeholders who have opinions as to the types of risks that can occur and that they can tolerate. What about the end-users? They will eventually be using the system in their day-to-day job performance – should they not be included in the identification of risks that might pertain to their use of the system? By involving these types of participants, a sense of ownership and responsibility for associated risks and responses to risk will occur.
It has also been my experience that the identification of risks is not a one-time process at the beginning of the project. Risk identification is an iterative process. New risks evolve as the project progresses. The exercise to identify risks should occur periodically, especially for longer projects. Risks should be identified, documented clearly and unambiguously, and reviewed as to their ongoing potential effect on the project.
For example, a typical risk that I have encountered on every project is the potential lack of client resources. The organizations that hired us did so for our firm’s expertise in the industry and our proved track record in managing and delivering IT projects. Often these organizations would assume that our expertise could substitute for their own, thus relieving them of the responsibility to lend full time resources to the project effort.
Not only did we identify this as a potential risk on every project; but after several years of experiencing this risk event, we documented some foolproof mitigation factors. We were able to show the organizations how contributing their brightest and best employees to the project on a fulltime basis would result in the best product for their organization. At the same time, we illustrated why contributing less capable staff would invariably have detrimental results.
Such risk identification was often predictable because we as a project team had experienced it on previous projects. But how does one go about identifying project risks that project team members had not experienced before?
On one very large project, I was part of the Project Management Organization (PMO) that was responsible for delivering an enterprise-wide, mission critical system. Well into project execution, a major piece of legislation was enacted, which would profoundly affect the project we were managing. New federal rules were being promulgated even as we were implementing the new system.
It was a learning experience for all involved; but because we took risk identification seriously, we were able to absorb most of the effects of the new legislation in stride, implementing on time and within budget. Risk identification early, and ongoing risk management, was critical to that success.
So what activities are useful to begin the exercise of identifying project risks? The above examples offer some clues. Some risks will always be prevalent and need to be reviewed for each new project. Some risks will not have been previously encountered. Identifying these and monitoring them regularly is paramount.
I like to begin by scheduling focused information gathering sessions. Such sessions may include brainstorming with the project team and the client organization, and/or may use a Delphi process to reach the consensus of those involved. On many projects I have also interviewed experienced members of the client organization and the stakeholders to help identify risks from their perspectives.
One organization for which I worked maintained a comprehensive risk identification checklist. The checklist was invaluable in reminding project teams to review all types of potential situations on projects, such as:
- understanding how the project would handle late delivery of development hardware,
- defining options for replacing the identified Project Manager should we win both bids on which she is bid,
- assessing how to deliver according to the client’s aggressive timelines,
- resolving ambiguously defined requirements,
- and many others.
The checklist was very long, but it had been developed over years of project delivery that had encountered these types of risks.
Part of this checklist also included a review of the assumptions that we had documented in bidding the project. Were these assumptions valid? Was there inconsistency among some of the assumptions? Were some assumptions incomplete, or too conservative?
Another useful technique in identifying project risks is a SWOT analysis. A SWOT analysis reviews the Strengths, Weaknesses, Opportunities, and Threats to the project based on the caliber of the project team itself, the capability of the client organization, the business areas most responsible for the project outcome, or any combination of these. Strengths may lead to an identification of opportunities, while weaknesses may point out potential threats.
For example, on one project I worked on, a highly experienced technical resource was freed up from another project, and we were able to substitute him for a lesser experienced person on the project. This presented an opportunity to reduce task durations along the critical path, saving several weeks on the schedule. However, the opposite is more often true, and the lack of a key resource must be identified as a threat.
Although I have not often seen a formal SWOT analysis used in risk identification, I have seen all of its elements (strengths, weaknesses, opportunities, and threats) utilized implicitly. Such analysis reviews the degree to which organizational strengths can offset threats, and identifies opportunities that may help overcome weaknesses.
All of this analysis is for naught if not documented well. The best approach to document potential project risks is through the use of a Risk Register. The Risk Register lists the identified risks, describing events that may occur and the potential impact on the project should they occur. It also documents a list of potential responses to those risks. What I’ve also found helpful, though typically not described in the process of risk identification, is to document contingency plans that accompany the risk responses. Not all identified risks require contingency plans, but documenting them while they are fresh is very helpful.
The result of this analysis is direct input into the Risk Management Plan. The Risk Register and the Risk Management Plan are living documents to be reviewed and updated throughout the duration of the project.
What all of this comes down to is that the identification of potential project risks must not be construed as another box to check in the project management planning process, or another rote exercise that “proves” that we are managing the project. Identification of risk is a critical element in managing projects, and deserves the attention of the project team and the organization for which the system is being developed. It very much entails the people aspects of project management in that every project is different, every project has its own potential risks, and every risk must be comprehensively and creatively ferreted out by the expert judgment of people.
Risks identified are risks that can be managed. Risks that can be managed are risks that will not hamper project delivery or objectives for the end-user.
Get Your Free Guidebook
Subscribe and receive your free guidebook,
5 Ways to Master the Art of Managing People, Projects and Profits.