Not Responsible For Hidden Damage

Last week my car had an unfortunate meeting with the back of a car carrier.

It’s probably one of the only times  I’ll ever be hit in the front end while I’m frantically steering my car in reverse.

Seems that a local trucking school undergraduate forgot to read the part in “Trucking 101 for Dummies” that says it’s not recommended to stop in the middle of a road and shift suddenly to reverse – without looking behind you.

I’ve heard  some good comes from every situation. In this case the “good” is a simply brilliant phrase that I’m eager to incorporate (with slightly different wording) into my proposals and engagement letters.

This  phrase covers much of the challenge that I’ve been having with fixed fee pricing – especially when applied to upgrades with many different unknown variables – data integrity being the biggest.

While traversing the fun world of auto insurance claims, and body repair shops I was introduced to this phrase.  I’m claiming for my own use.

Not Responsible For Hidden Damage

The “A-Ha” moment for me was when I realized that the fixed price the repair shop gave me – really wasn’t fixed if there were areas that they couldn’t readily see when preparing their estimate.

Right there on the quote in bold letters was the phrase “NOT RESPONSIBLE FOR HIDDEN DAMAGE”. They continue by saying that if there is damage beyond what the realistically can be expected to observe that they’ll issue you an additional quote to fix the damage.

Note that the body shop doesn’t step into the role of an unpaid insurer by fixing things that were laying beneath the surface and not readily detectable.

How often does this type of issue happen to you on a consulting engagement?

  • The client’s data is corrupt – an issue only uncovered during the actual process of converting?
  • A third party add-on selected by the client doesn’t work the way the documentation claims.
  • That special integration promised by an outside service bureau amounts to a CSV file that lands in your lap instead of a fully complete on-button-push smooth transfer of data.
  • Suddenly 10 new requirements are added by the purchasing department – who were not part of the initial evaluation team that approved the purchase of that new accounting system.
  • The client’s server refused to allow you to install the upgrade disk due to a last minute patch automatically installed by the operating system.

The Three Ways I’m Guarding Against Being Stuck for “Hidden Damages”

Since starting to offer fixed fee engagements nearly exclusively – I’ve learned three very important things that must be present on every project to avoid losing money and client confidence.

Effective immediately we’re also adding that during an upgrade engagement we aren’t responsible for damage that’s hidden which we were unable to discover using ordinary care and best practices prior to starting a project

A detailed scope letter – This one seems like a no brainer – except it’s  the one area  everybody skimps on. This scope letter is simple. It defines exactly what you will and won’t be doing. For upgrades we’re sure to define the company codes, versions and enhancements (if any) that we’re upgrading.

In order to make sure that each of our engagements has a scope letter I’ve created a template in my Google Docs. Two clicks of a mouse and my scope letter has all my boilerplate advice – and is ready for me to start adding client specific tasks. It’s not perfect – but having the document nearly complete and easy to finish (and email via PDF through Google Apps) makes it that much more likely that I’ll create a letter that covers all the details of the project.

Clearly explain that upgrade means upgrade – not fixing or re-training  on old issues –  As consultants we naturally want to fix everything. When we get into a fixed fee upgrade there are many areas that we’ll see that need improving.

Avoid the temptation to make those “one second fixes”. The danger? As soon as you open up Crystal Reports to modify a report from version 4.0 (assuming you’re working an upgrade from 4.3 to 4.4) then you own any future or present problem with that report — even though you will not be paid one cent to have fixed it as part of your fixed fee UPGRADE.

Keep an issues list so that non-upgrade items are quoted separately – Similar concept as above – keeping an issues list of non-upgrade related issues means you don’t get sidetracked on half a dozen “quick fixes” that in actuality add up to a day or more of unquoted effort.

One last great concept that was taught to me by Brett Zimmerman was to always send a pre-project list of items that the client is responsible for. This serves as a baseline list of readiness that you agree will be expected from the client.

Here’s and example of my MAS90 & MAS200 pre-upgrade and project readiness instructions– which admittedly is a work in progress which I continually fine tune– but outlines our expectations as to the readiness of the client’s site. This eliminates all types of delays for which I haven’t budgeted (example – waiting for a backup, making sure things are posted, having to reschedule because a server can’t be rebooted, etc).

About admin

Trackbacks

  1. […] option #1 and #2 exclude hidden damage. If there’s a damaged data file. Program bug that requires a Sage case. The client is […]