Deliverables as Interview Tools
Many of my associates spend a lot of time looking at new ways of getting the best tools for their projects, and one day a few weeks ago I was sent a link on a new way of interviewing for selecting team members "Projects Are the New Job Interviews” http://blogs.hbr.org/schrage/2012/05/projects-are-the-new-job-inter.html?awid=4711429804570248879-3271 by Michael Schrage. I read it and it gave me some food for thought. I do understand the need to be confident that the candidate can do the job, but is forcing work product the right way to do it? I personally don't think that for PM/BA work, that's necessarily the best way to go.
My husband is a developer at a company that has a large custom software division. He constantly needs to conduct interviews with candidates, and I have been stunned at some of the things that he has experienced. He has had candidates that interviewed on the phone, NOT be the same individual that showed up to the in-person interview; had individuals show open source code and try to pass it off as their own; had others take their entrance tests and fill out their forms, when they got to the interview they were unable to complete the application as their English was so poor! The list of tricks is stunning! So, I wonder, if you give someone a "project" to complete as part of the interview process, is there any guarantee that they would be the one that will have actually produced the work product that you get? And, what does that really tell you about the individual’s ability to fit in with the team? I personally feel that the human factor is more important in our position as a coordinator and communicator for Projects than our ability to produce a Project plan. Let’s face it, you can produce the best documentation on the planet, have a great ability to manage Project Plans and even to keep meetings on track, but if you are just a jerk and people can’t stand you will you ever be successful? In my experience, people need to want to work with you, if they don’t, my money is on a low quality, late Project.
Now I agree that for certain positions putting someone on the spot and pushing them to perform will give you some insight into how they get things done, and give you an idea of how quickly they work. If their job doesn’t require a lot of interaction with other departments (maybe even one where their daily duties keeps them what I affectionately call a “Cave Dweller”) there would be greater value to forcing the candidate to produce a tailored deliverable on demand. A Developer’s position would be better suited to a performance test than that of a PM, as their communication and coordination skills are not primary requirements for writing code. But if you do decide to go that route, consider doing it within a “controlled” environment so that you are at least fairly sure that the candidate isn’t pulling something off the Internet and trying to pass it off as original work!
My point is that you cannot underestimate the need for soft skills in dealing with such a key position where the ability to motivate and rally the players on the team is critical to the end product. Our success as Project Managers is dependent on our ability to communicate and provide an environment for the individuals doing the work to be successful. That means somewhere that the team can disagree, discuss, and ultimately work through issues and obstacles on the Project. I don’t ever see that being determined by having a candidate produce a Project Plan in MS Project in the spare office down the hall. I suggest that when we are looking for BA’s and PM’s to fill our open spots that we don’t fall into the latest hiring “Fad”, but that we do what works, we assess their personal skills, see how they fit into the team and then go from there. After all, the care and feeding of the team should always be paramount in our minds when looking to fill any open position.
Margaret de Haan - PMP, MBA, CSM