A client that I am currently working with had been with her company for almost seventeen years. During that time, she’d progressed from being a project analyst to being in charge of change control for all of a large IT Department.

She actually helped to create the change control function and all of its processes, not a particularly popular job because no one wanted to take on the responsibility required to make everyone document what they had been working on, as well as every single change.

Despite the initial resistance, she made a success of it and it became a very important job -- saving the company considerable dollars because it reduced downtime, enabled them to process sales orders more quickly and turn them into revenue, and it sharply reduced customer complaints.

However, when the company decided to down-size, because the industry it was in also was downsizing globally, she was laid off. And she had to start looking for a new job. So of course we worked with her to write a resume.

After reviewing her work history, the question then became: What could we use as her job title? And what kind of offering could she present to a potential employer? Her title had been “Manager, Operational Systems, Change Control”. However, she hadn’t managed people, only projects. Before that, she had been a “Coordinator”, in charge of testing for a large ERP software installation. And prior to that, she had been a “Senior Progammer/Analyst”. And her previous position had been as a “Programmer”.

Her first impulse was to list the positions on her resume, using exactly the titles she had been given by her previous employer. This didn’t sit well with me because, after thinking about it, I didn’t think they were “vanilla” enough to communicate a general type of position in the marketplace.

Let me digress here.

When they’re looking for a new employee, companies tend to want someone “vanilla” – that is, who fits the job description and title exactly. If they’re looking in IT for a “programmer”, they want a “programmer” not a business analyst who can write code or a testing coordinator who knows how to program. That’s what I mean by “vanilla”.

They don’t want to think about how somebody can fit the job; they want the assurance that their applicant is doing the job, has the title, and can do the job.

Has the exactly same title, to emphasize the point.

They’re also not particularly interested in “transferable skills.”

Recruiters or headhunters feel much the same way, although some of the less experienced ones believe that, if you throw enough against the wall, some of it will stick; in general they’re looking for someone who has the exact same job, the same title, the same industry experience, that the job description calls for.

So it’s wishful thinking to think that your skills, no matter how superb, are “transferable” in these prospective employers’ mind.

Many people that I speak to, not my clients, have this belief and often get defensive when they told this just isn’t so. There are just too many people whose skills and job description fit whatever the employer is asking for, so there’s no point fighting it.

At any rate, when I looked at my client’s resume, what we’d written so far, a pattern emerged. Everything she had tackled, from change control, to the software enhancement installation and testing, to installation of an asset management system, to the creation of standards for service levels throughout IT – they all were projects!

And in none of them had my client had people working directly for her. Perfect!

If we added the word “Project” to “Manager, Operational Systems, Change Control” we got “Project Manager, Operational Systems, Change Control”; if we added the word “Project” to “-------- Software Enhancement”, it would be “------------ Software Enhancement Project”; and if we added the word “Project” to “Asset Management” we got “Asset Management Project”.

My client had been acting as the Project Manager for all of these projects, so it was truthful to call her a project manager and to call each of her work experiences a project. She had the responsibility for defining the scope of the work, forming the team (even though they didn’t work for her), tracking the progress, and getting job done by the promised date.

Now, Project Manager is something that an employer can understand clearly. It’s a “vanilla” title. What she worked on was projects, and a potential employer can easily understand her role in each of her work experiences. So that was the way we finally wrote her resume.

I call this positioning and believe it is critical to getting requests for interviews.

One interesting thing happened in relation to this. Although one HR person didn’t have her resume in front of him when my client called him on the phone, it was obvious he’d read it and it had stuck with him because he said, “Aren’t you the one with all that project management experience?”

Bingo!

It’s too early to tell what kind of success she’ll be having. But I do know that this type of thinking has consistently worked with prior clients, and I know that we both feel comfortable with sending out the resume in response to the project management jobs out there.

Job positioning

Ethics of inclusion exclusion

Online services