How can project management process influence the product management process?

Question

I experience projects in which Product Managers delivered the requirements with a great delay. In other cases, the requirements were delivered only for 1 or 2 sprints, then the PM left the company. Another situation was when a product manager gave us requirements at high level, and when asked details, he would endlessly speak without answering to the point.

I wonder now how can the project manager process influence the product management process, bearing in mind that project managers are under the constrains of budget and time?

What kind of levers are most useful in these kind of situations?

Answer 1

See my comment above; I think the answer is highly localized to the company. I'm going to suggest two levers that could be used, but either of these could be a career ender in your company.

The core of the answer is that you are responsible for project closure, not completion. If the project is going to fail it is in the company's best interest (and your best interest) to fail fast.

The first lever to use is risk management. Document that:

• Project X is three months behind because the product manager left the company. The project staff are being diverted to work on projects where the product manager is involved and active, and I don't blame them. This is 90% likely to delay production at least six months (three months to hire a new product manager and three months for him to get up to speed). We cannot mitigate this risk on our level and it will only get worse as time goes on.

• Project Y is two weeks behind, and falling further behind. We cannot begin design until we have a set of testable and deliverable requirements. Product manager YPM has not been able to supply them - he has high level goals, but we haven't been able to pin him down to testable deliverables. If we proceed without requirements, the project will fail unless we receive divine intervention; my staff are good, but they cannot read minds. I'm asking you for permission to restructure the project to include users X,Y, and Z and stakeholders who will own the requirements. My staff will sit down with them and develop a set of requirements that we'll submit to Product Manager YPM. I'd also recommend that we revise the schedule to deliver a prototype - that is a standard way of mitigating the risk of fuzzy requirements. What do you think?"

PMI says that you have the power to close a project unilaterally; that's not true in the real world, but it is still a lever you can use.

• "Boss, Project X will fail in six to nine months. The product owner has left the company and the company hasn't appointed a replacement or even an effective acting product manager. This project doesn't have the stakeholder support required to succeed. Unless you can convinced the board of directors to appoint a product manager, I would recommend closing the project and reassigning the staff to other projects."
• "Boss, Project Y will fail in six to nine months. The project plan identifies "requirements" as the next critical deliverable. I've had three separate meetings with the product manager and he hasn't been able to supply any requirements. He has some high level goals and visions for the project, but no testable, deliverable requirements. I've met with him and told him that I planned to talk with you and recommend cancellation unless we can bridge the gap between goals and requirements. He is unwilling to budge. If this project is important for the company, I think I need some support to set up a summit where I can lock my staff and his staff in a room until they can build a bridge between the goals and requirements."

The key is that in all of these cases (1) you demonstrate that you've done as much as you can, (2) you're asking for specific support, and (3) your recommendations are in the context of the company's bottom line/best interest. But you've got have really done your homework and you've got to have developed a relationship with the boss/stakeholder/whoever that will generate the trust you need.

Of course the final lever is to seek a new job. If you can't address the situation through risk, and you can't address the situation through recommendations to stakeholders, then your best approach may be to follow Product Manger X out the door. But I'd make very sure you have a good way of explaining why you chose that exit strategy for the next interview.

Answer 2

You can influence the product process only by stressing that the project mgmt process is only as good as the information that goes into it.

If there's a deadline, then remind everyone that that the project can't start until the requirements (scope) is known and delivered to the team. The clock doesn't start ticking until that happens.

The adage of Garbage In, Garbage Out holds for pm as well as anything. If the team isn't provided what they need, they can't be expected to produce what's desired.

Answer 3

My team used to face this kind of issue for over a year until we managed to work out a way of cooperating with the Product Manager/Owner that ensured the team received timely info and constant feedback.

It's not something straightforward to achieve. IMHO it highly depends on the maturity of the processes in place as well as the individuals.

If I had to suggest one single aspect to focus on, that would be increasing the frequency of status meetings until the situation is more or less stabilized.

I currently hold weekly status meetings. A year ago I had to meet 2 or 3 times a week with the Product Owner. He is a busy person and wouldn't fully understand the need for so many meetings at the beginning, but eventually he understood our side.

Currently the level of scope creep on projects is very low, and work on analysis/design phases is intense and gets the deserved attention by all stakeholders.

Answer 4

My personal opinion is to keep project and product management as far apart from each other as possible:

• Project Management: Get stuff done in time and budget.
• Product Management: Do things right for the next 10 years to come.

Better use different PMs, different developers and preferably even different departments.