I sometimes get the feeling that people do not always fully appreciate what the stakeholder view actually is, and how important it is to the success of a project, and how it forms the basis of an engagement plan.

I have spoken about Stakeholders in Architecture before. There are many types, and as they are the people, or teams that we are providing value to, it’s really important we understand them. Some points would like to stress:

A view in Archi – is not just a picture, it’s not just a model it’s a view. It’s a way for the architect to tell people how we see things. It’s what the word view means – to see, watch, to look on in a particular light.

I think its ok for architects to create a stakeholder view by themselves, mapping out the stakeholders, drivers, and goals, and adding their own assessments, but this should only be a starting point. A stakeholder view is more than just a collection of elements and relationships. If we start by drawing these views with Architect’s, it’s really important to validate them with the stakeholders. There are a few reasons to do this:

  1. In doing this, we get to validate and see if our assumptions as architects are correct.
  2. When stakeholders review a view, often they come up with new stakeholders, or thoughts, because architects don’t always think in the same way or see the world in the same way as the stakeholder’s do.
  3. When we validate, we are engaging with the stakeholders, and in doing that and listening to them, we can turn architecture from being a negative thing people just think has to be done, into a positive thing that is providing value.

It’s very easy for an architect to make assumptions as to what a stakeholder wants, and for a senior manager to sign off on that – and there’s an English expression that covers this: Assume makes an Ass out of u and me. Assuming things for our stakeholders robs us of the possibility to really get engagement.

Making an engagement plan

Engaging people doesn’t mean we have to individually get feedback from each and every stakeholder, and it doesn’t mean that we have to communicate in the same way with them all. I mentioned before in my previous blog that we can engage with different stakeholders in different ways. It’s worth sitting down with a project manager at the beginning of a project and making an engagement plan, where you make it clear how you are going to work with each stakeholder – some common questions to ask may be:

  • Do I need to get feedback from the stakeholder, or am I just informing them?
  • How many of these different types of stakeholders do I have?
  • What would be the most appropriate way to connect with them?
  • Given what I know of their needs – what should I be communicating to them?

Once you have started to think on these questions for each of the stakeholders you can start to think about how to engage them. Having this plan can make a huge impact on a projects perception which can make a project teams life significantly easier, when it comes to communicating, interacting with people and getting new funding. Nobody wants to be on a project that’s everyone hates and thinks will fail, I’ve been on these projects, and they are no fun. One demotivated stakeholder can have a chain effect, and everyone’s energy shifts from solving problems, to complaining about them, which can have a huge impact on efficiency.

Perception and communication can be key to a projects success. I once ran a project that took twice as long as was planned, cost 4 times the amount of money… but it was considered a success by everyone that worked with it. The reason? because although delayed and bad things happened, as they were seen and identified they were communicated. Everyone was informed, which changed stakeholders from being an outside group of judgemental people into the projects greatest cheerleaders. they were with us for the ride!

Below I want to talk about some different types of interactions we have with stakeholders. for some stakeholders we may mix the different approaches – for example at beginning of project I may have direct engagements with some stakeholders, but then take an indirect approach, making sure the stakeholders drivers are considered or addressed in the content I provide.

The indirect / Hands off engagement

Sometimes we can have very senior stakeholders in our views because technically they have responsibility for things, and will be the ones to cause trouble if we fail. Sometimes, these stakeholders can be so far removed from your team and project in the organization, that although they do get value, they do not specifically care about your project… its one in many. Those stakeholders will not spend a lot of time on the project. In this case, you can still influence them. As an example, in my work I have a very senior stakeholder that I don’t engage. Instead I can make sure my direct line manager is not only fully aware of what we do, but has a small amount of content (maybe even less than a PowerPoint Slide) that will keep the leadership aware. The same approach can be used if we have many users at a lower level who do not really care about a project.

The hands on approach – direct engagement

For key stakeholders that you want to engage, and will significantly influence the outcome of a project. These are important meetings to be prepared for. Often you may only get 30 mins, so its important to plan them. I would spend no more than 5 minutes with a prepared presentation that tells them who you are, what your project is, where they fit in, and where you think they fit in. This will drive a conversation where the stakeholder talks, and the architect listens. In this conversation you are normally getting a lot of information – assessments, frustrations, ideas… A good architect can shape that conversation to get a clear understanding of drivers. With more senior stakeholders there’s a tendency for them to talk in terms of requirements, or goals. Don’t listen! You are there to understand what drives them, and to capture their assessments, (which they are normally articulating as requirements and goals). Your stakeholder is providing you a single perspective. the goals are set by understanding all the perspectives together. Its rare for me to set goals in a stakeholder view on the first meeting, because I may have to change them depending on everyone else’s point of view. This is a very powerful approach to getting people to understanding the value of architecture – when you listen, and then show later that you actually acted on what they wanted. Because of this, you may want to layer your engagement plan. If you influence the most trouble making stakeholders in this way first, they can do a lot to make the rest of the project a much smoother ride.

The online / Survey engagement

Doing something like a Microsoft Form or a poll poll is really easy – at least from a technical standpoint. Its fantastic for engaging many stakeholders, and capturing information in a uniform way. Also the reporting is pretty great! But there’s a few things to be aware of:

  • Creating proper surveys is an art! It’s not easy to create an effective survey that gives good responses. If I do a survey I normally give it to a small test group first and get to provide me feedback. Bad questions can mess with peoples perceptions of the project.
  • You need to communicate the why effectively. When a stakeholder understands why they are supposed to do something, and the value its going to give them, you improve your chances of getting responses, or if you have the authority to insist, you improve the chances of your stakeholders actually thinking about your questions.
  • You need to think about what you want & how you will use the results. This influences your questions. For example if i am creating a survey for end user stakeholders for a new education I am planning I know to use the results effectively, I might the people paying for it to understand that these end users lack the education currently, and if they want it. Knowing the answers to these questions influences my drivers and goals. As architects we want to remain impartial where we can – the results from a large audience may influence your senior stakeholders. Of course in this fake scenario there are lots of other things to consider…
  • You need to be careful with your questions. When I write a question I try to imagine how its going to be interpreted by different types of people. I want my questions to be precise. I also think at this point about how that questions different responses may influence my stakeholder view. I also want to make sure I do not ask too many questions (where possible!)

I like to make sure I feed back my results to the stakeholders. There are sometimes cases where you may not want to, but as a rule of thumb, its a good one.

Informing With The Newsletter / Article

A newsletter is a mechanism that doesn’t provide much feedback, so it doesn’t influence the creation of our stakeholder view – unless you count likes, but as we were talking about engaging stakeholders, I thought it was worth mentioning.

For large projects its sometimes good to provide a weekly, or monthly overview of what’s going on. Stakeholders like to be informed, and this can save time, and a lot of questions, and help keep people feeling like your project is managed.

Creating a good newsletter is also an art. You do not want to put in too little or to much, and as a formal communication method you want to ensure its done with enough love and attention. If you put together a bad newsletter that’s not addressing the concerns of your stakeholders, it can do as much harm as it does good.

Photo by Jean-Christophe Andru00e9 on Pexels.com

The flow of things

Its worth taking time in your planning to think about what happens when (in fact project management may insist on it).

A first point to make is your stakeholder view is likely to go through some iterations. Maybe a first draft the architect makes when the stakeholders are identified, then as they are engaged, the view will change. Then once we have sufficient feedback from stakeholders, we will want to create and finalise our goals, and then get feedback.

The order of doing things is also important. I normally start with the business owner. If that owner has made assumptions, quite often the first job it to validate those. For example, if its a project around service desk improvement, that a single frustrated person with a budget has put forward as a proposal, my next port of call may be the customers of the service desk, to see if everyone sees the problem in the same way. This will be very good import for my next meeting with finance, where I can use that data to validate the project, while also capturing their concerns. If I am smart I will be making sure my business owner knows that I just helped him with finance…

The challenges & risk

If you do not take time to validate the drivers coming from a stakeholder, or the goals, there’s a very real risk you are projecting your own perception of things, or the perception of a subset of your stakeholders. The iceberg is a fantastic example of this. If you look at the picture, its very easy to focus on what you see above the waterline, but what’s hidden below it may be significantly bigger, and could sink your project.

Engaging stakeholders, and creating validated stakeholder views takes time. I’ve seen in many cases people wanting to do this part very quickly. Stop and think about how critical understanding stakeholders is to having a successful project that provides value, and how much easier successfully engaging them will make a project overall, and how it influences the perceived value of architecture.

We all are under a lot of pressure to deliver, but taking a little time to make sure we are delivering the right value to the right people, can stop some huge mistakes. In cases where we will not do the footwork around this, we should be expressing this as a risk.

Summing this up

These are just my thoughts and feelings on this subject, and I felt the need to share this because its very easy for an architect to get caught up in creating views and missing the engagement part of this – especially when stakeholders are busy and don’t particularly want to engage. Its demotivating, and when I find that I start doing the same thing – I need to stop and draw a line in the sand.

Secondly is watching projects go awry. In the past, I’ve seen full stakeholder engagements going to quickly created surveys, then moving to “well we know what they need”, and I see, and must communicate the risk in that.

For me, stakeholder views are one of the first to create in an engagement, and the word engagement is essential. We are architects who should be designing with our stakeholders in mind. We are not there to just document what other people do. I have seen many people not understand this, and in this case, the first step to changing that perception is to get this right.