Procurement Process in Project Management practices

Procurement Process in Project Management practices. The process is described and commonly used in government procurements. Commercial procurements are similar, but they have fewer steps. At first glance, nothing seems wrong with this procurement process.

In fact, it has a number of advantages. Let’s discuss these first before we identify the challenges:

  • Competition ensures that the bids will focus only on what is requested, to be produced in a way that is the most cost-competitive. This ensures that the outsourcing organization is obtaining good value.
  • Great care is taken to ensure fairness in the process. All bidders obtain the same information from the outsourcing organization.
  • The RFP typically requests a specific capability within a specified amount of time.

This means that the outsourcing organization knows in advance what capabilities it will have in the future and how much money must be committed in its budget to obtain the capability. This helps the organization plan its future budgets. These are key advantages for the outsourcing organization. Yet from a software development perspective, the procurement process causes a number of problems. Why? Let’s take a look.

What’s Wrong with This Procurement Process?

The problem with this procurement process is that it assumes that the item being procured is a simple commodity. In other words, given a general description of the system, a vendor should be able to determine the cost to make such a system, add a percentage of profit, and produce the bid.

Of course, the software industry is far from the level of maturity seen in other industries. Given the same requirements, bids for an identical system from different contractors have large variations that can’t be explained solely by one contractor’s being more proficient than another. Specifically, consider the following issues:

A limited number of inputs describe precisely what needs to be done. Most RFPs do not supply the detailed requirements needed to truly determine the size of a software system. Many requests for proposal (RFPs) ask for a single bid for the cost of an entire project, from requirements elicitation through the delivery of the final product. How can you determine a realistic bid before you know what the project’s requirements are?

You can’t. Worse still, the RFPs for these projects sometimes request Firm Fixed Price (FFP) proposals! This is a recipe for disaster before the project has even started. Most bidders respond to this situation in one of two ways:

They bid a high price to cover the worst-case situation. Most bidders don’t do this because doing so wouldn’t make them competitive with other bidders that are willing to accept a higher level of risk.

They load the proposal with so many assumptions and stipulations that the proposal becomes meaningless early in the project’s lifetime. Although this protects the bidder legally, it is ultimately harmful to the relationship between the client and contractor. This is also risky because if there are too many assumptions or the proposal is not specific enough, the bidder risks being eliminated due to being considered nonconforming or unresponsive to the client’s needs. Ways to handle this situation are covered later in this chapter.

The organization attempts to produce a detailed set of requirements

When the outsourcing organization attempts to produce a detailed set of requirements, they are often poorly done and incomplete. Unless the outsourcing organization has the proper expertise, the requirements do not follow the best practices for requirements that are clear, concise, unambiguous, and testable. Furthermore, many stakeholders are not even sure what they want (although they usually recognize a good solution when they see it). This makes it even more difficult to properly articulate the requirements.

The bidders have a limited amount of time to properly analyze the inputs. Even if accurate, detailed requirements are supplied, there is insufficient time to read and thoroughly understand them. The primary goal during the proposal process is to produce a winning bid that compares favorably with the other bids. Many proposals are analyzed and produced within a few weeks. As stated before, most proposal teams work very long hours, with little time to contemplate the long-term effect of many of the decisions made in the bid.

Questions and answers about the RFP take place in a competitively charged environment. When a bidder has a question about the RFP, it knows that any question it asks will be shown to the other bidders. Therefore, any question that hints at a bidder’s approach to the problem or its difficulty in understanding the RFP is not submitted. This means that important questions go unanswered, or the bidder makes assumptions about the RFP that may be inappropriate.

Questions that do get submitted are not allowed to go directly to the stakeholders. They first go through a contracts department. Questions and answers are in written form only. Often, the question is misunderstood or the answer is insufficient. There is no opportunity to interact with the stakeholders during the question-and-answer process.

Definition of best and final offer (BAFO)

The BAFO phase is often counterproductive. A detrimental psychological process seems to occur during this phase with bidders. A bidder works many hours to painstakingly produce what it believes is a viable, workable plan backed up with as many facts as possible. When BAFO occurs, the bidder knows it is one step away from winning the bid.

This pressure often leads a bidder to ignore the work previously produced, slashing estimates to get the cost lower to win the bid. This results in a proposal cost based on wishful thinking and luck rather than facts. An estimate that is prepared through a careful analysis of the facts is a non-negotiable figure. The only way an estimate can be changed honestly is to change the assumptions made as a condition of the estimate—or possibly, one of the inputs to the estimate is changed. Of course, during the proposal process, the bidder does not have control over the inputs. Occasionally, errors occur when an estimate is produced. But many contractors simply look at their budget and schedule figures, slice a percentage off those figures to meet the competitive pressure, and hope for the best.

At many companies, especially medium to large companies, the members of the team who produced the proposal are not the same as the members assigned to the team after the project is won. Often, the team running the project is shocked to learn of the assumptions, budget, and schedule set forth by their teammates in the proposal. Of course, by that time, there is no choice but to live with the situation.

Given these difficulties, it’s no wonder so many projects are behind schedule and over budget. And we have not even begun to consider the usual technical challenges that come into play on projects. Clearly, a better way is needed.

How Can Procurement of Software Systems Be Improved?

The Rational Unified Process incorporates iterative development as the core of the process. Why? As discussed in Chapter 2, “Overview of the Rational Unified Process,” you can best solve a large problem by breaking it into smaller, more easily understood parts. As you learn more through the execution of iterations, risks are resolved early, and the subsequent iterations can be adjusted. Why not apply these ideas to the procurement process?

A Proposed Progressive Acquisition Model for Small Projects

For small projects, the question is how to implement an iterative, progressive model without so much procurement-related overhead that the Return on Investment (ROI) becomes poor. A two-phase acquisition process solves this problem. The first RFP, referred to as a System Specification Contract, is issued strictly for the project’s Inception and Elaboration phases. The second RFP, called the System Realization Contract, covers the project’s Construction and Transition phases, as shown in Figure 3-1. Note that the RFP for the System Realization Contract can be prepared before the completion of the Elaboration phase to minimize delays in the project. Figure 3-1. Two-phase acquisition processThe key to this model is the tremendous amount of information that is learned during a project’s Inception and Elaboration phases. Yet, the bulk of the cost to implement a project occurs in Construction and Transition. Splitting the project into two separate procurements has the following advantages:

  • The project team can conduct the requirements elicitation by interacting directly with the stakeholders.
  • You can estimate the portions of the project that use the most time and resources from useful artifacts produced during Inception and Elaboration. Reference: “Program Resources Management”, (
  • The project estimation is performed outside of a competitively charged environment.
  • The project estimation can be accomplished over a reasonable period of time, instead of during the hectic period during a proposal.
  • The contractor is motivated to produce high-quality artifacts because it can potentially win the System Realization Contract if it performs well.
  • The outsourcing organization has more flexibility. It can retain the existing contractor or hire a different one for the System Realization Contract.

If the size, schedule, and budget needed for the System Realization Contract are much larger than the outsourcing organization anticipated, the subsequent RFP for the System Realization Contract can be canceled, rescoped, or modified before the majority of the overall project schedule and funding are consumed.

Outsourcing organizations should be aware of some issues with this model

Careful planning is needed to avoid delays between the System Specification and System Realization portions of the contract. The deliverables produced in the System Specification portion of the project that is needed for the System Realization Contract must be completed, at least in draft form, early enough so that the RFP for System Realization can be produced.

If the outsourcing organization decides to award the System Realization Contract to a contractor different from the one performing the System Specification portion of the contract, a significant amount of “ramp-up” time is needed. The new contractor needs time to review the deliverables and understand the project’s business processes.

Several examples of projects that have used this model exist.

On August 29, 2003, the Department of Commerce, National Oceanic and Atmospheric Administration (NOAA) awarded a contract for a project known as Grants Online. The purpose of the NOAA Grants Online project is to provide a fast, coherent, flexible, and robust application to support the Grants evaluation, award, and long-term management and operations process. Grants Online will deliver a standardized set of capabilities for viewing, retrieving, modifying, and deleting application- and award-related information, including (but not limited to) applications, awards, amendments, audits, proposal scoring and commentary, budget, and finance information, and technical and panel reviewer information.

The equivalent of the System Specification portion of the project in project management practices

This award was for the equivalent of the System Specification portion of the project. The contractor for the System Specification portion of the contract produced the following deliverables:

  • A complete set of business and system use cases
  • An architecture road map, which provided an overview of the key architectural attributes and decisions that would be made to develop the system
  • An initial draft of the project’s Configuration Management Plan
  • A Development Case, illustrating which artifacts should be created and developed from the Rational Unified Process
  • A draft of the Requirements Management Plan
  • A Reference Architecture document, containing a proposed reference architecture for the Grants Online system
  • A Unified Modeling Language (UML) model
  • A list of key project risks with suggested mitigation steps
  • A Supplementary Requirements Specification
  • A Vision document explaining why the system is needed, who the stakeholders are, the environment, and other key information

It is far easier to produce a proposal (with a realistic schedule and budget estimates) with this accompanying information. Accordingly, RFPs with this accompanying information are more likely to receive accurate bids, and they have a better chance of concluding successfully.

Organizations that are considering implementing a two-stage acquisition model (with one contract for Inception/Elaboration and another for Construction/Transition) should consult Appendix B, “Implementing a Two-Stage Procurement Process.” It discusses the artifacts that should be produced by the system specification contract and included in the RFP for the System Realization Contract.

3 thoughts on “Procurement Process in Project Management practices”

Comments are closed.