Beginning Project Management: Project Management Level One

This process group starts all the fun. In this group the business need for the project is identified, some initial solutions might be proposed, and the project manager is selected.

The most important document to come out of this group is the project charter, which authorizes the project work and assigns the project manager the power to complete the project on behalf of the project sponsor. The project sponsor is typically someone high enough in the organizational hierarchy to have power over the resources that need to be involved in the project.

Business analysis is the study of the requirements, the feasibility, the cost, duration, and likelihood of achieving a project goal. Business analysis usually happens before the project work begins and may be led by a business analyst.

A business analyst is a specialist that interviews people about the problem, documents solutions, and makes recommendations for the project to be launched or not. When it comes to project management, business analysis is all about gathering requirements for the project to complete.

The project is a document that authorizes the project manager and the project. It authorizes the project in the sense that it’s allowed to exist within the organization. It authorizes the project manager as it allows the project manager to lead, direct, and manage the resources on the project to get the project scope done.

In this lecture we’ll discuss the project charter and its contents. We’ll also take a look at a sample project charter you can use for your projects.

Stakeholders are people or groups that are affected by your project or they can affect your project. When you launch a new project you’ll want to quickly and accurately identify the project stakeholders – no one likes to be left out.

Stakeholder identification is also about documenting stakeholders’ needs, wants, threats, and even perceived threats. In this lecture we’ll take a look at how a project manager goes about finding and documenting project stakeholders.

Ready to test what you've learned so far? Don't worry! This is an easy quiz that you'll do fine on if you've completed the section. Let's go!

Great job finishing this section on project initiation. All projects move through some type of initiation – some more formal than others. In this lecture we’ll take a look back at what we covered in this section and the most important things you should remember when it comes to project initiation.

The project management plan defines how the project will be managed from start to finish. The project management plan is an aggregate of many different plans. In the project management plan you define how you plan, execute and control:

• Scope
• Schedule
• Costs
• Quality
• Human resources
• Communications
• Risk
• Procurement
• Stakeholders

In this lecture we’ll look at the most important components of the project management plan you need to know as a new project manager.

In project management there are actually two different scopes. The first is the product scope, which is what the end result of the project will create. The product scope is what customers focus on—what they are envisioning for you to create. The product scope describes the thing or service that will exist as a result of your project.

The project scope, on the other hand, describes all the work to create the product scope. It includes all of the work, and only the required work, to complete the project deliverable.

The project scope and the product scope support one another. In the IT world, for example, if you're creating an application for a stakeholder, they have expectations of what the application will do. When they discuss the requirements with you, they describe the end result of the application. Stakeholders think in terms of the vision, of the product existing. They can see into the future and experience the application before it's created. Stakeholders usually have a way of seeing the problem solved and the organization with their solution, and can feel a sense of relief and urgency to get the deliverable into production.

In the perfect project-management world, which doesn't exist, there is a logical, practical approach to calculating how long a project should take to complete. Let's pretend that we're living in this perfect project management world and see how things should go.

First we work with the customer to define the product scope—describing the thing that they want us to create. Then we create the project scope—all of the required work and only the required work to create the product scope.

Based on the project scope we’ll create an activity list. The activity list should then be arranged in the order in which the activities must or should take place. Many of the activities will rely on hard logic; they must occur in a particular order for the project to be successful. We have to install the operating system before installing the application. Soft logic relies on management discretion. For example, we could create a fancy script to install the operating system and then call a remote server to pull the application and install it on the target machine once the OS has been installed. But we may choose not to do that. It's preferential logic based on experience, the nature of the work, or your mood on that particular day.

How do we know what a project will cost? We really don't, until the project is complete. I sound more like a car mechanic than a project manager, but the truth is—and this may sting just a little—we can't know the final project cost until the project is complete because we can't accurately predict the future.

What we can do is create an estimate. An estimate is more than pulling a random number out of the air, adding 20% for good measure, and then saying, "That'll work." A real estimate evolves as project details become available. This is progressive elaboration. Project estimates start out broad, and as the project deliverables come into focus we're able to more accurately define our estimates.

Each estimate should provide an acceptable range of variance, the conditions of the estimates, and any assumptions made by the estimate provider. For example, an estimate to build a new warehouse may state that the warehouse will cost $350,000, +/– 10%, is valid for 30 days, and assumes that the warehouse will be built in the month of June.

In addition to defining all of the project objectives the project manager has to determine how her project will live under the quality policy of her organizations. In some organizations the quality policy may be nice and vague, like “Quality is job done.” Or “The customer is always right if they pay on time.”

Other organizations subscribe to quality programs like Six Sigma, Lean Manufacturing, Kaizen Technologies, and ISO 9000 or 10000 programs. In these systems the project manager must follow the quality expectations of the organization to show improvements, measurements, and satisfaction.

Planning for quality means that you plan on doing the project work in alignment with the expectations of what constitutes quality.

When it comes to your role as a project manager, you must always—and I do mean always—be on the lookout for any risks that can cause the project to fail. And not just the project manager, but the whole project team.

Risk identification is an iterative, active process. Risk identification doesn't live between launch and execution, but from project launch to project closure. The project manager must stress, must perform risk identification.

But how exactly does this work? Glad you asked.

Most organizations have some risk management procedures in play—even if they're not formally identified. A risk management methodology, in its purest form, has procedures for risk identification and classification, the organization's utility function, and the process for risk analysis.

Ready to test what you've learned so far? Don't worry! This is an easy quiz that you'll do fine on if you've completed the section. Let's go!

Planning is an iterative activity that happens throughout the project. Rarely will the project management plan be created entirely upfront before any work begins. Planning requires time, sometimes a budget, and other experts helping you to make the best decision for the project.

In this section we talked about the most important aspects of project planning: scope, time, cost, quality, and risks. While there are other areas of the project that will require project planning, these five are the most crucial to project success.

All the planning in the world is worthless if you don’t act on those plans. In this section we’ll look at the execution of the project plans and what the project manager’s role is in these activities.

You’ll manage the project team to ensure they’re executing the work properly. You’ll host project team meetings to keep up-to-date with the project team’s progress and you’ll communicate that status to the appropriate stakeholders. And speaking of stakeholders, you’ll also work to keep them engaged with the project.

Ever hear the quip, "Plan your work and then work your plan?" This is the working part. The executing process group is the project team executing the project work according to plan—and the project manager working with any vendors who might be involved in the execution or support of the deliverables needed for the project completion.

Project management is all about getting things done. In this lecture we’ll explore the activities you and the project team will need to do get things done. Let’s get this lecture done!

This won't be a shock to most of you: human resource management is the most difficult part of project management. Do you ever wonder why, oh why, won't the project team just do what's been asked of them? Do you ever wonder why management won't give you more power to help the project team get the project done? Or why you can't have all the resources you need to get this project done?

I bet you have. I bet you've asked countless other questions related to human resources. It's a tough business and whether we like it or not our project team, our workers, and our colleagues look to us for two things: leadership and management.

Management is concerned with getting the job done. Leadership is concerned with motivating, aligning, and directing people. All the above info is accurate, interesting, and great for any MBA class, but to apply it, well, that takes experience and talent. No jokes here.

How many meetings have you been to that have been a complete waste of time? I call those WOT meetings – Waste of Time meetings. People know they need to meet to discuss the project, but they’ve not prepared the meeting to accomplish any particular goal – something you don’t want to experience.

In this lecture we’ll examine how you can prepare to lead an effective team meeting. Team meetings are something you’ll do on a regular cadence, so it’s vital to set the stage and to set expectations for each meeting to save time and to garner valuable information.

Stakeholders want, need, demand to know the project status. Communication, of course, is more than just talking. Communication is also listening. When it comes to project management, communication takes up 90% of a project manager's time.

Real communication is about transferring knowledge. You know something and you tell someone else, and then they know it. But it doesn't always work that way, does it? Communication is tough. There are two big categories of communications you’ll utilize as a project manager: written and oral.

In this lecture we’ll examine the communication practices for keeping stakeholders informed about project status.

Every project manager knows that you need to manage the project team, but did you know that you also need to manage your stakeholders? Managing stakeholders is all about communication – communicating what’s happening with the project, but also addressing stakeholder concerns.

Managing stakeholders is also about keeping stakeholders engaged. You want stakeholders to be excited about your project and to keep stakeholders bought into the project vision. You do not want stakeholders to lose interest and drift away from your project.

Ready to test what you've learned so far? Don't worry! This is an easy quiz that you'll do fine on if you've completed the section. Let's go!

Project management is all about getting things done, and that was also the main thrust of this section. Great job finishing this chunk of the course.

In this section we discussed several items:

• Doing the project work
• Managing the project team
• Hosting team meetings
• Communicating the project status
• Managing stakeholders

Way to go! Let’s keep moving forward!

Control freaks need not apply. Controlling isn't about micromanaging—it's about compliance with the project plan. There's a required balance between execution and control. The project manager works with the project team, not over it, to ensure that it's doing the work as it was planned. And if not? The project manager makes corrective actions to get the project back in alignment with the project plan.

Controlling is also about balancing the time, cost, and scope constraints as the project moves along. The project manager has to measure, compare, and adjust controls within the project to ensure project success. If we do not measure, we cannot improve.

The project team can have the largest influence on the project success or failure. The project team can do the work correctly or they can rush, make mistakes, be sloppy and totally wreck your project!

In my experience, most project team members want to do the work correctly - and it's important for us, the project managers, to not get in the way of their work. We want the individuals on the project team to take pride in what they're creating, but we do need some monitoring and controlling of the project team throughout the project life cycle.

You've planned for communications and now you're following your plan. But you have to listen to what's being said. I don't know about you, but I have two ears and one mouth. I've heard that this means I should listen twice as much as I talk. I have to listen to understand and receive the messages being sent to me.

As a project manager, you have scores of communication channels. And within your project there are potentially hundreds of communication channels. The larger the project, the greater opportunity for communications to break down. That’s why controlling communications is so vital to successful project management.

You now know that stakeholders are the people and groups that have a vested interest in your project. These stakeholders can affect your project, and they can be affected by your project. Keeping stakeholders engaged is important as you aim to keep stakeholders on-board, excited, and supportive of the project.

In this lecture we’ll examine some approaches you can take to keep stakeholders engaged in your projects. Let’s go!

Ready to test what you've learned so far? Don't worry! This is an easy quiz that you'll do fine on if you've completed the section. Let's go!

We talked about many different topics in this section, but the main theme is that the project manager works to control all aspects of the project along with project execution. In this section we discussed:

• Controlling the project work
• Managing changes in the project
• Balancing time, cost, and scope
• Controlling project communications
• Keeping stakeholders engaged

Great job finishing this section on project control. We’re so close to wrapping up the entire course – let’s keep moving forward!

While most of the closing activities are focused on closing the entire project you should also know that you may have to close down a phase of the project. This is common in larger projects where the successful closure of one phase allows the next phase of the project to begin. While all of the project phases are connected, it's the closure of a phase that signals progress and usually creates an accepted project deliverable.

Let's take a look at the processes and activities you'll do to close down a project phase in this lecture.

So how do you know when the project is done? Some would say when you run out of money or out of time. To some extent, that's true—if the planning has been done accurately, the project should end on time and with no remaining funds. But this is supposed to be a realistic discussion on project management.

Projects are finished when the project scope has been completed. A project is complete when the project scope equates to the present state. A project is complete when the project manager and the project customer can take the WBS and check off each item like last week's shopping list. This is scope verification and leads to customer acceptance.

Scope verification is simply the project manager and the project customer inspecting the project deliverables to ensure that all the promises in the project plan exist in the project deliverable. There may be some rework, corrective actions, or last-minute change requests to complete the project; if all goes according to plan, the project manager and the customer are in agreement that the deliverables equate to the project scope.

The final step in closing the project is to officially close down the project. This means you’ve completed everything and the customer has accepted the work, right? Well, usually. It’s possible that a project could be cancelled – and then you’d still need to shut down the project.

Project closure includes filing a final report and performing a final review meeting with the project team. Closing the project properly helps future projects based on what you and the team have learned from the current project.

Ready to test what you've learned so far? Don't worry! This is an easy quiz that you'll do fine on if you've completed the section. Let's go!

Successfully closing a project is a wonderful feeling. In fact, I’d wager it’s one of the best feelings and aspects of project management. In this section we talked about the three big things concerning closing a project:

• Closing a phase (phase gates, validation, acceptance)
• Customer acceptance
• Closing the project

You did it! Great job finishing this course on Beginning Project Management. We’ve covered a lot of material in this course:

Projects are short-term endeavors to create a unique product or service. Projects are out of the normal duties you do as part of your operations. Projects are constrained by time, cost, and scope—and other constraints such as regulations, resources, or even vendors.

The Iron Triangle of project management posits that all projects are constrained by time, cost, and scope. If one angle of the project is out of whack, the whole project suffers.

Projects (and, technically, even project phases) move through five process groups: initiating, planning, executing, controlling, and closing. Each process group has key activities that lend to a successful project. I believe the most important group is planning. Without planning, the project is destined for failure.

In this lecture we’ll recap all of this exciting information to help make you a more productive project manager.