Brett Harned:       Hey, welcome back to The Art & Science of Leading Projects. I'm going to warn you, this class is a little scary. All right, maybe not scary per se, but it's about a topic that will give any solid project leader the chills, that's scope creep. This is going to be its first and last appearance in this class because I'll be teaching you how to avoid it completely.

Brett Harned:       But first, I want to tell a story because scope creep and I go way, way back. And sometimes you just have to learn your lesson when it comes to avoiding scope creep and I've done just that. Okay, so I was working on a website Redesign Project and our design team presented some really fun and innovative designs to the client, we had done our internal review but our team's developer was out of the office that week. So we presented the work and the clients loved it.

Brett Harned:       Fast forward a week, we're reviewing some minor design revisions internally that the client had requested, and our developer looks at the designs and comes over to me and says, "These designs are way out of scope." I immediately broke into a cold sweat, why hadn't I checked with her sooner? Why didn't I bring her manager in to do a scope check in the meeting? I then got on a call with the client to tell him we couldn't accomplish the work that we had proposed without writing a change request to increase the budget, it was bad, he wasn't happy, he yelled at me.

Brett Harned:       But thankfully I did my pre-work and came to the table with some options for how to make it happen. It wasn't ideal but we did make it work with a slight increase to the scope and a little bit of team collaboration. And that's only one of the several stories that I have where I team scope creep. The thing is, there are a lot of things that can change on a project and those things can often affect your scope. Think about it, it happens all the time. A stakeholders business goals change or a new stakeholder gets pulled into a project and you're forced to have a discussion about things that were 90% complete and already approved. Or worse, a stakeholder just completely disappears and it causes your plan to go sideways.

Brett Harned:       This type of thing can kill project morale, draw timing, completely drain a project budget. So what do you do? The first reaction of a PM is to build a wall to ward off in pending scope creep. But that's impossible because scope creep isn't actually a person or an animal that you contain. It's an idea that can spin your project out of control, or a personality that it'll get its way even at the cost of destroying your project and throwing you under the bus.

Brett Harned:       Trust me, I've totally been there. So how do you team scope creep on your projects? It's your job as the project manager to act as both of the project gatekeeper and the cheerleader to monitor, manage and report on its progress and to also guard your project estimate scope and timeline with courage and diplomacy.

Brett Harned:       Basically you always have to be on guard and you always have to be looking for issues. As you already know, any change additional requests or new requirement can bring on project stress, whether it impacts the deadline or budget or not, but when you're caught up in that moment and trying to figure that out, it's always good to remember that you've got a lot to fall back on. Provided you've done your due diligence and you've truly read and understood your scope, you've documented requirements and built a plan based on that scope.

Brett Harned:       Plus, if you have everything completely vetted by your team and your clients, you've got a big part of your argument in your back pocket. The initial steps of a well-constructed PM process, which you've already learned in previous classes will truly carve a path to success for you and your project. Here's the thing, people hate talking about money or things that they cannot have due to a budget, especially when they don't even understand the scope. And it's your job to talk about things that people hate.

Brett Harned:       That's just how it is for project managers or project leaders, so the best way to approach topics like budget overages and scope creep is to handle them head on and to document, document, document. But it doesn't always just start with a document, it starts with the work and the conversation surrounding that work.

Brett Harned:       A change in scope should never be a surprise to your stakeholders. They wouldn't call it scope creep if it didn't slowly slither upon you. Sure, some requests are obviously out of the boundaries of your scope and you can address those immediately, but there's often that one feature or requirement that starts as a manageable piece of scope and slowly evolves into something else. This, my friends is scope creep and it's your job to keep an eye on these things and make sure that they're not killing your budget.

Brett Harned:       It may feel like a personal burden and it sure can be, but we'll talk through ways to make it feel like a process and not a scary situation. On that note, you shouldn't take this personally. After all, you can't control everything and the work you've done to get a project in order should help you to make the right decisions when it comes to planning for even accepting a change. So when change does come up, whether you're blindsided by it or not, don't be shy to stop a conversation and say, "Let me refer back to the scope and requirements or the plan and get back to you."

Brett Harned:       You should never expect to or be expected to have every detail committed to memory, especially if you're responsible for more than one project. So take your time, don't feel like you have to provide an immediate answer and always remember that a solid informed response with a backup is going to have the biggest impact and provide direction or options.

Brett Harned:       Okay, so let's dig into the documents referenced here. I want to talk about how each can help you. First use your scope, 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.

Brett Harned:       In other words, it's what needs to be achieved and the work that must be done to deliver a project. Scopes can set serious boundaries around the work that will or will not be done on a project. So if you're not creating them now, whether you work with external clients or internal stakeholders, you might want to consider at least outlining some of what goes into a formal scope just to help cover your future self when inevitable change happens and you need to scramble to define the limits of what your team can or will do on a project.

Brett Harned:       What it comes down to is this, scopes can save you from major headaches when you're working on projects because they define all of those critical aspects and are agreed upon by the team and the stakeholders, and that agreement is important. Scopes make things very black and white pretty literally because they're printed documents with signatures, so they allow you to kind of more easily say no when new requests come up.

Brett Harned:       Now, of course, I'm not saying you'll deny every change, but scopes help you to determine what changes will make the greatest impact and where. For instance, if a stakeholder asks me for an extension on a deadline, I won't argue, it will be a change to the plan and I'll just communicate that but it doesn't impact my team's work as much. But if they ask for an additional review and changes to a deliverable, I might think twice depending on how much those changes will impact our budget or plan time. No matter what, both requests would make me look back at my scope to make sure we're aligned or just not going off track and I'll always communicate related impacts no matter the size of the change.

Brett Harned:       Like I said, scopes build agreement. When you have a scope, it gets everyone involved in the project aligned around the important details that can make or break a project. If you haven't already, checkout class six to dig into the details that make up a solid project scope, and download the sample scope and project brief documents. I just have one reminder, you can't create a scope and just let it sit. You often need to refer back to it to make sure you're actually managing it, effective scope of management can help to avoid some of the issues outlined on this slide by clearly defining and communicating the scope to all parties involved in the project.

Brett Harned:       Essentially, managing your scope will help you to distinguish what is and is not involved in the project and help you to make decisions on what you will find acceptable to add or remove as change occurs. Project scope is critical because without it, you would have no clue what time, cost, or labor is involved in a project. Without a scope or some definition of what should be accomplished, you can't effectively manage limits.

Brett Harned:       Don't forget your project scope is your source of truth for what's supposed to be happening on your project. Use it to help set and manage expectations about what will and will not be done on your project. Also, keep in mind that not everyone will have read or even care about the scope, so make sure it's someone's job to keep it top of mind. So when you see some change on the horizon, you can address it quickly. A requirement is a document or a statement that defines what must be achieved or created on a project. They're often also referred to as use cases, features or even functional requirements, and essentially defines an overall goal of what a product must do, what it should look like, and even how it should function.

Brett Harned:       If you want to dig in further on how to document and manage requirements, checkout class four and download the requirements template in case you haven't checked that out, let's give a quick primer on requirements. Essentially, the goal with requirements is to make sure you're able to communicate the information a team needs to design, build and test the product or even a piece of it. Oh, in there great for setting expectations with stakeholders to make sure you're clear on what they're going to get.

Brett Harned:       In that respect, it makes it easy to decide if something's complete or not. Plus, if a stakeholder decided to add a feature request or change in your project, you can refer to your scope and requirements to make a decision about priority or if scope increases are needed. This alone helps to make scope control easier. So if you aren't writing requirements now, you might want to think about it. Requirements are basically a backup to your scope and while your scope defines what you'll do on a higher level, the requirements will break down features or tasks on a more granular level. That helps you to stay truly within the boundaries of your scope and to have a clearly documented plan for it and that makes it easier for you to defend against scope creep when it happens, but requirements also help you to manage your projects to completion.

Brett Harned:       All right, let's talk about plans. Plans actually take a lot of hard work to pull together and they take time and care to manage over time. You learn that in class five. But here's the thing, you don't want to let all of your hard work go down the drain by succumbing to every new issue in requests. That first version of your plan is your baseline and it outlines every step you need to take to get from beginning to end on your project.

Brett Harned:       You don't just make these things up, if you're doing it right, you're basing it on your estimate and your scope. Sure, plans can change but referring to that first plan as your baseline will often help you in arguing the case for more time or more budget when scope starts to creep in. So stick to the plan and use it as your projects roadmap.

Brett Harned:       I want to mention that not every project change will result in scope change. Sometimes unexpected things happen, someone gets sick, a stakeholder has gone missing and can't provide feedback. A baby's born, you get the idea. If plans change and they likely will, be sure to track those changes and don't ever slip a timeline. Update in without notifying everyone involved, always communicate it in several ways. Here for some strategies for communicating change.

Brett Harned:       First, build agreement on details connected to your scope. Then help to track work to completion, and then update all impacted tasks and keep notes on extensions in your plan. For instance, if a stakeholder milestone is missed and a deadline is extended, make the change and add a note in the plan to task in TeamGantt, so people are made aware of the change. Then you should provide an update in your project status report. You should always be reporting on current timeline status and your status reports, so it's a perfect spot to report on the updates you've made to your plan.

Brett Harned:       You might choose to replicate the note made in your plan or even attach the plan for review and discussion. Next, be sure to discuss changes and impacts. I know I keep saying you have to communicate but you really do, it'll only take you a few minutes and it'll guard you from issues or questions down the road, plus a date is a date. If someone misses a deadline, your next delivery date might be impacted, as well as the final deadline. Missing deadlines will most often cause an impact, whether it be on your resourcing plan, the next delivery or the final deadline. Don't fear the conversation about timeline issues and impacts, especially if you've made the time to discuss and review your baseline plan.

Brett Harned:       Talking things out while a change is happening will help everyone to understand what's affected. Lastly, be sure to keep your documents updated, this can get kind of annoying, but if you make a point to keep your documents updated you'll make your life easier later on. Note or add the change in your project requirements document. I'm going to quickly show you a few things I just mentioned in TeamGantt. Okay, so when you're managing scope, keeping updated with your plan and making sure that any changes you're making are really communicated and clear to everybody on the project, your clients, your stakeholders, your team, all included.

Brett Harned:       So what I want to do is show you just a few simple things that you can do in TeamGantt to make sure that you're keeping up with change. First of all, making a change to your plan is super simple, so I'm going to show you that. As you can tell, we're looking at a plan here and I've set up the plan already, you can see that I've got tasks and milestones, some of my tasks are completed. I've also set up dependencies and when I set up dependencies that makes making a change simple. So simply by doing that, I'm saying, "This task cannot be started until this task is completed."

Brett Harned:       So if I need to move this task, design downloads out by a couple of days, that's going to move everything out with it. Pretty cool, I'm going to move it back because we're not going to make that change yet. One other feature that I think is really important for you to know before you make the change is baselines. So if you go over to the menu bar and scroll down to baselines, what a baseline does is basically shows you where a project was on any given day or time. So if we look at my baseline from April 25th, 2019, you can see that a task was extended. And that this task was this milestone was moved out and this task was moved out with it.

Brett Harned:       So showing that baseline shows me where the project has moved over time and you can say that as I've made other changes to the project, I've got baseline set up for them as well. So let's say I want to set a new baseline because I'm going to move that other task out. So I'll click create a new baseline, I can see it adds another baseline to the list for the date that I'm recording this. And essentially as I move this task out a few days, I can go back and view that baseline and it shows where that task has moved from here to here. And because I have all of the other baselines viewed or checked off in this box, you're seeing all of them but right there you can see that change. What I recommend doing when you do make that change is going into that you're going into that task and you're going to add a note.

Brett Harned:       I just moved this deadline out by a few days due to a delay in receiving design assets, okay? So that's basically setting an expectation that we always communicate about changes. We talk very clearly and concisely about why we're making changes to the plan so that we can go back and not only look at the baseline but look at the communication that happened on that day. So it's really easy especially on a really large project where a lot's happening, it's really easy to look back and know what happened throughout the history of the project.

Brett Harned:       So that's pretty much everything that I wanted to show you here, essentially when you're making changes, make sure that you're communicating them and also make sure that you're keeping all of your project communications and documentation up-to-date. All right, let's get back to the class. All right, we've covered all of the work you can do to back you up when change happens. Now, let's talk about how to formalize that change, that can happen through more documentation and you guessed it, communication. What it comes down to is you need agreement on change before you proceed with it. Sometimes that requires re-estimating a task to determine what is really needed in terms of time to get the change done. And that'll lead to a decision on how formal you need to make the change process.

Brett Harned:       As a rule of thumb, I recommend that at a minimum you document changes in your plan using the discussion feature, and when you make scope increases, those should be done through a more formal document. If you make a change control process a conversation and a known part of your process or even your role as a PM, it'll make change a little easier to handle. That's all to say, from day one on a project, you should be transparent about the fact that you know change will happen and that you have a process for handling it.

Brett Harned:       This is equal parts, setting expectations and creating process. If you're in a larger organization, you might be required to complete a series of approvals to ensure that everyone on your team agrees to a change in plans or timeline. On smaller projects, with smaller teams, it's often easy to merely take everyone's word for it and keep moving on with the change.

Brett Harned:       In that instance, it's not a horrible idea to create a paper trail associated with the particular conversation or change, that paper trail could be your scope and any subsequent changes made to it, but before you get to the change request, you want to be sure you're properly diagnosing a change, so when you realize that they're going to kill your budget, use your documentation and status reports to call out the issue. There are many ways that you'll handle this.

Brett Harned:       I just want to share a couple with you here. If you're working with a budget related to the amount of time your team spends on tasks, your first step would be to reassess the budget and note where the work is trending. Take a look at the estimated effort, then check in with your team to see if they would estimate an overage. If they confirm, you need to make your stakeholders aware right away. If they think it's fine and you're just being an alarmist, you might want to let your stakeholders know anyway because there could be a potential risk.

Brett Harned:       It never hurts to show that you're thinking ahead and being budget conscious, the best way to do this is to make it formal, creative risks and issues section in your status report, so you can write out potential issues then discuss them with your stakeholders. Discussing the issue might feel uncomfortable, but it doesn't have to be. Calling things out early will give you the time to think through a mitigation plan and discuss it with your stakeholders. Plus, by not waiting until the very last minute to call out the issue, you're positioning it in a way that will help everyone involved to devise a reasonable approach to the change.

Brett Harned:       You always have your scope and plan to back you up, a well-researched and planned discussion surrounding the risk of scope creep will help to put you, your stakeholders, and the potential issue at ease. Anything can be sorted out with planning and discussion. And when you come to an agreement about what the changes, documented in a change request. Many organizations use change requests also sometimes called change orders to document and track change. Whether those changes are related to a budget and scope or timeline. I've certainly written a lot of no cost change requests in my day as an agency project manager, and I never mind to doing that because I knew I was being really clear about change on a project, and making sure others were too.

Brett Harned:       It's just as important because those things can get misinterpreted or even lost in conversation, so why not formalize it? You can use your judgment here, but it's never a bad thing to write a change request for a non-scope related change. It can be a good way to cover your basis and ensured that no one will go back on what they've verbally agreed to. Download and adapt the change request template, if you don't have a change request template already set for your organization.

Brett Harned:       At the same time, you should know that any good change requests will include these things. A description of the change, your approach to the change, the schedule or timeline impacts, any risks associated, any applicable costs and then signatures and I always recommend that if you're working with external stakeholders that you require a signature on a change request.

Brett Harned:       Sometimes you'll get to a point where the team can't continue work without a budgetary change request, but the stakeholders don't want to agree to it. Talk about uncomfortable. It's never easy to proceed under those conditions but as the project lead, you have to come up with some options. Here are a few scenarios to think through. First, can you trade scope? Meaning, if your team does let scope creep commit hostile takeover, can you cut something else from the project to make up for lost time or budget?

Brett Harned:       How will the change impact the quality of the product is another question? If it's going to make it worse, how does that impact your bottom line? Is your company willing to eat some of that cost in order to develop a better product and keep the client happy? If yes, what is that cost? No matter what the answer is, you'll need the buy in of your team and management to make the change that's best for your project, your stakeholders and your company. It's never an easy decision to make.

Brett Harned:       Okay, I just want to take a second to talk about quality because scope creep can make us do crazy things sometimes. Often, you'll be asked if you can cut corners to make something happen, and just because you want to please a stakeholder or even just get them out of your hair, you might agree. I just want to warn against doing this without serious consideration and discussion with your team. At the end of the day, everybody wants to deliver a quality product that's successful and invokes a sense of pride.

Brett Harned:       So while it's important to complete and deliver on time and under budget and not given to scope creep, you should never lose sight of delivering a quality product. The expectations of what you're to deliver should never be overshadowed by the scope or the timeline. You'll always use your timeline and budget as the guiding light, but it's important to set forth what will make the project to success in the eyes of your stakeholders and your team.

Brett Harned:       So in order to make sure you're making the right calls when it comes to accepting change or cutting corners, make sure you have a mutual understanding of what's important and what will make your project a success. Onscreen, you'll see just a few questions to ask when change arises. This should help you to keep your eyes on what's important to the success of the project and the quality of the outcomes while still staying true to the scope.

Brett Harned:       First, what are the goals of the project? Defining those will help you to assess whether a change actually helps to meet a goal, that can quickly change the conversation about a change when needed. Then what will make the project a success and what can we do to ensure success? Is a change going to change your view of that success in a positive or negative way. And lastly, how will you measure success after completion of the project. When thinking about change? Well, the measurement be impacted negatively by a change or will that change cloud the measurement that you agreed upon?

Brett Harned:       Asking these questions will help your team set some targets within the context of your project budget and timeline. Having goals helps you to set the stage for how you can meet them within the constraints of the project. Goals can also help you to gauge the validity of new requests as they come in. If you're experiencing scope creep and the work doesn't actually meet the outcomes of the early discussion, it's much easier to say no, and that leads me to my final point here. There are times when you just can't accept the change, this is hard for a lot of people, but again, your scope is black and white, so use it and use your requirements and use your plan, and tell them no and why you have to say no, be clear and concise, but be open to complaints and maybe think through some options that might lessen the blow of the word no.

Brett Harned:       This reminds me of a time when I was working with a really high profile and kind of intense client, who wanted to roll a whole unplanned section of a website into a project. I loved the idea and my team loved it too, but we just didn't have the budget to do the work. So I had to break the news to the client and you bet I had some backup options in my back pocket for that conversation. I was prepared. So I get to the call, I break the news that we can allow additional scope and it was also going to be adding to our deadline. I got yelled at, which is never cool.

Brett Harned:       I explained why we could not take on the extra work, it was strictly budgetary and really clearly outlined in our scope. But I presented three options for adding scope, offloading other work and adding work to phase two and we came to an agreement on working together to offload some work, everyone was happy, I was able to say no and then but and that worked well for me.

Brett Harned:       So I've already told a couple of stories but I thought it would be fun to share another scenario and then some specific actions to take in a situation like this. I hope you can relate to this scenario and that the follow-ups I'm mentioning here are helpful. I think what's most important to mention here is that there really is no right or wrong answer, I keep saying that scope is very black and white and that's true, but the way you handle scope creep will to be dependent on their relationship that you have with your stakeholders and sometimes their willingness to give up time and a plan or even to get more budget.

Brett Harned:       Along with other factors like the availability of your team, the validity of the change and much more. I'm sure you get it but I wanted to mention it here because there's no rule book or script to teach this stuff. All right, here's the scenario. Your project is 50% done and it has been approved along the way, your deadlines pretty set in stone and you're on track to deliver on time, but a new stakeholder joined the project and now wants to add a series of features to the project and they've never been mentioned or discussed.

Brett Harned:       So this is completely out of the blue, something brand new to think about, with a new perspective now in the picture. So what do you do? The first question you should ask is, what is the priority here? Meaning, if you want to change your ad scope and we already have a tight deadline, I need to know what you want. Is it what we had planned or this new thing? Because essentially you cannot get both.

Brett Harned:       All right, that sounds a little harsh and I wouldn't word it that way, but you get the gist. When you're stretched for time and someone presents a new challenge, you have every right to push back and do right by your team and the project. And that's okay, sometimes people ask for more because they had some great idea or maybe someone outside of the project requested it, or like in this case they're new to the project and maybe haven't been filled in on the scope and no matter how it creeped in as the pm you have to push it back out.

Brett Harned:       That doesn't mean you can't consider it late or take a phased approach, but you need to protect the focus of the project now. So how do you do that? This is a tough one, especially when you're dealing with a demanding stakeholder. The first thing you should do is question whether the new request supports the documented goals for the project. If it doesn't, you can quickly pivot to a conversation about those goals and how you might be better served addressing it later, possibly under a separate timeline and a separate scope.

Brett Harned:       At the same time, you have to prepare yourself for a conversation about the scope of your work and the level of effort included in the tasks that already are in your plan and the ones that they're proposing. Work up a quick estimate with your team and see what it'll do to your timeline. If you watched class three, you're all set. If you haven't set up good estimating practices in your team, check it out now and come back to this later. Really, what it comes down to is that the more you can educate stakeholders and provide evidence about the work you'd be doing and what it takes to do well, the more understanding they'll be.

Brett Harned:       If they won't budge, use the baseline feature again and show them the realistic timing using the estimate you created. At the end of the day, you need them to understand what it all realistically take to do the work and negotiate to come up with an alternate plan for that work. Sometimes, you'll make it work and that's great if you can do it, but if you do that, still be clear about the level of effort, no matter the outcome of your conversation, whether you add the feature with an increase to scope and a change to your plan, you have to document it.

Brett Harned:       For me, that would mean a change request. For you, it could mean the same or it could even mean an email to the proper stakeholders included. You should also baseline your plan and change it and share that with notes in the plan and update it in your status report, and of course add new requirements to your documentation. Just to everything you can to communicate why the change happened, how it's being addressed and any impacts it may have on your scope requirements and plan, then track it and talk about it until it's completed.

Brett Harned:       And that's all I have for you today, but let's check in to see what our expert PMs have to add when it comes to managing scope creep.

Meghan M.:          How do you prevent scope creep? A little trick question. So I don't know that you can prevent scope creep because that assumes that the client knows exactly what they want when they hire you or when they... if you're an in-house PM when they sort of come to you and say, "This is a project we want to execute on." And I think that's actually very rarely true, so I think for me it's less about preventing scope creep and more about creating a process for delivery that allows for change and adaptability.

Meghan M.:          So how are we going to adapt to the new information that we absolutely are certain to learn along the way? I often use the analogy of like an HGTV show when talking about scope creep. Like there's never, you never watch one of those shows and have everything go according to plan, there's always like they knock out a wall and the pipes are rusted and now like, "Okay, the thing that we thought we were going to do in this house, we have to do something different."

Meghan M.:          And I think our work is exactly the same, we think we know what we're getting into, we make our best guess, but we're going to get new information along the way. And so how do we create a process where the client or our team can safely change our minds and adjust course?

Lina Calin:         It's important to define what the project is just as much as what it isn't. Make sure that that's documented and laid out clearly for everyone to refer back to easily, and get the investment of your entire project team, let your team know that they can help catch red flags and risks just as frequently as you can, sometimes they're even closer to the problems and might be able to catch them faster, and let your clients or your internal stakeholders know that they can take care of this as well.

Lina Calin:         Let them know the dangers of scope creep and how it might delay the project launch or affect the project costs. And when they realize how scope creep can affect the project, they'll be on onboard to protect the project from scope creep just as much as you are.

Carson Pierce:      There are two things I think with scope creep. One is in order to avoid going outside of your scope, you have to really understand what your scope is in the first place, and that means at the beginning of the project, really defining your requirements, knowing exactly where the walls around your project are. Once you know where the borders are, you know it's outside the borders.

Carson Pierce:      And part of that it involves the idea of knowing when you can say no by knowing what you're saying yes to, and the story that comes to mind for that is we used to get a lot of calls for donations to charities. And I always felt really bad saying no to anyone and there was a lot of guilt involved in that. But what we did instead is we actually sat down and said, "We're going to focus our donations this year on two particular charities." So once we knew who we were saying yes to, it became a lot easier to say no to others because we had a purpose to that.

Carson Pierce:      And I think it's the same with projects. Once you know what you're saying yes to, it's a lot easier to say no, and then that helps you to keep your project in scope.

Brett Harned:       At the end of the day, there's no denying change when it comes to projects and we all experience and stress out over that change. Remember, a number of things can happen to test the boundaries of your scope and timeline. Your best bet to handle or adapt to these changes is to embrace them and do these things, ensure that your plan is based on the reality that is your project scope. When a change does occur, update your project documentation and communicate the change to everyone involved.

Brett Harned:       This will ensure that everyone's aware and not ignoring the issue. If you got to increase, no. If you have to increase your budget for a change, talk about it and document it, and don't forget you don't always have to accept a full change. Talk through options of how you might make something happen without fully increasing your scope.

Brett Harned:       Remember, projects or partnerships. Lastly, don't ever forsake the quality of your project for a change. Keep your project goals in mind because it could help you rule out an impending change. And now that's a wrap. Congratulations, you made it halfway through The Art & Science of Leading Projects. How do you feel you're doing so far? Feel free to drop me an email at brett@teamgantt.com or better yet, leave a comment or question in the comment section. Come back for class eight, which is an important one, communications. Thanks for following along.

‍