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 risk. This risk is often codified in a series of assumptions or 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 small-scale projects, creating 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 or deliverable requests, or removing existing features to replace with another at the eleventh hour (i.e. horse trading)
-
Providing 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 may 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 your risk assessment 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. If you’re describing all of the possible things that can go wrong—from your own team’s internal POV, in what could happen with third-party vendors, and from the client’s side if they are late with feedback on key deliverables—then the client understands that you are acting in the best interest of the work being done to a professional standard. If you just outline what might happen if they cause a problem, then they will feel like you are being punitive.
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. Outlining the process helps prevent error—and if an error does occur, you can state in your written response as to how the error will be mitigated that you are following the protocol that you’d described in the risk mitigation plan.
The more risk assessments you conduct, the easier it will be to pull one together for similar projects. You can keep improving your body of knowledge from project to project, based on any problems or errors that do end up slipping through.
Every client project contains risk. With this process, you can clarify them in advance and mitigate them throughout the project, no matter the scale of your engagement.
So: what do you do to help reduce risk as part of how you fulfill your projects?
Photo 2894740018 by Stuart Kale (kyz) on Flickr, shared via a Creative Commons Attribution 2.0 Generic license.