September 28 & 29, 2020 | Virtual
Please login or join to subscribe to this thread
1. Absolutely not, ALWAYS communicate client requests to the team/stakeholders.
2. Document everything-get all requests in email form- even if the client won't, you email them saying "just to confirm you request is..... that way he is covered.
ad 1: Same as Hank. He must communicate, especially his concern related to implications and come up with suggestions.
ad 2: Communicate and discuss with the team the implications, working out suggestions how to proceed, get structured acceptance process in place as this is needed for both parties
ad 3: Write down the reaons why client demand is unrealistic and present also the implications. Make a propsal how to proceed. If company futher ignores the suggestions and PM role, it is time to step out.
My responses to 1, 2 and 3:
Your colleague should have informed the Management Team/Key Stakeholders. Any client or management team that pressures a PM to do the wrong thing is setting that PM up to as a scapegoat, and when the project fails the PM will be blamed and probably fired for it. Therefore, trying to please the client in this situation won’t ensure job security.
A PM’s best defense in any situation is to have a record of clear, honest communication, especially when others don’t want to accept certain truths about a project. That way when the project fails people will remember that the PM had the integrity and strength of character to do the right thing.
I do believe communication plays a major role in project execution. While you may not have to cascade every single detail to all the stakeholders; as PM's we should be able to identify what information needs to be discussed/shared and the relevant stakeholders it applies and hence need to be brought to the discussion. In some cases may be all your stakeholders and in others, it won't. For this instance, since the request is coming from a major stakeholder (client); most likely should of have had a quick meeting with the team to first extend customer's request, seek a solution and analyze its viability and finally to reach consensus and build a proper answer to customer (whether an acceptace or rejection of the request). All the above can be documented and not only protects the project and the business itself, but also customer. Minute meetings or summarizing/confirmation emails after meetings can be used to consolidate the discussion and agreements between customer and PM. Whenever I engage in a conversation with customer (or other stakeholders) I follow up with an email stating "as discussed.....", highilight relevant points and if applicable request for acceptance/confirmation.
Now I dont' suggest the above can be used as a standard, because of course each PM will find the most suitable way to ensure new requirements or variations are captured; but I consider is a good example.
An lastly; unrealistic demands from customer come everyday but the way I have found makes it easier is first understanding the nature of customer's request; anaylizing the impact on delivery, cost and quality (and any other risk if applicable), presenting that information/analysis to key stakeholders such as Senior PM (specially when there is a high impact in cost and it then becomes a business decision as to what the firm wants to do to keep customer) and then formally reply to customer on a traceable document (formal letter most of the time).
I strongly agree with Eric, honest communication is key. Regardless of what the response may be, being honest with all stakeholders has proven successful.
1.Did he do right thing for not informing Management Team / Key Stakeholders
2. What better should he would have done though he know client would ultimately blame him because it is not documented anywhere acceptance or non acceptance
Dialogues, agreements, expectations, committments all need to be documented and stored as artifacts of the particular effort.The more one works in a silo, the less the team around them can help and support them.
3.What should be his strategy to deal in environment / culture, which is known to meeting client unrealistic demands at the end ignore PM's roleThe clients request is part of the incoming work.
Its an effort with the team to determine the ability to reach those time constraints based on the scope of the effort and the budget/cost. The decision to accomodate the clients date request does not solely lie with the PM. So, in this regard, not communicating the request was not inline with hte responsibilities and [professional] obligations of the PM.
One of the reasons because project managers fail when working as project managers is because they do not understand that decisions about cost, time, scope and quality must be taken for the stakeholders not for the project manager. Project managers do not own the projects, they are not the owners. The stakeholders are the owners. In fact, a project manager never have enough information about a key point to take decisions: the impact those decisions are creating inside the organization. So, your colleague was "dead on arrive" due to her/his project management style.
Agree with the responses above. It's really important to keep communication channels open and talk about requirements and expectations, even if that means having difficult conversations.
Thank you so much for your valuable advice. I would definitely share these responses with my colleague and it is also good intake for me as well.
Please login or join to reply