Should there be separate PMs for projects which involve development of new hardware and new software?

Question

My company is developing a new product which consists of several embedded systems. The hardware for these devices is being developed by electrical and mechanical engineers and the software is being developed by software engineers. Of course the hardware guys and the software guys work together as necessary, but since the devices are running embedded Linux, the hardware/software concerns are pretty well separated and the different engineers are able to work separately and in parallel for the most part, independent of each others' progress.

This project has a single PM with a hardware background, and he has been mostly focusing on the hardware aspect of things while the software side has not received much managerial attention and has fallen behind schedule. I, as a software engineer on the project, have often wished we had a software project manager assigned to the project to manage things better on our end. I have tried to fill in as an unofficial software PM as much as I can without stepping on any toes, but I just don't have enough pull to be effective in this effort.

So my question is, do projects of this nature generally have a software PM and a hardware PM assigned? I would like to suggest a possible new approach for our next project, and I'd like to know what has worked for other people in this situation.

EDIT - More details from comments below.

Half the software is being developed in-house and the other half is being done by a contractor.

We have regularly-scheduled hardware reviews and all of our meetings with the contractor consist of 95% hardware talk. We have no idea what the status of the software being developed by the contractor is, other than they are "working on it" and it's "coming along". I seem to be the only one that is concerned that we have no real idea of the status of the software after 1 year of work so far. I have tried to convince the PM that we need more visibility into the software status, but he doesn't seem concerned, even after hearing my suspicions that the contractor is way behind schedule on the software side.

I feel that if we had a Software PM, we would have a much better handle on the software status and we wouldn't be at such risk of schedule/cost overruns.

Answer 1

This is about span of control. And there are rules of thumb to help an organization decide when it is time to put in a layer of control. Of course, there are competing and contradicting schools of thought on this. You need to research the benefits, costs, and risks of different approaches to see what fits best in your organization for this project at this time.

You will likely find rules that say at about six to eight reports you need a layer and other rules that say you can go as high as 20 reports before adding a layer. A lot of this thinking is economically driven rather than validity of the thought. You have to sift through that.

If on your team it proves adding a layer adds more expense than benefit, the attention paid to the other team might be out of necessity, e.g., that team is struggling and that degree of attention is warranted, no matter the struggles your team is having...at least up until your struggles exceed the other team's. That just has to happen because no project is ever perfect and you have to pick your battles.

Another aspect to look at is the natural evolution of team roles that develop. Throw five or six people at a task and you will see, over time as the team matures, the individuals gravitating to various team roles, including a lead role. I'd be surprised if this is not happening on your team, though it may not be if your team is imploding. If it is happening, exploit and enhance it. The one who is sort of taking ownership as the lead needs to continue in that evolution, which means (s)he needs to begin overseeing not only the task but also the management and control of it, including costs, schedule, risks, and other leadership things. If this happens to be you, run with it.

EDIT to follow additional information: After reading your additional comments, it appears the issue is not a lack of SW PM, it is a lack of PM controls and methods. It is typical to throw a person at a problem the same way we blame a person when things go south. A more sophisticated analysis will likely show other capability enabling issues, such as weak and out-of-control processes, weak tools that lack integration, weak organization intellectual capital...and certainly it can also be due to weak people performance.

The piece of work farmed out needed to have other deliverables as part of that contract, things like a schedule, reports on a set frequency, intermediate verification and validation of scope and milestones, things like this. Flying blind to the end date is using hope for strategy.

So certainly your current PM has some blame for not enforcing or causing these controls to oversee your farmed out work; however, you may have bigger issues with your organization and its current maturation level around project management methods.

Answer 2

I think there are two problems here. I cannot improve on David Espina's description of the Span of Control problem; the second problem has to do with accountability. The PM is focusing on the areas where his technical skills are most applicable and failing to exert effective project management over the project. I think the H/W vs S/W issue is a distraction; the core issue is that the PM is failing to exercise effective oversight over cost/scope/schedule.

You propose insertion of a S/W PM as a solution. I don't have all the information that you do, but my preferred intervention would be to assess the impact of the problem. For political reasons, you'd probably have to brief the PM first. I would avoid discussion of HW vs S/W. I would focus on:

• The tasks/WBS lines that are delayed
• The impact of the delay on the project's scope/schedule/cost/quality/fitness for use/enterprise objectives
• The root cause(s) of the delay
• One or more solutions to the root cause(s)
• How to measure whether the solutions are working (if they aren't, it may be necessary to brief stakeholders about the risk of project failure.

That would be my advice, and I guarantee that it is worth at least what you paid for it.

Answer 3

The more I read this question and think about it, the more it seems that this is really an issue of you working in an environment where there is limited information about a project's progress and therefore where informal relationships take the place of a clear reporting process.

Rather than dwell on the problem, let me propose a potential solution. You should be the change agent. Meet with the stakeholders/project sponsors, understand their goals and build a high-level baseline plan on what milestones/deliverables the project should be hitting at what times and how much that should cost at each milestone. Then try to track where you are. This will help quench and quantify your interest in having more formal information. It will also show you whether this is a corporate culture you can comfortably stay in. If they are receptive to it, great. If not, it may be time to look for another job.

Answer 4

The project should be sub-divided as you suggest only if it is so complex and/or critical for your organization that there is business value in having the added overhead. For example, I've worked on US govt projects that have had multiple PMs overseeing different aspects of the overall project just because the workload was that big.

I think anytime you have a PM with deep technical knowledge of one aspect of a project you run the risk that they will get sucked into that part of the project at the expense of other parts. This is something that can only really be solved with proper mentoring of the PM and better training.

Personally, I am more in the camp that thinks that it is better to take a person dedicated to project management as a discipline and train them to a base level of knowledge about the project's products rather than trying to turn a technical expert into a PM. At the end of the day the underlying principles of good project management will be the same regardless of your industry.

Answer 5

Why This Isn't Your Problem

This isn't your problem. Whether or not a project succeeds (and most don't) is the responsibility of senior management, although management may delegate day-to-day operational responsibility for the project to a product or project manager.

Since you've already notified the accountable person that you feel the process is broken, you have discharged any professional responsibility you may have. It is up to those with responsibility or delegated authority to inspect the process and adapt it as necessary.

Visibility and Transparency as Process Issues

The core process issue you're facing isn't about lines of responsibility, or the professional background or areas of expertise of those in charge of the project. You've already clearly identified the real issue as one of transparency:

We have no idea what the status of the software being developed by the contractor is, other than they are "working on it" and it's "coming along"...we have no real idea of the status of the software after 1 year of work so far.

It seems like reporting on the software side is not something that your current project manager is accountable for, nor is it something that senior management has tasked your team to manage. Senior management is ultimately responsible for managing that side of the project, and it is really up to them to determine whether their current process is adding value to the organization.

The lack of organizational visibility into the software development process can certainly be labeled as a process problem. However, unless it is impacting your team, it's not your process problem. You're just tilting at windmills if you try to fix a process problem that doesn't fundamentally involve you, your team, or your assigned responsibilities.