Are Project Managers redundant in a digital agency?

Question

I have worked as a freelancer and have experienced this problem several times in various places.

Scenario:

• In a digital agency, there is a coding development team with a coding development lead.
• The agency creates code based projects for external clients.
• There is a project/accounts manager who acts as an intermediary between the coders and the external client.

The following problem scenario occurs (chronological order):

1. The project/accounts manager isn't a developer.
2. Chinese whispers effect happens and requirements get lost/confused.
3. The client wants to speak directly with the developers.
4. The developers end up becoming project managers.

Question What would be a good solution for preventing this and for projects to be managed efficiently?

It seems difficult to find good technical project managers with development experience and who understand development flow.

Answer 1

Disclaimer: I have never worked in a digital agency and I am aware that the role of Project Manager in Digital Agencies can be somewhat different to that commonly accepted in other I.T. operations whether in-house or software development suppliers. Furthermore I am not clear on the exact differences.

Despite my disclaimer above, and taking the question and roles at face-value, I think there are a number of problems with the assumptions made here:

1. The Project/Accounts Manager isn't a developer

So what? These are very different roles with very different responsibilities. In my experience developers often think that the role of Project Manager is akin in some way to Team Lead, or Development Lead. Undoubtedly in some organisations that is the case in practise, but I assume it isn't here as you have already stated you have Dev Leads. So this is a statement of fact rather than an actual problem. It can lead to significant project problems if the PM needs a technical appreciation in order to complete their PM work or if the development team use the PM's lack of technical experience against them by, say, over or under-estimating workload when the PM doesn't have the necessary skills to review and challenge estimates. But it is not, in itself, a problem. It would be worth thinking about why this is a problem to you or to the project as that will uncover issues that can be addressed.

2. Chinese whispers effect happens and requirements get lost/confused

This is a process problem. You don't have robust enough change management, requirements gathering and logging processes in place to ensure that requirements don't "get lost". The PM should recognise that, even if the organisation doesn't, and deploy something locally to the project. However the fact that you (and presumably by extension) the rest of the dev team knows this is a problem and you haven't deployed a solution speaks of other unwritten issues here. It is everyone's responsibility to ensure the requirements are managed properly.

3. The client wants to speak directly with the developers.

There is no inherent reason why this is a problem. It can be a problem if the developers are not able to communicate effectively with the client(s) and this is often the case in the wider I.T. world. Note, I (hope I) am not stereotyping here- developers are goal oriented detail-people in the main, and often clients wish to talk at a more conceptual level with other agendas that developers do not perceive. Conversely clients often cannot discern the true meaning and consequence behind developers' technical questions. There are always exceptions on both sides and I have seen it work well, but it doesn't always. If there is a real need for clients and developers to communicate then it should be facilitated and managed by the PM. I don't mean they have to be the postman in-between the dialogue or present at every meeting, but they should manage when and how it happens and provide oversight to ensure the outcomes from the communications are mutually beneficial.

4. The developers end up becoming project managers.

Do they though? Or do they become what developers think are project managers? Do the developers start actively managing the employers' and the clients' risks? Do they begin negotiating resource levels, contracts and expectations? Do they rearrange the project plan to take into account new dependencies and ensure regular clear communications goes out against the communications plan? etc. etc. etc. If they really do start being project managers then clearly you have an ineffective project manager. Or perhaps you have a PM that is inexperienced and doesn't communicate properly, or doesn't work with the development team to understand what is happening to the project?

Summary/TL:DR

It seems to me that all these "problems" are actually symptoms. None of them on their own is an actual problem (except for point 2. which is a group failure as far as I can see).

So what is the net result of these symptoms?

• Does the project get delivered late?
• Does the project go over budget?
• Is the deliverable quality poor?
• Is the client unsatisfied?

What you have described is, possibly, a dysfunctional team maybe with an inexperienced or just downright rubbish PM, but maybe not.

Start by defining what the actual material issues are, not what you or the developers or the PM thinks are local working practise issues. It sounds like some resentment has built up- try and see past that to the actual problems. Then when you know what is actually wrong you can begin, as a company, a team and an individual to think about what needs to change to correct the situation.

Answer 2

First, you still haven't defined a problem. Clients want to talk to developers - what's wrong with that? What effect does that have on the scope/schedule/cost of the project? On any other project metric?

• Is there a communications plan? Communications between developers and client should be covered by the communications plan, which should also contain provisions to make sure that the right stakeholders have an opportunity to participate in or be aware of the discussions.

• Is there a requirements management plan? If the requirements are unclear, then it seems there is an opportunity to improve requirements capture & management. If the requirements were managed, then perhaps the problem would be diminished?

• Is there change control? Although you haven't said, I infer that the problem is that when the clients have the opportunity to dialogue with the developers, "clarification" of the requirements results in changes to scope/schedule/cost/quality that impact the contract. This wouldn't happen if the requirements were under change management.

To the extent that I understand the problem, it seems that the PM is failing in at least one section of his/her job. The solution seems to be to coach/train/augment the PM to enable successful performance.

Aside: I would also recommend taking a careful look at the position description to make sure that the company requires those skills, and at the recruitment process to ensure that you are interviewing for those skills. If intervention with the incumbent project manager fails, you want to make sure that you don't repeat the issue. (but I think that is outside the scope of PM:SE)

Answer 3

What the OP is exhibiting is a bias, and is using the symptoms of his organization of what appears to be team immaturity, process immaturity, and maybe cultural issues as evidence to support prejudicial thinking.

Every role has a set of knowledge, skill, and ability requirements, and every person who occupies a role comes with different degrees of strengths and weaknesses meeting those knowledge, skill, and ability requirements. Some of us do better than others managing those weaknesses in terms of identifying gap closing mitigators but most of us who are not eventually selected out of the role find a way to perform to some level.

A PM who is missing a technical area in knowledge and skill but who has outstanding strengths in the 100 or so other knowledge and skill requirements can certainly succeed in the role if he finds decent gap closing mitigators for what he does not know while exploiting his strengths in all of those other requirements.

Selection validity is so hard to nail down because there is no such thing as a one size fits all. The needs of any given project at any given time could require a non technical PM who has outstanding soft skills for customer service / salesability at one point and then shift to where a very strong technical PM would be better.

Answer 4

As a PM and former developer working in a digital agency, here is my take on the issue based on my experience and what I've seen previously working under technical leads (as a former dev) and seeing developers previously running the projects at my current company:

• There was no real structure with how the projects were delivered, so despite the technical team being technically able, this did not equate to being able to communicate efficiently. This really came though when there were multiple people working on one project, the technical team had trouble distributing work and forecasting timescales accurately.

The developers just did not have the imagination to improve existing processes to increase efficiency improving how projects were delivered.

• The technical team had trouble requirement gathering efficiently, very often the techies would look at a requirement too technically as opposed to how a user sees it and lacked the 'know how' with organising requirements based on what gives the most business value. This is more of a business analyst role as opposed to PM, but a PM should possess this skill.

• The techies that were managing the projects before lacked strong interpersonal skills which is a must. Keeping people motivated sounds easy, but can be very difficult without resorting to micromanagement when a project is going badly. I have worked for technical leads who saw things so black and white (like coding), that they just did not know how to keep their teams motivated and get the best out of their colleagues leaving them disgruntled in the process.

• Account management is a non technical skill but a vital one. Very often I have to communicate the project status to the end client, and when things are not going well, have to find a way to diffuse the situation so that the client remains a client. This is a completely non technical skill and more about interpersonal skills.

• Budgeting, a key component of my role is making sure profit margins are high for any project I have to deliver. This means having a spreadsheet to keep track of all project costs.

So there you go, being technical helps but there is a lot more to PM than knowing the technicalities of a project inside out. A good PM needs to have enough technical awareness so that the developers don't put wool over their eyes, but it does not need to be in depth. A talented PM will find talented people to handle that side of the project for them, which ties in with resource management. So if anything, having a good overview of the project is arguably much more important, from stakeholder level down to the technicalities of the project.

It is true that developers can learn to become PMs, but not every developer has the right personality to do it such as the technical lead I mentioned.

Answer 5

I've worked as a PM at 2 digital agencies, my opinion:

• It depends!

What on? It depends on the agency itself, and if you actually need somebody other than an account manager & development lead to play some role on the project.

At times, I felt like my role was unnecessary -- and other times, I've felt like the project would fall apart if I wasn't holding it together.

What it comes down to is division of labor. Is there actual work for the PM to do? Or is s/he only there because someone in management felt it was necessary to have a project manager on the team, for whatever reason?

Sometimes, there's only one way to find out. Why not try launching a project without a PM on it, and see how it goes? Figure out what tasks slip, what isn't communicated, and so on. If you find that things go smoothly without this extra person in the mix, chances are their job is redundant at your company. If everything goes wrong (and in a hurry), then you know that this team member has been playing a key role, even though it wasn't obvious at first.

Good PM's make their teams better, find problems, and solve them proactively, so that no one ever knows that a potential problem was avoided. Put another way: When you have a great PM, sometimes you don't even know s/he's there. The job itself isn't supposed to be flashy. Instead, they are supposed to keep things moving smoothly, and get out of the way so that everyone can do their job as efficiently as possible, navigating the project around obstacles before anyone else is aware of them. It's like they are the captain of a ship, navigating around icebergs, while everyone is making sure that the engine is running properly. Just because you don't see all the work they do, doesn't mean they aren't playing a key role.

Answer 6

Looking at the list of symptoms, I would say:

• No.

• bad PMs are redundant (at least in the sense that you could get rid of them without losing much).

• devs who show a talent for it may indeed become PMs, but this should be formally recognized and supported (and be constituted by more than "I make my own schedules")