SQLServerCentral Article

Lesson Learned from Contracting, Revisited


A recently published “lessons learned” by a real world contractor naturally enough focused on the contractor. What about the companies employing contractors and consultants? Aren’t there any good lessons for them to pickup from an experienced consultant?  I think so. This article presents a few things I wish my clients and future clients knew about by my trade.

Expect the Unexpected

Many companies seem genuinely shocked when the newly arrived contractor fails to meet expectations. How could an agency possibly send an unqualified person to their office? Personal experience suggests that infamous catchall culprit – communications. The IT trade contains many specialties with different labels filled by many people with different levels of expertise. No wonder why a process requiring the exact specification of knowledge and experience regularly fails.

Imagine a company project manager asks an agency for a data architect. The agency sends over a DBA with data modeling experience.  The volume of blogs and articles devoted to what constitutes a data architect suggests there will likely be a disappointed project manager and a frustrated DBA meeting and parting shortly. 

There is a (happy) flip side to this issue which I have observed.  The more seasoned consultants usually exceed expectations. Getting back to our example, maybe our data modeling DBA also sports experience with data dictionaries, data warehouses, metadata registries, etc. Suddenly disappointment turns into delight. But despite this happy ending, the high probability of expectation mismatch motivates the next point.

Know thy Contractor

Screen your contractors and consultants. Usually an interview does the trick.  I’m continually amazed at how often companies disregard this practice. The common reasons for not screening typically fall into one of three categories: lack of time, technical expertise or good sense.

Knowing which of these reasons tells me much about the type of engagement to come. For example, if a company does not have the good sense or time to screen contractors they probably do not handle outsourcing well which translates into inexperienced IT management. That signals me not to assume anything, such as, the existence of backups and proper security policies.

I must confess a more forgiving attitude towards companies not screening contractors due to a lack of in house technical expertise. In many cases that’s why they are bringing in a consultant. But even a not so technical discussion may avoid an obvious mismatch. When a client asked me about my (lack of) RBASE experience I think both of us were happy that the question had been raised.

You Get What You Pay For

I think contractor billing economics closely follows that of corporate staffing, which can be summed up in two sentences. First, valuable employees usually earn better wages.  Second, well compensated employees may not always be valuable.  In other words, do not count on getting a top notch contractor for a low rate; and don’t assume that a high bill rate guarantees a top notch contractor.

While we have all heard the anecdote about the high priced consultant deleting a production database, most of us have seen the low cost consultant place too many indices on a busy database table.  There’s a reason why one of these scenarios is an anecdote and the other a periodic observation.  Low cost, inexperienced contractors are not uncommon. High cost, inexperienced contracts are not common.

Don’t Blame the Contractors

All too often I have heard a client blame a questionable configuration, design, implementation, and so forth on a prior contractor. The need to justify a mess is understandable. Nonetheless, the problem at hand is not the last contractor’s responsibility. It is the client’s. I learned in the military many years ago, “You can delegate authority, you can’t delegate responsibility.” The adage applies in IT.

Working with companies that do not understand their responsibility for a consultant’s handiwork can be frustrating.  A client once asked me to alter their backup strategy to reflect changing business needs.  Unfortunately the available technology could not support the requirements. I recommended several options. After it became clear that no one would take responsibility for choosing an option, I did.  (And yes, this client will speak my name in vain someday for another questionable implementation.)

One of the best warnings to any and all companies regarding responsibility came to me indirectly via a fellow consultant.  I asked about some questionable schema changes that he had introduced. Without pause this very successful fellow declared, “My job is to make sure that the client calls me back to help them blow off their remaining foot.”

Contractors as Internal Auditors

Occasionally when a gig ends the hiring manager informally asks me if I have any recommendations, observations or suggestions. Not a surprising request considering most experienced consultants and contractors usually know what constitutes “normal” and maybe even “best practices” in their trade.  One manager said she preferred hearing from me rather than corporate internal auditors about any potential data management issues.

Asking for feedback is not the same as acting on it though. That, I guess, is the challenge facing a manager savvy enough to ask for criticism. A few years ago I responded to an inquiring manager that their website’s authentication mechanism was susceptible to SQL injection attacks. Twelve months later I read in the local newspaper about a security breach in the client’s website.  C’est la vie.


4.57 (21)

You rated this post out of 5. Change rating




4.57 (21)

You rated this post out of 5. Change rating