Making Late Projects Later

"We're so sorry Denny. We've done everything we can, but we're going to need six more weeks."

This was the second extension requested during a short time. There were signs that the second request was coming. For their part, they did sound genuinely apologetic.

"Oh really?" I asked trying to gather my thoughts. Is there anything we can do to speed this up? Contractually, our hands are tied. Then the vendor said something unexpected.

"I mean… we've got three project managers on this."

In Fred Brooks' canonical book The Mythic Man-Month, a simple concept is iterated over and over: adding people to a late software project makes it later.

After taking part in several software projects in various roles, I have never seen a project manager added to a project. Turnover, yes. Addition, no. In my experience, the instinct is to add more programmers.

What compels the addition of project managers? Complexity.

The thought behind adding project managers is that they will be able to cut through the fog and convey a clearer picture to the rest of the project team. What kinds of complexity needs to be navigated? In my experience with software development, most complexity is derived from one of two sources: people and system design.

When roles and responsibilities on a project team are unclear, team members may not feel empowered to resolve issues at their level. When requirements are not clearly translated from the customers to the developers (or customers simply change the requirements), complexity arises.

System design needs to consider the maturity of the technologies used along with the experience of the developers. The design itself should be focused on simplicity.

As professionals, we should strive to streamline processes and find better abstractions. Be aware, though, that these sorts of things need to be normalized to help team members have a better understanding new processes/technologies.

You may also like