IT consulting is a people business.  Knowledge and information, while still important, are not as important as whom you know and who knows, and trusts, you.  Factors such as the explosion of the Internet, the spectacular growth of search engines like Google and Yahoo!, the wave of outsourcing to countries in Eastern Europe and Asia, and the tremendous decrease in costs for computing power and storage have all led to more organizations offering IT consulting services on a playing field that is as level and transparent as its ever been.

So, what does this have to do with technical recruitment firms?  I have yet to find a recruiter or placement firm that understands that consulting is a people business.  I’ve been on both sides of the table with them.  I’ve worked with recruiters while I was looking for a job and I’ve worked with them while looking to find employees to hire.  I’m still in search of a long-term relationship with a technical recruiter.  I’m looking for someone who can do the following:

• Listen and understand my needs as well as the needs of my organization.
• Call me periodically to discuss my needs.  Don’t call me when you have the “perfect” candidate.
• Understand that an employee is much more than the sum of her technical skills.
• Understand what it’s like to work as an IT consultant or software developer.  It’s not necessary for you to have actually programmed yourself, but you should be familiar with basic terms like software development life cycle, agile development, database administration, and client-side scripting.  Bonus points for you if you understand (and can explain) the difference between Java and JavaScript
• Assign a single person to deal with me and/or develop better, internal systems to keep track of my needs.  Don’t have each of your recruiters call me asking me what skills I’m looking for or asking me the same questions repeatedly.
• Talk to your candidates and get to know what they want in a employer or in a job.  Discover their personal and professional goals.  Tell me something about the candidate that’s not on their resume or cover letter.

If you can recommend a firm that fulfills these simple requirements (or if you’re convinced that you’re the recruiter for me), e-mail me at james99 (at) networkats (dot) com or post a comment to this entry.  I look forward to hearing from you.  A recent photograph is not required…

One question that we (almost) always ask organizations that are considering our services is: Has money been budgeted for this project?  If so, how much has been budgeted?  As you can imagine, there are a number of different responses to the question; however, essentially there are two responses.  The more popular response goes something like this, “Well, um, yes, we have money in the budget for project XYZ.  No, I can’t reveal that amount to you.”  The less popular response sounds like this, “Yes, we have set aside money for the project in the budget.  While I can’t tell you how much has been set aside, our expectation is for proposals between $X and $Y.”

Why don’t organizations reveal how much they’ve budgeted for their project, or, at a minimum, what their expectation of how much the project will cost?  I can think of a couple of reasons.  They include:

• If we reveal our budget — let’s call it $X — to vendors, every last one of them will bid $X or $X - 1.
• It’s none of your business.
• We really don’t know what the project will cost and we’re using this RFP process to help us figure out how much to budget.

Let me address each of these reasons.

If we reveal our budget, every vendor will bid that amount (or close to it)

OK, I understand why someone would think this way; however, in today’s IT consulting marketplace, there is enough competition between far too many vendors chasing a limited number of clients and projects that I just don’t think it happens that often.  In an ideal world, we, as a IT consulting firm, would be able to convince you, the possible client, of the value of our services and justify the cost of our bid as a sound business decision.  The reality is that price does matter.  Organizations, especially those in our target markets — associations, non-profits, professional service firms, financial institutions — have a limited amount of money to deal with growing IT issues.

It’s none of your business

While I’ve never heard a possible client use these exact words, I’m sure there were more than a handful that were thinking it after hearing our request :-)  Yes, you do have a right to reveal or not reveal information about your organization, your staff and your requirements.  However, the more transparent and open the process is, the more likely that (a) you are going to find a vendor that fits and (b) the project will be successful.  Yes, we are in the business of making money; however, the best way for us to make money and to succeed as a service organization is to develop solid, long-term relationships with our clients and work hard to deliver quality service at a fair price.

We don’t know how much the project should (or will cost)

As a vendor, I think this reason is the most frustrating one to deal with.  If you’re not willing to invest the time and energy to figure out how much you think the project will cost, why should I, as a vendor, spend time and resources to develop a good response to your RFP?  Instead of issuing an RFP, perhaps the better approach would be to issue a Request for Information (RFI) instead.

I’m sure there are many other reasons.  Send me your feedback via the comment feature and I’ll post them.

Please see Five Things Every RFP Should Contain for other comments, as well as my disclaimer.

One of my job responsibilities at NetworkATS is to interview technical candidates. Maybe I’m in the minority, but I really do enjoy interviewing candidates. Not only does it provide a short break from daily tasks such as coding, testing, dealing with clients, responding to RFPs, etc., I’ve gotten an inside view of other IT shops and learned how other organizations deal with their IT needs. One day I might interview a recent college graduate for an entry-level position. Another day I may talk with an experienced IT consultant who’s looking for a Project Manager position. Unlike the typical human resources person, I try to spend a few minutes reviewing each resume that comes across my desk. Regardless of the position you’re interested in, below are a few simple things that you can apply to your resume if you don’t want a job interview.

List Every Software Application, Language or Tool You’ve Ever Used

In today’s slow moving IT world, it’s critically important to list every software application, language or tool that you’ve ever used. You never know when someone’s going to have a project that’s going to require in-depth knowledge of CP/M, Windows 95. COBOL or Fortran. Let’s look at a two resumes I received last year in response to a job posting for Microsoft .Net developers:

OK, this candidate has both ASP.Net and VB.Net experience. Good. He also has VB 6. OK, that’s good to know. He has DOS, Windows 95, NT, 2000, XP and 2003 Server experience, too. Not too shabby. I’m also glad to see that we can count on him for both structured and object oriented analysis (What I need are people that can deal with un-structured analysis and change-oriented analysis!) Now, let’s compare this resume to the one below.

Now, this is an impressive resume for someone applying for a .Net developer position. He’s got 12 years of Visual Studio experience. Wow. Since this resume was one I received in 2005, that would mean that he started using Visual Studio in 1993. Impressive. Equally impressive is his 3 years of experience in Very Rapid Prototyping. I wonder how many years he spent Prototyping and Rapid Prototyping before being comfortable with Very Rapid Prototyping. What comes after a few years of Very Rapid Prototyping? Double Very Rapid Prototyping, perhaps? In case you were curious, his resume was a svelte seven pages long.

Use English in New and Innovative Ways

Here’s an example.

Here’s another example of using English in new and innovative ways.

Be Vague When Describing Your Previous Experience

It’s important to be vague when describing your previous job or educational experience. The less I know about what you’ve done in previous jobs, the more you and I have to talk about during the interview process. Also, if you also follow rule 1 listed above, List Every Software Application, Language or Tool You’ve Ever Used, why bother writing descriptive prose about what you actually did? Let the long list of technical skills speak for itself!

Here’s an example for your consideration:

This snippet below is a good example of two rules: being vague and using English in creative ways.

If your resume follows these three simple rules, I guarantee that you’ll succeed in not getting a job interview with me. Do you have other “rules” to add to my list? Post them in the comments section…