Brett Harned:       Hey, welcome back. Before we jump in, I just need to tell you one thing, this class is going to take you more than 20 minutes to watch and you're going to want to download the five PDFs that will provide guidance on how to set and manage project expectations. See what I just did there? I set an expectation for what you'll get out of this class and a general sense for how much time it will take you. But to be honest, this class could take you 40 minutes. I can't say because my friends Jason and Jamin need to edit the class. Anyway, we're getting to the meat of what makes being a project leader so difficult. The previous class set the stage for the rest of the classes because when you've got a solid estimate, requirements and a plan, your well on your way to fending off any problems that might come your way. And so first step is setting and managing expectations. Let's do this.

Before I really jump in, I just want to say that it's really hard to set expectations when the ship has already sailed. So do your best to define expectations with your team and stakeholders early and then use checkpoints throughout the project to check in on them and manage them. You have to be very mindful of this or it might not work. So a lot of what I'll talk about in this class is about how the work you can do will set expectations and then help you manage them. But if the ship has already sailed and you need advice, reach out or post in the comments and get the help and advice you need from me or the smart folks who are taking this course. You have to remember, you can solve any issue as long as you pause, think through what's causing the issue and present some options to correct it. So let's carry on.

Let's start at the ground level, which is really about providing structure for how your projects operate. I mean, you can't really set expectations as a project leader if you don't have some basis for how you operate or how your organization operates. So think about operational norms and what I mean by that is, what are the things that must be done in your organization to not only manage a project, but to get one set up and running successfully? Think about these things. How do projects get initiated? What types of services can your team provide? How do you work together? Are there any processes or guidelines to consider? What tools need to be set up or used for the project? And does everyone have access? Essentially what is expected of the project experience, not only from your organization and leadership, but also from your team.

You might be sitting there scratching your head or even saying what? There are none, and honestly, I wouldn't be surprised. Not all organizations take a hyper organized approach to how projects run, but here's the thing, that doesn't mean you can't start to formalize them for your projects and teams. In fact, if you do, you'll likely be lauded for thinking through the things that will make your projects run smoothly. So give it a short. Check out the prepping your orgs for successful projects download and use the guidance provided to set clear expectations before a project is even assigned. I have just a few more notes on norms before you check out the downloads. Within established teams or even departments, there tend to be many things that are already pre-determined about the way we work and people just do them. So you naturally just assume that everyone follows those norms, but they might not.

So it's always a good idea to be able to point to some form of guidelines or documentation about how you'll be running the project. Just remember that making assumptions about who knows what early on in a project can be dangerous and it can lead to missed expectations. So these are the things that you want alignment on. It may feel like a long list, but honestly, if you can ensure that your team has a basic understanding of these things and how they're handled on your projects, you'll be setting a very clear expectation for how you'll operate as a team. And that doesn't mean that you have to pull together a detailed document for every project that states how you handle things on every project. People wouldn't like that or they'd ignore the document. This is where you can use your natural leadership skills to slyly get info across in an easy to understand open way. I'll talk in a bit about the internal team kickoff. That's a great time to reference these things and set expectations or even clarify how things will be done.

But before we get to that, I have some more general advice. This is really important for project leadership in general, but it really, really matters when you're setting expectations and it's that words matter. You've got to not only be very careful about how you state things, but you have to be sure that your message is actually landing well because if people don't follow, you're going to experience some kind of misunderstanding that will lead to chaos. So be careful about how you speak and ensure that you're being heard. But how do you do that? After all, you never actually know if someone's truly listening to you or even understanding you. I've got a few tricks up my sleeve that I'll share with you here. Sometimes it's just a matter of taking a step back and restating things in a way that everyone will understand. I know that I'm really guilty of this quite often. I'll speak quickly or refer to terms, people or projects that my team don't know much about or just move on and that's not fair.

I've learned my lesson here and I try to use some of these clarifying statements to ensure that everyone's on the same page and it's pretty simple. Part of it is knowing your audience, but when you're talking about something that seems complicated or new, you have to clarify it and when you hit an important point, pause and ask a question that will ensure people are actually listening. And do it in a way that doesn't make them feel like they're being talked down to, because you'll lose trust quickly if you do that. You have to be kind and helpful and make your team feel like they're doing this in a way that they're being supported, because that's what you really want to do and not like, my favorite here is am I making sense? Because it's self effacing and shows vulnerability in a way you don't actually know everything and that you really just want an alignment.

I've also learned that clarifying words and understanding vocabulary, it's very important to setting and managing expectations. You might hear one thing, but the person on the other end hears something completely different or interprets it differently than you. It happens because we're humans, we think and process information differently. So think about your project vocabulary. Are there terms your stakeholders might not know? Are there stakeholder terms that your team might confuse? This has happened to me so many times. You start a project and the stakeholders speak in acronyms and you have to stop them to clarify. Obviously you should avoid speaking in acronyms at first, but as you start to get clarification on terms, start a little project dictionary. This will help everyone to stay on the same page and hopefully avoid awkward breaks and conversation or even miscommunications.

It all comes down to the fact that if you're clear and concise as a communicator and you think about what others may or may not know, you'll create an environment where you're open and constantly learning from one another and that's really awesome. I really do think that education within a project setting creates a win-win situation. If you teach a stakeholder something, there then aren't to tell their team about it and look pretty smart and in return they know that you helped them and that helped them to make them look good. That's all to say, getting everyone on the same page early is a big win for you because it narrows the chances for missed expectations and I want you to win, so try it.

Okay. Next I want to talk about project scopes and how they can set the proper boundaries to help you set and manage expectations. I know that not everyone works in the same type of organization, so scope documents might not be a common practice for you. So in that case, what exactly is a scope? Well, it's a document that spells out specific project goals, deliverables, features, functions, tasks, deadlines, and ultimately costs. In other words, it's what needs to be achieved and the work that must be done to deliver the project. Scopes can save you from headaches when you're working on projects because they define all of the critical aspects and allow you to more easily say no when new requests come up. That's called scope creep and we'll cover that in class number seven. When you have a scope, it gets everyone, your team and stakeholders alike, aligned around the important details that can make or break projects.

First is the business case, which explains why the project is required and what benefits are expected to be delivered. Essentially, these are your goals. Then there's the project description, which is an overview of the project's final deliverable. That's a major expectation. In other words, what are you actually making here? The success criteria are the key components that will help you and your stakeholders to determine what will make the project a success. If you don't know this, you might have a hard time determining if the work hits the mark or if it was worth it at all. Then you have to think about limitations which could call out any resources, technology, time constraints or related issues that may limit the project while you're working on it. Getting this in writing can be critical to truly defining what can and cannot be done on a project, so be sure to think through this.

Lastly, you want to think through and discuss any assumptions that have been made and will affect the final outcome. An example of this might be that when scoping or estimating, you assumed that you'll have access to a full time team for the duration of a project. That's a pretty hefty assumption that will impact your budget, timeline and ability to deliver. If that assumption is incorrect, you'd have to reset expectations for how the project will work. So you may be wondering how that translates to an actual scope document. This will vary depending on the organization team or even the project, but typically you'll see these things outlined, project goals, which are the intended outcomes of your project. Deliverables, which are obviously the things you'll deliver to get buy in along the way. Features, which is basically what needs to be included. Functions, which is how those things should work. Tasks, which are the things that need to be done in order to create the deliverables. Deadlines, which is obviously when it needs to be done and then costs, which would be the money involved.

Of course, if you're on an internal team, this might not be included on your scopes, so check out the sample scope document and sample project brief in the course downloads and feel free to adapt them to your own use on your projects. But keep in mind these can be done in many different ways. The most important thing about them is that they set the right expectation for what will be delivered, how, when and at what cost. Effective scope management can help to avoid issues like changing requirements, missed expectations, increase in time and costs, and much more just by clearly defining and communicating the scope to all parties involved in the project. Without a sense for scope, you'll have no clue what time, costs or labor was involved in a project. That said, a solid scope forms the basis for many decisions you'll make on a project. In a way the scope sets the expectation for what you will and will not accept on your projects.

But like a plan, you can't just set it and forget it. You need to manage your scope in order to keep the expectations it sets in check, so think about doing these things, document goals, vision and requirements in a clear and transparent way and make sure others are reviewing them as well. Review ideas with your team before execution to ensure that you're not under or over delivering on your scope. Make your team aware of budgets, so they understand the level of effort implied by your scope. Discuss scope at presentations and reinforce it when feedback comes in and feels like it's crossing a line. Really, you just need to remember that your scope is your source of truth for what's supposed to be happening on your project. Use it to help set and manage expectations and when someone tries to deviate from the expectation, pull the scope and have a very black and white conversation about it.

Now I don't want to come off as too rigid here. Clearly I think scopes can help you to avoid difficult conversations, but sometimes you'll bend because it feels right or it'll help preserve a client or a stakeholder relationship, and that's okay to, just do what feels right and know that you can lean on the scope when you need to. Now let's move on and talk about the things you've already nailed in classes four and five, and those topics happened to be project requirements and project plans. I'm not going to harp on those because you can get all of the info you need on them in those classes, but I do want to make sure you understand is that well documented requirements and well thought out project plans will help you to reinforce and maintain the expectations you set early in a project. But they'll also help you to track the changes in details that come up along the way. That means you should use your requirements and plan as your guide to help you look through issues and keep those expectations in check.

Think about it, all of the work you put into documenting the details of requirements and creating a strategic and realistic plan can actually help you to do more than just checking on tasks. Okay, moving on. I want to talk about roles and expectations. Think about a band or an orchestra, you'll often see rows of people playing the same instrument on the same song. That means every musician has a part, but how do they know which part is there's? Can you tell I'm not a musician? Well, obviously they sat down before even playing the song to determine who would play what, if they didn't, it would have been a mess. Kind of like when I lip synced to the trumpet in my fourth grade choir because I just couldn't keep up. But I digress. If an orchestra can sit down and define parts, why don't we always do that on project work? When you're determining the overall process and plan for your project, you have to keep in mind that each person will need to know exactly what they're there to do.

That's right, it's another expectation to be set, and you can do this in a couple of very simple, quick ways. One of them being the RACI chart. The RACI chart is especially useful in clarifying roles and responsibilities in cross functional or departmental projects and processes. RACI is an acronym derived from the four key responsibilities most typically used, responsible, accountable, consulted and informed. Okay, so this is the format for the tool. This is a more visual example, but you could very easily do this in a spreadsheet. In fact check out the RACI template in the class downloads. Essentially list your team members and maybe even your stakeholders along the top as columns, and tasks and milestones on the left as rows. As a group, sit down and rank everyone's role on the task level using the RACI setup. R stands for responsible and it's designated to the people who are responsible for completing the work. A stands for accountable. This is typically the person who signs off on the work or maybe the person who's going to feel the heat if something goes wrong with the task. C is for consulted and it's for the people who aren't doing the work but are in the know and sometimes review or contribute to the work. And finally I stands for informed and that's for people on the project who just need to know that the work is happening. Using a tool like a RACI sets a very firm expectation for who will be responsible for what work. I love it because it removes any confusion about who's doing what and when. That means that the team member who likes to hide from the team can't really do that anymore, because everyone will hold that person accountable to their tasks or even their level of engagement on the task they're not assigned to. If you're like me and you want to cross every T and dot every I, you'll take the RACI a step further and use TeamGantt to set expectations about work assignments. Let's check that out now.

Brett Harned:       Okay, so I'm going to show you really quickly how you can use the RACI Matrix along with your project plan to set some major expectations about who is doing what. First it comes down to the idea that you can assign people. So obviously here I've got myself assigned, I've got Jamin assigned, and I've got Jason assigned that's going to show up in the Gantt chart. They are going to be notified when those tasks are coming due. So that's a big expectation, just assigning people to tasks and TeamGantt. But you can take that a step further like I alluded to before. Essentially you can use the discussion in TeamGantt to actually show what your scope is and what the assignments are. So you can see here that I've pinned to task on every task. There's this little box at the top where you can pin a note. So, I like to use this note to set expectations about the tasks themselves. So as you can see, I typed in here, we are scoped to do 12 interviews and then I also put in our RACI values as well. So I'm going to be a responsible, Jason will be accountable. Jamin will be consulted and our dev team is just going to be informed on this task. So everyone who's assigned to this task is going to get an update. They're going to be able to go in and click on this and see what the scope is and what the RACI is. It's a really good way of using a RACI Matrix that might be a separate document and pulling it into your project plan to help you set expectations. And that's it. I see that as a really simple low effort way of setting a big expectation and checking in on things, and that's the kind of magic you need in your back pocket when you're managing busy people on multiple projects. It's kind of funny because it's a simple expectation that we often overlook, because we trust that people in specific roles always know which tasks are theirs. But if four of you are playing the saxophone, that could get kind of confusing. So take a few minutes to talk about roles and make assignments very clear.

All right, now we're getting to the heart of the matter. You cannot set and manage project expectations without really good communication practices. So first I'm going to talk about some communication basics and then dig into some tactics that will help you to set and manage expectations. First, it's got to be said. If you want your teams to perform, you have to communicate openly. Details are really important and there's usually no reason to hide them from anyone. In fact, sharing more will help you gain trust and solve issues quickly, but you can't just turn the communication's faucet on and start sharing everything. You do have to be selective both in what and how you share, but also how much you share. In fact, you might want to sit down with your team to talk about how you'll communicate. Setting an expectation for how you'll engage on a project will help you majorly in the long run.

Think about it, you won't have to chase people for updates. Beg people to respond to messages or better yet worry that they're completely ignoring you. Ah, the life of a project leader. Let's talk about the forms of communication that will help you to set and manage expectations. They're listed on screen here, but before I jump in, I want to say it again. You can adapt or adopt these practices at your will. There's no right or wrong way of doing this. Just be thoughtful and consistent and you'll get what you need. First, let's talk about meetings. Most people hate meetings, but that's probably because they're handling them the wrong way. As a project leader, you're probably in a lot of meetings. You schedule them, you take notes, you move onto the next one. It can feel like they stop you from getting work done and again, if you're feeling that way, you might be handling them the wrong way.

Meetings are work and they should serve your projects, not drag them down. If you're in a position to manage meetings, you should use them to your advantage. How do you do that? You handle them as a form of communication. One that helps you to move your project forward by confirming expectations that were set by your scope and plan, and one that allows you to have face to face time with your team and your stakeholders to discuss important issues and enjoy it all at the same time. The first thing you should do is set an expectation for how meetings are used. Part of the reason many people don't like meetings is because they end up in meetings that are not useful to them and it's your job as a team lead to organize a meeting that will be useful for everyone involved and in some cases even replace other communications. This sets an expectation of how your time is to be used and how meetings should operate efficiently.

I won't get too deep into how to manage meetings here, because that's covered in class 12, but I do want to cover some specific meetings that do a really great job in managing expectations. The first one is the internal team kickoff meeting. And by internal, I mean the project team, so maybe call it the project team kickoff. I don't know, anyone at TeamGantt is going to tell you that I'm the worst at naming things, so call the meeting what works for you. Anyway, this is a meeting with your team only no stake holders, and the purpose of the meeting really is to set expectations. This is your first opportunity to talk openly about those operational norms and things that will make your project a success. On that note, you want to be sure your whole team is invited to and prepared for this meeting, so be sure to schedule it a few days in advance so your team has the opportunity to think about the upcoming projects and read through project documentation like the scope.

This meeting is the one where you'll talk through basic project expectations and dig deeper on how you'll work together to get it done. I typically recommend that the person from your organization who initiated the project lead the meeting, so that could be a manager or a department lead or even a salesperson who sold the project to a new client. You also want to be sure you're making enough time to talk through details and answering questions your team has. You want to leave this meeting feeling informed, energized, and ready to take on the project with the team, so schedule at least an hour for your get together. If you handle this one well, you'll walk away with 100% understanding of the project, a solid introduction to the stakeholders and their organization or department, and their project needs and goals as well as an opportunity to hear any team questions, concerns, or potential risks or issues.

Check out the sample internal project kickoff agenda in the class downloads and put this meeting to use and set those expectations off the bat. All right, up next is another meeting type that is not dissimilar to the last, the stakeholder kickoff can happen in many ways. Some companies will do a short kind of, this is how we work, meeting and jump right in. Others do kickoff meetings that are workshops. I'm a fan of doing those, but I also like to prime the team lead and stakeholder relationship with an introductory call to set expectations for what's to come. I also like this meeting because it's an opportunity to build the beginnings of a great trusting relationship based on solid information and discussion about how you'll work together as partners. So about this meeting, I typically recommend for this to be between the two team leads on the team and the stakeholders sides, and the goal again is to build a relationship and reset expectations for how you'll work together.

This is particularly helpful if you're working with a client who had initial discussions with someone else in your organization. It's your chance to talk through preferences on how you'll work and set the tone for a great project. But specifically you'll want to review the scope at a high level. Talk about how the project will be managed by you and your stakeholder, how you'll communicate and then be open about the possible issues or blockers. Trust me, when you do this, you can rest assured that the expectations are clear and the issues that might exist can be worked through together with your stakeholders and that's why I love this meeting. It makes the ownership of the expectations shared and that means you'll have a partner to manage through challenges when they come up. Check out the sample stakeholder kickoff agenda in the class downloads and get your stakeholder relationships started on the right foot with all of your expectations in place.

At the end of the day, you want to be sure that you agree on the project details and that you've both actually read the scope. I've been on a quite a few of these calls to find that not only did my main contact not read the scope, but the scope had changed without his knowledge. So a quick review can not only reset expectations but also save you from headaches down the road. So take the time to do this meeting and gain alignment on scope team roles, how you'll communicate and gain insight on early signs of potential problems. Okay. The final meeting type is one that actually helps you to maintain expectations. It's the standup meeting and you've likely heard of them or even been to them. Standup's are short meetings that do a few things for you. They build trust and accountability, ensure everyone's focused, keep communications transparent and they help you to solve issues quickly.

Typically, stand ups are done daily but you should put them at a routine that meets your team's availability and your scope. It's a very quick exercise that can yield a lot of info for you to act on. You stand around as a group and each person provides an update. What I did yesterday, what I'm doing today and what blockers stand in my way. Once you get through everyone, you're done and everyone breaks. As the PM, if you hear issues you'll likely follow up on them with folks outside of the meeting. What I like about standup's is that they force teams to have face to face time and it keeps everyone accountable to their tasks. At the same time, it helps to maintain the expectations of the project because you're putting details out in a very open way, on a regular basis, that keeps people on their toes and accountable to the project and the team, and that's huge.

I'll say this though, some teams struggle with standup's, but they're worth your time when you think about how easy it makes the flow of communication, which means it makes it easy to resolve issues before they become major problems. Grab the sample standup meeting agenda download along with the others, and you'll be armed with three meetings to help you manage project expectations with your team and your stakeholders. All right, enough about meetings. We'll cover a lot more ground about them in class 12. Let's move on to what I consider to be the most valuable tool when it comes to communicating project details and maintaining expectations. It's the status report. It's a good practice to keep an open, consistent line of communication with your stakeholders. When you deliver status reports and conduct regular status meetings, you're ensuring that the expectations you established in the beginning of your project with a well crafted plan are consistently reviewed and reaffirmed as you proceed to the delivery of your final product.

These regular check ins also give you an opportunity to build a relationship, which can be really valuable when you hit rough patches in your project. It's always good to have stakeholders on your side, so be sure to make time to talk about non-project related things when it makes sense. Find some common ground like hobbies or interests and make small talk. The only reason I mention this is because as project managers, we tend to want to be all business and formal all the time, but going a little off script can help with communications. When you've built a business relationship that's based on trust and comfortable conversation, it makes the more difficult news easier to swallow. Plus you're a human, you have to find ways to connect with the people you're working with. Now that you know what it can do, let's talk about what a good status report covers.

Essentially, a status report is a document that supports your formal project plan. I always recommend doing weekly or biweekly status reports for stakeholders depending on the size of your project. But essentially I see the status report as a critical form of communication that keeps everyone honest about the project details. A good status report covers the work that's recently been done and highlights what's coming next. By outlining this, you can set expectations about what's complete and what will not be revisited, as well as look at what's coming next and have conversations or even educate your stakeholders about how next steps fit into your overall process. A regular status report also includes an update on your timeline percent complete, which you can pull directly out of TeamGantt, as well as a budget update if you do report on those. It's just as important to include next steps and action items so you can be 100% sure that all parties are accountable for their tasks.

Lastly, I always recommend using status reports as your own way of tracking possible issues and initiating conversations about them before they become big problems. This is the part of the status report that requires transparency and some critical thinking on your part. You don't want to scare stakeholders, but if you see a potential issue, document it and discuss it, because talking through an issue will help you to resolve it quickly. One last note about status reports. You can get your status reports on a schedule by scheduling a call to review it with your stakeholders. This will keep you accountable to getting it done every week. The bonus in doing that is when you write a status report, it forces you to check in on all the aspects of your project. You'll update your plan and look at upcoming tasks and milestones and TeamGantt, work through to dos and check in on, on your budget.

It's the stuff that you have to do as a project leader, but we all know that other things often get in the way. So get in a routine and you'll always rest assured that you're up to date and so are your stakeholders. If you're not doing status reports now, I definitely encourage you to. Check out the status report template in the downloads and put it to use on your projects. Not only will you keep expectations in check, you'll keep people accountable and informed. Trust me, it's a total win for you as a project lead and it should only take you about 15 minutes or so to update and send every week. It's absolutely worth your time. Okay, so I have one final point to make here to help you manage expectations and it's a pretty simple but powerful one, and it's be an honest communicator. And what I mean by that is first never hide details or sugarcoat things. If things are bad, just say it.

In the words of my friend Nancy Lyons, communicate bad news at the same velocity as good news. Doing that sets the expectation with everyone on the project, your team and stakeholders included that you put the project success first, and that's important and powerful, and shows that you're a true leader with a strategic eye for producing the best possible project. Communications are important. You have to focus on being a good communicator, and sometimes that takes practice or even missing the mark just to get better. And there's more information on that in class eight, so you are covering all in the art and science of leading projects. But seriously, if you don't focus on solid communication practices and making sure everyone's aligned, you'll never have clearly set expectations.

All right, so that brings us to the end of this class. Consider yourself armed with the tools to help you set and manage expectations. And of course, if you're feeling a little overwhelmed, check out all of the downloads we've created to go along with this class. They're designed to help you set your own systems and be the best leader for your teams. Come back for class seven, which is all about managing scope and the inevitable scope creep.