Vjylku

I've recently been assigned to a project as the PM and I'm fairly sure that a senior executive in the company has heard some fancy marketing spill at a conference and now wants this product at the company.

As far as I can see, it is an expensive and specialised application to coordinate much more complicated infrastructure than what we have and there is no use case for this product at this company.

I've tried explaining this but there is a lack of technical knowledge and the managers have expectations of all these proposed benefits, all of which are hypothetical and frankly unrealistic.

What is my responsibility here? Do I just accept that even through I disagree with the project benefits, I've been given this task to purchase and integrate this application so that should be my goal?

How do I protect myself when the application inevitably does not do everything that management expect it to do? Morally, should I step down as the PM for this project?

There's a conflict between the Product management and the Project management role.

As Product Manager, you're responsible to ensure the product is viable and will have acceptance within users.

As Project Manager, you're responsible to ensure the project objectives are achieved.

Based on the context, it seems you have a considerable amount of knowledge on the product. As a professional (role-agnostic) you should ensure the proper people (senior management, probably?) is aware of your perspective. Assume you do not have the whole information. Maybe the project becomes reasonable if some other sound changes are applied.

By raising this concern, try to obtain as much information as possible. It's very important for project successful to understand the whole product picture.

If after raising the concern the information or context provided is not enough to make you believe on it, it'll be much harder to manage... get ready. This should also be raised as a project risk. If this is also absorbed by the team, it'll be even harder.

Once your concerns are clear*, you should go ahead with the project as project manager, focused on the project objectives. Ensure project successful criteria are very clear from the offset. And focus on them.

* IMMV. The "clear" will depend on your company. It may be a chat. It may be a mail. A formal risk entry on CMMI.

Agree with @Tiago Cardoso, but I'll provide a different analytical framework.

The PM is responsible to the stakeholders for closing the project.

If the project is authorized based on flawed assumptions (or on assumptions which the PM believes to be flawed), then there is a risk to project success. (I don't remember the statistics, but from memory, flawed assumptions about benefits/flawed stakeholder expectations is one of the major reasons for project failure).

If you have reason to doubt that the project can succeed, then I think your obligation is to voice that doubt early, track it as a risk, and create the kind of information that will allow the project to be closed early when it demonstrates that it cannot meet the expectations.

Were I in your shoes I would:

1. Make sure the assumptions are explicit. Make sure that stakeholder assumptions, expectations etc. are explicitly recorded in project documentation.




2. Work with the project sponsor to craft performance indicators that measure the project's ability to deliver the anticipated results.




3. Make sure that the communications plan includes a section where the stakeholders express the information they want on the project, and that that section includes the metric identified above.




4. Every assumption is a risk - make sure your risk register tracks risks associated with the assumption. Do your best to include risk triggers that will escalate the risk to stakeholder attention when the risk trigger indicates that the project is unlikely to deliver expectations.




5. Work with the other stakeholders to build a coalition to manage expectations for the project (Can anyone remember the Japanese term for building a coalition outside a meeting so that during the meeting everyone saves face?)

And lastly, and most importantly, I would prepare to be wrong. I have to admit that the manager may be right, and this might be the right approach. I have to give the best counsel I can collect, but prepare to be joyfully wrong.

For the past several years, I have read what seems to be a push to extend the PM's accountability not only with the success of project delivery but also product success and organization success. This comes across to me as more of way to expand the scope of a project manager versus something that makes sense.

I 100% agree with Tiago and Mark. The PM's scope of accountability is the delivery of the project objectives. So if you're the PM, and you have no other role in that company, as the PM, your scope is the delivery of the objectives and that's it. If the company is choosing to do something silly, or their business case for their project is heavily flawed, as the PM, that's none of your business or concern. You shouldn't even opine on it because that exposes you spent cycles analyzing it, and that is not in your scope.

If you wear another hat in your organization, then perhaps then in those other roles you would have standing to discuss the business case. Have at it, if that's the case, but do so not as a PM.

As others have pointed out, understanding who is responsible for what is helpful and avoids a lot of chaos.

However, the Golden Rule trumps organizational "walls". If your conscience forbids you to be quiet while your teammate, regardless of position (including the boss) is attempting to cross Niagara Falls in a barrel then obey your conscience, even if just to say "I want it noted that it is my professional judgment that this project needs to be redesigned before it will have a reasonable expectation of success because...".

Depending on what is at stake and the clarity of the flaw in the planning, lying down in front of the barrel may be in order. But if the ship will not sink if the project proceeds and fails or if you aren't certain that it will then make your concerns known, defer to the leadership and expect your "minority report" to eventually be vindicated.

Not too long ago I was charged with developing some ETL in SSIS. The specs called for grouping at one level while I was very sure that it should have been grouped at another level. The manager told me that we were committed to this spec and just to do it per spec. Also I told him that the spec said to get the data from one source but I pointed out that it would be incomplete if we didn't get the data from a different system altogether. Again, we were committed to the spec. Since I struck out with convincing my manager (who, don't get me wrong, was very smart, diligent... he just didn't see this particular spec the way I did, as that was my area of expertise).

To make a long story longer, the program "worked" but gave the wrong results, as predicted. The manager burst into my "office" (a temp situation with a whole bunch of other consultants) and publicly chewed me out (I could tell he was just grouchy because of things bigger than I), asked me if I knew how to program, yada yada... Fortunately I had the example he had given me and my output matched that. He conceded he was wrong and I was able to fix both contested issues fairly easily.

What I'm driving at is that:

• I stood up for my concerns


• I let him have the final decision


• When he was chewing me out for failure I had "peace like a river" because I knew I had given him all the information he needed to change his course


• He changed course and all was well

Had it been a bigger issue I might have gone over his head but in my judgment it was not necessary and instead the whole thing worked out to be a "team building" experience.

What you DON'T want to do is:

• not say anything out of timidity


• overstate your concerns


• create a self-fulfilling prophecy (by causing the failure)


• make it personal

All team members (except you and I, of course) make mistakes and it is everyone's responsibility to communicate.

I'm thinking of the USA auto industry that was producing a large percentage of defective cars. The Japanese were not. We learned from them the value of anyone on the line having the power to suspend production immediately if the line was in danger of letting a defect slip through.

Fortunately, many companies today "get" that assuring their teams that everyone has the right - and responsibility - to report threats to quality product delivery, etc.

The best case scenario is that you report it and trouble is averted. But the second best is if you report it, they ignore it and they realize that they should have listened to you. The worst case if you don't report it and disaster ensues.