Project Management Essential Training

In this lecture, we're going to define what a  project is, talk about the general approaches to project management and  discuss the skills and tools necessary to manage them.

First, let's define what a project is?

A project is a unique endeavor that has a specific goal, a beginning and an end, and usually a budget.

Let's break the step down into its components:

• First,  each project is unique: say you have the blueprints for house design  (you might think that the work is the same every time you build that  house but each construction project is just that: a project. Where you  build the house or the weather can make a big difference in each  construction project. A big snow could delay excavation, require careful  concrete pouring, or modification to the roof structure to handle snow  load; so each construction project is unique)

  
  

• Second,  a project has a specific goal to accomplish; maybe the project is  supposed to solve a problem like reducing cost in your company or take  advantage of an opportunity like re-proposing your company's product to  increase sales; the project has a specific goal.

  
  

• Third,  a project has a beginning and an end; if a project seems to go on for  ever, it could be doing just that, because you haven't define the goal  clearly enough. The goal of the project is crucial for identifying when  the project is done.

  
  

• Fourth, most projects  have budget, most of the  time you think about money when you hear the  word "budget",but you're likely to face other constraints on project  such as resources, or time.

Finally  it's important to  know that a project is not operations, operations is work that is the  same day after day producing the same results, for example, I was in  charge of the technical support group at a software company,every day  our team opened and closed support requests, each support request was  unique? but we basically perform the same tasks day after day: this was  operations. However besides my operational work I was giving the task of  modifying our system and taking advantage of our international offices  so that we could begin providing 24 hour technical support. I was giving  a specific goal, a beginning and end date and a budget; this was  clearly a project.

Many project managers get their stars because they're good at making things happen, but project management is more than showing off your organizational skills and supervising others. Project management can be summed up as answering a few crucial questions.

• The first question you have to answer is: what problem are you solving? the best draw to a successful project starts with knowing what you're trying to do.

• The second question is how are you going to solve this problem? whither you're solving a problem or pouncing on an opportunity you might have to choose from several possible strategies.

• The next question is: what is your plan? you need a plan for getting a project done, you have to identify the work that need to be done in detail: How long the work takes? the resources you need and how much they cost?

• The next question is: How will you know when you're done ? clearly defined objectives and requirements are the first step, but you also need to define success criteria, quantifiable, measurable results that show that the project is completed. like a certificate of occupancy for a house, or a sales increase of 20 %

At the end of a project you can answer the last question: how well did the project go? this important step is often skipped: what works well? what didn't? and why ? how could work have been than better ?.

Through out this course we'll be looking at how to answer this crucial questions to increase the likelihood of success for your project and the ones you work on in the future.

The perception most people have about project managers is that they're really organized and good at getting things done. Project managers actually utilize a whole set of skills !

• First: project managers learn technical skills specific to project management. like what goes in a project plan? how to build and find project schedule? and how to measure progress with tools like earned value analysis

• The there is business expertise: as a project manager it is up to you to make sure your project delivers value. you want to make sure that the project achieves the goals and objectives that you identified during project planning, you also need to understand your organization's business: what it does? and what it consider important?

• One of the most important things in project managers toolbox is interpersonal skills: projects typically use people from different groups, departments, and even different companies. You're the leader of this team, so it's your job to motivate your people.

• Strong leadership could be the most important characteristic: you lust inspire your people, guide them to do the right things, and motivate them to give their best.

Does project management sound like something you want to do ?  if so, this course will help you improve your skills, once you know your own strengths and weaknesses you can develop a plan for building up you skill set.

Project management can be categorized into five measure processes to help guide a project successfully from beginning to end. here is  how the project management institute classifies these activities:

• Initiating is all about getting the commitment to start the project, basically we answer the questions: what problem are you solving? and how are we going to solve this problem?

• Planning is where you figure out how you're going to perform the project, we answer the questions: what is your plan? and how will you know when you're done?

The next tow steps involve putting your plan into action,

• The executing process starts with launching a project, you bring your resources on board, introduce them to one another, get them settled in, and explain the rules you'll use to run the project.

• Monitoring and controlling a project is ongoing responsibility to see whither the project is going according to plan, and if it isn't you work out ways to get it back on track.

• The closing process is short but important, you get the client to officially accept that the project is complete, you doculment the project performance, gather the lessons learned, close contract and help resources move on to their next assignement.

In this lecture, we're going to examine two common approaches to project management, we'll also discuss how to identify which method makes sense for your project.

We previously talked about the five main processes in project management.When each process occurs, one after another, it is known as traditional project management, or the water fall approche.

Traditional project management, works well when a project is relatively familiar, the goal and solution are easy to identify, scope and deliverables are clear and you use familiar technology your tools.

Because the project is a known quantity, you can define it clearly, and build a plan for completing it, then you execute the project, and perform the usual activity to make sure the work is done, and the goal is achieved.

With many projects today, you don't know what the solution looks like, so you have to figure it out ad you go along, this type of project requires a different approach. Agile project management goes throw iterations to get closer to and eventually reach a successfull outcome, for example: you might know the project goal, such as replacing  a financial system, but your customer doesn't have his procedures and requirements documented in any way. In this case you can iterate within the project management processes to get closer to what he wants.

In the initiating and planning processes, you define the overall goal for the project, and build an overall plan to achieve that goal. With agile project management, you also define what you're trying to achieve with each iteration and develop the detailed plan for the work in that iteration.

The executing process is often easier in agile projects, because it typically uses small team of highly skilled people who work in the same location. These conditions make it much simpler to get every one on board. With agile project management, you monitor and control the project more closely, and communicate faster and more frequently.

Finally, each iteration has its own closing process for accepting its specific deliverables, then when the final itiration is accepted you can complete the other closing activities, such as closing contract.

You'll determine which approach traditional or agile makes sense during the initiating process of a project; once you know whither or not your solution is clear. we'll discuss the initiating process in the next section.

In this lecture, we'll going to examine some of the software options available in the market that can make your job as a project manager easier.

Scheduling software comes in a variety of shapes and sizes, with the simplest projects, some people use a spread sheet to map out who works on what day by day?

However for more complex projects the most well known desktop project management programs are project and Primavera. both of these programs come with a tones of features for setting up and managing a project schedule.

Other project management programs costs less but still offer impressive toolkit, for example: Fastrack schedule Openproject and @task.

When you think about all the documents you produce during the life of a project, you quickly release that a word processing program is an essential part of your project management software. Although every project is unique, projects still share a lot of similarities, so it's a good idea to build a document template so you don't have to start from scratch every time.

A spread sheet program is another must have for all kind of calculations and analysis, for example you can put together a spread sheet to analyze the risks your project faces and figure out which one you should keep an eye on a presentation program like Powerpoint is usefull when you have to communicate project information at a high level, or when you want to include information from a variety of other types of documents.

Because a project has usually a team of people working on it, you need some kind of tool for collaborating with others, Basecamp and Microsoft Sharepoint are just two of the web oriented collaboration tools you can use to share files with others, keep track of issues or even manage a workflow.

If you work on a very large projects or in an organization that runs dozens or even hundreds of different projects at the same time, then you should consider enterprise project management software.

Enterprise level software, provides tools that allow you to find resources with the skills you need and see which resources are available when you need them. it helps you track risks, issues and other information, and even build document libraries so team members can easily find information they need.

We've only briefly touched up on some of the software available .

I recommend you consider the following in your decisions:

• The culture and work environment of your organization

• Costs

• The number of project you manage, and

• Their complexity

The purpose of the initiating process is to obtain commitment to start project. You want the customer or the management team to be able to make an informal decision whither to move to the planning process without spending a lot of money or time.

During the initiation process you identify the problem that the project is supposed to solve and you gather more information to define the project. This information is presented in a document known as a project definition or project summary.

In many instances you as project manager maybe assigned to the project after it's been approved.

In this section I'll be sharing with you the key elements of a project summery, I'll also discuss identifying the project stakeholders and how you present your project summary to them to obtain approval.

In the first chapter of this course, we've said that every project has a specific goal. The goal of a project is to accomplish something, like solve a problem, or take advantage of an opportunity; this goal drives every decision in the project so you want to make sure you accurately describe the underline problem or opportunity.

You do this by putting together a document called a problem statement. A problem statement clearly defines the problem you're attempting to solve or the opportunity you're attempting to take advantage of. it doesn't have to be along wind to the fear. if you spell out what the problem is in one sentence all the better.

Let's look at some examples:

• Our company has 300 employees and need another 100 people. The current office space can handle up to 320 people. The problem statement is: "We don't have enough space for all our employees".

And one more example:

• We have new product that customers don't know about, our sales have been declining. The problem statement is: "We're loosing sales to our competitors".

Defining a problem can be a challenge because people often jump straight to solutions.

Solutions describe the end result of a project not the beginning motivation. For example end result would be: we need a new building, or we need to increase sales. These are not problem statement but solutions, one way to back track from a purpose solution to the original problem is to ask why? Why do we need a new building? why do we need to increase sales? don't be afraid to ask why more than once and then probe for more details as the story unfolds.

You can use the answers to get to the bottom of the problem and start uncovering more specific objectives for the project.

The problem statement would be: "we don't have enough space for growth or we are loosing sales to our competitors".

Write a problem statement for the project you're working on, keep it simple, make sure you're not writing the solution statement, don't be afraid to ask why and other questions until you have clear and simple statement that defines the underline statement for your project.

In the previous lectures we defined the problem that our project is attempting to solve. Now that the problem has been defined, we need to describe what the project is supposed to achieve. we do this by defining a project goal. A project goal is the high level target that states the end result that the project will achieve.

The goal should be a simple statement and easy for every one to understand, that way you can guide the team to a successful conclusion: for example host a corporate sales event. Objectives further define the goal by flashing out specific details. Identifying objectives is important because they help define the scope your approach and the success criteria you have to meet.

• Business objectives are often strategies or tactics that support your organization goals. For example reduce the return rates on orders.

• Financial objectives are all about money; your organization might require that project deliver a 15% return on the money invested in the project

• Quality objectives specify how good results must be. for instance if your project is supposed to increase customer satisfaction you might want to the number of customer satisfaction ratings.

• Project can have technical objectives; for example you might want to use tough machines that can wish-stand harsh environment.

• Another category of objectives is a catch out called performance. for instance you project might need to finish by a specific date such as your company's product release date.

Now that we've discussed several categories of objectives, let's talk about how to document objectives well.

Specific objectives are clear so there is no miss understanding about what you're supposed to achieve, for example: host an event that reaches 80% of our customers and costs no more than $80'000.

Vague objective are bad because you probably will not get what you want: be specific when you wright your objectives.

Measurable objectives eliminate any question as to whither or not they have been achieved. for instance you can use rating from surveys to measure customer satisfaction.

• Realistic objectives spell out what you can do with the resources available. Setting challenging objectives can motivate people but your team might give up if they think the objectives are impossible.

• Time related objectives identify when they can be achieved for example a new product might need to be available on stores before the end of the year. For time related objective set a clear target date.

Using the problem statement you wrote earlier, now write the project goal that states the end result that the project will achieve, keep it short, simple and easy for every one to understand then write your objectives keeping them specific, measurable, realistic and time-related.

Once you know the goals and objective for the project, you're likely to find that there are more than one strategy from which to choose. In this lecture we will examine how you can evaluate alternative strategies and select the right solution.

• First I recommend that you assemble a small group of people familiar with  the project to brainstorms strategies.

The brainstorming group should read the problem statement the goal as well as the objectives and then begin generating possible strategies, this should be a free flow of ideas.

The point is to get as many ideas written down as possible before you begin criticizing  or evaluating the strategies.

• Once you have a significant number of strategies written down, you'll need to begin evaluating those ideas,

You can use a decision matrix to compare your options.

• First the group should ask how well does this strategy satisfies the project objectives. One way to quickly shorten the list of contenders is to check whether the  strategy satisfies all the must have objectives. If a strategy doesn't satisfy one of your must haves, you don't have to fill out the rest of the values for that strategy. Next, for the strategies that pass that  first test read the performance for each objective. if some objectives are more than others you can increase weighting.

The strategy with the highest overall weighting is most likely your winner.

• Second, the group should ask, is this strategy feasible? strategies that use new technology or unproven methods might not work. If feasibility could be an issue, a feasibility study can explore whither the strategy will work without committing too much time or money.

• Third, ask: Are the risks of this strategy acceptable? you won know all the risks at this stage of your project, but you can perform an initial risk analysis to see whither any risks are so significant and likely that  you don't want to proceed.

• Fourth, ask: Does this strategy fit the culture of the organization? trying to force a strategy that doesn't fit with the culture is a loosing battle, you won't get the commitment you need for management or team members, remember: the strategy you choose has to satisfy most if not all of the project objectives. Once you select a solution, from the alternative strategies the details of your project will start falling in the place.

The goal, objectives and solution for a project identify what you're trying to achieve and the general approach for getting there.

Requirements provide the details of what the outcomes must look like, they're the specific needs of the project.

Gathering requirements is important, because if you miss true requirements, the customer won't be satisfied with the project results. On the other hand, if you include requirements that aren't really necessary the project will probably take longer and cost you more than it should.

For the corporate sales event one objective is to showcase both new and existing products. One of the requirements could be to include all the selling points that the sales team identifies in each presentation. Another requirement could be to use the organisation brand terminology in all presentations. These requirements are both necessary and detailed.

Gathering requirements can be challenging, sometimes customers know what they want and sometimes they don't.

Customers and stakeholders often mix wish list items with true requirements. Another hazard is people who aren't stakeholders often append their requirements on to your to do list.

As the project manager to have to distinguish between true requirements and false requirements. There are several techniques for gathering requirements, each technique has its pros and count. The best choice of technique depends on your project:

If your current project is like one that's been done in the past then try reusing existing requirements. To do this you'll need documentation from that project. Determine whether some features have become obsolete or new ones have cropped up.

Another way to flash out requirements is to build a prototype: A prototype is usually a quick and rough model that your customer uses to test out an idea. A prototype is great if your customers aren't quit sure what they want.

Business process modeling and use cases are examples of methodologies for gathering requirements about processes and systems. You may have to train people on the methodology first or hire people experienced with the tools.

If your project involves several groups you can hold requirement meetings with representors from each group to discuss their requirements for the project. These meetings non only help identify requirements, but offer the advantage that you may also obtain by in from the departments that attend.

You might wanna hold separate meetings for different audiences such as the business team, and the IT department.

In some cases you might have one group attend to listen to what other groups need. If you're working on a project to"reveal" how people work, you can work with the end users directely.

One approach is to conduct observations, in other words watch what people do in their day to day  activities. To make sure you get the requirements right, write them up and review them with the workers. You can also interview people: It's a good idea to put together specific questions for the first round of interviews, that way you ask every one the same questions and don't leave anything out. A second roud of interviews can help clarify and refine the requirements.

With your goal in mind document your requirements by writing detailed statement of what must be accomplished in the project to satisfy the objectives.

People expect to get something when a project is done, these results are called deliverables.

Deliverables are products or services that are delivered. deliverables can be tangible like a building, software, or a new employee.Other times are more abstract, like a new service.

During the planning process deliverables help you to find the project scope, which basically means what is and isn't included in the project. Once your project gets under way delivrables then help you measure progress.

Write down what the deliverables for your project are. begin with the end deliverables which are the goods or services that your project delivers at the end of the project. For example, for our corporate sales event, an end delivrable would be print 1000 sale brochures to be handed out at the event.

Next, document your intermediate deliverables, these are items or services that are delivered during the course of the project. For instance if an end deliverable is print 1000 sale brochures an intermediate delivrable would be sign a contract with the printer company.

Keep in mind that the customer doesn't necessarily receive the intermediate deliverables. Whenever possible, try to define deliverables that can be accomplished in the time for in between status reports, that way you can evaluate progress based on the delivrables completed since the last report. If a deliverable is too big, you could go months without really knowing where things stand. Break up your deliverables into manageable pieces.

So  now that you have defined your deliverables, how do you know that the deliverables you receive are what you want it. You need someway to measure them.

Success criteria are definitions of success, something easy to figure out like: sign vendors contracts or the certificate of occupancy for a building. Other criteria are not so easy and can be subjective, therefor to be effective write success criteria that are clear and quantifiable.

For the sales event you might write success criteria that indicates the number of customers you will attend, the number of products that will be sold at the event, or a target rating on a survey about how likely attendees are to purchase your products in the near future.

Identify the end deliverables for your project then identify any intermediate deliverables you expect to receive, once you have deliverables documented define success criterea that are clear and quantifiable.

It is important that you protect your project by identifying assumptions and risks early on.

Let's start with assumptions: an assumption is something that someone takes to be true without confirming it. Different people can make different assumptions and if those assumptions aren't brought into the open someone will end up disappointed.

For example, if you assume that the marketing department is going to send invitations to the customers and marketing assumes sales will do that task, everyone can find out too late that no body sent the invitations and customers don't know about the event.

Assumptions can be tricky, because people don't often realize they're assuming something. The key is to get assumptions out in the open. That way, you can make sure everyone is on the same page. Think about uncovering unspoken assumptions as you work through every step of the project plan.

Ask questions about what people expect, what the invasion when they think about the project. Don't be shy about asking more than once.

Uncovering unspoken assumptions is almost being like a detective, you ask again and again to see if the story changes.

• First, ask people to describe the results expect from the project, ask them to describe project success. This helps identify objectives that may have been unspoken. If the list you end up with out-steps the budget or resources you have available.

• Let's now discuss risks: a risk is a situation or event with some probability of occurring that might negatively affect your project. Risks are event that may or may not rise; but will cause problems if they do occur.

Early on in the project, spend some time identifying risks that could affect the project, mainly so the management team can make an educated decision about whither or not to invest in the project.

If you identify numerous risks, and several are quit worrisome, it may be better to forgot the project for another one.

After you document requirements and deliverables, create a scope statement so what the project is going to do is crystal clear. The project scope actually describes the boundaries of the project, that is what is included in the scope of the project and just as important what isn't included.

A scope statement helps you evaluate whither a project is doing what it should no more and no less, and whither the budget and other aspect make it worth while.

Here is an initial scope for the corporate sales event: as you can see the scope statement covers the work and deliverables for which the team is responsible. Your scope statement can also include an out of scope section that indicates the work that is not the responsibility of the team.

Suppose the trade show organizers to take care of running electrical services and deliver your shipment to where your booth is located on the trade show floor. In that case you can define the scope so your teams know what they do and what the trade show people do. The out of scope section is a good place to document assumptions about what is outside the boundaries of your project.

A scope statement also helps to prevent a project from expanding. Scope creep is the name for this well known hazard in the project world.

Customers and team members alike might come up with this one little thing to add to the project but those little things add up and before you know that the scope is expanded beyond your budget, beyond your resources, and pass the due day. With a clear scope statement you know what's within scope, if someone wants to add something, you can discuss the impact to decide whither or not it makes sense.

Because a scope statement defines the boundaries of the project at a high level you also need a change management process,to control the smaller change requests that come in; we'll cover the change management process in the next section; Sometimes, members of your team end up expanding the scope without you knowing about it, perhaps the programmer adds a feature that she's sure the customer want, even if it isn't in the requirements.

When you assemble your project team, emphasize the importance of the scope and the project objectives, revisit your objectives and deliverables and use them to write a scope statement that identifies what is and what is not within the scope of your project.

Then review your assumptions and if necessary add items to what is within scope or out of scope for your project.

The term stakeholder means someone who has a stake in the outcome of the project. This includes the customer, the departments affected by the project, and even people who work on project tasks.

Sometimes, it can be challenging to determine who the stakeholders are for your project.

First, Let's identify measure stakeholder roles: the project customer is the personal group who has a problem to solve. The project customer bring three  crucial things to a project:

• First, the customer funds the project;

• Second, the customer has a lot to say about what the project will do;

• Third, the customer approves deliverables from start to finish.

• The next stakeholder roles is project sponsors. Sponsors are people who want to say the project succeed and have enough formal authority to make that happen, like an executive who believes in the project.

A sponsor can help prioritize objectives, talk to stakeholders who aren't being supportive, and suggest improvements to the plan.The third type of stakeholders is functional or line manager. Functional managers run departments and accountable for achieving their departments goals, They also manage the people in their departments who are the very same people you need for you project.

Finally, team members are also stakeholders, while assigned to your project, their jobs depend on their assignments and how well they perform.

Now that you identified your stakeholders, how do you work with them effectively?

First, you need to know what motivates your stakeholders and how they're connected to your project. You can store information in a stakeholders analysis document, start by including the department, business unit or company the stakeholder belongs to;

• Determine who the stakeholder listens to, that can help if you need to explore ways to deal with an issue with the stakeholder.

• Identify the project objective that the stakeholder cares about and their priority, that way you know who to talk to if an issue comes up with an objective.

• Finally document the stakeholder contribution to the project so you know what to expect from him or who to turn to for things you need.

Remember, stakeholders are crucial to the success of your project.

Now that the project is defined you need to get approval from stakeholders to proceed to planning. Obtaining approval is important because you need commitment from project stakeholders to make a project a success.

Once you have the initial project summery you might think about getting approval by mailing or E-mailing a packet to stakeholders and asking them to sign on the dated line, I DO NOT RECOMMEND YOU DO THIS, the problem with that approach is that people don't read through the packet. they might sign their names, but if they find something they disagree with later, their commitment disappears and you're back where you started.

A face to face sign off meeting is more effective. Schedule a meeting specifically for obtaining approval. The agenda for the meeting is straight forward:

• First, review the project summery that you've put together to make sure that the stakeholders agree with it. If any issues come up deal with them right then and there, Or if the issues are big enough you might have to reschedule the sign off and go back to rework the document.

  • Once every one agrees ask them all to sign a signature page to indicate their approval. If you can get every one in the same room a video-conference or a conference call works too

• Ask people another location to transmit their signatures to you by fax, email or "snail" mail if necessary.

Signing a project summery isn't like signing a legal document, you'll probably never going to come back to your stakeholders and say "would you sign this!!!".

What is important is that the stakeholders understand what the project is about and buy into it.

Now that the project is approved the final step of the initiating process is writing a project charter.

Project managers don't have the kind of authority that managers in the structured organizations do. Project manager's authority "less" as more as the project stay managed and applies only to those projects. for that reason, it's important that people understand what a project manager is authorized to do.

A project charter is the vehicle for doing that. typically, your project sponsor publishes your project charter to formally announce the project and to communicate the responsibility and authority that you have as the assigned project manager. the typical project charter includes the following items:

The name of the project, the purpose of the project, a one sentence summery of goals and objectives will do, the name of the project manager, the project manager's responsibilities including a brief description of the work that project manager does, the extend of the project manager's authority and the specific work the project manager has authority to perform, such as requesting resources, or signing contracts, a formal declaration of the sponsor's support for the project.

Think of this declaration as a power of "a journey" given to the project manager by the sponsor or customer. When the project charter is ready to go, the project sponsor distributes it to every one affected by or in someway involved in the project. Unlike the project approval meetings, the publication of the charter can be via email or the preferred method in your organization.

Once you have approval to start planning the project and your authority as project manager is a common knowledge, you're ready to begin the planning process.

During the planning process, you identify the work that must be done, who's gonna do it, how long everything will take, when things will happen and how much it will cost.

You also plan how you run the project, such as how you'll communicate, manage change and risks, and insure quality. All of this information goes into a documents that together represent the project plan.

You use the plan once the project work get started to direct the people working in your project, to keep track of how the project is going, to correct course if need be.and to communicate with team members and management.

In this section, I'll be sharing with you the components of the project plan, and because a project schedule is a key component of your plan, section 4 is devoted to how you build one.

After you get to get the go ahead to start planning your project, the first thing you do is identify the work that has to be done.

A work breakdown structure or WBS is a tool you use to devil-up project work into "bite size pieces" so you can plan, track and manage your project effectively.

Creating a WBS helps the project in several ways:

• First, it is easier to estimate the time and cost for smaller chunks of work"

• Second, it is easier to assign work, to team members,

• Third, by breaking work into smaller pieces, you build checkpoint into your project that allows you to measure progress.

A WBS contains two kind of tasks: Summery tasks and work packages.

• First, summery tasks are the higher level tasks that summarizes project work in someway.

Summery task can describe each process of the project including planning the event, preparing the materials, making the arrangements and finally holding the event. The number of levels of summery tasks depends on the size of the project. A few levels is probably enough for small project. With a large or complex project, such as developing a new airplane you could have many levels of summery tasks.

• Second, work packages are the lowest level tasks that spell out the details of the work that needs to be done.

In our example, under preparing materials, work packages would include: creating sales materials, creating presentations, and printing materials. The work break down structure is the key to planning out a project and managing it effectively. Now that we understand what a WBS is, and how it is structured, let's look at how you build one..

In the previous lecture we defined what a work breakdown structure is, now I'm going to explain how to build one.

The best way to build a WBS is to start at the top and work your way down, by top I mean the top level of the summery tasks. For larger projects you might work as a team, to identify the top couple of levels of summery tasks, then the team can split of into smaller groups to breakdown the work for the summery tasks; At the end everyone gets back together to review the results and correct any issues. Start by using the scope statement and deliverables to identify the top level summery tasks..

For example: since the sales event scope including attend trade shows and producing new sales materials you add summery tasks to cover those.

Next, breakdown the work that makes up each of the summery task. This is where the intermediate deliverables come in handy for identifying lower levels summery tasks, and work packages.

For example the sales project includes deliverables for sign contracts; Add task to prepare, negotiate it, and sign the contracts.

The question you might be asking at this point is: how much breakdown is enough ?

One approach is to breakdown project work to much the frequency of your status reports, so you have measurable progress and completed tasks for every status report.

The rule of thumb most project managers use is to shoot for work packages that take between 8 and 80 hours to complete. You can use the following test to determine whether you have broken work down to the right level!:

• Time and cost are easy to estimate.

• Status is easy to measure.

• Task duration are shorter than your reporting period

• And the detail is at the level that you can and want to manage

Different parts of the project might require different levels of decomposition: One part of the project might include more work so you break it down to three levels. If another part of the project is simpler you might need only two levels.

Finally, don't worry about the initial organization of your WBS, you could review it later on, to see whether you want to rearrange tasks.

Now that you've build the WBS you need to make sure your team understands it. A short name in a WBS typically isn't enough to tell people exactly what they're supposed to do.

To make sure your team knows what to do, create work package documents that describe the work identified in the WBS in detail. The level of detail you include in the work package document depends on things like how familiar the work is and perhaps the experience of the person assigned to the  task.

For example, a work package document might include a check list of things to do, which helps a less experienced person understand their assignments but serves as a reminder for a more experienced individual.

You don't have to include every detail in the work package document. If the specifics of the work are described somewhere else you can refer to the other document that contains the information.

A work package document does more than describe the work, it also identifies how you know the task is complete? and whither it was completed correctly. For some task you can include the corresponding deliverable and success criteria in work package document. Otherwise write up a description of what you will have when the task is complete and what it should look like.

Finally, you've probably figured out that you, the project manager, don't know enough about every aspect of the work to produce this detailed description for every task. Turn to the people who helped you build the WBS: Team leaders for groups that will work on the project or other knowledgeable people to help filling the details. If you get the details right your team is more likely to know exactly what to do..

A WBS identifies the work people have to do, to complete the project but it doesn't tell you how long the work will take or when it can be performed.

To do that you need to turn your list of tasks into a schedule:

• First, put the tasks into the right sequential order, that is you have to specify which task have to finish before other tasks can start, which tasks start or finish at the same time and so on. For example, you can't load computers with sales presentations until the presentations are complete and working properly.

To get tasks into order, you specifies the dependencies also called links between tasks in your project. The most common is finish to start but you can choose from several types of dependencies as I will explain further in the lecture "creating dependencies between tasks"

• Second, you need to estimate the time each task will take. The time estimated you put together for each task and the order in which tasks occur help determine how long the entire project will take. Reasonable estimates are key to figuring out when a project can finish. You have to estimate as accurately as you can because under estimating and over estimating both lead to project problems.

  
  

• Third, you need to identify people in your project team and assign them to tasks. with the estimated hours and the people assigned to do the work, you can calculate the task duration.

  
  

• Finally, take into account other constraints such as deadlines. If your initial schedule doesn't quit do what you want, you can tweak it in a number of ways whither you're trying to shorten the schedule, cut costs, or assign available people. The schedule is one of the more important aspect of your project, it tells you how long the project will last and when you will need the people who will do the work.

As project manager, you should understand every person's role and responsibility in the project, likewise your team members should know the chain of command and understand their own personal roles and responsibilities within that chain.

• First, create a responsibility matrix. Responsibility matrix spells out who can make or approve decisions, the groups performing works, and which group needs to be consulted or informed of what's going on. A responsibility matrix includes four categories of responsibility:

                   R: means that the group is responsible for performing work

                   I: represents informed, which means a group gets information

                   C: means that you consult the group about decisions, However, they aren't accountable for the decision that's made

                   A: is for accountable, which means the groups makes or approves decisions and delegates work.

• Next, review the responsibility matrix with stakeholders during planning, and work out any disagreement before work get started. If a part of your project doesn't have an owner, talk to the stakeholders, and your project sponsor to determine owners of the offend areas. If you use resources from other organizations, such as with outsourcing, subcontracting and partnering arrangements, document how all this groups contribute in the responsibility matrix.

• Next, create a project organization chart,  which shows the hierarchy and reporting structure for people involved with or working in a project. Your project organization chart identifies the chain of command so you know who to talk to if you need to escalate a request or decision.

• Finally, identify the type and number of skilled team members the project requires. A skills matrix is the tool you use to determine these requirements

  To build a skills matrix:

  
  

  1. First, examine your work packages and identify the skills the package requires.

  2. Second, create a matrix with your project tasks and roles and the skills you need in the columns

  3. Third, check boxes in the matrix when tasks require specific skill. The number of check boxes for a skill helps you identify how many people you need with that skill.

  4. Fourth, estimate the labor cost of the project. To do this, assign a typical pay rate to each skill, then multiply the number of people by the pay rate. This will give you an estimate of the labor cost for the project.

You, now, have an idea of skilled team members your project requires as well as an estimate of the labor cost.

Most projects boil down to money, making it, saving it, or the very least staying within a budgeted amount. The total cost of a project, that is the budget, is almost always important.

As a project manager, you estimate the total project cost, by calculating the cost to complete all the work. In some cases you present that budget to management and they decide whither the project makes financial sense?

In many instances, however, you receive a target cost from the management team, then it's your responsibility to figure out how to plan the project to stay within that budget.

Now that you understand your role in building a budget , it's time to examine the costs that make up a "project price tag"

• First, labor costs are, usually, a big part of the project cost. If you hire vendors or contractors, their charges go directly into your labor cost. Including employees cost is important because they contribute to whither a project makes financial sense.

  For employees, you use the burden cost, that is salary and employee benefit which you can obtain from your human resources department

• Second, project could use other types of time-based resources, such as equipment or office space that you rent. Include these equipments and other time-based costs in your calculations.

• The third type of costs is material cost, such as the paper you use to print sales materials or the construction materials for a building.

• Finally, be sure to include other types of ancillary costs that don't fit in the previous three categories. For example: travel, training expenses, and registration fees, fall into this catch all category.

Money is almost always a consideration with projects, you might need to know only whither the price tag is within your budget or you might have to show that the project delivers the financial benefits that your organization expects.

Every project faces risks: if you don't plan for how you will deal with them you end up putting out fires which can cost your project time and money and increase the pressure on your people.

A risk management plan is the tool you use to plan for the risks you might encounter. With a risk management plan in place you've already decided how to respond when risks become reality so you're ready to make informed and prudent decisions. To build a risk management plan:

First, identify the risks your project faces. Risks you're aware of are called known unknowns such as cancelled flights  or mistreated  shipments.

To help you get started here is some examples of things that can introduce risks to project. Technology might not work the way it is supposed to, costs more than you expect or not show up when you need it.

Team members located in different areas can increase risks, such as delays due to time zone differences, miss communication due to different languages, or cultural differences or lack of team work because remote team members can't develop effective work and relationships

Lack of details such as specific undeliverables, due date, or who will work on your project can leads all sorts of problems. Limited options such as needing people of rare skills, increase risk because you don't have alternatives if the problem arises.

• Work with everyone on your team to identify risks.

• Talk to the experts for different parts of the project about the risks "safe or see"

• Ask key people on the project what they think ?

• Ask other project managers about risks from similar projects

• Sell out a risk information form with what you know about each risk you identify

• Document specific about the risks,  for example; which tasks are affected? what objectives are in danger?  what the consequences are? and so on.

Up until now, we've covered identifying risks we can anticipate, but what you do about the risks you can't forced called unknown unknowns: These risks come from situations that are so out of this world and they've never occur to you. For example, prior to the invention of the personal computer, manufacturers of typewriters probably didn't foresee the risks to their business.

Because you can't identify these risks, you handle them by setting a side contingency funds for dealing with them, like having an assurance policy. Contingency funds are commonly used method for responding to small risks and the unknown risks you can't foresee. The question is how much should you set aside ? Many companies use a percentage of the project budget, but the percentage used is typically based on past experience.

Now that you've identified risks your project  may face, you need to evaluate risks and determine how you plan to respond to them if they occur.

After you identified risks, the next step in developing a risk management plan is to assess each risk  you've identified.

• To assess risks you ask two questions: what is the likelihood that the risk will occur?  For example, if a trade show takes place in Denver in March the likelihood of bad weather and cancelled flight is high.

• The second question is: how big is the impact if it does occur. For example, if bad weather prevents your sale teams from arriving the impact on your sales event is significant.

• Ask the same people who helped you identify risks to assess the probability and impact. After you assess all the risks, the next step is to prioritize the risks and decide which one you will manage. If you use low, medium and high; you might decide to manage risks if they're medium or high in either probability or impact.

• The next step in the risk management plan is to decide how you respond to each risk in your plan.

Here are some risk responses you can use: The easiest option is to simply accept consequences, that's fine for risk with low probability and impact. Another option

for less significant risks is to use contingency funds to address the issue. Avoiding risk is another option; For instance, changing the project scope to remove the risky part of the project or flying the sales team out several days in advance.

Mitigating risk means taking steps to reduce the consequences. For example, you can ship backup computers to the trade show in case some of them don't work.

Transferring risk simply means handing of the risk to someone else, like  you do when you purchase insurance. When you choose your responses make sure they aren't over-call. If the impact of a schedule delay is a 500 dollar lade fee it doesn't make sense to spend 5000 to prevent the delay.

• The final step in a risk management plan is defining how you will monitor risks and measure responses. You create a risk log with information about each risk you plan to manage, this log summarizes your plan for the risk:

A description of the risk , the events or circumstances that trigger the risk, the response you've chosen, who will monitor the risk and the result you expect from the response if you have to use it.

You create a risk management plan during the planning process then you implement that plan once the project is on the way.

Good communication is crucial to the success of the project. If your project is large and complex with people working around the globe, good communication is even more important.

During planning, you put together a communication plan that helps you get the right information to the right people in the most effective way.

• First, identify your audiences, that is who needs to know about the project? the responsibility matrix is a good place to look to find your audience.

• Second, define what do your audiences need or want to know? Management stakeholders typically care most about a project achieving its goals. During planning you communicate the project plan to do that. When project is on the way, you communicate progress, how much you've spend, and the overall project result.

  The project sponsor is more tightly connected with the project, so you'll probably communicate with the sponsor more often and perhaps use frequent face to face meetings.

Functional managers initially need to know the skill sets when you need them and the other things like cost constraints. When people are on assignment, these managers wanna know whether the assignments are going according to plan and how long their people are going to be on the assignment. Team members need to know what they're supposed to do,and ideally how that fits into the big picture. As they complete assignments, they also need to know what's on "deck"

• Finally, the last part of the communication plan, is how you distribute information to your audiences? that is: how often information is exchanged? how it is sent and the format you use?

  Face to face communication is good for brain-storming, getting know people, and discussing sensitive topics.

  If your team is dispersed geographically, Email, conference calls, and video-conferencing are indispensable.

  Documents are good when you have to send a lot of information or people need time to do adjust the information they receive.

You define your communication plan during the planning process, then  once the project is on the way you implement that plan so your audiences get the information they need as efficiently as possible.

When you plan a project, you also have to consider the quality stakeholders want from the project deliverables or final product. You develop a quality plan in order to help your project meet that quality standard.

For a project quality translates into meeting customer's requirements, and delivering on time and within budget. If your project includes deliverables or products quality also means those products or deliverables conform to specifications.

A quality management plan is made up of three processes:

• First, identify the quality standards for deliverables. For example the quality plan might include the acceptable tolerance for the dimensions of the final product or the acceptable number of defective products in a "batch"/. Keep in mind that the goal is for quality to meet the standards you've set, obviously you don't want quality that is below standard. The customer won't be happy, might ask for additional work to deliver the right result or simply may refuse to pay.

  However, you don't want quality that's higher than required either because other aspects of the project can suffer such as the schedule lightening or costs expending.

  
  

• Second, define a quality assurance plan, that is document how you will demonstrate that the quality standards have been met, for example, you might spot test the product coming of the production line to statically determine the number of defective product in a batch; Although it isn't a separate quality process you can also plan your project to prevent defects in the first place, for example: you might opt for a simpler design that makes it easier to manufacture a product and thus reduces the number of defective products that come off the assembly line.

  
  

• Finally, the quality control process is how you will monitor and measure the quality of your results. Inspection goes by a number of names, review, walk through and audit to name a few.

The bottom line, is that you examine or measure results to see if they meet the standard set. Continuous improvement is a big part of quality management, if you find a quality issues you also analyze the problems to see how to prevent them or at least reduce their frequency. For example, cause and effects diagrams also called fish "ban" diagrams because of their appearance help identify factors that could lead to problems, which in turn helps you figure out ways to prevent the problems.

Another tool is a PARETO diagram,, which shows how many defects are generated by each cause. The diagram lists the causes by the number of defect they generate, so you can address the causes that produce the most defects first.

During the planning process you define the quality standards that are required, how you will measure quality, and how you will determine that the results meet the  quality standards you set. Once the project is on the way you begin monitoring and measuring results and evaluating whether they meet the quality standards you set.

One at a time request for changes can seem small, but those small changes add up and can completely derail your project schedule and budget. Changes are unavoidable so the only solution is to manage them:

• First, you have to know the items that you want to control, such as the project scope, requirements, or the entire project plan. The versions you control are called the baseline documents. For example: if you have an approved list of requirements for the project, that's your baseline, if new requirements are suggested you can use your change management process to decide whether or not to add them to the project plan. Keep in mind you don't use change management on draft versions of documents. When stakeholders sign off on them that's when they go under change management.

• Next, you need a group that reviews change requests and decides whether to approve them. This group is called the change review board; as usually made up of key stakeholders: such as the customer, functional managers, and team leaders.

  Then you need to define a change management process to use when someone requests a change. Here is one example of a change management process.

  The first step is submitting a change request: standardized change request form that people fill out makes it easier to evaluate changes because each request has the information the review board needs to evaluate and make decisions, typically a change request form includes details about the request to change, the reason for the change, the business justification and the results it should produce.

  In the second step, the change review board reviews submitted change request. The board may reject the change request, they might ask the requester to provide more details or revise and resubmit it or they may accept the change request. If the board accept the request it moves to the evaluation step.

  In this step someone has to evaluate the impact of the change. As project manager you can assign this task to someone on your team. The evaluator looks at different ways to handle the request and determines the impact of each alternative. The result of the evaluation is a change request impact statement, which outlines the alternatives and their impact and might include a recommendation for how to proceed.

• The fourth step is when the impact statement comes back to the review board. If the board approve the impact statement you add the request to the project plan. Whether the decision is yes or no, be sure to notify the person who requested the change. If necessary you perform a fit step in which you update the baseline documents. For example, your project might need new tasks added or deadline extended for specific task.

• Finally, you track where change requests are in your process. You can use the change request log to record the status of the submitted change requests.

  As a request works its way through the steps you update the log with who's in charge of the request, The impact estimate, current status and at the end actual impact. You don't have to send every change request through the change management process.

  I recommend you set Thresholds so team leaders can decide what to do with smaller requests. Finally it's also a good idea to have a process for emergency changes that need a rapid decision between meetings of the change review board.

Estimating time and cost accurately is important because those estimates affect your project schedule and budget which, in turn, could determine whether it makes sense to run the project. If your estimates are low  a project might get approved when another project will deliver better results, in addition low estimates make meeting expectations almost impossible. If you estimate too high, a worth while project might not be approved or a project could take longer and cost more because people tend to take time and money you give them.

Estimating accurately is challenging because estimates are nothing more than educated guesses. They're too things you estimate in projects: time and cost.

• For time you need to estimate hours of work because labor costs are based on the amount of time people work in addition other time-based resources affect your cost, such as how long you rent equipment or leased office space.

• Second, you estimate cost that aren't time-based like materials you need or travel required. Having reliable people to assist in estimating is crucial, typically you work with a planning team made up of people knowledgeable about the project. This planning team helps you develop your initial estimates, another option is to hire outside experts to help you with estimating. Later on, during the executing process you can obtain more accurate estimates from the people assigned to do your project work: They understand what has to be done, know how long it will take them based on their experience and they're  more motivated to live up to the estimates they've made.

When possible base your estimates on the results from similar projects that are complete, If that isn't possible there are several techniques you can use for estimating.

With parametric models you can calculate work and cost based on sum measure such as the number of square feet for construction. It's a pretty easy approach because you can enter your numbers into a spread sheet on a program and get a quick answer. The disadvantage is that you can only build a parametric model when you have many similar projects in your database.

The program evaluation and review technique abbreviated to PERT uses the best, worst, and most likely results to estimate a project. It's a good approach if a project is unfamiliar or has a lot of uncertainty. Estimators think about what can go wrong or right with tasks which helps produce better estimates.

The DELPHI technique counts several heads being better than one. First, you ask several experts to produce estimates independent of one another. You then share the results with the group keeping the estimates anonymous. You keep them anonymous as you don't want any one to be influenced by the reputation or authority of a co-expert.

You then ask each expert to estimate again; repeat this step a few more times and then use the average of the last round as your final estimated value. You can estimate from the top down or the bottom up.

Top down estimating is effective for large projects or early rough estimates; you estimate phases or measure components and then break those estimates into smaller pieces until you get to individual tasks.

Estimating from the bottom up means you estimate each task and then add them up until you have the estimate for the entire project. For large or complex projects, add time for complexity, communication, interactions, trouble, management and so on..

There is no good rule of thumb for how much to add so you have to base your increases on experience. On the other hand, watch out for people adding time to their estimates is a safety margin. the best way to prevent these issues is set a side time and money that every one can share.

Contingency funds can be used if a task needs more people to finish on time for example. You can use contingency time too, in fact critical chain project management includes time buffers to help deliver projects at less time than you could otherwise.

Consider the project you're working on and decide which estimating method makes the most sense then identify the people who can help you estimate. Finally ask management to satisfy contingency time and money so you can be pro-active resolving problems that arise.

A key part of building a schedule is getting tasks in the right order when one task can start or finish is often controlled by the start or finish of other tasks.

For example you have to create your sales documents before you can print them. By linking tasks, you turn a list of tasks into a sequence that defines when your project work will occur.

A task dependency is when one task controls the timing of another task. Because each task has a start and finish they're four types of task dependencies.

Finish to start dependencies are the most common: the finish of one task controls when the other task starts. For example you have to finish a flight reservation before some one can get on the plane.

With a start to start dependency the start of one task triggers the start of the other. When the trade show starts your sales team their presentations on the booth.

A finish to finish dependency means the finish of one task controls the finish of the other. When the sales team finish working on their presentations the graphics department finish their work on the materials.

Start to finish dependencies don't occur very often, the start of one task triggers the finish of another so in this case the task in control occurs after the one it controls. For example, the start of the trade show breakdown determines when sale presentations end, no matter how interested the customers are.

You can figure out which type of dependency to use by asking a few questions:

• Which task controls the other? that tells you which task is the first one in the dependency.

• Does the start or finish day of the first task control the second task? That identifies whether the dependency begins with a start or finish.

• Does the the first task controls the start or finish of the second task? That identifies whether the second half of the dependency is start or finish.

Task dependencies, put tasks into sequence so you can build your project schedule. Now that you're aware of the different types, try to identify all the task dependencies in your project.

By understanding the relationship between work, duration, and units; you can assign people to work on tasks, to get the schedule the way you want.

Work also called effort is number of hours or days someone works on a task.

Duration is the length of time between when a task starts and when it ends, so let's say you estimate that it will take 10 hours of work to print and assemble sales packet to be handed out at your event; if you spend 2 hours per day, then the duration is 5 days. If you spend 5 hours per day the duration is 2 days.

The works stays the same but the duration varies. The term for the percentage of time a person spends on a task is often called units. in the project world units are based on a typical work day. 8 hours in a lot of cases. So when someone works full time (8 hours a day) units are 100%

Now let's look at what happens if you work only two hours per day; two hours out of a possible 8 hours is 25% of each work day. It's like you take a work day and deviate it into four pieces. So for your one work day task it is going to take four pieces of the task to make one full day's worth of work.

Because you work 25% of each day you now have a task 4 days long  so your duration is 4 days. If you assign more than one person to a task you still change the units, but in this case the duration of the task deceases.

For example, start with the same one day task, if you assign two people to the task, they can each work at the same time. That's like taking the one day and dividing it into half day tasks. By assigning two people the task, the duration shortens to half a day.

Then there are tasks that don't get shorter, no matter how many people you assign.  meeting are the classic example! a one day meeting is a one day whether 3 people attend or 10.

Because of the relationship between work, duration and units you can assign people in different ways to make the schedule do what you want.

It is important to make your project schedule realistic so your project's actual performance is as close as possible to what you planned.

• First, assign people to tasks using the actual number of hours they work on your project in a day. People don't work 100% of their time on their project tasks

  Other activities "chow up" time such as attending department meetings, filling out time sheets, training or time off. Even walking across campus or riding the elevators uses up work time, so do your best to estimate the actual number of hours people work.

• Second, assign part time workers using the amount time they're available. Part-time workers don't work as many hours in a week as full-time workers, so you have to increase task duration.

• Third, adjust task hours based on how fast the assigned workers are, for example if someone is a wise with building presentations on a computer she won't need as much time to build the slideshows as someone who can't tape.

• Fourth, don't assign someone to work on more than three tasks at a time. Multi tasking negatively affects productivity. Switching between tasks means a person has to switch focus which introduces a small delay. If a person is in great demand and you have to assign him to several tasks and just those assignments to reflect his decreased productivity.

As you assign people to project tasks think about all the factors that affect people's productivity. The closer is your model, you resources assignment to reality, the easier it'll be to keep your project on time.

The critical path is the sequence of tasks in your schedule with longest duration. The critical path is important, because any delay on that path delays the finish date of the project. Just as significant you can shorten the project schedule if you can figure out how to shorten the critical path. So what makes tasks critical?

Put simply, they don't have any slack. In project management slack is also called flow; just like a strain without slack. Critical tasks have no lee way to move without affecting the schedule. For example the develop hand out, print hand out, and ship materials tasks all occur one after the other with no slack, if any of these three tasks are delayed the finish date of the project moves later in time. Conversely,  if a task has slack it can start later without delaying the tasks that come after it. For example, the print biz cards task could delay as much as 8 days before it delays the project finish date.

Now let's look at how you identify whether or not a task has slack. A task has two sets of start and finish dates that back it when the task can occur. the early start and early finish are the earliest possible dates the task can start or finish based on its dependencies with other tasks. For example the print biz cards task can start as early as august 10th and finish on august 16th.

The late start and late finish are the latest possible dates the task can start and finish without delaying tasks that follow. The late start and finish dates are august 22nd and august 26th that means the task has 8 working days of slack and is not on the critical path. On the other hand if the early and late dates are the same there is no slack, that's why print hand out is on the critical path. The good news is that you don't have to perform these calculations; when you use project scheduling programs they take care of figuring out the critical path for you.

The critical chain is a slightly different take on the critical path. Using the critical chain approach you might be able to deliver your project earlier than you would other ways in addition critical chain techniques help you prevent delays in the project finish date.

• First, the critical chain approach schedules tasks to occur as late as possible. One benefit of doing this is you don't spend money on the project until you absolutely have to. Because of this type of scheduling you adjust the schedule by moving tasks to occur earlier.

• Second, critical chain focuses on resource limitations to identify the important task to manage; that's because resource constraints re often the toughest ones to deal with. You start by scheduling the tasks with most limited resources; so you use those people as effectively as possible.

• Third, the critical chain uses buffers to give a project breathing room; so it's less likely to delay past its finish date.

The critical chain approach is adding shared time to the project. Each task doesn't get its own time buffer, instead, sequences of tasks share a buffer: That way only the tasks that actually need extra time use some of the buffer.

You apply a couple of different types of buffers.

• First, you add buffers at the end of each sequence of tasks

• Second, you add a project buffer at the end of the project to protect the overall project finish date.

The critical chain approach helps deliver projects on time or earlier than expected. If you're interested in using this method, I recommend you take a look on the supplementary material of this lecture to learn how to put its techniques into practice.

Stakeholders often ask you to deliver projects earlier than the first finish date you calculate. In this lecture I'll describe two techniques for shortening your schedule: Fast tracking and Crashing.

Whether you fast-track or crash, keep in mind that the critical path can change. Some tasks might become non critical and others may turn into critical tasks.

Be sure to review the critical path after every adjustment to make sure that the next task you work on is still on the critical path.

Once the customer and stakeholders have approved the project plan it is time to save your project baseline.

In this lecture I'll be teaching you what is a baseline, how to save it, and how to use it to evaluate progress and project performance.

The executing process starts with lining up the people and other resources you need to perform the project.

In this lecture you'll be able to help the team members get familiar with their assignements, set up a place to store project information and save a baseline of your plan that you'll use to compare with actual performance

The executing process starts when the project plan has been approved and project plan can finally begin.

The first step in the executing process is usually procurement. You might work with a core team for the initiating and planning processes, but executing is when you bring on the rest of the team and acquire equipment and materials the project requires.

In this lecture you'll learn how to get vendors' proposals or bids and evaluate the responses using the criteria you identified then you select the winner.

The selection process depends on the size and complexity of the project: it is given in this lecture as a form of a step by step guide.

Developing your project team into a finally tuned machine is important, because you'll get more productivity from your people and higher quality results.

Bruce Tuckman's forming, storming, norming and performing is one model that describes the typical phases that the teams go through.

In this lecture you'll know more about this model and how to put it in practice for your project.

The data you need depends on what the customer and other stakeholders consider important. Because schedule and budget usually top the list, information about hours worked and money spent are givens.

This lecture is a step by step guide to obtain the information you need about tasks.

Earned value analysis evaluates how much a project has earned based on work that's been completed. In other word a project earned value by completing work. You'll truly appreciate earned value when you understand how basic project measures can be deceiving.

This lecture will make you interested in using earned value measures on your projects and will teach you how to perform those measures.

As project manager, you're always communicating what's going on to other people, like team members who do work or stakeholders who want to know status.

This lecture is a step by step guide to reporting your project progress. You'll be able to:

• Gather the information you need from your team

• Produce and distribute reports to the audiences

• Report problems or issues along with the steps you planned to resolve them

• Adjust your reporting system, to insure that your project communication is as effective as possible

In this lecture I'll explain some of the more common financial measures organizations use to evaluate project performance, That way as you run your project you can make sure you're meeting management's expectations. Financial calculations for projects are known as capital budgeting analysis. These measures look at the return on the money invested in a project. You need to know how much a project costs, how much a project saves or earns and when money flows in or goes out.

A project is a bouncing act trying to maintain equilibrium between scope, schedule, cost, and quality and sometimes other measures.

In this lecture I'll discuss how to make changes when your project goes off course.

During the planning process, you created plans for how you would manage changes, risks and quality. Now that the project is in progress you perform the steps in those plans to manage changes, handle the risks that occur, and control quality.

Remember managing change, risk and quality isn't a one time effort, while your project is running continuously watch for change requests, monitor risks, and measure Quality.

When you complete your project deliverables you might think the project is finished. But you have several activities to perform before you can call the project done.

• The most important part of the closing process is getting the customer to agree that the project completed successfully.

• Second, you document the lessons learned during the project. You can improve the performance of the future projects by identifying what worked well, what didn't and how things could have been done better.

  
  

• Third, you produce final documentation and a closeout report for your project

• Finally, it is time to close the contracts, archive your project information where others can get to it and see your project team off to their next assignments.

In this section I'll describe each of these activities in more detail.

Obtaining customer acceptance is absolutely essential, because without acceptance you simply aren't done.

During initiating and planning you should have documented your deliverables and defined success criteria that are both clear and quantifiable. You use the success criteria developed during planning to design acceptance tests which demonstrate whether the deliverables do what they're supposed to. You also work with the customer and other stakeholders to document acceptance procedures for running your tests.

For example, a software project might include features to speed up a business process; to measure success you set up a test environment production and then run test cases to evaluate whether the software decreases processing time by the required amount.

After you successfully complete the acceptance tests, hold a brief but important sign off meeting to get the signatures you need from the customer and any other stakeholders.

Obtaining customer acceptance is a huge milestone and wordy of celebration but you have a few more steps before you can complete the closing process. The rest of the lectures in this section explain what still left to do.

Learning lessons from what goes well and what could've gone better is a great way to improve your performance in the future. With those lessons on hand you focus on repeating you successes and improving on your less than still below performance. In this lecture I'll share with you several techniques you can use to kooks this crucial info out of your team members then you document the lessons you identify for the benefit of future projects.

• First, schedule time for regular lessons learned sessions, don't wait until the end of the project to ask about lessons learned by then, your team members have already forgotten a lot of them. Set a side  time in the agenda of your status meetings to ask team members for lessons learned or schedule dedicated meetings for the topic every few weeks.

• Second, keep lessons learned sessions positive and productive. Start with what went right, ask each person for a tip or technique that help them in their work; such as what saved you the most time recently? or what was a difficult challenge you solved and how did you do it? Then progress to lessons from the problems people faced, Pose questions about problems in a positive light: for example, how can we make the sales presentations more compelling? or what would you do differently next time?

  Ask team members to talk about themselves, that way it's easier to prevent people from blaming others.

• Third, give people the opportunity to be open and honest. Try scheduling meetings without managers to see if people will share information more freely. Consider including an anonymous method for submitting lessons learned such us a suggestion box. This approach can be helpful for sensitive issues or when people are afraid to admit mistakes for fear of loosing their jobs.

• Fourth, document lessons learned. I suggest you put them in your project notebook but you can also set up a repository so everyone in your company can learn what you already know. For example, a webpage with frequently asked questions, tips and tricks or knowledge base.

By making lessons learned an important part of your process you give your organization and your self the opportunity to learn and grow with each new project.

Part of the closing process is preparing a closeout report, which is like a final status report. A closeout report is important because it sums up the project in a

concise and a formative document. What the project did? how it did it? and how well it went?

• The first item in a closeout report is the bottom line, was the project a success? You might think the answer is a simple yes or no, instead summarize the quantitative results you achieved.

• Second, include the final cost of the complete project because stakeholders typically care about this value.

  Depending on the stakeholders you might include cost for measure portions of the project, cost variances, return on investment, and other financial measures.

• Third, document the delivery dates for the entire project and key milestones. If the project was significantly early or late, include the variances from your original dates and the reasons, that helps publicize ways to improve estimates on future projects

• Fourth, summarize any significant changes, for example if the project didn't deliver anything on the scope statement include the scope that was and wasn't delivered

• Next, consider including information you want to share with others, such as lessons learned, or significant risks and issues and how you handled them.

  For risks, describe how you handled them and the results. You can also point out risks that occurred that one identified in the initial risk management plan, so others don't miss them in the future.

• Finally, end with a section about the effectiveness of your project management practices. Similar to lessons learned, you can describe what worked well, and how you would plan and manage differently in the future, that way other projects can benefit from your experience.

It's important to archive details about your project. Archiving information electronically, makes it easier to find them later on. There is no need to store shelf after shelf or lief through page after page.

Once you prepared your closeout report and you store your project information a way in its archive, your ready for closure.