Competitive procurement

By -

Competitive procurement

41.1 Purpose

Competitive procurement is a set of procedures for subcontracting work through a bidding process. The intent is to solicit fair, impartial, competitive bids.

41.2 Strengths, weaknesses, and limitations

Because the contract is typically awarded to the low bidder, the competitive bidding process tends to minimize cost. Multiple bidders bring different viewpoints to the process, and often suggest alternative solutions. The step-by-step nature of the process provides the sponsoring organization with a useful structure for managing subcontracted or outplaced projects.

Preparing specifications and bids is expensive. It is difficult (perhaps impossible) to prespecify every detail of a complex system that will be developed over several years. The competitive bidding process tends to be rigid. Requirements change over time, and procedures for dealing with changes are a major weak point.

Preparing and evaluating the documents submitted by numerous bidders is incredibly time-consuming. In today’s economy, firms that cannot react quickly to changing conditions find it difficult to compete, and the delays caused by frequent bidding cycles are intolerable. Consequently, many organizations that subcontract or outsource information system development work use a streamlined version of the competitive bidding process that sacrifices some control to gain time.

Low bids do not always imply high quality. In an effort to improve quality, many organizations have significantly reduced the number of projects that go through the competitive procurement process and have chosen instead to establish long-term relationships with a limited number of subcontractors.

41.3 Inputs and related ideas

Competitive procurement can occur during or immediately after the problem definition (Part II), analysis (Part IV), and design (Part VI) phases of the system development life cycle, and specific subsystems or tasks can be put out for competitive bids at any stage. The requirements specification (Chapter 35) often serves as a basis for competitive procurement.

41.4 Concepts

The competitive procurement process was initially developed by the U.S. Department of Defense as a means to minimize costs and ensure fair access on major military-related projects. Today, the trend toward downsizing and outplacement has led to an increase in the number of firms that subcontract or outplace information system development projects. Many corporate competitive procurement systems are modeled on the Department of Defense standard.

41.4.1 Standards

There are several widely used standards for writing requirements. DoD-STD-2167A2 defines procedures for defense system software development. DoD-STD-490 and DoD-STD-499 must be followed on most military contracts. Other standards, such as IEEE STD-729 (a glossary) and IEEE STD-830 are defined by civilian organizations1 (in this case, by the Institute of Electrical and Electronics Engineers), and many companies have their own internal standards.

41.4.2 Department of Defense Standard 2167A

Figure 41.1 shows a hurricane tracking system that consists of three major subsystems. Outlined below are the key elements of a DoD-STD-2167A requirements specification that might be prepared for such a system.

41.4.2.1 The system/segment specifications

Sometimes called the project or mission requirements, the system/segment specifications (SSS), or A-specs, identify major systems and subsystems at a conceptual level. For example, the highest-level system/segment specification for the system pictured in Figure 41.1 might identify such requirements as:

Locate the position of the hurricane’s eye within 500 m every 15 min.
Reproject the hurricane’s likely landfalls every 15 min.
Graphically display the hurricane’s most current position and likely landfalls in a format acceptable to the television networks.

Note the nature of these requirements. They are logical. They describe what the system must do, not how the system must work. The requirement that a hurricane’s position be graphically displayed calls for both hardware and software, making it a hardware/software composite item. Clearly, it specifies more than a single physical component.

41-01
Figure 41.1  A hurricane tracking system that consists of three major subsystems.

The system/segment specifications define the requirements down to, but not including, the configuration item level. (The system’s physical components begin to appear at the configuration item level.) A high-level mission requirement might be subdivided into several segments, and those segments might be further subdivided, so there can be several levels of system/segment specifications.

41.4.2.2 The system/segment design documents

The system/segment design documents (SSDD), or B-specs, define, in black-box form, the components that occupy the configuration item level. For example, a system/segment design document might be prepared for a program, but the routines that make up the program are below the configuration item level and so do not appear in the SSDD.

Figure 41.2 shows that the Data collection subsystem consists of a Satellite segment, anObservation plane segment, a Data preparation segment, and, perhaps, several other discrete, high-level, physical components. In this example, the Satellite segment is hardware and the Data preparation segment is software. If controlling the satellite calls for additional software, the appropriate program would appear as a separate segment. One system/segment design document is prepared for each configuration item. These documents summarize high-level design decisions, and they serve as a basis for defining the next lower level of requirements.

Like the system/segment specifications, the system/segment design documents are logical, not physical. Each one describes a discrete physical component, but they specify what that component must do, not how it must work. For example, an SSDD for a microcomputer might specify such things as weight and size limitations, response time requirements, and the number of transactions that must be processed per unit of time, but it will not specify a particular model computer or distinguish between a Dell Dimension system and an Apple Macintosh.

41-02
Figure 41.2  TheData collection subsystem.

41.4.2.3 The software requirements specifications

Each subsystem that is to be implemented in software is called a computer software configuration item (CSCI) and is documented in a software requirements specification (SRS). These documents consist of program design specifications. They are prepared after key design decisions have been made. Unlike the SSS and SSDD specifications, they define how the solution will be implemented.

41.4.2.4 The prime item development specifications

Each subsystem that is to be implemented in hardware is called a hardware configuration item (HWCI) and is documented in a prime item development specification (PIDS). These documents consist of hardware design specifications. They are prepared after key design decisions have been made. Unlike the SSS and SSDD specifications, they define how the solution will be implemented.

41.4.3 The procurement process

Figure 41.3 summarizes the competitive procurement process. Note that few organizations seek competitive bids at each stage, so the process is much more flexible than the flow diagram suggests.

The process begins during the problem definition and information gathering stage of the system development life cycle (Part II). Based on a preliminary analysis of the problem, user experts who work for the government agency or the customer organization that is sponsoring the project define a set of needs and write the system/segment specifications (A-specs), which are then released for bids.

On a major system, several firms might be awarded contracts and charged with preparing competitive system/segment design documents (B-specs). The completed SSDDs are submitted to the customer and evaluated. The best set is then selected and once again released for bids. Sometimes, the firm that prepared the system/segment design documents is prohibited from participating in the next round.

Based on the competitive bids, a contract to generate a physical design and prepare a set of specifications based on the system/segment design documents is subsequently awarded to one or (perhaps) two companies. One PIDS (hardware) or SRS (software) is prepared for each SSDD. (In other words, one physical design specification is created for each configuration item.)

At the end of this phase, the PIDS and SRS documents are reviewed and approved. The best design specifications are then released for a final round of competitive procurement, with the winning firm getting a contract to build the system. Clearly, the organization that created the final specifications has an advantage, but there are no guarantees. Sometimes a backup supplier is awarded a portion of the contract.

41-03
Figure 41.3  The competitive procurement process.

41.5 Key terms
Competitive procurement—
A set of procedures for subcontracting work through a bidding process.
Computer software configuration item (CSCI)—
A subsystem that is to be implemented in software.
Configuration item—
A functional primitive that appears at the lowest level of decomposition.
Configuration item level—
An imaginary line that links the system’s configuration items.
Hardware configuration item (HWCI)—
A subsystem that is to be implemented in hardware.
Prime item development specification (PIDS)—
The documentation for a hardware configuration item; a hardware design specification.
Software requirements specification (SRS)—
The documentation for a computer software configuration item; a program design specification.
System/segment design documents (SSDD) (B-specs)—
A set of specifications that define, in black-box form, the components that occupy the configuration item level.
System/segment specifications (SSS) (A-specs)—
A set of specifications that identify major systems and subsystems at a conceptual level; the system/segment specifications define the requirements down to, but not including, the configuration item level; sometimes called the project or mission requirements.
41.6 Software

Not applicable.

41.7 References
1.  Thayer, R. H. and Dorfman, M., System and Software Requirements Engineering, IEEE Computer Society Press, Los Alamitos, CA, 1990.
2.  Anon., Military Standard, Defense System Software Development, (DoD-STD-2167A), U.S. Department of Defense, Washington, D.C.

Comments

Post a Comment

Popular posts from this blog

The Conversion Cycle:The Traditional Manufacturing Environment

By -
Image
The Traditional Manufacturing Environment The conversion cycle consists of both physical and information activities related to manufacturing products for sale. The context-level data flow diagram (DFD) in Figure 7-1 illustrates the central role of the conversion cycle and its interactions with other business cycles. Production is triggered by customer orders from the revenue cycle and/or by sales forecasts from marketing. These inputs are used to set a production target and prepare a production plan, which drives production activities. Purchase requisitions for the raw materials needed to meet production objectives are sent to the purchases procedures (expenditure cycle), which prepares purchase orders for vendors. Labor used in production is transmitted to the payroll system (expenditure cycle) for payroll processing. Manufacturing costs associated with intermediate work-in-process and finished goods (FG) are sent to the general ledger (GL) and financial reporting system. Dependin...
Read more

The Revenue Cycle:Manual Systems

By -
Image
Manual Systems The purpose of this section is to support the system concepts presented in the previous section with models depicting people, organizational units, and physical documents and files. This section should help you envision the segregation of duties and independent verifications, which are essential to effective internal control regardless of the technology in place. In addition, we highlight inefficiencies intrinsic to manual systems, which gave rise to modern systems using improved technologies. SALES ORDER PROCESSING The system flowchart in Figure 4-12 shows the procedures and the documents typical to a manual sales order system. In manual systems, maintaining physical files of source documents is critical to the audit trail. As we walk through the flowchart, notice that in each department, after completion of the assigned task, one or more documents are filed as evidence that the task was completed. Sales Department The sales process begins with a customer cont...
Read more

HIPO (hierarchy plus input-process-output)

By -
Image
HIPO (hierarchy plus input-process-output) 64.1 Purpose The HIPO (Hierarchy plus Input-Process-Output) technique is a tool for planning and/or documenting a computer program. A HIPO model consists of a hierarchy chart that graphically represents the program’s control structure and a set of IPO (Input-Process-Output) charts that describe the inputs to, the outputs from, and the functions (or processes) performed by each module on the hierarchy chart. 64.2 Strengths, weaknesses, and limitations Using the HIPO technique, designers can evaluate and refine a program’s design, and correct flaws prior to implementation. Given the graphic nature of HIPO, users and managers can easily follow a program’s structure. The hierarchy chart serves as a useful planning and visualization document for managing the program development process. The IPO charts define for the programmer each module’s inputs, outputs, and algorithms. In theory, HIPO provides valuable long-term documentation. However...
Read more