How can I handle objections about the percent of utilization of a non-technical PM?

Question

One of our best PMs is a non-technical PM. She used to be a BA, not a developer, and is extremely detail oriented, has excellent communications, is Scrum certified, etc. We are placing her on one of our highest valued Fortune 50, but the customer has raised an objection that since she is not technical she will not be able to fill her "slack time" with development time.

In reality, we just don't think there will be any slack, and in fact a technical PM is a bit worrisome for us as it is a large project and we want to make sure that the PM takes care of all the team members. Communication with the customer takes 3+ hours a day with all the emails, and meetings by itself.

How can I handle objections about potential PM idleness stemming from a lack of technical ability?

Answer 1

I've been very successful as a program manager and now agile coach, in Silicon Valley, for over fifteen years based on a completely non-technical background. I've faced this argument many times in the earlier stages of my program management career. My technical skills are at a basic advanced computer user and I've never coded.

When faced with these arguments I provide three reasons why I am well qualified. Two of those are fairly universal to any non-technical PM.

1- Perspective: As a non-technical person I am able to avoid falling down the rat hole. Because I don't have a technical background, I remain focused on the project itself and ensuring the project is a success. Whether we use one SQL query or another is not something I need to worry about. If we are getting enough work done to meet our schedule is something I need to worry about.

2- Force Multiplier: This one is best done through a short example.

"Say you have a team of five engineers and you want to improve productivity. If you hire a sixth engineer, in theory you will improve productivity by 20%. However, the law of diminishing returns and also the principles of team dynamics tell us that we'll probably only get 10% more productivity. If, however, you hire someone to focus solely on the program and helping the team and this person helps each member of the team get 5% more productive, than that one person has improved productivity by 25%. That's more than the best case of hiring one more engineer."

3- Broad Experience This one is more specific to me. In my career I've worked from computer games to enterprise virtualization to hard drives. I've also worked in support, QA, product management, business development, project/program management and agile coaching. The broad experience allows me to work well with almost any team.

Answer 2

TL; DR

You and the customer have both fallen prey to the "100% utilization fallacy." This puts the project at risk. Build more slack into your project management process, not less.

Analysis

[T]he customer has raised an objection that since she is not technical she will not be able to fill her "slack time" with development time...In reality, we just don't think there will be any slack, and in fact a technical PM is a bit worrisome for us as it is a large project and we want to make sure that the PM takes care of all the team members. Communication with the customer takes 3+ hours a day with all the emails, and meetings by itself.

Both you and the customer are making the same error. 100% utilization of any resource is undesirable. It is a "project smell" that causes bottlenecks, reduces flow, and prevents the project from dealing with even a normal distribution of schedule perturbations.

Expecting more than six hours a day of "real work" is not pragmatic. If your project's communications overhead is already projected at 50% of a project manager's capacity, you're essentially saying you expect that person to actually manage the project in three hours per day or less.

Is 15 hours a week of gathering status, reporting, schedule adjustments, preparing project management artifacts, and other routine tasks adequate? Probably not.

Even if it is, is there sufficient slack in that time allocation to handle unforeseen events, resolve problems, or handle anything that is not strictly routine? Again, this seems unlikely.

You need to build more slack into your resource allocations and scheduling, not less. Anything else is setting the project up for failure.

Answer 3

Looking for a general argument would not be the best approach. This is a long term debate and, depending on how you grew up in the field, you would favor one or the other schools of thought. There is no winning this debate.

Instead, identify the specific argument for this particular PM for this particular project in this particular environment at this particular time. There are simply some cases where a technical PM would be more appropriate and other times a non technical PM would be more appropriate. That's because all projects are different with different sets of stakeholders and different environmental aspects and risks. This means that the requirements of knowledge, skill, and abilities of a PM would differ in order to meet the demands of that project.

So acknowledge the fact that some projects would be better served with more weight on technical knowledge. But make a case for why her strengths, her areas of knowledge and skill, would benefit this particular project now. What are the constraints being faced, who are the stakeholders, what are the legal ramifications at play, who needs to get sold something, etc., and then show how her knowledge, skills, and abilities are predicted to be better while also showing how you will mitigate her technological knowledge deficit.

EDIT to answer Comment: Here is a real example: I was asked to take over a very technical project--multiple different types of modalities--from a technical PM because the customer was not happy. It turned out the customer was not a technical person and had a ton of issues communicating with the technical PM. In addition, there were other stakeholders with competing agendas where a lot of "sales" needed to occur. This is not to say another technical PM could NOT have turned this project around but in this case I had the skills more conducive to this situation than any other technical PM available to us at that time. Indeed, I had a ton of issues understand all the technical stuff going on and had to find mitigating workarounds in order to make this work but most of my time was dealing with the customer in more a business / sales / "therapist" than the actual content of the work. Once that was calmed down, I had less to do and turned the project back over to someone with more technical skills. Worked out great.

Answer 4

I also face sometimes questions concerning the sense or non-sense of PM. I usually argue as follows:

1. Having a technical problem it's obvious to introduce a specialised and experienced person. But this requirement should not count for the one personnel responsible for the overall project success incl. budget and time management? So we might agree that you require personnel, being specialise in PM. Providing some kind of respected PM education on this point helps in the following.

2. PMIs PMBOK defines several PM processes that should be at least known by the PM (from PMIs point of view), defined within project groups:

   • Project initialisation
   • Project planning, incl. keeping the plan updated
   • Project execution, incl. stakeholder management and necessary team development
   • Project monitoring and control, incl. change control and parts of the risk management
   • Project closure, incl. finishing a project phase, e.g. milestone

   Giving this or a similar overview about the PMs job to be done usually helps to prove the estimated PM effort regarding the project.

3. As for some of the best design solutions, if you say afterwards: It's obvious, that this is the best solution, maybe the engineering team just did a great job. So there is a big chance that if a non PM says: The project runs so smooth, we could drop the PM effort, maybe the PM just makes a great job :) The PMs job is to keep the keep the customer satisfied and the teams productivity on a high level. If the PM is really successful, the project looks like a perpetuum mobile.

4. Call out a dedicated technical responsible / chief engineer / responsible system architect observing the project from a technical point of view and assisting the PM in communication with the customer on the technical details.

This way to argue should bring the discussion away from the person and towards the estimation of the PM effort. Sometime you will just not agree on this estimate. So my last not-so-nice-but-I-have-to-get-a-meeting-and-need-to-end-the-discussion-point is sometimes:

5. Having an experienced PM, this person will not be working for 100% on the project because the experience is requested by other projects too. This fills remaining slacks.