Friday, March 9, 2012

Project Procurement Management & Contract Types

Project Procurement Management


Project Procurement Management includes the processes necessary to purchase or acquire products, services, or results needed from outside the project team. The organization can be either the buyer or seller of the products, services, or results of a project.

The Procurement Project Management processes are:

Plan Procurement - The process of documenting project purchasing decisions, specifying the approach, and identifying potential sellers.

Conduct Procurement - The process of obtaining seller responses, selecting a seller, and awarding a contract.

Administer Procurement - The process of managing procurement relationships, monitoring contract performance, and making changes and corrections as needed.

Close Procurement - The process of completing each project procurement.

The PMBOK contains comprehensive information to prepare for the exam. This page further details the contract types to to support your studies.

Contract Types

The risk shared by the buyer and seller is determined by the contract type. The characteristics of the major contract types are defined as follows:

Fixed-price contracts

The category of contracts involves setting a fixed total price for a defined product or service to be provided. Fixed-price contracts may also incorporate financial incentives for achieving or exceeding selected project objectives, such as schedule delivery dates, cost and technical performance, or anything that can be quantified and subsequently measured. Sellers under fixed-price contracts are legally obligated to complete such contracts, with possible financial damages if they do not. Under the fixed-price arrangement, buyers must precisely specify the product of services being procured. Changes in scope can be accommodated, but generally at an increase in contract price.

Firm Fixed Price Contracts (FFP)

The most commonly used contract type is the FFP. It is favored by most buying organizations because the price for goods is set at the outset and not subject to change unless the scope of work changes. Any cost increase due to adverse performance is the responsibility of the seller, who is obligated to complete the effort. Under the FFP contract, the buyer must precisely specify the product or services to be procured, and any changes to the procurement specification can increase the costs to the buyer.

Example: Software Package for $25,000. The payment will $25,000 regardless of the seller cost.

Fixed Price Incentive Fee Contracts (FPIF)

This fixed-price arrangement gives the buyer and seller some flexibility in that allows for deviation from performance, with financial incentives tied to achieving agreed to metrics. Typically such financial incentives are related to cost, schedule, or technical performance of the seller. Performance targets are established at the outset, and the final contract price is determined after completion of all work based on the seller's performance. Under FPIF contracts, a price ceiling is set, and all costs above the price ceiling are the responsibility of the seller, who is obligated to complete the work.

Example: Under development.

Fixed Price with Economic Price Adjustment Contracts (FP-EPA)

This contract type is used whenever the seller's performance period spans a considerable period of years, as is desired with many long-term relationships. It is a fixed-price contract, but with a special provision allowing for pre-defined final adjustments to the contract price due to changed conditions, such as inflation changes, or cost increases (or decreases) for specific commodities. The EPA clause must relate to some reliable financial index which is used to precisely adjust the final price. The FP-EPA contract is intended to protect both buyer and seller from external conditions beyond their control.

Example: Under development.

Cost-reimbursable contracts

This category of contract involves payments (cost reimbursements) to the seller for all legitimate actual costs incurred for completed work, plus a fee representing seller profit. Cost-reimbursable contracts may also include financial incentive clauses whenever the seller exceeds, of falls below, defined objectives such as costs, schedule, or technical performance targets.

A cost-reimbursable contract gives the project flexibility to redirect a seller whenever the scope of work cannot be precisely defined at the start and needs to be altered, or when high risks may exist in the effort.

Cost plus Fixed Fee Contract (CPFF)

The seller is reimbursed for all allowable costs for performing the contract work, and receives a fixed fee payment calculated as a percentage of the initial estimated project costs. Fee is paid only for completed work and does not change due to seller performance. Fee amounts do not change unless the project scope changes.

Example: If your cost ceiling is $80,000 and the fixed fee is $8,000 for a total contract value of $88,000, the seller will be reimbursed for cost incurred up to, but not exceeding,$90,000 and will receive $8,000 as a fee. If the seller spend more than $80,000 the reimbursement will be $80,000 plus $8,000 fee. If the seller spent $70,000 the reimbursement will be $70,000 and the fee will be $8,000 as agreed in the contract.

Cost Plus Incentive Fee Contracts (CPIF)

The seller is reimbursed for all allowable costs for performing the contract work and receives a predetermined incentive fee based upon achieving certain performance objectives as set forth in the contract. IN CPIF contracts, if the final costs are less or greater than the origin estimated costs, then both the buyer and seller share costs from the departures based upon a prenegotiated cost sharing formula, e.g., an 80/20 split over/under target costs based on the actual performance of the seller.

To achieve the incentive, in CPIF contracts, the seller is paid his target cost plus an initially negotiated fee plus a variable amount that is determined by subcontractor the target cost from the actual cost, and multiplying the difference by the buyer ratio.

Formula: Final payout = target cost + fixed fee + buyer share ratio * (actual cost - target cost).
If there is a ceiling price involved and actual cost is more than the ceiling final payout = target cost + fixed fee + buyer share ratio * (ceiling price - target cost).

Example: If the final costs are higher than the target, say 1100, the buyer will pay 1000 + 100 + 0.8 *(1100-1000)=1180 (seller earns 80 which is less than if he had reached the target cost).

Cost plus award Fee Contracts (CPAF)

The seller is reimbursed for all legitimate costs, but a majority of the fee is only earned based on the satisfaction of certain broad subjective performance criteria and incorporated into the contract. The determination of fee is based solely on the subjective determination of seller performance by the buyer, and is generally not subject to appeals.

In other words, a contractor is offered an incentive award amount that may be earned (in part of full) based on the excellence displayed in contract completion time, cost, effectiveness, quality of work, and technical ingenuity.

Example: Preparation of the technical modification to improve the quality of the assembly line. The seller commits to reimburse all cost including an incentive of $10,000, of which $5,000 will be based on the cost effectiveness of this contract.

Time and Material Contracts (T&M)

Time and material contracts are a hybrid type of contractual arrangement that contain aspects of both cost-reimbursable and fixed-price contracts. They are often used for staff augmentation, acquisition of experts, and any outside support when a precise statement of work cannot be quickly prescribed.

These types of contracts resemble cost-reimbursable contracts in that they can be left open ended and may be subject to a cost increase for the buyer.

The full value of the agreement and the exact quantity of items to be delivered may not be defined by the buyer at the time of the contract award. Thus, T&M contracts can increase in contract value as if they were cost-reimbursable contracts.

Many organizations require not-to-exceed values and time limits placed in all T&M contracts to prevent unlimited cost growth. Consequently, T&M contracts can also resemble fixed unit price arrangements when certain parameters are specified in the contract.

Unit labor or material rates can be preset by the buyer and seller, including seller profit, when both parties agree on the values for specific resource categories.

Example 1: Business consultant to an hourly rate of $150.

Example 2: Business consultant to an hourly rate of $150. The consultant activity is limited to 500 hours.

Example 3: Business consultant to an hourly rate of $150. The consultant activity is limited to $10,000.

Friday, March 2, 2012

Project Risk Management and Essentials

A project is, by definition, unique. This uniqueness implies risks. So, if you want to manage your project, you need to manage the risks, just as you need to manage the planning, or the customer, or the scope, or the costs etc.
A risk is something that may happen and if it does, will have a positive or negative impact on the project. A few points here. "That may happen" implies a probability of less then 100%. If it has a probability of 100% - in other words it will happen - it is an issue. An issue is managed differently to a risk and we will handle issue management in a later white paper. A risk must also have a probability something above 0%. It must be a chance to happen or it is not a risk.
The second thing to consider from the definition is "will have a positive or negative impact". Most people dive into the negative risks but what if something goes right?

Take the example I came across recently where we identified a project finishing ahead of schedule as a risk. It might seem to be a bonus but the completion date happened to occur at the busiest time of the year for the company. The last thing they needed was a project going live in their peak period. The mitigation was that if we were ahead of schedule, we would slow the project down by reducing resources.

Risk Management Plan

There are four stages to risk management planning. They are: ·
  • Risk Identification
  • Risks Quantification
  • Risk Response
  • Risk Monitoring and Control

Risk Identification:

In this stage, we identify and name the risks. The best approach is a workshop with business and IT people to carry out the identification. Use a combination of brainstorming and reviewing of standard risk lists.
There are different sorts of risks and we need to decide on a project by project basis what to do about each type.
Business risks are ongoing risks that are best handled by the business. An example is that if the project cannot meet end of financial year deadline, the business area may need to retain their existing accounting system for another year. The response is likely to be a contingency plan developed by the business, to use the existing system for another year.
Generic risks are risks to all projects. For example the risk that business users might not be available and requirements may be incomplete. Each organisation will develop standard responses to generic risks.
Risks should be defined in two parts. The first is the cause of the situation (Vendor not meeting deadline, Business users not available, etc.). The second part is the impact (Budget will be exceeded, Milestones not achieved, etc.). Hence a risk might be defined as "The vendor not meeting deadline will mean that budget will be exceeded". If this format is used, it is easy to remove duplicates, and understand the risk.

Risk Quantification

Risk need to be quantified in two dimensions. The impact of the risk needs to be assessed. The probability of the risk occurring needs to be assessed. For simplicity, rate each on a 1 to 4 scale. The larger the number, the larger the impact or probability. By using a matrix, a priority can be established.
Note that if probability is high, and impact is low, it is a Medium risk. On the other hand if impact is high, and probability low, it is High priority. A remote chance of a catastrophe warrants more attention than a high chance of a hiccup.

Risk Response

There are four things you can do about a risk. The strategies are:
  • Avoid the risk. Do something to remove it. Use another supplier for example.
  • Transfer the risk. Make someone else responsible. Perhaps a Vendor can be made responsible for a particularly risky part of the project.
  • Mitigate the risk. Take actions to lessen the impact or chance of the risk occurring. If the risk relates to availability of resources, draw up an agreement and get sign-off for the resource to be available.
  • Accept the risk. The risk might be so small the effort to do anything is not worth while.
A risk response plan should include the strategy and action items to address the strategy. The actions should include what needs to be done, who is doing it, and when it should be completed.

Risk Control:
The final step is to continually monitor risks to identify any change in the status, or if they turn into an issue. It is best to hold regular risk reviews to identify actions outstanding, risk probability and impact, remove risks that have passed, and identify new risks.

For every Project, PM should ensure proper identification of Risks and ways to mitigate them with proper contingency plans followed with fall back plan.The following 5 key elements have to be managed in Risk Management:

Risk management is not a complex task. If you follow the four steps, you can put together a risk management plan for a project in a short space of time. Without a plan, the success of the project, and your reputation as a Project Manager, are on the line. Follow these steps and you will increase your chances of success.

Stakeholder Management: A Key Aspect of Project Management

Stakeholder Management is an important discipline that successful architecture practitioners can use to win support from others. It helps them ensure that their projects succeed where others fail.
The benefits of successful Stakeholder Management are that:
  • The most powerful stakeholders can be identified early and their input can then be used to shape the architecture; this ensures their support and improves the quality of the models produced.
  • Support from the more powerful stakeholders will help the engagement win more resource, thus making the architecture engagement more likely to succeed.
  • By communicating with stakeholders early and frequently, the architecture team can ensure that they fully understand the architecture process, and the benefits of enterprise architecture; this means they can support the architecture team more actively when necessary.
  • The architecture team can more effectively anticipate likely reactions to the architecture models and reports, and can build into the plan the actions that will be needed to capitalize on positive reaction while avoiding or addressing any negative reactions.
  • The architecture team can identify conflicting or competing objectives among stakeholders early and develop a strategy to resolve the issues arising from them.
It is essential in any initiative to identify the individuals and groups within the organization who will contribute to the development of the architecture, identify those that will gain and those that will lose from its introduction, and then develop a strategy for dealing with them.
Approach to Stakeholder Management
Stakeholder analysis should be used during Phase A (Architecture Vision) to identify the key players in the engagement, and also be updated throughout each phase; different stakeholders may be uncovered as the engagement progresses through into Opportunities & Solutions, Migration Planning, and Architecture Change Management.
Complex architectures are extremely hard to manage, not only in terms of the architecture development process itself, but also in terms of obtaining agreement from the large numbers of stakeholders touched by it.
For example, just as a building architect will create wiring diagrams, floor plans, and elevations to describe different facets of a building to its different stakeholders (electricians, owners, planning officials), so an enterprise architect must create different views of the business, information system, and technology architecture for the stakeholders who have concerns related to these aspects.
 Steps in the Stakeholder Management Process
The following sections detail recommended Stakeholder Management activity.

 Identify Stakeholders:

Identify the key stakeholders of the enterprise architecture.
The first task is to brainstorm who the main enterprise architecture stakeholders are. As part of this, think of all the people who are affected by it, who have influence or power over it, or have an interest in its successful or unsuccessful conclusion.
It might include senior executives, project organization roles, client organization roles, system developers, alliance partners, suppliers, IT operations, customers, etc.
When identifying stakeholders there is a danger of concentrating too heavily on the formal structure of an organization as the basis for identification. Informal stakeholder groups may be just as powerful and influential as the formal ones.
Most individuals will belong to more than one stakeholder group, and these groups tend to arise as a result of specific events.
Look at who is impacted by the enterprise architecture project:
  • Who gains and who loses from this change?
  • Who controls change management of processes?
  • Who designs new systems?
  • Who will make the decisions?
  • Who procures IT systems and who decides what to buy?
  • Who controls resources?
  • Who has specialist skills the project needs?
  • Who has influence?
In particular, influencers need to be identified. These will be well respected and moving up, participate in important meetings and committees (look at meeting minutes), know what's going on in the company, be valued by their peers and superiors, and not necessarily be in any formal position of power.
Although stakeholders may be both organizations and people, ultimately the enterprise architecture team will need to communicate with people. It is the correct individual stakeholders within a stakeholder organization that need to be formally identified.

Sample Stakeholder Analysis
A sample stakeholder analysis that distinguishes 22 types of stakeholder, in five broad categories, is shown in the following figure. Any particular architecture project may have more, fewer, or different stakeholders; and they may be grouped into more, fewer, or different categories.

Consider both the Visible team - those obviously associated with the project/change - and the Invisible team - those who must make a real contribution to the project/change for it to be successful but who are not obviously associated with it (e.g., providers of support services).
Classify Stakeholder Positions
Develop a good understanding of the most important stakeholders and record this analysis for reference and refresh during the project. An example stakeholder analysis is shown in the following table

Stakeholder Group
Ability to Disrupt Change
Current under-standing
Required under-standing
Current Commit-ment
Required Commit-ment
Required Support
John Smith
Jeff Brown

 Example Stakeholder Analysis
It is also important to assess the readiness of each stakeholder to behave in a supportive manner (i.e., demonstrate commitment to the enterprise architecture initiative).
This can be done by asking a series of questions:
  • Is that person ready to change direction and begin moving towards the Target Architecture? If so, how ready?
  • Is that person capable of being a credible advocate or agent of the proposed enterprise architecture initiative? If so, how capable?
  • How involved is the individual in the enterprise architecture initiative? Are they simply an interested observer, or do they need to be involved in the details?
  • Has that person made a contractual commitment to the development of the enterprise architecture, and its role in the governance of the development of the organization?
Then, for each person whose commitment is critical to ensure success, make a judgment as to their current level of commitment and the desired future level of commitment.

Determine Stakeholder Management Approach:
The previous steps identified a long list of people and organizations that are affected by the enterprise architecture project.
Some of these may have the power either to block or advance. Some may be interested in what the enterprise architecture initiative is doing; others may not care. This step enables the team to easily see which stakeholders are expected to be blockers or critics, and which stakeholders are likely to be advocates and supporters of the initiative.
Work out stakeholder power, influence, and interest, so as to focus the enterprise architecture engagement on the key individuals. These can be mapped onto a power/interest matrix, which also indicates the strategy to adopt for engaging with them. The below mentioned figure  shows an example power grid matrix.

Figure 24-2: Stakeholder Power Grid

Tailor Engagement Deliverables:
Identify catalogs, matrices, and diagrams that the architecture engagement needs to produce and validate with each stakeholder group to deliver an effective architecture model.
It is important to pay particular attention to stakeholder interests by defining specific catalogs, matrices, and diagrams that are relevant for a particular enterprise architecture model. This enables the architecture to be communicated to, and understood by, all the stakeholders, and enables them to verify that the enterprise architecture initiative will address their concerns
Template Stakeholder Map:
The following table provides an example stakeholder map

Key Concerns
Catalogs, Matrices and Diagrams
(Corporate Functions);
e.g., CEO, CFO, CIO, COO
The high-level drivers, goals, and objectives of the organization, and how these are translated into an effective process and IT architecture to advance the business.
Business Footprint diagram
Goal/Objective/ Service diagram
Organization Decomposition diagram
Program Management Office
(Corporate Functions);
e.g., Project Portfolio Managers
Prioritizing, funding, and aligning change activity. An understanding of project content and technical dependencies between projects supports portfolio management decision-making.
Requirements catalog
Project Context diagram
Benefits diagram
Business Footprint diagram
Application Communication diagram
Functional Decomposition diagram
(Corporate Functions);
e.g., Acquirers
Understanding what building blocks of the architecture can be bought, and what constraints (or rules) are relevant to the purchase. Acquirers will shop with multiple vendors looking for the best cost solution while adhering to the constraints (or rules) derived from the architecture, such as standards. The key concern is to make purchasing decisions that fit the architecture.
Technology Portfolio catalog
Technology Standards catalog
Human Resources (HR)
(Corporate Functions);
e.g., HR Managers, Training & Development Managers
The roles and actors are required to support the architecture and changes to it. The key concern is managing people transitions.
Organization Decomposition diagram
Organization/Actor catalog
Location catalog
Application and User Location diagram
Enterprise Security
(Corporate Functions);
e.g., Corporate Risk Management, Security Officers, IT Security Managers
Ensuring that the information, data, and systems of the organization are available to only those that have permission, and protecting the information, data, and systems from unauthorized tampering.
Product Lifecycle diagram
Data Dissemination diagram
Data Security diagram
Actor/Role matrix
Networked Computing Hardware diagram
Communications Engineering diagram
QA/Standards Group
(Corporate Functions);
e.g., Data Owners, Process Owners, Technical Standards Bodies
Ensuring the consistent governance of the organization's business, data, application, and technology assets.
Process/Event/ Control/Product catalog
Contract/Measure catalog
Application Portfolio catalog
Interface catalog
Technology Standards catalog
Technology Portfolio catalog
(End User Organization);
e.g., Business Unit Directors, Business Unit CxOs, Business Unit Head of IT/Architecture
The high-level drivers, goals, and objectives of the organization, and how these are translated into an effective process and architecture to advance the business.
Business Footprint diagram
Goal/Objective/ Service diagram
Organization Decomposition diagram
Process Flow diagram
Application Communication diagram
Line Management
(End User Organization);
e.g., Senior Business Managers, Operations Regional Managers, IT Managers
Top-level functions and processes of the organization, and how the key applications support these processes.
Business Footprint diagram
Organization Decomposition diagram
Functional Decomposition diagram
Process Flow diagram
Application Communication diagram
Application and User Location diagram
Business Domain Experts
(End User Organization);
e.g., Business Process Experts, Business/Process Analyst, Process Architect, Process Designer, Functional Managers, Business Analyst
Functional aspects of processes and supporting systems. This can cover the human actors involved in the system, the user processes involved in the system, the functions required to support the processes, and the information required to flow in support of the processes.
Business Interaction matrix
Actor/Role matrix
Business Service/ Information diagram
Functional Decomposition diagram
Product Lifecycle diagram
Business Use-case diagram
Application Use-case diagram
Application Communication diagram
Data Entity/Business Function matrix
IT Service Management
(Systems Operations);
e.g., Service Delivery Manager
Ensuring that IT services provided to the organization meet the service levels required by that organization to succeed in business.
Technology Standards catalog
Technology Portfolio catalog
Contract/Measure catalog
Process/Application Realization diagram
Enterprise Manageability diagram
IT Operations - Applications
(System Operations);
e.g., Application Architecture, System & Software Engineers
Development approach, software modularity and re-use, portability migration, and interoperability.
Process/Application Realization diagram
Application/Data matrix
Application Migration diagram
Software Engineering diagram
Platform decomposition Diagram
Networked Computing/ Hardware diagram
Software distribution Diagram
IT Operations - Infrastructure
(System Operations);
e.g., Infrastructure Architect, Wintel support, Mid-range support, Operational DBA, Service Desk
Location, modifiability, re-usability, and availability of all components of the system. Ensuring that the appropriate components are developed and deployed within the system in an optimal manner.
Platform Decomposition diagram
Technology Standards catalog
Technology Portfolio catalog
Enterprise Manageability diagram
Networked Computing/ Hardware diagram
Processing diagram
Environments and Locations diagram
IT Operations - Data/Voice Communications
(System Operations);
e.g., Network Management
Location, modifiability, re-usability, and availability of communications and networking services. Ensuring that the appropriate communications and networking services are developed and deployed within the system in an optimal manner.
Communications Engineering diagram
(Project Organization);
e.g., Sponsor, Program Manager
On-time, on-budget delivery of a change initiative that will realize expected benefits for the organization.
Requirements catalog
Principles catalog
Value Chain diagram
Solution Concept diagram
Functional Decomposition diagram
Application and User Location diagram
Line Management
(Project Organization);
e.g., Project Manager
Operationally achieving on-time, on-budget delivery of a change initiative with an agreed scope.
Application Communication diagram
Functional Decomposition diagram
Environments and Locations diagram
Business Process/Functional Expert
(Project Organization);
e.g., Financials FICO Functional Consultant, HR Functional Consultant
Adding more detail to the functional requirements of a change initiative based on experience and interaction with business domain experts in the end-user organization.
Process Flow diagram
Business Use-case diagram
Business Service/Information diagram
Functional Decomposition diagram
Application Communication diagram
Product Specialist
(Project Organization);
e.g., Portal Product Specialist
Specifying technology product designs in order to meet project requirements and comply with the Architecture Vision of the solution.
In a packages and packaged services environment, product expertise can be used to identify product capabilities that can be readily leveraged and can provide guidance on strategies for product customization.
Software Engineering diagram
Application/Data matrix
Technical Specialist
(Project Organization);
e.g., Application Architect
Specifying technology product designs in order to meet project requirements and comply with the Architecture Vision of the solution.
Software Engineering diagram
Platform Decomposition diagram
Process/Application Realization diagram
Application/Data matrix
Application Migration diagram
Regulatory Bodies
(Outside Services);
e.g., Financial Regulator, Industry Regulator
Receipt of the information they need in order to regulate the client organization, and ensuring that their information requirements are properly satisfied. Interested in reporting processes, and the data and applications used to provide regulatory return information.
Business Footprint diagram
Application Communication diagram
(Outside Services);
e.g., Alliance Partners, Key Suppliers
Ensuring that their information exchange requirements are met in order that agreed service contracts with the client organizations can be fulfilled.
Business Footprint diagram
Business Service/Information diagram
Application Communication diagram

Tuesday, February 21, 2012

Guidelines on Project Human Resource Management

Human resource management is a sequence of processes that allow planning, acquiring, developing and managing project team. The process of planning HR resources for project is the primary activity within HR management which results in creating a project human resource management plan. The given guidelines describe how to develop such a plan, what needs to be done to select, acquire and build the project team, and how to manage team activities.
Project human resource management plan definition:
A project human resource management plan is a formal statement of project roles, responsibilities, relationships, and skills which all together serve as a foundation for developing the staffing management plan. Project HR management plan is a document in which human resources with skills and abilities required for project success are determined and indentified. The plan is obtained as a result of successful implementation of the process for managing project human resources.
Project human resource management plan purpose:
The purpose of project HR management plan is to determine, identify and select human resources that have all necessary skills and abilities to undertake project activities on schedule, within budget and as per technical requirements.

Development of project HR management plan pursues the following major goals:
  • Select and acquire human resources that have all necessary skills and abilities required for project success
  • Develop team building strategies
  • Manage team activities
Considering the listed project HR management plan goals, the following major objectives can be identified:
  • Develop a list of necessary skills and abilities required for project success
  • Use the list to develop criteria for selecting human resources
  • Acquire selected human resources
  • Develop project team in which every member is assigned to appropriate role and responsibilities
  • Manage and control activities of project team
Human resource management plan structure
The structure of project human resource management plan includes the following elements:

  • Roles and responsibilities (including respective authorities and competencies) that describe what position, rights, activities, and skills each person should have to complete assignments and contribute to the project work progress.
  • Project organization charts that give a graphic representation of team members and their relationships with each other in the context of the project work.
  • Staffing management plan (including efforts schedules) that identifies human resource requirements and describes how and when these requirements are planned to be met. This document consists of the following items:
    • Staff acquisition statement that describes aspects of project HR planning.
    • Timeline that represents necessary time frames for team members to perform project activities.
    • Staff release plan that depicts ways for releasing team members from project and mitigates HR management risks.
    • Training that includes a training plan to develop skills and abilities of team members.
    • Recognition and rewards system that creates criteria for identifying how to promote and reinforce desired behavior.
    • Safety that includes policies and procedures to protect team members from safety hazards.
Human resource management process:
Implementation of the project human resource management process includes the following steps:
  1. Project Team Acquiring
  2. Project Team Developing
  3. Project Team Managing

The essentials of Project Quality Management

The knowledge area of project quality management includes the organizational

processes that determine quality policies, objectives, and responsibilities. The PMBOK identifies three processes for quality management: 

  • Quality Planning
  • Quality Assurance
  • Quality Control

Quality Planning
A good quality plan starts with a clear definition of the goal of the project. What is the product or deliverable supposed to accomplish? What does it look like? What is it supposed to do? How do you measure customer satisfaction? How do you determine whether or not the project was successful?
Answering these questions and others will help you identify and define quality goals, allowing you to discuss the approach and plans needed to achieve those goals. This includes assessing the risks to success, setting high standards, documenting everything, and defining the methods and tests to achieve, control, predict and verify success. Be sure to include quality management tasks in the project plan and delegate these tasks to work groups and/or individuals who will report and track quality metrics.
Quality Assurance
Quality assurance tests use a system of metrics to determine whether or not the quality plan is proceeding in an acceptable manner. By using both qualitative and quantitative metrics, you can effectively measure project quality with customer satisfaction. These tests or quality audits will help you predict and verify the achievement of goals and identify need for corrective actions. Additionally, quality assurance tests will help you map quality metrics to quality goals, allowing you to report on the status of quality at periodic project review meetings.
Quality Control
Quality control involves operational techniques meant to ensure quality standards. This includes identifying, analyzing, and correcting problems. While quality assurance occurs before a problem is identified, quality control is reactionary and occurs after a problem has been identified.
Quality control monitors specific project outputs and determines compliance with applicable standards. It also identifies project risk factors, their mitigation, and looks for ways to prevent and eliminate unsatisfactory performance.

The basic approach to quality management described in this section is intended to be compatible with that of the International Organization for Standardization (ISO). This generalized approach should also be compatible with proprietary approaches to quality management such as those recommended by Deming, Juran, Crosby and others, and non-proprietary approaches such as Total Quality Management (TQM), Six Sigma, Failure Mode and Effect Analysis, Design Reviews, Voice of the Customer, Cost of Quality (COQ), and Continuous Improvement.

Project Quality Management must address the management of the project and the product of the project. While Project Quality Management applies to all projects, regardless of the nature of their product, product quality measures and techniques are specific to the particular type of product produced by the project.

For example, quality management of software products entails different approaches and measures than nuclear power plants, while Project Quality Management approaches apply to both. In either case, failure to meet quality requirements in either dimension can have serious negative consequences for any or all of the project stakeholders. For example:

Meeting customer requirements by overworking the project team may produce negative consequences in the form of increased employee attrition, unfounded errors, or rework
Meeting project schedule objectives by rushing planned quality inspections  may produce negative consequences when errors go undetected.
Quality is “the degree to which a set of inherent characteristics fulfill requirements”. Stated and implied needs are the inputs to developing project requirements. A critical element of quality management in the project context is to turn stakeholder needs, wants, and expectations into requirements through Stakeholder Analysis, performed during Project Scope Management.
Customer satisfaction: Understanding, evaluating, defining, and managing expectations so that customer requirements are met. This requires a combination of conformance to requirements (the project must produce what it said it would produce) and fitness for use (the product or service must satisfy real needs).
Prevention over inspection: The cost of preventing mistakes is generally a lot less than the cost of correcting them, as revealed by inspection. It is said that the cost of a bug rises exponentially as the project reaches completion. Think of how much more a problem costs if it reaches the field and a new release has to be manufactured to fix it. This not only costs in the obvious dollars but also in the reputation of the firm delivering the product, especially in shops that run 24*7.
Management responsibility: Success requires the participation of all members of the team, but it remains the responsibility of management to provide the resources needed to succeed.
Continuous improvement: The plan-do-check-act cycle is the basis for quality improvement (as defined by Shewhart and modified by Deming, in the ASQ Handbook, pages 13–14, American Society for Quality, 1999). In addition, quality improvement initiatives undertaken by the performing organization, such as TQM and Six Sigma, can improve the quality of the project’s management as well as the quality of the project’s product. Process improvement models include Malcolm Baldrige, CMM®, and CMMISM.
The cost of quality refers to the total cost of all efforts related to quality.
Project decisions can impact operational costs of quality as a result of product returns, warranty claims, and recall campaigns. However, the temporary nature of the project means that investments in product quality improvement, especially defect prevention and appraisal, can often be borne by the acquiring organization, rather than the project, since the project may not last long enough to reap the rewards.
Cost-Benefit Analysis: Quality planning must consider cost-benefits tradeoffs. The primary benefit of meeting quality requirements is less rework, which means higher productivity, lower costs, and increased stakeholder satisfaction. The primary cost of meeting quality requirements is the expense associated with Project Quality Management activities.
Benchmarking involves comparing actual or planned project practices to those of other projects to generate ideas for improvement and to provide a basis by which to measure performance. These other projects can be within the performing organization or outside of it, and can be within the same or in another application area.
Design of Experiments:
Design of experiments (DOE) is a statistical method that helps identify which factors may influence specific variables of a product or process under development or in production. It also plays a role in the optimization of products or processes. Think of the scientific method.
An example is where an organization can use DOE to reduce the sensitivity of product performance to sources of variations caused by environmental or manufacturing differences. The most important aspect of this technique is that it provides a statistical framework for systematically changing all of the important factors, instead of changing the factors one at a time. The analysis of the experimental data should provide the optimal conditions for the product or process, highlighting the factors that influence the results, and revealing the presence of interactions and synergisms among the factors. For example, automotive designers use this technique to determine which combination of suspension and tires will produce the most desirable results in the time given.
Cost of Quality (COQ):
Quality costs are the total costs incurred by investment in preventing nonconformance to requirements, appraising the product or service for conformance to requirements, and failing to meet requirements (rework). Failure costs are often categorized into internal and external. Failure costs are also called cost of poor quality.
Additional Quality Planning Tools
Other quality planning tools are also often used to help better define the situation and help plan effective quality management activities. These include brainstorming, affinity diagrams, force field analysis, nominal group techniques, matrix diagrams, flowcharts, and prioritization matrices.

As you can see quality is a main component of customer satisfaction and to the bottom line. A bug found early can save a company millions of dollars!

Tuesday, February 14, 2012

Essence of Time Management in Project Management

Calculating Realistic Project Timelines by Mindtools

Have you ever been on a project where the deadline was way too tight? Chances are that tempers were frayed, sponsors were unhappy, and team members were working ridiculous hours.  Chances are, too, that this happened because someone underestimated the amount of work needed to complete the project.
People often underestimate the amount of time needed to implement projects, particularly when they're not familiar with the work that needs to be done.  For instance, they may not take into account unexpected events or urgent high priority work; and they may fail to allow for the full complexity of the job. Clearly, this is likely to have serious negative consequences further down the line. This is why it's important to estimate time accurately, if your project is to be successful. In this article, we look at a process for making good time estimates, and we explore some of the estimating methods that you can use

Why Estimate Time Accurately?

Accurate time estimation is a crucial skill in project management. Without it, you won't know how long your project will take, and you won't be able to get commitment from the people who need to sign it off.  Even more importantly for your career, sponsors often judge whether a project has succeeded or failed depending on whether it has been delivered on time and on budget. To have a chance of being successful as a project manager, you need to be able to negotiate sensible budgets and achievable deadlines.

How to Estimate Time Accurately

Use these steps to make accurate time estimates:

Step 1: Understand What's Required

Start by identifying all of the work that needs to be done within the project. Use tools such as Business Requirements Analysis, Work Breakdown Structures, Gap Analysis and Drill-Down to help you do this in sufficient detail.
As part of this, make sure that you allow time for meetings, reporting, communications, testing and other activities that are critical to the project's success. (You can find out more on these activities in our article on Project Management Phases and Processes.)

Step 2: Order These Activities

Now, list all of the activities you identified in the order in which they need to happen.
At this stage, you don't need to add in how long you think activities are going to take. However, you might want to note any important deadlines. For example, you might need to get work by the finance department finished before it starts work on "Year End."

Step 3: Decide Who You Need to Involve

You can do the estimates yourself, brainstorm them as a group, or ask others to contribute.
Where you can, get the help of the people who will actually do the work, as they are likely to have prior experience to draw upon. By involving them, they'll also take on greater ownership of the time estimates they come up with, and they'll work harder to meet them.
Tip: If you involve others, this is a good time to confirm your assumptions with them

Step 4: Make Your Estimates

You're now ready to make your estimates. We've outlined a variety of methods below to help you do this. Whichever methods you choose, bear these basic rules in mind:
  • To begin with, estimate the time needed for each task rather than for the project as a whole.
  • The level of detail you need to go into depends on the circumstances. For example, you may only need a rough outline of time estimates for future project phases, but you'll probably need detailed estimates for the phase ahead.
  • List all of the assumptions, exclusions and constraints that are relevant; and note any data sources that you rely on. This will help you when your estimates are questioned, and will also help you identify any risk areas if circumstances change.
  • Assume that your resources will only be productive for 80 percent of the time. Build in time for unexpected events such as sickness, supply problems, equipment failure, accidents and emergencies, problem solving, and meetings.
  • If some people are only working "part-time" on your project, bear in mind that they may lose time as they switch between their various roles.
  • Remember that people are often overly optimistic, and may significantly underestimate the amount of time that it will take for them to complete tasks.
The most reliable estimates are those that you have arranged to be challenged. This helps you identify any assumptions and biases that aren't valid. You can ask team members, other managers, or co-workers to challenge your time estimates.

Methods for Estimating Time

We'll now look at different approaches that you can use to estimate time. You'll probably find it most useful to use a mixture of these techniques.
  • Bottom-Up Estimating
  • Bottom-up estimating allows you to create an estimate for the project as a whole. To analyze from the "bottom up," break larger tasks down into detailed tasks, and then estimate the time needed to complete each one.
  • Because you're considering each task incrementally, your estimate of the time required for each task is likely to be more accurate. You can then add up the total amount of time needed to complete the plan.
Tip 1:
How much detail you go into depends on the situation. However, the more detail you go into, the more accurate you'll be. If you don't know how far to go, consider breaking work down into chunks that one person can complete in half a day, for example. Sure, this is a bit circular, but it gives you an idea of the level of detail you should aim for.
Tip 2:
Yes, this does take a lot of work, however, this work will pay off later in the project. Just make sure that you leave plenty of time for it in the project's Design Phase.

Top-Down Estimating
In top-down analysis, you develop an overview of the expected timeline first, using past projects or previous experience as a guide. It's often helpful to compare top-down estimates against your bottom-up estimates, to ensure accuracy.
Don't assume that the bottom-up estimates are wrong if they differ widely from the top-down ones. In fact, it's more likely that the reverse is true.

Instead, use the top-down estimates to challenge the validity of the bottom-up estimates, and to refine them as appropriate

Analogous (Comparative) Estimating: With comparative estimating, you look at the time it took to do similar tasks, on other projects.

Parametric Estimating:With this method, you estimate the time required for one deliverable; and then multiply it by the number of deliverables required.
For example, if you need to create pages for a website, you'd estimate how much time it would take to do one page, and you'd then multiply this time by the total number of pages to be produced.

Three-Point Estimating: To build in a cushion for uncertainty, you can do three estimates - one for the best case, another for the worst case, and a final one for the most likely case. Although this approach requires additional effort to create three separate estimates, it allows you to set more reasonable expectations, based on a more realistic estimate of outcomes.
In the early stages of project planning, you often won't know who will do each task - this can influence how long the task will take. For example, an experienced programmer should be able to develop a software module much more quickly than someone less experienced.
You can build this into your estimates by giving best, worst, and most likely estimates, stating the basis for each view.

Preparing Your Schedule

Once you've estimated the time needed for each task, you can prepare your project schedule. Add your estimates to the draft activity list that you produced in the second step, above.
You can then create a Gantt Chart to schedule activities and assign resources to your project; and to finalize milestones and deadlines.
Tip:If your project is complex, you might find that identifying the critical path on your plan is helpful. This will help you highlight the tasks that cannot be delayed if you're going to hit your deadline

Key Points

You need to estimate time accurately if you're going to deliver your project on time and on budget. Without this skill, you won't know how long your project will take, and you won't be able to get commitment from the people required to help you achieve your objective.
More than this, you risk agreeing to impossibly short deadlines, with all of the stress, pain, and loss of credibility associated with this.
To estimate time effectively, follow this four-step process:
  1. Understand what's required.
  2. Prioritize activities and tasks.
  3. Decide who you need to involve.
  4. Do your estimates.
Use a variety of estimating methods to get the most accurate time estimates

Tuesday, February 7, 2012

Scope Creep and How to avoid it?

Scope Creep: This happens when you think you know the impact of a change so you go ahead, but it turns out that that change leads to another one, and since you are already making the first change, you go with the next. Then another change comes up, and another, and another, until it’s hard to tell what the scope of the project is. What happens is the project scope keeps changing, which leads to unclear deliverables. This has the knock on effect of causing confusion and increased budgets as well as timeframes. Soon you end up with a project which never delivers, or which the Organization decides to scrap.

Scope Creep is a terrible thing. Basically it occurs when one or all of the following happens:

Causes of Scope Creep:

·      Poorly detailed Project Scope Statement in the Project Initiation Document (PID)
·      Poor Project Management Requirements have been delivered
·      Poor control of the Project by the Project Manager
·      Indecisive Project Stakeholders
·      Too many Project Stakeholders who have differing priorities and objectives

How to avoid Scope Creep?:
Each and every change needs to be evaluated in terms of impact. If there is any impact to the project constraints—time, cost, scope, quality, resources, or risk— need to go through change control, Ensuring that no-one has to make assumptions, and better still that nothing is ambiguous with regard to scope. The number one tip is “ never forgot what your project scope is. Everyone will continually try to get you to make seemingly "small" scope changes, which you should resist. After all if you give into one person's request, you create a precedent and before long a little change start snowballing and voila you have lost control of the project and potentially your project management career.

Ways to Avoid Scope Creep:
There are basically a number of ways scope creep can be managed. These include:
·    A) Rigid compliance with Project Management Process
·    B) A good rapport with Project Stakeholders
·    C) Active management of expectations
·    D) Good initial estimating and planning
The scope creep could be minimized by creating major awareness among the stake holders at the early stage of planning. Specially educating them the importance of setting the requirements & expectations, elaborated in detailed and having the consensus among the key stake holders, after several iterations of review and verification. It's better avoid proceeding to next level until the requirements are finalized and sign-off. Further should consider having effective change control mechanism, where all changers are channeled through change control board for review and approval, with submission of justification for change and the impact analysis report
Ways to avoid Scope Creep:

A) Write an Accurate Project Scope Statement: Undoubtedly the best thing you can do is ensure the Project Initiation Document contains an accurate Project Scope Statement. This may seem easy to do, but it is amazing how many project managers simply skim over this section without realising the problems this will cause later on. So get this statement right and fully approved by all Project Stakholders during project initiation and you are well on your way to ensuring scope creep doesn't happen.

B) Ensure Accurate Project Requirements are Documented and Approved: Now this one is a bit trickier as you are dependent on your team of Business Analysts's to make this happen. However what you can do is make sure all the project stakholders devote the time to reading and approving the requirements. In my experience this is usually the vital piece in the equation as usually Business Analysts have a fairly clear idea what they are doing. So concentrate on the Stakholders and let the Business Analysts get on with their job.
C)Strictly Enforce the Change Request Process: I've learned that no matter how much you insist the project has no contingency in terms of budget or timeframes, project stakeholders will always try to scope creep. However by forcing everyone to fill in, what is often an extremely onerous Change Request document, a significant portion of these will miraculously disappear. And for those which remain you simply have to impact assess them and then present your findings to the Programme Steering Board. I find by following this process I can get rid of 99% of scope creep, whilst keeping the Project Stakeholders happy.
Bottom Line: Accurate Requirements were not documented in the first place, and the project scope was not properly managed

Sudhakar Velaga MBA; PMP®