1. Team: _____JAR_________________ System: ____Agile Bid System (ABS)_
Descriptive Statement
The ABS is a self refining rapid bid generation tool, for simple and complex applications. In the competitive world of business, the bidding process must afford companies with a tool to accurately assess and bid proposals. As this is predominately accomplished using company funds, this process must allow companies to quickly deliver accurate bids. The system ensures accuracy and completeness throughout the bid process to include bid element databases (i.e. bid review process elements) and suggested basis of estimates (BOEs).
Strategic Values/Objectives
Rapid Bid Configurability
Integrated, centralized database of systems and processes
Streamline bid process including production, review, and revision
With fast yes/no from customer
Reduce cost and time of getting accepted bid
Quick Reaction Bid Process
Phased bid process with customer feedback

2. Put as many points in each category as you feel appropriate)
CURVE High-Level System/Process Environment Consider both reactive needs & proactive opportunities to seize, within mission
Caprice: unknowable situations
Don’t know systems to be bid (reactive)
Changing timelines (reactive)
Similar programs being bid (proactive)
Adding features from previous contracts (proactive)
Uncertainty: randomness with unknowable probabilities
Revs, ECRs & E-18a (reactive)
Customer intentions and miscommunications (reactive)
? (proactive)
Risk: randomness with knowable probabilities
Subcontracts (reactive)
COTS (reactive)
Assumed Expertise and Leveraging (reactive)
Poor legacy documentation/tracking (reactive)
Reusing bids (proactive)
Variation: knowable variables and variance range
Period of Performance (reactive)
Bidder expertise (reactive)
Bidder expertise (proactive)
BOE generation (proactive)
Evolution: gradual (relatively) successive developments
Integration to other software (reactive)
Scalable (reactive)
Accuracy over time (proactive)
Predictability

3. System ___ABS_________________________
Reality Factors
Human (Including Customer) Behavior – Human error, whimsy, expediency, arrogance...
Lazy, rushed employees
Bidders familiarity with processes and systems
Organizational Behavior – Survival rules rule, nobody's in absolute control...
Management pressures, timelines, and influence
Pro-rations
Technology Pace – Accelerating technology and security-vulnerability introductions, sparse testing...
Interface software changes
Security (Proprietary Data)
System Complexity – Incomprehensible, highly networked, unintended consequences, emergence...
Moderate knowledge/experience required
Emergent reliance
Chaotic emergence from data overload
Globalization – Partners with different ethics, values, infrastructures, cultural assumptions...
Different customer expectations of outcome
Differing standards to meet targeted
Different customer expectations of detail
Partially-Agile Enterprise Faddish Practices – Outsourcing, web services, transparency, COTS policies/affects...
Subcontracting
Database Location
BOE development
Agile Customers/Competitors/Adversaries – Distributed, collaborative, self organizing, proactive, impatient, innovative...
Customer expects accurate bid
Competitors may provide a better estimate
Other? ?

4. Response Situation Analysis for System: ___ABS_________________
with [t,c,p,s] metric-priorities for each issue, t = time of response, c = cost of response, p = predictability of response, s = scope of response
Domain
Response Issue
Proactive
Reactive
Creation
(and Elimination)
What artifacts/data/knowledge must the system be creating or eliminating during its operational activity?
Creating proposal responses
Create an intuitive bidding process
Create a database to draw from in the bidding process (expanding database in operational time/ creating new entries in the database)
Create a prototype proposal (High Quality Cost Estimate) to enable discussions and get expectation concurrence
Improvement
What performance characteristics will the system be expected to improve during operational life cycle?
Responses to proposals which we respond (improve on hit ratio)
RFPs gained with bids given
Lower B & P cost per proposal compared to last quarter
Migration
What major events coming down the road will require a change in the system infrastructure?
Organizational structure changes
Technology advancements (i.e. information integration from different systems) ?
Modification
(Add/Sub Capability)
What modifications in resources-employed might need made as the system is used?
Operating system changes
Information security protocols ?
Correction
What can go wrong that will need an automatic systemic detection and response?
Systemic system crashes
Integration of and corruption of data
SME non-availability
Variation
What system/process variables will range across what values and need accommodation?
Variation in different business areas being supported
Variation in competencies of people involved with system ?
Expansion
(and Contraction
of Capacity)
What are “quantity-based” elastic-capacity range needs on resources/output/activity/other?
Implementation inside of currently company of the bidding program (how many per month to keep alive)
Reduction in number of engineering tools which are need to integrate with by enveloping currently used programs, Min and max of # of proposals per year (if fixed costs, what min proposals to offset or justify cost and how many proposals might we have to handle per year and ensure can handle scale of how many we want it to work in 5 years), Computing resources, # people simultaneously working proposal efforts (some which cross pollenate and other can’t), How many users at one point can it handle
Reconfigu-ration
What types of resource relationship configurations will need changed during operation?
Integrating SME not already involved in the team or whom are in the wrong teams ?

5. RRS Principles for System: _____ABS_________________
(Think: Plug-and-Play, Drag-and-drop)
Reconfigurable
Scalable
Reusable
Encapsulated Resources Resources are encapsulated independent units loosely coupled through the passive infrastructure.
SMEs
Financial Module
Capability Module
Hours Module
Communication Module
Evolving Infrastructure ConOps and resource interface and interaction standards that evolve slowly.
Role Assignments
ConOps
Relationship Rules between Modules
Config Control Module
Facilitated Interfacing (Pluggable) Resources & infrastructure have features facilitating easy resource insertion/removal.
Team members/Users
Third party resources
Redundancy and Diversity Duplicate resources provide fail-soft & capacity options; diversity provides functional options.
Databases
Standard Process used across different modules
Generic Structure
Facilitated Reuse Resources are reusable and/or replicable; with supporting facilitation for finding and employing appropriate resources.
Databased Legacy Projects
Elastic Capacity Resource populations & functional capacity may be increased and decreased widely within existing infrastructure.
Increased bidder population amongst employees
Peer-Peer Interaction Resources communicate directly on a peer-to-peer relationship; parallel rather than sequential relationships are favored.
Reusable database replace legacy knowledge
Parallel bidders working efforts simultaneously
Distributed Control & Information Decisions made at point of maximum knowledge; information accessible globally but kept locally.
Databases distributed
Bid Scope definition controlled and maintained
Deferred Commitment Resource relationships are transient when possible; decisions & fixed bindings are postponed until necessary.
Modularity independence
Timely customer feedback at early phases
Self-Organization Resource relationships are self-determined; and resource interaction is self-adjusting or negotiated.
Inherent self organization in processes

6. System: ____ABS________________
(Think … Drag-and-Drop / Plug-and-Play)
Encapsulated Resources
Bidders/SMEs/Operators
BOEs/Databases
Financial Models Modules
Capability Modules
Hours Modules
Integration Modules
Revision Control Modules
Communication Modules
Work Breakdown Structures
Management
Scalable
Reusable
Evolving Infrastructure Standards
Sockets: ? Role Assignments (SE/PE/PM)
Signals: ? ConOps
Security: ? Capability/Priveleges (Who can sign-off/lockout)
Safety: ?
Service: ? Relationship rules between modules (drop down menu/gray out options based on previous choices)
sockets (physical interconnect)
signals (data/stuff flow between resources)
security (trust interconnect)
safety (of user, system, and environment)
service (system assembly ConOps and evolutionary agility sustainment)

7. System ___ABS______________________
Sample Graphics for your modification into your system needs
Resources
SMEs/Bidders
Integrity
Management
Capability Module
Financial Module
Management
Hours Module
Databases
Communication Module
Situational awareness
Resource mix evolution
Resource readiness
Activity assembly
Infrastructure evolution
Customer
Databases
SMEs
Project Engineers
Databases and Company Organization
Active
Infrastructure
Passive
Minimal
Stanard
Advanced
Sockets
Signals
Security
Safety
Service
Software Interfaces
Communications and data
QA, Configuration management
Training, Reviews/Gates, Relationship rules between modules
Bid Process ConOps,
Rules/Standards