Who should train business stakeholders on Project Management basics?



  • To clarify, I'm working as a Project Manager for a company where such concept was mostly unknown across business stakeholders. While projects were being done, no specific project management framework was in place, so everything was done on an ad-hoc basis.

    Part of my job have been to stablish a method to prioritize projects trying to quantify them and create a framework of deliverables and stages to align everyone on. (I am no expert but that sounds as a different role, more like stablishing a PMO).

    The question I have is, as business stakeholders don't seem to understand intuitively why focusing on prioritization and working on a solid business case is highly relevant, I'm curious to who should be training them?

    Obvious answer would be me, but that would add an additional responsibility in the sense that perhaps stakeholders should learn that elsewhere and assuming the task on my own may leave gaps or misconceptions.



  • I wanted a little more background, and by reading your other posts I see that you are/were a product owner for a group of 10 developers. I will answer assuming that this is still true, but the answer will be much the same if your position has migrated to a project manager within DevOps. It just means you will work with the current product owner to provide this guidance.

    As you have hinted, this may be more of a PMO issue. However, I don't think the solution has to do with approaching them from any perspective of "training."

    Others my disagree, but when something is not working right with our stakeholder interactions, I find it more productive to consider that the ones needing training are me and my team (currently 41 people across multiple projects). Our business stakeholders are experts in what they do; they have neither the time nor the desire to learn about our jobs.

    So if this occurred here, I would want to help the product owner get a clear understanding of the business value of the projects (or the backlog). We need our product owners to gain that knowledge, and to present it in a way that is relatable to the business.

    Others may have better ways, but we present the business with a spreadsheet that lists projects (or Epics). For each one we have summarized the business value, a rough estimate of the level of effort, the anticipated return on investment, and the relationship of this item to the others on the list (relationship, dependencies, etc.) If we cannot accurately create the spreadsheet, then we do independent research or engage with the business stakeholders until we do understand. We sometimes find that one-on-one is more effective than in a group, but that varies by the personality of the organization.

    This assumes that the stakeholders you are supporting are within the same business area, with all of their interests and goals are aligned. If they are in different areas, with competing interests for the priority of their projects, then it is more of a PMO challenge. In that case we would still use the spreadsheet, but a higher authority than any of the individual stakeholders would be making the decision about which projects we should focus on.



Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 1