Monday Consulting Questions: Three Reasons Not to Work On-Site

I’ve been saving up questions for a while, so without further ado let me welcome another installment of Monday Consulting Questions.

Q.  What is your position on working on-site?  I have a new client who is pressuring me to work 100% on-site, and I don’t know what to tell them. A. When you say “working on-site” I’m going to assume you mean actually developing software on-site.

The general rule I’ve set for Cogeian Systems is that we do not do development work on-site.  We have our own work spaces, our own machines, our own software and everything else we need to complete a project.  We primarily do work at our own locations.  Now, we do travel out to see clients for various reasons – meetings, installations, training, etc., and these things are work.  However, it is not our generally our practice to generate work product (software) on-site.  There are a couple of reasons for this, and I suggest that you as a consultant think long and hard about them.

First, my experience has been that developing on-site devalues your expertise in the client’s eyes.  Back in the early days when it was just me, I had a couple of clients nastily refer to how I was “just typing all day” and that they didn’t understand why they were paying my rate – this despite the fact that what I was building was demonstrably saving them 3x my bill in labor costs each month.  But for whatever reason, this client didn’t care – all they knew was that a typist should cost $10/hour, yet there I was, “just typing all day” while being paid almost 10 times that.  However, take that same client, go away for a week or two, come back with a big fat feature to install, and they’ll think you were off working miracles for them.  It’s lame but it does happen.

Second, working on-site introduces the danger of the client treating a consultant like an employee.  You’re there every day, sitting at a desk like an employee, arriving at 8 and leaving at 6 like an employee, taking an hour for lunch like an employee, hell, they may as well treat you like an employee – that is to say, micromanage, second-guess, interrupt, and generally stop you from being effective.  I know, I know, this sounds terrible for me to say, but I’ve called clients on this before and they admitted that I was right.  There is nothing more dangerous than for a client to take an expensive consultant too casually and give them the employee treatment, thereby working against their own best interests.  The most effective (and happiest!) consultant is going to be the least encumbered.

Third, working on-site prevents you from doing the things you need to do to grow your practice.  If you’re stuck behind the client’s desk for 8 hours a day, when are you going to market?  When are you going to recruit?  When are you going to make or take prospect calls?  Sure, you could do all these things after hours, but isn’t it better to NOT do it that way?  This is the kiss of death for anyone trying to found a consulting practice that they intend to grow beyond a 1-person operation.

So, the over-reaching meta-reason for not working on-site is simple:  it is not an effective practice.  It’s not an effective way to get a project done (which is bad for the client) and it’s not an effective way to grow your business (which is bad for you).

Now, the exceptions.

For certain remediation projects, there is no way to avoid working on-site.  Although we do 90% of our work via some sort of remote services, there are times when you need to be physically at the location, and that is fine if that is what the job requires.  We’re just not going to work on-site for every little mundane task.

Personally, I think that a client who wants a consultant to be on-site full-time has a trust problem.  And if a client cannot trust my team and I, then we probably shouldn’t be working together.  Again, this is a hard line I’m taking, but I think it is a useful one.

Of course, there are folks out there who don’t really want to be a consultant, they want to be a contractor – that is, contracted labor meant to augment the client’s W2 staff.  There’s certainly nothing wrong with this kind of arrangement, as I know a few guys who make it work with some combination of on-site and off-site development work.  I simply don’t recommend this as a long-term method of operation for anyone who is looking to build a consulting firm.

Q. What do you do when a project requires technology that you are not familiar with?  A. Now, this is an interesting questions.  I have always said that my company specializes in the Microsoft platform of technologies; if someone called us to do, say, a PHP project, I’d have to politely decline.  However, I have recently decided that this stance does not mesh with my oft-repeated claim that we are actually in the business-problem-solving business.  So, I’m currently looking for competent PHP and MySQL resources so that I can apply my take on effective development practices and extend my company’s offerings to include the LAMP ecosystem.  I might even pick up some PHP skills myself (more on this later).  But, I’m digressing.

When faced with a project that includes or requires technologies that neither I nor my team are up to speed on, I do one of a few things:

If the unknown technology is a strong majority of the project, I will refer the client to someone else.

If the unknown technology is a strong minority of the project, I will accept the project and subcontract the parts that include the unknown technology.

If the unknown technology is a minimal factor in the project, I will strive to understand it (or have one of my team members strive to understand it) to the degree that is required to complete the project.

Do you have questions about the custom software/consulting business?  Email me your question and I’ll try to use it in a future installment of Monday Consulting Questions.