Thursday, July 16, 2009

Stupid Consultant Tricks

A couple of weeks ago, I finished up the beta version of a data importer that a client (the representative of whom I'll call "Rick") had asked for. Specifically, he wanted a way to automate monthly well production and test data imports from their oilfield management software into their reserves database for Aries (the economics software we use). Rick asked "Jim" (one of the engineers I work for) if we could whip something like this up for them, and Jim asked me, because he knows I can do tricky technical/coding things.

It was a pretty fun project. They sent us sample data in Excel, and I learned enough VBA to write a nice little program in Access. Basically, you click a button to start the import, and it asks you where the Excel file is, sucks the data in, determines what data is duplicate and what data is new, asks you if you want to update existing records, then if you want to add new records, does all of those things, and outputs a form of log letting you know exactly what was done.

Unfortunately, after Rick (the client) had a chance to play with what we sent him, he sent Jim this email:
Looking back on our initial email, I thought we were looking at a loading process from our production database into the Aries database. Both are in Access so it would seem that there should be a way to link the tables with some type of load query. Your current load process is workable for other areas but it would be a huge benefit if the we could do this loading internally within Access.
Apparently what he had wanted was an import from one Access database to another, not from Excel into Access. Although this is not a gigantic change, and is in some ways easier to code, it wasn't what I thought we were doing.

And at first I felt quite annoyed with Rick. Why the hell would you send sample data in Excel if you weren't intending to import the data from Excel? I mean, I worked with what I was given. Stupid client!

But, no. This is actually my fault. I mean, I have most of an entire degree in software engineering. I know better than to just go off half-cocked and write a bunch of code without doing even a minimal amount of requirements engineering. (It's probably not appropriate to write up an entire set of requirements for this project, but a simple email to the client clarifying his needs would have been prudent.) It is not the client's job to know how to unambiguously ask for what he wants.

Stupid consultant! ;-)


Sally said...

I will say, possibly in your defense, that it always seems trickier when there is a middleman like Jim. I've been Jim in a situation like this before (at the market research company). Not sure how much interaction you had directly with the client, but it sounds like not a lot.

The first time I (as Jim) invited the programmer on a conference call with a client to hammer out specs, the head of programming was immediately suspicious about what was going on. It took a moment for her to get a grip on the fact that I wanted the programmer there from the beginning and so he could ask questions of the client because our office didn't work that way. A lot of offices don't.

So I will add: It's Jim's fault, too! :)

Tam said...

Yeah, the fact that I am not in the habit of talking to clients (whose phone calls I am at least allowed and often encouraged to actively refuse) did not help.