If the world were perfect, a client would come through the door knowing exactly what he wants, reasons for wanting it, and a plan of attack. Unfortunately, the world isn’t perfect. Clients are often misguided by a combination of preconceived notions and their associates, resulting in a very frustrating experience for both parties involved.
Many agencies find themselves consistently frustrated with client work, straining to find a way to leave it by the wayside in an attempt to be self-sustaining through a number of profit garnering internal projects. I think it’s wonderful when an extremely talented agency is able to gather enough resource to build and sustain internal projects which are able to propel their business forward. That’s no easy task and it’s great to read when an agency goal has been met.
I dig client work, it’s a challenge
I’ve got to admit, however, I think I’ve found my place in client work. While many people are discouraged when working with clients, my experience has been surprisingly good. That’s not to say I haven’t had my fair share of frustration, quite the contrary. What I like most, though, is figuring out what caused the frustration and finding out how to prevent it from occurring again. Working with clients is a great way to widen your view of how people view the Web.
I think it would be safe to say that I’m equally interested in process as I’m interested in the work itself. I’m thrilled to see that other designers I look up to are writing (extensively) about process. Being able to compare and contrast both similarities and differences is extremely intriguing for me.
One of the most difficult parts about client work is the estimation process. It’s been written about before, and I’ll continue to write about it. Project estimation is one of those things you should never feel you’ve mastered. With every project you should refine your skill, learning from past projects. Naturally, through the learning process your estimate will be less than accurate, but handling a situation at that point is a strategy by itself.
At my office, we’ve established some light guidelines for our estimation process. These guidelines help us to determine what type of estimate will be required for a particular project. We have a wide variety of projects come through the door, the majority of which are content powered websites. Over the past year or two we’ve had a number of larger projects come in, involving much more extensive custom programming work. These projects began to throw a segment of our estimation process for a loop. Enter blueprints.
Blueprinting
We needed a way to effectively handle estimates for projects involving significant back end development. Our office bills by the hour, so our estimates are often a range of work hours as opposed to a timeframe for completion. We do our best to accurately determine when a project should be finished, but unless a client has a hard deadline, the number they’re most concerned with is billable hours.
We found it difficult to devote the time required to provide an accurate estimate for custom programming jobs simply because we had no way of compensation. We were forced to eat the hours used for the estimation, or apply those hours to our final estimate. Neither option would have worked out, however. If we decided to eat the hours, employees would find themselves trying to compile an estimate quickly for the sake of minimizing non-billable hours. With custom programming jobs, however, non-billable hours really start to rack up quickly. Alternatively, if we decided to apply the hours spent to the total project estimation, there was risk of the client going with another agency.
At some point last year, two of my colleagues presented the idea of blueprinting as a way to circumvent this obvious issue we were having. We thought the idea was brilliant, implementing it immediately. Essentially, our idea of blueprinting is to abstract the planning process from the production work itself. Our programmers and developers would take the time to piece together documentation for the project before a single line of code is written. The purpose of the document is to outline on paper many of the technical details involved with the project as a whole. Data requirements, possibilities of error display, flow charts, and goals are included in the document as to provide a fantastic foundation from which to build an accurate estimation. At the end of the day, our average blueprint will end up being upwards of 100 pages in length (all visual references included), making estimation of production work extensively more straightforward.
While the documentation itself acts as a fantastic resource for both the agency as well as the client, there is another valuable piece to blueprinting; it’s billable time.
Billing for blueprints
As previously stated, our biggest problem was the lack of compensation for the time we put into estimations. With our implementation of a blueprinting tier, we decided to make that time billable. Instead of providing an estimation for the project as a whole, we divided the project in (at least) two phases, the first of which is a blueprint. We do our best to estimate the time for the blueprint itself and use that process to help us build an accurate estimation for the rest of the project.
At first we wondered what you’re wondering: what client is going to approve that? I’ve got to admit; reactions have been surprisingly positive. We’ve presented blueprinting to a number of clients, and have yet to receive utter refusal to partake. More often than not, clients are intrigued to hear about our approach. Another benefit to a blueprint document is its take home value to the client.
Worst case scenario: a client completely jumps ship and decides to cut off the project post-blueprinting. You’re able to bill for your time spent in developing the blueprint, and your client is able to use that documentation to pick up exactly where he left off, all planning complete. Theoretically your client could take the blueprint to another agency and request that his project be completed exactly to that spec, no matter how ethically wrong that may be.
On a happier note, however, our experience has shown that clients truly enjoy this part of the process. It helps to show that we as an agency are putting in the proper time to ensure end goals are effectively met. It’s much more beneficial for all parties involved to know a global understanding is in place from the start.
What’s your strategy?
I’m terribly curious to hear how others have come to effectively stay in business when it comes to large projects (especially those including significant custom programming work). What have you implemented that has worked out astoundingly well? What have you tried that ended up doing more harm than good?
Comments
We basic have arrived at a similar solution as you described. We realized that, when a client walks in the door without properly knowing the details of what they want, extracting those details is of great value to them.
The amount of time a client would have to spend planning their project by themselves would be factor enough for them to consider getting help from experts, but the fact that our knowledge will be able to find solutions they’d never think of is even more significant then the time alone.
The number one obstacle, at this point however, is the clients that really don’t want to invest their time very much at all. Ultimately, it’s their project –so they’ll have to provide quite a bit of input– but some clients just want it done, they don’t want to be involved.