Pass PMI-ACP Certification Exam in First Attempt Guaranteed!

All PMI PMI-ACP certification exam dumps, study guide, training courses are prepared by industry experts. PMI PMI-ACP certification practice test questions and answers, exam dumps, study guide and training courses help candidates to study and pass hassle-free!

PMI-ACP Exam Domain: Stakeholder Engagement

5. Working with Stakeholders to Create the Shared Vision

Creating a shared vision It's all about understanding that what's requested is what we deliver earlier to the customer earlier. If I come to you and your development team and I ask you all to create an app for my business, I describe what the app is to be. If you and I don't have a shared vision, or if your team doesn't have a shared vision, we're very likely to end up with two different items: what I had in mind and what you actually created.

So this lecture is all about creating a shared vision of the steps that we take to ensure that the customer or the end user and you and your development team are all on the same page, that you're all singing out of the same hymnal, as we say in the South. All right, let's hop in and talk about what it means to create a shared vision. Failing fast is one way that we can create a shared vision. So what this means is that failing fast—failing early and cheaply—makes it more cost-effective to make mistakes and catch them early in the project than to make mistakes and not catch them until late in the project.

So here's what failing fast means in alignment with a shared vision: If I described an app that I want to you, And then your team goes about going to work, and they very quickly show me at the end of that first sprint what they've come up with, what the demo is, whether it's a mockup or a wireframe or what have you, and I can very quickly say, "Well, it's not quite what we're after."

It is far more cost-effective to correct the error now rather than several months later. So it's a good way to discover misunderstandings, and it ensures that the project team understands exactly what the stakeholder wants. So it's a good idea to fail fast and fail early because it saves money and time, and it's really a way to clarify what the customer expects from you and your development team. Well, if you're a PMP, you know that projects need a charter. A charter is a way to authorise the project, the project manager, and those resources.

Well, in agile project management, the agile chart works just a little differently. So agile charters are still used to authorise the project and the project manager; they're still from the project sponsor. But typically in Agile, they're going to be a little bit more high-level; they could be very detailed, but typically they're lightweight. In the Agile charter, there's a key difference, and that's the acknowledgement that change is very likely in an Agile project. As I mentioned, agile project charters are different than traditional or predictive project management charters. So traditional charters are very specific.

They lay out exactly the goals of the project, how much, when, and what the constraints are, and you go about getting to work. Well, agile project charters, though, are more broad and high-level when compared to predictive project charters. Agile charters are defined. So who will be engaged? What is this project about? Where will the project take place? When will the project begin and when will the project end? Why are we doing this project? Why is it chartered? Then discuss how the project's objectives will be met. So these are all at a very high level. Another way that we can ensure a common understanding is to create a project tweet. Alright, this is the idea where the project customers and the team take the model of Twitter and describe the goal of the project in 140 characters or less.

So it's just a way to define a high-level description to ensure understanding. And then this can also be an elevator statement, where an elevator statement is just a real quick statement to describe what your project is doing and what it is going to accomplish. Probably the most important exercise we can do with this shared vision is to ensure that we both understand what is meant by "done." We've discussed it a few times, right, that you and I must have a shared understanding of what "done" means for our project.

Well, defining "done" is really important for everyone on the project. It's an example of a shared vision user story. Done will mean developed, documented, and tested. When we talk about releases, "done" means there are no large defects or any remaining change requests, and then we have the final project deliverables or deliverables with priority features that are implemented. So maybe you have three months of trouble-free operation, or you have a review and satisfactory scores from the end user. But whatever these are upfront, we have to define and come to an agreement on what "done" means. As a result, the team is working toward a common understanding of what has been accomplished.

That is the same for the customer, the product owner, the end user, the project manager, and even the project sponsor. We're all on the same page; we all understand what it means to work with Agile modeling. Now, the modelling techniques we're going to look at in the next few slides are great for agile projects. The real value here is the discussion. It facilitates not so much the model as the process of creating these models. Most of the time, you can just draw these on a whiteboard, and then you take a picture of it, get off your cell phone, and take a picture of it, and then you have a record of what you've created.

These models are now lightweight and barely adequate, which means they're fast, quick, and will adapt and change throughout the project. So Agile Modeling, which we're going to look at in the next few slides, is really a way to help individuals build consensus and synergy on what "done" means and what the goal of the project is. The first one is just a use case diagram. How will the user use the solution? So in this example, we have a customer, and this customer is going to place the order over the phone. And so that goes into the queue for placing the order. And then, based on what they order, we have to go and look in the catalog, or they might go and look at what they've ordered in the past.

Notice there's also an Internet customer. So they have an Internet order, and it also goes in the queue and then follows the same flow. So a use case diagram, real quick, real simple, just describes how the user will interact with the system.

How do they go through the system? Now, a sample data model. This is a pretty complex one we're looking at here, but it just shows how data flows through the system. You can imagine that if we were to order something from Amazon or Netflix, or whatever, all of this information would be associated with our account. Then how does that data flow through the system?

So we might have you wanting to order a pair of shoes. What are some shoes you've ordered in the past? Is it capable of remembering the same size? Is it a running shoe or a dress shoe? So there are all these different variables. Is this for a personal account or a business account? How is it being paid? Is it a credit card, PayPal, or whatever the case may be? So it just shows how data flows through the whole system. How does it flow, but also how is it pulled into the system based on what the user does?

Screen design is another great way to kind of mock up a solution. So what does the user interface look like? So, obviously, you could draw this on a whiteboard and map out the various fields and stuff. But this is an obvious example of a screen capture that's showing all the things you could do in the user interface. This is a very complex interface.

Look at all the different fields and things. You can click on different tabs, so it's a little bit more complex. But a screen design helps the end user and the developers develop consensus about what to create. Now I've mentioned wireframes a few times. I think it's one of the best tools to build consensus and create a shared vision. Because it's a quick mockup of a product, it doesn't take a whole lot of time.

So screens and data flows make sure that everyone has the same understanding of the product. It's a form of low-fidelity prototyping; low-fidelity prototyping is quick, fast, and easy to do, and it's a quick way to get feedback. So for your exam, you might pay attention to wireframes. really easy to do. Another term you should pay attention to for your exam is called a user persona.

A user persona is a biographical sketch of key stakeholders. So, I don't know, it's kind of fluffy, but it's a way of describing who's going to be using the thing you're recreating or who's going to be involved in the process. So it's a description of the product's users, somewhat grounded in reality. It's not all fiction. It's goal-oriented.

Now, let's take a look at your new software. Let's say it's a new version of Adobe Photoshop. And then you think, okay, we have photographers, we have editors, we have graphic artists, and sometimes the salespeople need to get in there and do whatever. So we have all these different roles. Well, a persona then would say, "Okay, as a photographer, this is Bob, the photographer, and how he uses Photoshop." And then this is Sam, and she's a graphic designer.

And this is how she uses Photoshop. All right. And then here's Jane, and she is an account rep. And this is so on and so forth. So you just take these roles and responsibilities that are based on reality and write a story about what your solution should provide as a result. So it's goal-oriented, and then it shows tangible, actionable outcomes. So focus on the users and what the users are going to do. Who are these people? So a user persona So for your exam, pay attention to user personas. You're probably going to see that on a test. User personas. It's a biographical sketch, somewhat fictionalized, but it's based on real stakeholders.

6. Managing Project Communications

It's been said that 90% of project management is communication. Now, whether that's true or not, I think it's a pretty accurate statistic when we consider all of the different people that you have to communicate with. Your team, your vendors, your manager, the customers, the end users—all the different stakeholders Well, in this lecture, we're going to talk about the importance of communication in agile projects. Let's first talk about planning communication management. So we need some type of communications requirements analysis. So what does that mean? It's a way to examine who needs what information, when the information is needed, what modality of information is expected, who's responsible for communicating the information, and then who has access to the information once it's been communicated.

So it's really a study of all the different stakeholders and what they need, when they need it, and how they expect it expected. We also have to consider communication technology. Email, text messages, instant messages, and chat are all possibilities. How will you communicate with one another and with your stakeholders? We will look at a communication model. How do two people or multiple people communicate? What are the communication methods that are acceptable and most effective? We're going to look at that coming up.

We'll also talk about meetings and facilitating them to be effective. We don't want meetings that are a waste of time. We want effective meetings that have a goal. They're time-boxed, and we get in, accomplish the goal, and get out. Create the communications management plan. That's something that's kind of a tie-in to the Pinbuck fifth edition in chapter ten. It can be pretty lightweight. Basically, who needs what information and when they need it And then you may need to update the project documents. Let's talk about managing communication. Well, communication technology What technologies are permitted or recommended for communicating communication models? So how does information go from one person to another in your project? We're going to look at the communication methods.

So what are the different methods? Whether it's face-to-face communication or snail mail, where you put something in an envelope and mail it. So what are the different methods of communication and the pros and cons of information management systems? You need some way of organising and archiving information that's been developed for performance reporting. So, we discussed Earnvalue management briefly earlier, but you may also have some reports in your information radiator where you communicate on timeliness, lead time cycle time velocity, and how long things will take. You might also have your burn up or burn down charts for risk, for tasks that you're working on, and for the achievement of goals towards the project scope. How will you communicate with stakeholders? How will you protect the team from disruptions, too much communication, or ad hoc conversations?

And then you also update the project management plan with any type of organisational process asset that is relevant. All right, for your exam, you can tell a lot of this is from the Pinbuck Guide, Fifth Edition. So I think some of this is a little too heavy on the PMI side. I'm not criticising PMI; I just don't think it's realistic for most Agile projects. On your exam, though, know this information because you might be tested on it in the real world. Maybe you won't have a communications management plan. Or maybe it's just one document or a table of who communicates with whom. Before your test, you should be familiar with what I'm sharing with you here. Alright, let's get back on track. It's important to control communications with any type of project, and we can do this through information management systems, expert judgment, meetings, work, and performance information.

This is just a way of saying, all right, based on what we've done, how well is the project performing or what activities are in the queue or what activities are next up in the priority change request? We're going to have lots of change requests in Agile. That's expected as long as it's entered into the backlog and reprioritized accordingly. Then we can incorporate those into iterations. And then, as I mentioned, you update the project management plan, project documents, and organisational process assets according to what's relevant to the project. All right, here's the communication model: a sender-receiver model. So if I want to send you something, I'm the sender, and you are the receiver. Let's pretend I'm going to send you a fax, okay? So I'm going to send you a fax. I'm the sender. The fax machine on my end is the encoder. So I push that in, it scans it in, it takes that image, it makes it analog, and then it goes over the phone line. Well, the phone line is the medium. Now on your end, we're going to skip over that noise for a minute.

On your end, we have your fax. And your fax is the decoder. It listens to the analogue sound, puts it back into usable format, and prints out a replica of the facsimile of what I sent. So you are the receiver. Now the noise, which could be static or any type of distraction in the message that could distort the message, is noise. A barrier is anything that prevents communication from happening. like your fax machine is out of paper, unplugged, or you no longer have a fax machine. So these are all things that could be a barrier.

Now, I know fax machines are kind of data, but it's a great example. We could do the same thing with an email if you and I were having a face-to-face conversation. This is the communication model between a sender and a receiver. Now, of all our communication methods, face-to-face is preferred. It's the best type of communication. It has the highest bandwidth of all communication types, meaning that it's effective, gives immediate feedback, and allows both parties to ask for clarification. It is easiest to achieve a shared vision or shared understanding of one another's messages. So face-to-face on your exam—even in the real world—is a good thing that you want in your projects.

So what's the effectiveness of different communication channels? So if we look at the left on our Y axis, there we have communication effectiveness. So as we move from cold to hot, hot is where we want to be mentioned: two people at a white board working on a problem. They can turn and look at one another; they can speak to each other. It's low-tech and high-touch. So that's a very effective way to communicate. It's effective with two people on the phone now, but not as effective as face-to-face communication. There's more room on the whiteboard. It's still pretty easy for people talking on the phone to have a good conversation. Then a video tape So, no question and answer videotape. I mean, it's all static. It's asynchronous, where it's just one way.

An audio tape is even worse, like a voicemail, and then two people communicating via email or mailing back and forth on paper is cold; it's not effective. So, on your exam, if you're asked to choose an effective method of communication, I'll put two people speaking to each other, preferably face-to-face. If we're putting letters in an envelope or dealing with memos sent around the office, that's cold and not very reliable.

I should say unreliable rather than ineffective. We have two-way communication and a top-down dispatching model. So that comes from the CEO going to send out a message about what our summer hours are. It's top-down. A collaborative model is more interactive, so the sender and receiver can talk with each other. It's usually a little bit more casual or direct, where we can look at each other. Knowledge sharing is critical on agile projects. We've talked about this early in the course—that we don't want these silos of information, that we want a shared collaboration and shared ownership and synergy.

That's knowledge sharing. As a result, its information is openly shared and collectively owned, which means that anyone at any time can edit any code. So, Agile, we've already discussed the idea of spreading knowledge. Remember, they can be on boards, information, radiators, personas, and wireframes. But these are all pretty important ways to have knowledge sharing, communication, and agile projects are pretty important.

As you already know, we want low-tech, high-touch tools. like a whiteboard, like a sticky note. There you go. Stand up Meetings are alright; that's a pretty easy way to communicate. It's time-bound to 15 minutes. What did you do yesterday? What are you going to do today? Are there any impediments in your way? It's called the stand-up meeting because we stand up during the meeting. Osmotic communications. Osmotic communication and tacit knowledge These are two really important things for your exam. Let's first talk about osmotic communication.

Osmotic communication is when you're working in an open environment and you can hear other conversations and pick up on that information. And so when you need it, you can recall it. It's like learning by osmosis. So you're absorbing things that are happening around you. Now, tacit knowledge is information that's understood without having to be explained directly to you. You just kind of understand it, like how to turn the lights on in the morning, or if the printer gets jammed, how do you open the thing, rip out the piece of paper, and reprint? So they're similar, but Osmodic is more indirect.

You hear it around you, and so someone says, "Oh, you're not getting an error message when we do our integration," and someone says, "We have to close your file and then save it and then integrate." Okay, well, I'm getting ready to integrate soon, so I know what I need to do. Where Tacit is, you've seen it enough times on how people turn on the lights in the morning or fix the printer that you can do it without assuming or implying that you understand information radiators. We've talked a little bit about "information radiators," highly visible displays of information, typically large graphs or charts.

They are also known as "visual controls" because they summarise project data in plain sight and are easily accessible. So, again, this can be just on a whiteboard or a printout like we have here. Maybe you update it once a week or whatnot, but it's just a way of taking key information you want to communicate and making it widely available so everyone can touch it and access it. So what do you put on an information radiator? Well, every project is different, but these are some common items that you might put on your information radiator.

Features delivered versus features remaining So who is working on what? So it's a racy matrix of roles and responsibilities. So who's working on the features of the current iteration that you're creating? So what has been brought up as a priority that you're working on now? What are your velocity and defect measurements? What were the outcomes of your retrospective? Remember, the retrospective is for the project team, where you consider the outcome of your Sprint review and then look back on what worked and didn't work last time, and how can you improve upon it? Are there any threats or issues with the project? So how do you address those? Do you have burn-up and burn-down charts?

Remember, a burn-up chart is where we have the scope across the top. A line across the top represents our scope. And if there are increases or fluctuations in scope, that line moves up and down. Then, as tasks, features, or user stories are completed, we begin to move up against the total number of user stories or features to equate to the scope of what a burn up burn down is. We have, I don't know, 800 features to create, and as we create them, a bar chart goes down and down and down to zero when we're done. So you might have burn up and burn down charts, and then you might also have a story map where you map out your stories by the different areas of what you're creating.

Now that social media is another way that we can communicate, it's becoming more and more popular, so it lets remote workers stay in touch. So, of course, Facebook or Twitter are not always the best way to stay in touch. At a lot of companies, you can't go on Facebook during the daytime while doing your work, or maybe that's considered a threat with your project information. So maybe you use some web collaboration tools like Linkor, some type of LinkedIn group, or another piece of software that is separate from social media that's just unique, that you own, and that's on your server. Ideally, this is for a non-located team; it's just a way of staying in touch with one another and what's going on. Of course, with all of this, we have to consider the sensitivity of the project information. Is this really wise to use?

7. Reviewing Collaborative Approaches in Agiles

Collaboration is so important in Agile project management. We've already seen this about customer collaboration over contracts. We also need collaboration with our team members, our stakeholders, and our product owner so that we all work on this together and work towards success together. That's key for your PMI ACP exam: you need collaboration to be successful in Agile projects.

So collaboration is key in Agile projects. As I mentioned, I prefer customer collaboration over contract negotiations. Businesspeople and developers work together daily throughout the project. That's a key example right there of how business people and developers work together. So why do we collaborate? Well, I think we know why we collaborate. It promotes wiser decisions, problem solving, and action.

Who's going to do what? Who builds social capital, and what does that mean? It is the goodwill, favor, and relationship-building among those involved in the projects. And it's ownership of a collective problem in that when there's an issue, problem, or risk, it's not isolated to just the development team or just the test team; we all own it, we all work on it, we celebrate our successes, and we all learn from our failures as a whole. It is crucial to engage people, to reach out and invite them to collaborate.

Engagement creates better ideas and brings some thought to our conversations. It's so easy in traditional project management to define your stakeholders, have a kickoff, and then ignore everyone except your project team. In Agile, we don't do that. We reach out and actively problem-solve. So it's critical to keep people involved, to reach out and engage them, to give them a sense of ownership and synergy, and to make them feel like they're a part of something big and successful. We take action rather than being passive. We don't wait for people to come to us to be involved.

We go to the people and invite them to participate and contribute. We have a collective ownership of ideas, so it's not just my idea, and it's not command and control my way or no way. It's a collection. It's a collection of ideas owned by different people. We motivate and engage the project team by keeping them involved and listening to what they have to say. They are driving the project; the customer is driving the project; the product owner is driving the product; and all of us are driving the product, so we are all involved and working toward the same goal.

Now, this approach also shifts the power downward, so that it's not the project manager, it's not the project sponsor, it's the project team and the key stakeholders—they own the solution, not the project manager. So, a little tip for you on your exam: don't put the project manager in the centre of decisions. Move it to the team. The PM takes on a servant leadership role. Our next point here is to talk about the green zone versus the red zone. So the green zone is where we want to be as an Agile project manager: we take responsibility, we respond to issues and threats in bad situations non-defensively, and we're not easily threatened. We want to build a mutually successful relationship. We're looking for solutions, and we're going to persuade as needed. We're firm, but we're not rigid. We think both short-term and long-term. We do consider other people's points of view. It's not command and control. We welcome and want feedback.

We consider conflict to be natural. We speak calmly and directly about difficult issues. We accept responsibility, and we seek excellence. So these are all attributes of being in the green zone. These are our goals for our team, for the product owner, for our customers, and most importantly, these are our goals for us as the project manager. Now, what does it mean to be in the red zone? Well, as you might guess, the red zone is the opposite. It's not where we want to be hanging out. So we do not want to be in the red zone. Characteristics of the red zone You are blaming others, acting defensively, feeling threatened or wrong, triggering defensiveness, holding grudges, shame, blame, and accusations. Binary thinking, binary thinking Zero one, correct or incorrect. So binary thinking is definitely a characteristic of the red zone.

We look for short-term gain and may feel victimized. It's an individual who doesn't seek feedback. They must win at any cost. They're rigid and reactive. There's a climate of antagonism, disapproval, and some consentment—I say contentment here—where disapproval and being condescending and contention see others as the enemy. It's an individual who does not listen effectively. So we don't want to be hanging out in the red zone. You might know these, and you might know the green zone. You're probably going to see something about that on a certain exam coming up. Workshops are something that we do on occasion in Agile projects. This is a meeting for participants to get work done. That's why we have a workshop. According to the schedule, there are clear goals and frequent retrospectives. a team, they look back.

The retrospective could be a workshop. Planning meetings could be workshops, as could estimating sessions. But a workshop is usually a time box where we're going to go for 4 hours, 8 hours, or even a couple of days depending on the size of the project. and this is the goal of the workshop. This is what we're going to get done. We're going to work on nothing else but this goal in the workshop. If you want to host a workshop, it's a good idea to have a diverse group of people. needs to be facilitated for involvement.

So if you're the facilitator, you make certain that everyone is contributing and that we know there are people in the team who are going to talk over other people or who seem to know more than anyone else. Well, as a facilitator, you need to make sure that everyone has a chance to contribute. and to share their ideas and thoughts.

One way to do that is to get people involved early, get everyone involved, whether through icebreakers or a quick round-the-room introduction, and make people feel welcome, valued, and that their opinion is needed in this workshop. For candidate user stories, a user story workshop, also known as a story writing workshop, is now the preferred method.

So this is where you document the user stories that will be added to the backlog. As a result, the product owner, key stakeholders, and the project team are all involved. It optimises the workflow and helps you understand the user's needs. We engage stakeholders in the design process, so this keeps them involved. It's not as if we're saying, "Tell us what you want, and then we'll go hide that you're involved in this," but rather that we're understanding and that you're assisting us.

You're leading by participating in this user story workshop. Now, brainstorming—we've all heard about brainstorming. It's a collaborative technique to rapidly generate a whole bunch of ideas. We want to maximise suggestions. We tell people that there is no such thing as a stupid idea because any thought that someone has may spark another thought in someone else.

So throw out any idea when we do brainstorming, and then we sort through the ideas later. So the initial thing is just to get as many ideas out there as possible. We're not judging, we're not sorting, we're not throwing anything away; just get it out there, no matter what it is.

Now, there are three types of brainstorming you should know for your exam. We have quiet writing sessions where the team will take five or ten minutes or even 15 minutes to write down all of their ideas.

Then we come back together and share ideas. So if I'm facilitating this meeting, let's say you and six other people go, and they take ten minutes to write down as many ideas as they have. We come back together, and you begin reading your ideas. If your idea is on somebody else's list, they scratch it off their list because you both had the same idea. So it's a way of kind of assimilating all these different ideas into one big list.

Now, round robin is where we go around the room, so each person comes up and says an idea, and we go to the next person and so on. This ensures that everybody has a chance to participate, and an individual could say they're passing if they don't have an idea. That's fine. A freeforall is just what it sounds like. Anyone can yell anything at any time, so there's no rhyme or reason, no order, but you just throw out as many ideas as you want and have people write them down on the whiteboard to keep track. Now, collaboration games are a way to identify requirements and user stories.

And so these are games or little exercises to help you come up with ideas and requirements. features user stories, also known as innovation games. So we have a couple we're going to look at. Remember the future, prune the product tree, buy a speedboat, buy a feature, and then bang for the buck. We're going to look at these right now.

The first one is to remember the future. This is a collaboration game where everyone in your meeting, your workshop, looks at the project, and then they take 20 minutes to write a future report about how the project went. So you write a report about how the project was completed, how you got here, and what you created. And so it includes what was created, and then you typically write those on sticky notes.

At the end of these 20 minutes, you take all those sticky notes and begin to create an affinity diagram, even though that's not on this slide. We're not sure what it's called technically, but it's an affinity diagram in which you take items and place them in min clusters to eliminate duplicates.

So this game helps you define success. Now, pruning the product tree means you have a big picture of a tree on your whiteboard. You draw a big tree, and then the trunk is what you already know or what's already been built. The branches are the new functionality and what needs to be designed. Participants in this activity take sticky notes, write features on them, and stick them to the tree. So the closer they are to the trunk, the higher they are in priority, and the farther away they are from the trunk. It might be nice to have, but perhaps not right now. So they're lower priorities. So that's pruning the product tree. Now, in the speedboat game, sometimes it's called a sailboat. But imagine that your project is your goal. Here is a speedboat. So what winds are pushing the sailboat? What is working in your favor? What anchors are holding the sailboat back? So what are the impediments to success that you need to get rid of? What direction is the sailboat going? So is there anything that we need to make some corrections on to move us towards the goal? Are there any rocks in the way?

So, what are the risks or threats that stand in the way? So this is a way to just begin to identify what's working and not working in your project. I'm going to hop back just for a second to our original list because I skipped over these two. Buy a feature and get bang for your buck. "Buy a Feature" is kind of like what we talked about earlier with Monopoly money. Same with bang for the buck.

We have so much money to spend on features, so we put money towards buying those different features to help prioritise them. Same with bang for the buck. We only have so much money to spend, so you spend it on the top priorities. So it's just another collaboration game. For your exam, I'd recommend you, you know, remember the future croon of the product tree and this sailing or speedboat game about what's in your way or what's not in your way. All right. Good job.

PMI-ACP certification practice test questions and answers, training course, study guide are uploaded in ETE files format by real users. Study and pass PMI PMI-ACP certification exam dumps & practice test questions and answers are the best available resource to help students pass at the first attempt.