Risky Business

In: Articles

By Andy Budd

Published on August 18, 2004

It’s risky out there

It sounds like a cliché, but the world we live in is a risky place. To survive in this hostile environment, we’ve become very good at identifying and managing risk.

For everyday tasks, we don’t really think about risks on a conscious level. When we cross the street we quickly check both ways to avoid the risk of being run over. We’ve done this so many times that it has become habit.

For activities that we perceive as out of the ordinary or slightly more risky, we come up with simple methods of helping mitigate the risk. Due to a couple of well-publicized train accidents in the UK, whenever I travel up to London I try to sit in one of the middle carriages as I perceive this to be the safest place. It’s a small thing, but it’s my method of offsetting some risk.

These techniques are fine for simple situations. However, for unusual, complex or risky activities, we need to do much more careful planning.

As you may know, I like to travel. When I go away, I assess the risks involved and then plan for these risks. I book travel insurance to cover getting sick or being robbed. I take a variety of payment methods (Visa card, traveler’s checks, local currency, and so on) and have them in different locations in case one of my bags goes astray. I may take a small medical kit, especially if I’m going off the beaten track. I use these methods to help plan for and manage the risks involved in going on vacation.

What does this have to do with Web design?

Like the world around us, Web projects can be a risky business. They can be big, complicated, time-consuming affairs. When you start out, you are faced with many unknowns. The success of a project can depend on external factors—such as clients, partners, or other stakeholders—that you have no control over. Put simply, projects can go wrong for a whole host of reasons.

A good project manager is someone who is expert at managing risk, and the first step in risk management is identifying potential problems. At the start of a new project, it’s a good idea to assemble your team to identify the risks involved. This may sound like a negative thing to do at the outset, but it can actually be quite fun!

Use your experience with previous projects. Write down everything that could possibly go wrong. Don’t worry how important these are, or how likely they are to occur. This is a brainstorming exercise, so the more problems you come up with, the better. Some risks will be common to many projects while others will be specific to the current project or client.

Some example problems include:

• Client fails to supply copy on time or in the correct format
• Approval takes longer than planned
• Critical staff members fall ill
• Programming jobs turn out to be more complex than initially estimated

The next step is to define what will happen if one of these problems occurs. What if the client is late with the site content, or you’ve underestimated how long it will take to program the shopping cart? Will it delay the project? If so, how long will the delay be? Will you have to pull people off other projects to get the project back on track? What will it cost? This result of this exercise is a risk register—a list of the possible risks associated with the project and practical responses to those risks.

Once you’ve got your list of risks, you need to rank them. I give each risk a value between one and five to indicate the seriousness of the risk. One equals a very serious risk and five equals a less serious risk. Next, assign each risk a number to indicate how likely it is to occur. One indicates a risk is very likely to happen, while five indicates a risk is unlikely. Multiply these two numbers. The risks assigned the lowest numbers need the most attention, and the risks with the highest numbers need the least.

Some risks should be kept private, but you’ll want to involve the client with most of them.

Give each risk an owner. On smaller projects, the project manager will likely own all of the risks. On larger projects, you’ll want to make various senior team members responsible for particular risks. It will be the risk owner’s job to monitor his risk and update the risk register (and in turn the project manager) should the severity or likelihood of the risk change.

Share the risk

One problem Web design companies have is that they keep risks under wraps until it’s too late. We just don’t like admitting that there are serious risks associated with a project. As professionals, we feel that we should know all the answers and shield our clients from potential problems. However, in any project, communication is they key to success. It’s no use to complain that the client is making unreasonable demands if the risks involved with these demands are never properly explained and discussed.

A problem shared is definitely a problem halved. Your public risk register should form part of your project plan and your client should be informed of common risks from the outset. When you discuss the risks involved with parts of the project and the effects these risks could have, you enable the client to make rational decisions. Also, by involving them in the decision-making process, they are actively accepting some of the risk. During your weekly progress report to your client (you all have one of these, right?), you should discuss the risks that are currently hot on the agenda to make sure the client knows exactly where the project stands.

For example, imagine you’ve given your client a deadline for copy. You let them know that if the copy is late, the completion date of the project will change. Of course, you may be able to get things back on track by assigning more people to the project, but that costs. As the deadline for the copy approaches, you re-evaluate the likelihood of the copy being late and inform the client of your concerns. This should be enough to get the client back on track. However, if the deadline is missed, the client has been warned of the ramifications so project delays or incurred costs won’t come as a surprise.

Managing change

Risks come into play in a big way when clients request changes to the project spec. Changes to a project should never be taken lightly—they can have huge ramifications down the line. If the client wishes to make a change, the first thing they should do is send you a change order. This is an official document requesting the change, usually authorized by the person in charge of the project on the client side. When you get a change order, you need to think about how this change is going to affect the project. Apart from technical and budgetary issues (you really should be charging for change), you need to work out the risk the new change imposes.

In the same way you worked out the initial risk register, you need to outline the risks involved in the change, and then assign each risk a priority. Some changes will be straightforward, but some may have unknown ramifications. If most of the programming has already been completed, changing one element could literally stop the whole site from working. These risks need to be clearly communicated to the client and they need to take responsibility for requesting changes.

Send the change request back to the client, outlining the risks and ramifications involved in the change. If the client wants to go ahead with the change, ask them to sign the change request, indicating they understand and accept the risks involved. You should add this change request to your project document and the new risks to your risk register. By getting the client to accept the risks involved in making a change, they, rather than you, are taking responsibility for that risk.

Good risk management = happy clients

Good project management really is about communication. It’s about letting clients know exactly what is going on with the project. Most clients aren’t experienced Web designers, so you can’t expect them to innately understand the risks involved in a project. If you have concerns, you need to share them with the client as early as possible, before they become problems.

People like to be asked their opinion. By letting clients know the risks, you are making them feel much more in control of the project. More importantly, you are sharing the risk. It allows you to communicate problems at an early stage and potentially stop them before they start. If a problem does occur, nobody gets a nasty shock and everybody is in a much better position to deal with it. Simply put, good risk management can be the difference between a happy client and an unhappy one.

Related Topics: Client Management, Web Teams, Business