Project Management | Feature

How to Keep Your IT Project From Becoming a Disaster

A disciplined approach to risk management can help you prepare for the worst and prevent unexpected problems from derailing your project.

• By Dian Schaffhauser
• 04/18/13

Good risk management is like getting ready for a storm: Stock up on flashlights, extra food and water, and anything else you need to get through the dark times. Or, in project management terms, "Think about the positive and negative things that can impact your project and the likelihood that those things might happen," says Adriene Radcliffe, director of governance, service management, and e-services at Yale University--and then prepare for them. "When very large, complex things threaten to end your project success [but] you have a path you can follow, it's a great feeling," she says.

What complicates risk management in a university setting is higher ed's broad assortment of potential stakeholders, those people who could be affected by the introduction of a new project or program. They're numerous, Radcliffe says. "At a complex campus like Yale, we have students who are technologically hip. We have the teaching faculty, who are at varying levels in their use of technology. We have researchers and labs for conducting research. We have students who also live on campus, so we have dining services. We serve the groups that administer and run the university." On top of those stakeholders are clinical-care staff and patients from the School of Medicine and the Yale New Haven Hospital, which are "intertwined."

The enormous diversity of constituents being served by a project "makes identifying risks and thinking about them from all those perspectives very challenging," she notes.

Compiling Risks
Administrators at Yale build out a list of risks "from the minute we propose a project," Radcliffe explains. Each new project is described in a "short sheet" that lays out what it's supposed to achieve, how it's going to be done, about how much money it may require, and what the high-level risks are.

Once a project works its way through the governance process, details are fleshed out in a requirements gathering phase. Even more risks are identified as the project manager holds meetings with the "functional side of the house," says Radcliffe. Stakeholders may mention something in an offhand way that could be problematic, and it's important to probe further to best understand their needs.

Risks may involve technology not working, challenges of working with vendors, or dependencies with other projects, teams, or technologies. Sometimes risks are internal to the project team--for example, concerns about the commitment level of a project sponsor. Such issues are not necessarily shared with others, but are monitored all the same.

Radcliffe warns that a portfolio should never be weighted too far with high-risk projects. "As the risks increase, it's not that your success rate goes down--but the more likely it is that you'll be unable to complete everything you think you'll be able to complete." Better to have a set of projects with a "decent balance of risk versus reward," she says. "You want to make sure you're introducing some projects with quick wins that don't have a lot of risk."

When a project is identified as having a lot of risks, it gets extra attention. "We think about it more," she says. "We might ask for more detail--especially if it's tied to one of our core mission areas." When a project fits into that category, the assessment of risks is deeper, "so we can get a better idea of whether we can be successful doing something or how much it will impact certain areas of our community."

Getting Out from Under Risks
Radcliffe counts off three tactics for managing risks: avoidance, mitigation, and transfer.

Risk avoidance calls for doing everything you can to make sure the risk remains a line item in a log rather than a reality. For example, if the risk is that users won't adopt a new technology, then "you spend a lot of time on organizational change management to make sure that risk does not come to pass," advises Radcliffe. "You avoid that risk by a significant amount of planning, communication, that sort of thing."

Mitigation requires figuring out ways to lessen the impact of the risk should it come true--what the worst-case scenario would be and how to deal with it. Sometimes you might choose to put a monetary value on that, if possible, to justify the mitigation. For example, if there's concern about a technology not working or a resource not being available, says Radcliffe, "you might decide to conduct more tests or cross-train more people."

Risk transfer is not common in a university setting, Radcliffe notes, but it still comes up. For example, the institution might decide to employ a third party to take on a given risk, as a form of insurance. She gives the example of a data breach: To ensure that every potential affected person is contacted efficiently and comprehensively, a school might choose to hire an identity theft company to handle outreach, "which helps shift the impact of the risk."

Big Risk No. 1: Resource Management
Managing the people working on a project is frequently overlooked. The project schedule will often show generic--unnamed--resources working on a particular task; but when that part of the work is ready to be done, the right person with the right specialty isn't available. Waiting for staff can pull the whole schedule out of whack.

However, Radcliffe offers a couple of possible tactics for avoiding that risk. It can be as simple as creating extra documentation about processes so a substitute "can pick up in a heartbeat." You might also build contingency time into the schedule "to plan for staff swaps."

She notes, "If you're prepared for it, you have a good plan in place, you have things really well documented, you have a little bit of lag time built in--you could use all of that and continue on pretty well."

Big Risk No. 2: Scheduling
Calendar risks are a big part of risk management in a university. Whereas every industry has a set of cycles it goes through, higher ed seems to have more than most. "We have the start of the semester, we have the break, we have the fiscal calendar, we have year-end close, month-end close, then the summer comes and half of our faculty have left or are on leave," explains Radcliffe. If the project involves faculty, for example, and it's not delivered before they're mostly gone, "you might lose the opportunity to deliver something and need to wait for an entire semester."

The same problems surface on the research end, she adds. "Research grants have specific cycles, specific due dates. If you have faculty working on a grant, there are certain dates and times they're completely unavailable, because they're working on their grant proposal. You've got to manage all of this."

Big Risk No. 3: Underestimating the Work
While managing risks related to resources and scheduling is tough, says Radcliffe, the biggest risk is managing project complexity. That is, the risk of a project being more complex, costing more money, and requiring more resources than you can afford. "That speaks to estimation," she notes, "and getting good at estimation takes a long time."

The antidote: time and attention. "The more vigilant your organization is about looking at what you thought it would take to do something, what it actually took, and then learning from that, the more your risk goes down--significantly."

"Honestly," she adds, "at some point anybody that comes to work at the university always says, 'I had no idea it was this complicated.' We talk about it in the interview process, they always nod their head, and then later say, 'I didn't believe you. I thought, gee, how tough could it be?' The complexities of the communities, the lines of business, the calendar--that all equals risks to projects. You've got to be on your game if you're going to be a project manager at Yale."

The Lifecycle of a Risk To monitor risk at Yale, project managers create a risk register or log for each project. This is a template filled out and maintained in a project SharePoint site or wiki, along with the other components of the project documentation. The register contains the risk name or title, a detailed description of the risk, an assessment of the risk level (low, medium, or high), and the likelihood of the risk occurring. Those last two characteristics help the project team pinpoint risks that are "high-impact, high-likelihood," which are, Radcliffe adds, "the stuff you want to pay attention to." The register is also used to record the strategy for monitoring the risk and what the risk plan is. The latter may be short enough to put right into the log; or it might be detailed enough that it becomes an additional attachment to the project plan and referenced in the log. For the most part, project teams at Yale meet weekly, and that's how often status reports are updated. The agenda of that meeting is to assess the schedule, the scope, and also the risk log. As a project progresses, Radcliffe explains, risks may lessen, may no longer be valid, or may come to pass; risks are dropped from the list and sometimes they're added. "A good project manager is constantly updating the risk register and managing it. It's part of managing the project," she says. Once a month, the overarching technology operations committee meets and examines issues and risks for all of the projects. When problems surface, that's when the governance hierarchy proves its worth. "If a project team can't resolve an issue, needs to make a decision, or has a risk that's currently being monitored because it's got a high likelihood of happening, the program committee will see it and possibly [offer] some advice on it," notes Radcliffe. If the risk holds the possibility of dooming a project, a higher-level strategic committee is asked to weigh in. For example, a project may need some special expertise--a person working on something else at the time. To pull that resource into the project may require "some clout," observes Radcliffe. "If managing the risk means you need to reach out across the university as an organization, you'd want to do that higher up in the food chain."