Who should train business stakeholders on Project Management basics?

Question

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.

Answer 1

Honestly, I'd be cautious about the idea of "training" business owners. You've really just got "a classic salesman's problem." How to convince people that your approach does have merit, that it really will reduce costs and business risk, and that you actually understand their point-of-view. (Which is necessarily altogether different from yours ... trust me on this.)

Usually, you need a champion within their ranks: one of their peers. Someone who speaks the same language. And, someone who can discreetly counsel you on how to approach a particular individual.

To reiterate: the business role of "business owners" and other executives within their same stratosphere is extremely different from yours. The things that "keep them awake at night" are not at all like those which deprive you of your sleep.

Answer 2

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.

Answer 3

This is a systemic problem, and although you may support business stakeholders to understand what prioritisation means, you will definitely need senior management support.

In your case, you mention you have joined the project to stablish a prioritisation method. That's a demonstration that senior management is aware of the problem (which in itself is a big step). However, a Project Management role is intended to help identifying risks and to help tracking project progress, not necessarily to mediate different priorities across independent groups.

Assuming you're in an IT area for a company that has different sources of demand like Accounting, HR, Sales - who dictates the priorities? A common understanding on how priorities will be set needs to be stablished, and to do so at such level, you'll definitely need senior management support. If you're able to stretch your role into Product Management, the better - but Product and Project management are different roles and it's important to manage expectations from start rather than facing frustrations down the road. Note of advise - maybe you were hired to do exactly this. Consider this as some may not want to keep a Product and a Project manager.

Answer 4

You didn't say what kind of projects these are. If you are talking about software, data and technology work then generally it is better to focus on products and value streams rather than projects. In software, projects tend to matter very little and the product is what your business stakeholders should be (and probably are) focused on.

As Tiago suggested, work towards better product ownership and management if you can. If and when your software products under development all have properly engaged owners then those product owners should set the business priorities. If development teams are aligned to product/value streams then they can self-manage to the priorities set by the POs.

There are courses and self-study materials that can help train business managers in product ownership. For example, see scrum.org.

Answer 5

Who should train business stakeholders

very short answer: Someone who has the knowledge

and a hint upfront: It is not only that they should be trained, they must be motivated to do the "new" part of their work and as always with "new" work, nobody wants to earn new workload.

Now the longer and explanatory part:

I have no idea which framework you start to introduce and why you need change the existing workflow. I assume you want to introduce something more agile and leave the pure waterfall way, that said only to understand my thoughts.

From my experience it is important that:

• every one in the organization has to understand that all disciplines have to understand a new framework and must accept that they are part of it.

• that especially in agile frameworks the customer has its role in that framework which means attendance in framework events in a much higher frequency as in waterfall models.

• any try to introduce a framework only in parts ( of the framework itself ) or only in parts of all effected disciplines must fail

This opens the point, that not only the "who" trains someone is important, but more that co-work is absolutely required to make the new framework a success story. That means, that all involved persons have not only to understand what the new tasks for them are but more important, how all the work of all disciplines is interacting. For agile frameworks it has one important part: It is not longer a chain workflow as putting something from the top into the queue and waiting on a product at the end of the cycle, it is now an interactive workflow, where on every team and role interface a feedback loop is introduced.

It is wise to give the stakeholders also the perspective that the total amount of work will not increase, because a lot of (old) work will be reduced. This increase the first acceptance rate :-)

Back to the "who" should do it:

My experience is, that external persons can be react more flexible on questions and have a higher acceptance rate by introducing something "new". Stakeholders are typically feeling "higher" in hierarchy, it is maybe not a good idea that "lower" disciplines try to train them. That is not a question of qualification but a question of acceptance! And it did not help, that upper management tell someone, that "you have to" do something. This may increase the "wall against the new" instead.

My hint: Take some external guide which helps you to setup the new framework over all disciplines even if it requires a bit of money. Let these guys help you all by taking part of all your workframe events, especially by starting new projects or during general introduction step.

In later phases you already have a good chance to improve your workflow by taking all the events set up for this topic. All modern frameworks have the "inspect & adapt" sessions, which can increase interdisciplinary understanding and lets your daily work move forward more softly. This will especially help people which are not have really "hands on the product" but keep customer relations which is also very important.

Some remark on the comment:

It sounds bad to keep old behavior on the track of moving to agile. "Waterfall deliverables" is a perfect reason to fail I belief. Why you need feedback to get opportunities? Who is deciding which workflow you practice? If the organization decides to move to agile, it is not about waiting on getting opportunities. If you see that your current business did not drive well because waterfall did what it always did, you have already good arguments to move forward. And if you decide to do it: Do it! But don't keep staying on the half of the way. That will waste all your resources and all the motivations. There is no "half of agile". You can't earn the fruits if you don't do a full step. Hanging in the mid is collecting the bad of both sides. Don't do it!