Did We Break It?

I know I’m going out on a limb with this and it’s probably going to piss some people off on one side of the argument or the other. I do have an opinion on the subject and like a lot of things, it’s complicated. So on to it.

What prompts this commentary is the news that one more business oriented politician has come out saying there are not enough technology workers in this country and we need more H-1B Visa workers. I find this a very relevant topic. I work in I.T. and I have worked with several ‘consultants’ both from here in this country as well as some that were brought in from overseas.

I am not in a position to recommend a consultant for a particular project, nor am I in a position to suggest not hiring a consultant. In most cases I can’t yet do what we need them to do. So, skipping the validity of the available talent argument and completely ignoring the salary expectations of some of that talent, here are some things I’ve observed with regards to I.T. consultants as developers. They are very handy for short term projects. They know it’s a project that won’t last. They know they are expected to get a job done, and hopefully documented properly. Long term consultants that are utilized as in house resources are a potential nightmare, not to mention a potential waste of money. In either case, no matter how good they are, how long they’ve been there, or how professional they may be, they are not likely to have the best interests of your company at heart. And unless specifically told to, they are not likely to build their projects with future technologies or a future without them in mind.

Here’s an example of a waste of money, from my point of view, there may have been reasons for this however; I was not privy to the the decision making process. I am a junior, or so, DBA with a little experience creating or editing SSIS packages for MS-SQL. We have a legacy IBM AS400 system with data in it that we needed to get into an SQL database. We had one really big table that the extract kept failing. A little research on the Internet and some time working with my boss and we were finally able to get the data. Really, we had solved the hardest part. This was the biggest table that needed extracting and we were able to do it in a reasonable amount of time and still do our regular work. At this point, I, a junior DBA with only a little package building experience, could have done the job, on the company’s timeline and saved the company better than twice my annual salary. Instead the project was given to a long term developer consultant who turned in work that my boss had to fix before it could be deployed and some of which I have had to go back and correct due to data being extracted to the worng field or not being extracted at all.

One of the biggest problems with long term consultants and supposedly short term consultants that become long term, is the lack of planning for the termination of the contract. Often documentation and knowledge transfer are put off until whenever. If there is documentation it may be in obscure places. It may not exist at all beyond the initial project proposal or a few not very specific emails.

This might be because the “final” product is delivered and instead of documenting it at that point, there are already enhancements and improvements to be made. And since it’s all going to change when those are done there is no point in documenting it yet. Or so the thinking goes.

To be fair, this can be mitigated some what by the company that has hired the consultant. Tighter controls, and oversight can keep these sorts of situations in check to some extent. Having a code storage location with proper version control is a start. Requiring proper commenting in code and some one to review for that is also key. A company can’t just turn over some development project to a consultant and expect them to do what the company wants and how the company wants it without putting in significant oversight. If a company wants something done on time, with documentation and all the features they ask for then they need to spell it out and avoid scope creep.

There are times when there are legitimate reasons for scope creep. Say a company wants something done a certain way using specific technology. Problem is that what they want and how they want to get it may not be efficient, may not work right, or may not be possible at all, that way. The consultant may not know this or the extent of this until they start to work. This can be due to lack of initial information from the company. Yes, this is sometimes the consultants fault. It is their responsibility to get all the information before bidding on the job. It doesn’t always work that way.

Then there are other times when scope creep is caused by the ‘well, can we make it do…?’This can come from the company that changes it’s collective mind. It can come from the users testing the process who ‘think it would be great if it…’ It can come from the consultant who gets to working on the project and along the way thinks of features they want to add because they think the company needs them, relevant or not. Good oversight can keep this in check.

We all hope and expect that the consultants are being fair and honest and working diligently on our company’s project. For the most part, they are. But let’s face it, sometimes we all think that maybe they are just trying to make more work for themselves or create a situation where the company is going to need them every time the slightest change is needed.

In house talent isn’t always the answer either. Especially when the in house talent has the mind set of a consultant or free lancer. The same thing happens as with the longer term consultants. A future without them is never planned for. They may move from one project to another without completely wrapping up the first one. Here scope creep can be insidious. That’s because the company figures they are paying the talent a salary so why not ask for the extras. It’s not like it’s going to cost extra if it takes another two weeks or two months to code those extras. And that in house developer who behaves like a freelancer, is, in the mean time, keeping things close to their chest and hasn’t written the documentation.

I know this sounds like I don’t like consultants or developers. That is not at all the case. I aspire to the expertise they are expected to have and the salary they can command. And while I understand the need for consultants in general, a lot of the time I find them really annoying and something of an irritant. Especially when it’s my team that is stuck dealing with the mess they leave behind.

There are needs for consultants, whether from in country or overseas. How they are utilized and managed is important. Ultimately the key to using consultants, long or short term, on shore or off shore, and even in house talent that behaves like a consultant, is: clear expectations, strong oversight, and review.