Dummy Deadlines and Transparency

As I wrap up a consulting engagement with a heavy data management bent, I’d like to impart a few lessons learned. Despite a tight deadline, change management issues, and data of a very interesting and inconsistent nature, I am leaving my current client satisfied. While this post offers no guarantees, it outlines two tips to improve the odds of success on data management projects.

As I wrap up a consulting engagement with a heavy data management bent, I’d like to impart a few lessons learned. Despite a tight deadline, change management issues, and data of a very interesting and inconsistent nature, I am leaving my current client satisfied. While this post offers no guarantees, it outlines two tips to improve the odds of success on data management projects.

Dummy Deadlines

This is one of my favorite tips. (Any time that I am calling the shots, I always build in a few days because “life happens”, as a friend of mine told me once. If I need something by Friday, I try to get it by Wednesday. I always assume that it will take longer for me to transform data than it probably will for one simple reason: I don’t know what I’m going to get, much less how I am going to get it.

For my past client, my manager told me that the financial data coming the different transactional systems was golden. That is, I should expect no problems. Want to guess if that happened? Of course it wasn’t perfect. By identifying the problems and sending the file back, I gave my client time to review its own systems and processes. Ultimately, when I did get back the good file a few days later, I was still able to hit my initial deadline. This isn’t exactly magic, but it’s a neat little trick.

Simon Says

Simplicity is a wonderful thing. Be careful when you announce the deadlines; we consultants are not calling the shots. In the end, there’s only so much I can do. Dummy deadlines aren’t an exilir. However, they can be tremendously helpful.

Transparency

Many consultants attempt to foster dependency, making their clients call them for the slightest of modifications or questions. Reputable folks try to make themselves expendable. Of course, there’s no way that I can teach an eager–but novice–individual all that I know about manipulating data. Consequently, there’s a chasm between what I know and what I have successfully taught my client. That gap typically shrinks from the time that I arrive and the time that I leave, but trust me: it still exists.

The question becomes: How do I teach my client how to fish without starving to death–and having to call me to bait a hook?

The answer: transparency. By teaching my client what I am doing to make modifications and manipulate data, I am really accomplishing two critical things:

• I am transferring knowledge. This is usually a good thing.
• More important, I am letting him/her get under the hood with me. With a new appreciation for the complexity of the tool, my client will resist efforts of higher ups to make ostensibly simple changes. This will preserve the integrity of the data and the tool.

Now, plenty of people take a Just Do It mentality. They don’t want to know how something works, thank you. This is fine. However, those same folks who don’t want to get their hands dirty invariably wind up calling me after the project is “finished.” Should my schedule allow, I am more than happy to do the work. But what happens if that’s not the case? What about budgets?

Take the time to work with others and at least understand the basics of the tools that they create. You might just learn what to do–and how not to break it.

Feedback

What say you?