Welcome back to The Art & Science of Leading Projects. This class is all about project management methodologies, what they are, how they work, and how you can select or create your own. Before we dig in, I want you to think about how you work. Are you using a predetermined documented method? Are you following it by the book? Is it working for all of your projects? Are you bending it to make it work on your own? To be truly successful in project management, you have to know what it takes to get your project done regardless of a formalized methodology. That means you need to recognize that there's no such thing as a one-size-fits-all method because projects vary in size, scope, goals, deadlines, and so much more. This class is designed to help you understand the basics of the more well-known methodologies and to help you determine which are best for your projects.

If you're feeling really adventurous, you'll leave this class feeling empowered to explore your projects to create your own customized method that works not only for you, but also for your team and your stakeholders, because we all know that a well-rounded approach is the recipe for a great project's success. So let's start at the top. What's a methodology anyway? According to the Project Management Institute, a method is defined as a system of practices, techniques, procedures, and rules used by those who work in a discipline. Essentially, a method will help you determine how your team works together and how you deliver that work. Choosing a project management methodology is one of the first decisions you'll have to make as a project manager, unless it's already been determined by your organization.

There's a lot to learn about methodologies, whether you'll formally use them or not. When you use a formalized PM methodology, there's a lot to gain. You can receive training to help you understand how the methodology works and how to manage it properly. You can use tested practices that work well for other organizations, teams, and even individuals. You can use templates and guidelines to help you manage your projects, and you can gain the support of a community surrounding that methodology. Examples of those communities would be around the Scrum method or within the Project Management Institute. The Project Management Institute actually provides a ton of value to its members on everything from education to networking and even formalized process training and certification, and the same goes for the Scrum community within Agile. They have online resources, conferences, meetups, trainings, and so much more, but really, the best part about using a methodology is that you'll find a way to organize your projects, create routines and expectancy so you manage a little less chaos, and you'll have a ton of resources and support while doing it.

There are a lot of PM methodologies and they all have their merits. It's actually hard to say which of these are used the most because they're used in a wide variety of industries and project types. It's actually pretty amazing how the PM community has built up such a strong toolkit for managing projects of all types, and while it's hard to know which are used most, we definitely seem to hear the most about Waterfall, Agile and Hybrid methods. Waterfall is a tried and true method that's been used for a variety of project types, and Agile methods are certainly increasing in popularity these days. In fact, Agile's become a bit of a buzzword. Executives seemed to think it will make their employees more efficient, which it can, but it can also be butchered and fail miserably without consideration, mostly because it's misused or misunderstood. Because of those challenges and a desire to be faster. More and more teams are developing their own Hybrid methods. That's the term we use for when people combine methods to do what works for them.

At TeamGantt, we call the Hybrid method "Complete" because it's the comprehensive approach tailored to your project, and it allows you to complete projects efficiently and on time. You won't see these methods documented anywhere official. That's because it's kind of a just-do-it method where you pull from your own toolkit which might include some formalized methods, or you just make them up on your own. So let's dig into these methods. I want to explore at a high level how each of these methods works and where they work best. Knowing this stuff should help you to pick your own method, which we'll also cover later in this class. First up's Waterfall.

Waterfall is a traditional method for managing projects and one that's pretty simple to understand. Essentially, one task or phase must be completed before the next one begins in a connected sequence of items that adds up to an overall deliverable. The phases of Waterfall projects are requirements gathering and documentation, planning and design, building or development, testing, deployment, and support and maintenance. These phases include tasks and dependencies that are mapped out clearly so all involved parties understand the order in which the work happens, and that a handoff can occur to keep the project pace moving steadily. You'll see Waterfall employed on mission-critical projects that outlined finite requirements to be met. It's used far and wide and in a variety of industries including construction, manufacturing, IT, print design and production, and a lot more. It's a really great methodology that ensures you have all of your details covered.

The pacing of the work is properly mapped out, and team members gain an accurate picture of when and how they'll be working on a project. The focus is on documentation and shared handoffs, and that means that expectations are set early with requirements and solid estimates that can be used to define tasks, responsibilities, and overall workflow that makes feedback, decision making straightforward. Plus many Waterfall projects use Gantt charts to provide an easy-to-read visual plan. That helps with planning your team's time and keeping them accountable to specific tasks, seeing dependencies on tasks, estimating impacts when change occurs, and really just having a snapshot of overall progress. I've said it before, but Waterfall really is tried and true and has helped many teams successfully accomplish their goals. If you're looking for a clear start and finish and have what it takes to plan a linear project, Waterfall is for you. Check out the Waterfall method download for more details on the methodology. Next, I want to talk about Agile.

It was in the early 2000s that a group of thought leaders in the software development space decided that they needed a different way to release working software, so they put out a rallying cry to their industry with a set of values and principles on how to better deliver software. That's when Agile became a methodology, and has since been adopted by many teams in a variety of industries, but it's important to remember that Agile isn't a process as much as a behavior. It's an adjective, not a noun. Let's cover that first. By definition, Agile is a set of values and principles, not a specific way of doing things. The values of Agile are pretty straightforward. individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation and responding to change over following a plan. So really ,it's all about constant collaboration and iteration with regular deliveries of working software.

The principles and values of Agile are employed really well in the Scrum methodology. Scrum is the most popular Agile development framework because it's relatively simple to implement. It also solves a lot of problems that software developers have struggled with in the past, such as convoluted development cycles, inflexible project plans, delayed production, and little collaboration. In Scrum, the vision of the project and the priority of its features are determined by the product owner who is the closest to the product's goals, stakeholders and users. The work is done by the development team who are 100 percent dedicated to a single project and work in short cycles called Sprint.

Consider a traditional project manager. Instead, the team is led by a Scrum master whose main job is to clear away all obstacles to work getting done more efficiently. The scrub master also facilitates all of the Scrum ceremonies or meetings to help guide the team through the process. I'm going to give a high-level overview of those ceremonies that help to make up the Scrum process, but you should dig in and learn more about them on your own. Review the Agile methods download, or do some exploring on your own. Okay. Let's jump in. First, the Sprint planning. This is where the team estimates tasks or stories and determines what work they'll take on in the next Sprint, which typically lasts anywhere between two and four weeks with the goal of delivering a working product or at least the part of it. Next, this is the daily Scrum.

This is a daily check in where the team gets together to talk about what they worked on yesterday, what they're doing today, and if they have any blockers in their way. Then there's the Sprint review. This is the meeting where the whole team and stakeholders sit down to review or demo work done in the Sprint and get feedback or approvals. Then there's the Sprint retrospective. This is an important meeting where the team sits down to talk through what worked and what didn't work in the last Sprint, and they commit to making changes together to be better. And then of course, there's Sprints. Those are the core of the Scrum methodology and essentially are the spans of time the development team takes to complete a set of goals or stories. Essentially, it's working time and the ceremonies help to organize that work. Once they're through the cycle of a sprint, they start over and continue with the next priority.

Scrum is super flexible to continue to build on and improve products, particularly software. Agile works really well when you need the flexibility to deliver a project and continue to iterate on it to meet your desired goals, and it really works best under these conditions. When you have an idea, but maybe not a full set of requirements for what you're creating, when you've got a team who can be fully focused on one project, when you don't have to worry about dependencies within or outside of your project and your project can truly stand alone, and when you don't have to deal with management who wants clear timelines with distinct phases, tasks, independencies outlined. There's truly a lot to consider with Waterfall and Agile and whether or not they'll work for your projects, and only you can decide whether they'll work for you or not. I encourage you to dive in and figure out what will work for you and for your team, and consider using the foundation of what you've learned about those methods, and combine them with the principles and practices that make your team successful. After all, you have to do what's right for you.

Selecting or even crafting your own process is all about saving time and making really good decisions about how you work. For some, Waterfall's perfect because there's a set deadline for requirements and a stakeholder team who will follow expectations for reviews and approvals. For others, Agile's perfect because there's an idea for a project, but no real boundaries or requirements, so the team and stakeholders are open to experimentation and iteration, but then there are constraints to consider within the methods that could make your stakeholders feel uneasy, or simply just won't fit with the project or the way that you fundamentally work as a team. For instance, I've often heard that Agile feels too rushed, and sometimes too heavy with meetings, or that a team just doesn't have the luxury of being assigned to only one project, or even worse, the values of Agile aren't aligned to an organization, so it's really difficult to make it work.

But guess what, that's completely fine. Not every documented method, tip or tactic or template will work for you. It just means that you should take what you've learned and adapt it to your own needs. You have to figure out what's gonna work for your project and craft a process that's tailored to the way that your team works. This is where the Hybrid method comes in. Many teams and organizations have used their own methods from the start, and while many large organizations are investing in Agile transformation, others are failing and finding it hard to implement. So there's a trend in organizations to combine methods rather than pledge allegiance to PMI or the Scrum Alliance. I think we'll see even more of this in the future, and you know what, I like making my own process because it means I can sort through what's gonna work for my project and it's related deadline and scope as well as my team and stakeholders, and I know that when I can do that, things are just going to work more smoothly.

I'd never say it's going to be perfect, but when a process feels tailored to the project and the team, it just feels right. But how do you craft your own process? Before digging in, I warn you that it's not easy, and it takes a lot of knowledge, experimentation, patience, and the ability to make and accept failures and move on. There's no simple way of teaching anyone how to craft your own process. I think you're off to a good start because you're taking the first step to immerse yourself in and educate yourself on the variety of methods out there. Part of that evaluation is thinking through what would work for you, so be sure you keep that in mind when you're listening and reading, but also know that you cannot do this alone. You have to evaluate a lot of aspects of your work and arrive at decisions with your team.

After all, they'll be working in the process too. You may be excited about the idea of creating your own process, but wondering where to start. I'm going to say it again: before jumping in, you have to know and accept that there is no process that works for all projects, so start your process by collecting and documenting the different types of phases, tasks, deliverables, and tactics your teams take on. Think of it like your toolkit. You've got tactics that work well, and maybe some that don't. You know what you typically employ, but you want to look for different ways of doing those things, so think about what's working and what could use some improvement. Point out the pain points and discuss how you can improve upon them, and when you're ready to start a new project, take a look at those factors of the projects to determine what might work, and even have an open discussion about it with your team.

Essentially, you'll look at the project and the people, so let's dig in on that. First, look at the project. You'll want to evaluate a few things, starting with your project type. If you're building a physical item or structure like a building or a bridge, planning an event, or doing something that requires a more stepped-out workflow, you're likely going to go Waterfall. If you're working on software or a website that can be continually modified, you're likely interested in more Agile methods. Also, look at the size of your project. If it's a really large undertaking and has a defined deadline, or if development is just a part of the larger project, you'll want to use a more traditional approach. Agile is definitely better on smaller, more iterative projects like prototypes, maintenance, or even updates to existing products. Here's a simple example that I think might highlight a process miss, or maybe even start a debate.

Remember the launch of the Affordable Care Act website around 2010? Most Americans know that project ended up as a disaster. There was a large project where everything had to work on a particular day, which happened to be the day that open enrollment started. That team used Agile methods, and it didn't launch on time. Now, the methodology might not be the reason why it didn't launch, but there's probably a case to be made that because they had a deadline and a clear scope, they should have used Waterfall or even a Hybrid method. Another aspect of your project to examine is your budget. If it's small or finite, you need to keep activities constrained. That could mean you need less meetings, defined requirements upfront, or even a smaller team if you need to pull it off. If it's a huge project, you'll probably want to break it down and plan things out more.

Then there's the timeline. If it's a longer project, you'll have more flexibility to experiment with process, but if there's a strict deadline, you'll want to make sure you're making the right decisions about timing needed to complete tasks, and pay special attention to how you're handling reviews and feedback because when that time it goes off track, you'll either have to squeeze more work in or extend the deadline. Timeline and budget are very strong constraints on projects, and knowing these things will really help you decide on what you can do and what you can experiment with. Next, look at your team. What is the experience level of the individuals on your team? Can they self-organize and make progress without you checking in often? Also, are they trained in any methods or have specific preferences about the way that you work? There are a ton of Agile trainings out there, and any expert will tell you that not just the PM should be trained.

In fact, a whole team should be, because Agile is a way of thinking, and it needs to be learned by a whole team. Also, are your team experience collaborators who are going to work well together, or do they work in disparate departments or organizations making it difficult to communicate or collaborate? And of course, are they dedicated to the project? If they're not, how stretched will they be across other projects, and essentially, if they look at the job of the project manager as a babysitter or secretary, they're not going to be able to self-organize. Also, you might want to reevaluate your role if you're the PM and your team sees you that way. Finally, consider your stakeholders because they can completely derail your process. You need to keep in mind that your stakeholders likely don't care about your process at all, and that means that they can and sometimes will do whatever they want when they want throughout the process, unless you educate them and get them truly invested in the project and the way that you work.

Of course, you might get great stakeholders who do care about things, but chances are you're always going to have to do a lot of education and leave room for error and change, and sometimes rework, and probably some meetings to help get them up to speed and on your side. But if you do have good stakeholders who can be engaged in the project, try Agile approaches. If you know that they won't engage, lean on more traditional stepped-out approaches so you can formalize critical decisions and milestones that build up to approvals, or at least put a lot of thought into the review and revision process and how they can impact your project overall. But let me warn you, it can be really tricky to make Agile methods work when you're working with stakeholder groups. When I worked for a digital agency and lead the project management department, I got a lot of urging from our lead developer to adapt more Agile methods.

I'd been through Scrum training and certification and knew that while our tech projects were a good fit for Agile, the fact that we worked with paying clients who often held up projects due to feedback or indecision, it would be a bit of a challenge. So I scheduled a call with the Agile trainer and the developer, and I had the developer explain the desire and project scenarios to the trainer, and immediately the trainer said, "Working with a group of stakeholders will make Agile very challenging for you." So we looked at what Agile method's development team desired, and figured out how we could work it into our stepped-out process that included key milestones and decision points, and it worked really well. And since then, it has been refined and refined again, which is always what happens with a Hybrid method. What it all comes down to is that you have to be able to take all of the details in, analyze them for the right fit or method, and be willing to try new things.

Make sure you rely on great communications by talking through your process and options with your team and maybe even your stakeholders. Draft a plan and review it with everyone and make sure you get commitments from everyone involved, and most importantly, be open to change. If things are not working, make adjustments on the fly and be open about that change. The best teams do this, and they end up working well together on really successful projects. So you might be wondering what some of these Hybrid projects would look like in an actual project plan. Let's take a quick look and feel free to explore them more in the class downloads. I'm going to show you just how easy it is to manage a Hybrid plan using TeamGantt. Like I've already said, there's no one-size-fits-all approach, so using a combination of the List and Gantt views and TeamGantt as well as task assignments and the upcoming board view, you'll be able to manage just about any combination of Hybrid methods, and gain a really clear view of what your team's working on across a number of projects, so let's jump in:

(Screen Share) What you're looking at here is a sample project for the redesign of the website. I have myself assigned as the PM and researcher. I've also assigned a design team, a development team, a video team, and the marketing team to be involved in the project. The Waterfall portion of this project really lies in beginning where you can see the team working through some initial research and a project kickoff. It's really tough to do any kind of research in Sprints, especially when you have to rely on scheduling interviews with large stakeholder groups or even users who have to be recruited in. So we're going to start here with a Waterfall process, and then we're gonna jump into Sprints, and I'm just going to scroll down so you can kind of see what the project is doing.

There's a lot of flexibility in adding tasks to your plan. As you can see, while the second part of this plan is mostly about Sprints, I've added another section here, and it's a Waterfall portion of the project as it relates to video tasks. So these are tasks that are part of my overall project, but they take on a separate track on the project outside of the sprints, but at the same time, they also rely on some of the work done, so I've scheduled them here to show what will work will happen at the same time as the sprints. This is a big benefit of using a Gantt chart. You can do sprints and more typical timeline planning all in one place. I also just want to show you how quick and easy it is to schedule or rescheduled tasks in TeamGantt. So let's say for instance, I wanted to add some more additional concurrent work that's not necessarily going to be happening in these sprints, but something that's outside of that, maybe at the same time as sprint three.

I can go over here, hover on Group of Tasks to add a new group of tasks, and just call this, let's say I'm going to call it Marketing Tasks. Okay, so I'm going to add a task here. I'm just going to say Ad Copy. That's, we're gonna write the ad copy. I'm going to schedule that to happen within sprint three, but it doesn't take part in sprint three. It's not a part of it. It's going to be separate. Let's say that there's another task that goes on that, it's revisions. Going to add that. I'm also going to add it here, and let's say obviously, I can't make the revisions without the ad copy being written, so I'm going to have a dependency that goes from writing the ad copy to revising the ad copy. I also want to define who's working on those tasks, so quickly, I'm going to go in and just say the marketing team is going to do this, and I'm estimating that they're going to put about six hours into the task.

And that's going to show up right there. It's really easy to add tasks. It's also easy to move things around if you're not feeling like things are working in the right order, or you need to just make revisions as your plan sort of proceeds. Alright, so I want to take a closer look at the second half of this plan, specifically within the sprints. I've seen sprints done in Hybrid projects in a number of ways, but when a stakeholder team can't really commit to making quick decisions where if your brand or design system hasn't been defined, so it's gonna take some time to get to a design that everyone agrees on, you might be better off scheduling a Waterfall approach to account for how that time really plays out within designing the work, reviewing the work internally, presenting it to a client or a stakeholder, collecting their feedback and then iterating on it a number of times. Spelling up those steps can sometimes benefit you because it helps you to define expectations and keep your work within scope.

But for the purpose of this project, we've got a design style to work with, so it's all about prototyping some functionality and jumping right in, and that's what I've scheduled here in this first design sprint, so we'll complete most of the design work in the first sprint, but based on my experience, you'll want to make sure that you keep your design team around to consult on the build out to make sure that if you are designing and building a website, the build actually looks like what was designed. As you can see here, we've got four sprints earmarked, so here's the first and second that we're working on. The second is actually currently in progress, and then I've got the third sprint here, this is the marketing tasks that I added. I'm actually going to go ahead and delete those because I was just showing those to you, that's not really going to be used. See how simple it is to delete those tasks. Voila, they're gone, and there is our fourth plan sprint.

I like planning my sprints on a Gantt chart to provide some hard dates that helps people to understand that adding more and more features could be impossible and it can inspire some conversations about task and feature priority. You can also see here that while I was planning out my sprints, I went ahead and added milestones for a sprint start date and a sprint end date and so that I can add those into my Gantt chart and have milestones reflected for when important things we're going to be happening. I really like that you can easily map out how many sprints you'll be able to take on during a project if you've got a big deadline, and you can see here my fourth sprint ends on the 14th, and that just so happens to be when the project needs to end.

I also like that adding sprints here gives you a quick visual of how the project works, which can be really helpful to your team and stakeholders as well. So knowing the end date's mid-December, you can also plan other tasks right in the Gantt chart for things related to the project, but maybe not core to your sprints. Like I mentioned earlier, this is where you see I've added groups of tasks in a more Waterfall-like process, so you can see here, I added a whole section of tasks that our video team is going to work on while the rest of the team is working in Sprints. Now I decided to add it here because it is a part of the project. The video that they're producing is a part of the redesign project, so I want to have all of that information about what's happening on the project in one place, and I don't have to view all these tasks all the time. I can just collapse them and really focus on the work that's happening at the moment.

So you might be wondering what the backlog is here at the bottom of the project plan. It looks like a list of tasks, just a list of tasks that haven't been assigned, and in fact, that is the case here. So I'm scrolling back to show you that I have made assignments on each of these. I just haven't scheduled the tasks yet. These are the things that I know the full team will need to do across the sprints, but because we're taking a Hybrid approach, we're going to plan what gets pulled into each sprint at the beginning of the sprint, so when those milestones are listed in the plan, and what I like about this approach is that you can do your best to determine all the tasks you'll take on in a project and drag them into your plan sprints. You can also have the flexibility of adding things to the backlog as they come up. So when I talk about dragging things into Sprints, it's really simple. I can grab things from the backlog, and drag them into the sprints to signify what's gonna be happening in the sprint.

That's what I did with all of these. So I can imagine sitting down with the team at the beginning of the sprint and saying, "Okay, we need to determine how much we can take on. What's the level of effort of the tasks in the backlog and which are the most, the highest priority in which should we pull into the sprint." And then as a PM, I can go in and quickly drag those into the sprint to signify the tasks that we're going to take on during any given sprint. So that's pretty much everything that I wanted to show you here. It's all about Waterfall when you need it, and managing sprints to a deadline. So managing a Hybrid plan is pretty simple within TeamGantt, and it's about to get better. We're currently working on a board view within TeamGantt to help you and your teams manage sprints and even overall workloads with boards. If you're interested in checking that out when the beta's released, please send us an email at support@teamgantt.com to let us know you want to test boards or any other new features we're working on. (End Screen Share)

As you can probably tell, the options are endless when you're crafting your own process. I've personally seen teams do really interesting progressive work using methods they developed completely on their own. So keep in mind you cannot only do what works for you at the beginning of a project, but you can create ways of working and continue to be better by refining that workflow. To me, that's really exciting because you're constantly becoming a more thoughtful, efficient, and adaptable as a team. So that covers everything for this class. I hope you've learned enough about Waterfall and Agile to start crafting your own Hybrid processes. Here's a quick recap of what was discussed. Methodologies help us to find efficient ways to organize projects, create routines, and set expectations which makes projects less chaotic, and as a result, teams and stakeholders are happier. There are quite a few methods for you to explore and learn from, and no single method fits all projects.

Waterfall is a method that's commonly used for projects that have a high level of expectancy and come with fixed requirements, deadlines, budgets and resources. Agile is a set of values and principles that are used in methods like Scrum on projects where there are no major constraints on time, so a dedicated team can collaboratively work in short cycles to develop ideas, test them with customers, and iterate to make them stronger. The up and coming Hybrid method is a combination of methods that allows a project leader to do what's right for their project team or stakeholders. No matter what you do with your method, it's important to evaluate and adjust to become more efficient. Remember, there's no wrong way of creating your own methodology. You have to test, discuss and iterate to get it right. Be confident in that you know what's best for your projects, and you'll find the best solution. Come back to checkout class three where I'll be exploring ways of estimating projects.

‍

‍