Establishing client responsibilities for an IT project helps everyone involved maintain their sanity. Here are tips for setting up this framework.
Experienced IT consultants know something goes south in every project and build in some cushion -- either in the fixed bid or hourly rate -- in expectation of swallowing a few hours, or even days, and just weathering through to the final deliverable. Clients, on the other hand, always seem surprised when told that some whacky past business practice or demented infrastructure choice on their part is going to add a couple weeks to a project. And some of the stuff you come across can be pretty demented.
On what should have been a fairly manageable WordPress site project I project managed recently, we discovered that the developer who created the client's current site had stashed away several key config files, making it impossible for us to completely index both the content and images. This created dozens of hours of hand-editing and porting content from a 4,000-page site to its new canister.
There is no way to anticipate these kinds of specifics. But you can be sure something pretty crazy is going to happen.
As always, managing client expectations needs to happen on the front end of the project. Part of that process needs to be spelling out specific, even seemingly obvious, obligations on the part of the client. By the time you sign a contract, the client should have a healthy appreciation that they too have responsibilities, and you should have at least a loosely defined action plan laid out in case something unexpected comes up.
On bigger projects, you (or your shop) should build in an audit of key existing systems, just to play it safe. For smaller clients, that may not be plausible on the basis of expense. So you just have to move ahead on the basis of best practice and common sense.
Here are tactics I have found useful in setting up a framework for establishing client responsibilities for a project, and giving yourself reasonable recourse when something inevitably goes wrong.Create a disclaimer sheet for "reasonable" expectations from the client. Again, you probably won't have the bandwidth to do a full audit, but do create a one-sheet rider explaining that certain pre-existing aspects of the client's tech profile can have a dramatic impact on the project. Areas that can come up to bite you include:
- Standing with certain key service providers (i.e., "Have you ever done anything to tick off Google?")
- Access to all account passwords and cloud resources. Particularly in smaller shops, you may be surprised to find how much key information has walked out the door with a previous staffer or contractor. I have worked with no less than three clients who could not get to their Google Analytics data -- that makes it kind of tough to identify key features and pages to focus on in the next site iteration.
- Review of current hosting arrangements. Even if you can't do a full network audit, be sure to carefully review a client site's hosting arrangement to ensure you can move data painlessly to and from your dev environment, and that no tire-kicking you plan to do will bring down a key system. You will be startled to find how many sites run in threadbare shared environments.
All of these tips address only unforeseen complications that can come up on the client side. If you screw up, that it on you. But managing against the fair certainty that the client is going to drop a few unexpected delay bombs of their own will help maintain everybody's sanity as you move through a project.