Hiring the super project manager
Wednesday, November 19, 2008 01:50 PM
If you’re hiring a project manager to lead your PMO, you have to look beyond a PMP certification. Find out what characteristics to focus on.
Some would argue that hiring good people is now more science than art. Personality tests, leadership tests, background checks, reference checks, relevant experience, etc., all make selecting the right candidate an easier task.
That may be the case for some IT resources, but it doesn't necessarily apply to project managers. And it definitely doesn't, for project managers for small and midsized businesses (SMBs).
I will address other hiring and organizational insights in my next post, but I wanted to touch on PMs outside of that context because they're incredibly important to a successful PMO.
PMP-certified project managers understand risk to a project and can notify management of potential issues. They have had hands on experience creating project plans and all the necessary artifacts to ensure a smooth running project. Certified PMPs have to have a few good-sized projects under their belts before they get this certification.
But you need to go deeper than the PMP certification. The certification tells you that they meet the standardized requirements of a Project Management Professional, but it does not address style, critical thinking, approach to challenges, personality and more importantly, motivation.
What SMB PMOs need is a project management core with visioning skills, leadership skills, a quality focus and a knowledge of all the PMP tools and tricks. Let me illustrate here.
Let's say a business manager has a great idea for a new product that will make the company $xx million in 18 months. The developers say it is feasible and the CEO is all excited. The business manager has this unique vision as to how the product is to interact with customers. The vision is more of a solution than a product, so there are a lot of subjective aspects to the final picture. There are reasons for these subjective elements and they all work together to come up with the $xx million return.
The PM and the business analyst get all the requirements down. The business manager signs off on the core elements and then it's up to the developer to make all the decisions that will eventually end up in the finished product.
So Iteration One of the product is presented to the business manager. The product looks nothing like the solution the business manager had envisioned. So back and forth the process continues until the solution becomes a product of compromise. This means that the developer says "we can do it this way to meet the timeline, but this feature won’t be available" and the product manager says "we need that feature and the deadline is immovable."
Therefore, something in the middle occurs. The product is released on schedule, but fizzles. $xx million is not realized and the project is a failure. The project manager did his job. It was released on time and within budget, right?
All the hard requirements were documented, but what was missing was an understanding of the final solution. The PM is so wrapped up in project risk factors, slipping schedule, and budget that he/she can't see the forest for the trees.
Once you are in a project, there are pressures from all sides. The developer can't do it this way unless he re-writes an entire module causing a two-month delay. Or the developer says that something just can't be done and pushes back on the PM. Or the business manager cannot articulate why something needs to be a certain way.
What is needed here is a PM with the knowledge and the intestinal fortitude to push hard. He pushes himself hard to fully understand the vision of the business manager: All the subtleties, all the subjective qualities and the reasons for each of them. He doesn't stop pushing himself until he fully sees the vision of the business manager and that vision becomes his as well. Now you have someone who understands technology and sees the full vision of what is needed to make the $xx million in 18 months.
Now this type of PM pushes back on the developer. He knows if the developer is trying to blow by a fast ball. He also has the leadership skills to push the team above and beyond in order to fully realize the vision.
Short cuts and compromises are not part of the process. "Not good enough" is frequently uttered by this PM. If something is more difficult than anticipated, the PM can speak with the business manager and fully explain the benefits of a delay or the impact of adding the feature or function in a follow-up release. If the feature is going to take two months, the PM works his leadership magic and pushes the team to get it done in one month.
Developers are a very smart and creative group. There are always new ways to approach something to trim a schedule and still meet or exceed requirements. They just need to be led appropriately. I've never met a developer who didn't love a challenge. They just hate getting beat up all the time for missed schedules or a buggy product that tends to be out of their control anyway. When you let a good developer be a good developer, you get amazing results.
Now all the tools and tricks the PM learned during PMP certification come into play. These tools combined with leadership skills, visioning skills and a quality focus makes this PM a super PM.
This super PM is not typical. Most PMs that I have seen focus on the documented requirements and point out to the business manager that he signed off on these requirements if he complains that the product is not meeting his expectations. If there's an issue on schedule risk, he notifies the CIO so that he can try and lead the team to overcome obstacles. This type of PM becomes overhead very quickly.
Finding a super PM is no easy task. Because basically, you're hiring your replacement. See how succession planning just kind of happens when you hire the right people?
So where have these super PMs come from? One successful combination is a very good business analyst that became a developer and then got into project management. Good BAs inject themselves into the visioning process when they're gathering requirements. They just become too far removed during the development from the finished product to really have an impact on product quality during the process. That frustration is typically what drives these BAs to become developers and then PMs. This combination has worked six out of seven times for me personally.
During an interview, ask the candidate to define visioning. How has that candidate used visioning in the past? How has this skill led to delivering successful solutions? Have the candidate tell you about a project that failed and why. What were the lessons learned? What would he/she have done differently?
Ask the candidates to describe their relationship with the technical teams. Find out if it was an adversarial relationship or more of a high-powered team. If it was more of a team environment, you should see a change in the candidate's face when he/she describes it. These super PMs thrive in team environments. They have an inherent, almost genetic, understanding that things can never be done alone and can describe how, at times, the team members could almost read each others' mind.
Ask candidates to define "good enough". When you hear enough of these answers, you'll know what you're looking for and more importantly, what you don't want. This is just an opinion based upon my personal experience. I have found a formula that works and as they say, if it ain't broke....
Play video
» Ultimate virtualization blade
IMPO, the PMP is nothing more than an entry level, knowledge based credential
Hi Jay, While I certainly agree with the gist of your article, I think you have over-rated the PMP. Given the PMP has been around for going on 25 years and there are some 400,000 PMP's we need to ask why projects, especially those from the IT sector, are still failing with such alarming regularity. IMPO, this is because PMI has over sold the PMP, implying much more than was ever originally intended. When the PMP was first created, it was designed for potential team members so that when they joined the project team, they knew and understood the fundamentals of project management. The PMP was NOT originally designed to be a standard of professionalism nor of COMPETENCY in project management. To be realistic, exactly how much faith or trust should we put in the results of an exam that starts with 4,500 hours of UNDOCUMENTED experience; requires only 35 hours of training, (which even a $49.95 podcast qualifies as meeting), and culminates in a 200 question, multiple choice exam, of which only 175 questions actually count and where the passing score is only ~61%? I mean, realistically speaking, would you get on the next commercial airliner knowing the pilot had never actually flown a plane successfully, but has only passed a multiple choice like the PMP? Or how about the same qualifications of your cardiologist if you have to undergo open heart surgery? Folks, we need to be realistic and put the PMP in proper perspective. It tests for one thing and one thing only- knowledge of PMI's unique terms, which are not even universally accepted or recognized. Absolutely nothing more. BR, Dr. PDG, Jakarta
Posted by Dr. Paul D. Giammalvo on Thursday, November 20 2008 03:43 PM