Free Yourself From Uncertainty: Defining Scope of Work and Setting Expectations

I recently completed a project to create a document defining the types of functionality and relationships associated with the various database columns and tables in the back-end of a client’s medical billing software.  While the project was fun (at least in the sense that I got to work on something nerdy and technical), it was also a sobering reminder about the uncertainty endemic to the world of consulting.

Our initial understanding of the project was that the client was looking for a database dictionary documenting a product’s back-end. This type of document typically lists the tables and fields in a database, along with information on each table’s key(s) and each field’s data type (if you’re lost, click here for an example). Of course, it turned out that client’s expectation of what would be included in the “database dictionary” was much broader than what I had in mind based on my  previous experience (2 years of minor DB analyst and documentation work).

Let this be a reminder – when defining scope of work and setting expectations for a new project, make sure to put in 125% of the effort that you expect it to take. In this particular situation we did everything we could – including a two-page sample of what we proposed to do – so the client understood what it would receive at the end of the project.  In the end, the client’s expectations were still not completely clear (as we later found out). While we delivered a database dictionary incorporating highly detailed table and field descriptions based on interviews with subject matter experts, it turned out the client expected something explaining “how it all works,” including detailed explanations on the relationships between the various tables and fields.  This is why I believe it’s important to always supplement the question of “what do you want to get from us?” with “what do you hope to accomplish with this project?”

In my case, I believe the client’s answer to that last question would’ve been “replace our database guy,” which would’ve given us the opening to respectfully recommend an alternate course of action. As much as we love documentation, we firmly believe you should retain the services of your database analyst if you’re actively developing something that runs on a database. I mean, those guys don’t get paid$85k/yr for no reason…