Transcripts
1. Introduction: I really like problem-solving. It's the simple things in there. It's not all about delivery, it's about every day coming across those challenges that you might meet and overcoming them. That's really the thing that gives me much joy. Waking up in the morning, knowing there's a problem to solve, and finishing the day when we've made progress on those issues. Hi. I'm Matt Corroboy. I'm a software projects director in the Life Sciences Industry. Now, I've been running projects for the last 20 years or so, and 10 of those years have been running a team of project and program managers. Today's class is going to be aimed at people who are just getting into project management or maybe are looking at getting to project management or maybe getting that first project and are looking for some hints and tips of what it takes to be a good project manager. Today's class is going to be a whistle stop tour of the basics of being a project manager. We're going to talk about what it takes to have the right mindset as a project manager. We're going to talk about how to understand what you need to know about a project, we'll look at planning projects, we'll look at managing projects, and we'll then look at how to communicate where we are on a project with our key stakeholders. I first got into project management almost from the get-go at the beginning of my career, and I was a systems tech at the time and was given a project to run that was maybe a month long, involved a few stakeholders. From that, I really got the bulk of organizing, controlling, almost staying on top of all of these activities at once and actually that communication and the satisfaction that you get from bringing things together and delivering something at the end. That was really the catalyst for that first project, right back at the beginning of my career. I'm excited for people to take this class because I think that there's life skills in this, this isn't just about projects. If you pay attention carefully to some of the lessons we'll go through, they'll apply not just to the workplace, but will apply to life in general. We've got a lot to get through in this class, so let's jump into our first lesson on how to think like a great project manager.
2. Thinking like a Great Project Manager: Projects rarely go smoothly, if they did there'd probably be no need for a project manager, but that's rarely the case. There's often deviation on projects or maybe things that need to be managed and often leadership in order to bring those things together. For me, being a good project manager or even a great project manager is more about how you think and behave in the role rather than the tactics, the specifics of stakeholder management, risk management, etc. It's more about how you think that's important. In some ways, it's really simple; you need to be organized, you need to be disciplined, you need to be strong when times are hard, you need to be a positive influence, you need to be great at building relationships. Here are a few areas that compound on why it's important to think like a great project manager. Let's talk about grit and resilience; when projects encounter challenges, the mindset is key. Now, projects rarely follow the happy path so you have to go into a project with your eyes wide open, ready to face those challenges, ready to be proactive, often leading with that mindset to encourage others to do so as well. The problem should be acknowledged for sure but we're in the business of creating solutions as a project manager. Let's talk about growth mindset; as a project manager, it's really important to always be learning, always learning from what's happened, and what you need to do moving forward. That could be the current initiative you're on, what worked, what didn't? Maybe the last project, what worked, what didn't, what do I need to apply for this future project in order to be better? It's massively important from one project to the next to take those learnings forward with that growth mindset that we're always going to get better because no project is perfect, no project manager is perfect but if you go into it, ready to learn, then that's where you can really make the difference. The next tip is that relationships are key, you need to have the right mindset with those stakeholders and team members around you. Rapport and trust is key. If you're going to motivate and inspire team members around you, then you need to work on those relationships. Delivering a project at all costs might deliver the value of that specific project but it won't help you for the next if you've not spent the time working on those relationships. The next tip is being comfortable and calm within the chaos. Potentially, there are lots of things going on within the project that you are running and you need to be able to handle all of those multiple activities while staying calm and disciplined. Now, project managers that love project management often thrive in this environment, whether a choice is to be made as to what the priorities are in any given day of the week. But discipline is key here, that's the thing that's going to make a difference for you. Notice how all of these tips are all about being positive as we approach the work. Again, this is vital, having the right mindset as we approach things. Being calm within the chaos, being organized, being of a growth mindset, looking for those opportunities to get better from one project to the next, and when projects are encountered, being positive in dealing with them in the right way. These all really help as we move forward into actual mechanics of running a project. But that all starts with carrying forward that thinking mind when it comes to managing projects. Let's move on to our next lesson where it's all about understanding our project, understanding the why, and building the foundation for our projects understanding that will enable us to deliver it much more successfully.
3. Understanding Your Project: This lesson is all about understanding your project at the beginning and understanding your project throughout the work, and this is really important. You can be somewhat of a good project manager just by following systems, by following almost robotically if this then doing that type statements. But within a project, there are decisions to be made. There's critical points, there's stakeholder engagement, where people are looking for information and it really pays to understand the fundamentals of what you're trying to do so that you can convey that information, you can motivate and lead when needed to do. You can also make decisions as you go through the course of the project much better if you understand your projects at the right depth. Here Here the tips that will help you understand your project from start to finish. The first step is understanding the why of your project. This is vital, especially at the beginning, to understand why have I been given this piece of work? What does it mean? Why is it important for the business that I'm part of? You can use multiple techniques there: you can use a five whys technique where you're going to ask yourself: why I'm I doing this project? Why is it important to the business? Why does it align to the strategy? Why is that market error important? That really should be able to connect your project to maybe the business strategy or maybe even their vision and purpose, which is massively important. Now I truly believe that to be a great project manager, you need to understand the why and understand the project with both your head and your heart. That's massively important. You can, as I said, be that robot going through the project. But I think if you understand passionately the why behind what you do, you can convey that to others and that will really bring success in your project. The next step is understanding your project through the course of its duration. Now, you're not just being made a project manager just to deliver the outcomes at the end, is that to represent control through the course of the work itself, you need to have techniques and strategies in place which allow you to look at the entirety of the project, all the activities that you should be considering in front of you any point in time. There might be risk management, change management, stakeholders to deal with. There might be a business case, there might be project tracking, there might be reporting. There might be a whole list of activities that need to be driven forward at any point in time. Sometimes it can be overwhelming as a project manager to have all of these things in front of you. The key for me is having a simple mechanism to be able to take a step back, look at your project, look at all the various different elements in a simple view, like a mind-map for example, and ask yourself questions any given day; have I got these things under control? I think putting that discipline and understanding where things need to be, will really help you as you move forward on your project. The next step is always being ready for the elevator pitch. Now, this is a tip which I often share with my project managers and ask them to think about this. Imagine you've got stopped in a corridor by the CEO or maybe a senior stakeholder, and they're going to ask you about, what's currently going on in the project? How are you going to summarize that? How are you going to summarize the highs and lows, the challenges, and what's the key takeaway that you want this individual to have when they talk to you. You should take the time and think about this. This is going to compound on that why message around the project, is going to allow you to communicate much clearer if you understand what's going on at that one-minute interval level that you can summarize it so condensely. Take the time to think about yourself and that will really pay dividends in the future. If you've currently got a project that you're running, then pause at this point in time and think about some of these tips. Think about understanding the why of the project. Think about how you're managing the work and your level of visibility, and think about how you'd summarize it in a condensed way. Understanding the why of your project and everything that's going on is really the bedrock for its future success. That's at any stage right from the beginning and all the way through, so take the time now, think about that.
4. Planning for Your Project : This next lesson is all about planning your project. It's fun to go on a journey where you have no destination. But actually, in the workplace, that's rarely the case. There's normally an outcome or a deliverable or an expectation that your project is intended to deliver, and in order to get to that destination, you need to know what the steps are that are going to get you from where you are today to that endpoint, and that's just the plan. That's the thing that we need to create that's going to represent our A to B for the work that we're trying to do. Without having a plan, spending time on a plant or creating a plan, and we're not really managing a project. They're just a sequence of things that are happening. Now having a plan gives us something to center ourselves around, to center your teammates around your stakeholders to become aligned as to what you're trying to achieve, not just the output at the end, but actually what are we trying to do today and tomorrow and next week. A plan is something that represents the activities and tasks that need to be taken throughout the course of the project to deliver those outcomes that you've been asked to project manage. Those activities might be dependent on each other, which might mean there's a sequence of work that needs to take place. You'll often heard terms like critical path mentioned here, which really shows how those tasks link together to get to that endpoint for the project that you're running. Let's talk about how to create the outline plan and that often starts with something called a work breakdown structure or WBS, which you might hear in project management circles. Let's imagine we've got this, the top-level task, which is the project itself. Now, the project's obviously too high-level to have a plan associated with it so we need to break that down into the main chunks of work that will live within it. So let's imagine for this example that we break that down into three segments of A, B, and C. Now again, in most circumstances that's not enough detail for us to really understand who's doing what. So for this simple example, let's break down some of these to one level below this as well. Again, for simplicity, let's label this A_1, A_2, and A_3 and for this B task we'll do a B_1 and a B_2. Now, we'll do three more under C; so C_1, C_2 and C_3. So what this enables us to do, which is really important in project management, is ask ourselves some simple questions here. What do we know about these tasks? Have we done something like this before? Could we potentially estimate how long it would take to do this? What's the duration of the effort involved? So if we've gone through this and we look at it and go, "Hang on a second, we've, we've done these things before. I can size that, I understand the risk associated with it," then that's great. Maybe this one too is the case. A_3, not really. That's something that maybe there's a little bit of uncertainty around so we're going to question mark against that one. Then we go through the B tasks. This looks okay, this is fine, this is fine, this is fine and again, we've got another task with a bit of a question mark against it. What we're trying to do when we do project planning at this level is find out where the risk is in our project. We're not defining every single task that's in our project. I think that would be crazy to do that. We've got to do it at the right level that tells us where the risk is. So what we've done here is identify a couple of areas where there's some flux being raised. What we might do as a result of that is dig a little bit further down on these into the tasks beneath them and when we do that, what we might end up finding is that we're okay with this, we've done this before, but actually this A_3 2 task that we've got here now is the one that posses a question on our ability to deliver this project. So that might be enough, that might be enough rest, we understand it enough to actually move on. So for this simple example, we'll pretend that that's the case. The other thing we've got to do when we go through the work breakdown structure is look at the size of these tasks. So there's many different ways in different schools of thought outside the company work in really constrains up thinking where you have to be really specific, but a very simple way when you're throwing that projects together for the first time is to T-shirt size these things. So give these labels, so you've got small, extra small, small, medium, large, extra large, maybe XXL in there and associate those sizes with potential days; so extra small might be one day, small two days, medium three, large five, etc. What that allows you to do is look at your tasks now and start putting size as a T-shirts against these, that's a small, this is a medium, this one's an extra large. Work your way through for the areas where there's risk in the plan, you might want to put a range of sizes against them maybe that's a medium to large and we'll use that later on when we join the dots on the project. So we've got a size on there, we understand the tasks, the next thing to do is to draw dependencies as part of this plan. So maybe A_2 needs to take place only after A_1 is complete, maybe C_1 has to only start once this A_3, 2 is complete, draw out those dependencies and then you've got that full view that we are actually where you understand at this stage as you understand your task breakdown, you understand some sizing, you've identified some risk and you know the dependencies. That's your first pass of a work breakdown structure. With these previous steps now completed, it's time to map this out. Now there's many ways you can do this. You can have post-it notes, you could do it on a piece of paper, you can use and MS project or an Excel spreadsheet. The dependencies are key here because obviously this dictates which tasks can only start once those are complete. Now a brief word on leveling in this. What we tried to do in this simple example, you just assume everything is a duration as opposed to an FL on projects with multiple people, you can have multiple tasks running parallel, you may have the ability to reduce a task size by putting more people are now. But for this simple example, let's just assume we can map these things out just purely on durations. So do that, map them out on a board for your specific project and if you look to the right hand side when you do that, you'll see that endpoint. Now that endpoint is your first core planner when the end of the project is due to land. Now what's important at this stage is to review that date. What does that tell us? Does that meet the constraints that maybe on the project, maybe somebody needs to adjust, maybe more resources need to be part of the project, or maybe some other scope needs to change? Either way, this is your plan. Make sure you review that with your stakeholders and then we'll move on from there. As you can see, there's a lot to think about when it comes to planning your project and what I want you to do now is think about your own projects and think about your project structure and how that has been created. Maybe it's too detailed, maybe it needs refining a little bit more, maybe you have not identified the risk in there. But this is a great start to get us moving and that leads us into the next part of the class, which is about managing your projects.
5. Managing Your Project: The next lesson we're going to step into is about managing the project. We've done really well now we've created our first plan and if everything worked perfectly fine, it run to the end with no management needed whatsoever. But again, as I said earlier on, that's rarely the case. The plan is just the beginning and what you actually really need to do is manage that plan through well. That's not just doing the work itself. There are lots of other activities that you have to consider as a project manager. People want to know what's happening, how are you going to do that? How are you going to align people towards what they need to do today or tomorrow? Because most people rarely do know what they need to be focusing on without that direction, this is what it takes to manage your project successfully. What we're going to do today is go a little bit into some of those tips. We're going to look at zooming in and zooming out as a concept, as a way of tracking the project. We're going to look at risk management. We're going to look at measuring success as we go through the course of the project, and we're also going to look at all the other activities that we might need to think about in our day-to-day as a project manager. This first step is all about project tracking and I like to employ a technique called zooming in and zooming out on our projects in order to make sure those focus, to make sure that stakeholders and team members are really clearly focused on the tasks that are right in front of us. What does zooming in and zooming out mean? You've got your big plan that you've just created. But looking at that as an entire picture, day in, day out can sometimes be overwhelming. What I like to do is make sure we chunk up the work in a period of time in front of us. Maybe it's a four-week project. We're only going to focus on Week 1's activities and that allows us to bring those stakeholders together, bring those team members that may have activities to do within that into a room, look at those activities just for that week and stay laser-focused on delivering those in that period of time. Now the next thing you do after doing our zoom in, here's your retrospective on the work, so you're going to pause for a second. You're going to look at what you said you were going to do in that period of time and you're going to look at what went well, what didn't, what was maybe a bit of a struggle. Maybe you want to stop doing things moving forward. Maybe there was some activities that took a little bit longer than they should have done. Maybe actually you didn't complete all of the activities that you said you were going to do within that time window. Now what we do with that information from the retrospective, those lessons learned is we zoom out. We look at that big picture, we look at what we originally planned and we take those lessons learned and we adjust accordingly. We look at which tasks are filtered into the second period of time. Maybe we've discovered something which means something's much larger further down the plan than we initially thought it was going to be. We adjust the plan accordingly, get ourselves set, realign over what the next chunk of work is and then we zoom back in again with our focus and this rinse and repeat of the zooming in, zooming out cycles is really important to keep people focused but always reflecting on what we're learning and what it means for that bigger picture. That's one of my key tips for project tracking in a working environment. Our next tip is all about identifying and managing risks. Now, risk management is often really undervalued aspects of project management with most people ignoring it and as a result of that, just dealing with issues through the course of the project, jumping from one fire to the next. Often the problem with risk management is actually the identification of the risks themselves and most people don't really think about it creatively when they think about what might go wrong within the course of a project. I like to employ a technique called the use of a pre-mortem when trying to get teams and people to think creatively about what might go wrong in the project. Here's an example. Let's say we're going to frame to the project team that the project was a disaster. What went wrong? We've completed the work and now it's the end of the project. Everything's falling apart. What happened? For example, maybe the project missed all its targets. Why was that the case? Well, we didn't do the right level analysis or we didn't assess as we went or take a pragmatic approach. Maybe the stakeholders actually hated the product ultimately in the end and why was that? Well, we didn't engage with them. We didn't listen to them or ask them for their feedback, or actually we didn't attest the assumptions as we went around the product itself or maybe nobody actually knew what was going on in the course of the project. Maybe our reports were poor and out of date. Maybe our coms were too infrequent and not really sharp enough. But what we've done here is we've identified what did go wrong in this future state. We can now start thinking about these elements and look at putting risk mitigations in place to identify how we make sure that they don't happen themselves. Now for a lot of projects, this is actually enough that we've actually identified things we want to address. But if you want to go a level deeper down, you can then take these risks, potentially combine with other ones and actually put them in some sort. What we do here, in this example, is we take these risk, let's say we've identified five risks, 1-5 and we want to think about what the probability of that risk occurring and what the impact might be if it did. Then again, individually or within the team that you're working with, just basically put these in the places where they might exist within the project. So R2 is high probability medium impact. We've got R1's here and over low, low, R5 might be flagged as being high, high and R3 sets or pair in this medium category. Now, what this actually helps you do is identify which risks you want to put mitigation plans in place for. If we just said we're only going to focus on highs, then we've got the red bracket here. We've got R2 and R5. They're the ones we're going to do something about. The rest of the risk, we're just going to accept and live with at that point in time. That's a really good way of narrowing down and where that focus needs to be around risk management for the project. But risk management doesn't stop there. You then have to manage that risk that are wound. Let's say R2 and R5 actually did have mitigation plans in place. We have to stay on top of them as project managers, make sure that those activities are taking place and then we're able to ultimately mitigate that risk, which is what the plan was all along. That is the basics of risk management. Let's talk about the next tip which is measuring success along the way. Now, just because your project is trailblazing its way through the tasks that it's put in it's plan, it doesn't actually mean it's been successful. What KPIs or key performance indicators might you have in your project which will actually allow you to see whether you think the outcomes of your projects are going to get met. This is often a tricky one, but maybe you're creating new products. How do we test that product in development early on? What assumptions are we making about what are project's going to be? Maybe we need to give early drafts of things to certain clients to get feed back in, and set these as milestones through the course of the project. We have to think carefully about making sure that we're deliberate on the outcomes of the project and that we're learning as we go. Now, often these are indicators which are going to lead towards that outcome at the end, but there could be other indicators as well that we have within the course of our project. We might be measuring the number of words within a document that we creating, we might be looking at a number of images created, we might be talking about the number of clients we're talking to in the course of our project. These are all things that will show a certain level of integrity to the project that you're running, and again, show that you've got not just control over the tasks themselves, but also a deeper understanding of the outcomes that we're trying to achieve through the course of the project. The previous section focus on some key areas of project management or managing a project in flow, but there's lots of other activities too that we might need to consider through the course of managing any project that we might need to stay on top of every given day of the week. I'd like to explore some of those very briefly now just to keep us all up to speed. I like to keep a little bit of a mind map here of things I need to think about on any given day and I'll often actually use this as a way of checking whether I'm on track or not, almost like a mental check as I go through this and in no particular order on this. Risk we're taught about this, but are there any new risks coming up, are there any risk actions that need to be followed up on today? Let's think about change. Has there been any changes in the project? Maybe I need to pull some specific and change plans in place. Maybe I'm not communicating the change or maybe I need to do something specific as a result. Let's talk about roles and responsibilities. Who are the key people involved in the project? Does everyone know their role? Is it clear? Does anyone not know their role? Do I need to realign with anyone? Let's think about tracking as we've just talked about. Do we know where we are at this point in time? Maybe I've had to escalate something up to some project review board or a senior management team or a committee then are there any escalations? Do I need to chase anything up about communicating appropriately with those review boards? What about my stakeholders? Do I know who they are? Have the stake holders changed? Am I communicating with them at the right level, and more importantly are they happy with what they're receiving from me? Maybe an environment you're operating in. There's a process. Maybe there's things that you need to adhere to, documents to create in a certain order. What needs to be created? Are we on track with those too? Is there anything I need to follow up on? Is there any risk there particularly? Let's talk about leadership. Who am I as a leader? Am I serving the team? Am I inspiring and motivating? How would I know? Am I asking them? Am I getting feedback from them? We talk about budget. Maybe you're in charge of the purse strings on the project as well. You've got to keep an eye on what's happening with the costs. How do I know where we're up to? What's the return on investment for the project itself? Success we've just talked about, But how are we measuring that? What KPIs are we looking at everyday? Then there's reporting. What messages am I sending out? Who am I sending those messages to? Are they getting clear messages for the project? Then if you're lucky enough to run a project that's already been released, then let's look at that extended project life cycle. What did we learn from that? What outputs that we seeing as a result and how will we know whether we need to do anything for the next project moving forward? All of this represents a pretty large picture of activities that you might need to consider for the project that you're dealing with as well. Now, staying on top of all of these things is often really, really tricky, which is why I love having visual representations of everything that's in play at any point in time. This is where the term spinning plates often comes from. Because if you focus purely on the tracking aspect for the project, for example, then it's very easy for us to lose track of the budget or maybe a raise in escalation and then I spend all my time dealing with risks, then I might lose track of those escalations and then maybe things might not get done. It's really important to have a visual representation and I like to, maybe in five minutes every day, just go round the mind map and ask myself whether I think that these things need any work as I go through them. That really allows you to stay in control, brings that discipline into the project, and allows you to be a successful project manager. Before we move on to the next lesson as part of this class, I want you to pause and think about some of these tips and techniques that we've gone through here. Think about how you're currently managing the project that you've got in flight. Do you need a mechanism like this which is going to help you understand where things are up to in your current projects. Take the time and think about that now before we move on to the next section, which is all about communicating our project status and communicating with our stakeholders on an ongoing basis.
6. Communicating Your Project : Our next lesson's going to be about communicating your project to others. Now you might ask why that's important, but you could be running the world's best project with the most amazing team of people working within it. But if you're not communicating that to people, then how might they know? If you think about your weekly report or an email that you send out to summarize to your stakeholders how things are going on a project, then maybe that's the only window that they have to what's going on day in, day out. Let's make sure it does a service to all those people working hard within the project, to really represent where things are up to. Good communication also represents control, which again is something that you're being asked to represent as a project manager on a project. Are you doing that in the way that you communicate? Let's jump into some hints and tips which are going to help us along the way. Our first step is all about communicating that formal status of the project. This is your project report. There's some tips in here which are really, really important. First off, it needs to be concise. It needs to be clear. It needs to be able to represent in as few words as possible, what that status is. You need to be thinking about explaining what's just happened, what's happening next, what that bigger picture of the project is, what risks you might be carrying? Maybe you want to put some asks in there as well, so that you're asking the audience to consider a certain aspect of the project or to give some feedback. Always concentrate on these concepts when it comes to reporting. I've seen project reports in my time, spam multiple pages that are dense with words and it leaves the stakeholders not really being able to get a good feel for what the takeaways are. Think about that. Key questions, key summaries, and what potentially the key takeaways are for the audience. Report is really an art form. It's saying maximum amount of things in as few words as possible. Seek that feedback. Look to see whether your stakeholders are getting what they needed, and shape, and refine that message so that it's clear and concise because that's what's going to be important to convey that message. The next step is to keep up the informal comms too, don't just focus on that formal project report, but look at the opportunity with things like Slack, or MS Teams, or other ways of talking to people. Maybe it's a daily stand up or weekly stand up with a wider group of people. Be that positive communicator, share the successes in the project. You'll motivate the teams that you're working with as a result of that, as they'll see that you're saying it too and that you're sharing that with those stakeholders that may be only get little glimpses of what's happened in day in, day out. Focus on those informal comms and again, you'll be better teams as a result of that. The next step is don't rush it and keep things up to date. There's nothing worse as a key stakeholder in opening a digital report that's out of date, that's not been serviced. Maybe it's actually in a central location which is meant to be real-time and they're getting information that's clearly out of date. Always be careful of what you're submitting, what you're sharing with your stakeholders, and that it's fresh information. Make sure the cadence report in that for matches the size and scale of the project they running. The second tip within this is to use your alter ego, as you create that first pass of your project report and just pause, switch on that alter ego and ask yourself questions, about what this report is telling me. What things might go unanswered? If I was reading this for the first time, what questions might I have? Just tidy up the report using the alter ego and maybe even as a third tip, room through that report top to bottom as if you were presenting it. Does it hit on all the key markers? I think that's really important to focus on that and keep the stakeholders happy as you go through it. For conciseness, think about the three things that you want someone to take away from reading your report. They should be really easy to identify when you read your material. Now remember, if you put an escalation on page 4, paragraph 3, then people aren't going to read that as an escalation. So think carefully about the information that you're conveying. The next step is understanding that communication isn't just talking to yourself. Let's say you got a stakeholder meeting and you brought people into a room to convey status of the project. You just talking for 20 minutes in full control of everything that's going on, maybe isn't the right thing to do. Communication is also listening. You've got an opportunity by bringing those stakeholders together to ask these people what they think of the project. Do they think we're on track? What risks do they see? What things do they need help with as well? I think the quiet you are in those meetings, letting others talk, the more value you're going to get from it. For sure, you're going to need to do that upfront setting the scene pace. You're going to explain to people where it is, but keep that less than you might think it needs to be. As a result of that, you'll build better collaborative teams. People will want to work because they feel that they're being listened to and if you adjust the plan based on this feedback, they'll be encouraged more to convey their own personal views of whether this project is on track or whether anything needs to change. Before we close out in this class, I want you to just pause and think about a whole communication side of things on your own project. What's working? What's not? Are the stakeholders happy? Are your reports too long that they need to be more concise? Have you got the right meetings and you conveying the right message in those? Take the time to think about that. Once again, if you get communication right along with the other things, then you're really going to make a successful project.
7. Final Thoughts: Thanks for watching the class today. Remember, it doesn't take too much to be a good project manager, just a little bit of discipline, and some organization, and the right mindset. What I want you to do now is think about your class project as you went through this, what hints and tips have really resonated with you, what does your schedule now look like, what things that you're going to start using in your own day-to-day? I want you to share them in the class project section if possible. If you've got any questions, then please drop them in the discussion board. Thank you again for watching and I'll see you soon.
Matt Corroboy, Projects, leadership, life and mindset.
