100 comments to celebrate 100 IT Consultant posts

In honor of his 100th IT Consultant column, Chip Camden highlights 100 member comments that made him think, laugh, or both.

This column marks my 100th submission to TechRepublic. In the almost two years since my first post here, I've learned a lot more than I ever dreamed I could know about consulting from the comments left here by you, our readers. So to celebrate our 100th conversation, I'm highlighting some of your most enlightening comments on my first 99 posts.

1. meryllogue's comment about So you want to be a consultant?: GREAT first post!

Nice article! And the replies have been good as well. I was going to add one, but it got covered already (note your free hours). In response to "never asked for a referral"... I NEVER hire a consultant without at least 3 referrals. AND... I always ask that one of them be a negative referral! I want to hear good and the bad, and I want to talk to them about the bad to see how they handled it, their perspective on it, etc. It gives me insight into how things might go if (when) the going gets tough. And it lets them off the hook of trying to look like Superman.

2. apotheon's comment about Getting beyond the ‘bull' perception: consultants who consult

That was an interesting cautionary tale. There's just one problem with the substance of the joke:

Often enough, many corporate shops could really benefit from the advice of a consultant who does nothing but consults. Of course, such a person would be able to do more as a vice president, most likely. The problem is that without an MBA and at least fifteen years of management experience - or a father-son relationship with the owner - it's highly unlikely such a person would get a VP job.

Well all know how well nepotism and an MBA qualify someone to make good decisions, I trust.

All in all, however, you make some excellent points about the way "consultants" actually work in the real world, and how they should go about getting their jobs done.

Sadly (or, in my case, gladly) I don't have any "evil consultant" stories to tell. I guess I've lucked into getting to avoid that sort of problem so far. The closest I've gotten to an "evil consultant" is being the next guy they hired - so I never really saw what work the previous guy did (or didn't do) in any kind of useful context.

3. Locrian_Lyric's comment about The consulting misnomer: You wouldn't pay an architect to hammer in a few loose floorboards

Why the heck do companies pay consultants to do grunt-level implementation?

4. dglovin's comment about Six reasons why you might work for free: I do it all the time.

Freinds, family, to gain a new client. Sometimes a freebie for the bigwigs at the companies I contract with. Sometimes for struggling businesses to help them get back on their feet.

It's a Karma thing. Pay it forward.

5. gbentley's comment about Should consultants blog?: Professional

It all comes down to acting in a professional way in your blog just as we w(sh)ould in person, in email, ...

Reminds me of a rule of thumb re. emails.

"Assume you'll have to explain your comments in a court of law and to your mother."

6. Tell It Like I See It's comment about Handing off your project (without killing it): Grooming

In cases when you can think ahead a while (as much as a year out, depending on the system), begin grooming a particular person to take the job.

Start by bringing them on board as a "junior partner" and have them handle some of the relatively routine updates -- such as changing text on a screen or web page. You still handle the major stuff. This begins getting them acclimated to the coding style you used.

Over time, give this "junior partner" more and more responsibility for more advanced changes. At some point (when you feel they are ready), start bringing them into various meetings with the users, such as for requirements gathering.

About the same time you begin taking them to requirements meetings (and other meetings as well), begin asking their opinion on design issues. At first, you'll have to point out a lot of issues they hadn't thought of (and you should point these out) and ask for a revised idea. Possibly even hint to them about an idea you had -- but do your best to let them figure it out themselves.

Once they begin figuring out a design that you agree would work well, let them implement it in the system. Just as with the coding, let them start out relatively small and build from there. You still handle the large stuff initially; but over time the "junior partner" takes over more and more of the design work as well.

You may be surprised once in a while. Sometimes the "junior partner" might actually come up with a solution even better than yours. If it gets to the point that this happens regularly, it is time for you to step aside and let the "junior partner" to take over the mantle of master.

Hopefully the newly mantled master also learned some grooming tips from your bringing them up so they can begin the grooming process with their own successor.

It is not always possible to do this for a variety of reasons. However, when it is possible, this can be a tremendously effective way to pass on the torch.

The approaches you mention are like insurance, for when this grooming process can't be used or doesn't work. They can also help with the grooming process, perhaps streamlining something that would otherwise take a year down to a quarter or so (IF you get a really good "junior partner") so they can still be valuable. But they can't truly replace the grooming method.

7. ITLifecycler's comment about Employee vs. contractor: Rules of Engagement

Response to the question, "What differences in these two forms of engagement make one more appropriate than the other for a given role?

Quick Response: Whether or not a programmer is engaged by a business as a contractor or employee is independent of whether or not a consultant is engaged by a business as a contractor or an employee. An engagement is based solely on the terms and conditions agreed upon between the services provider and the purchaser. The differences that make the most difference are the rules of engagement (express, implied) which may also include role.

Service Provider Roles: Programmer, Consultant

Type of Engagement: Employee, Contractor

Rules of Engagement: Negotiations will address who assumes the risks associated with an engagement, who will be accountable for the results (if specified), and a host of other variables.

8. dean.owen's comment about What to do when you get in over your head: Eat your crow early

when it's young and tender - don't wait until it's old and tough. Good advice I recieved from a veteran project manager years ago. It applies to any 'gotcha' in a project.

9. jmgarvin's comment about 19 things to worry about when traveling on business: 19 is too true

Everybody thinks you were on vacation while in [insert crappy location here].

Let me add 20: When do I stop working? When I'm on the road, I find it is easy for me to put in 12-15 hour days without thinking about it. Why? I have no family or anyone to go home to, so I work my ass off. That leads to burn out and you start to get a little upset with your job.

10. BobR's comment about Is independent consulting on the rise?: Not everyone is cut out to be independent

I agree with the theory that ?self-employment increases during economic down-turns, because of the constriction of available opportunities for wage-earning employment?. In my observation, most independents do take a salaried position when they have the opportunity. If there are more independents right now here in northeast Ohio, it is because we are still dealing with a somewhat depressed economy.

Most people do not seem to think the benefits of being independent outweigh the disadvantages. I do, but seem to be in the minority. I became an independent consultant when I was laid off in the year 2000. Most of my clients do try to hire me, but I plan on remaining independent the rest of my life if at all possible.

I had been employed by a consulting firm and found out the hard way that the ?security? benefit of being an employee does not exist. Many people would pale at the thought of paying $1400/month for health insurance out of their pocket, but to me it is just a number in the formula in determining how much I need to charge per hour.

The big thing for me is, I feel like I have control of my life! As an independent, as long as I get the job done, am onsite when needed, etc, nobody cares what time I start, what time I leave, how many hours a week I work, or how many vacation days I take. Scheduling my life around HR policy (8 hour days, 40 hour weeks, certain number of vacation days per year, etc) to me would be a choker-chain!

11. alphawiz's comment about Handling office politics from the outside: RE: Handling office politics from the outside

Rule #6: Send it to Scott Adams. It's probably excellent Dilbert fodder.

12. dgh2007's comment about Seven reasons to turn down business: RE: Seven reasons to turn down business

You forgot the obvious (read: simple) 8th (or should that be 1st) reason:

If it does not feel right, DON'T!

13. Igor Royzis's comment about Five steps to enlightened expectations for managing your workload: I feel really upset when I can't deliver as promised

I tend to estimate project duration based on my 17 years of software development experience, but sometimes I run into problems, especially if I hire subcontractors to help me. I feel really bad when I can't deliver as promised. Your suggestion of not giving clients a time estimate would be great but it ususally doesn't work - clients want to know when you can deliver the project. As a matter of fact, some of them even tell you what the deadline is - take it or leave it (sometimes it's too good to leave).

The way I handle multiple projects is by allocating blocks of hours to each project during the day. I never switch to another project when running a 3 minute build or restarting the app server.

I also send my clients detailed status reports every week, including what I expect to complete the following week. This keeps them abreast of the progress and decreases the number of unpleasant surprises.

14. julie.dixon's comment about Six secrets to productivity and getting tasks completed: The "escalation" method

Not only am I a geek, but I'm also a writer.

My SO and I have developed the "escalation" method to deal with interruptions while working/writing.

If either of us is concentrating and the other e-mails/calls/interrupts we just state "escalation" and the other backs off immediately.

It works really well, and since we devised the method together neither of us takes the "rejection" personally and no feelings are hurt.

15. brian.mills' comment about Are you working only for the money?: The Money

It would take a heck of a lot more than any employer is willing to pay in order for me to take the job from hell. Money is nice to have, but I'd rather be poor and happy than rich and miserable.

If money wasn't an issue I'd still work in IT, but it definitely wouldn't be on a full-time basis. I'd probably get a part-time gig pulling cable and setting up networks, because I really enjoy that aspect of IT. I like building things, and seeing a project transition from an idea to a functioning system. Then I'd take all that free time between projects and spend it with my family, as well as work on improving my guitar playing and photography skills.

I know it's mostly wishful thinking, but my wife and I want to be in a position where one of us can work from home by the time we start having children, so that we can spend time with them instead of shipping them off to day-care every day.

16. Locrian_Lyric's comment about What's more important to become an IT consultant: education or experience?: The difference between knowledge and wisdom

Knowledge is knowing that a tomato is a fruit.

Wisdom is not using it in a fruit salad.

17. Locrian_Lyric's comment about What's more important to become an IT consultant: education or experience?: Too often, management's view of consultants is...

...akin to hiring nine women to have a baby in one month.

consultants/contractors are often called in once the situation is near FUBAR.

18. rob_o's comment about Six ways IT consultants can build their reputation: Emphasise recent success

One of the best pieces of advice I ever got was from a successful project manager "You're only as good as your last project". He would meet a prospective client and if appropriate present them with a letter of recommendation from his most recent/current project. If they want to know about other past projects that's fine, it's all in the resume. But he sells the most recent project.

The reverse is also true - stuff up your last project and word gets around...

19. blieffring's comment about Can you identify your shortcomings as an IT consultant?: Kryptonite II

Superman's personal job description:

I fly everywhere and resolve the impossible, except in the presence of Kryptonite. My stories generate large sales of special editions.

Management preformance review:

Hard to find. Not always in compliance with working hours, overtime requirements and travel policies. Medical conditions limit expected performance. Monitoring possible personal relationship with co-worker. His actions directly strain the limits of our scheduling and infrastructure.

20. Ed Woychowsky's comment about Why long-term IT consulting engagements may be preferable: Five ways to tell that it's time to move on...

1. You find yourself forgetting that you're a consultant.

2. You run-out of fresh ideas.

3. The assignment isn't fun anymore.

4. You're not pushing your skills to the limit

5. The check bounces.

21. PMP'sicle's comment about Four issues to consider before becoming a remote IT consultant: #5 Unreasonable Work Loads

Some clients will expect you to work an unreasonable number of hours in the day. Or they'll expect you to be available 24x7 ("Sleep? You don' need no stinkin' sleep!"). Because they are not keeping you company they don't clue in that the hours are unreasonable. This is especially true for clients located in other time zones. It also seems to be most true for clients who insist on a per-diem rate. And of course, they expect 12 hours of output in 8 hours because they haven't realized how much time is being spent.

22. Justin James's comment about Do IT consultants have a right to reuse software?: It really is tricky

Let's say that I do Web sites, and on my very first job, I do a nice design. For the next job, I take the HTML, change the image names to fit the new customer, change the colors in the CSS document to fit the new customer, and change the words. In other words, the HTML document remains nearly untouched in terms of the tags and their structure, but some of the tags' attributes change and nearly 100% of the content inside of tags changes. What's the "breaking point" that makes it sufficiently changed?

My experience has been that most customers are pretty flexible with this. As long as you strip out any business-specific logic, or any other "secret sauce" in the code, they are usually pretty happy. It has also been my experience that the customers who insist or beleive that the "secret sauce" is the entire application because they thought of it (after all, the idea of making an icon cornflower blue instead of periwinkle is so important to a project) are usually the pain-in-the-neck customers anyways; it's an indicator of a particular attitude that rubs me wrong.

That being said, a contract can say whatever it says on the topic, and if both sides sign it than both sides need to adhere to it. If the customer insists on no reuse and you want to reuse the code, don't sign the contract.

Also note that this *can* potentially cut both ways. What if the code contains things (maybe an innovative technique or concepts that you would like to productize in some way), and the customer does something like release it as open source? I would imagine that a really good contract would account for these kinds of scenarios too, although they typically say something like "customers owns all code and can do whatever they want with it."

23. The Chief Nerd's comment about Billing IT consulting clients for travel time: RE: Billing IT consulting clients for travel time

I can't think of a single client that is less than 15-30 minutes away. Remote access has definately helped and we are doing that more and more, thankfully. Clients also have us do it more because it improves response time greatly and cuts their cost. When we do have to bill for travel time, we also take the "first hour" approach. The first hour has a slightly higher rate than all other hours and I don't get many complaints. When I get asked, we explain that it is necessary to cover travel time and we normally get a sympthetic nod of approval. The high cost of gas has helped with the sympathy aspect.

24. BobR's comment about Big trouble for little white IT consulting lies: Under-Sell and Over-Deliver works for me.

Call me chicken, but my biggest professional fear is failing to perform at something that the client expects me to be able to do. I will never misrepresent my actual experience. When asked if I have experience with something that I do not, I try to be very frank and say something like, "I have never done this, but I have worked on similar applications, and I believe that I can do this." (I will only say that if I really believe that I can do it. Sometimes I just say no.) I also like to discuss who in their organization I can use as a resource and how much of their time I might need. Sometimes I get the work, sometimes not. But all cards are on the table, and I look forward to going to work each day.

25. herlizness's comment about Onsite IT consulting: Do you charge by the hour or per day?: Ordinary Economics

No business can afford NOT to pass along all costs of doing business; I can't even imagine why a client should think they don't have to pay for my time spent AND my time lost.

Working onsite is *very* inefficient for me and most other people, so it has to be paid for ... and that includes my daily travel time. I know ... some clients want to think that "that's just a commute" ... no, it's typically two hours lost out of my day ... not to mention the gasoline, the additional time and expense of "looking office-acceptable," the phone calls I can't field and so on. They have to pay for this the same way we all have to pay for all kinds of goofy overhead that's built into the products and services we buy ... when your friends in sales tell you about the $1000 dinner they hosted or attended, do you think their customers are not paying for that?

All this said, I think it's best to build overhead into base pricing; I'm not about to deliver an invoice with line items for all the overhead .. it's a hassle and they'd go nuts if they saw it.

Bottom line: everything costs and ALL expenses incurred on behalf of a client have to be compensated.

26. stan's comment about Onsite IT consulting: Do you charge by the hour or per day?: A different method.

I charge by how much I don't want to do it. And I think $250 an hour is quite reasonable

27. Michael Kassner's comment about IT consulting: The importance of naive creativity: No such thing

It's an old cliche, but IMO, there isn't such a thing as a "stupid question". I don't even like the phrase.

In my old age, I'm not afraid to ask what many perceive as stupid questions. As a consultant, I'd rather get burned by asking a stupid question, than being burned by not totally understanding every detail.

As for others asking what may be considered stupid questions, I don't approach the questions that way at all. I've always cherished those kinds of questions as they get me thinking "outside the box". 5 of my 7 patents started that way.

I took special notice of your point about more knowledge getting in the way. I firmly believe that and it's why I take as many creativity workshops I can. Just to break the influence of "too much knowledge".

My ultimate hero is Mr. Einstein and he must have a zillion quotes about this exact thing. Here are a few:

"Imagination is more important than knowledge."

"The only real valuable thing is intuition."

"A person starts to live when he can live outside himself."

"The only thing that interferes with my learning is my education."

"We can't solve problems by using the same kind of thinking we used when we created them."

"The important thing is not to stop questioning. Curiosity has its own reason for existing."

"Not everything that counts can be counted, and not everything that can be counted counts." (Sign hanging in Einstein's office at Princeton)

28. steve.weber.ctr's comment about IT consulting: The importance of naive creativity: Stupid questions are always easier to fix than stupid mistakes

so give me stupid questions anytime

29. boxfiddler's comment about IT consulting: The importance of naive creativity: Imagination...

not only is it underrated, it appears that fewer and fewer are cultivating imagination. Watching my students with their unwillingness to explore the software they are learning leads me to believe that somewhere in the earlier stages of life and education we are failing them in the 'imaginative zone'.

I may be wrong about that, I hope so.

30. apotheon's comment about Offshore developers: Focus on comprehension rather than speed: the commodity

Treating coders as commodities, rather than talent and resource, is what creates the problem of hiring bad domestic coders that compare unfavorably to offshore coders (because the major difference is price) in the first place. If accountants weren't the ultimate arbiter of developer value -- if programmers were treated as internal value generators rather than judging them by the standards of cost accounting -- the emphasis in hiring would shift, and good developers would be (rightly) valued more.

Treating programmers as commodities (and IT in general as overhead costs) just guarantees that the quality of the code is ultimately treated as nothing more important to business policy than the weather.

. . . and, predictably, something that is in fact entirely under the control of the business decision-makers ends up being left to the vagaries of chance, with a definite bias toward poor quality that can materially damage the company's bottom line.

31. techrepublic's comment about An Adventure in IT consulting: Committing the Truth

I call what you mention "Committing the Truth". Often, when you do this you become the pariah and are labeled "not a team player". As a consultant, I don't have to worry about that. Honesty is, in the long run, the best policy after all.

Oh, and I loved your "Adventure" references. You're really showing your age! I will now disappear in a puff of greasy black smoke! :-D

32. TripleII's comment about How to respond if a client asks you to lie: Reply to story, oops: Is that a client you want?

#1, thats just sales speak. If anyone in the meeting takes every wonderful thing a salesman says as the truth, well, they are only 2 weeks out of school.

#2, and especially, #3, it shows the character of the company you are working with, do you want them as part of your sphere. Yes, you may lose revenue, but you can never, ever, get respect back. They may call you every name in the book, but I guarantee that even if they hate you now, they do respect you.

33. boxfiddler's comment about Should IT consultants pay for their stupid mistakes?: Owning up to mistakes is the best way to go...

Biggies, in particular, eat at you until you do. Best just to own up, eat it if you have to, and move on. A side-benefit of that is that it adds to your reputation for integrity. No matter how silly some clients and end users can be, they are happier, thus more likely to stick with, someone who can admit to mistakes. We all make them, and most us feel a bit better about being seen in our own foolishness when we know that others have their moments, too.

I would rather have a tech, mechanic, lawn guy who admitted his mistake over one who tried to hide it from me. Trust is key.

34. Locrian_Lyric's comment about Should IT consultants pay for their stupid mistakes?: My take on it.

The client hired *you*

That means they get *you*.

Here's what I mean.

Let's say the situation was this:

You were working on a project and created your own sandbox environment on your local drive, including copies of data files for some real case testing.

Your employer erases his copy of those important files, and only has backups from one week ago.

You drop them in and save the day, saving the employer at least a week's worth of backtracking and scraping around.

Would they accept a bill for half of what it would have cost them to recover the information themselves?

Your clients did not hire a robot, they hired a human being.

If you can recover the time lost and still deliver the project on time and under budget, you have done the job that was required of you.

35. pwoodctfl's comment about 10 personality traits of a highly effective independent consultant: Another need - Support System

Most independent contractors fail because of a lack of a support system when something does not follow the plan. This impacts not only their clients, but their outside relationships as well.

If you are a "confederacy of one" and rely on no one and no one relies on you, you need to get a backup plan. Illnesses, accidents, delays in a project, or other personal emergencies can make you look ridiculous in front of your client without a solid support system that allows you to weather the unexpected. You need to find a group of professional associates who can step in and finish the job without disadvantaging your client if you are to maintain credibility with them. Otherwise, when it all falls apart in your life....and it will from time to time....you are going to lose clients.

You also have to set expectations and get agreement with the significant personal relationships in your life. Nothing will create more stress that diverts your mental energies from the job at hand than chronically disappointing people who are important to you. Make sure they know when they can count on you and when they will have to cope on their own. It beats trying to work those issues out on the fly. Make sure that they know that having a client is not like having an employer. Clients do not have to understand.