Speaker 1: Hi everyone, welcome back to these processes from the Project Management Body of Knowledge. Today we're looking at identifying the stakeholders in our project. And as you can see in the process group and knowledge area mapping, it's one of the very first things that we'll do as part of our project and it's actually an ongoing activity as well. So we'll be doing it throughout our project as things change, as people come on board or people leave and things move, which is typical of a project. It's a temporary endeavor and things will change a lot as we're going along. So we're identifying those stakeholders very, very first once we've kicked off our project with the project charter. So with identifying stakeholders, this process frequently occurs for the first time in a project either prior to or at the same time as our project charter is developed and approved. So we're initiating our project, we need to know who's going to be involved and then we get a more detailed look when we're really delving into identifying our stakeholders. And it's repeated as necessary, but it should definitely be performed at the start of each phase or each milestone and when a significant change in the project or the organization does occur. So if something big happens, then we'll need to reassess who's on our project. Each time the identification process is repeated, the project management plan components and project document updates should be updated to identify all of those relevant stakeholders. Let's look at the inputs, tools and techniques and outputs for identifying our stakeholders. Of course, the project charter might have a high level view of our stakeholders. Business documents, project management plan, of course, project documents, agreements and EEFs and OPAs will come into it as part of an input when we're identifying our stakeholders. Tools and techniques that we'll use are our favorite expert judgment and data gathering makes a lot of an appearance as well. Data analysis, so stakeholder analysis. How are they tracking? Are they with us or are they against us? Are they neutral? Are they resistant or are they supportive? Data representation. So maybe we can put that into a nice visual stakeholder mapping or representation and meetings with stakeholders to tie everything together as usual. Outputs that we will see are our stakeholder register, a nice neat table of all of our stakeholders so we know who's involved. Change requests if necessary, project management plan updates and project documents updates too. And as you can see, a lot of things have an input into identifying our stakeholders. The charter, the project documents, any business case or benefits management plan, all of those stakeholders. And the stakeholders themselves are an input back into our project management plan and project documents and even procurements as we've seen because we might have stakeholders involved with our third party who's doing a piece of work for us or the whole amount of work for us if we're buying that from them. Let's look at the inputs in more detail. We've got the project charter. So the project charter usually identifies a key stakeholder list at the very, very beginning and it may change and it may be updated but it's a high level piece of information about the responsibilities of the stakeholders initially. Business documents as well for the same reason. The business case, that cost to benefit ratio that we've seen. The feasibility study, you know, is the project feasible and who's involved. The benefits management plan, who is getting the benefit of this project. So we need to put them as a stakeholder too. Communications management plan and stakeholder management plan within our project management plan. These things will be an input. So who are we communicating to and who are the stakeholders that we've identified. This will be an input as we're continually updating it along the schedule of our project. Project documents will see any change logs, issue logs that are raised by stakeholders. Maybe we need to add them now. And requirements documentation, same with our communication or stakeholder communication information there. Agreements that we've made, so the parties of an agreement are project stakeholders. An agreement can contain reference to additional stakeholders as well. So maybe any agreements that have been made with a department to get resources from their department, people working in your project, for example, away from their normal jobs, then that's an agreement that's made and we need to add stakeholders for that reason. Enterprise environmental factors might be organisational culture or the political climate or any governance frameworks that are existing that we need to abide by in an organisation. And of course geographic distribution of people. How do we communicate with them? We need to place that information in our stakeholder register. Organisational process assets might be existing templates, existing stakeholder template registers, that sort of thing, lessons learned as usual, and stakeholder registers from previous projects. Maybe we can utilise some expertise from a previous project. Tools and techniques that we'll see are expert judgment. So experts may be required and we need to gather that information for people who have knowledge of an industry, knowledge of the deliverable that we're working on, knowledge of the particular team member contributions and expertise, maybe their leader or manager. And understanding the politics and power of an organisation as well could be very, very handy. Meetings will help us tie everything together and they can take the form of facilitation workshops, getting everyone in a room, saying here's what we need, here's the problem we need to solve, how do we solve it, what deliverables do we need to make. Small group guided discussion, working group meetings for catch-ups every week or even daily stand-ups, virtual groups using social media technology to share ideas or analyse data or even solve problems. And because of that we'll need to be doing data gathering of course, questions or surveys, brainstorming with our stakeholders. Data analysis, so stakeholder analysis where we're looking at the interest of the stakeholders and the impact they might have as well, the ownership of particular areas and document analysis for the scope, who owns that piece of scope, what's the requirements that's going in, who's getting the benefit of those requirements. Data representation that we'll use in tools and techniques are things like our power interest grid. So this is where we're looking at power and my actual favourite is the impact and influence. So what is the impact of our project on them, is it high or is it low and what is their influence? And we'll see this in the key concepts as well but if they have a high influence and it's a high impact to their department then they're going to have a pretty loud voice on our project and we need to keep them on board. The stakeholder cube just adds a third dimension to that so maybe we look at something else like their position for example or their power again. Salience model is a good example of a stakeholder cube which is a three dimensional, so three items instead of just two there. Directions of influence, so for our project are we influencing horizontally with our peers down into our project management team or upwards to executives or project sponsors and prioritisation of our stakeholders as well. Stakeholder register itself is a nice little table of our stakeholders. We need identification information, assessment and the stakeholder classification. For example do they have a high power and influence or a low power and influence that we've looked at from our stakeholder assessment. Change requests we'll see as an output for identifying stakeholders if anything needs to change. New stakeholders, new information about stakeholders and all this may result in a change to the baseline documents. Maybe someone else comes on board and they say look this scope needs to change, it's not what we really wanted and the project is now moving in a different direction. That can happen so just be aware that you may need a change request and of course that will impact your project management plan, so the requirements management plan, communications management plan if we're communicating to different people, the risks that might be involved and of course the stakeholder engagement plan itself. Project documents updates of course then will be things like any issues that are raised, assumptions that we've made and risks that we find along the way and those are all the details that we'll find in identifying the stakeholders initially and ongoing as part of our project for the project management body of knowledge.