Networking

Justifying the invisible project

IT consulting work sometimes seems invisible to clients and may lead to billing questions. Chip Camden offers advice on keeping clients informed about what you're accomplishing.

I received an email from TechRepublic member Bob Eisenhardt (aka reisen55), which read in part:

Yesterday I migrated most of [my client's] office, save one segment that cannot move easily because of a unique software package, to a domain. The server was upgraded to DNS and DHCP, the network router demoted to an access point. Active directory implemented, and I used the PROF WIZ utility to migrate stations to the directory. This is a wonderful utility, can move out of a workgroup completely TRUE, COMPLETE, ALL SETTINGS CARRY OVER - to a domain in 10 minutes or less per station.

And everything is up this morning, no problems at all. Great.

To the client, it appears that nothing has changed at all. As it should be.

Which prompts this email. I am monitoring such a large scale change - as proper - and will give the client a large invoice for this project. And to the client, the project is actually invisible!!!!! Odd reaction - WHAT DID YOU DO? Really, if nothing changed, why are you giving us such a large invoice and why did you do this?

Advantages are many of course - security, Exchange server if needed, HIPAA rules apply better.

But an odd reaction from a client if you think about it. To their view - without education - just WHAT DID I actually DO if everything looks just the SAME as it was before?

I've run into the same thing often in my career: the invisible project that the client needs anyway. These projects derive from at least the following sources:

  • Incremental improvements - like Bob's case above. Code reorganization and refactoring can often fall under this heading as well. It's not strictly necessary, but it will pay dividends in the long run. Clients mistrust these projects because they rightly perceive the opportunity for churning, so they need to know how this project will benefit them. Don't rely on the magic words "best practices" - nine times out of ten that's just an excuse for not thinking creatively, and if your client is smart, they'll know that or instinctively suspect it.
  • Preventing disaster. How often have you stumbled across a client's procedure or piece of code and wondered "How has this not bitten them in the aft end before now?" When you bring it to your client's attention, be ready to explain its urgency. They'll have a tough time believing that it's important if it hasn't been a problem all this time.
  • Compliance. The government and other regulatory bodies often make unnecessary work for you. Fortunately, you can blame them. However, that doesn't automatically mean that your client won't try to get out of doing it.
  • Research. It depends on your type of client whether you can bill for research. End users typically want you to deploy proven solutions at the lowest possible cost. I'm fortunate that, since my clients are software developers themselves, they generally appreciate the value of research projects. But they still get discouraged when the only deliverable from a hundred hours' work is "We now know that we don't want to go down that road." In that case, I emphasize how much money they saved by researching it instead of jumping into the implementation and finding out they were wrong a year later.

Even projects that deliver quantifiable results can sometimes elicit the question "What did you do?" If you bill monthly or on some other regular schedule, then you can sometimes evoke that reaction by presenting a bill while the deliverables are still pending. One way to avoid that is to deliver as frequently as possible, but in some circumstances you can't — you'll break something if you push changes too soon (although watch out for these kinds of projects — chances are you'll break a lot when you do finally commit).

Clients naturally have the right and obligation to insure that they're spending their money wisely. In severe economic times, their knee-jerk reaction is to nix any project that isn't strictly necessary. They need to realize, however, that a project that makes or saves more money than it costs (including opportunity costs) should not end up on the cutting-room floor — especially when money is tight. If the wolf stays curled up in his den all winter to conserve energy rather than going out on the hunt, he will starve.

The presence of an observer changes the thing observed. When we know that the client is looking for justifications, we try to provide them. Unfortunately, that sometimes shifts our focus from making a dramatic difference to making a theatrical one instead. We consultants must employ wisdom, honesty, and balance in order to keep our clients informed about what we're accomplishing without degenerating into "Productivity Theater".

About Chip Camden

Chip Camden has been programming since 1978, and he's still not done. An independent consultant since 1991, Chip specializes in software development tools, languages, and migration to new technology. Besides writing for TechRepublic's IT Consultant b...

Editor's Picks

Free Newsletters, In your Inbox