A software engineering project for a consulting company vs a product company can be very different animals.  Timelines can be longer in product companies. Less urgency. Less accountability. And probably less chance that you'll find a Project Manager.

Why?  When I've witnessed this it's been because engineers have longer tenure and the organization has grown from four-engineers-in-a-bedroom without (it seems) any outside influences creeping in from modern software practices. They've been heads-down for years.. and dare I say it?.. no engineer will ask for project management.

One such company (half-jokingly I hope) even boasted that there were no windows in Engineering areas, lest they see what wonders were out there..

But I've talked about my struggles inside product companies a lot here already, so this time we'll look at the other side of the fence - consulting projects (I'm currently at Inventive, the fourth consulting company I've held a senior role at, and helped manage 100+ engineers and scores of projects).

Consulting companies always use PM's, for good reason

With a consulting project, there's a LOT more accountability (unless you're building healthcare.gov) since there's a customer regularly being asked to pay your invoices.

Customers have budgets and expectations. They're unlikely to forget that you estimated their T&M project as 12 weeks, regardless if your SOW says "actual hours will be billed".  Managing scope is still your problem if you want a happy customer!

Communication is key (duh, Tell Them Everything). But who does the communication? PM's. Your Client Success team will do the polishing and catch some feedback once a month, but PM's bear the brunt.  

In a consulting company, PM's are critical.  

  • Engineers are so often heads-down in the flow, that they cannot (should not) be responsive to customers every hour.
  • Engineers won't choose to show up to standup if given the chance to code.
  • Engineers don't want to stop coding just because they've hit 80% of their estimate for that task.
  • Engineers don't want anything to do with timesheets.

I'm not bashing engineers in any way - I am one, or at worst was one for many years - but you know they'd rather write code than do almost anything.

And there are many, many more examples of how PM's save customers more money than they cost.

But PM's still cost something

The more budget conscious your customer, the more this question will come up:

Can't I manage the project/engineers myself?

To which the answer should always be no.  Say it with me!  

Even if your customer was qualified, they cannot be on both sides of the conversation. The PM is the necessary checks-and-balances between customer and team. They work for the customer's interests, but also have an understanding and trust of the team.  Plus, they've done this many times before - the customer may not have.

A good PM is your customer's proxy, looking at the engineering output and being a sanity check. Does what we've built make sense? Does it satisfy the intent of the customer, not just the literal requirement?  

How much to budget for Project Management?

As a rough guide, start with budgeting 10% of total engineering hours to the PM role. Two full-time engineers == 8 hours PM per week. At 5 full-time engineers, your PM may be close to half-time themselves.

There are limits to this napkin math of course, depending on customer, project, engineering team, complexity, location, and more, so take this with a pinch of salt.

In fact, looking at our timesheets our actual PM time is closer to a 5% average.  But we continue to use 10% in estimates so that we set expectations at the kickoff of the project when PM percentage is slightly higher.  No-one minds the invoices being lower than expected.

But beware of very small projects..

If you are ever tempted to offer extremely small projects to customers, perhaps a follow-on 'maintenance' project where a small retainer covers a few hours of engineering time each month (and I speak from experience!), you'll notice an anomaly.  

There is also a minimum number of PM hours/week when even that bare minimum of customer communication or engineering management becomes statistically significant.  

In these circumstances it's very easy for PM time to become 20-30% or more - and be left with insufficient engineering hours in the budget. For this reason you should set realistic minimum project sizes or you'll risk your PM's using more budget than the engineers the customers wanted!  

There are many factors that control what your minimum project size may be, but don't be afraid to have a frank conversation with your customer if they have too small a budget to engage with you.  Better to tell them before they engage and become unhappy.