1.1: History of Project Management as a Profession - Video Tutorials & Practice Problems

<v ->Welcome to lesson one,</v> history of project management as a profession. Let's look back at the history of project management. Actually, the first recorded project in the history of project management goes back to 2570 years BC, when the Great Pyramid of Giza was completed. Actually, ancient records show that there were managers for each of the four faces of the pyramid. And each of them covered planning, execution and control in managing their part of the project. Similarly, there are records that confirmed that the project managers of the Great Wall of China, constructed over 2500 years starting in the seventh century BC and completed in mid 1800s, used soldiers, common people and criminals, and organized them by their deliverables to complete the project. It was only in the 20th century that traditional project management became a profession and a school of study. In 1910, Henry Lawrence Gantt, an American mechanical engineer and management consultant, produced a concept of a graphic representation of tasks across time. This chart that you can see on this slide, now known as Gantt chart, clearly illustrated a project's individual activities and deliverables, and allowed visual indications of how well the work was progressing, who was responsible, and when and where action would be necessary to keep this project on schedule. A significant leap forward in professional project management happened in 1960s, where a number of new techniques were introduced by industry leaders. There are three primary techniques that were introduced at that time. The first was called the critical path method. This technique was developed by the DuPont Corporation when they were modernizing their plans and closing one plant to make it more modern. The intent was to keep the sequence of activities on track. The sequence of activities, you may have guessed, to was referred to as the critical path. This technique allow the company to save millions of dollars, and the critical path method became widely used in project management. The second one is the work breakdown structure. Think about it as a parent child relationship. When we need to complete the project, what does need to happen, and how every activity is split into tasks. That originated in 1950s with the US Navy's Polaris nuclear missile project. And finally, PERT analysis. PERT stands for program evaluation and review techniques. It takes the critical path method and sequences all the activities end to end. That directly led to the Gantt chart that sequence those activities from start of one to the finish of the other. Here in this slide, you can see a sample work breakdown structure. Throughout the decades of the 20th century, project management allowed for significant savings and greater efficiency. That led in 1960s to the creation of the Project Management Institute. It is a non-profit professional organization dedicated to advancing the practice, science and profession of project management. In the UK, a similar organization was launched with prints as their project management methodology. Those organizations provide certifications, like the project management professional certification. You see certificates on your screen. And also PMI created a guidebook known as the project management body of knowledge or PMBOC, that describes how you execute projects, measure success, close them, monitor them, and all the formal stages of risk management, capacity management, and personnel management. Now let us review PERT. Program evaluation and review technique that gave birth to project management as a profession. So it starts by coming up with an idea, let's call it start. In our example, let's say we want to build a web application, and here is the finish. This is our application deployed on the cloud and available to the users. Then we'll look at what needs to be done for this application to be delivered to the customer. So let us say one thing we need to do. We said by building it on the cloud, this is our task number one. And what it means, we want to procure cloud capabilities. Let us say we want to start a few instances and select which services we need to use. Maybe we need to use AI. Maybe we need to visualize our data through QuickSight, whatever we need, we need to procure services on the cloud. And let us see, based on our analysis, we spoke with stakeholders, and we know it is a really, really fast activity. It'll take only one day from the moment that we start. Then once we procured the right services, we need to configure our application on the cloud. So let's call it configure application, just basic settings, access levels, and access capabilities. So let's call its configure. And we found out through our experience from stakeholders, from other work that has been done before, that it will take two days. So that's number one activity that needs to be performed. Now, there is another activity, which is we need to provide documentation. And documentation contains requirements, basic designs, and user manual. So this is basic designs. Probably there is some software specification, and user manual based on this. Good part of it, we are in traditional or waterfall delivery, which means that all this work has already been done and all of this is available to us, so we just need to review and review the sign-offs and confirm that it is all completed. So this is just one single day, and we are done with this part. But now we need to build the application itself. That hasn't started yet. So let's think what needs to be done here. First, obviously we take requirements, designs, manuals, anything that we can use to define the features and the functionality. Then we have our developers. It's actually not that big of a feature. So developers are telling us that the developments itself, since designs are already completed, development will take them two days. Then it goes into testing. So our testers do the testing and also any back and forth if they find any problems, and they say testing will take them another two days. That also includes validation by end users. And once they complete testing, it can be deployed. So what we do here, we'll look at how long this will take, for that we'll have established for each set of activities' total duration. And that's very simple math. One day plus two days, so this whole path, let's call it path number one, is taking three days. Now let's look here. All we need is to confirm in one day, and then documentation activity is finished. So number two is taking us just one day. Let's look at number three. One day here, two days here, two days here, and this total is five days. So this is called the critical path, which is the least flexible and the longest way to complete the activity. So in this case, it means that we can do this slightly later, one or two days. We can do this later, meaning move this to the finish line. But whatever is here is our critical path. This is the minimum time that it takes us to deliver this application. So this is the critical path method. PERT is using critical path method to create the duration for the whole activity. Another thing that PERT is doing, it's looking at what is the pessimistic prognosis. In our case, we're saying five days is our ideal path. That's our optimistic prognosis. And maybe we are saying, give us another two days because developers may get more time, may need more time to complete. And also testers, if they find a lot of bugs, it has to be back and forth. So we are asking for two more days, and then the estimation is seven days is the pessimistic prognosis. We're saying five days is what we actually expect. So it's realistic based on what we know. And then what we know, if there are no defects, no bugs, then testing will be done in only one day. So we are seeing, there is also optimistic prognosis. If we are really happy, that potentially can be done in four days. And that's what PERT analysis is all about.