Planning is the largest group of processes in the project management life cycle as it has 20 processes to consider. Planning is an iterative activity that happens throughout the project until you reach the project 's final closing activities. Be aware, however, that while there may be 20 processes in the planning process group, you don 't have to complete all twenty processes.

Also according to the CompTIA International Technology Adoption. And abilities of individuals in project. On this website are the property of their. CompTIA is the voice of. International; Get. Check out the latest edition of CompTIAWorld magazine to read about all the ways CompTIA and AITP members are.

The size of the project, the conditions within the project, the project priority and other factors can influence which processes are needed and the depth of planning each project process receives. You do not have to use all 20 processes to manage a project effectively.

For example, your project may not be buying anything from vendors so it 'd be useless to plan procurements. Here are the twenty planning processes and a brief description of each: Develop project management plan - the project management plan is the compilation of the project plans for scope, time, cost, quality, human resources, communication, risk, and procurement. The project management plan defines how the project will planned, executed, monitored and controlled, and finally closed. Collect requirements - the project requirements are the details of the project deliverables.

They include the specifics that satisfy the project objectives and define the conditions that must exist for the project to be considered completed and successful. Define the project scope - the project scope is often based on the requirements that have been gathered.

It is all of the project work - and only the project work - to satisfy the project requirements. Create the Work Breakdown Structure (WBS) - the WBS is a visual decomposition of the project scope.

The project scope is taken and broken down into smaller, more manageable units. Each of these units can be broken down again and again until you define the smallest item in the WBS called the work package. Define activities - the WBS and its work packages help the project manager and the project team define the activities that are needed to create the elements of the WBS. Sequence the activities - once the activities have been defined then the project manager and the project team can begin ordering the activities to create the project network diagram. Estimate activity resources - the activities will require labor, materials, facilities, and other resources in order to complete the work. Estimate activity durations - the project manager and project team will examine the activities, the resources available, and then predict the expected duration of each defined activity. Develop schedule - the project schedule defines when the actual work will take place.

It considers the ordering of the activities, the availability of the resources, the working hours of the project, and any other factors that can affect when the project work takes place. Estimate costs - the costs of the project 's resources are determined. These resources can include materials, equipment, facilities, and human resources. Determine budget - the project 's requirements and needs are aggregated, or rolled-up, into a project budget for the complete scope. Plan quality - this process determines the quality assurance activities and the quality control activities for the project. Plan quality also directs the process improvement plan and its execution in the project. Develop human resource plan - this project plan, often based on organizational process assets, defines how the project team should be managed.

As part of this plan you 'll define the needed resources, training, rewards and recognition, and how the project team will be brought onto and released from the project. Plan communications - this process defines who will need what information in the project, when the information is needed, the expected modality of the communication, and the person responsible for providing the needed communication. Plan risk management - this process defines the approach for risk identification, risk analysis, risk response planning, and the project activities for risk monitoring and control. This process creates the project 's risk register and risk management plan. Identify risks - the project manager, the project team, and key stakeholders are consistently looking to identify risks that can help or hinder the project 's success.

Risks are recorded in the risk register and tracked throughout the project life cycle. Qualitative risk analysis - this is a fast and subjective review of the identified risks to determine if the risks are valid and should be analyzed in quantitative risk analysis. Quantitative risk analysis - this is a more in-depth study of the risk 's probability and financial impact on the project.

Quantitative risk analysis helps the project team and the project manager determine how the risks should be managed. Plan risk responses - based on the risk identification and analysis the risk responses are created. There are seven risk responses (three for negative risks, three for positive risks, and one for either): mitigation, transference, avoidance, enhance, exploit, share, and acceptance. Plan procurements - the project procurement planning determines the needs for procuring, how vendor selection and management will transpire, the contract types that are acceptable, and the process for closing out the project 's contracts. These twenty processes are iterative throughout the project. All of these processes contribute to the project management plan.

This project management plan is actually a collection of project subsidiary plans. Each plan dictates how the project manager and the project team will work with that facet of the project. Basically, the project management plan communicates the expectations for the project manager and the project team as to how the project will be executed, monitored and controlled, and finally closed.

It's a fluid document that reflects the output of the planning processes. The project scope is the definition of what the project is supposed to accomplish and the budget of both time and money that has been created to achieve these objectives. It is the total work required to deliver a product, service, or result with the specified features and functions.' There are two places that scope is defined on your project. High-level scope is defined in your project charter. Low-level scope is defined in your business requirements document and as one might expect, gets into the details of each objective scope. High-level scope consists of two main components: Deliverables.

If you can 't remember anything else about scope, list your deliverables. Defining your deliverables goes a long way toward defining the overall scope of the project Boundaries. This may not be applicable to all projects, but you should also try to define the boundaries of your project. Boundary statements help to separate the things that are applicable to your project from those areas that are out of scope.

Examples of boundary statements could be that the project will only affect the ERP and CRM applications. All other applications are out of scope. Project Scope Management is one of the nine Project Management Knowledge areas. It is a group of the following processes required to ensure that the project includes all the work required, and only the work required, to complete the project: *Collect Requirements *Define Scope *Create Work Breakdown Structure (WBS) *Verify Scope *Control Scope The term 'Scope' may refer to product scope or project scope. Project Scope Management includes the processes required to ensure that the project includes all the work required, and only the work required, to complete the project successfully.

Project Scope Management is primarily concerned with defining and controlling what is and is not included in the project. A Statement of Work (SOW) is a document that captures and defines the work activities, deliverables and timeline that a vendor will execute against in performance of work for a customer. Detailed requirements and pricing are usually specified in it, along with many other terms and conditions.

SOW is a narrative description of products or services to be supplied by the project. For internal projects, the project initiator or sponsor provides the Statement of Work based on business needs, product, or service requirements. For external projects, the Statement of Work can be received from the customer as part of a bid document. Scope creep is the gradual addition of new requirements to the original specification and can adversely affect time and cost.

It is likely to happen if changes to the scope are not controlled through change control. As the requirements list increases, project complexity increases. Scope creep is the main reason for the failure of big projects. However, while scope creep is almost always seen negatively, it isn't all bad. For example, maybe the marketing team wants to introduce that one new feature into the project scope that could give your organization a huge edge over the competition. And the timeline demands that in order for the feature to be competitive, it must be included in the project scope.

All scope creep has an associated cost. The question is whether it's worth it, and that's for the project team to determine. Most projects are impacted by scope creep in some way, at some point or another.

This expansion of a project outside of the planned objectives, commonly known as scope creep, is an inherent part of IT development, and can originate from several sources. If not handled in time, and not handled well, it is a leading cause of project. Here are some common causes of scope creep: 1.

Unclear deliverables at project start. Make sure a thorough analysis is done before the project planning phase by using methods, such as interviews, focus groups, and surveys to list all the project requirements and deliverables needed. Evolving stakeholder expectations. Stakeholders should acknowledge the scope statement, which could state that only the deliverables defined in the scope statement will be produced and that no additions or changes to the scope statement are permitted. Developers recognizing new possibilities. Team members should be given exact specifications to work with in order to produce the deliverables as specified in the scope statement.

Their work should be periodically tested to make sure it matches the exact specifications, and they should be encouraged to discuss any new possibilities they think of before incorporating them. Defining a project's scope means clearly identifying what lies within the boundaries of the project.

Project planning can be only as good as the project's scope definition. The first activity in defining a scope for a project includes evaluating the business requirements and defining the efforts to meet those requirements. The next set of activities refines the project concept. Each activity adds more detailed information to the project definition and helps the organization define project boundaries. The scope definition is often given little attention. This is a critical mistake.

It is essential to spend the time on scope definition at the beginning of the project to ensure success. Without a precise, well-documented scope, a project is doomed to fail because all subsequent project phases are based on the information gathered, documented, and agreed to during scope definition. Creating a carefully documented scope definition also helps avoid scope creep later in the project.

Defining the scope means coming to a common understanding of the project's major boundaries and the business functions the project will incorporate. The scope statement helps establish these boundaries and functions and sets a project scope baseline.

Without this baseline, the time for completion and success criteria for final evaluation could expand to unmanageable or unrealistic proportions. Failure to define scope at the start of a project will leave the project manager unable to determine success criteria, cost, time, or resources needed for project completion. Changes to the scope of a project should be made only through an established change control process. Scope control starts on day one, before the first line of code is ever written. As discussed earlier, scope creep is very common to projects, but there are several strategies to help control scope creep.

Use the following strategies to set yourself up to successfully control the scope of your project: Understand the project vision: Meet with the project drivers and clearly understand the vision for the project and the stakes if the project is not delivered to scope. Deliver an overview of the project as a whole for their review and comments. Make sure you understand the project sponsor 's vision very clearly. Prioritization: Understand the priorities of the project and create a task list based on that priority. Items should include budget, deadline, feature delivery, and end user satisfaction. You 'll use this list to justify your scheduling decisions once the project has begun. Approved deliverables: Define your deliverables (general descriptions of functionality) and have them approved by the project drivers.

Break the approved deliverables: into actual work requirements, with major and minor milestones. Leave room for error in the scheduling, without being overly conservative.

Do use a WBS (Work Breakdown Structure): Once a schedule has been created, assign resources and determine your critical path using a PERT Chart or Work Breakdown Structure. Microsoft Project will create this for you. Expect that there will be scope creep: Every experienced project manager knows that the scope set at the beginning of a project in terms of budget and deliverables is at best an educated 'best guess' at the time and is going to change. Implement Change Order forms early and educate the project drivers on your processes. The project calendar is used to define the working and nonworking days and times for tasks. This calendar is usually used to represent an organization's traditional working hours.

A project uses this calendar to schedule tasks that do not have resources assigned or that have a task type of fixed duration. By default, the Standard base calendar is used as the project calendar. A user can also reflect alternative schedules by using other base calendars.

The working days and hours in the project calendar reflect the working days and hours for the whole project. A user can also specify special days off, such as company holidays.

A user can also indicate other nonworking times to reflect periods when the whole team will be working on non-project activities, such as company meetings or department retreats. Schedule slippage can occur for a variety of reasons, the most common being: *Miscommunication: For example, a team member 's misperception of what is expected. *Substandard ability: Substandard ability to perform according to expectations.

*Lack of training: Self-explanatory. *Environmental considerations: Team members know what to do and how to do it but are held back by environmental problems. *Lack of adequate resources: This can include human as well as hardware, software, facility, and other materials needed to accomplish the project successfully and on time. Red light/green light method is a simple approach to project management based on traffic lights (green, yellow, and red). Project reports highlight the project status as: *Green:The project is on schedule and on budget. *Yellow: The project is slightly behind schedule and/or over budget.

The project manager should assess the situation and take action, such as: **Provide additional funding and/or a new target date. **Move to a multiple release plan to ensure that delivery takes place on time so that the risk of the follow-on project not being approved is removed. *Red: The project is significantly behind schedule and/or over budget. The customer or sponsor must provide more money and a new date or limit the scope or decide to kill it. Organizations that introduce this traffic light system typically find that 70 percent of projects go red at least once in the first 6 months. This is almost always due to scope creep. Key Performance Indicators are quantifiable measurements, agreed to beforehand, that reflect the critical success factors for a given project.

Whatever Key Performance Indicators are selected, they must reflect the organization's goals, they must be key to its success, and they must be quantifiable (measurable). Key Performance Indicators usually are long-term considerations.

The definition of what they are and how they are measured do not change often. The goals for a particular Key Performance Indicator may change as the organization's goals change, or as it gets closer to achieving a goal. A Work Breakdown Structure (WBS) is a visual decomposition of the project scope. The project scope is taken and broken down into smaller, more manageable units.

Each of these units can be broken down again and again until you define the smallest item in the WBS called the work package. Project groups and the project's discrete work elements are defined in a way that helps organize and define the total work scope of the project.

A WBS element may be a product, data, a service, or any combination. WBS also provides the necessary framework for detailed cost estimating and control along with providing guidance for schedule development and control.

In the project management industry, the Work Breakdown Structure (WBS) is considered to be the foundation for project planning. It is a visual decomposition of the project scope.

The project scope is taken and broken down into smaller, more manageable units. Each of these units can be broken down again and again until you define the smallest item in the WBS called the work package. A WBS helps the project manager define and sequence project activities into discrete tasks. Define activities - the WBS and its work packages help the project manager and the project team define the activities that are needed to create the elements of the WBS. Sequence the activities - once the activities have been defined then the project manager and the project team can begin sequencing (ordering) the activities to create the project network diagram. New project managers feel writing WBS on post-its and drawing charts to be a waste of time and prefer to jump right in to the project work. However, most seasoned project managers will give you at least three good reasons to use a WBS in your projects.

The first is that is helps more accurately and specifically define and organize the scope of the total project. The most common way this is done is by using a hierarchical tree structure. Each level of this structure breaks the project deliverables or objectives down to more specific and measurable chunks.

The second reason for using a WBS in your projects is to help with assigning responsibilities, resource allocation, monitoring the project, and controlling the project. The WBS makes the deliverables more precise and concrete so that the project team knows exactly what has to be accomplished within each deliverable. This also allows for better estimating of cost, risk, and time because you can work from the smaller tasks back up to the level of the entire project. Finally, it allows you double check all the deliverables' specifics with the stakeholders and make sure there is nothing missing or overlapping. The Work breakdown structure (WBS) dictionary is a companion document to the WBS. It describes each component in the WBS. It includes a brief definition of the scope or statement of work, defined deliverables, a list of associated activities, and a list of milestones.

It details all work packages in WBS including estimates and billing information. The WBS dictionary describes: *Deliverables *Acceptance criteria *Quality requirements *Time estimates and milestones *Cost estimates *Contract information (if applicable) *Responsible individual or department.

Creating a good WBS can require several iterations. The Project Management Institute has developed a Practice Standard for Work Breakdown Structures to provide guidance for developing a WBS.

Outlined below are some of the basic guiding principles: 1. Working from the scope statement, identify the major business goal(s) of the project.

From the scope statement, identify the functional requirements that will meet the project goal(s). Identify the major tasks needed to meet the functional needs. To make the project more manageable and to ensure that you have included all of the relevant tasks, it's helpful to include an intermediate level of breakdown. Organize the tasks by using one of the following groupings or a combination (for example, systems alone, or first systems and then stages). List all deliverables (major hardware and software subsystems) 5. Go through all Stages (major development stages, such as concept, feasibility, design, development, integration, and test) 6.

Build a hierarchical outline, creating as many layers as necessary to break the work down into small, manageable pieces at a level of detail sufficient to do the following: 7. Make time and cost estimates 8. Assign the work to an individual or group 9.

Monitor and communicate work progress. Breaking work down into smaller pieces by identifying tasks helps make project goals manageable.

Projects might have a few hundred tasks to complete, however, and a simple list of these tasks will be difficult to manage. The WBS is a means to organize tasks to simplify the jobs of: *Budgeting *Scheduling *Status reporting *Issuing authorizations to perform work.

*Tracking variances Other plans that are based on the activities identified in the WBS include the following: 1. Project schedule 2. Resource allocation 3. Detailed budget 4.Risk assessment. Change, as most of us well know is inevitable. Projects are no exception. Managing change means evaluating and implementing changes.

A change control process includes the identification, evaluation, notification, and actual change in scope, time, cost, schedule, and budget. All changes should be undertaken only through the change control process. T he following are guidelines a project manager can use for these changes. Use a standard change request form. This form should include a description of the change, the reason, and who is requesting the change.

Investigate the overall impact of the change request on project. Use a formal approval process to accept or reject the request. Relay this information to the stakeholders. Include the approved changes in the project plan documentation. Change control is a systematic, formal approach to ensure that changes to a product or system are introduced in a controlled and coordinated manner. All changes made to a project, product or system is managed by change control. The purpose is to ensure that no unnecessary changes are made, that all changes are documented, that services are not unnecessarily disrupted and that resources are used efficiently.

Change control is usually a component of change management. Change control includes the following activities: *Identifying and evaluating necessary changes. *Evaluating the impact of changes on scope, time, cost, performance indicators, resource availability, risks, and project goals. *Evaluating whether the change needs to be elevated to customer or sponsor. *Notifying the appropriate parties of the changes and their impact. *Documenting and implementing accepted changes.

*Rejecting unacceptable changes. *Documenting unacceptable changes. *Reforecasting the scope, time and cost based on the changes. In project management, a change order is a component of the change management process whereby changes in the project scope are agreed to by the project sponsor. Change orders are common to most projects, and very common with large projects.

After the original project scope is defined, there may be perfectly good reasons to determine that the original plans are not best representation of the project deliverable or deliverables, or even the vision itself. Accordingly, the project manager may suggest a change order. A change order is work that is added to or deleted from the original scope of work of a project scope or contract, which alters the original contract amount or completion date. A change order may fork a new project to handle significant changes to the current project. Change orders must be submitted in writing to the project manager, as a part of an overall change control process. Change order documents can vary by the degree of detail, but certain minimal information is needed, such as: *Control number (might be assigned by the project manager if not known to the requestor).

*Requestor's name, telephone number, e-mail address, and best method of contact. *Date of request. *Recipient's name, telephone number, and e-mail address.

*A statement of needs, to include the business problem, reason for the request, and suggested solution. *Estimation of the impact of the change on other project aspects, including related tasks, deliverables, resource concerns, time, cost, risk and quality. The same change order document could also be used to track change status and disposition. The following information is needed: *Date received.

*Disposition (approval versus deferral). *Action plan. *Appropriate signatures and dates (i.e., project manager, change control board, customer or sponsor) as determined by organizational policies. *Change orders must be submitted in writing to the project manager. Change control includes the following activities: 1. Identifying and evaluating necessary changes.

Evaluating the impact of changes on scope, time, cost, performance indicators, resource availability, risks, and project goals. Evaluating whether the change needs to be elevated to customer or sponsor. Notifying the appropriate parties of the changes and their impact. Documenting and implementing accepted changes.

Rejecting unacceptable changes. Documenting unacceptable changes. Reforecasting the scope, time and cost based on the changes. Configuration Management is a subsystem of the overall project management system.

It is a collection of formal documented procedures used to identify and document the functional and physical characteristics of a product, result, service, or component of the project. It also controls any changes to such characteristics, and records and reports each change and its implementation status.

It includes the documentation, tracking systems, and defined approval levels necessary for authorizing and controlling changes. Audits are performed as part of configuration management to determine if the requirements have been met. Change to the project scope is usually inevitable. The scope (high and low level) for a project are defined by the Project Scope Statement, Work Breakdown Structure (WBS) and WBS Dictionary. The Project Manager, Sponsor and Stakeholders will establish and approve documentation for measuring project scope which includes deliverable quality checklists and work performance measurements. Proposed scope changes may be initiated by the Project Manager, Stakeholders or any member of the project team. All change requests will be submitted to the Project Manager who will then evaluate the requested scope change.

Upon acceptance of the scope change request the Project Manager will submit the scope change request to the Change Control Board and Project Sponsor for acceptance. Upon approval of scope changes by the Change Control Board and Project Sponsor the Project Manager will update all project documents and communicate the scope change to all stakeholders.

Based on feedback and input from the Project Manager and Stakeholders, the Project Sponsor is responsible for the acceptance of the final project deliverables and project scope. An efficient scope and change control process should be defined sooner than later. There needs to be a balance between flexibility and control. If the process is too onerous, either valuable changes will be lost or the participants will ignore the rules - leading to uncontrolled scope and configuration.

If the process is too easy, then many changes may be applied with insufficient thought given to their merits and consequences. Change control is usually the weakest part of a project and, if not monitored, can lead to significant resource waste and missed schedules. Successful project managers do the following: 1.

Place great emphasis on managing changes, insisting they are carefully defined, accurately budgeted in terms of cost, and formally approved. Amend the project management plan to reflect the impact of any changes. Use change orders for making changes. Have a contract describing who pays for the changes. Examples of changes to a project include, but are not limited to, the following: 1.

Scope: The customer redefines requirements after the project has begun. Personnel: Promotions, hiring, downsizing, reassignments, illnesses, or accidents occur. Management: A change in the organizational structure or corporate ownership takes place. Economics: Reallocation of budgets due to financial factors affecting the organization happens. Environment: The project or company moves to a new location, or data resources become unavailable.

Priorities: Management shifts. Scope changes can fall into two categories: • Changes that are necessary • Changes that are unnecessary but would still be beneficial. The project manager and stakeholders must agree on the necessity/benefits of each change request. After a change has been deemed necessary to the current project, the project manager must evaluate the impact of change in terms of the following: • Scope: How will the change affect the deliverables? • Time: Can the change be accomplished without altering the length of the project? How is the completion date for any of the deliverables affected? • Cost: What effect will the change have on project costs?

• Performance indicators: Do the established project performance indicators change as a result of the change? • Resource: Will resources (people, equipment, facilities) still be available given the proposed changes? How does a change in availability affect other areas of the project (time and cost)?

• Risks: Does the change increase risk? • Project goals: How does the change effect project goals (do the goals change or are they unaffected)? Evaluating change requests and alternatives to the requests is an important task.

The key areas that might be affected by changes must be evaluated as follows: 1. Budget What actions can be taken to accommodate the scope change without increasing the budget?

Examine alternatives, such as: o Reordering tasks o Outsourcing 2. Schedule What can you do to accommodate the scope change without jeopardizing the schedule? Examine alternatives, such as: o Modifying the schedule 3. Quality What actions can be taken to accommodate the scope change while minimizing the effect on quality?

Examine alternatives, such as: o Modifying the work process o Increasing the number of test sites o Modifying the design o Using substitute materials. The project schedule is a calendar that links the project tasks to the resources that will do them by a certain date and time. Before the project schedule can be created, the project manager must have a work breakdown structure (WBS) and estimates, The schedule is part of the project plan. To schedule project tasks, the project team must be aware of both the effort and the duration. Effort is the number of hours that a person spends working on the task. Effort is measured in person hours (hours, days, weeks, months, etc.).

Duration is the amount of time that elapses between the start time and end time for a given task It is measured in regular units of time (hours, days, etc.). Building the project schedule involves: 1. Allocation of resources: For each task in the WBS, one or more resources must be assigned. Assignment must be based on qualifications, familiarity with the project, technology (if applicable) and availability of the resource.

Be sure to include some overhead when calculating the duration of each task. Identifying dependencies: a task has a dependency if it involves an activity, resource or work product which is required by another task. Tasks may have dependencies because they require the same resource. Every dependency has a predecessor or task that must have begun, be in progress or completed for another task to begin. Identify the type of predecessor for each dependency. You are now ready to create the schedule using Gantt charts. A Gantt chart is a type of bar chart that illustrates a project schedule.

The Gantt charts illustrate the start and finish dates of the terminal elements and summary elements of a project. The terminal elements and summary elements comprise the work breakdown structure of the project. Some Gantt charts also show the dependency (i.e., precedence network) relationships between activities. The Gantt charts have become a common technique for representing the phases and activities of a project work breakdown structure (WBS), so they can be understood by a wide audience. Gantt charts can be used to: 1. See how long the project will take.

Prepare easy-to-read and easy-to-understand reports for management, customers, and team members. Determine resource requirement for the project 4.

Determine who must do each job 5. Measure your progress. A critical path is the sequence of project activities which add up to the longest overall duration. This determines the shortest time possible to complete the project. Any delay of an activity on the critical path directly impacts the planned project completion date (i.e.

There is no float on the critical path). A project can have several, parallel, near critical paths.

An additional parallel path through the network with the total durations shorter than the critical path is called a sub-critical or non-critical path. These results allow managers to prioritize activities for the effective management of project completion, and to shorten the planned critical path of a project by pruning critical path activities, by 'fast tracking' (i.e., performing more activities in parallel), and/or by 'crashing the critical path' (i.e., shortening the durations of critical path activities by adding resources). If an activity on the critical path is completed a day late, the completion date of the entire project is moved out by a day (unless the subsequent activities on the critical path are completed more quickly than planned).

If a critical path task is late, it threatens to delay the completion of the project. Tradeoff decisions must be made between time and cost. The project manager's first priority is to identify the critical path activities early, monitor them closely, and create prevention and contingency plans to avoid project delays in the future.

The critical path establishes the length of the project. If an activity on the critical path is completed a day late, the completion date of the entire project is moved out by a day (unless the subsequent activities on the critical path are completed more quickly than planned). If a critical path task is late, it threatens to delay the completion of the project. Tradeoff decisions must be made between time and cost. The project manager's first priority is to identify the critical path activities early, monitor them closely, and create prevention and contingency plans to avoid project delays in the future. Every project has a baseline plan which is the original project plan used to track progress of a project. The baseline plan is a snapshot of the schedule at the time that the baseline is saved.

It includes information about tasks, resources, and assignments. The project scope document also serves as a baseline. A scope means coming to a common understanding of the project's major boundaries and the business functions the project will incorporate. The scope statement helps establish these boundaries and functions and sets a project scope baseline. Without this baseline, the time for completion and success criteria for final evaluation could expand to unmanageable or unrealistic proportions. A Cost baseline is an approved time-phased budget that monitors and measures cost performance throughout the project life cycle. It includes a budget contingency to accommodate the risk of incurring unidentifiable but normally occurring costs within the defined scope.

Cost baseline varies from project to project, depending on the project's budget and schedule. Schedule variance (SV) is a earned value technique used for measuring the schedule performance on a project. The variance signifies that the schedule is ahead or behind what was planned for this period in time. The schedule variance is calculated based on the following formula: SV = Earned value (EV) - Planned value (PV) If the resulting schedule is negative, it indicates that the project is behind schedule. A value greater than 0 shows that the project is ahead of the planned schedule. A value of 0 indicates that the project is right on target.

A three-point estimate is a way to enhance the accuracy of activity duration estimates. This concept is originated with the Program Evaluation and Review Technique (PERT). PERT charts the following three estimates: • Most likely (TM): The duration of activity based on realistic factors, such as resources assigned, interruptions, etc. • Optimistic (TO): The activity duration based on the best-case scenario • Pessimistic (TP): The activity duration based on the worst-case scenario The expected (TE) activity duration is a weighted average of these three estimates: TE = (TO + 4TM + TP) / 6 Duration estimates based on the above equations (sometimes simple average of the three estimates is also used) provide more accuracy. A PERT chart is a project management tool used to schedule, organize, and coordinate tasks within a project.

PERT stands for Program Evaluation Review Technique, a methodology developed by the U.S. Navy in the 1950s to manage the Polaris submarine missile program.

A PERT chart presents a graphic illustration of a project as a network diagram consisting of numbered nodes (either circles or rectangles) representing events, or milestones in the project linked by labeled vectors (directional lines) representing tasks in the project. The direction of the arrows on the lines indicates the sequence of tasks. GERT is a schedule development technique commonly used by project managers to determine alternate paths of activity flow that can be taken if something goes wrong with the original schedule. GERT illustrates loops in an activity sequence, branches between activities, and different project outcomes.

It allows for conditional and the probabilistic treatment of the logical relationships between the project 's activities following randomly determined sequence of observations. The logical relationships between the project 's activities are primarily based on the dependency between the two project activities or the dependency between a project activity and milestone.

GERT is the only network diagramming technique that provides branching and loop backs for project decisions. An arrow diagramming method (ADM) is a network diagramming technique in which activities are represented by arrows. It is used for scheduling activities in a project plan.

The precedence relation between activities is represented by circles connecting to one or more arrows. The length of the arrow represents the duration of the relevant activity. Use of the ADM as a common project management practice has declined with the adoption of computer-based scheduling tools. The precedence diagram method (PDM) is often favored over the ADM. The ADM is also known as the activity-on-arrow (AOA) method, it only show finish-to-start relationship. The basis for the critical chain method is the same as the basis for the critical path method but with one key difference; the critical chain method accounts for resource limitations.

By adding resource limits to the analysis, the result is that critical path is generally longer. The resource-constrained critical path is known as the critical chain.

If resources are allocated in the scheduling tool, the network diagram will display the critical chain. Using the critical chain method involves adding duration buffers to project schedules to protect the targeted finish date from slippage. Duration buffers are added to the schedule as non-work schedule activities - one at the end of the critical chain and others at the end of each sequence of tasks that feeds into the critical chain. As a result, 'buffer time is integrated throughout the project schedule to account for duration uncertainty.

Later in the project, project teams monitor project progress by reviewing the consumption rate of the buffers. Communication between team members is very important to find out the issues and to determine the progress and challenges of the project. During team meetings, the project manager has an opportunity to see whether intra-team communication is adequate. Are team members aware of what is going on with the work of other team members? This is especially important where there are task dependencies between the work of one team member and that of another. These team members should be aware of each other's work, where it stands, whether there are any issues, and so on.

Of course, not everyone needs to know every detail about what every team member is doing at any given time, but team members should have sufficient communication among them and not operate in an isolated manner. If the project manager feels team communication is inadequate, it must be pointed out to team members during the team meeting or, if the situation warrants it, schedule a private meeting with the team members who do not seem to be communicating. Be sure to explain: • Why communication between team members is important. • The consequences of inadequate communication (perhaps a task has already fallen behind schedule because of lack of intra-team communication). Make sure team members understand your position and rationale.

Don't be accusatory. Attacking people is usually not helpful in resolving issues. Stick to the facts and try to help team members to understand the importance of intra-team communication. Project managers will also want to follow up with the team members involved to make sure communication between them has improved. If they find that a single team member is simply unwilling to share information, they will have to discuss this in a private meeting and, if no changes are made by the team member, they might have to find a replacement. Lack of communication between team members can be a serious threat to the successful outcome of the project.

Communication planning helps in identifying who needs to receive information on the project, what information is required, and how and when they will get that information. Scheduling a project team meeting, developing distribution lists, and creating a project status template are all activities that might be the result of a communication plan. Why is it important? A communications management plan is needed for the smooth flow of information to the stakeholders involved in a project, including the project sponsor, upper management, project team, end-users, and sellers.

Project managers can either use the informal or formal methods of communication (both written and verbal). Project communication is intended to ensure that the project managers, team members, sponsors, stakeholders, sellers, and other people affected by the project can make reasonable, informed decisions throughout the life of a project. Communication planning process helps in identifying who needs to receive information on the project, what information is required, and how they will get that information. Scheduling a project team meeting, developing distribution lists, and creating a project status template are all activities that might be the result of a communication plan. A communications management plan is needed for the smooth flow of information to the stakeholders involved in a project, including the project sponsor, upper management, project team, end-users, and sellers. The plan describes who needs to receive information, what information is needed, when it is needed, and how it is disseminated.

Project managers can either use the informal or formal methods of communication (both written and verbal). The primary purpose of a communication management plan is to ensure that communication does occur. The best intentions to have good communications might fall by the wayside as project managers get inundated with requests and questions. Communication must be planned for from the outset, to ensure the project manager has the time to perform this critical function. A communications management plan must ensure that communication is done right. Too many status reports and meetings end up wasting the time of both the sender and the receiver.

When information is unnecessarily communicated, the receiver might become desensitized. A good communication plan determines who needs what and when. The project manager must understand the communication requirements of stakeholders. Rather than routing an overly detailed report to everyone who might have a need to know some of the content, specific reports need be prepared that meet the specific requirements of various audiences. Once those requirements are understood, the project manager should leverage the power of word processing software to create supersets and subsets of the information to be communicated. Information is prepared only once as a superset, but custom reports can easily be prepared by selecting appropriate subsets. Even when only one audience is identified for a significant piece of information, a form or template can reduce the level of effort in report creation by reminding the project manager of what needs to be addressed in the document and by providing a format for its presentation.

Creating or identifying report forms or formats is a valuable part of an effective communication management plan. Identifying who, what, when, and how An important aspect of the communications management plan is making sure the appropriate stakeholders receive relevant information at regular intervals throughout the project's life cycle. As a project manager, you should create a plan identifying the stakeholders (who), the types of reports they should receive (what), their frequency (when) and how the information will be disseminated (how). A project manager plays a very critical role in communicating with various people in different situations during the course of a project. It is the project manager's responsibility to always keep an open communication atmosphere and use leadership skills to communicate effectively in any situation.

A strict professional decorum and adherence to the organization's business practices should be followed at all times. Certain situations require specific responses on the part of the project manager: 1. Personality conflicts between team members.

Meet with the two team members separately and try to understand their individual issues and concerns. Then meet with them together to discuss and resolve the differences. The project is significantly behind schedule.

Discuss the issue with the sponsor. Minor organizational changes have occurred. Discuss the issue with the project team during the team's regular meeting. An important milestone has been successfully completed. Notify the sponsor and senior management of the achievement. A team member leaves the organization.

Discuss the team member's exit and its effect on the project during the team's regular meeting. A team member passed away unexpectedly. Immediately hold an emergency meeting with the project team to discuss its effect on the project. The main seller is unresponsive. First meet with the seller and review the contract requirements and deliverables. Immediately following that, the sponsor should be notified. In order to protect any legal standing, document objections to the seller in writing.

Significant budget cuts have occurred. Call an emergency meeting of project team and announce the change and how it is going to affect the scope, project, and resources needed for the project. If required, also meet with the seller and negotiate new contract terms. A distribution list is a collection of contacts, which is used to provide an easy way to send messages to a group of people. If a project manager wants to frequently send messages to a group of people in the DBA team, he can create a distribution list called 'dbas' that contains the names and email ids of all the DBAs. An e-mail message sent to this distribution list ensures all the people in that team goes to all recipients listed in the distribution list.

Recipients will see their own names and the names of all other recipients in the 'To ' line of the message instead of seeing the name of the distribution list. A project manager can use distribution lists in messages, task requests, meeting requests, and other distribution lists. A risk management plan is a document arranged by a project manager to estimate the effectiveness of the project, predict risks, and build response plans to mitigate them.

It also consists of the risk assessment matrix. Risks are built-in with any project, and project managers evaluate risks repeatedly and build plans to address them.

The risk management plan consists of analysis of possible risks with both high and low impacts, and the mitigation strategies to facilitate the project and avoid being derailed through which the common problems arise. Risk management plans should be timely reviewed by the project team in order to avoid having the analysis become stale and not reflective of actual potential project risks. Most critically, risk management plans include a risk strategy for project execution. Risk management is a decision-making process that involves the organization, users, and the project team.

It deals with the uncertainties that might occur during the project. During this process, risks are identified and decisions are made about how to mitigate them. The process also involves various decisions about which risks deserve immediate attention. Steps involved in the Risk Management process: 1. To set up goals and identify the risks or impediments that might occur when implementing a project 2.

To collect sufficient information, so that the project team and the organization can make decisions and prioritize the risks for mitigating them 3. To formulate various risk mitigating strategies, plans, and actions by scheduling time for risk planning in the project 4. To monitor the status of high-priority risks, and to report every progress of the plans to the project team and the key stakeholders 5. To control the risk management process by executing various risk mitigation plans and maintaining each and every progress of the program 6. To make proper documentation from the data being collected during the risk plans Identify risks - the project manager, the project team, and key stakeholders are consistently looking to identify risks that can help or hinder the project's success. Risks are recorded in the risk register and tracked throughout the project life cycle. Qualitative risk analysis: this is a fast and subjective review of the identified risks to determine if the risks are valid and should be analyzed in quantitative risk analysis.

Quantitative risk analysis: this is a more in-depth study of the risk's probability and financial impact on the project. Quantitative risk analysis helps the project team and the project manager determine how the risks should be managed.

Plan risk responses: based on the risk identification and analysis the risk responses are created. There are seven risk responses (three for negative risks, three for positive risks, and one for either): mitigation, transference, avoidance, enhance, exploit, share, and acceptance. Identifying risks is the process of determining which risks may affect the project. It also documents risks' characteristics. The identify risks process is part of the project risk management knowledge area. As new risks may evolve or become known as the project progresses through its life cycle, identify risks is an iterative process.

The process should involve the project team so that they can develop and maintain a sense of ownership and responsibility for the risks and associated risk response actions. Risk register is the only output of this process. Identifying Risks is the process of determining which risks may affect the project. It also documents risks' characteristics. The Identify Risks process is part of the Project Risk Management knowledge area.

As new risks may evolve or become known as the project progresses through its life cycle, Identify Risks is an iterative process. The process should involve the project team so that they can develop and maintain a sense of ownership and responsibility for the risks and associated risk response actions.

Risk Register is the only output of this process. Risk tolerance is often misunderstood or overlooked by project managers. The levels and perspectives of risk tolerance are dynamic throughout the life of the project.

The stakeholder 's risk tolerance is influenced by project objective. Each stakeholder has a different tolerance level for risk, but they are rarely asked about it. It is important to get their buy-in for risk sharing, as much as it is important to get their sign-off on the project charter!

Unfortunately, failures in communication between the stakeholder and project manager are quite common because there are few applicable tools available to support the process. In most organizations, stakeholders place their trust in the project manager, without fully understanding the impact of a risk until it's too late. Understanding the risk tolerance of each stakeholder and formulating a risk management plan in conformance to those levels is a key factor to the project manager 's success at dealing with project related risks. In project management terminology, resources are required to complete project tasks. They can be people, equipment, facilities, money, or anything else required for the completion of a project activity. The lack of a resource will therefore be a constraint or risk to project activity. Resources may be storable or non-storable.

Storable resources remain available unless depleted by usage, and may be replenished by project tasks which produce them. Non-storable resources must be renewed for each time period, even if not utilized in previous time periods. Resources may be required for the entire duration of the project, at specific times, or for a specific period in time. Resource scheduling, availability and optimization are key factors to successful project management.

Resource Breakdown Structure (RBS) is a standardized list of personnel resources related by function and arranged in a hierarchical structure. The Resource Breakdown Structure standardizes the Departments personnel resources to facilitate planning and controlling of project work. It defines assignable resources such as personnel, from a functional point of view. It identifies 'who' is doing the work. The total resources define the Top Level, and each subsequent level is a subset of the resource category (or level) above it. Each lower level represents an increasingly detailed description of the resource until small enough to be used in conjunction with the Work Breakdown Structure (WBS) to allow the work to be planned, monitored, and controlled.

Project Quality Management is one of the nine Knowledge Areas. It is a group of processes that include all the activities of the performing organization that determine quality policies, objectives, and responsibilities so that the project will satisfy the needs for which it was undertaken.

It is a group of the following processes necessary to ensure that the project will satisfy customer requirements: • Plan Quality • Perform Quality Assurance • Perform Quality Control These processes measure overall performance, monitor product results, and compare them to the quality standards set out in the project-planning process. The purpose of quality management is to prevent or minimize errors of the deliverables. Quality originates from adequate planning and proper processes during executing.

It is backed by verification and review of each task's output before it is passed on to the next dependent task. Actions that help maintain project quality include applying standards and using qualitative and quantitative evaluation and testing methods. Standards applied throughout the executing phase help to ensure that task outputs are consistent with project goals and objectives. Standards include the following: • Structured plans • Work standards and templates • Structured programming.

Acceptance testing in an IT setting, means that the final project deliverable needs to be tested for user acceptance. In this phase, the system is fully tested by the end user business community against the requirements defined in the analysis and design stages. Corrections are made as required before the Production system is built. In project management terms, it is done at the end of the execution phase, just prior to turnover of the project deliverable and project closure. User acceptance testing validates the end-to-end business process. Quality planning is the basis for turning over deliverables that meet expectations.

A quality management plan involves identifying what constitutes a quality product (or service) and then devising methods to meet that goal. A project manager monitors quality by using methods such as testing, inspections, review by focus groups and users, and customer review meetings. A solid quality management plan needs to be in place to resolve any conflicts and differences that arise among the project team or between seller and buyer during the project. Methods such as voting, evaluations, and discussions help resolve such disagreements.

Quality management involves planning, communication, monitoring, and response. During planning, you determine the quality requirements, how to communicate those requirements, what to monitor and how, and how to respond to various possible occurrences. To ensure quality, sponsor or customer acceptance and sign-off should be obtained at the completion of milestones.

It is important to formalize quality monitoring as part of the project management processes. There are several benefits if user will incorporate monitoring as a project management task, establish requirements for how and when to monitor, and allocate time and budget to perform this task throughout project execution: 1. Tasks tend to get completed if user plan them. Tasks are easier to complete if user have an established system and routines. There are more benefits from monitoring if user have taken the time to determine what user want to get out of the process. A proactive quality management policy is characterized by prevention which keeps errors out of the process.

It pays for quality primarily through prevention and appraisal cost. • Prevention costs: These costs cover training, quality planning, and process improvement cost. • Appraisal costs: These costs keep defects from reaching the customer; they include testing, inspection, and quality audits. Proactive quality management is typically less expensive by a factor of 10 than reactive quality management. As part of the quality management plan, methods need to be devised for resolving disagreements among team members or between seller and buyer about the suitability of deliverables.

Methods for resolving disagreements can include the following: • Individual and group evaluation by team members against written criteria. Checklists or rating scales are helpful when using this method. • Discussion followed by consensus among team members.

• Approval by voting (majority rule). • Final decision made by preselected team members. • Final decision at the sole discretion of the project manager. • Final decision at the sole discretion of the sponsor or customer. The method for resolving disagreements on quality issues should be documented in the project management plan and shared with all team members before work on the project begins. Analyzing project constraints can help project managers to determine whether client satisfaction can be achieved with respect to the quality of the project deliverable.

This analysis will help project managers to anticipate any rework that might need to be done in the foreseeable future. Project managers first must address any government regulations that might affect their project or any industry standards they might need to follow. Once they have identified these constraints, they need to revisit their cost-benefits analysis to double-check for any changes to the project outcome. Project managers might want to look again at your benchmarking; the quality standards they found and planned for need to make the project results more efficient for project managers and the business. For instance, in a software upgrade, they need to ask if the upgrade will allow more information to be gained or whether the upgrade will enable the customers to more easily input information into a Web site.

Useful quality management tools include Pareto chart, control chart, fishbone diagram, flowchart and scatter diagram. After the quality measures are identified, the project manager should implement a system to monitor them throughout the project's life cycle (quality assurance and quality audit). Developing this system includes identifying quantitative and qualitative approaches to determine the extent to which these measures are being met, including the following: • Periodic inspections • Verification testing • Reviews by peers • Customer surveys • Focus groups • Quality review meetings Many organizations employ a quality system and quality policies that meet the requirements of the international standard for quality systems, ISO 9001. Each of the methods previously described might be part of the ISO 9001 requirements for design control verification, validation, and reviews. Project Cost Management consists of the processes involved in planning, estimating, budgeting, and controlling costs in order to complete the project within the approved budget. Project Cost Management (PCM) is a method which uses technology to measure cost and productivity through the full life cycle of enterprise level projects. PCM encompasses several specific functions of project management that include estimating, job controls, field data collection, scheduling, accounting and design.

Beginning with estimating, a vital tool in PCM, actual historical data is used to accurately plan all aspects of the project. As the project continues, job control uses data from the estimate with the information reported from the field to measure the cost and production in the project. From project initiation to completion, project cost management has an objective to simplify and cheapen the project experience. More at: http://en.wikipedia.org/wiki/Project_cost_management.

Analogous is an estimating technique that uses the values of parameter, such as scope, cost, budget, and duration or measures of scale such as size, weight, and complexity from a previous, similar activity as the basis for estimation of the same parameter for a future activity. It is a top-down estimating technique and is a form of expert judgment. It provides a lower degree of accuracy than other estimating techniques. This technique is primarily used when there is a limited amount of detailed information about the project or program. Analogous cost estimation is a method in which top managers use their experience, historical information from similar projects, and expert judgment to determine the total project cost or time estimation. This method is also known as top-down estimation since the estimations are generated for the top levels of the WBS and then shared downward through the levels of WBS.

Analogous cost estimation is used when limited amount of information is available about the project and similar project information is available for comparison. The cost estimation process is used for building an estimate of the monetary resources required to complete project activities. It helps to estimate the costs of a product or project. It defines or compares various techniques for performing cost estimates such as parametric modeling, analogy estimating, and expert judgment. There are many reasons for failures in estimating costs correctly.

Many late or over-budget projects deemed failures are actually only estimating failures. Bad estimates are, among others, due to the either incomplete or changing requirements, or a lack of familiarity of team members with project tasks.

The first implication is that requirements must be clearly established. Estimating from incomplete requirements increases the risk of scope creep or delivery of an ill-fitting product (or service) needing major rework. One of the goals of the work breakdown structure is to describe tasks at a level of detail sufficient to facilitate the estimating process. Estimates may need to be revised throughout the project. Only with confidence in the relative accuracy of an estimate is time and cost tracking a valuable exercise. Project budgets are usually defined and regulated by the accounting department, they are usually broken down by some specific cost categories. Some of the basic example of cost categories consists of hardware, software, training etc.

Client should make a copy of their working organization's cost categories so that they can track and classify their resources in future. Project budgets are as varied as other projects themselves.

The Lordof The Rings Hindidabbled Mkvfull M there. Although the format for project budgets may be related from project to project, the expenses, budget amounts, and categories client use will modify for each project. There are many causes of estimating failures.

Many late or over-budget projects deemed failures are actually only estimating failures. Bad estimates are, among others, due to the following factors: 1. Incomplete or changing requirements 2. Lack of familiarity of team members with tasks The first implication is that requirements must be clearly established. Estimating from incomplete requirements increases the risk of scope creep or delivery of an ill-fitting product (or service) needing major rework. One of the goals of the work breakdown structure is to describe tasks at a level of detail sufficient to facilitate the estimating process. Estimates may need to be revised throughout the project.

Only with confidence in the relative accuracy of an estimate is time and cost tracking a valuable exercise. The following table defines the three major elements of estimating and their importance in the planning process. Free Workshop Manual For Peugeot 106 Wiki. Effort time is the total number of person hours (or person days) needed to complete a specified activity. If two people working full time (40 hours) for a week could do a system design, then the needed effort time estimate is 80 hours.

Effort time is mostly reported in terms of full-time equivalents (FTEs). If 40 hours is defined as the regular number of hours that a resource is supposed to work in a week, then that is a single FTE.

The total FTEs is the sum of all of the work hours put in by all resources divided by 40. The effort time estimate drives the needed number of resources.

Accurate estimating uses one or more of the following techniques: • Experience: Acceptable when both the business problem and the technical problem are within the experience of the estimator. • Activity or deliverable: Based on activities or deliverables to produce an overall estimate. Requires an application development methodology that includes necessary activities or deliverables, a database of related metrics, and variance factors (for example, complexity). • Function point: Uses a function point (size) estimate and historical productivity metrics to calculate effort. Function points quantify the functions performed by software in relation to business needs.

The International Function Point Users Group (IFPUG), in the IFPUG Counting Manual, describes the method for counting functions. Project costs typically fall into the following categories: • Labor • Equipment and material • Facilities The above costs are typically charged directly to a project (direct costs) while others are overhead (indirect costs). Direct labor costs include the costs for personnel actively involved in the project, and direct equipment and material costs are costs that are directly associated with the project.

For example, computer and networking components are direct equipment and material costs. Indirect overhead costs include items used in support of the project, such as the cost of support and administrative personnel, and the cost of incidentals, such as office supplies, rent and electricity. Project managers will generally use one of three categories to estimate cost: 1. Analogous estimates: Sometimes referred to as top-down estimates, these use estimates based on earlier, similar projects for comparison. Parametric estimates: Require a multiplication to gauge the cost of the task that needs to be completed. For example, if a square foot of hardwood flooring costs $ 15, then it should cost $ 3000 to put hardwood flooring in for 200 square feet.

Bottom-up estimates: Use estimates at the lowest level of the Work Breakdown Structure (WBS), i.e., at the Work Package level, which are then consolidated to an overall estimate for the project. The chart of accounts (COA) is used to list the account number and description for each category of expense user will use on the budget. It is used to create the list of the accounts used by a business entity to describe each class of items for which money or the equivalent is spent or received.

It also helps in organizing the finances of the entity and to segregate expenditures, revenue, assets and liabilities in order to give involved parties a better indulgent of the financial health of the entity. Budget planning entails creating a bottom-up budget. Budgeting takes into consideration the timing of the expenses and the spending pattern of the project. Budget variance is used throughout the project's life cycle to calculate the difference between initial allocated budget and the actual spending. A contingency reserve and/or management reserve is created that can be used in case of a budget shortage. A bottom-up budget starts with detailed cost estimates.

In its simplest form, a bottom-up budget is just a roll-up of cost subtotals of various parts of the project. Project expenses are integrated with the chart of accounts kept by the accounting department. Such a budget can help demonstrate whether the project manager can meet the top-down budget that was developed during initiating. A budget has to provide an allocation over time and allowance for risk. A contingency reserve helps meet unexpected costs from project.

The contingency reserve is money client have set aside to cover unexpected costs within the original scope of the project. The amount of the contingency reserve varies, but most project managers will place a percentage of the total project costs into this reserve. The project manager, manage this fund. The same principles apply to the management reserve as they do to the contingency fund.

Client would typically allocate a percentage of the total project funding to this account. However, senior management oversees the management reserve. Here are some considerations for project managers to keep in mind while they perform cost estimation for their projects: • When client formulate the cost estimates, document cost estimates and calculations. This information will help answer questions from stakeholders.

• Use software or templates related to project to help you. • Consolidate all estimates to an overall cost baseline (or budget) for the project. Get contributions from your project team; work with them to brainstorm possible costs. This technique will help the client to get by-in from the team.

Project Procurement Management is a group of processes to purchase or acquire the products, services, or results needed from outside the project team to perform the work. Following are the four processes that are part of Project Procurement Management: • Plan Procurements • Conduct Procurements • Administer Procurements • Close Procurements Project Procurement Management includes administering any contract issued by an outside organization (the buyer) that is acquiring the project from the performing organization (the seller), and administering contractual obligations placed on the project team by the contract. Reasons for disagreements with a seller are many, but here are some examples: • Misunderstanding: Sometimes, disagreements stem simply from misunderstandings or miscommunication on either part (seller or team members). Getting to the bottom of the misunderstanding should resolve the disagreement.

• Team member rigidity: Now and then, disagreements come from a team member thinking rigidly. For example, the team member might not want anything to change from the way things were done before. In this scenario, the seller is not doing anything wrong; rather, the team member is resisting perhaps a new technology he or she has to learn, or perhaps the team member is convinced that one technology is better than another. (This is often the case if a new product is being implemented; many IT people have strong preferences for one product over another.) In this scenario, client will have to convince the team member that going with the new technology is integral to the project's success and try to get the team member's buy-in. Sometimes, a team member simply thinks he or she knows what is best for the project even better than the seller. This can be a serious problem. Try to address it with the team member, but if he insists on being right and is unwilling to cooperate with the seller, he can jeopardize the success of the project.

In this scenario, client might have to look to replace the team member. • Seller rigidity: In some cases, the seller is unwilling (or perhaps even unable) to be flexible in terms of their product offering and how it will fit into project simply because their product is too complex and integrated for changes or adjustments to be made. In this scenario, clients are usually getting an integrated solution from one seller, making dependent on them. The seller will show little to no flexibility in terms of how things are done when it comes to the product they are delivering. This is actually a point client should have anticipated before selecting the seller if inflexibility of this type does not work well for organization and if sticking to the constraints of a particular product does not work for the project, client might have selected the wrong seller. They might be completely aware of this constraint and might have to convince team members the seller is simply delivering what they were requested to deliver. At times, disagreements between sellers and the project team might arise.

In this situation client will have to meet with the team member(s) that are involved in the disagreement, as well as with the seller (not necessarily at the same time) to be able to hear both sides of the story. Gap analysis is a technique that helps a company to compare its actual performance with its potential performance. It is a formal study of what a business is doing currently and where it wants to go in the future. Gap analysis provides a foundation for measuring investment of time, money, and human resources required to achieve a particular outcome.

The goal of gap analysis is to identify the gap between the optimized allocation and integration of the inputs, and the current level of allocation. This helps provide the company with insight into areas, which could be improved. The gap analysis process involves determining, documenting, and approving the variance between business requirements and current capabilities. Procurement planning is the process of identifying the project needs that can best be met by using products or services from sources external to the organization. The procurement management plan outlines the following: • Whether to procure • How to procure • What to procure • How much to procure • When to procure Input needed for procurement planning includes the scope statement, product descriptions, market conditions, constraints, and assumptions. For example, a large company might consider outsourcing the delivery, maintenance, and basic user training and support for laptops supplied to its international sales and marketing personnel.

The company makes this decision according to the procurement planning input. If the suppliers can provide these services at a reasonable cost, the company can decide to outsource these services. Doing so reduces fixed and recurring costs for the company and enables it to focus on its core business. Clients must understand the need to procure products or services and the input required for procurement planning. They must clearly define the scope of the project, the products, market conditions, and constraints and assumptions before undertaking procurement planning.

It is essential for organizations to prepare evaluation criteria, preferably before they issue a formal RFP or RFQ. Organizations use criteria to rate or score proposals, and they often assign a weight to each criterion to indicate its importance. Some examples of criteria include the technical approach (30 percent weight), management approach (30 percent weight), past performance (20 percent weight), and price (20 percent weight).

The criteria should be specific and objective. For example, if the buyer wants the seller's project manager to be a certified Project Management Professional (PMP), this requirement must be stated clearly in the procurement documents and followed during the award process. Losing bidders might pursue legal recourse if the buyer does not follow a fair and consistent evaluation process. Input, a firm with a focus on government contracts, provides market reports and buyer guides to assist organizations in outsourcing. One buyer guide offers suggestions on selection criteria, which include reputation and past performance, industry knowledge, strategic partnership, and ability to meet needs.

Input's research shows that most contracts include provisions to safeguard against unsatisfactory partnering, but most companies hesitate to exercise the provisions. Buyers should look for a supplier with a proven record of excellence and reputation for quality.

It is critical to evaluate proposals on more than the appearance of the paperwork. A key factor in evaluating bids is the bidder's past performance record. The RFP should require bidders to list similar projects they have worked on and provide customer references. Reviewing performance records and references helps reduce the risk of selecting a seller with a poor track record. Sellers should demonstrate their understanding of the buyer's needs, their technical and financial capabilities, their management approach, and their price for delivering the desired goods and services.

Some projects require potential sellers to deliver a technical presentation as part of their proposal. The proposed project manager should lead the potential seller's presentation team. When the external project manager leads the proposal presentation, the organization can build a relationship with the potential seller. Visits to contractor sites can also help the buyer get information about the seller's capabilities and project management style. Request seller response involves obtaining proposals from prospective sellers. Prospective sellers complete most of the work in this process, at no cost to the buyer. The buying organization might hold a bidders' conference to answer questions about the procurement.

Organizations can advertise in many different ways to procure products and services. Sometimes, a specific seller might be the buyer's preferred seller. In this case, the buyer provides procurement information only to that seller. If the preferred seller responds favorably, both organizations proceed to work together. In many cases, however, several sellers might be qualified to provide the desired products and services. Solicitation from several potential sellers often provides the buyer the advantage of a competitive business environment and allows the development of competitive bidding strategies.

As a result, the buyer might be able to procure products and services at a lower cost. A bidders' conference is a meeting with prospective sellers prior to the preparation of a proposal. These conferences help ensure that everyone involved shares a clear and common understanding of the products or services the buyer desires. The buyer might incorporate responses to questions as amendments to the procurement documents before, during, or after the conference. Reasons for disagreements with a seller are many, but here are some examples: • Misunderstanding: Sometimes, disagreements stem simply from misunderstandings or miscommunication on either part (seller or team members). Getting to the bottom of the misunderstanding should resolve the disagreement • Team member rigidity: Now and then, disagreements come from a team member thinking rigidly. For example, the team member might not want anything to change from the way things were done before.

In this scenario, the seller is not doing anything wrong; rather, the team member is resisting perhaps a new technology he or she has to learn, or perhaps the team member is convinced that one technology is better than another. (This is often the case if a new product is being implemented; many IT people have strong preferences for one product over another.) In this scenario, client will have to convince the team member that going with the new technology is integral to the project's success and try to get the team member's buy-in.

• Sometimes, a team member simply thinks he or she knows what is best for the project even better than the seller. This can be a serious problem. Try to address it with the team member, but if he insists on being right and is unwilling to cooperate with the seller, he can jeopardize the success of the project. In this scenario, client might have to look to replace the team member. • Seller rigidity: In some cases, the seller is unwilling (or perhaps even unable) to be flexible in terms of their product offering and how it will fit into project simply because their product is too complex and integrated for changes or adjustments to be made. In this scenario, clients are usually getting an integrated solution from one seller, making dependent on them.

The seller will show little to no flexibility in terms of how things are done when it comes to the product they are delivering. This is actually a point client should have anticipated before selecting the seller if inflexibility of this type does not work well for organization and if sticking to the constraints of a particular product does not work for the project, client might have selected the wrong seller.

They might be completely aware of this constraint and might have to convince team members the seller is simply delivering what they were requested to deliver. At times, disagreements between sellers and the project team might arise.

In this situation client will have to meet with the team member(s) that are involved in the disagreement, as well as with the seller (not necessarily at the same time) to be able to hear both sides of the story. A transition plan is used to describe how the deliverables of a project will be brought to full operational status, integrated into existing operations and maintained, once a project goes live.

This plan is usually developed during the Planning Phase. A transition plan discusses issues such as: 1. Transition dates 3.

Training of end-users 4. Extended support 5.

Warranties The project management plan also contains information about the processes and procedures that are necessary at the conclusion of the project to transition the product (or service) to operations (in case of an internal project) or the customer (in case of an external project). Ownership: When a project is completed and a set of deliverables have been created, someone must now be responsible for the management of deliverables. The transition plan describes the ownership of project deliverables and makes a person responsible for the maintenance and upkeep on the deliverables. Transition dates: There should be a defined date for the deliverables to be transferred to the organization; an account of the conditions for the deliverables to be moved from the management of the project to the management of operations. Transition dates can be defined as a defined date for the deliverables to be transferred to the organization; an account of the conditions for the deliverables to be moved from the management of the project to the management of operations. Training: The project team should train the recipients of the deliverables and define how to use and maintain the deliverables. This can be made through training manuals, train-the-trainer sessions, hands on exercises, or a combination of knowledge transfer events.

Assume that there will be a learning curve and plan for plenty of training. Extended support: There should be some extended support depending upon the type of project and the deliverable. The extended support entails the project team and the operation team to work together as the new technology is applied so that the operational team can learn from the project team about the project deliverables and implementation. Warranties: There must be some warranty information about the project deliverables if the project was completed by a vendor for a client. The warranty must be detailed in the project contract and talked about during the operation transfer.

A warranty is basically an assurance by one party to the other party that specific conditions are true. The various objectives of a transition plan are as follows: • Transition dates: There should be a defined date for the deliverables to be transferred to the organization; an account of the conditions for the deliverables to be moved from the management of the project to the management of operations. • Ownership: When a project is completed and a set of deliverables have been created, someone must now be responsible for the management of deliverables. The transition plan describes the ownership of project deliverables and makes a person responsible for the maintenance and upkeep on the deliverables.

• Training: The project team should train the recipients of the deliverables and define how to use and maintain the deliverables. This can be made through training manuals, train-the-trainer sessions, hands on exercises, or a combination of knowledge transfer events. • Extended support: There should be some extended support depending upon the type of project and the deliverable. The extended support entails the project team and the operation team to work together as the new technology is applied so that the operational team can learn from the project team about the project deliverables and implementation. • Warranties: There must be some warranty information about the project deliverables if the project was completed by a vendor for a client. The warranty must be detailed in the project contract and talked about during the operation transfer. A risk fallback plan is a proper plan devised to identify definite action to be taken if the risk action plan (risk mitigation plan) is not helpful.

The fallback plan is important in risk response planning. If the contingency plan for a risk is not successful, then the project team implements the fallback plan.

Fall-back planning is intended for a known and specific activity that may perhaps fail to produce desired outcome. It is related with technical procedures and with the responsibility of the technical lead.