Tools and Techniques of Acquire Project Team

Preassignment, negotiation, acquisitions, and virtual teams are tools and techniques of the Acquire Project Team process. As the project manager, you will use the negotiation technique a lot. You'll have to negotiate with functional managers and other organizational department managers—and sometimes with the vendor to get some of their best people—for resources for your project and for the timing of those resources.

Preassignment can happen when the project is put out for bid and specific team members are promised as part of the proposal or when internal project team members are promised and assigned as a condition of the project. When staff members are promised as part of the project proposal—particularly on internal projects—they should be identified in the project charter.

Acquiring the Project Team

The Acquire Project Team process involves attaining and assigning human resources to the project. Project staff may come from inside the company or from outside the company in the form of full-time employees hired specifically for the project or as contract help. In any case, it's your job as the project manager to ensure that resources are available and skilled in the project activities they're assigned to. However, in practice you may find that you don't always have control over the selection of team members. Someone else, the big boss for example, may hand-pick the folks they want working on the project and it's up to you to assess their skills and decide where they best fit on the project.

The Acquire Project Team process inputs are as follows: enterprise environmental factors, organizational process assets, roles and responsibilities, project organization charts, and staffing management plan.

Outputs of Direct and Manage Project Execution

Most of the outputs of the Planning process group, and some of the outputs of the Monitoring and Controlling process group, are utilized by the Direct and Manage Project Execution process. The outputs of the Direct and Manage Project Execution process are as follows:

■ Deliverables
■ Requested changes
■ Implemented change requests
■ Implemented corrective actions
■ Implemented preventive actions
■ Implemented defect repairs
■ Work performance information

The two primary outputs are deliverables, meaning actually accomplishing the activities leading to completion of the product or service you set out to produce, and work performance information. Without having completed the prior processes, you wouldn't know what the work of the project should look like.

Project plan is the approvel

Believe it or not, we have officially completed the Planning process group. Along the way, I've mentioned gaining approvals for portions of the project plan like the schedule and budget.
The project plan is the approved, formal, documented plan that's used to guide you throughout the project Executing process group. The plan is made up of all the outputs of the Planning process groups, including the Project Management Plan. It's the map that tells you where you're going and how to perform the activities of the project plan during the Project Plan Execution process. It serves several purposes, the most important of which is tracking and measuring project performance through the Executing and Monitoring and Controlling processes and making future project decisions. The project plan is critical in all communications you'll have from here forward with the stakeholders, management, and customers. The project plan also documents all project planning assumptions, all project planning decisions, and important management reviews needed.
The project plan encompasses everything we've talked about up to now and is represented in a formal document, or collection of documents. This document contains the project scope statement, deliverables, assumptions, risks, WBS, milestones, project schedule, resources, and more. It becomes the baseline you'll use to measure and track progress against. It's also used to help you control the components that tend to stray from the original plan so you can get them back in line.
The project plan is used as a communication and information tool for stakeholders, team members, and the management team. They will use the project plan to review and gauge progress as well.

Documenting the Cost Baseline

The cost baseline, the first output of Cost Budgeting, is developed by adding up the costs of the WBS elements (remember, these costs were aggregated with the cost aggregation tool and technique) according to time periods. Most projects span some length of time and most organizations time the funding with the project. In other words, you won't get all the funds for the project at the beginning of the project; they'll likely be disbursed over time. The cost baseline provides the basis for measurement, over time, of the expected cash flows (or funding disbursements) against the requirements.

Cost Estimating Process Outputs in Project

Obviously, one of the outputs of the Cost Estimating process is the activity cost estimates. These are quantitative amounts—usually stated in monetary units—that reflect the cost of the resources needed to complete the project activities. The tools and techniques we just described help you derive these estimates. Resources in this case include human resources, material, equipment, information technology needs, and so on as well as any contingency reserve amounts and inflation factors (if you're using them).

Activity Cost Estimating supporting detail, requested changes, and cost management plan updates are the remaining Cost Estimating outputs. Supporting detail is just as you've seen in other processes. Any information that supports how the estimates were developed, what assumptions were made during the Cost Estimating process, and any other details you think need to be documented go here. According to A Guide to the PMBOK, the supporting detail should include the following:
A description of the work that was estimated.
• A description of how the estimate was developed or the basis for the estimate.
■ A description of the assumptions made about the estimates or the method used to determine them.
• A description of the constraints.
■ A range of possible results. Like the time estimates, the cost estimates should be stated within ranges such as "$500 ± $75."
Cost variances will occur and estimates will be refined as you get further into your project. As a result, you'll update cost estimates and ultimately the project budget to reflect these changes.
Cost Estimating uses several techniques to make an accurate assessment of the project costs. In practice, using a combination of techniques is your best bet to come up with the most reliable cost estimates. The activity cost estimates will become an input to the Cost Budgeting process, which allows you to establish a baseline for project costs to track against.

Cost Estimating Tools and Techniques in Project management

Cost Estimating has eight tools and techniques used to derive estimates:
■ Analogous estimating
■ Determine resource cost rates
■ Bottom-up estimating
■ Parametric estimating
■ Project management software

• Vendor bid analysis
• Reserve analysis
• Cost of quality

Cost Estimating Inputs

You arc already familiar with all of the Cost Estimating inputs. They arc as follows:
■ Enterprise environmental factors
■ Organizational process assets
■ Project scope statement
■ WBS
■ WBS dictionary
■ Project management plan (including the schedule management plan, staffing management plan, and risk register)
As with several other processes we've covered, keep in mind organizational policies (such as cost estimating policies or templates), historical information, previous project files, constraints, and assumptions when deriving your cost estimates.

How to Estimating a cost in Project Management?

You now- have an exhaustive breakdown of project activities, and you have some pretty good duration estimates. Now the question that's forever on the mind of the executive management staff: How much is it going to cost? The purpose of the Cost Estimating process is to answer that question.

Every project has a budget, and part of completing a project successfully is completing it within the approved budget. Sometimes project managers arc not responsible for the budget portion of the project. This function is assigned instead to a functional manager who is responsible for tracking and reporting all the project costs. I believe project mangers will have more and more responsibility in this area as the project management discipline evolves. Keep in mind that if you, as the project manager, don't have responsibility for the project budget, your performance evaluation for the project should not include budget or cost measurements.
Before we dive into the Cost Estimating and Cost Budgeting process particulars, you should know that these processes arc governed by a cost management plan that is created when you perform the Project Management Plan process. Just like the schedule management plan, the cost management plan isn't developed during these processes and it isn't an output of any of the Cost processes. There arc a couple of things you should know about this plan for the exam. Like all the other management plans, it's a subsidiary of the project management plan. According to A Guide to the PMBOK, some of the elements of this plan include, but aren't limited to, the following:
■ Precision levels, or the rounding you'll use for project costs (hundreds, thousands, and so on)
■ Units of measure for resources such has hours for staff resources and hourly rates for contractor staff
■ Control account links so that cost estimates for WBS elements can be linked directly to the accounting system
■ Variance thresholds for costs
■ Earned value rules (We'll talk about this in the tools and techniques section.)
■ Reporting formats
■ Process descriptions

As with time estimates, the work breakdown structure (WBS) is the key to determining accurate cost estimates. The Cost Estimating process develops a cost estimate for the resources (human and material) required for each schedule activity. This includes weighing alternative options and examining trade-offs.

Gathering Activity and Dependency Information

Let's say you arc the project manager for a new software project. The company you arc working for is venturing into the movie rental business over the Web. You need to devise a software system that tracks all the information related to rentals and also supplies the management team with reports that will help them make good business decisions. For purposes of illustration, I'm showing only a limited portion of the tasks that you would have on a project like this.

The list of activities comes from the Activity Definition process. The durations for each activity arc listed in the Duration column and were derived during the Activity Duration Estimating process. The duration times arc listed in days.
The Dependency column lists the activities that require a previous activity to finish before the current activity can start. You're using only finish-to-start relationships. For example, you'll sec that activity number 2 and activity number 4 each depend on activity 1 to finish before they can begin. The dependency information came from the Activity Sequencing process. Now, you'll proceed to calculating the dates.

What is Critical path method (CPM)?

Critical path method (CPM) is a schedule network analysis technique. It determines the amount of float, or schedule flexibility, for each of the network paths by calculating the earliest start date, earliest finish date, latest start date, and latest finish date for each activity. This is a schedule network analysis technique that relics on sequential networks (one activity* occurs before the next, or a scries of activities occurring concurrently arc completed before the next scries of activities, and so on) and on a single duration estimate for each activity. Keep in mind that CPM is a method to determine schedule durations without regard to resource availability.

The critical path (CP) is generally the longest full path on the project. Any project activity with a float time that equals zero is considered a critical path task. The critical path can end under a few conditions. When activities with float time use up all their float, they can become critical path tasks. Or you may have a milestone midway through the project with a hnish-no-latcr-than constraint that can change the critical path if it isn't met.

Float time is also called slack time, and you'll sec these terms used interchangeably. There arc two types of float: total float and free float. Total float (TF) is the amount of time you can delay the earliest start of a task without delaying the ending of the project. Free float (FF) is the amount of time you can delay the start of a task without delaying the early start of a successor task.
In the following section, you'll calculate the CP for a sample project and illustrate how all the dates, the CP, and the float times arc derived.

Developing the Project Schedule

The Schedule Development process is the heart of the Planning process group. This is where you lay out the schedule for your project activities, determine their start and finish dates, and finalize activity sequences and durations. This process, along with Activity Resource Estimating and Activity Duration Estimating, is repeated several times before you actually come up with the project schedule. The project schedule, once it's approved, serves as the schedule baseline for the project that you can track against in later processes.

You'll learn later in this section that project management software comes in very handy during this process. In fact, it is one of the tools and techniques of this process.

We've got a lot of material to cover in this process. We'll start out with the inputs to the Schedule Development process and then follow up with an in-depth discussion of the tools and techniques of the process. These techniques will help you get to the primary output of this process, which is the project schedule.
Schedule Development Inputs
Schedule Development has nine inputs, seven of which arc outputs from other Planning processes. The inputs arc as follows:
• Organizational process assets
■ Project scope statement
■ Activity list
■ Activity attributes
■ Project schedule network diagrams
■ Activity resource requirements
■ Resource calendars
■ Activity duration estimates
■ Project management plan (risk register)

You can sec how important it is to perform all of the Planning processes accurately because the information you derive from almost every process in the Planning group is used somewhere else in Planning, many of them here. Your project schedule will reflect the information you know at this point in time. If you have incorrectly estimated activity durations or didn't identify the right dependencies, for example, the inputs to this process will be distorted and your project schedule will not be correct. It's definitely worth the investment of time to correctly plan your project and come up with accurate outputs for each of the Planning processes.
As with several other processes, constraints and assumptions arc highlighted as the elements of the project scope statement to pay particular attention to. Constraints arc with you throughout the life of the project. The most important constraints to consider in the Schedule Development process arc time constraints. well the time constraints in this process fall into two categories: imposed dates and key events or major milestones.
Imposed dates arc used to restrict the start or finish date of activities. The two most common constraints used to restrict dates arc enforced by most computerized project management software programs. They arc "start no earlier than" and "finish no later than" constraints. For example, let's go back to Chapter 6*s house-painting example. The painting activity cannot start until the primer has dried. If the primer takes 24 hours to dry and is scheduled to be completed on Wednesday, this implies the painting activity can start no earlier than Thursday. This is an example of an imposed date.
Key events or milestones refer to the completion of specific deliverables by a specific date. Stakeholders, customers, or management staff may request that certain deliverables be completed or delivered by specific dates. Once you've agreed to those dates (even if the agreement is only verbal), it's often cast in stone and very difficult to change. These dates, therefore, become constraints.

Activity Duration Estimating Outputs

Everything we've talked about up to this point has brought us to the primary output of this process: the activity duration estimates. The inputs and tools and techniques are used to establish these estimates. As mentioned in the opening of this section, activity' duration estimates arc an estimate of the required work periods needed to complete the activity. This is a quantitative measure usually expressed in hours, weeks, days, or months.

One thing to note about your final estimates as an output to this process is that they should contain a range of possible results. In the cable-running example, you would state the activity duration estimates as " 100 hours - 10 hours" to show that the actual duration will take at least 90 hours and may go as long as 110 hours. Or you could use percentages to express this range.

The other output of Activity Duration Estimating is activity attribute updates. You will update the activity attributes with the duration estimate and the assumptions you used when deriving the estimates.

Now that we have all the activity information in hand, along with a host of other inputs, we're ready to develop the project schedule.

Estimating Activity Durations

The Activity Duration Estimating process attempts to estimate the work effort, resources, and number of work periods needed to complete each schedule activity. The primary output of this process is the activity duration estimates. These arc quantifiable estimates expressed as the number of work periods needed to complete a schedule activity. Work periods arc usually expressed in hours or days. However, larger projects might express duration in weeks or months. Work periods arc the activity duration estimates, and they become inputs to the project schedule in a later process.
When you're estimating activity duration, you arc estimating the length of time the activity will take to complete, including any elapsed time needed from the beginning to the ending of the activity. For example, let's look at the house-painting project. You estimate that it will take three days, including drying time, to prime the house. Now, let's say priming is scheduled to begin on Saturday, but your crew doesn't work on Sunday. The activity duration in this case is four days, which includes the three days to prime and dry plus the Sunday the crew doesn't work. Most project management software programs will handle this kind of situation automatically.
Progressive elaboration comes into play during this process also. Estimates typically start out at a fairly high level, and as more and more details arc known about the deliverables and their associated activities, the estimates become more accurate. You should rely on those folks who have the most knowledge of the activities you're trying to estimate to help you with this process.

Project Management vs. Project Leadership

Is there a difference between project management and project leadership?

Project management uses the tools, knowledge, and techniques needed for defining, planning, organizing, controlling, leading, and closing a project. Project leadership appears, therefore, to be a subset of project management. But it would be a mistake to assume that project leadership is secondary to project management. Project leadership is the only function that occurs throughout the project cycle. It is. in many ways, the glue that holds the other functions together. The output from defining, planning, organizing, controlling, and closing a project depends largely on how well project leadership is exhibited. Without solid leadership, performance of the other functions will be marginal at best.

Industries are replete with examples of projects that had well-defined plans and plenty of financial support, yet achieved less than satisfactory results. Project managers must gain and retain the confidence of myriad players, including the project sponsor, client, team, and senior management. Project leadership, then, means going beyond the mechanics of managing a project, such as building a work breakdown structure, constructing schedules, or managing change. It calls for inspiring all players to accomplish the goals and objectives in a maimer that meets or exceeds expectations.

what are The Power of the Project Manager?

Power is often defined as the ability to influence key players in the decision-making process to achieve a goal In other words, power means getting what one wants.

Project managers often feel powerless because they lack the powers of functional managers, such as hiring and firing. While true, they are not as powerless as they think. According to management theorists John French and Bertram Raven, five different sources of power exist. Each applies to varying extents to the project manager.

• Coercive power uses fear as a primary tool. It involves inflicting punishment. Project managers usually have little coercive power in an overt sense. On a more subtle level, however, they may not assign certain people to coveted tasks, not invite them to meetings, or not communicate with them.
• Reward power uses positive financial and nonmonetary tools. Most project managers lack the power to use monetary incentives. However, they can provide feedback to functional managers on performance, which in turn provides a basis for determining salary increases. Project managers can also pay for training and dispense other perks. From a nonmonetary perspective, they can reward people by assigning them to high-visibility tasks, as well as involve them in the decision-making process.
• Legitimate power is the authority granted by the institution. In other words, such power allows managers to "order" people with the foil backing of the institution. Project managers, especially in a matrix environment lack This power—the}- must use other power sources. Still, the}- have some legitimate power, especially if they have the political support of a powerful senior manager.
• Expert power is based on a person's knowledge credentials, expertise, or education. Project managers are often chosen for these characteristics and they gain considerable power in this regard. The only problem is that project managers often become narrowly focused, failing to see the big picture and working on other key areas. In addition, they have power only as long as people respect those characteristics.
• Referent power is based on trait theory—that is. a person's characteristics. These project managers have certain characteristics that make people want to follow them. An example of such a trait is charisma.

what is General Nature of the Business

GWI frequently receives solicitations for proposals. These requests are for weddings of all sizes and religions. A proposal request is a formal document sent to potential vendors. It states the requirements and expectations of the client, as well as the terms and conditions of the contract. A reply to a proposal request provides vendors with the opportunity to describe the who. what. when, where, and how for meeting the proposal's request.

A proposal has three major components: technical, management, and cost. The technical component includes:

• Vendor's experience/expertise with similar projects
• List of equipment
• Photographs of end products
• Services

The Project Cycle and its Phases

In the classical approach, project management was conceived in a linear way. or was at least formally portrayed that way. Project managers were to define, plan, organize, control and close—in that order. While it made sense, the reality was usually something else.
Today, we view the project manager's role differently; although project managers perform the same functions, we perceive their performance not in a linear context but in a cyclical one. Each time the cycle completes (reaches closure), it begins again, requiring the reinstitution or refinement of the functions that were used in a previous cycle.

Classical vs. Behavioral Approaches to Managing Projects

The field of project management is currently in transition. What worked in the past may not necessarily work in the future, precisely because the world of business has changed. In the past, managing a project meant focusing on three key elements of a project: cost, schedule, and quality. Each element had a direct relationship with the other two. Do something to one and the other two would be affected, positively or negatively. This viewpoint is considered the classical approach for managing projects. The classical approach emphasized the formal, structural aspects. Managing projects meant building neat organizational charts and highly logical schedules, as well as using formal decision-making disciplines.
Recently, however, project management has taken a more behavioral approach. The emphasis is shifting toward viewing a project as a total system, or subsystem operating within a system. This system perspective emphasizes the human aspects of a project as much as the structural ones. This does not mean that the formal tools, techniques, and principles are less important: it is just that they share the stage with behavioral techniques. The three elements—cost, schedule, and quality—gain an added dimension: people. Cost, schedule, quality, and people all play integral roles in the success or failure of a project.

Indeed, it is quite evident that the behavioral aspects of a project can have an impact on final results. Individual and team motivations, informal power structures, and interpersonal communications can have as much an effect as a poorly defined schedule or an ill-defined goal. In many cases, the impact of behavioral problems can be even more dramatic.

How does the PMBOK define quality assurance

A) " The processes required to ensure that the project will meet the needs for which it was started" is the PMBOK's definition of the knowledge area of project quality management.



> B) "The process of regularly evaluating the overall performance of the project to show confidence that the project will satisfy quality standards " is the PMBOK's definition of quality assurance. It includes regular evaluations to provide confidence that the project will meet the quality standards that relate to the given project.

The quality function deployment process is used to do what?

Quality function deployment helps a design team to define, design, manufacture, and deliver a product or service to meet or exceed customer needs. Its main features are to capture the customer's requirements, ensure cross-functional teamwork, and link the main phases of product development-product planning, part deployment, process planning, and production planning.

According to learning curve theory, when many items are produced repetitively then what is the result?

Learning curve theory indicates that human performance usually improves when a task is repeated. Specifically, each time output doubles worker hours per unit decrease by a fixed percentage. This percentage is called the learning rate.