Blog Feature
Dan Fisher

By: Dan Fisher on September 29th, 2008

Print/Save as PDF

"You Mean You’re A Body Shop?"


Admit it, at least once you’ve all heard these words come out of the mouth of your prospect. It’s a not a good feeling and it certainly doesn’t articulate the value that we deliver to our clients each and every day. Next thing you know you are reeling to turn the conversation around and convince the prospect why you are not a body shop. Not a good place to be to say the least. But let me ask you another question, when was the last time you took a really hard look and scrutinized your open job requirements/sales orders? I decided to take a gander the other day at the open IT consulting/contracting opportunities on the various job boards and vendor websites. Based on the quality of what I saw, it’s no surprise our prospects often use the term “body shop” to typify our industry. Let me share with you what I uncovered and then provide some thoughts and insight to help ensure you’re never labeled a “body shop.”

Despite what you read in the papers and hear in the news, the IT consulting market for the most part continues to remain robust. There were a plethora of requirements posted on the Internet, but they all looked the same. Zero differentiation. And I would say at least 90% of them screamed “Human Resources”-indicating they wrote and posted the specification. They were all simply listings of technical buzzwords. Big long laundry lists. The postings I reviewed were often long-winded and wordy lacking articulation or way to vague in describing the role and the day-to-day responsibilities. None of them talked to the goals and overall scope of the project or career opportunity nor did they explain the technical challenges the consultant/employee would be expected to solve. I never saw the word “deliverable” mentioned once, in any of them! Yes, I know staffing companies typically don’t take on deliverables. Guess what, even so your consultant is still expected to deliver work output or work product, actual artifacts and/or functionality to enhance your customer’s business. That is what the consultant gets paid to do. Deliver results. And the person responsible for taking and writing the job requirement should understand this.

Interestingly enough, most if not all had an extensive laundry list of technical jargon and/or buzzwords. Yet in most cases, the technologies listed in those “laundry lists” spanned the entire technology spectrum, making it impossible for any recruiter to find the right candidate, if such a candidate exists. Because the Sales Representative didn’t further qualify or ask additional questions, they’re now sending their recruiter(s) off on a fruitless exercise. More on that in a second.

Lastly and most importantly, not one of the postings I saw articulated anything compelling or unique about the project, the consulting/career opportunity, or anything unique and compelling about the client company the consultant would be working for. Talk about lack of differentiation. Yes, I know you are thinking that you explain those things over the phone but you have to receive the phone call in order to have the conversation.

In our industry there are limited opportunities and limited ways in which you can differentiate yourself from the competition. Developing a high quality statement of work or sales order is one of them.

Now put yourself in the shoes of an independent IT consultant. When reviewing IT consulting/contracting opportunities on various websites, how are you going to decide which opportunities to pursue and which to pass on? Aside from narrowing it down by technical discipline and location, you’re going to pursue the opportunities (job descriptions) that are interesting and tell a story. The opportunities that share with you the information you need in order to make an informed decision. What do those descriptions look like? Those are the descriptions that share with you what the company’s goal and strategy is and how the consulting opportunity (or career opportunity) will help support and carry out that strategy; the descriptions that share with you what the business drivers of the project are, who you will be working with, the tasks you will perform, and who, and how many users will be using the application or product you are going to help develop; the descriptions where you understand the scope of the project, team size, and technical environment and technical challenges you will be expected to solve; the descriptions that share with you the project milestones and exactly what you’re expected to deliver to the customer. I could go on and on but you get the idea.

Now let me jump back to the salesman asking his recruiting team to spin their wheels on a wasted recruiting cycle. We’ve all been in morning huddles where we get to that one requirement where everyone is saying to themselves “not this one again, take it off the board, it’s a waste of time.” But to everyone’s amazement, the sales representative is still convinced that it’s a real opportunity and they expect their recruiter to fill the order. Meanwhile, the recruiters and other staff members are rolling their eyes and/or looking away because they are afraid to tell the sales person that they’re really not working that hard on their job order. (Thus the tension and proverbial invisible wall is erected between sales and recruiting. Another topic for me to discuss in a future article!) Folks, these are the job descriptions/sales orders I am talking about. These are the job descriptions that I saw posted all over the job boards and competitor websites, possibly even yours.

As professionals of the IT Staffing and Consulting industry we can all relate to the above to varying degrees. The question then becomes, why are our job requirements of such poor quality and lacking proper qualification? I could write another article on the many different answers to that question. Instead, let me arm you with a few tools for taking a detailed statement of work or sales order. Your boss and recruiting team will love you for it!


Ask the customer for a project overview including, scope, business drivers, and goals. What are they building and why? Who will use the application once built? This explains why the project is so important to the customer. Find out where they’re at in the SDLC and what is their next project milestone (more sales opportunities).
Get the details of the day-to-day responsibilities. Simply developing code or testing an application is too vague.
Differentiate between the desired skills and the required skills. Ask the customer to commit to drawing a line in the sand. This is critical.
Understand the entire technical environment and uncover how it’s all connected. This includes databases, operating systems, application and web servers, programming languages etc.
Find out what the biggest technical challenge you client is facing. Getting the details on this will help you find your candidate and look like a hero.
Don’t just find out why the opportunity exists; find out what the consequences are if the opportunity goes unfilled and how that personally affects your client.
Secure 3-4 interview time slots at the time of taking the statement of work. It gives you an idea of how serious they are sends the right message to your recruiting team and potential candidates.


Always get the answers to these six questions before getting started.

Determine what the budget is and if it has been approved. If it has not yet been approved, find out in excruciating detail the steps and tasks the client needs to complete to get it approved.
Find out if they have hired consultants before. If so, have them explain to you exactly what steps they need to complete before they can extend an offer AND allow the consultant to begin work. If they have not hired consultants, you need to lead them down this conversation.
Find out in detail what the interview process is.
Uncover in finite detail the decision making process.
Uncover the hiring process in detail. There are never too many questions you can ask in any of these areas.
Think two steps ahead of your client. For example, ask them him if they have an office or cube already set up for the consultant? How long will a security badge take? Do they have a computer available for them along with network access?

Hopefully my observations will compel will you tighten up your game and write high quality job descriptions that differentiate yourself as a sales person as well as your organization. Heck, it’s too competitive out there for you not to. And nobody wants to be referred to as a “body shop.”

Happy Selling.

Dan Fisher

Menemsha Group, creator of the MoshupMethodology, a proprietary methodology for selling IT Professional Services, is dedicated to serving sales professionals in the IT Staffing & Consulting industry. Leveraging the MoshupMethodolgoy, sales professionals are equipped with the necessary tools, knowledge, and self-confidence to sell up the customer value chain, resulting in high-end gross profit margins and bill rates. Our content & training is focused exclusively on wining strategic IT staffing engagements including the placement of senior-level IT practitioners and winning IT projects. The MoshupMethodology provides a predictable and repeatable process guaranteeing success in selling IT professional services.
Dan can be reached at


About Dan Fisher

Dan Fisher is founder and owner of Menemsha Group, a provider of sales enablement solutions dedicated to helping IT staffing firms improve win rates, shorten their sales cycle, and increase revenue per sales rep. Since launching Menemsha Group in 2008, Dan has consulted with over 200 IT staffing firms and has invested over 5000 hours coaching IT staffing sales reps. He’s authored is his own proprietary sales methodology and has previously spoken at Staffing World, TechServe Alliance and Bullhorn Live 2012. Prior to launching Menemsha Group, Dan spent 16 years in the IT industry running local, regional and national sales teams. Dan worked for Kelly Services, Oracle Corporation and Alliance Consulting. Dan currently resides in Boston, Ma.

  • Connect with Dan Fisher