[MUSIC] Hello, welcome to Initiating and Planning Projects. This is our first course in our Introduction to Project Management series. I'm Margaret Meloni and it's my honor to lead you through this course, so I'm really glad you're here. After you complete this course, you will be able to identify the key characteristics of a project, and identify project constraints. You will know and understand the role and responsibilities of the project manager and be familiar with the project organizational structures we frequently use to run our projects. You will see why a project charter can be useful and you will know the key elements that go into a project plan. You are going to consider what causes conflict within a project and you will gain an understanding of the difference between authority and influence. This will help you understand more about your role, and about how you wish to lead your team. Are you ready? Let's jump in. We should start with the basics. And in the very beginning of an introductory project management course, we should start with, what is a project? A project is a unique and temporary endeavor. It has a defined beginning and end. And the purpose of the project is to create a specific product or service or to make changes to a specific product or service. Let's consider some examples. If you have ever planned a large party or an event, that is a project. It was a specific party for a specific reason. It was held on a specific date and time. That means it was unique, temporary, and had a defined beginning and end, and created a specific product or service. At work, if your office is moved, it will most likely be handled as a project. If your payroll system is replaced with a new payroll system, that's a project. If your human resources department decides to change the processes they use to recruit and interview and hire new employees, that too can be handled as a project. Now day to day operations, they're not projects. Creating monthly financial reports is not a project. Cleaning your house, not a project. What about painting the Golden Gate Bridge in San Fransisco, do you think that is a project? I'm not trying to trick you. You might call it a project because it's such a large bridge and certainly painting it must require special effort and planning. Or you might say it's not a project because there's a maintenance team whose job it is to paint the bridge, and when they finish, they probably start painting the bridge all over again. There are gonna be times when someone you work with is going to call something a project even if it does not fit our definition of a project. Depending on who it is, it could be because they want this specific effort to receive the attention and oversight that a project receives. An example of this could be a computer refresh. Perhaps your organization has decided that employees should have new computers every two years. Replacing them one by one is really an equipment upgrade. But, if all of them are replaced at once, the entire effort may be very likely treated as a project. When you execute a project, you have certain constraints that you face. A constraint is a factor which might place limitations or restrictions on what you do or how you do it or when you do it. For example, if your project is a party or an event and it has to occur on a specific date, that is a constraint. If your project is to purchase and install a new payroll system, that new system has to provide a certain functionality. Yet you do not have unlimited budget, that's a constraint. If your project is to design and manufacture a new product, you might have requirements as to how much of the manufacturing can occur outside of your country, that's a constraint. As a project manager, you oversee the success of the project. You are using your knowledge and skills, combined with project management tools and techniques, to ensure that project objectives are met. You are the one who is responsible for defining that special event or that payroll system or implementation. You help to ensure that the requirements are identified, that all involved are properly represented, and that communications are clear and well coordinated and you lead the team to success. As we go through this course together, each area we cover is another part of your domain. When we discuss managing risks, it's because you need to ensure that your project has strong risk management. When we talk about the schedule, it's because you need to ensure that the project has a realistic schedule. The way in which your project team is structured really sets the tone for how you are going to work with your team. There are some specific structures that are used by most organizations. The basis for these organizations is the Guide to the Project Management Body of Knowledge. We haven't discussed the Project Management Body of Knowledge yet, so now we will. The Project Management Body of Knowledge, or PMBOK Guide, has been created for us by the Project Management Institute, or PMI. The PMI is the global, professional organization for project managers. The PMI created and now updates the PMBOK Guide to promote successful project management through standardized knowledge areas and processes, which we use to manage our projects from start to finish. What you are learning about in this class is based upon the recommendations of the PMI and from the Guide to the Project Management Body of Knowledge. With that information in hand, let's look at some of those project organizations. First we will look at what is called the Functional Organization. In a Functional Organization, there is little to no project management. You might not be involved as a project manager. Sometimes there can be some project coordination involved. And that coordination takes place between the functional departments. Now by functional, I mean groups such as marketing, operations, finance, information technology. Each manager of each group oversees their part of the project. Employees working on the project may or may not know there's a project. They just might recognize that their manager has asked them to do something different than usual. There's probably limited conversation between team members, because they do not know they are a team. And there are probably no project team meetings. Now we're going to look at three types of matrix organizations, weak, balanced, and strong. The designation of weak, balanced, or strong has to do with who has more power or control over the project, the functional manager or the project manager. And remember that functional manager is someone who has a responsibility over a specific area and doesn't typically run projects. In a weak matrix, the functional manager is in charge and he or she will probably have the assistance of a coordinator. The project coordinator will help maintain the schedule and the status and assist the functional manager, but the coordinator, not gonna have any decision making responsibility. Within the balanced matrix, there's a recognition that having a project manager assigned will help to ensure success. And that project manager has some decision making responsibilities, but so does the functional manager. The project manager manages the team to stay within scope and schedule and budget. And the functional manager will make decisions as to who does the work and how that work is to be accomplished. In a strong matrix, the project manager has much more responsibility and authority. But not complete responsibility and authority. He or she still cannot make all of the decisions. Now when we talk about a projectized organization, this is where the project manager is king or queen. The team is dedicated, works on this one project, and the project manager will act as the manager of the team. Possibly even writing performance appraisals. So which one of these is the best organization? Now that's a trick question. They all have their place. For example, the functional organization works very well for groups who do not run very many projects or for projects which are not complicated and not on a tight deadline. The Matrix Organizations work well when team members are going to be assigned to a combination of multiple projects and also other work. And in a matrix, team members could be assigned to quite a few projects. In a matrix situation, you as the project manager, most likely you're running multiple projects. As to which matrix is best, weak, balanced or strong? Well the PMI would ask us to consider strong because that is where the project manager has more power. And of course the PMI wants to see projects run by project managers, who are drawing upon the best practices. But sometimes a weak matrix is good, when the functional manager in charge has much of the required expertise and simply needs help with project coordination. A balanced matrix works well when it's easy to divide decision making and responsibility between the project manager and the functional manager. If it makes sense for the project manager to have more of the authority and the decision making, but not all of it, then a strong matrix could be the way to go. Now, a Projectized Organization is good for a very critical project, especially if time is of the essence. It is more expensive, because you take team members and put them all on one effort, and they were doing something before, so you probably have to backfill them. But the project gets all of the focus and attention that's required. There really is a time and a place for each of the project organizations. And in fact you'll find that some companies may use a combination of all or some depending on the project at hand. Now look at you. We started out with some basics such as what is a project. And now you have an idea as to what you will do as a project manager and how project teams can be structured. And we're finishing up our first module. [SOUND]
