CHAPTER 15
Project Procurement Management in Practice

JUDITH A. EDWARDS, PHD, PMP, IEEE, SM; CONSULTANT

Procurement practice is one of those things that organizations and teams acknowledge is important up to a point—the point of actually performing the practice. The rationale for not implementing the procurement practice is that it costs too much or takes too long. However, many failed procurement outcomes have root cause in avoiding key elements in the process. The risk of not performing the process is seldom assessed when waivers or deviations occur. Yet many organizations owe their successful outcomes to project procurement management best practice.

Procurements should be a “project” and managed as such, even for small efforts. This chapter outlines roles and responsibilities for a procurement project team and offers best practices, lessons learned, and methods of increasing opportunities for success derived from actual procurement experiences.

PROCUREMENT PROCESS AND PROJECT

A variety of process standards and guides are available to organizations, including IEEE Std 1062 from the software standards collection,1 Software Engineering Institute (SEI),2 and other sources.3, 4 The overall process in those sources is very similar to that found in A Guide to the Project Management Body of Knowledge, Fourth Edition.5 Although the first two references indicate software procurement standards, those process descriptions are essentially the same as any general procurement. This process evolved to solve many problems and issues with procurements in meeting the 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.

• Monitor and control costs and performance.

• Determine criteria for selection and acceptance.

Keeping these objectives in mind, it is logical that in the PMBOK Guide, Fourth Edition, the procurement chapter was simplified from six processes to four; after all, the process of obtaining inputs to a project needs to be as streamlined as possible. The new standard reflects a less bureaucratic procurement process and a more streamlined supply chain, in part because of technological advancements. It also recognizes the increasing role played by partnering arrangements, including new items on handling “teaming agreements” in planning and conducting procurement.

Procurement efforts satisfy the definition of “project” as they seem to be specific, with varying complexity and timeframes. Usually, the procurement is embedded in a larger project effort. Each effort should have a project manager in the role to assure the processes are completed and the team functions toward the desired objectives. This should 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 where the 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 phases or processes.

Image

FIGURE 15-1. PROCUREMENT PROJECT MANAGEMENT ACTIVITIES AND DURATION

In the schedule representation for procurement effort, the project actually starts with initiation and planning to cover the preparation of solicitation documents, qualifying sellers (if necessary), and performing the selection. The execution of the project includes the monitoring and control of the seller while the seller executes the project. A procurement could involve codevelopments with others and the buyer organization. Acceptance of deliverables may occur at varying points depending on the contract agreements. The final closure includes the closure of the effort as well as the contract. The project effort depends on a variety of knowledge worker experiences that are outlined in the roles/responsibility description below.

ROLES/RESPONSIBILITIES

Typically, no one person has the entire set of skills for completing the entire set of tasks for legal, technical skills, business, purchasing, and project management. Therefore, forming a team with members from various disciplines will be beneficial to provide checks and balances in the procurement project processes. The further justification for the procurement becoming a project lies in this variety of teaming relationships, set of stakeholders, and unique business needs situations. This coordination of the procurement will need an assigned project manager who understands the business and technical needs.

In Table 15-1, the Responsibility Assignment Matrix (RAM) shows the complexity of activities and roles involved for a typical, medium-sized organization. Note that in the RAM, 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 during the executing or monitoring and control phases.

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

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

• Managing the acceptable sellers.

• Qualifying new, potential sellers.

• Defining 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 the team 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 and set the working relations.

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

Image

TABLE 15-1. RESPONSIBILITY ASSIGNMENT MATRIX (RAM)

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

• The size of the team will be dictated by the business and technology factors, as well as by the complexity and risk for procurement

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

Other stakeholders’ considerations may be needed for procurement project. They may include project management office, line management, managers with dependencies on the procurement outcome, quality organization, business units, other services, and manufacturing. As the team is formed, the next section provides some experiences, lessons learned, and best practices 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 commercial projects, Table 15-2 organizes lessons learned and best practices by knowledge area or project management phase. These suggestions, based on experience in the field, do not repeat but amplify recommendations or practices described in the PMBOK® Guide.

Some table items were adopted from a major support software procurement for a defense project.6 The software project procurement practices are not different from procurement process in general. The next section suggests methods for obtaining successful outcomes.

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”:

imageHold early “bidders” conference to obtain feedback on the statement of work and specifications. These can be held by teleconference. It is essential that all potential sellers hear the same message. Seller comments need to be managed for nondisclosure of competition sensitive information. From the feedback, hold a follow-up conference to show the updated documents. This also helps the sellers to determine their response strategy.

imageObtain a “should cost” during the make-or-buy decision period to gage the seller responses more accurately. Underbids by significant amounts will need believable justification for how the effort can be managed to cost without defaulting.

imageDo not rush through the procurement process steps only to find that the best opportunities for seller selection were missed or the specifications are incomplete, requiring new bids.

imageCompetitive bidding is considered a risk reduction method that avoids locked-in solutions or favoritism. If the procurement process is performed well, then the procurement effort should yield the best outcome for the buyer.

imageDetermine how to impose on the seller reasonable quality standards for the end product or service. The end result cannot be better than the weakest quality component.

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

imageAssure that the team is adequately trained on procurement processes. Provide refresher training for those with immediate need.

imageUpdate organization practices with lessons learned and best practices.

imageDefine the responsibility and accountability for the team. Retain visibility into the project procurement practices and results. Audit the project for adherence to the practice and the project work statement and specifications.

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

Project management area or phase

Lesson learned or best practices

Process

• Risks increase by avoiding steps in the process. The standard process evolved to avoid 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 the solicitation documents and reinforce training on procurement processes.

Contract types

• Large organizations with supply chain management will require interface processes based on purchase type, seller category, qualifications, and information automation access.

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

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

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

Initiating

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

• Risks should be identified and managed.

Seller selection

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

• It is not practical to expect the seller’s systems to duplicate the buying organization. Where common processes or infrastructure is important, then define the needed capability in the work statements.

• The low-cost bidder may be the highest risk.

• Reference checking is a good way to learn others’ experiences in dealing with candidate sellers.

Planning

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

• Plans need to address risk management.

Risk management

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

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

Training

• Often procurement processes are so rarely exercised that refresher training is necessary to assure compliance to the organization practices.

Project management

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

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

• Recurring, commodity purchases may still need technical acceptance and change management.

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

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

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

Business management strategy

• “Buy” objectives may have little to do with buyer core capability. The technical team needs to understand the roles and relationships and strategy.

• “Should cost” needs to be determined 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 organization objective should support strategic business needs.

• Outsourcing should not be a “me too” decision because it appears cheaper than in country; some end strategy must be considered.

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

Roles and responsibilities

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

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

Executing

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

• Sellers may need additional support since they may not understand the end-user or the domain where their products or services will be used.

• It is good for the seller to “hear and see” the voice of end customer to understand their needs and to assure that the outcome will be successful.

Change management

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

Seller risks

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

• Incurring added seller efforts for micro management by large organizations will increase claims and non productive work.

Closing

• Canceling projects can be very costly.

• Not canceling projects can also be very costly.

• Terms and conditions of the contract should clearly define the termination process and the payment methods involved.

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

imageReduce risks by using the two-person (or more) rule to assure oversight and that evaluations are fair.

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

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

Thoroughly understanding the procurement process and practicing project management tenets aids efficiencies for the organization in getting products and services to market. Next, let’s examine some considerations in applying lessons learned to several different sizes, or classes, of procurements.

SCENARIOS BASED ON “CLASS” OF PROCUREMENT

Four scenarios summarize procurement considerations based upon size or “class” of procurement. 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 defined for their selection. Often much time and money is wasted when the purchased item becomes “shelf ware” because the desired capability was never defined. The definition needs 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 are found, an estimate is needed to determine the total cost to integrate the items into the end product. Often a slightly more expensive item would save integration and troubleshooting efforts.

Experience or training is also needed to assess purchased items’ quality. Volume purchase requires higher levels of specification for reducing rework or recalls. The selection of an existing item will be dependent on the degree of risk the organization wants to assume. 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 Seller Items

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

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

Strict management of product development interfaces aids in isolating difficulties and solutions. Decomposition allows better estimating of costs and integration efforts.

Managing to clearly defined interfaces simplifies the tasks. It is difficult to have total system knowledge of complex systems. By partitioning the effort along defined decomposition and interfaces, the buyer/seller teams only need to know their functionality and the interface requirements. The next scenario considers allocating the entire component to the seller for development.

Scenario 3. Major New Development

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

In this scenario, the procurement goal is typically to transform a unique feature or capability into a stable product. A high degree of new technology or special implementations incurs more risk. The procurement strategy should involve a phased approach to prove various incremental deliveries. In a phased approach, stage the effort of development from minimum required functionality in pre-production to several increased capability solutions. Key parts of the procurement project involve planning, risk management, monitoring and control, integrated change management, quality control acceptance, and communications.

Scenario 4. Offshoring or outsourcing

Companies are tempted to outsouce by sending major development ‘offshore’ without enough risk analysis or management support planning. Core competencies are lost and difficult to recover.7 The number of unsuccessful projects are immense. What looks like a cost advantage is soon sacrificed to lack of project management. A ‘me too’ is not enough motivation for sending development out-of-country. Rationale for more successful outcomes include the amount of business the offshore will support in country. It is easy to lose branding and commonality if the entire development is sent offshore. Following are some considerations to include in the plan:

• The management approach.

• Communications and travel.

• Standards should be established.

• Product acceptance and quality controls.

• Additional procurements may be required.

• Tracking and metrics established.

• Cost reporting and containment.

• Customer satisfaction.

It would be advisable for all parties to see the project plan, create their own plan with approval. Before the project is initiated, significant organizational portfolio analysis and core competency review for strategic advantages and disadvantages. Near term gains will not sustain long term losses.

The four scenarios cover aspects of project procurement management. The following summary section reviews the basic processes covered in this chapter and is supported by exercises at the end.

CONCLUSION

The project procurement process knowledge area has had significance to business and industry over the years. Since trends indicate that outsourcing and other procurements will continue in the future, project managers should master the project procurement processes. A project effort usually begins after the make-or-buy decision from the strategic business planning. At several checkpoints, the decision can be made to go forward with the procurement to the next phase. The project procurement process steps are listed as 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 and control, stakeholder communications, and integrated change management.

The effort should be established as a two-phase project to cover (1) the activities through 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 capabilities, and performance

• 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/customized developments. Different controls and risk management are needed for each class.

REFERENCES

1 IEEE Standard 1062 Recommended Practice for Software Acquisition. New York: Institute of Electrical and Electronics Engineering, Inc.

2 Chrissis, M.B., M. Konrad, and S. Shrum. CMMI Guidelines for process Integration and Product Improvement. Boston: Addison Wesley, 2003.

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

4 Fleming, Q. W. Project Procurement Management, FMC Press, 2003.

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

6 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.

7 Moore, G.A. Crossing the Chasm. New York: Harper Business; Revised edition, 2002.

7 Lacity, M. C. and R. Hirschheim. Outsourcing, John Wiley & Sons, 1993.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset