Introduction to Project Management

0:00Thank you for joining me on this journey into the realm of project management. I am Bob Mailer. I'm going to be your hostess with the mostest for this introduction to project management. So strap in, grab a helmet. Here we go. Let's imagine we're both walking down the street of any given awesome city. And we both stop in front of this building and look at it. You might be thinking, how long did this take to build? How much did it cost? And how many people were involved? Why are there so many windows? Maybe thinking a range of things.

0:30You're a tourist and you're overseas and you see the tower bridge in London. You might be thinking, when did they build this and why does it look so great? And could they've built something a little more simple? The answer is no, because it's awesome. You may have again a range of questions like, how has it stood the test of time ? If you're like me, you like to go to amusement parks and you get on the neck breaker roller coaster. And as you're winging around it, hitting those curves at 10 G's, trying not to pass out and throw up, you may have some questions like, this thing is amazing.

1:00But why am I still strapped in this chair going 200 miles an hour? Why aren't people being flung in every direction? How long did this take to build? How much engineering is used to build this? And is it even safe? You're dancing at the edge of project management. Those are all good questions. If you were to ask PMI, the project management Institute, they might say that project management is the application of knowledge skills, tools and techniques to activities to meet project requirements.

1:34But that's a lot. So let's break it down. The application of knowledge and skills. Well, who's knowledge and skills? Well, that would be yours and the project team, engineers, code writers, etc. Well, what tools and techniques are they applying meetings, expert judgment, brainstorming, alternatives analysis, and the list goes on and on. Now, when you say activities, what are you really talking about? You're talking about work, people doing stuff.

2:06And then finally, to meet project requirements, what project requirements? Well, projects are undertaken to produce a product, a service or a result. Your product might be drone delivered pizza. It's coming. And I definitely want some or a service. People coming to your house to fill up your vehicle just because you don't want to go to the gas station. That's a real service, by the way. And finally, a result. How about a 15% increase in customer satisfaction or a 5% increase in stock price?

2:40Projects produce products, services and results, sometimes all three. So let's clear this and drive on. If you can't wrap your head around that, take a look at your phone because you probably have one. You may even be watching this video on it right now. How many apps do you have on your phone? You probably have one that gives you access to your money in a bank or a savings account or your stock market. And how about projects that clean up natural disasters like tornadoes or hurricanes?

3:12And what about good old social media? You know what it is and we all have it. So really, what is project management? And the answer is it depends. It depends on who you ask. If you ask me, I think it's nothing more than a framework, a framework that's going to take you from point A to point B. Because right now you have the present state or the status quo and you're trying to go to the future state, some sort of gain, perhaps.

3:43The future state is over here. Project management is going to take you there. And there's more than one kind and we're going to talk about it until you know way more than you think you should know. So if you're feeling confused up to this point, you're not alone. Let's take a pause for cause. Let's take a break for a shake because we're in for a minute to win it. And yes, I rhymed all of those on purpose.

0:00And welcome back to training. If you stuck with me this long, well, it's only been a few minutes. So hopefully I've dropped some knowledge bombs on you and you are excited to learn more. So let's get to it. Previously, we talked about what project management is. And for the next few minutes, I want to talk about how it might be used. So think about the construction industry very mature. In this example, we have the Burj Khalifa in Dubai. It is the world's tallest building. That by itself is notable, but here's the really crazy part. 12,000 workers worked on it. 12,000. That is amazing to me. Also notable. More than 100,000 pounds of concrete.

0:41Now, take a moment, consider how many miles of electrical line there might be. How much plumbing, how many rooms, how many elevators, how long did it take to build. It is an engineering marvel hands down. And if you ever need an example of how the construction industry can really leverage project management, the Burj Khal ifa is it. Let's move on to AI. Raise your hand. Well, wherever you're sitting, if you're using some form of chat, GPT or deep-seak or grok, you can't touch any piece of software these days without having some form of AI integration. It is amazing.

1:19The processing power, the speed, the results. And obviously, there are some problems with it. Sometimes it'll make things up. Sometimes it'll give you too much, but it doesn't at a speed unheard of before. I cannot imagine what AI is going to look like in five years, but I'm excited to see it. The healthcare industry, very mature space for project management. Here's a great example. The Mayo Clinic is one of the most prestigious institutions in the world. Now, sometime back, they undertook a $1.5 billion project to standardize their EHR, their electronic health records across all their locations.

1:57They have 90 different hospitals and clinics. Imagine walking into one clinic here, let's call this clinic A, having an exam, and then you go to a different clinic over here, perhaps later that day. And then you go see a specialist over here, maybe next week, and then you have to get blood work over here. Maybe the same day, maybe next week. It doesn't really matter. But all of your information is seamlessly moving around from point A to point B all the way through point D, which may not seem like a whole lot, but what about data quality? What about data integrity? What about data security?

2:34It really starts to add up and oh, by the way, what about data storage? It gets out of control very, very fast. Wildly cool project management. If that's not working for you, think about marketing. Do you know in the most recent Super Bowl, it cost a staggering $8 million for a 30 second slot? $8 million. Can you imagine how much time and energy they put into making sure that every single second they put out there for the most? Watched sports contest in the United States every year? How much ROI they're trying to get on that? There was no thoughts wasted. Well, that's not necessarily true, but there's definitely no time wasted for those 30 second slots.

3:18If you ponied up $8 million, you definitely wanted your money back. Here's another crazy marketing idea. Back in 2011, Coca-Cola was trying to do a re brand too. Remember when they came out with all the bottles with everyone's name on them, Bob, Shelley, Steve, Frank, George? They had to come up with 250 common names across the world that they could use in this marketing campaign. 250. You may not know that, you may not care. You may not still care, but now you know. Let 's move on.

3:49The space exploration industry right now. Has anyone paying attention to SpaceX ? Not long ago, they launched a payload into space and then they caught the heavy booster rocket. It came all the way back down. They coddled on what looked like chopsticks on this 24 story gurney. It is one of the most amazing feats of engineering and project management that I have ever seen. If you haven't seen that video, you should definitely Google it. It will blow your mind. And we're going to go to Mars, not me, but someone's going. And what about the cruise line industry? Here's one for you. I don't know if you like cruises, but the oasis of the seas is the largest cruise ship ever built and it took how long? Six years. Six years to build a boat. Well, it doesn't sound like a whole lot until you figure out that it took more than 10,000 people to do it and wait for it.

4:43It can hold up to 7,600 passengers and crew. Huge. Can you imagine what it would take? How much propulsion? How much wastewater recycling? How much to cook for that many people? How much to make sure they're safety if they have to evacuate? It just blows my mind. And yeah, I might be a project management nerd, but you have to admit, these are some wild stats. Project management is used almost anywhere and everywhere.

5:14And if someone's telling you they're not using it, they're probably not really thinking about it. You use it at home when you paint a room or when you plan a vacation, plan a wedding. We use project management all the time in almost every industry that I can think of and it's only going to get cooler as we go. If your mind's full, let's do what I like to do. Let's take a break. When we come back, we're going to talk about the timeline and the history of project management.

0:00Well, welcome to part three of the course. I'm glad you came back. I'm super excited. You've probably picked up on that by now. I'm a little bit of a nerd in the project management field, but I love it. Hopefully, you're going to love it too. Now, part one, we talked a little bit about what project management is, and we just got done talking about how it might be used. Now, we're going to talk about some notable dates. As soon as I figure out how to do it. Now, project management is not an immature field. It's been around a long time, and there's some very formal dates where some transformative things have happened in the project management industry to move it along.

0:37Let's start with 1917. 1917 is the Gantt chart. Henry Gantt developed the Gantt chart, which is really just a visual scheduling tool used for tracking project activities. And it might look like this. Imagine you have January, February, March. Well, the Gantt chart, sometimes called the bar chart, might look like this. This activity takes this long across that many weeks. And then the next one is here. And then the next one is here. Then maybe you have a bunch of little activities running as well at the same time.

1:10And it's a really interesting way to see how project activities are sequenced through your network diagram. And we're going to see much more of this when we get to the scheduling portion of this course. Now, 1956-- let me grab my cursor here-- 1956, the AA CE is formed. The American Association of Cost Engineers. Now, a moment ago, we had something that significantly impacted the schedule. Now we have something significantly impacting the budget or the cost.

1:41The American Association of Cost Engineers is all about focusing on cost controls. Cost controls dictate how you spend money, how you track money, and when you need to be really concerned about how much money you're spending. We're going to talk more about the budget in future nuggets. These are two very important events. Let's go to 1957-- the critical path method. The critical path method is a method of determining which of the network paths through a diagram are the critical path.

2:13Let's imagine this is January. And then you have December over year for one project. Typically, in a one-year project, you might have multiple network paths through it. Now, this is a real simple expression of that. But one of them is going to be called the critical path. And the critical path is critical because it is the path that dictates when this project is going to start and when all of the project activities are going to be done or should be done.

2:45And it's called the critical path because it dictates when the project should end. Any deviation from that usually means the project is going to be late. Now, let's fast forward to 1958. PERT, or Program Evaluation and Review Technique, is introduced. The Navy figured out that when they ask someone how long it was going to take to do something, they were overly optimistic or pessimistic so they developed PERT as an estimating technique. And it is a formula.

3:16And it looks like this. P plus 4R plus O divided by 6. I know that looks terrible, but it's P plus 4R plus O divided by 6. P is pessimistic, R is realistic, or most likely, and O is optimistic. I know this sounds a little wonky, but this really helped them determine how long activities we're going to take, particularly those that had never been done before. We'll talk more about this in estimation. Moving on. 1969, PMI is born.

3:46PMI is the Project Management Institute. They are in Pennsylvania. And right now, and probably for the foreseeable future, they are the de facto standard in project management. If you've ever heard of the PMP, the Project Management Professional, they are the overseers of that certification and quite a few others, actually. Let's drive on. This brings us up to 1986, and the Scrum framework is introduced. Scrum, which I may have mentioned before, is a methodology of framework, if you will, that's normally used for software development.

4:23Predictive is usually used for infrastructure development. One is good for one, one is good for the other, and they are rarely interchangeable. However, they may be used together for various kinds of projects. When we get to the comparison of Scrum and Predictive, so you can visually see it, it'll make more sense. Now, PMI was formed in 1969, and you may have heard of the Project Management's correction, the Project Management Body of Knowledge.

4:55The Pembok, the Pembok Guide, is a framework of inputs, tools, outputs, and various items you might use to make your projects better. It started as a pamphlet, and now it's morphed into a pretty thick book. We'll talk more about this later on, but this is when Pembok 1 came out. We are currently on Pembok 7, so a lot has changed. Now, in 1994, the Chaos Report is published. Really talks about the high failure rate of IT projects, information technology, and if memory serves at the time, they pointed out that something like 90% of all IT projects were suffering problems.

5:35They were out of scope or not delivering all of the scope. They were way over budget. They were way behind schedule. It was a train wreck. Not surprising, not long after that. In 1995, we had the official introduction of Scrum, officially introduced as an agile framework. And then, tied to that, in 2001, the agile manifesto is released. Now, the agile manifesto is the, oh, a very pivotal foundational document that dictates how software should be developed.

6:09And it is wildly different from predictive. We're going to talk more about this, but make no mistake, the agile manifesto changed the game for how software would be developed, and it is in practice now. All right, this is going to bring us up to 2009. Now, because the agile manifesto was released and how it changed the game for software development, PMI, which had previously released the PMP, is now releasing the professional certification for agile practitioners.

6:40And it exploded. 2017, we came out. Again, PMI came out with the sixth edition. We previously talked about the first edition. And now, we are on the seventh edition of the PIMBOC, the Project Management Body of Knowledge, which is now principal-based approach. No, do not go out and start buying old versions of the PIMBOC guide so you can read up and catch up, because you'll just fall asleep. That's the only thing that's going to happen. The whole point of this entire nugget is just to show you that the evolution of the project management industry has really been accelerating since the release of the Gantt chart all the way through cost controls and the introduction of the Scrum Guide, the Agile Manifesto, and the Project Management Guide, the PIMBOC guide.

7:29Here's where we are. I hope you've enjoyed this. And if you're super excited about learning more, raise your hands. Well, they must be excited, so you know what time it is. It's time for a break.

0:00And thanks for coming back to training. I really do appreciate it. I hope some of this is making sense. Heck, I hope I'm making sense. So far we've talked about what project management is at a very high level. Some of the industries that use it, and we've given quite a few examples along with some key dates in the timeline. So from this point, we're going to have to dig a little bit deeper and get into the benefits and reasons behind why a company might use project management. So let's talk about the reasons. What are some of the reasons that a company might undertake a new project?

0:33And believe it or not, there are quite a few. The easiest one is market demand. Not long ago, there was just chat GPT, and everyone went bonkers. And now, like I previously pointed out earlier, you have Grock and DeepSeek and almost every software application has some kind of AI integration in it. We are hungry for whatever will make our lives easy, and so far, AI is going to meet that need. And this isn't a new concept. Think about Alexa. Or, okay Google, tell me about it's been around a while. So market demand makes sense.

1:10But what about the business needs? There are plenty of business reasons to undertake a project. Let's say two companies merge. They're integrating two different kinds of software and they need one platform. That's a business need to initiate a project. Easy peasy lemon squeezy. Or, they've grown so much because of data storage, they have to perhaps build another data center. That's a business need. One of my favorite reasons is a customer request. Here 's $20 million and I want you to build something for me.

1:41Okay, I'd like that in small unmarked bills please. Another reason, they're not going to do it, but it is kind of funny to think about. Another reason to initiate a project is for legal reasons. There are plenty of reporting reasons into say financial institutions about how you're managing your money or where it's going or where your customers money has gone. There are plenty of health reasons, particularly with data privacy for customers and patients. There are lots of legal reasons to initiate a project.

2:15Another good one, and you'll know this one, technological advancements. Didn't I just see that Microsoft just introduced a quantum computing chip on the heels of AI, which is recently exploded as well? I've been talking about it. It's only a matter of time before your dinner is going to cook itself. If you 've ever watched some of the old episodes of Star Trek, Jean-Luc Picard's will walk over to what looks like a microwave to me and says tea, Earl Grey, hot, and it just materializes. I don't think we're far from that, and that would be a cool tech advancement.

2:50Another good reason, environmental considerations, perhaps to restrict flooding somewhere you want to build a dam, or because of forest fires you're trying to plant a bunch of new trees, tens of thousands. Who knows? The environment is important. There are plenty of reasons to undertake some of those projects. What about competitive pressure? Well, our client just came out with a 2x AI model. We need to come out with a 3 x AI model. You know what I mean. If you're client, correction. If you're competitive, or is suddenly doing something better than you, or offering something better than you do, you better figure something out pretty quick.

3:28Another good reason to initiate a project? Crisis response. Well, that's not right. I better figure that one out. One second while I do the eraser, because apparently, I don't know how to spell cry. Well, let's try this again. Perhaps you have a data breach, and you need to institute some sort of new data protection or security measures to make sure it doesn't happen again. So, there are plenty of reasons to initiate a project. It may not be at your level, but someone somewhere is taking a look at this.

4:01Even easier is the age-old reason. This is the present state. This is the future state. This is where we are right now. Perhaps a company somewhere says, "Alright, last year we made $200 billion by providing X, Y, and Z." And next year, I want to make $300 million by providing a better version of X, Y, and Z. So you're going to initiate projects to go from the present state to the future state. And it happens all the time. This has been beneficial. I want you to chew on the reasons why you might initiate a project, and we'll be right back.

0:00In a previous section, I happened to mention some of the reasons why a company might undertake a project, and I need you to understand that list is not all inclusive. There are plenty of other reasons why a company might start some projects or expand or even stop a project. Those are just some teasers as we go further into this training. But now I want to talk about some definitions, because to really understand project management, there are a ton of vocabulary words that need to make sense. Hopefully this will help. And trust me, this list is not all inclusive either.

0:32So let's get to it. The first one right out of the gate is scoped. The scope is what's included in your project. The deliverables, the product, the service, the result. And here 's an easy example. Let's say you go to the store with a grocery list, and you need sugar and flour and oil and a pan and a bunch of other stuff. So you get it all and you take it home, you mix it all up, you bake it, you put some icing on it because you're deliverable is a birthday cake. That is what this project was all about. Scope equals deliverables. And once you clearly understand what you 're deliverable is, you can figure out what the scope is. And I know this sounds very elementary, it can be very complicated and very technical, very fast. The next definition are stakeholders.

1:26Stakeholders are people. People that believe your project has a positive or negative impact on them. People who can have a positive or negative impact on them. And let me give you a couple of examples. Your customer is definitely a stakeholder. And users are a stake holder. The public can be stakeholders. The government might have a stake in your project. Stakeholders. The project manager definitely a stakeholder. The project team definitely stakeholders. Stake holders is a very broad list.

2:00Another important definition is a milestone. A milestone is a key date in the timeline of your project. Think about your annual key dates wherever you live, perhaps a national holiday. Here in the United States, some of those key dates are the 4th of July, Christmas, Halloween, Labor Day, Memorial Day, Tree Day and Flag Day. Okay, I'm not so sure about Tree Day, but some of those others are pretty important. Perhaps your milestone can be the completion of a key component of your deliverable milestones. Another very important, probably too important.

2:39Definition is a risk. A risk is an uncertain event or condition. It's uncertain . And if it happens, it may or may not have a positive or negative impact on your project. If it actually happens, it becomes an issue. And an issue is a problem. This becomes that. Another phrase you might hear me use throughout this training. Another upcoming training is WBS or Work Break down Structure. The work breakdown structure is a structure that breaks down the work. Think of your deliverable.

3:15How many, it's where you decompose something large into some things that are much smaller. Think about a car in this easy example. So we want to build a new car. So our project deliverable is a car. But how many different ways can we break that car down into smaller pieces? Well, perhaps there's the frame. And then there's the engine. And then there's electrical. And then there's the transmission. Well, let's think about that frame for a second. You might have internal and then external. We break it down into smaller and smaller, more digestible, easily understandable pieces. That is your work breakdown structure. And oh, by the way, there's work that's broken down as well. Things like inspections and audits and meetings. How many meetings do we have on the project? Now let's talk briefly about waterfall project management, sometimes called predictive versus agile. They are not the same. A waterfall project may have a life cycle that looks like this.

4:19Perhaps you have concept and then planning and then design and then build and then roll out and then retirement. I don't know. I just made that up. But notice how it falls this very waterfall-esque downhill looking slope. This can take a long time. Some projects last for decades. Some, just a couple of months. It's called predictive because there's so much planning that goes into it, you can predict or have a pretty good understanding of predicting what might happen next.

4:52Agile is very different. Agile is very flexible. It's very fast and it's largely associated with software development. In agile, scrum to be more specific, a scrum sprint is only one month long. So in this example, let's say you have 5,000 lines of code. Well in the one month sprint, they decide they're only going to write 500 lines. So they write the first 500 lines and then they get ready for the next sprint. Well they're also reviewing that first 500 lines.

5:26And so they take what they don't like and they may roll it into the next sprint and they do it again and then they do it again and then they do it again. And I know you folks are familiar with this because you all have phones and if you have phone apps, you've probably seen a new download is available. Do it now. That's because they fixed something in the previous code version or they've enhanced it. They've added something to it. Waterfall is most associated with infrastructure type projects or heavy engineering where a lot of planning is necessary while agile is considered very fast and very flexible. They normally do not work well when you exchange them one for the other straight across the board. They do work well together for some projects and there's a huge debate on LinkedIn and the project management world about which is better. And the answer is it depends. It really depends on the kind of project you're dealing with, what kind of timeline and the list goes on and on and on. The next definition is dependency or dependencies in this case. This means something is dependent upon something else and in the schedule it usually means something must happen before or after something else. In one example,

6:44Monday, Tuesday, Thursday, Thursday, Friday. Monday must end before Tuesday can begin. Tuesday must end before Wednesday can begin. Another way of saying it is Tuesday is dependent upon Monday. Monday must happen before Tuesday. This is the finish to start relationship. Something must finish before something else can start. And thinking of your work week is the easiest way to do that. I think that's a lot for right now. Let's take a pause for cause and we'll get back to it in part two of definitions.

0:00Welcome back to definitions and right out of the gate I want to talk about one of the most important definitions in any project and that is the project plan. Let's just call it the plan. The plan is what we're going to do on this project and how we're going to do it. It is our methodology and it sounds simple enough but that is a mistake. It is not simple at all because there are a bunch of sub plans that make up the plan. So let's get into it. First you have strategic plans.

0:33Let's just call them strategic. Well that's not right but I think you know what I mean. Strategic plans affect the entire project. Plans like the change plan. How are we going to change things on the project? If you can't track changes you can't track what happened and if you can't track what happened you can't fix anything . Then you have a life cycle description. What process, water fall, hybrid is this project going to take? I don't know but we need to figure it out .

1:06Those are just a couple of your strategic plans. Well then you have what I call tactical plans. Tactical plans affect just one or two areas. How do I deal with the scope? Well there's a scope plan. Along with the scope plan there's a requirements plan. How are we going to capture and deal with the requirements? These two are tied together. Well what about the budget? Oh I know let's check the cost plan. Well what about the timeline? I bet we can find something in the schedule plan. These three look familiar?

1:39They should because these are your triple constraints and if you remember what I said what I done did said it when I said it. I actually said it. Your triple constraints mean you cannot change one of these without affecting at least one of the others and in my humble opinion you can't change any of them without affecting the other two. We're going to talk more about that further in training. Well how do I deal with the risk? I bet there's a risk plan and you would win that bet. What about my vendors? There's probably a procurement plan.

2:11Well what about my resources? My people? My stuff? My heavy equipment? My wood? There's a resource plan. Do you see where all of this is going? There's a plan for everything or there should be a plan for the things you need. Don't have too many, don't have too few, have just enough to keep this project under control. How do I do with my stakeholders? Well there's a stakeholder plan. You probably saw that one coming. That is a big overview of the plan and all the stuff that goes into it and make no mistake. There are other plans so don't be surprised later on when I say the plan and then this piece if it's the first time you've heard it and don't even forget that we still have agile out there because in the world of agile you may have a release plan and an iteration plan. Well what's the difference?

3:04Well you may have three or four iterations for your sprints and decide to release all of that stuff that you did in the first release. I have no idea. Every project, every industry, every project is different. The point is you must have a plan. But why do I really care about the plan if I know what I'm going to do and I know how I'm going to do it? Well what happens if you do something different than what you said you were going to do? The plan is what you said you were going to do.

3:35The actual is what you actually did. That's why it's called the actual. Well what's the difference? The difference is the variance. The variance is the result and the variance is what will get you into trouble. If you can't tell the difference between what you said you were going to do and what you actually did if something goes wrong you can't fix it. The variance tells you what happened and from the variance you can figure out what to do next. Again I know I'm dropping a lot of knowledge on you right now.

4:07We're going to talk more about this in future nuggets in future skills. So that's the plan. Now let's talk about documents. The plan tells you how to do stuff but documents are the information you capture from actually doing the stuff. There are plenty of logs like assumptions log. Well what is an assumption? An assumption is a belief you hold to be true or false in the absence of proof and if it turns out to be different than what you thought it becomes a risk. A risk becomes an issue. An issue is a problem and it goes in the issue log.

4:43What do we do with problems? We solve them and there are tons of other documents. Scheduled data, risk reports, risk registers, resource calendars, quality reports, quality metrics. The milestone list, the lessons learned, registered, documents and plans, plans and documents, lines and tigers and bears. Oh my! You see where this is going and this is an area where many project managers fall apart because they don't keep up with their plans and their documents and because of that they can't figure out the variance and they can't properly report to leadership about what's happened and what they're going to do next. So make no mistake in all of the definitions we're going to talk about through this nugget and future trainings plans and documents are super duper important.

0:00So far we've talked about what project management is, why a project may be initiated, lots of plans, lots of documents, but that still begs the question, where does it fit? Why do it at all? And that really is a good question. So let's talk about it for just a moment. Where does it fit? Well, every organization usually has a C-suite. These folks, the CEO, the CFO, the CIO, and the list goes on and on. And every year they take a look at the present state, what they've currently done. And in this example only, excuse me, let's say they've only made $100 million.

0:40Well, they'd like to make more. So they have a future state. And in the future state, they'd like to double that. And that's where project management fits. There's a gap. How to go from here to then. Projects do that. So they have a product, a service, or a result that's going to do that. So what do they do? They start handing down instructions to their VPs. This is what we're going to do. Figure out how to get us there. Well, along the way, there's a very important organization that may or may not exist. The project management office.

1:16They are the office that manages projects in this particular company. Let's say it exists. So what do they do? They appoint a project manager for this particular product, service, or result. And they ask for people from each of these verticals. So sales sends someone, engineering, customer support, and operations. They all send someone. And now you have a project team. Project team focuses on the product, the service, or the result that's going to move the company from the present state to the future state.

1:52But that's not the end of the story. There are some quirks here, depending on the company. Now, the project manager really wants to be large and in charge, so he or she can move this project along. And that's going to take a lot of cooperation and coordination from the VPs. That might sound like it happens, but it doesn't happen like that. Very often. It depends on the organizational structure. It really comes down to power. And this is the easiest way to see it.

2:24In the functional organization, the project manager's power is very limited. So I'm going to call that 5%, meaning the project manager has to ask everyone for everything with this hat in his hand or her hand. And it can be very uncomfortable. You see this in very traditional type companies that have very rigid departments, like sales, engineering, customer support, operations, and the list goes on and on. On the other side of the spectrum, you have projectized. And this is where project manager's power is near absolute. Let's call that 99%.

2:59The project manager can move seamlessly from group to group, has a ton of power , and normally was given that power by someone in the C suite. You don't see this very often, but it does happen. What you normally see is something called the matrix organization, a blend of traditional and projectized. This is where you see a lot of companies moving to as they call it a transformation as they try to get project management better within their organization.

3:30I like to call this the 50% power project manager. It works very well in some organizations, but again, the key factor in every project manager's success, not all of the keys, but one of them is having executive. Someone says, this is what I want. This is the person that's going to do it, and this is how you're going to support it. In almost every instance where that happens, you have a more successful project.

4:00But there's another wrinkle here. There may not be a project management office. And so now the C suite may just appoint a project manager or that looks like a mountain. So the project mountain, I think you know what I'm trying to say, or the C suite may decide that this particular VP is going to handle it. So now this VP appoints a project manager, and these VP's all have to get on board with this project, which means now they all have to provide people maybe to this project manager.

4:36What do you think happens if they don't agree with this particular project, or they don't have the staffing resources to support it? This project manager gets beat up, and it happens all the time. That's not the only issue. Other issues, processes. You might have every one of these VPs on the same page as the executive sponsor, who whichever C-level officer is pushing this, and the company's processes aren't agile enough for you. They're agile enough or quick enough to let this happen. It may take two weeks to get anything approved. What do you think that's going to do to the schedule, or the budget, or the scope?

5:16Or they may have preferred vendors that they have to use. What do you think might happen to the budget if they limit competition? Other factors involve too, like shipping. If you're ordering quite a bit of material from overseas, how long might that take? Take, excuse me. What about competition? Not every project that started is born, because the competition beats you to market first. What about regulations? There are a ton of factors involved in where project management fits within an organization, moving from the present state to the future state.

5:52So just when you think it was going to be easy, I know all the plans, I know all the documents, you have a whole bunch of other variables dropped on you, and it happens all the time. When we come back, we're going to talk about the differences between project management and other companies' functions, specifically operations.

0:00So what happens at the end of a project? The answer is, it depends. It depends on the type of product, service, and results. And more importantly, it depends on who the customer was. Was the customer internal or external? If the customer was external, they take their widget and they leave. But that's after extensive testing and confirmation that they got exactly what they paid for. But what happens if it's internal? That's very different.

0:30Now let me give you an example here. Let's say it's internal. In this example, let's assume that the company stores data for everybody else. So this particular project was a big data center. And the project manager and the project management team built it. So what do they do then? Well, operations gets involved. There's a lot of testing. They confirm it meets the standard that they were looking for. It's compliant in all the ways it needs to be. They turn it on and it does what it's supposed to do.

1:02And maybe that project manager is now done. He or she goes back to wherever he or she came from, whichever one of these verticals. And that's the end of it. But that may not be the end of it. Because let's not forget, you've built something. And that something has to be maintained. Operations and maintenance is going to maintain it. They're going to check on it every day, every week, every month, whatever it is . Cleaning upon the kind of product, if it's a piece of heavy machinery, they're going to put lubrication on it, they're going to rent it out, they're going to bring it back, they're going to clean it, they're going to do all of these things.

1:36But let's go back to that data center example. Let's say operations and maintenance has it and it's working as expected. But customers support these folks get a complaint. It's not working as expected. They find out it doesn't work well the way it's supposed to. Or there's some sort of bug in it or some sort of missing hardware and it doesn 't act the way it's supposed to in case there's a power outage. That may initiate a brand new project. Which means there's a project manager that has to do it.

2:09Which means the project manager is going to go back to operations to find out exactly what's going on. Which means sales might be involved to let existing customers know, hey, we need to do something else. Which also means engineering may get involved so they can help do it. If you've picked up on it, there's the project lifecycle to produce the widget that went over to operations. That's the project lifecycle on the being very specific here.

2:43Specific here. Then there's the product lifecycle. The product may last for a very long time and go through several iterations of projects. And don't think for a second that just because you produce this product, service or result, that it's out there all by itself. Let's go back to that data center for just a second. I want you to envision a big building. Lots of servers in it. Lots of data coming in. In this example only, data center, how is that data touching the outside world?

3:19That could be a project all by itself separate from the data center independently. And what about how is it touching the infrastructure around it? And what about backup power? And what about batteries? I have no idea. And what about spill containment? All of these things are factors that play a role in the product lifecycle. All the way to retirement. At some point, the data center is going to be outdated.

3:50It will out data itself. New technology will arrive, quantum computing, data packets. There are a host of things that might happen to make that data center obsolete. Then they may actually have to tear it down. Who knows? The point of this is make no mistake. Even if the project manager is no longer involved in that particular product, operations is paying attention to it and doing something. Customer support is fielding calls from happier, dissatisfied customers.

4:22Sales may be looking for updated materials so they can actually go out there and sell it. And engineering may be playing a role as well with upgrades or problem correction and such. That's because a project ends and a product, service or result is actually delivered doesn't mean that's the end of it. This may go on for decades. And here's an easy example. Remember this? Windows. How many iterations of the Windows operating software have we seen? I remember Windows 3-1-1.

4:53I think it was. And then there's Windows 95. And then there's Windows 98. Then there's Windows XT. Then there-or XT. You know what I mean. It's P. Let's get rid of that one. And then there's Windows 7. I think there's Windows 8. I think I'm on Windows 10 right now. I'm not even sure. This is the product lifecycle. How long will it be there? I have no idea. If that's not working for you, look at the iPhone. I don't even remember the iPhone 1 or 2 or 3. And I think we're up to the iPhone 11-teen right now.

5:25So again, just because a project ends doesn't mean the product ends. And these are very clear distinctions. Thank you if you made it this far. Let's get ready for the next skill. Let's clear the screen. And give me a thumbs up if some of this made sense. Alright, it looks like it made sense to those folks. Let's drive on to the next skill.

0:00Okay, it is time to test your knowledge. I know we've gone through an introduction to Project Management at a very high level, so I promise you, this little test will not be overly difficult, and I want it to hurt just a little bit. So it's not going to be easy, but it's not going to be too tough, and I have a feeling if you've been paying attention, you're going to figure it out. So let's check it out. You've just been appointed as a new Project Manager for an IT project. You have three years of experience, which may be relevant, and this is going to be the biggest project you've led the date.

0:33Now your company is not mature with Project Management Processes, but they're working on it, which means they're trying. Which of the following is going to provide the most support for delivering a successful project? Well, let's look at your choices. You've got plenty of plans and document templates, which means you're not rec reating the wheel every time you do something, so that's good. Everyone clearly understands their roles and responsibilities on the team, so that's good. There's an executive sponsor for your project who provides a high level of authority.

1:05That sounds like a winner, and a very reasonable project timeline and budget. So these all sound pretty good. The question you have to figure out is, which one of them will provide the most support? So take a minute and think about it, and when we come back, I'll explain to you the answer, answer and why.

0:00So how did we do? Well, let's find out. All of the choices were good. Plenty of project plans and templates is going to make it easy to get this off the ground, at least for information's sake. Clearly understood roles and responsibilities sounds like you have a pretty experienced team. Reasonable timeline and budget sounds fantastic, but the one key word you should have caught was authority. More authority means more power, more power to get work done. And if you've ever tried to work on something with people that don't report to you, you know exactly the kind of authority I'm talking about. It's not a good or a bad thing.

0:38It's just necessary, particularly on a project. If you didn't pick up on it, that's okay. We're very early in this set of skills and you're going to learn a ton more as we go. Once again, thanks for training with me and I'll see you with the next skill.