Valid RFP Development

Introduction and RationaleAn RFP is a request for proposal. RFPs are intended to be the terms, conditions, and specifications of work to be done by some other organization. For government agencies, the other organization is often a contractor. For large corporations, the different organization is either a contractor or a different internal organization.

The most critical aspect of an RFP is that it is valid, reliable, and repeatable. Valid means an RFP must accurately reflect what is needed to be developed. Reliable means an RFP should produce proposals that are all priced within a reasonably narrow range, say, +/- 10%. Repeatable means an RFP should produce proposals that are sufficiently similar in technical understanding and work approach from the different organizations bidding the work.

The process of creating the correct technical specification component of an RFP involves the creation of the following technical components:

• Missions, Scope and User Community
• Data Models
• Function Models
• Developed Information Systems
• Business Event and Transaction Models
• Interface Systems
• System Control Components

These RFP technical specification components should be fully defined, and the resulting work products be completely cross-referenced. Further, these work products should be stored, for example, in a Whitemarsh metabase system database.

Produced from these RFP technical specification components are a series of prototypes using Clarion (www.softvelocity.com). These function-based prototypes should be validated through cycles of demonstrations and specification product revision. As changes are accomplished, components are updated and cross-references updated.

These RFP technical specification components should be incorporated within the RFP. Incorporated as well should be: 1) a copy of the metadata management system (e.g., Metabase) and the metadata databases that contain the browse-able and cross-referenced specifications, and 2) a complete set of the prototypes that can be downloaded and executed on the bidder’s computers.

RFP Technical Specification ComponentsFrom above, the RFP technical specification components are detailed in a summary fashion in the sections that follow.

Mission, Scope, and User Community
The mission and scope materials for existing business environments should fully describe the ultimate objective of the business information system. Necessary also would be a description of all the different user communities that are expected to be served: that is, those that create and update data, that report data and that perform special analyses on the business information systems containing data. This material is important in the RFP so that bidders can fully understand the nature, scope, and user communities that are already served and that will be served by the replacement system.

Data Models
The data model materials for the existing systems are of six (6) distinct types. These are:

• Data element model
• Conceptual data model
• Logical data model
• Physical data model
• View data model
• XML data model

Function Models
Function models are the behavior models that govern the interaction between the existing business information system users, the business information systems, and the databases. Function models are materialized in the following forms:

• End-user screen specifications and their step-by-step sequences and inter-screen invocations
• Batch processing systems including their steps, sequences and alternative processing routes and inter-batch process system invocations
• Business rules and their specifications that get executed on behalf of data quality checking, completeness, transformation, and computation
• Use case diagrams that specify the behavior to be performed. Included are step-by-step sequences, invocation of business rules, and invocation of other use cases
• Data mapping between the required behavior model components and the databases, These are commonly expressed in an SQL view form of syntax
• Information systems and contained subsystems down to processing modules mappings to the function models and contained processes within the function models

The behavior models of the existing business information systems need to be discovered and put into a form that can be reviewed as to their correctness, complexity and completeness. Thereafter, a form of that research should be placed in the appropriate section of the RFP.

Developed Information Systems
Existing business information systems need to be identified, assessed and materialized into the appropriate section of the RFP. The three classes that should be described are:

• Existing business information systems within the context of the current set of business information systems
• New business information systems for the proposed replacement system
• Data standardization and migration systems that must exist and execute between the existing business information systems and the new business information system replacement system

Each existing information system needs to be identified and described as to its construction characteristics.

Business Event and Transaction Models
Business events are situations that occur in the business environment that may require special before and after processing, process sequence tracking and audit trails, and may include knowing and storing the very context upon which the business event occurred. It may also require knowing which business event occurred before and then afterwards. Business events are independent of database data model that sets out the natural relationships among the data. Business events are also independent of the function model that sets out the human behavior functions that occur. Business events are, however, closely interrelated with both data and function models and must be supported by mappings.

Interface Systems
It is almost always the case that information systems interface with many other types of information systems. Each such interface needs to be identified and thoroughly specified. The common components of an interface system are the data models of the interface that may range from a direct interface mechanism such as SQL views, to fixed format data file, to a comma delimited file, to an XML-based data exchange. In any of these interface alternatives, the key issues are data types, levels of precision, the proper use of reference data values, whether the exchanged data is atomic or derived, and the like.

Each interface has to be specified such that there is little to no room for ambiguity. Specified, too, has to be the frequency and volume of data required for each interface execution. Also specified must be the required consequences of interface failures.

System Control Components
There are a number of components that deal with system control. Mainly they deal with:

• Audit Trails – the ability to roll-back a given update, and/or to follow a trail of previous updates for a particular business event
• Backup and Recovery – the ability to recover to the last successfully completed transaction or to specified date and time of a collection of successfully completed transactions
• Message Processing – the posting of messages to end users and/or recording to processing logs for batch processing as the consequence of some event that occurred during the execution of a transaction or the instigation/termination of a transaction
• Security and Privacy – the ability to allow and/or prevent accessing (insert, delete, modify, read, or select) data and/or processes by classes of users and/or individual users

The existing set of system control facilities of these and others needs to be identified and recorded from within the existing business information system.

Prototyping and Metadata ManagementThe seven sets of materials cited above will have been collected from existing business information systems and will be stored in a metadata management system. These materials will all be elaborately cross referenced and reportable. These materials will support the production of traceability from requirements through to prototyped functional operations.

These materials will also support the creation of functional prototypes across the whole of refined set of business information system requirements. These prototypes can be created in a matter of days to at most a staff week and will be presented as part of the functional models development and validation.

As each functional prototype is created it will be demonstrated to the functional subject-matter experts for review and comment. The results of the reviews will be folded back into changes to the data models, the functional models, and the business event and transaction models. At each such cycle, all the seven classes of artifacts that are stored in the metadata management system will be updated. Updated traceability is automatic. Immediately thereafter another functional prototype will be created and its review recommenced.

This process of functional prototyping will occur across entire breadth of business information system until the functional experts are satisfied that close to 100% of all the functional requirements have been teased out of their hidden corners and have been made manifest within both functional prototypes and also the metadata contained within the metadata management system. The result of this effort will be a completely updated and thoroughly cross-referenced set of the seven sets of metadata artifacts.

Summary and Return on InvestmentThe resulting set of materials that form the technical foundation of the RFP are valid, reliable, and repeatable. First, they are valid because the function-based prototypes that are cycled through the functional and technical subject-matter experts “tease out” the naturally occurring and intrinsic hidden requirements. Hence the specification, as evidenced by the RFP technical specification components and functional prototypes, “is” what is required.

Second, the work products that are to be developed into a production system are reliable mechanisms to produce bids in a narrow price range because all the work products are identified and detailed to such an extent that there’s very little room for guessing. This, of course, assumes that the bidders have experience in developing the business information system evidenced through the RFP technical specification components.

Third, the work products are repeatable because the overall process to build a business information system has been documented and validated for many years. Hence, the proposed process employed by the bidders will be essentially the same.

In summary, because the RFP technical specification components are valid, reliable and repeatable, the resulting bids are likely to enable the correct selection of an implementation contractor that will accomplish a correct implementation the first time.

There are two natural reactions to the accomplishment of this work by the contracting organization. First, that these products should be the bidder’s responsibility, and second, it’s too costly. As to the first reaction, it’s the bidders responsibility, if that were appropriate, why are the majority of development efforts late, cost more, or be less than expected? In the Standish Group’s “CHAOS Summary 2009,” report, it stated,

Could it possibly be because the requirements are not fully known at time the work is bid? In a study of 13 $100 million IT failure analyses by the U.S. Government’s Accountability Office, more than 50% of these failures were attributed to inadequate artifact specification and capture within the requirements and design phases of IT efforts. Again, could it possibly be because the requirements are not fully known at time the work is bid? Iterated and validated requirements and prototyped-based functional designs are manifest through the RFP technical specification components.

As to the second reaction, cost, based on a start-from-scratch effort, the likely cost is about 5% of the business information systems implementation. In a recent $100 million IT failure on which Whitemarsh performed the data management IV&V; function, the cost to develop these RFP technical specification components would have been 1%. Whitemarsh suspects 1% would have been very easy to justify to prevent the 99% failure. The reason why the cost is so little is that the objective of this effort is not the actual business information system but the development of valid, reliable and repeatable set of business information system specifications that can be bid by a set of contractors.