The New Decade of Design Thanking
The Blind Man and the Cheeseburger: Form and Interconnection in User Experience Design

Creating a Risk Assessment

Too Many Problems

When taking on projects with hairpin-turn deadlines, high levels of technical complexity, and large cross-disciplinary teams that function across silos within a large organization, designers often have to assume a great deal of risk. This risk is often codified in a series of contingencies that serve as part of a proposal, and take on the form of laundry lists such as:

  • Our firm will receive collated feedback from client within 24 hours of each provided deliverable
  • Our firm will require access to the hosting environment for initial testing by back-end development at the start of the project
  • Our firm will hold to the specified feature set provided in this estimate; any changes in the agreed-upon scope will have an impact upon timeline, budget, or both

While these itemized lists are valuable in defining client/designer boundaries, they don't do a great job of describing what happens when said boundaries are violated—either by the designer or by the client. We rarely dive into the nitty-gritty details of how badly things can actually go wrong until we've signed the contract and started work.

But there should always be a time slotted into project kickoffs where you sit down and put together a risk assessment.

On tiny projects, doing a risk assessment doesn't have to be a formal affair. On much larger projects, however, you have to plan for at least one client meeting where you'll mutually discuss the risks you'll face over the life of the work, and how you will work together to keep your project on the rails. For this meeting, you will need a risk assessment document.

A risk assessment document can be set up as a three-column chart designed to answer the following question, over and over again:

If [something bad] happens, we're going to do [agreed-upon action].

In the first column, you list all the possible things that could happen that can and do go wrong. For example:

  • Missed milestones (both client and designer)
  • Late payments from client, based on your negotiated fee structure
  • Additional feature requests, or removing existing features to replace with another at the eleventh hour (i.e. horse trading)
  • Providing critical content too late in the process
  • Backing up from visual design into wireframes or baseline IA based on surprise stakeholder feedback
  • Additional meetings, deliverables, and/or presentations to gain baseline approval
  • Failure of third party vendors to respond in a timely fashion (server and/or IT vendors)
  • Promised resources or information that is required to fulfill key deliverables, such as research results or metrics

In the second column, you then describe what you and the client will do together to surmount those problems. You can't always be specific about exact impacts, but you can posit some solutions.

Let's say that you have a third up, third down, third done payment policy for new clients, and you require payment up front for the services of a third party, such as hiring a photographer or setting up a server. You've received your first third and have begun to dig into discovery and planning. In your risk assessment, you note the following:

If client is unable to meet the agreed-upon payment schedule for third-party services, work will stop and there will be a day-to-day slip on the project schedule until payment has been provided.

Note that this is probably something you've already placed in your design contract (I hope!), but it's useful to reiterate such things as part of your overall project risks. Freezing to negotiate on money is a big, painful impact on the whole team's progress in a way that can be a bit demoralizing and freeze a project in its tracks.

Another common risk is the client promising to meet feedback schedules or providing content for deployment of a site. Often, in the throes of executing on a big project, we don't want to slow things down—at the cost of our timeframe for execution. This is where errors creep in. It's also where we end up paying for it in late payment.

So in your risk assessment, when it comes to talking about late content, you can say the following:

If client is unable to provide content for the website within the agreed upon timeframe, there will be a day-to-day slip on the project schedule until payment has been provided. There may also be budgetary impacts, based on said timeline extension, that will result in a change order.

Time is money! If the schedule slips a week because of late deliverables, it's costing your business billable time that can't be allocated quickly enough to other projects. This money must be recouped from the client, and they need to be aware from Day One that their company is assuming risk by forcing a fast timeline.

The third column in the chart? It's where you provide a bulleted list of what deliverables and points in the schedule may be impacted (separate of the narrative).

Keep in mind that your risk assessment document is a draft until the client provides their input and agrees to it (in writing). But you are in a much better position with them if you have thought through the best course of action before you get together to review it.

These are simple documents, but they have very complex ramifications in implementation. They force you, your team, and your client to confront all the possible ways things can (and will) go wrong. And the more that you make them, the easier that it is to pull one together for similar types of projects.


Rob Edwards

Good post - firmly bookmarked.

The comments to this entry are closed.