As they say, “a good sales (wo)man can sell any product, and a good project manager can manage any project”. I, myself, have used this line a few times in the past.
Great communication skills, ability to listen to your team and stay attuned to your client needs, ability to find the balance between the two, make timely decisions, and stand your ground with a smile are fundamental skills, regardless of the domain area of the project.
However, as with any other craft and trade that takes years to master – there are nuances. Not all project managers (PMs) with X years of experience are equally equipped and fit for every job. Akin to how you may have your favorite physician or general counselor, but in certain cases, you may need to find a pediatric specialist, or a Traffic Court lawyer. Similarly, you may need a PM with a certain specialty to get the job done. When the deadlines are tight, there might not be enough time for a good generalist to learn the knowledge domain needed for the project.
Here are a few considerations to keep in mind when evaluating PM resumes (after all other criteria for education, years of experience, certifications, project size, and salary range are met):
Did the person manage IT or non-IT projects? This one may be fairly obvious, but every once in a while I will come across a resume of a PM with 20 years of experience managing business initiatives and organizational restructuring projects. Prior technical exposure and background are important for the PMs to bond with their teams (and clients).
Was the PM mostly a PMO PM or in the trenches? There are a number of experiences that the PMO PM never had to develop (usually in the areas of people management, staffing a project and building a team) and vice versa (dashboarding, executive reporting, condensing large volumes of project performance into pretty PowerPoint slides may be a little foreign to the entrenched PMs).
Does the PM have mostly Infrastructure Management or Software Engineering project management experience? I haven’t seen many software engineers that are good sysadmins and vice versa, and the same applies to the PMs. The DevOps movement is adding a little wrinkle to this notion since “infrastructure” is supposed to be treated as “code”, but I still see strong patterns.
Was the PM mostly in the public or private sector? Public sector PMs understand better the government acquisition cycles and the contract management processes. Private sector PMs generally have a higher sense of urgency and appreciation for time-to-market.
As secondary to the above – what is the government agency or industry vertical the PM had exposure to? Dealing with SoX requirements (Financial sector) is a little different from HIPAA (Healthcare), and the DoD software engineering lifecycle and lingo is somewhat different than in DHS.
Once past this initial triage, the fit is at about 60%. Some clients and recruiters try to go a level deeper and try to find a perfect match looking for the specifics – “Java project experience”, “mobile development”, “big data”, “SalesForce implementation”. In my humble opinion and experience, this is unnecessary and acts as a mechanical filter that can exclude some very valuable candidates. Managing a Java project is just as complex as managing a .Net project. Some COTS implementations have so many customizations that they are hardly much different than a greenfield project. Modern web applications, almost by default, are required to be responsive and mobile-friendly. Of course, there are nuances, but that’s what the architects and technical leads are for.
The primary responsibility of a PM is to communicate and sell their project.
Instead of focusing on a particular technology, I usually take into account couple of other factors, especially if I am hiring for greenfield or modernization projects:
Does the PM have the greenfield/modernization experience or they have done mostly O&M work? The level of complexity and uncertainty is a lot higher in a greenfield project and requires a different level of stamina, decision making, and reasoning skills.
Does the PM have experience starting up and closing out projects? This used to be a lot more relevant in the waterfall world, but it is still applicable in Agile projects. The “startup” PM has the power and responsibility to select the team, establish the processes, set the tempo and elevate the quality standards. It takes incredible maturity and level-headedness to lead a team through the initial forming, storming and norming, until they start performing. Selecting an inexperienced PM to kick off a project has long-lasting (negative) effects.
The above is only a general guideline. There are too many exceptions to the rules and I have seen too many incredible career paths. My personal rule of the thumb has been – if I see ~60% match on a resume – I am ready to interview, and if I feel 80% comfortable after the interview – I am ready to make the offer. There is never a perfect match and moving forward with a “good enough” candidate is a lot better than a hiring paralysis.
PS: Never trust a PM who has “delivered all projects on time and under budget”! When statistically 70% of all projects fail at least one of these dimensions, the said PM had either never managed more than one project, or they are have never managed a real project. Real-life projects are messy and they never execute according to the project plan. When I interview PMs I zoom into their “difficult” projects and I evaluate the candidates not as much on the basis on their successes, but on the basis of how honest and transparent they are and the lessons they have learned in the past never to repeat again on my projects.
Bella Trenkova
Comentarios