Introduction to Project Management: Methods & Tactics for Success | Learn with TeamGantt

1. Introduction: Hi. I'm Brett Harned. I'm a Digital Project Management Consultant from Philadelphia, Pennsylvania. In my role, I work with a lot of teams whether they're from agencies, startup companies, internal teams, or corporations, and I help them solve their project management challenges. In this class we're going to cover the basics of project management. We'll talk about the characteristics and principles of project management. I'll take you through a demo using project planning tool called TeamGantt, and then we'll talk about what it takes to set and manage expectations and be a great communicator. In case you haven't heard of a gantt chart, it's a tool that project managers use to represent how projects will get done. Essentially, it's a project plan using horizontal lines to represent tasks. TeamGantt is an online project planning tool that allows you to add tasks to projects, assign people, track time and really manage your project as a whole. You can create a Gantt chart, you can create a list view, you can communicate on tasks, and do everything that you need to manage your projects. No project is perfect, but if you want to know that it's managed well, look back at the timeline. Did people meet deadlines? Are people happy with the outcome? Have the goals been met? Is the budget still intact? Project management is the practice of keeping projects on timeline and on budget. There's usually a person who's behind the scenes setting up to do lists, managing project plans, taking a look at budgets, and ensuring that people are communicating. I hope you get a lot out of this class. The intent here is really to share some of the values that will make you good at project management. It's not about using a tool or being really great at one thing, it's about a collective experience and applying some principles to the work that you're doing. So, at the same time you should have some takeaways and things that you can really start implementing right when you get back to your job. 2. Principles of Project Management: Project management means a lot of different things to a lot of different people. So, no matter if you are an actual project manager on site in a construction site, whether you're working with an agency and a client, working on a website or if you're just a part of a team who has to really get a project done without a formal project manager in place, the principles of project management are important. In this section, we're going to talk about what it takes to make a good project manager and I'll talk through some of the skills that you can sharpen to get there. Over the course of my career, I've managed a lot of project managers. I've also worked with a lot of different clients as a project manager and I've found that there are certain set of skills or principles that really help to identify what a good project manager is. So, I'm going to go through those now. The first one is having an eagle eye for project issues. So, projects are difficult. Things change all the time, people come in and out of projects and you have to be the person who will deal with that change and that change will bring some issues. So, the best thing that you can do as a project manager is to have an eagle eye for the things that might come in and ruin the project, whether that's additional scope, whether it's a new stakeholder or an opinion that might come to the table. You have to be responsible for keeping tabs on what might go wrong on your project. Next is being a clear calm communicator. Communications is 90 percent of project management. As a good PM, you have to be direct and transparent in all communications. You have to ensure that you're not hiding any information or worried what will happen if you share some sensitive information with the team. The point is always to get the project done and get it done on time and within your budget. You also need to be a little bit flexible in the way that you communicate. People tend to communicate differently and they'll react to the way that you communicate and do their work. So, when you're working with someone, think about how they communicate. If someone's got their headphones on, do you need to bug them? Probably not. If you're in a meeting, what do you need to do to facilitate that meeting well and get what you need out of the team and push the project forward? At the same time, never be afraid to be yourself. You're going to build more trust with people as they see your personality and as you adjust the way that you communicate with them you'll be able to move things along a lot faster and difficult conversations will be much easier. You have to be empathetic as a project manager and what that means is thinking about the people on your team and how they're feeling about the work that you're actually managing. Put yourself in their shoes. If you're working with a designer, how does it feel to have to come up with a design within a really tight timeline? Think about deadlines and how that will make them feel. The more empathy you show, the better relationships you'll build with those people and the better you'll be able to complete projects on time. Next is being adaptable and flexible. So, the thing about project management is that people think it's based on a template or a tool. As a project manager, you have to know that templates and tools aren't the only way that you can manage projects because people are involved. When projects get difficult, you have to be flexible and adjust to change and at that time, you have to come up with new scopes, you have to estimate new work, you have to find new paths of completing projects. Being adaptable helps because you're always looking out for a change and you're able to make that change quickly. It's important to be curious as a project manager. Things change all the time no matter what industry you're working in and you're never really the subject matter expert on anything, you're the person who has to manage everything. So, you're better off talking to people understanding about the way that they work. If they found new ways to deliver things or new methods or processes that they want to try out. The more that you learn from people on your team and from people in your industry, the better position you'll be to lead projects successfully. As a project manager, you really have to be invested in the work that you're doing. What I mean by that is you can't be a box checker, you can't just be the person who's trying to push a process through and make sure people get their tasks done. Do everything that you can to pay close attention to your project and all of the details within it. Sit down with your team, understand what's happening, contribute to brainstorming, be a part of generating ideas, take part in presentations and meetings. Don't be the team secretary, be the person who's there to lead and motivate and manage people. The qualities of project management are individual characteristics that any person can take on to decide whether or not they're good at project management or if it's a career or path they want to pursue. As a PM in my career, I started to find that there were really no standards for how project management worked specifically within digital. Now there's the PMP and there's Agile and there are certifications and courses and books and formal methodologies that honestly for me in digital were helpful because they gave me a background for how things can and should be done within organizations. But I found that within digital, things are much different. There is a faster pace. The culture is different. There are a lot of different needs that you have to account when you're working with clients in an agency or with a digital team when technology is constantly changing and innovation is a part of something you have to build into projects. So, for me it felt like there were no standards and I wanted to create some principles or guides for how we as digital project managers should operate. Project managers are chaos junkies. We thrive on problems because we know we can solve them. Now we might not be the person at the table who always has an answer but we know when to bring the right person in. So, if I'm on a call with a client and they're asking me about deep technology things that I just really don't have a background on, I know that I can say, "Sorry, I can't give you that answer now but I'll follow up with my lead developer and we'll get back to you as soon as possible." That's a situation where we can be calm in the face of chaos. We also break processes to fix them or create new ones. We know that not every process or methodology that is rigid will work for all of our project scenarios so we take a lot of different things into account including our team, our client, project goals and other processes that we might have used on past or similar projects. Lastly, we manage with our minds not our tools. So, there are a lot of tools in the market that PMs love to talk about and use but none of those tools actually solve all of our problems. A lot of project management has to do with dealing with the chaos and personally figuring out how you can solve problems quickly and get your project back on track or keep your project on track. Project managers are multilingual communicators and by that I mean we speak many different languages within our businesses and within our projects. So, as a PM, I know a little bit about marketing, I can speak to it, I know about IT, I know about finance, I also know about UX design, graphic design, a little bit about code, content strategy as you can tell the list goes on and on. Having a little bit of knowledge and being able to speak to those things, helps in a lot of different project scenarios. Building trust is something that is really important as a project manager and I'll talk a bit about that soon but really when you can speak all of those different languages, you immediately start to build trust with your teams and with your clients. At the same time, we also speak with empathy and consistency and as PMs with expertise. We take our teams into account. We take our stakeholders into account and we can speak to them on a level that will help us to move a project along or at least to understand challenges or better past to move a project to its deadline. The way that we get to a good communications is through routine communications. We do regular status check ins, we do stand up meetings, we do one-on-ones, we communicate through tools like base camp and team camp and Trello and we do everything that we can to ensure that things are documented and shared with the team. Project managers are lovable hard asses. That means that they have to walk the line between being the team's friend and being the taskmaster and that's not easy. It takes really hard work to build trust and get a team to understand that you're looking out for the project's goals as much as you are them. Part of doing that is being an active member on the team. Like I said before, really showing an interest in the project and how it can be done successfully and contributing to its ideas. At the same time remembering that you're not the team's secretary. You're the person who's there to keep control of a lot of the project details but you don't have to be held responsible for managing people's personal calendars or setting up meetings for people. Make sure that you're focused on what's important which is the project, it's goals, and moving it forward. Project managers are consummate learners and teachers and by that I mean we're people who are always curious about what's happening in our industry and in our companies. So, it's always good as a PM to have a place to go where you can continuously learn about your craft. There are a lot of sites online. There are a lot of books that have been published and places where you can learn more about being a really good project manager. There are also conferences and meet ups and places where you can learn about project management and network with people within your community. At the same time, it's really good to take on the roles of a teacher in your projects and by that I really mean working with a client or a stakeholder to make sure that they understand how your team operates, what the level of effort is that goes into building or designing something. Clients were never trained to be clients themselves so, they need someone to help them through it. So, the more that you can teach them, the more that they can go into their organization and teach other people about the project and the type of work that you're doing and that creates a win-win situation because they end up looking good in their organization and you end up looking good because you're teaching them. Project managers are laser focused on goals. It's important as a project get started that you keep your goals in mind. There are going to be points in your project where things are complicated and typically that involves people because people tend to complicate projects. So, any time a new issue or question or scope creep comes into play, keep your eye on the goals, make sure that you're always questioning those changes and you're questioning whether or not that change will actually meet the goals. At the same time, make sure that you're keeping your professional goals in mind. It's good to sit down and document three to five short and long term goals to make sure that you're progressing in your career and you're moving in a direction that's going to work for you. Project managers are always honest because so many problems can happen in projects and we're responsible for those details. It's important that we develop a reputation for straight talk. So, anytime you see a problem come up, you have to address it immediately and that could mean that you have to handle a difficult conversation. It might mean that you have to communicate with someone really quickly and pull them into a conference room. You can't be scared of doing that. You have to be honest because you know that when you're honest, you resolve issues and keep project moving in a positive way at all times. A good way to be honest about the way you're working is to conduct retrospective meetings. As a practice, as a project wraps up, sit down with your team and have an open honest conversation about what worked and what didn't. It's not about finger pointing and getting someone in trouble. It's about resolving issues or identifying issues and coming up with a plan for how to fix them on future similar projects. Lastly, project managers are pathfinders. We don't just focus on a spreadsheet or a timeline or a budget. We focus on the strategic path for project and take into consideration our team, our tools, our process and everything therein to create a path that will get our project completed successfully. So, formalized project management might seem scary to some people. It feels rigid and really formalized but it's really embedded in everything that we do on a daily basis just as humans. Think about your life and the things that you do that require planning and management, things like making dinner, inviting friends over for a party, planning a vacation. Those are all activities that you do that you're actually managing in some way. So, a lot of what we've discussed here can be applied to real life scenarios as well as your work. 3. Project Management Methods: So far, I've talked a lot about soft skills in project management and those skills are really important. But it's also important to have a foundation and an understanding of formalized processes or methodologies that are out there. There are a ton of documented processes, all you have to do is a quick Google search on PM process and you'll find a lot of different crazy names for processes you can implement on a variety of different project types. For the purpose of this course, we're going to cover three main methodologies. And they're kind of the methodology that I've experience most in my career in digital. Those are: waterfall, agile, and hybrid. The first is waterfall. Waterfall is probably the one that people are using less and less today, because it's a little bit longer, it requires a lot of handoffs and sign offs, there's less collaboration and more silos within a team. It's really used a lot in product development and construction settings and a lot of more traditional project management settings as well. When thinking about the waterfall methodology, try to visualize an actual waterfall. It starts with one task at the top that gets completed and handed down to one person, that then gets completed and handed to the next person. So, there are a lot of points that essentially are dependencies. So, one task cannot happen without the predecessor completing. The waterfall method can be great for a lot of different project types, especially if you've got a fixed scope or a fixed timeline and requirements so that you know something must be done within a certain amount of time, with a certain amount of resources. It can also be really good when you're in settings that require a lot of client or stakeholder feedback and sign off, and there are people who are product owners who can't really be involved in the development of a product day to day. Waterfalls being used less and less at least in the digital industry because people are focusing more on being Agile and collaborating and working together to produce products more quickly. The tools used to manage waterfall projects are typically line by line project plans or get charts that can help you to navigate the steps of a process and the dependencies there in. The almost opposite process of waterfall is agile. You'll find agile being used mostly with internal teams who are really focusing on building products. In fact, it was first started and documented for product teams who could self organize, make decisions, and really prototype and rapidly iterate on products. So, Agile comes with a pretty formulaic framework for how teams should operate. Essentially, teams operate in sprints. First, they organize themselves around roles. So, on every agile team there is a product owner who determines the direction of the product, there is a development team who works on the product, and there's a scrum master, who essentially acts as the project manager and removes any blockers from the development teams plates. In Agile, teams will meet to plan a sprint, sprints are basically working time. So, sprint might be a two week iteration where a team is dedicated specifically to user stories or features within the project. So, they'll meet at the beginning to plan out what they're going to do in the sprint, and then they'll meet at the end to demo the work that was done on the sprint. You'll see a lot of agile teams working with Kanban boards, and by Kanban board I mean essentially a board that will list features or stories across the top and they're kind of in swim lanes that can be moved from one lane to another. You might be familiar with tools like Trello, Pivotal, Tracker or Jira. The place where agile breaks down is when a team isn't able to actually operate and complete the product or project on their own. When maybe a stakeholder in a company comes in and wants to give their opinion about the direction or the way that a product is forming. There's been a recent shift in the way teams work and they're being more agile and you find that happening more within products companies and startups where teams can actually own their work and make decisions on their own. It doesn't work as well when you're in an agency working with a client because of the decision making aspect. But there are ways to combine agile and waterfall to make a process that is a little bit faster or less dependent on the handoffs and more collaborative. The hybrid methodology takes the best aspects of waterfall and agile and creates a process that's flexible and adaptable to your projects, to your team, and to the clients that you're working with, no matter the scenario that you're working in. You could be working in a products company, you could be working at an agency, you could be working for an internal team at a corporation, and you can develop a hybrid method that's going to work for you. By that, I mean that there can be aspects of the project where there are explicit handoffs because there are decisions that need to be made maybe that's around design or look and feel of something or content, but then there can be sprints or quick iterations on things and that might come in when you're in development. The best part about the waterfall method is that it allows you to stop and do a gut check on the work that you're producing. So, if you need to gain feedback or make changes or course correct along the way, waterfall works for you. The best part about Agile is that you get to group tasks and move a little bit more quickly after some of those waterfall like decisions are out of the way. The hybrid method works when agile or waterfall are breaking down in places. Those might be when you have to conduct research or discovery on a project and you can't work in sprints, or when you're developing UX design and graphic design and you need the input of stakeholders or clients. There are a lot of different ways that you can approach the hybrid method, you can start development earlier, you can combine development and design. There are different ways of layering in tasks depending on the people that you're working with. So, that's where the flexibility and adaptability comes in. You get to try and test new methods within the hybrid method that will help you get your project done more quickly. I'm going to use the hybrid method while doing a demo of a project plan in team again. The reason I want to use the hybrid method is because you'll be able to pick up fundamentals of both waterfall and agile and figure out how you might be able to adapt both of those to make your own hybrid method. When you're trying to decide on which method to use or what process to follow, think about these things: Your project, what are the goals? The deadline? The scope? How is your process going to impact that? Your team, what is their expertise? How do they prefer to work? And how will the methodology actually work for them? Then your client, what are they used to? What are they comfortable with? Can they take on the product ownership role? Do they work in a more agile like methodology in their internal or in-house teams? What are they used to? 4. Collaborating as a Project Manager: The demo that I'm going to walk you through is for a typical website redesign. So, something that goes from the very beginning stages of doing research and understanding stakeholders and their needs and business goals as well as users and their needs and goals for a website, everything through designing and developing the website as well. So, that's the box creating a website. Before I jump into TeamGantt, it's important to think about the things that will contribute to building a good project plan, one that considers everything including your project goals and deadlines and budget as well as your team and their expertise, and your clients and their availability, and input or partnership within the project. It's important to not just jump right into a tool because again project managers think with their minds not with the tools. So, what I'm going to do is share a collaborative process that will get you from understanding your project through to managing the project plan. First, I'd like to start with research. So, if you're a PM who's on a team who's conducting some discovery, try to sit in on their stakeholder interviews. Find out the intentions of the people on your client team, understand how they're going to interact with the project and how they want to be involved. That's going to give you background information from your planning so that you can account for time-off meetings that the client might have, ways that they might interact with the projects or not interact with it, so you can understand who the decision makers are going to be, so that you're pulling them in or at least prompting your clients to have those people pulled in at the right time. After I understand everything about a project, I sit down and just think about it, and do a little bit of a sketch on what I think the plan will look like. Sometimes that turns into, me sketching out a calendar view and where deadlines are going to fall. Sometimes it's just the list of tasks. No matter what it is, the idea is to start with an idea that I can then bring to my team. As a PM, you don't want to dictate process or deliverables, you want to work and collaborate with the team so that they're invested in the process and it will help you manage the project better. So, starting with an idea, go to the team, present those ideas, and talk about ways that you might adapt it or are different ways that you might deliver on the project. That will help you to come up with a plan that's going to work well for everyone. After I sit down with the team, inevitably, something will change and I'll have to make that change in an actual project plan. So, that's when I'm going to sit down with TeamGantt, start plugging in tasks, finding deadlines, and making sure that everything's playing out the way that the team intends it to, but it is also meeting the deadline. Nine times out of 10, after I get every task in the project plan, the deadline is two weeks over and I end up having to make changes to fit within the deadline. So, after the complete plan is done, I'll then go back to the team and tell them about the assumptions that I made, the things that have been changed, and make sure that they're comfortable with dedicating themselves to the way that we're going to run the project. From there, it's all about communicating with the client and helping them understand what the project plan means, pointing out things like groups and tasks and when things are happening and how the project plan is laid out is really important. It's good to sit down and do a line-by-line walk through, but also remember that nobody is ever going to remember the details of the project planned the way that you are. So, going back, maybe at the beginning of a phase or at the beginning of a task and reminding on status reports how process is working, how things will happen and how you intend for other people to be involved is really important. Then when the project is in play, it's really just about managing and updating. Anytime something changes you have to make an update to your plan. That change might mean that there is a change in the deadline or a change in the process and you have to be accountable for communicating to everyone about those changes. You can adopt that process any way you like, in a way that really will work for you and for your team. But the most important thing is to understand your project, your clients, your team, your stakeholders, and making sure that you're taking into account all of the things that are going to guide the project in the right direction. Now, that we have all that information we're ready to jump into TeamGantt and start formalizing our plan. 5. Setting Up Your Projects in TeamGantt: So, now that I've got my ideas on how the project is going to work and I've had my conversation with the team, I'm ready to jump into TeamGantt. On my side, I've got my notes that I took to the team, and basically what I've laid out here is essentially how I picture the process working. So, I've noted who the people on the team are, what the steps or groups will be on the projects, and what the deliverables will be, and how long those things will take. So, I basically can take this sloppy scratch notes version of what I imagine the project plan to be to the team and have a conversation about what I think will work, and they can contribute ideas and essentially we'll come up with a process together. So, essentially, I'll take these notes and use them to help me formalize what I think the project plan is going to look like in TeamGantt. So first, I'm going to open up TeamGantt and create a new project plan. So, as you can see, you can import a CSV or duplicate an existing project. So if you've done something similar, TeamGantt will create a template for you which is really great. I definitely let people know that they should be wary of using templates because those come with past steps and people so you have to be careful. I like to start with fresh plans, so let's create a new project. So, this one is going to be our Website Redesign. Let's see. Let's make it version one. We're going to use the basic template that comes with TeamGantt and we're going to set the schedule. This is really important considering the working time that your team is working in. So, I'm used to working 9:00 to 5:00, 8:00 to 6:00, Monday through Friday, but some teams work Saturdays and Sundays. So using this functionality, you can block out the days that you won't use. So, click on save new project, and it will bring us to our fresh and clean Website Redesign project plan. So, as you can see, TeamGantt will start with some basic groups of tasks and tasks included. Like I said, I'm going to start fresh so it's easy to just go in and delete those tasks. Or if you want, you can go in and just click on the task to actually rename them. So, that's we're going to start with. So, in my notes, I have that we're going to start with our research phase. So, essentially, what I'll do is start by entering what the overall larger groups of tasks are going to be on the project. So starting with research, can key that in, simple, and then as the task are in, then I can just start entering them. So, essentially, I'm thinking through on my notes, what are the things that our team is going to do? So first, we're going to start with stakeholder interviews, so I'm going to key that in. Right now, I'm really just focusing on tasks, I'm not focusing on the length of time those tasks are going to take, I'm really just trying to get all of the steps in so that I know that I'm accounting for everything. So, I'm going to add user interviews, and then I'm going to do a competitive analysis, and these steps are going to be essentially tailored to the way that your team works. You might not take all of these steps in a research process, you might not even do a research process and that's okay, but these are all of the steps that my team would normally take in research. Then, we would probably write a creative brief, and then client review of creative brief, and then approval of creative brief. So when I check my notes and make sure that I got everything and I already know that I missed something, so one of the things that we'd do is a kickoff meeting. So, I'm going to add the kickoff meeting in here, and that typically does not happen at the very end. We'd usually do that somewhere right after the analyses are done before the brief is written, so I can easily drag and drop this up there and it moves the kickoff meeting to where I want it to be in the sequence of events. So, it's really simple, as you can see, to add a high-level task or a phase, so this phase of my project is the research phase that I'm adding all of the tasks and underneath of that, and I'll continue to do that for the rest of the project. So now, I have all of my tasks and then it let me run through them at a really high-level. So, the overall phases or groups of tasks that I have in my project plan currently start with discovery, so everything from stakeholder interviews and research through to a client approval on a brief. So, we're getting consensus essentially on what the project will be and how we'll execute it. Then directly, we move straight into our UX phase. So, essentially, we are creating a sitemap and delivering it and getting some client feedback on that. Again, this is where the more waterfall-like version of a project comes into play. We're accounting for creating, delivering, probably within that delivery, there's going to be a meeting that I'll have to schedule, and then some client feedback. In the assumptions in my notes, I put a three-day review for clients. So, that's a step that I'll definitely need to take into account when I'm planning and actually using the start and end dates of the Gantt chart functionality in TeamGantt. But for now, I've got all of my tasks in. After the UX phase, we essentially have a wireframe approval. Again, this is the more waterfall-like version of the project. I can't move into design without an approval on the wireframes. I might try to play around with the dates a little bit if my deadline is going over knowing that I could probably start working on a mood board before I have all of my sitemap and wireframe approved. So you see here, I've got a mood board, client feedback, again, a revision to that, and then essentially some design of pages and elements. So, the idea here is that we're establishing a high-level design so that we can then move straight into development and have designers working with our developers to build out the functionality of the site. So, this is where things get a little bit more hybrid, a little bit faster, and we're stacking some tasks in a way that makes it feel like we can move a little bit more quickly. So, this is where we get into the more agile part of the project. So, I'm thinking that we start with what I'm calling a sprint 0. So, this sprint 0 is where our developers are doing all the content management and technology set up. So, this is work that they can probably do before there is a formal hand-off of design, but it's something that I don't want to forget about. Then, I jump into sprints. So, people don't typically use Gantt charts for managing sprints, and I wouldn't use just the Gantt chart to manage the sprints either, though, there is great functionality within this tool to be able to list out the potential items that you might include in a sprint. The idea with agile is that you have to be a little flexible. You have to estimate what might be done within a sprint, and you might not always complete all of that work. But because this is a hybrid project and my client does have a deadline, I know that there's a limit to how many sprints I can do based on the deadline that we have for the project. So as you see here, I started to mock and sprints. Essentially, what I'm going to do is just create a two-week deadline for each sprint, and in that are essentially tasks that I think that are going to happen within those sprints. Now, let's say, for instance, we get to the end of sprint 1 and the homepage has not been coded, that's okay. All I need to do is move it down to sprint 2, probably update my sprint 2 title here, and proceed. It really needs to be easy and flexible, again, with a more agile-like methodology. You're more concerned about iterating and estimating work and trying to get as much done within that two-week sprint. If it isn't done, then it gets pushed out. That's where you have to pay attention to your scope and timeline because if things start to push, you might hit a bottleneck. So as you can see, what I've done here is I've built in a Beta. I like to set a deadline for when something could be launchable. So after sprint 3, I've got a Beta where we're doing some QA and then a launching essentially all of the functionality that we've built from sprint 1 to sprint 3. So, maybe our site's not really alive, but we're launching something and proving that we've got at least a tangible product almost complete. After that Beta sprint, then we're jumping right into sprint 4 to continue some of the integration and additional development work, and then we're going to do sprint 5 as essentially all testing. So, in this methodology, I'm building in some user testing. So, essentially, this is a little bit of a waterfall process within a sprint that I'll definitely mock out when I'm building out the timeline. But essentially, that gets us to a final sprint, sprint 6, where you can see we're working on final changes and then working on QA and an eventual launch. So, that's the overall view of what the project looks like and the steps that we're taking in the hybrid process. Again, you can change these sprints the way that they operate, the way that they work, the pacing of them, all of that is really up to you to design in terms of process with your team. You have to do what's comfortable for you and what you think is going to work. 6. Utilizing Your System: So, now that I'm comfortable with all of the tasks and the pacing of those tasks in the project plan view, I'm going to start thinking about the people who are involved in the project and who's taking on each task. So, in TeamGantt, I can take a look at my tasks and go in and assign people to the project. So, currently, I've got my project team in, and I know that Nathan is going to lead research. So, I simply can click-off Nathan's name, I could put in the hours per day that he works and the estimates for what he should be working on that project here. But for now, I'm just going to assign Nathan, so that I know who's responsible for the task. Simple as that, Nathan's name pops up, and he'll show up in the Gantt chart view as well. The other thing that I can do here that I really love is setting expectations about what is going to happen within each task, so essentially setting expectations around scope. So, here, there's a comment section in TeamGantt. So, I can go and add a note and I'd probably add a sticky note here that says "stakeholder interviews: 12 total, 8 minimum." So, essentially, what I'm doing here is saying to someone, "This is how much time we've scoped for this. Let's not schedule more than 12 but we have to do at least eight." So, that just sets the expectation. There's no questions about how many we're doing. I like to do this when it comes to design as well. So, if there are expectations to be set about how much we'll design or how many concepts will be designed, those notes will go in. I like for the team and the clients to see those notes, so that it's really, again, transparent about all details regarding the project. So, then, once I've got all of my resources assigned to all of the tasks based on the conversation that I had with the team, I'll then go in and start scheduling how long I think it should take to get things done. So, in this first task for stakeholder interviews that Nathan is taking on, and one of the features that I really like about TeamGantt is that, you'll see this bar, color has changed because I've assigned Nathan to it. So, there's a nice visual cue for Nathan when he comes in to look at the plan to see which tasks are his. He can scan the Gantt chart, look for that color green, and know what he's responsible for. So, I can essentially just start adding in lines on our Gantt chart to illustrate start dates, which you can see here at the top, and end dates as well. This is really important when it comes to project planning because it's all about calendaring. So, you can see I've started to add a few in here. Another thing to point out that's really important is that, within TeamGantt, you can set parameters on what your line items or tasks are. So, you can see that this kickoff meeting is a milestone. What is a milestone? A milestone is essentially a point in the project where an important decision or delivery is going to be made. So, a kickoff meeting is essentially in our more waterfall-like plan, a point where all preceding tasks must be complete. We have this milestone once that milestones complete. It's a major point in the project where we can move on. That's a big point in the waterfall process. So then, you can see I've added more tasks here. Essentially, I've added a client approval on the 26th here, but what I want to do is that's a major milestone as well. I'm going to convert that task to a milestone. So, again, there's a nice visual cue that points to essentially, the end of a section in a project. So then, as I move into creating the sitemap, I know that in this waterfall portion of the projects, I'm going to essentially schedule tasks after that milestone date. So, my sitemap creation is going to start on the 27th, and based on what my team and I have discussed, it's going to take one week to complete it, so it will be finished that Friday. I haven't added the resource in here yet, so I can go and do that now. JSON's going to do the sitemap. That's basically all we need to share there, and it's created our start and end date. It's really simple to add tasks and drag them. Like I mentioned before, if you typed in something improperly in terms of the order of things, it's really simple to drag and drop things from one place to another. Because we've been talking a little bit about methodology and process, I want to talk about how I set up sprints within this hybrid process. So, the way that I'm going to use sprints within a Gantt chart, which is not necessarily a typical way of doing things. Like I mentioned before, the sprint methodology lends itself really well to tools like Trello, and Jira, and Pivotal Tracker. TeamGantt also works really well to give you a high-level picture of how sprints can be mapped out in a project, and then you can use a more kanbun-style board to actually manage the tasks within a sprint. So, what I've marked in here are some ideas of what would happen in that sprint, and I'm naming the sprints based on those ideas, which to me, makes sense because I know that I'm thinking through all of the things that our team will have to build. You can see, I'm not necessarily dictating that any specific task takes a number of days. I'm simply showing these are the tasks that I've got built into our sprint, and this is how long it's going to take. Because I've discussed with the team how we're going to manage sprints, and we know that they're going to last two weeks long. So, each sprint essentially should be dependent on the last sprint ending, and we plan them for two weeks. So, after you've added all of your people to your project and your start and end dates and you've got your Gantt chart partially built out, it's a good idea to go back through and think about what the dependencies are. So, when I talk about dependencies, I mean the things that must happen in order for a follow on task to happen. So, an example of that is right here with our kickoff meeting in our strategy brief. So, like I mentioned before, in terms of process, my team's not going to be comfortable writing a brief until we've had a kickoff meeting with the client to discuss all of the findings that we've done in the initial steps of the project. So, essentially, what I'm going to do is just add a little visual cue in TeamGantt to show that there is a dependency. Adding a dependency in TeamGantt is really simple. All you have to do is click and drag one task to another to show a really quick identifier. So, a really, really simple way and simple functionality for a really important part of your project plan and identifying how things happened and the pacing of how things happen. So, I recognized that this demo doesn't give you everything that you need to create a project plan in TeamGantt, but it gives you the fundamentals: adding tasks and groups, making the project plan readable, adding people to those tasks so that they can identify what tasks they're responsible for, adding notes and clarifications around dependencies, and also scope in your comment section are all things that can help you to create a great project plan no matter what tool you're using. I do recommend you check out TeamGantt. There's a lot of functionality that we haven't explored here today in terms of time tracking, resourcing, and like I said, they're adding the functionality of the konbun board, which is going to be really great. So, because this demo is a live demo, I want to show you a fully-baked project plan that I built in the past. So, this is a plan that I built to go along with TeamGantt's guide to project planning. It's, again, a fake project, but it gives you a sense of all of the things that might be happening in one project and it's something that you can access online through the TeamGantt website. Again, this shows you groups, so we've got project research and discovery, a project brief and a project plan creation. We've got even further breakdowns on actual deliverables, so you can see a sitemap, wire frames, content strategy. If you're building a website, this could be a pretty good template for you to pick up. You'll also note that there are signifiers here. Sometimes, when I'm creating plans, I like to add the initials of the company or the person who's responsible for each task. Again, just to make a plan like this a little bit more readable. You can also take a look at the Gantt view and all the beautiful colors that it produces. You can select those colors in TeamGantt, and again, helps you to signify who's doing what and when. So, I think this is a pretty good example of, again, another hybrid approach. It's not the same as using sprints, but it is similar in terms of how design is being done and how development is being done, so the batches here are simply sprints, just a different use of terminology. But it's pretty complete, and it shows all the steps you might need to take to actually complete or launch a website project. So, once you're done, your project plan in TeamGantt, it doesn't necessarily mean you're done with it. Project plans are living and breathing documents that you always have to keep an eye on as a PM. So, what I like to do is, do a weekly check-in on my plan and make sure that I'm keeping up with all of the tasks that are happening and reminding people appropriately. An important thing to consider when you're making updates is this percent complete column. You can see here, I've marked all of the things in my project research and discovery as complete. As I'm managing the project and I know what's happening on the project, I'm checking in with the team to get a sense for how far along work is. So, at any point, I can go in simply and just mark an estimate of how far along I think something is. I love this functionality because then, I can use that functionality to pull into my project status report to be very clear about updates and progress on a project. Another thing to really keep in mind as a PM is that, managing and updating your plan doesn't end with you. You have to be a really good communicator. So, as something changes, as you move a task, as you complete a task, as you delete a task, no matter what happens on your plan and the updates that you're making, you've got to be transparent about communicating those changes and what the risks or issues are that come along with completing those changes. Like I mentioned, there are many different ways of doing this. I tend to use TeamGantt, I tend to use a List View. A lot of project managers use to-do lists in order to keep tasks on track. There are other ways of doing this that are not as formalized. Some people use white boards. Some people use sticky notes and boards that are just on a wall in their office. It really just depends on your approach, and your personality, and your style, and what your team wants of you and the plan. What's most important is, to think about the things that we talked about here when showing the demo. So, overall, tasks and groups, accountability and assumptions that you're making about turnaround times, sprints and how they're managed is a whole other topic that you should think about, and really just making sure that you're considering all of those things as you create a plan, no matter what it looks like. 7. Communicating as a Project Manager: So, we've talked about some pretty high level characteristics and principles for project management. I've shown you how to build a project plan using a tool and a process, or creating a process around building that plan. Now, I want to talk about the things that will really kind of round out your skills as a project manager, and make you lead projects a little bit better. That all comes back to communications. As a project manager, there are a lot of points in your project or in your process, where you're able to set expectations and then manage them. When you sit down to start a brand new project, it's important that you really get everything out on the table. Make sure that everyone on your team including your clients, understand the scope, the deadline, and the goals of the project. It might be a good idea to sit down and discuss a contract if you're working from a contract or a creative brief. Whatever that document is that is guiding the way that a project should be and what success means, is something that you should get out on the table and discuss immediately. You also want to talk about the roles of the project. So, when I sit down with my team and I've got multiple people on the team producing multiple different deliverables, I want to sit down and really define what each deliverable is and who's responsible for it. A tool that you might be interested in looking up or using is a raci matrix. So, it's R-A-C-I, and essentially a raci matrix is a tool that can help you to really sort out tasks and deliverables and responsibility within those deliverables within a project. So, essentially you list out all of the people in your project, you list out all of the deliverables or tasks, and then you score each one dependent on who is responsible, who is accountable, who is consulted, and who is informed. It's a really helpful tool in really helping to establish expectations on who is going to do what. You also want to sit down and talk about how you'll communicate as a team. Not every project team communicates the same way because people tend to communicate in different ways and different teams collaborate and work in different ways. So, establish your best practices in terms of the tools that you're using to help you communicate. Establish best practices in terms of how you're going to meet daily, how you're going to check in on progress, and how you as the PM will sort of wrangle the team and help them to communicate better. Another tool that's really helpful in managing expectations is a regular status report. I usually recommend the project managers write a status report on a weekly basis. Your status report should include these things: It should give a high level overview of what's happening on the project. So, what happened last week, what's happening this week, and what's happening next week. So, essentially you're pulling in items from your project plan that are showing you the tasks that are being done. Then you want to take a look at your to do's. So, to do's don't have to necessarily be all related to simple tasks in your plan, but they might be things that you need from your clients, or decisions that need to be made or schedules that need to be put on calendars. A simple table that lists a to do and a due date and a person who is responsible for that to do can be really helpful in organizing those thoughts. After that, you want to list an update on your budget and your timeline. So, simply taking out of team again, your percent complete based on your updates that you're making to your plan, you can give a pretty quick read out on what's happening phase by phase or at a high level percentage complete on what's happening in your project. Then, if you want to be really transparent about your budget, you can let your team and your clients know how much of your budget you've spent and how you're tracking on it. The last section of a status report is arguably the most important one, that is your risks section. In that section, you want to have a simple list of any possible issues that might be coming up on your project. This is the hard work that you have to do as a PM. Is kind of thinking through next steps and what might happen on a project and what might go wrong. It's important when communicating, like I said earlier, to be very clear and transparent about issues. So, the more you're thinking about them and you're putting them in writing and discussing them, the less apt they are to happen in the future. So, just be really clear about what those risks are, what the outcomes could be if they're not resolved, and keep track of them week over week. And that really summarizes a pretty good status report. It's important to keep your finger on the pulse on what's happening on your projects at all time. A good tactic to understand and know what's happening with your team on a daily basis, is to conduct a regular status meeting. So, you can conduct a 15 minute, 10 minute long meeting where you all meet and talk about what you're doing. Go around the room, and have everyone state what I did yesterday, what I'm doing today, and any blockers or issues that might be in my way. This is a really good way just to get information out and in the open. It's a good way of establishing better communication and collaboration practices because one person might bring up an issue or a problem that someone else might be able to step in and resolve. It's just in general, a really good way to get your team on the same page and communicating and kind of building a really good atmosphere in terms of just teamwork. An added step you might want to take to keep communications flowing and open and transparent, is to also conduct one on one meetings. They don't have to be formally scheduled meetings. They can be kind of stop and chat situations where you're just checking with your team to see how things are going. I also recommend very often that people sit down either for a lunch or in lunch and learn kind of situations with their team, just to check in to see how they're doing, project information aside, just how they're doing personally, what's happening in their life. It's really all about building relationships with people, understanding what makes them tick, what motivates them, and really helping them to meet goals, not always putting the project first but understanding that a project can't get done without those valuable people really participating and giving it their all. I have found it really valuable to sit down with someone and just ask them what it takes to do their job, what they like about their job, what they like about projects, what kind of projects they like to work on. Those kind of motivators, give me kind of cues or ways to communicate with someone or know what they're going to be interested in, which I think can be really valuable in situations when I know I have to ask them to do something difficult that they probably aren't going to want to do. It's not used as a negative way or kind of like a backhanded way, it's just a way of adapting my communication style to theirs and really just like building that relationship so that I feel comfortable in asking them some of those difficult things and feel good about the work that we're doing together. 8. Communication Case Studies: There are a lot of opportunities for things to go wrong on projects and like I mentioned earlier, we thrive on chaos. In those situations, it's not always easy to know what to do. So, I thought I might share some real life scenarios that I've experienced on projects, probably things that you might experience on projects as well, as well as some outcomes and ways to handle those issues. The first of those issues is handling or managing scope creep or change on your project. So, client comes to you, you've delivered. Let's say you've delivered a website and a feature that you think is great. Client reviews it, they come back to you and say, "That's not what I expected you to deliver." That can be a problem but you can always solve that problem especially if you've got something like a contract or a requirement's document in your back pocket. Think back to that first meeting and how you set expectations for what would be done on the project. Do you have a requirement's document? Did you review a scope? Is there a way that you can point back to what you would deliver? If there isn't, chances are you probably have to give in and make that change without changing the scope of your project. Though you might have to consider the deadline because when you have to rework, timelines change. The other thing you want to think about when change comes into play is project goals. So, if they're asking for a change, does that change actually meet the goal? Is there a reason to accept that change if it doesn't meet the goal? That's a conversation that you can have with your clients, especially if something feels like it's definitely out of scope. The last thing that you can do is sit down, think through what the future is, and what it's going to take to change it. So, sitting down, doing a quick estimate, understanding what the level of effort is, is going to tell you whether or not you can afford to make that change without a change request or if you need to add it in. If you do need to add it in, you can have a very quick transparent easy conversation with your client or stakeholders about additional scope or budget that's needed and the extra time that it's going to take. I'll say this, when you bring that stuff up, people tend to say it's okay, let's not change it because they don't want to lose time or money. The second scenario has to do with working with team members. A lot of times we can get really close to people and become friends outside of work and friends inside of work as well. But when somebody who you really like and trust and have invested a lot of time in, starts to drag down a project, what do you do? So, I've been in scenarios where people on my team start to really become disinvested in the project, not interested in what's happening and maybe they just don't want to do the work. That tends to bring down the rest of the team and I've been the person who's in the middle and has to handle all that. So, I'm hearing comments from other team members about negative things that someone's saying or doing and I have to address it. So, how do you do that? Again, another difficult conversation not always easy to address but I have a little bit of a formula for how I handle it. So first, thinking back to characteristics and principles, I always like to be empathetic and think about what that person might have going on in their life. So, before I address any conversation, I know that I don't know everything about the situation. I know complaints from one side, I have my own point of view and I have to stay neutral about it. So, I definitely like to think about what could be going on. Not that I'm making guesses, I'm just putting myself in their shoes. Then what I try to do is think through, okay, what could happen in this meeting? What could the outcomes be? Is this person going to start crying? Are they going to get up and walk away? Are they going to laugh at me? It's a weird thing, it's a difficult conversation and you just have to prepare yourself for the range of emotions or responses that might come along with mentioning something that is a little contentious. So, instead of really formalizing a meeting like this, I like to keep it informal and maybe just approach someone at their desk and say "Hey, can we go out for a coffee? Do you have time for lunch? What can we do to just to like have a good conversation?" So, usually I love to take somebody out for coffee. It's removed from the work setting. There's a little bit less stress. There are other people around. So, it's not going to get really awkward or contentious. Then when we sit down, I really just say, "So, I wanted to have a conversation with you about that thing." So, whatever that thing is. Being really direct and honest about what that thing is, is what I try to do in this scenario. So, not coloring it in any certain way, not putting any judgment or blame on it but just saying, "This is something that's happening, let's talk about it." Then I'd like to just sit back and listen. No judgment, just understand where the person's coming from, hear their side of the story and really talk through it. There's not really much direction I can give you for that part of the conversation but what I will say is when you're wrapping up, you need to walk away with a resolution or next steps. So, if you resolve the issue great, you still need to check up on it and make sure that everyone's feeling good about that resolution. In many cases, you might not have a resolution right away and you need to just take a break and come back to it later. You have to make sure that you're the person who follows up on that because you don't want any sort of contention between you and that person in the team or anyone else that's really going to affect the project. So, those are the steps that I take to handle difficult conversations. Hopefully, that's helpful for you. Another scenario that is common particularly in my world of designing websites is gathering feedback, and making sure that the feedback makes sense and is 'actually actionable. A lot of times clients will come back and say, John from marketing really loved it, Sally from IT hated it, and there are four people who didn't even respond with feedback." That sends up a huge red flag as a project manager because the minute that you have indecision on a client side, is the minute that timelines start to get stretched out and your budget starts to be wasted away. So, how do you handle that situation when feedback is inconsistent and your timeline is really starting to crash? The first thing that I do is set expectations about how you collect feedback and what good feedback is. So, at the beginning of a project or after you've presented a deliverable explaining to your clients how you collect feedback. Essentially, the best way to collect feedback is in writing in one tone of voice. So, you don't want all of Sally and John's comments in one document conflicting about the same designs. You want somebody to go through their feedback and put it in one voice, in one point of view that gives you really actionable steps on changes that they want made. That's the first tip. Second is to be really clear about your iteration plans. So, within the project plan that you've built and in the one that I've built for this demo, I had two iterations on the design. Meaning that, we would collect feedback twice and make design revisions twice and then finalize them for an approval. Being really clear about that plan really sets parameters for clients or stakeholders to make sure that they understand how long they have to keep tweaking the work that you're working on. If you don't set that expectation, you'll end up with 18 revisions and different comments or conflicting comments coming in from left field at the last minute. It's also important to be really clear about timing. Timing is everything when you're a project manager. If someone on your client team doesn't understand that they only have three days to get feedback, they'd better work out a plan on how they can get that feedback to you. Because a day delay on their end, doesn't always equal a day delay on your end when you're juggling multiple projects and multiple different people working on those projects. I have some additional tips for collecting feedback on projects as well. If you're a PM and you're part of presentations which I absolutely think you should be, you can play a really valuable role to your team. First, by setting expectations for what will be presented and how excited your team is to present it. As the PM, there are a lot of opportunities for you to set the tone for the project and how things might go. So, by simply saying, "Hey, on Wednesday when we come to present design to you, there's going to be three comps that we present and two designers created those comps and they're really excited to show you their ideas." That just sets the tone for how a meeting could go and it sets a positive tone for how the interactions should be in that meeting. So, when you're in that meeting and your designer is presenting concepts or whatever it might be, you as the PM should sit back and take note on what people in the room are doing. Look at body language, see how people are reacting. Are they being positive? Are their arms crossed than being negative? Taking note of that body language can help you to figure out who's missing feedback, who you need to talk to or win over in the next meeting or what feedback you might be able to refute and actually get away with it. So, just understanding what's happening in the room can be really helpful. Also in that meeting, you want to make sure that you're taking notes. Now, those notes aren't going to be your final feedback from your clients but those notes might help your clients to go through their own feedback and talk through points of contention. Anything that you can do to help push them along and their process along can be really helpful. So, meeting notes can be helpful in that case. So, after work has actually been presented and you're ready to take comments from the people in the room, it's good to present a few directional questions that can guide people on the right path on giving feedback. So, does the design meet the goals? Is the brand represented appropriately? Your designer can help you come up with all of the questions that they need to get the right feedback from clients. But just giving them that cue sets an expectation for what type of feedback is suitable in that case. Sometimes in those meetings conversations can get tense. If I were a designer and I spent 40 hours creating a mock up and somebody shredded it in a meeting, I'd probably not be happy about it. So, I understand that and I have empathy for the person who's making that presentation and really putting their work out there for critique. It's not easy. But as the PM, it's my job to keep everything positive and keeping conversations moving in a positive direction. So, making sure that you're keeping both sides in check with their comments and their responses and making sure that you're driving everyone toward a decision is the best thing that you can do in that situation. The last thing that you can do to set great expectations for collecting feedback is at the end of the presentation, talk about next steps. Again, talk about the iteration plan, talk about how you collect feedback and always put a date out there. When is the day that they're delivering feedback? What is your next step after that? Closing every meeting with next steps and action items is the way to go. 9. Wrap Up: Okay. So, we've talked a lot about project management. We've talked about characteristics and principles and tools and processes and ways to implement some tactics that will help you to keep projects moving. We've touched on a lot of things that should help you to be a successful project manager, whether you're formally in the role or you're just taking on the role because you've got to get projects done. No matter what you've learned, I hope one key takeaway is that project management is not a tool or a process. It's about being yourself and doing everything that you can to be a great communicator who's looking out for people and looking out for goals. If you followed along the demo and you want to share your ideas or example project plans, please feel free to share them in the project gallery. Thanks for taking this class. 10. What's Next?: