32722190

Project Procurement ManagementIn Practice

•JUDITH A. EDWARDS, PHD, PMP,DIEBOLD, INC.

Procurement practice is one of those things that organizationsand teams acknowledge is important up to a point—the pointof actually/»er/brming- the practice. The rationale for notimplementing the procurement practice is that it costs toomuch or takes too long. However, many failed procurementoutcomes have root cause in avoiding key elements in theprocess. The risk of not performing the process is seldomassessed when waivers or deviations occur. Yet many organiza-tions owe their successful outcomes to project procurementmanagement best practice.

Procurements should be a "project" and managed as such,even for small efforts. In this chapter, we will outline rolesand responsibilities for a procurement project team and offerbest practices, lessons learned, and methods of increasingopportunities for success derived from actual procurementexperiences.

PROCUREMENT PROCESS AND PROJECT

A variety of process standards and guides are available toorganizations, including IEEE Std 1062 from the software stan-dards collection,' Software Engineering Institute (SEI),^ andother sources.^ The overall process in those sources is verysimilar to that found in A Guide to the Project ManagementBody of Knowledge, Third Edition." Although the first two ref-erences indicate software procurement standards, those processdescriptions are essentially the same as any general procurement.

196

Charter procurement team

Project initiation

Plan approval milestone

B Prepare soiicitatlon

Type of procurement

Statement of work, specification, critena. and instnictions

Bidders lists

Supplier quaiifications

Reviews complete and approved

E) Select suppliers

Proposals received, anaiyzed. and reviewed

Selection prioritization

Negotiations

Best and final offers

Final selection and contract initiation

Project Management (or the continuing effort

Acceptance

Project closure

• Yes

FIGURE 15-1. PROCUREMENT PROJECT MANAGEMENT ACTIVITIES AND DURATION

This process evolved to solve many problems and issues with procurements in meetingthe desired business objectives. Standard procurement processes were developed to:

•Overcome or reduce instances of contract fraud abuses

•Reduce risk

•Describe the needed goods and services

•Monitore and control costs and performance

•Determine criteria for selection and acceptance.

Procurement efforts satisfy the definition of "project" as they seem to be unique withvarying complexity and timeframes. Usually, the procurement is embedded in a largerproject effort. Each effort should have a project manager in the role to assure theprocesses are completed and the team functions toward the desired objectives. Thisshould be the case regardless of short duration for simple tasks or commodity purchases,or long-term for significant outsourcing or new product development.

Figure 15-1 shows typical timelines for a moderate scoped procurement effort wherethe timescale represents periods after initiating the effort from the strategic planning.After the make-or-buy decision point, other strategic milestone reviews may indicate"go" or "no go" based upon the information obtained during the various project phasesor processes.

In the schedule representation for procurement effort, the project actually starts withinitiation and plarming to cover the preparation of solicitation documents, qualifyingsellers (if necessary), and performing the selection. The execution of the project includesthe monitoring and control of the seller while the seller executes the project. Co-devel-opment may be involved by the buyer organization. Acceptance of deliverables may occur

PROJECT PROCUREMENT MANAGEMENT IN PRACTICE 197

mm

Role

Project

manager

Buyer*

Legal

Technicalspecialist

or lead

Businessunit

manager

Steering

committee

tofiMflBg §s(MaM)(l3a3!0aiji@

Etesffiajtega ©Mag

Typical responsibility per phase

Receivesthe charter;integratesdirectionsinto projectplanning;reviews pastlessonsleamed

Reviewplanning

Participates

Reviewplanning

Strategicplan

Oversight

Procurementplanning;preparesstatementof work;approvesspecifications;submitssolicitationdocuments

Reviewer

Creates contractterms &conditions;defines end-itemdata rights

Preparestechnicalspecifications

Make-or-buydecisions

Oversight

Co-lead:technicalselectiontasks

Co-lead:businesstasks

Reviews;handlesnegotiations

Supportstechnicalissues andreviews

Reviewsandapprovals

Oversight

Project interfaceto stakeholders

Business andfinanceinterface

Reviews

Reviewsandsupportsacceptance

Receivesperfomnancestatus

Oversight

Monitorsproject;communicatesstatus

Monitors sellerperformanceand paymentmilestones

Issues reviews;changemanagement

Technicalstatus ofthe effort

May requirescopechanges

Oversight

Completesarchival forthe project;createslessonsleamed

Completesprocurementrecords andfiles

Contractclosure

Supportsarchivalefforts

Businessdeployment

Oversight

'Notes:

• Typically the buyer role is from the procurement or purchasing organization.

• Outsourcing roles adds risk to be managed in addition to procurement risks.

• Other oversight may be needed to assure accountability of all participants to guard against fraud ormismanagement.

TABLE 15-1. RESPONSIBILITY ASSIGNMENT MATRIX (RAM)

at varying points depending on the contract agreements. The final closure includes the clo-sure of the effort as well as the contract. The project effort depends on a variety of knowl-edge worker experiences that are outlined in the roles/ responsibility description below.

ROLES/ RESPONSIBILITIES

Typically, no one person will have the entire set of skills for completing the entire set oftasks for legal, technical skills, business, purchasing, and project management. Therefore,forming a team with members from various disciplines will be beneficial to providechecks and balances in the procurement project processes. The further justification for the

198 THE AMA HANDBOOK OF PROJECT MANAGEMENT, SECOND EDITION

procurement becoming a project lies in this variety of teaming relationships, set of stake-holders, and unique business needs situations. This coordination ofthe procurement willneed an assigned project manager who understands the business and technical needs.

In Table 15-1, the Responsibility Assignment Matrix (RAM) shows the complexityof activities and roles involved for a typical, medium-sized organization. Note that in theRAM, the following situations may occur for the project:

•One person may hold more than one role.

•Some roles may be outsourced.

•Role tasks may be delegated.

•Other stakeholders will be involved as procurement situations and issues arise duringthe executing or monitoring and control phases.

The project RAM should be updated as changes occur during phase transitions. Somephases will require more experienced knowledge workers who are tasked to integrateand deploy the procured items.

Contention in roles and responsibilities will be reduced when organization processesand procedures address how the team is formed, functional requirements for the roles, andthe processes to be performed. The organization standard practices should also include:

•Managing the acceptable sellers

•Qualifying new, potential sellers

•Defming the selection process

•Deriving the criteria based on type of purchase

•Controlling scope changes

•Reporting for oversight, defined for the project, approvals, and processes.

SELECTION OF THE PROCUREMENT PROJECT MANAGEMENT TEAM

As you initiate the project, thought must be given to the make-up and training for theteam members. The following list contains some of the factors in the selection:

•Members who interface with the seller should be "peers" to gain the confidence andset the working relations.

•Task leads will need project management as well as negotiating skills.

•Responsibility and methods for accepting the product or services need to be clearlydefined; for example, defined in a joint RAM for the seller and the buying organization.

•The size ofthe team will be dictated by the business and technology factors, and thecomplexity and risk for procurement

• Stakeholders involvement need to be identified in the project planning.

•other stakeholders' considerations may be needed for procurement project. They mayinclude: project management office, line management, managers with dependencies on theprocurement outcome, quality organization, business units, other services, and manufacturing.


Lessons learned and best practices organized by project management area or phase

Process

Contract types

Initiating

Seller selection

Planning

Risk management

Training

Projectmanagement

• Risks increase by avoiding steps in the process. The standard process evolved toavoid risks or correct a failure or issue.

• Incomplete steps in procurement may add costs and time later.

• For a trained knowledge worker, the effort to follow the process is not excessive.

• Organizational tools and standard templates aid the preparation of thesolicitation documents and reinforce training on procurement processes.

• Large organizations with supply chain management will require interfaceprocesses based on purchase type, seller category, qualifications, and informationautomation access.

• Cost control begins with the specifications and seller quaiification processes.

• Ownership rights for end-dellverables must be clearly specified.

• Commercial-off-the-shelf purchases are often called COTS, if these areinappropriate or not planned, then the purchase might better be called COSTS.

• The team should review lessons learned on earlier procurement efforts duringinitial planning phases.

• Risks should be identified and managed.

• Time spent in qualifying sellers often means better working relationships and lessrisk.

• It is not practical to expect the seller's systems to duplicate the buyingorganization. Where common processes or infrastructure is important, thendefine the needed capability in the work statements.

• The low-cost bidder may be the highest risk.• Reference checking is a good way to leam others' experiences in dealing

with candidate sellers.

• Procurement needs to be managed to assure the products meet the specificationsand work statements.

• Plans need to address risk management.

• Payment milestones assure the buyer is getting specified deiiverables whilereducing risks. The payment criteria should be defined in the work statements.

• Risks must be managed regardless of the seller size and experience.

• Often procurement processes are so rarely exercised that refresher training isnecessary to assure compiiance to the organization practices.

• Detailed specifications and work statements reduce the potential future claims forscope changes.

• Outsourcing should be a project supported by a project manager and a plan.

• Recuning, commodity purchases may still need technical acceptance and changemanagement.

TABLE 15-2. LESSONS LEARNED AND BEST PRACTICES ORGANIZED BY PROJECT MANAGEMENTAREA OR PHASE


Lessons learned and best practices organized by project management area or phase

Businessmanagementstrategy

Roles andresponsibilities

Executing

Changemanagement

Seller risks

Closing

• Interfaces to the seller must be controlled by the buyer and project manager toprevent unauthorized scope changes.

• Project manager for the procurement project should be a peer of the seller's teamso as to effectively manage the effort.

• Problems occur if the seller becomes the primary project management interface tothe end customer.

• "Buy" objectives may have littie to do with in house capability. The technicai teamneeds to understand the roles and relationships and strategy

• "Should cost" needs to be detennined for the life cycle and total cost of ownership,not just the cost of the delivered items or services.

• Outsourcing does not necessarily save staff, time, or costs. The organizationobjective should support strategic business needs.

• Outsourcing should not be a "me too" decision,

• It is unlikely that a procurement will succeed without a project team.

• Technical team needs to perform the acceptance and validation of the delivereditems that are defined in the planning.

• Often companies assume that the purchasing organization is responsible for theentire process. The development organization then fails to understand their role inthe upfront planning. This results in key elements of the process being missed.

• Regardless of past experiences with a seller, procurements are not risk free.

• Sellers may need additional support since they may not understand the domainwhere their products or services will be used.

• It is good for the seller to "hear and see" the voice of end customer to understandtheir needs and to assure that the outcome wiil be successful.

• If the specification needs to be changed to eliminate unneeded features or tasksor to assure success of project, then is must be done. Obtaining the wrongsystem will be most likely lead to sunk costs or major rework.

• Dealing with financially troubled organizations is a major risk to seller cash fiow.

• Incun-ing added seller efforts for micro management by large organizations willincrease claims and non productive work.

• Canceling projects can be very costly

• Not canceling projects can also be very costly

• Terms and conditions of the contract shouid clearly define the termination processand the payment methods involved.

TABLE 15-2. CONTINUED


As the team is formed, the next section provides some experiences, lessons learned, and bestpractices from a variety of procurements.

PROCUREMENT LESSONS LEARNED AND BEST PRACTICES

Drawing from experience in a variety of procurement projects including long duration,expensive efforts to relatively simple commodity purchases for both defense, and com-mercial projects, Table 15-2 organizes lessons learned and best practices by knowledgearea or project management phase. These suggestions based on experience in the field donot repeat but amplify recommendations or practices described in the PMBOK^ Guide.

Some table items were adopted from a major support software procurement for adefense project.' The software project procurement practices are not different from pro-curement process in general. The next section suggests methods for obtaining successfuloutcomes.

INCREASING OPPORTUNITIES FOR SUCCESS

Procurement involves risks. Some techniques have been shown to be success enablers.Here are some recommended methods for "getting it right the first time":

•Hold early "bidders" conference to obtain feedback on the statement of work and speci-fications. These can be held by teleconference. It is essential that all potential sellers hearthe same message. Seller comments need to be managed for non-disclosure of competi-tion sensitive information. From the feedback, hold a follow-up conference to show theupdated documents. This also helps the sellers to determine their response strategy.

•Obtain a "should cost" during the make-or-buy decision period to gage the sellerresponses more accurately. Underbids by significant amounts will need believable justifi-cation for how the effort can be managed to cost without defaulting.

• D o not rush through the procurement process steps only to find that the best opportunitiesfor seller selection were missed or the specifications are incomplete, requiring new bids.

•Competitive bidding is considered a risk reduction method that avoids locked-in solu-tions or favoritism. If the procurement process is performed well, then the procurementeffort should yield the best outcome for the buyer.

•Determine how to impose on the seller reasonable quality standards for the end prod-uct or service. The end result cannot be better than the weakest quality component.

•Form integrated product development teams as part of the project team and stakeholders.

•Assure that the team is adequately trained on procurement processes. Provide refreshertraining for those with immediate need.

•Update organization practices with lessons learned and best practices.

•Define the responsibility and accountability for the team. Retain visibility into theproject procurement practices and results. Audit the project for adherence to the practiceand the project work statement and specifications.

•Reduce risks by using the two-person (or more) rule to assure oversight and that eval-uations are fair.


•Require justifications for sole-source purchases to avoid buying in haste and repentinglater. Cost/benefit analysis should be part of each decision process step.

•Exercise strict change control on both sides of the buyer/seller relationship.

Thoroughly understanding the procurement process and practicing project manage-ment tenets aids efficiencies for the organization in getting products and services to mar-ket. Next, let's examine some considerations in applying lessons learned to several dif-ferent sizes, or classes, of procurements.

SCENARIOS BASED ON "CLASS" OF PROCUREMENT

Three scenarios summarize procurement considerations based upon size or "class" ofprocurement. The guidance is given to increase the probability of successful outcomes,avoid defaults, and reduce sunk costs.

Scenario 1. Existing Items From Catalogs or Commercial-Off-the-Shelf

In buying existing items, some requirements specification or criteria need to be definedfor their selection. Ofren much time and money is wasted when the purchased itembecomes "shelf ware" because the desired capability was never defined. The definitionneeds to be more than either someone saw a demonstration or the competition uses it.The goal is to satisfy a business need.

The purchased items should be evaluated against the requirements. When deficiencies arefound, an estimate is needed to detemiine the total cost to integrate the items into the end prod-uct. Often a slightly more expensive item would save integration and troubleshooting efforts.

Experience or training is also needed to assess purchased items' quality. Volume pur-chase requires higher levels of specification for reducing rework or recalls. The selectionof an existing item will be dependent on the degree of risk the organization wants toassume. The result may end up with throwaway items and unnecessary costs for efforts.Key to the approach is investing in upfront feasibility or prototyping.

Scenario 2. Minimum Modifications to Existing Selier Items

An existing item may not completely meet the business needs unless it is modified. The pro-curement strategy may be to hire a seller to update their product to meet the specification.

Here, the solicitation documents need to clearly describe the responsibilities betweenthe buyer and seller for the integrated solution and its support. If both organizations workon the item, then the responsibility is not clear, nor can it easily be determined how tomaintain the item. Defined separation of responsibilify and efforts is a good managementapproach. It is also important to focus domain knowledge on areas of expertise. The sell-er may be an expert in their technology but not in the business application where theirproducts will be deployed. The buyer can provide the needed interface for the domain.

Strict management of product development interfaces aids in isolating difficulties andsolutions. Decomposition allows better estimating of costs and integration efforts.Managing to clearly defined interfaces simplifies the tasks. It is difficult to have totalsystem knowledge of complex systems. By partitioning the effort along defined decom-position and interfaces, the buyer/seller teams only need to know their functionality andthe interface requirements. The next scenario considers allocating the entire componentto the seller for development.


Scenario 3. Major New Development

In this instance, the buyer is procuring totally new technology or unique solutions. Thesize of the effort may be small, but very critical as for some autonomous or embeddedsystems. The buying organization may be dealing with what Moore called Crossing theChasm'' to plan and manage the delivered items from feasibility or research develop-ments through integration to a stable environment. Specification practices may need togo through a variety of stages for preliminary to fmal versions. For risk reduction,"go/no go" decision can be made based on performance at each stage. At some point, thebuyer can even require a proposal for the subsequent stage. If performance is poor orobjective not met, then the effort can be re-competed.

In this scenario, the procurement goal is typically to transform a unique feature or capa-bility into a stable product. A high degree of new technology or special implementationsincurs more risk. The procurement strategy should involve a phased approach to prove vari-ous incremental deliveries. In a phased approach, stage the effort of development from min-imum required functionality in pre-production to several increased capability solutions. Keyparts of the procurement project involve planning, risk management, monitoring and con-trol, integrated change management, quality control acceptance, and communications.

The three scenarios cover aspects of project procurement management. The follow-ing summary section reviews the basic processes covered in this chapter and is supportedby exercises at the end.

CONCLUSiON

The project procurement process knowledge area has had significance to business andindustry over the years. Since trends indicate that outsourcing and other procurementswill continue in the future, project managers should master the project procurementprocesses. A project effort usually begins after the make-or-buy decision from the strate-gic business planning. At several checkpoints, the decision can be made to go forwardwith the procurement to the next phase. The project procurement process steps are listedas follows:

1. Plan the purchase and acquisition.2. Plan the contracting.3. Request seller responses.4. Select sellers.5. Perform contract administration.6. Perform contract closure.

Supporting project processes include: the overall project planning, monitoring andcontrol, stakeholder communications, and integrated change management.

The effort should be established as a two-phase project to cover (1) the activitiesthrough seller selection and (2) managing the sellers through project and contract closure.

Important aspects of this knowledge area's processes include:

•Documentation, including plans, work statements, specifications, and acceptance criteria

•Project management performed at both the buyer and seller

• Skills training covering procurement processes, negotiations, assessment of capabili-ties, and performance

204 THE AMA HANDBOOK OF PROJECT MANAGEMENT SECOND EDITION

•Defined roles and responsibilities defined throughout the procurement project.

"Classes" of procurement may range from commodities, to commercial-off-the-shelf(COTS), to minor modifications to existing products, to special services, to unique/cus-tomized developments. Different controls and risk management are needed for each class.

DISCUSSION QUESTIONS

O You are planning to buy new technology (choose an area) for a product orservice. Use reference materials and the Internet to determine a beginningsupplier list to answer the following:

•What should go into the make-or-buy analysis?

•What are your seller selection criteria?

•Using cost benefit analysis, what are the pros and cons of sole sourceprocurement versus competitive selection?

© Create a risk register for the following classes of procurement:

•Very small effort, new seller.

•Very large effort, major company as seller.

•Company with financial difficulties or history of downsizing.

® In perfonning due diligence at the candidate sellers, what are the questionsor areas that you would want to ask before entering into a business relationship?What project methods would be used to monitor and control the seller'seffort?

REFERENCES

' IEEE Standard 1062 Recommended Practice for Software Acquisition. New York: Institute of Electrical andElectronics Engineering, Inc.

^ Chrissis, M.B., M. Konrad, and S. Shrum. CMMI Guidelines for process Integration and ProductImprovement. Boston: Addison Wesley, 2003.

' Mitulski, F.A. Managing Your Vendor. New Jersey: Prentice-Hall ECS Professional, 1993.

•* Project Management Institute. A Guide to the Project Management Body of Knowledge, Third Edition. PMI:Newtown Sqare, PA, 2004.

' Edwards, J.A., and B.L. Mowday. "How to buy a compiler." WADAS: Washington Ada Symposium 1984(March 1984) - 1994 (July 1994), New York: Association for Computing Machinery (ACM), Symposium,March 1984-1994.

' Moore, GA. Crossing the Chasm. New York: Harper Business; Revised edition, 2002.


32722190

Documents