Total collaborative procurement


Robin Hornby, PMP

Director, Tempest Management, Inc.

A rational, collaborative procurement process, in which buyer and seller work together to optimize the results for both parties, is the goal of this paper. Currently, buyers and sellers operate as silos, creating communication tangles and misunderstandings, unnecessary complexity, and, sometimes, causing project failures. Trust is difficult to build and can eventually dissolve, leading to a negative and non-productive project environment. The author's premise is that a new foundation must be laid—a collaborative methodology. The requirements and architecture for such a methodology are described and an overview of six key embedded practices is presented. Large project owners and vendor firms may implement these practices today, as point solutions. Longer term, a vision is outlined of a consortium of committed buyers and sellers needed to bring about a true joint, integrated, subscription-based methodology.

Some of the material for this paper is summarized with permission from the book, Projects for Profit, published by TMI.


No wonder things go wrong with contracted projects! Marketplace free-for-all, regulatory and procurement policy constraints, zero sum contracting terms, arm's length stakeholders, hidden communication channels, project delivery under commercial pressures, as well as the usual quota of technical and project management issues all serve to create a complex environment for most projects. There must be a better way.

Increasingly, projects (and project management services) are being delivered as part of a commercial arrangement between a buyer and a seller. The boom in outsourcing as a business model over the past 20 years is one clear demonstration of that fact. Unfortunately, there is no accepted framework that supports a collaborative approach through all phases of project proposal and delivery, and that is the purpose of this paper.

Note 1: I use the terms client and vendor interchangeably with the terms buyer and seller found in A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – Fifth Edition (Project Management Institute, 2013).

Note 2: Content is summarized with permission from the reference, Projects for Profit (Hornby, 2013).


Before examining such a business-level methodology and the embedded practices, I can suggest some other factors—skills, trust, and expanded project management—that are part of the procurement and delivery context.


The first is the skill of the project manager. The need for knowledge of standard processes such as the PMBOK® Guide is widely recognized. A less obvious issue is the need for business and organizational knowledge, and for business delegation to be granted to project managers. This signals the need for a training model that equips project managers with skills for the commercial and client environments they will be working in as they move into professional services.


Most observers rightly identify trust as the crucial ingredient for building commercial relationships. We can also learn from failure, about causes specific to the commercial environment that often point to less than open relationships. So trust and open relationships are, evidently, significant parts of the solution, but they are always conditional and in some ways, they are like the icing on the cake. This means that there must be a cake to put the icing on. That can only be a methodology subscribed to by both buyer and seller, to jointly guide these stakeholders from solicitation through to completion.

Expanded Project Management

The third factor, I label “Expanded Project Management.” The scope of project management migrates into the operational side of the business. The vendor whose business success is based entirely on project success must clearly build this PM “expansion” into their business model and their practices. Project risk, quality management, and project status are just three examples. Similar logic applies to the client. If their procurement process is based on unfounded budgets, ignorance of risk and estimating disciplines, and ambiguity on quality, then they are flirting with disappointment, or worse.

The Case for Methodology

Without formalization, just like standard project management, the attempts to improve the record of project contracting will be sporadic, temporary, and based on heroic measures by rare combinations of exceptional people.

The proposition is that the major benefits of collaborative procurement can only be achieved by a more thorough formalization—a new methodology. This formalization deserves a name, and as a working title, I suggest, Total Collaborative Procurement (TCP). Using the qualifier “Total,” reminds us that successful procurement is much more than just getting a qualified vendor selected for the project. Success demands that we include the entire delivery cycle. The client must forget about the idea that all risk and problems are delegated to the vendor. Projects are always a joint endeavour. The following (Exhibit 1) summarizes the requirements of a TCP methodology.


Exhibit 1: The requirements for a TCP methodology.


The architecture (Exhibit 2) is layered. Three layers are envisaged: (1) the business layer, (2) the project management layer, and (3) the work layer. It is important to understand that the primary context for the TCP is business, even though I borrow from the language and techniques of project management. Client procurement is, primarily, a business operation and vendor delivery is the fundamental business of the firm (and must generate profit).


Exhibit 2: The TCP architecture showing a contract for all phases.

The business level consists of five phases, as yet unnamed. The project management level shows the four functions operating as a cycle, and absolutely not as sequential phases. The work level is exampled as the simplest of waterfall application life cycles. An essential point of the model is that, for all important aspects, the project is supervised by the business level practices of the execute/control phase of the TCP cycle. This is extremely important to understand. For example, the diagram illustrates a “big bang” approach to the project—all phases are included under the umbrella of a TCP execute/control phase 4 in one pass of the TCP. If the rolling wave approach is more applicable, I would draw this diagram with, for example, only the Requirements and Design work included. A second cycle would then contract for the Build and Implement work.

Attributes of the TCP Methodology

The TCP Life Cycle Phases

Creating a jointly managed TCP life cycle is the biggest challenge. It will engage multiple organizations, some in competition in the first two phases, and is, perhaps, too complex to model in IPO (Input-Process-Output) format. I think we must accept a higher level of abstraction as being more workable, and so, I talk in terms of practices within the phases. The phases that result from the integration of the client and vendor viewpoints should be considered as business-focused, and they actually provide a wrapper for the application life cycle, as the architecture illustrates.

Although most components of the TCP are required to be customizable, the phases of the TCP life cycle should not be customizable as they are the rock upon which TCP is built.

Project Integration

If it doesn't integrate the client and the vendor and their project deliverables, then the TCP is a failure. Integration and joint operations are its purpose. Thus, the early phases of TCP must give instructions on how to integrate the planning, organizing, controlling, and leadership functions of project management with the phases of the application life cycle. It must map all vendor, client, team, and project management deliverables. This is designated as an essential practice, so both parties mutually understand exactly what the planned project will look like and how they will work together.

Other Required Design Features

These additional design features (Exhibit 3) of the collaborative TCP methodology will also be required:


Exhibit 3: Other required design features for the TCP.


There are challenges, naturally, which must be met with prerequisites. Both parties must be prepared to adopt a mutual approach to the project. Silo mentalities will militate against success. There will be joint documents produced. Not just prepared by one party and approved by the other, but worked out together in joint working sessions. In the process of working together, information must be shared openly, and both parties must be totally comfortable to permit that.

Overview of TCP Practices

This section describes the six key practices currently identified and assessed as significantly contributing to successful collaborations.

1. Life Cycle Mapping—The Revival of the Application Life Cycle

Focus on the application life cycle has been lost in recent years. Life cycles, the most important control technique of project management, are designed for the accomplishment of work in a specific application area—construction, electronics, pharmaceuticals, software, and so forth. Inevitably, the client and the vendor will have different views of the life cycle for the work to be done, and a different view of the project management to be applied. These facts create conditions for miscommunication and misunderstanding.

The solution is to recognize the essential role of the life cycle as the backbone of project integration. It will integrate project management explicitly into the work of the project, show the management activity supplied by both client and vendor, and map their management deliverables into the same phases of work as project deliverables. This is probably the most valuable of the six practices that can be applied.

To make this work, it is best to think of commercial project management as a series of functions that are applied repetitively during each phase of the life cycle. Indeed, they are applied repetitively each hour of every day! These functions are planning, organizing, controlling, and leading (POCL). This model (Exhibit 4) enables mapping and allocation of client and vendor responsibilities.


Exhibit 4: Life cycle mapping for collaborative project planning.

2. Accountabilities Definition—Bringing Clarity to Accountability

During project reviews or recoveries, I have observed that lack of clarity in stakeholder/team accountabilities is a leading cause of failure. A willingness by both parties to define accountabilities during the planning phase will avoid grief later in the project. I recommend the use of three techniques: structure charts, the RAA (responsibility, accountability, and authority) model, and RAM (responsibility assignment matrix) charts.

Structure Charts

The project organization structure chart is an essential tool for visually communicating the critical roles within a project, and the context of the project within the client organization. Most charts will fall into one of three classes: parallel management teams, technically-led teams, and business-led teams. Each has its own strengths and weaknesses.

With the overall design of the team sketched out, the roles and reporting relationships can be drawn. From the vendor side, these are the roles to be identified: vendor project manager, technical manager, professional services manager(s), sales manager, delivery manager, and business manager. From the client side, these roles must be identified: client project manager, sponsor, technical manager, operations manager, contract manager, resource manager(s), and customer(s).

RAA Model

The RAA model is classic management theory and is useful in analyzing roles and responsibilities in a contractual environment. Responsibility is what you have agreed to do or are professionally expected to do as a duty. Accountability is the other side of responsibility. If you are responsible, then you can be held accountable according to defined success measures. This suggests consequences for failure. Finally, authority is your mandate, your freedom of action, and your delegation.

RAM Charts

RAM charts give the project manager the extra precision and clarity needed. Most project managers are familiar with the tool, and it is possible that both vendor and client PMs will have developed their own chart. That, of course, is the problem. The true value of the RAM is when it is jointly developed in a proper working session, and issued as a project document signed off by both client and vendor.

3. Joint Resource Management

Resource constraints seem to dog most projects and appear in risk registers so often, it is almost “business as usual.” In the commercial world, the problem is exacerbated by the extreme reluctance of the parties to communicate their plans and status. In this particular case, I do believe that clients would benefit from adopting some of the techniques employed by most vendors.

Rational project resource planning can only occur when useful resource data are collected and analyzed to provide project and client departmental information. This requires implementation of systems and procedures to collect the needed resource effort data, utilization, and forecast availability. This is used to create a Project Resource Utilization Forecast and a Departmental Resource Availability Forecast. The parties are now in a position to collaborate meaningfully in project resourcing. This would take the form of a joint resource review meeting between the project managers and critical resource managers from both client and vendor (in vendor organizations, these are usually called Professional Services Managers). The discussion includes an open view of contingencies such as resourcing alternatives, training or coaching, trap-line for hiring, third parties, and any contractual issues that will have an influence.

4. Joint Risk Management

In contracted projects where the client and vendor operate joint risk assessments, I have noticed that outcomes have usually been positive. Teams seem to be influenced to perform collaboratively in other areas as well, and the project atmosphere is more positive.

The challenge is to bridge the marked difference in risk perception between the vendor sales, vendor project management, and the client. A salesperson trying to make a project sale tends to view risk as an annoyance, and presumes that the delivery side of the organization should accept it as an everyday challenge. The project manager will tend to assume an analytical posture and start drafting a risk register with only sketchy information available. On the client side, unfortunately, the likely attitude is that risk is something they really don't have to worry about, as it is likely to be downloaded onto the vendor! The most effective way to get everyone on the same page is to use two new models based on risk factors and risk indicators.

Risk Assessment During the Bid Phase

I use a Risk Factor Model (Exhibit 5) of risk at the project starting point. From experience, for given types of projects, a relatively constant set of risk facets can give rise to risk factors that act to sever a project from its objectives. The standard set of facets includes the Team, Contract, Size, Solution, Technology, and the Customer. For each facet, a checklist of risk factors is developed. Risk factors are then gathered into three tables. The base table, where risks are additive, and normalized to max at 100%; the compound table, where factors are scored with multipliers >1 and thus, act to increase the base risk score; and the mitigation table, where factors are scored with multipliers <1 and thus, decrease the risk score. The final score can be translated to a risk rank for the project, say 1 = very low to 5 = very high, and for projects of rank 4 and 5, the team can now turn its attention to further mitigation or contingency for facets associated with the threatened objectives.

There are many benefits from this approach to risk assessment. For specific project types, the expert work of defining facets and factors is done once; subsequent risk analysis can be performed by non-experts and does not start with a blank sheet of paper. The process also yields a metric that can be used to condition next steps, rather than subjecting all projects to a “one size fits all.”

Risk Assessment During the Execution Phase

When a project starts executing, everything changes. The risk rank, valuable in the planning phase, loses relevance. The specifics in the risk register gain in value, and become the team's primary future-focused risk tool. But, we still need a tool that is responsive to the project as it presently exists. With the Risk Alert Model (Exhibit 6), we can assess whether the project is in trouble, heading into trouble, or on track.

The model focuses on the strength of the links that keep our project on track with our objectives. These links are the Performance Chains. The health of the chain depends on the links—these are the risk indicators, and are the basis for declaring a risk alert for the chain, or the project as a whole.


Exhibit 5: The risk factor model for initial risk.


Exhibit 6: The risk alert model for execution risk.

The four chains are delivery, financial, team efficiency, and client relationship. The state of each chain is characterized by a set of risk indicators, forming an alert checklist that can be periodically rated. The strength of this method lies in the objectivity of the risk indicator questions, removing the subjectivity associated with many project dashboard systems.

5. Quality Target Development—Solving the Quality Conundrum

In my experience, establishing a meaningful understanding between client and vendor on the subject of project quality is one of the most difficult tasks of the project manager, and one not often achieved. Why should that be?

Quality is difficult at the best of times, more so in most commercial relationships. Both parties are more comfortable dealing in subjective terms—vendors will talk about the objective of “customer satisfaction;” clients will talk about the need for everything to “work the way we want.” Sometimes, slogans are mistaken for quality policy (“Quality is Job 1”), and serious engagement ends there. Often, (unfortunately) neither party has had adequate training on how quality best applies to their application area, and neither do they have a sharable quality system in place. Without a solid reference point, the vendor estimates and prices the work to their normal “high standard.”

Because quality issues are avoided at the front end, often past the contracting stage, cost can become an obstacle. The vendor probably did price the work to their usual high standard, but when the client insists on changing blue to red for the third time because the user doesn't like it, disconnects arise as the vendor tries to protect her margins, and the client protects his budget.

To build a collaborative approach to quality and resolve the conundrum, these are the techniques I recommend. First, we need a framework that moves subjective expressions of future states to objective measures that represent agreed upon project targets. Next, we need to use uncomplicated (intuitive) models to establish project norms that will best meet quality objectives. Finally, we do need a QMS (Quality Management System), though not necessarily ISO9000.

Subjective to Objective

The vendor must open a dialogue that will move the client's expression of needs from the subjective to the objective, which can be measured. The framework for this dialogue is as follows:

  1. The starting point is usually in terms of the client's subjective needs and a discussion on how important it is for the project to support those needs; therefore, the project needs measurable objectives.
  2. Next, analyze each subjective need to determine the objective need(s). To shake this out of the dialogue, “how” questions can be asked (e.g., “How will you know that your customers are satisfied?”). One of many possible answers may be “fewer complaints.”
  3. When the dialogue reaches this point of detail, we are able to discover the quality objective and contributing factors that play into the project. The question becomes, “What must the project do/product do/system do to reduce the number of complaints?” The answer to this question likely comes from team specialists for which the project manager can assume responsibility.

The project manager should never sign up for objectives that cannot be achieved within the scope of work. That way lays failure and frustration. So, accept accountability for product characteristics, but not customer complaints.

Useful Quality Models

Models don't work for everyone, but in the case of quality, with its shifting definition, “eye-of-the-beholder” nature, and the inadequacy of vocabulary, I believe they have a valuable role in communicating almost all the important points of debate in a project. The models I use (Exhibit 7) have a memorable arithmetic progression, starting with the Point of Quality. This is followed by the Quality Balance, the Quality Triangle, and the Quality Quadrant.

  • The Point of Quality: This question should be asked about any “overhead” that costs money. What is the goal the client is pursuing” What objectives are analyzed as feeding into that goal, and which of those translate to quality factors that the project must take responsibility for? This model can introduce the quality dialogue we have just reviewed.
  • The Quality Balance: Quality theory endorses the necessity for active receipt of goods by inspection. This concept can be broadened to suggest that the relationship between seller and buyer at the time of delivery is complex and places an onus upon the acceptor, as well as the supplier. I refer to this as a balance because optimum results arise from the duality of the relationship. Insufficient attention to the acceptor role, and quality may suffer. Too much may create diminishing returns, and add unnecessarily to time and cost. These are the dynamics we must keep in balance: Supplier: “Get it done!” Accepter: “Do it well!” Supplier: “Get paid!” and Accepter: “Get it in use!”
  • The Quality Triangle: The model expresses three fundamentals that determine quality: People, Process, and Technology. The quality movement has concentrated so much on process that the other two sides of the triangle are in danger of being forgotten, although sloganeering has almost compensated—remember: “People are our most valuable asset”! The model serves as a reminder and a powerful summation of the foundation for quality in most projects. Establishing a quality policy on projects is not usually seen as within the mandate of the project manager, who would typically adopt the corporate policy. For this reason, I think it falls to the vendor firm to think seriously about how they expect to build quality into their projects. The Quality Triangle is the best tool for thinking out corporate quality policy. It is not sufficient to circulate an executive memo stating the firm's “commitment to quality” and leaving it at that. Specifics (though not details) are required and the Quality Triangle is a model for this thinking.
  • The Quality Quadrant: Trade-offs are a fact of project life. The Quadrant model arose to acknowledge that client perception of the project as a whole was just as important as the quality factors carefully built into the project/product itself. In this view, quality has two dimensions: the quality of the execution (usually experienced as time and cost), and the quality of the product (experienced as functionality and durability). Sometimes, clients have difficulty in truly assessing their priorities when trade-offs are needed and this model is a good framework for such a discussion.

Exhibit 7: Four quality models used for collaborative analysis.

A Basic Quality Management System (QMS)

A QMS, by definition, is pre-existing and unlikely to be developed collaboratively. A QMS is implemented at the corporate level, and is applied to projects. Exceptionally, the client will have an ISO9000 environment into which the vendor must fit, but in the majority of cases, the onus will be on the vendor to supply the quality environment.

To meet this “minimum” need, I propose that vendors implement a Basic QMS (Exhibit 8), designed to represent the optimum point on the quality value scale. There are four essential components.


Exhibit 8: Components of a basic QMS.

Remember that implementation of these types of systems is ongoing—training of new project managers and new team members is critical. The client and vendor must collaborate on applying the Basic QMS to the project, scheduling the training, and completing the Quality Plan. As the most important QMS document, the vendor should have a Quality Plan checklist template available to facilitate this collaboration.

6. Estimate Counseling—Your Budget, My Estímate

My theme is collaboration and the reader might be wondering, how on earth can we collaborate on this topic and still operate in a fair and competitive environment? Nonetheless, there are some aspects that fit a collaborative approach, and a body of good advice that could be given to both clients and vendors. But, the main point is for both parties to avoid wedge issues that cause inefficiency, lead to inaccurate estimates, and benefit no one.

A wedge issue drives the client (the requirements and the budget) and the vendor (the solution and the estimate) further apart for no good reason, and to the detriment of getting a good proposal.

Partial List of Wedge Issues

  1. The acceptance of ambiguity by both parties. The client should strive to remove ambiguity from her requirements, and the vendor should not hesitate to question if it is uncovered.
  2. The conflation of estimate and price. These are two different data. An estimate is first expressed in work hours or days (for services), and then is priced. The parties should not argue about one, when they mean the other.
  3. Avoidance of decisions that will impact the estimate. A conscientious client will endeavor to have these decisions made before releasing the RFP.
  4. Unreasonable choice of contract type. Don't try to squeeze a T&M project into a FP pot! Both parties should be knowledgeable about the variety of contracting types and options available that can protect the legitimate interests of the parties and still provide a competitive deal.
  5. Reluctance to discuss assumptions. Assumptions are essential to a realistic estimate, but can also be the refuge of the lazy. Items 1 and 3 in this list must be covered by assumptions if the questions are not answered.
  6. Subterfuge to evade discussion on risk and contingency. This is one of the hardest wedge issues. I have sometimes buried contingency in “support” activities to avoid being stripped of my contingency, hardly a collaborative approach. Please refer to Joint Risk Management for best collaborative practice in this area.
  7. Accepting an unreasonable approach (e.g., “big bang”). This is related to item 4, but if the contract type is fixed, then both parties might collaborate on a revised approach that will better meet all objectives.


Why have I selected these six practices? Life cycle mapping is crucial to integration, joint project operations, and communications. Quality is difficult, misunderstood, and hence, frequently ignored. Resources, risk, and estimation are critical domains, but are frequently treated as confidential, proprietary, or as jeopardizing the competitive environment. It is time to change that, so the priority is to address those areas.

I expect there are additional practice areas required to support collaboration. Perhaps, short-listing, project initiation, joint scheduling, status reporting, performance management, communications, changes, issues (escalation), reviews, deficiencies, deliverable acceptance, lessons learned, and project sign-off are good candidates. Many of these demand less priority as they reach into existing project management methods and require less innovation to operate jointly, or are less controversial. Meanwhile, I see no reason why a vendor and client could not immediately adopt, with mutual agreement, some or all of the practices I describe here as point solutions for immediate implementation.

Future Development

This is the outline of how we could proceed:

  1. The first phase is to canvass a consortium of vendor and client firms on their best practices and their willingness to participate in a TCP development partnership. This should yield sponsorship, designation of a working group, and a development plan.
  2. The second phase is development, involving methodology design, draft documentation, and trials agreed upon with a committed client/vendor group.
  3. The third phase is to select a technology (web seems appropriate), create a technical design, and translate the methodology into software. Beta tests with the client/vendor group would validate the product.
  4. The final phase, or implementation, requires the publication of the TCP, the formalization of a supervisory organization, the design of a client/vendor subscription model, and contractual proformas.

An interim step could be to publish a complementary practice standard to support vendor firms in this neglected area. This might also cross over to more sophisticated clients who operate an internal economy.

Indisputably, there is a process vacuum in the commercial arena, and unless this initiative, or something similar, is taken into development, I can't see any reason for commercial projects to improve either in efficiency, in outcome for stakeholders, or in the equanimity of the project principals. The opportunity for PMI is evident.

For further information, please email the author at [email protected].

Hornby, Robin (2013). Projects for Profit: An insider's guide to delivering projects and getting paid. Calgary, Canada: Tempest Management Inc.

Project Management Institute. (2013). A guide to the project management body of knowledge (PMBOK® guide) – Fifth edition. Newtown Square, PA: Author.

© 2015, Robin Hornby
Originally published as a part of the 2015 PMI Global Congress Proceedings – Orlando, Florida, USA