What Skills and Attributes make the best Project Manager?

Rob
I certainly agree with you despite the fact that Project Managers nowdays need specific skills such as estimating and risk evaluation gained mostly by experience. Project management is the process of getting an initiative from point A to point B within scope, budget and time. Project Management is about execution. It’s the science and art of getting things done.

Dear Rob, Quite correct! But the problem lies with the clients or rather more likely with their HR (Human Robots) department who work to formulae and put these non-IT requirements on because they don’t know any better, or sometimes because they are in fact more comfortable if you are an FSA etc. expert.

While the specific technology is supposed to be irrelevant, in small teams a PM can be called upon to deputise or step in on behalf of an underperforming team member. That may well be the technical lead. But in general project management needs a mixture of book-keeping and cat-herding. Manage the people while making sure that all the Is are dotted and Ts are crossed. Managing the people gets the job done. Book-keeping is insurance against something going wrong. So a charismatic but anally-retentive tyrant should fit the bill most of the time. What do you look for on a CV to identify those?

I totally agree, the PM jobs advertised should stop specifying techy requirements and should focus on the elemental deliverables of that role.

Having said that, the PM does need to get somewhat involved on the inputs of the SME or specialist advisers in order to question the direction the solutions are taking. Simply ensuring timely completion within certain parameters is not enough to secure success. A particular company I know of wanted to expand into a new market which would be a natural extension of their most popular product line. The project was completed within the requirements, however the execution was abysmal because the assumptions made and the research performed was insufficient and the business intelligence missed some key factors. So although the PM managed the project very well, they were too hands-off to probe under the skin to understand the rationales behind the decisions being made.

We shouldn’t forget that the customer does know what they need to achieve in most cases. We are employed for our specific technical skills and our ability to bring the pure technical aspect into the real outcomes world. We have to herd cats true, but in doing so we should be sharing our knowledge. The more we can enthuse the resources rather than herd, the better the outcome. Risk and dependencies are everyday tasks but by no means routine. We can simplify the housekeeping and reporting side with decent software packages, not with layers of expensive products which require other products to make them useful. We can deliver because we don’t look at the blocks but go for the gaps! (I learned that in a very short and dreaful motor racing phase.)

I agree with you in theory, but just look at all the PM vacancies on Jobserve, where specific sector knowledge (and even specific package knowledge) is being asked for. I know this means the client is probably not looking for a real PM, but some sort of package implementation expert, and even though a decent PM could do the job, his cv won’t even get past the recruitment consultant.

I agree with Hilary H – PM’s need to identify the gaps & lead the project towards them explaining why it’s appropriate to do so to all team members.

Depending on the size, scope & client’s nature we can choose to apply a solid or fluid structure – Regardless, behind the scenes I certainly go through the same mantras.

Just like any management role, however it is prefixed, we are responsible for delivering results by identifying peoples strengths & getting the best out of them in line with the clients business/project objectives.

I like to keep it simple & honest at all times.

There is a lot of sense here but I think one of the other key elements is working hand in hand with the project sponsor to ensure that you do understand the un documented requirements and needs. Where the PM understands the sector he or she is working in they can also add value.

Rob, Your terms for what a PM should be seem to be pointing to a Change Manager rather than a Project Manager. A Project is always more than it’s stated aims, it also needs to encompass how the deliverable will impact the business user, how it will interact with outside forces – such as regulation – and how your experience will allow for the ‘added value’ that every business should demand from it’s high paid resource.

I’m with Des on this one. Jobserve is probably the worst example, and they always have “must have xxx experience” as the last sentence in the description rather than the first. I’ve spent 20 years completing projects where I didn’t know the technical details, but that didn’t stop me being successful. Organisations just end up recruiting the same type of people they have now and then wonder why they have the same problems with their projects. Then again I think maybe the organisations don’t know what good project management is. I’ve asked a few clients/employers “what the business case ?” and got a sea of blank faces.

I agree. Why is it then that recruiters want to typecast one? If as a PM, one is mean to just Manage The Project and rely on subject experts for the details, why will recruiters AND employers just not consider broadly skilled well experienced PM’s? I must say, unfortunately, that even having studied an MSc, having Princes2, still finds me hunting for work. I know many who are in the same or worse situations. At this point, I would trade a kidney to have a regular job.

Dare I suggest that recruiters who know their candidates well, and haven’t just trawled the CV database, will be able to promote PMs who can hit the ground running. If a recruiter knows his stuff he should be able explain to the customer that sector and package specific knowledge can mean a narrow perspective and could actually backfire. Generally, as only 66% of Interim assignments go through recruiters, surely the other 35/% would go on recommendation by other interims, or personal/third party contacts?

I agree with the sentiments of this article, especially about the PM getting too bogged down in the technical detail. Managers get results Through other people, like a football manager, they don’t kick the ball, others do that, they prepare the strategy and plot progress towards achievemnt. Much of a PM’s skill lies in managing people. Moniotoring and motivating the project team will go a long way to getting project completed on time and to budget.

While there is some truth in your comments, my expertise is in IT – I wouldn’t fancy project managing building a new house (or – more extremely – a nuclear power station). The main reason for this is that the PM needs to have a good understanding of the project risks and their liklihood / impact, and be able to come up with mitigating actions. While specific detailed knowledge should not be required, some experience arounf the project area will make you a better project manager for that project.

I work on SAP projects and implementations at a big 5 consultancy and almost all of the PMs and upwards have already walked the walk and done the technical graft. This has obvious benefits in the effectiveness of communication between the PMs and the technical experts where the impact of most issues and how best to remedy them is very well understood. Admittedly, no PM is technically omniscient but compared to a non-technical PM, there’s a world of difference. I do agree that good PMs already have enough to do without getting technically involved but their interpretation and appreciation of the technology shouldn’t be discounted. If I were spending my money, I’d want a PM with good knowledge of the techical aspects every time.

If a PM is not to be involved with technical issue just what is he supposed to do? Just what is the job if not technical? He just manages the process? As if there is some mandolic sequence of steps you go through and – magic – out comes a project. Software is the only engineering discipline that believes managers are just process monkeys. Say that to a project manager in the aircraft industry and he will look at you as if you are the village idiot. Just possibly that is why aircraft do not generaly fall out of he sky but most software projects under perform in some way, a large number fail completely.

Definition of PM from wiki:
“Project Management is quite often the province and responsibility of an individual project manager. This individual seldom participates directly in the activities that produce the end result, but rather strives to maintain the progress and mutual interaction and tasks of various parties in such a way that reduces the risk of overall failure, maximizes benefits, and restricts costs.”

@Rizwan Perhaps this should be tattoed onto the inside of Recruiter’s eyelids?

So vague as to be completely meaningless

I’ve recently started a blog, the information you provide on this site has helped me tremendously. Thank you for all of your time & work.

Not vague at all – does exactly what it says on the tin. People from other industries can bring a lot of benefit and innovative solutions, to coin a cliche “think outside of the box” (ref Chris’s and John Ferguson’s entries). ITV has an ex Asda boss as Chairman and an ex Royal Mail boss as CEO, ex boss of Ericsson is heading up BP.

I agree that the PM definition is vague – using a lot of words to say very little.
For me, PM involves delivering all of the requirements, on-time and to budget. Exactly which methodology, deliverables, frequency and methods of communications, issue resolution methods, status reporting, etc are used is the ‘how’ behind this end goal.

@Rizwan, I understand your argument but I’m afraid that I don’t see much value in comparing a CEO to a PM in this discussion. They are two very different roles and the discussion here is around whether technical skills benefit a PM role. I belive that a CEO’s role works around a business’ strategies, business model, market %, direction, etc which requires a very different skillset in which his or her appreciation of technical skills seems a moot point.

A Project Manager is supposed to be in control of the project. To be in control of the project he must be in control of the technical aspects. If he is not he is no more than a project secretary. A Software Project is essentially technical, whoever is in control of the technical aspects is the one who can deliver the project, or make it fail. Believe me: I have been in the industry for some 35 years. I started out on PDP8s, I have sbeen a contractor for some 30 years, I have been on some 40-50 project in that time, I have seen just about every way a project can fail. and the most efficient way a project can fail is for the person in effective control of the technology, whoever that is, to be a bad project leader. Or even more effective, for there to be more than one person in effective control, each with his own ideas. That realy does spell total disaster.

Adrian, at the risk of putting the cat amongst the pigeons. You mention in your first sentence that the Project Manager is supposed to be in control, then go on to mention that actually a number of other people are in control. Should you be surprised when you’ve seen so many failed projects ?
If the technical aspects are well specified and validated/tested to meet those specifications, and the Project Manager doesn’t relinquish his/her authority, then the project should be under control. The Prince2 Organisation section goes into considerable detail to avoid scenarios such as this.

Sorry if my words were unclear. What I meant was the scenario where he Project Manager effectively cedes control to others is the source of many disasters. The Project Manager must remain the ultimate autority in all things, including technical. Requirements must be analysed, not necessarily by the project manager, but he and only he must be the ultimate judge of whetehr the job has been done well enough. He must have sufficient skill to make that judgement. And so on for every phase of the project.

Of course even greater disasters are caused by the Project Manager retaining iron like control, but is not competant. And I have seen too many of those as well.

Thanks for all your comments, there are some really interesting points made here. I would love to hear your feedback on my follow-up blog, which is now live on the IT Jobboard.