The risk officer role is a vital one for important projects, especially large and/or complex projects. Even the very best-intended project managers can find themselves unable to get out in front of project troubles when such a role is absent from project planning.
However, success at project risk management requires additional factors that are also described in this article, and that provide the means for a risk officer to be entirely successful in his or her goal of safeguarding project results on behalf of the project stakeholders and execution team.
Committing to Risk Management
Success at risk management depends on making the commitment to perform risk management, developing an ability to perform it, carrying out activities to perform it, and verifying that the management plan for each risk has been effective.
If any of these important elements is missing, risk management will be ineffective. A commitment to risk management consists of three elements:
Written Risk-Management Approach
The project plan must describe a specific risk-management approach, such as the one presented in this article. Simply writing a contractual requirement for the service provider to perform project risk management will not be sufficient. Service provider project leaders are generally overly-optimistic. Such a requirement puts them in a conflict-of-interest position from several points of view. Even if they could view the project from an external perspective, reporting potential service provider problems to the customer is at odds with the public relations interests of the service provider. If the customer is highly risk-averse and also inexperienced in dealing with projects of this type, excessive time could be spent hand-holding an overly nervous customer.
Funding Risk Resolution
The budget for the project must include funds earmarked for risk resolution. If no funds can be earmarked for risk resolution, the project cannot be considered to have made a commitment to risk management. Many projects have “contingency funds”—but these are typically spent after problems occur, and the whole idea is to avoid the problems in the first place. It’s smart project economics whereby “a stitch in time saves nine”.
Updating Project Execution
When risks are assessed, their impacts must be incorporated into project plans. Some projects carry out risk assessments but don’t do anything with the risk information they obtain. That is roughly comparable to sending your calls to voice mail and never checking your messages.
Developing the ability to perform risk management is partly straightforward, partly subtle. The straightforward part is that the project team carries out the activities described in this article. The subtle part is that some organizations inadvertently discourage the flow of risk-oriented information to higher management and other people who need it. The plan described in this article helps to ameliorate that problem. The approach employs some project practices that are intended primarily to manage risk. Other practices described are not specifically risk-management practices but have been built into the approach because of their risk-management benefits. Practices recommended specifically for risk management include the following:
- Planning for risk management in the Software Development Plan (which is what this article has been describing)
- Identification of a risk officer
- Use of a Top 10 Risks List
- Creation of a risk-management plan for each risk
- Creation of an anonymous risk-reporting channel
Risk Officer
The project should identify a risk officer, who is a member of the project (preferably someone other than the project manager) responsible for spotting emerging risks. The risk officer must be part Chicken Little (“ the sky is falling”) and part Eeyore (“ it’ll never work”). The risk officer’s function is to play devil’s advocate during planning meetings and when reviewing planning materials. Continually looking for potential problems, the risk officer tries to pick apart the risk-management plans for each risk. He or she should have management’s respect; otherwise, the risk officer simply becomes the project’s “designated pessimist.”
Because the project manager’s job is to steer the project to success, the project manager can have difficulty adopting the devil’s advocate focus that the job of risk officer requires. The two jobs require different orientations.
Identification of a risk officer doesn’t eliminate the need for other project personnel to try to reduce project risk. The organization should encourage risk identification by all project personnel.
Top 10 Risks List
The key risk-management tool is the Top 10 Risks List, which is a list of the top risks the project faces at any given time. The simple act of maintaining a list of current risks helps to keep risk management at the forefront of the project manager’s mind. The project team should create a preliminary risks list before beginning requirements work and then keep the list current through the end of the project.
It isn’t important that the list contain exactly 10 risks. It can contain 5 risks or 15. What is important is that it is maintained regularly.
The project manager, risk officer, and the project manager’s boss should review the Top 10 Risks List every two weeks or so. This review should be on their biweekly schedule so that the activity isn’t abandoned. The act of updating the risks list, prioritizing the risks, and updating the “Risk Resolution Progress” column forces them to think about risks regularly and to be alert to changes in the risks’ importance.
In support of the survival skill of project-wide visibility, the list should be made available to all project personnel. People who are not in the management chain should be encouraged to sound an alarm if they identify significant problems at their level. This list can be simple, such as the one shown below.
Anonymous Risk-Reporting Channel
This is a challenging topic with regard to security systems projects. Reporting good news project-wide and up the management chain seldom poses problems, but reporting bad news often does.
Very large security projects often have penalty clauses for the contractors. Anyone reporting on risk factors can have the appearance of undermining the project, “not being a team player”, and so on.
However, if you’re in the contractor’s top management, and some technical person predicts 10 to 20 percent of the way through the project that the systems integration isn’t going to work, when do you wan t to know about that prediction? After 10 to 20 percent of the project has elapsed, or after 150 percent has elapsed, penalty clauses have kicked in, with the technical person saying, “I tried to tell you but couldn’t get past my project manager.”
In over 26 years of working with security technology, nearly every sizable project that has run over schedule had points at which, if the risk factors had been addressed, there was plenty of time in which to resolve the problems. There was no real reason for the projects to get into serious trouble, aside from an unwillingness to think of potential project problems as risk factors and address them early in the project.
The project team should establish an anonymous communication channel that project members can use to report status and risk information up the management chain. This “channel” can be as simple as a suggestion box in a break or printer/copy room. If project management is exaggerating the project’s progress in reports to upper management, a concerned team member can report that.
One organization that I know of had a history of million-dollar-plus projects running over cost and schedule. A $15 million-dollar project came up with a fixed and absolutely unmovable completion deadline. Senior management insisted on engaging outside resources to provide infallible project status information and to proactively address project risks. The organization had to step outside of its comfort zone many times to deal with risks large and small. The reporting of risks from inside the project team to senior management stakeholders was the subject of great argument and even some furniture-tossing fury. But senior management allocated funds to address risks—including several that were beyond the scope of the project contractor to contend with.
The result: it was the first time in the organization’s 75-year history that a million-dollar-plus project was on time and within budget.
Anonymous risk reporting is a best practice for product development teams, where the company’s future can hang on the success of a new product or product upgrade. The business impacts of project failure can be severe to catastrophic. Unfortunately, electronic physical security systems are not critical to corporate sales or manufacturing success. The “we can always post a guard” mentality, although an outdated holdover from an earlier era, still can be found in management circles.
Many confidential anonymous reporting hotline services exist, and many organizations employ them for employee misconduct and personal threat situations. For critical security projects, there is no reason not to use such a service, and your organization may already have one in use.
Regardless of whether or not the reporting is anonymous, a process must exist whereby risk factors can be brought to light, so that senior project stakeholders can bring otherwise unavailable resources into the picture, and can do their job in looking out for the organization’s interests.
—Ray Bernard
This article is based upon material from the book Software Project Survival Guide, by Steve McConnell, a leading software project specialist who has written several award-winning books documenting sound software development approaches and best practices. It has been revised as appropriate for the realities of electronic physical security systems deployment projects.