Project Management

Project Management Central

Please login or join to subscribe to this thread

How do you report stakeholder behavior
Anonymous
The biggest barrier to our program managers is the need to correct errant behavior from stakeholders, to fill gaps, train, improve project briefs and find missing information at the request stage. That’s fine for large strategic projects, but for routine, templatized activities it is a huge time suck. How do you ‘blow the whistle’ that your lowly PM staffers are covering a multitude of sins. In the event that we ‘let it all fall down’ we will be blamed for the failures.
Sort By:
It sounds like your non-"large strategic projects" could stand a bit of tailoring. Don't use a maul where a tack hammer will do.
Discipline in use of tools such as a RAID log can help. Also, a RACI or similar to proactively address who is responsible for what. And when it comes to stakeholders neglecting risk response actions, having them "sign on the dotted line" if they are willing to accept the costs of inaction.

Kiron
If I read your question correctly, the issues you describe are all at the Request For Information (RFI) and Request For Quote (RFQ) stage.

First I would suggest standardize and document your process requirements. Then you can improve on the current state. If you frequently have gaps/missing information, templates or checklists may be necessary.

Training is also easier when you have some kind of documented standards and an onboarding process. It's easy to claim ignorance when there is no consistent "right way". Then it falls on the PM to fix deficiencies rather than rely on mostly high quality inputs.

Smaller projects often have less stringent requirements which allows teams to be more flexible in their solutions, but too flexible can lead to chaos. This is where it can be very important for a PM to differentiate between the minimum "must have" requirements and "nice to have" can be addressed on a case-by-case basis.
I'm not sure I understand the question. Generally errant behaviour is due to inadequate understanding of the project requirements rather than an intent to sabotage - they don't recognize the impact of the actions/inactions.

The solution- speak to the stakeholders to make sure they understand their contribution and the risks they impose on the project by failing to deliver. That should address 90% of the errant behaviour.

The other 10% may require a stronger response. Find out why and mitigate considering anything from motivational talks, bribes to threats, or have them replaced - as may be appropriate. The effort now may save greater effort going forward or even salvage the project.
Stakeholders should be introduced adequately to the project information, so they understand the main purpose of this, and the value that is obtained. Individual Stakeholder engagement must be complemented with Team engagement, through integration activities.
The responsibility of each team member should be determined clearly in a RACI template, and a WBS is necessary to deploy work structure clearly, for visualization of all project stakeholders.
Since these steps are completed, stakeholder behavior tend to "collaborate" mode, since they feel engaged.
Monitoring tools for watch task advance, either for cascade, hybrid or agile approaches, are for comprobe stakeholder work results and confirm we are using adequate Stakeholder Management.
I agree with Kiron. Keith made valid points as well.
I worked for a Matrix based organisation where the internal stakeholders were much difficult to manage than the external ones. The attitude of the different leads was basically to use Project Manager as a punching bag because they were not the ones accountable for finance milestone or facing customers. One approach which helped me is to get a thorough understanding of the product so that I can question the timelines shared. The other way was to maintain MOM in written format and get written acknowledgement on the commitments. Also, including them in Steco meetings and making them face management brought the sense of accountability in them
Agree w most points, specifically - document-document-document. Project Managers being used as punching bags is very real. To circumvent this, I have informal 121's with the Stakeholders (Not within the Project Governance and Communications Framework). Hint that my PM's attempt the same with their peers. Sounds obvious, but not enough focus on these 121's. This reduces the "gaps" in communications and also ensures they are getting the right picture of the Project's Objectives, Status, etc. To re-ietrate, informal 121's.
...
1 reply by Peter Rapin
Jun 23, 2022 1:48 PM
Peter Rapin
...
One of the problems with one-to-one is inconsistent communications and the possible accusations that you are not telling everyone the same story and/or preferential treatment. There is also the potential for lecturing rather than open discussion.

Don't gey me wrong, one-on-one is an important communication tool but its not the only tool.
Jun 23, 2022 2:18 AM
Replying to Ganesan Pillay
...
Agree w most points, specifically - document-document-document. Project Managers being used as punching bags is very real. To circumvent this, I have informal 121's with the Stakeholders (Not within the Project Governance and Communications Framework). Hint that my PM's attempt the same with their peers. Sounds obvious, but not enough focus on these 121's. This reduces the "gaps" in communications and also ensures they are getting the right picture of the Project's Objectives, Status, etc. To re-ietrate, informal 121's.
One of the problems with one-to-one is inconsistent communications and the possible accusations that you are not telling everyone the same story and/or preferential treatment. There is also the potential for lecturing rather than open discussion.

Don't gey me wrong, one-on-one is an important communication tool but its not the only tool.

Please login or join to reply

Content ID:
ADVERTISEMENTS

"The amount of money one needs is terrifying..."

- Ludwig Van Beethoven

ADVERTISEMENT

Sponsors