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.

5 Answers 5


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.

  • This is a wise point of view in my opinion, indeed what they are aiming for involves things that are not always clear to us at the project management side. Even though we should be aligned with their goals, there are nuances that only them may know, specially when considering the bigger picture. So what you propose is a model of someone within their group with authority to propel upcoming changes on their work model. I think that could be thought of as the sponsor within the organization.
    – BlastDV
    Feb 15, 2021 at 14:57

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.


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.

  • This is more of a business side Project Manager rather than an IT one, which I think makes a difference because management is expecting me to be a bit more involved on what is going on rather than being at the other side (IT) just waiting for priorities to come in, so I think I see what you mean when saying that stretching into Product Management would be helpful. However it still feels like something is missing in terms of prioritization, the to-be would be to have stakeholders figuring their business cases on their own, rather than having Sr management to step in every time.
    – BlastDV
    Feb 12, 2021 at 11:08

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.

  • Would it be fair to point out that what you imply is that the missing prioritization and opportunity identification should come from my role? That is similar to what I have been trying to do, and is precisely when the doubt came in. I've worked in other organizations where business already had notions on how to get the most out of Project Managers, so it felt natural to work there, but in this case it is more like a blank canvas -which is a lot of responsibility if you ask me-. I'm more than happy to help and guide them at my best but I can't help feeling there are things they should know.
    – BlastDV
    Feb 12, 2021 at 11:15
  • @BlastDV I wasn't assuming you would set business priorities. What you could do is coach teams to self-manage and to identify the key stakeholders who can then set the business priorities going forward. Developers should be accountable to product owners. The fact that you phrased your question in terms of "project" priorities seemed like it could be part of the problem though. Don't talk to stakeholders about projects, talk to them about products and outcomes.
    – nvogel
    Feb 12, 2021 at 11:33
  • 1
    That is an interesting approach the one of appealing to products rather than projects, I will certainly consider that as I think it will help them feel like they are actually making progress instead of just adding layers of additional work and processes!
    – BlastDV
    Feb 12, 2021 at 13:41

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!

  • I think what you said about trying to make them feel engaged with the "new" is key, I agree. However the initial state of their workflow looked a lot like waterfall, but worked like decoupled pieces that were progressed when they felt like it. So as a first step I'm trying to formalize the framework and introduce specific waterfall deliverables and concepts to allow them to have a glance of the potential they have if they learn how to work organized. The idea is to get enough feedback to look for opportunities of jumping into Agile, while adding a layer of "order" into their workstream.
    – BlastDV
    Feb 12, 2021 at 11:25
  • 1
    @BlastDV I add some comment in my answer as it was to long for a comment
    – Klaus
    Feb 12, 2021 at 12:28
  • Thanks @Klaus for the extra detail. What I meant is that they had no formal process or framework at all. They were doing something that ressembled waterfall but not much more than that. The concept of stakeholders, project stages, deliverables, inspection points, etc, where not there, and everything was being done empirically. The feedback I need from the company during the upcoming months is to understand if Agile is suitable to us (I'm a new hiring) as there are different dev groups involved with different resources and availability. But I agree on what you said about avoiding half-ways.
    – BlastDV
    Feb 12, 2021 at 13:47
  • @BlastDV: Instead of comment "Thanks", it would be nice to get "payed" by votes or accepting the answer :-).
    – Klaus
    Feb 12, 2021 at 18:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.