You are here Home PM Value

How does the project manager add value to your business?

By Martyn Egerton

Some years ago I was invited to an interview for the role of programme manager. The invitation was from a US company that specialised in project delivery. They were in the process of building their UK presence and I was impressed by their approach to project management so I was very pleased with the invite.

The invitation told me that I could expect to spend the day at their HQ. I was to meet with a number of senior managers on a one-to-one basis and then in the afternoon I had to present to a group of senior managers. I was told the subject of the presentation was "How can the project manager add value to [their] business?" and I was to prepare the presentation in advance and it was to last no more than 15 minutes.

My first reaction to the subject was disappointment. Isn't it obvious what value the PM adds to the project? I had a week to prepare my presentation so I thought about the subject before putting pen to paper (well, actually it was PowerPoint). The more I thought about the subject the more I thought it's quite a clever question to ask of someone in that role. Go on, prove your worth.

I have quite a varied background. I trained in electronics and spent 6 years as a mainframe hardware engineer. I have also written microcode and assembler before dabbling in C and C++. Since then I have held roles in product planning, sales & marketing, consultancy and latterly eleven years of project and programme management experience so I have seen how a number of disciplines work.

In the early days, (before the advent of PC project scheduling tools), project managers would turn up to meetings with heavy ring binders stuffed full of papers, mostly handwritten with the odd paper typed. The project schedule and work breakdown structure would be handwritten (typed if you were very lucky) and photocopied. This was how projects were administered and every task was known to take so long, no quicker no longer. As a customer if you didn't like the time-line - tough, that's how long it takes. Every manufacturer had their own proprietary project management method. For many this was seen as a way to maintain control and ensure successful delivery. The methods were often closely guarded and not to be shared outside of the company, especially not with customers.

With the explosion of IT in the eighties and nineties as more and more competition entered the market place, as mid-sized servers and desktop PCs began to dominate, things changed rapidly. Not only was there more choice of platforms, more customisable applications, now it was possible to build bespoke applications at an affordable price.

Where once the old structured methods were seen as a way to guarantee success now they were seen as a hindrance. Eighteen month release cycles that were common in mainframe arenas no longer made sense in the server / PC market. The pressure to deliver earlier and earlier became more and more intense. A new breed of developer appeared on the scene, they would code from a minimum set of requirements without a structured design, they would release code with the minimum of testing and if it didn't work they would fix it and release it again.

All the old disciplines of version control, baseline requirements and designs, code reviews and test plans went south. We were now in the age of "iterative development". This new approach sidelined many project managers. There was no longer a need to plan a project, you just got on with it. For some projects this worked very well, for others it was a complete disaster. But the approach did lead to a number of newly defined methods such as DSDM, SCRUM and Agile that have evolved, are successful and are in widespread use today.

Inevitably, having seen how development could be delivered in short time frames, customers pushed for the same approach to be adopted on larger platforms and inevitably problems arose. The late nineties were littered with stories of failed IT projects that were delivered late and well over budget. Many of the disciplines that had been learnt had been cast aside in the pursuit of quick delivery. It was clear that something was needed that would provide a project management framework without the overhead of a structured method. The uptake of Prince2 and Scrum are testimony to how a project management framework can assist in the delivery of a project without being overly burdensome.

So how does all this play into the original question?

I hadn't thought about that question from all those years ago until recently. Well first off whilst it looked like the PM was a dying breed, they have enjoyed something of a renaissance in recent years. A steady hand on the tiller if you will, but I have been surprised recently by the number of organisations asking for PMs with particular product knowledge to a deep technical level. PM skills are to the most part transferable skills. It's not unusual to request sector knowledge but by asking for particular technical knowledge are we playing into the dual role scenario? Let me expand with an example.

It was quite natural for analysts and team leads to progress into project management roles. The one thing that was always impressed on junior PMs was you are no longer a team lead or an analyst you are the PM. There was a very good reason for this.

A team lead moves from his developer role to his first PM role. All is going well until an unexpected technical hitch appears. The team try to solve the problem but are not making much headway. The project executive is aware there is a problem and is worried that the project will slip if it is not resolved soon. The development team sit down with the PM and discuss the problem. Having been an experienced developer for many years the PM is confident he can fix the problem and assigns the development team to other tasks. The PM informs the exec that the problem is being addressed and a resolution will be found. A happy exec.

The PM now owns the technical issue and assumes the role of developer. He works night and day to fix the problem. He gives regular updates to the exec assuring him that the project will not slip. Still a happy exec.

As the next project board meeting approaches the exec asks the PM for the updated project documentation, schedule, risk log, progress report etc. The PM explains that none of the documentation has been updated because he was concentrating on resolving the technical issue and hasn't had time to update the project documentation. In fact he hasn't had time to do much of the PM role at all. We now have a very unhappy exec not a good place for a PM to be in. The PM has in fact reverted back to his comfort zone of developer.

A lot of research has been undertaken into why projects fail and one reason that shows up is project managers holding dual roles. By all means let a PM manage more than one project but if he has dual roles sooner or later one of the roles will suffer. I worry that some organisations may be slipping back to making the mistake of asking the PM to undertake dual roles.

The value a dedicated PM brings to the mix is to be able to step back and see the bigger picture, provide the bridge between the project executive, the business sponsor, the delivery resources and end users. By utilising an appropriate project management framework the PM can ensure predictable project delivery, reduce the risk inherent in any project by implementing repeatable processes, methods, techniques and standards. The PM needs to be focused on the PM role to ensure effective delivery for the organisation. Here is what the NCC has to say about the role ...

"With the ever-increasing challenge on IT to deliver more with less the ability to manage projects and multiple interdependent projects has fast become a critical requirement within IT. Project Management is recognised across both the public and private sectors as a fundamental organisational capability. Projects involve a complex mix of people, technology, organisations and tasks. This will need good control, effective leadership, teamwork, resource management and, increasingly, will invariably lead to organisational change ..."

Back to the top