From: Andrew Gabb (agabb@tpgi.com.au)
Date: Fri Sep 12 2003 - 18:10:38 EST
As threatened earlier. This is relevant to some recent discussions.
It may also give some of you an idea of what I mean by large complex
projects. A couple of these were *very* large.
A few years ago I carried out a survey of a number of projects in AusDoD, looking at the numbers and distribution of requirements in defence solicitations and contracts. For a number of reasons, including client sensitivity to release of the results, this work was never published, either internally or externally. At the time I was strongly aware of the potential value of the work, so I'm taking an opportunity to summarise the results here.
Some numbers:
# 7 projects, of considerable variety: platforms, systems.
# 12 document sets (solicitations and/or contracts).
# Budget range $30M to $2,000M ($A, $A1.00 = $US0.66).
# Pages 100-2500 (500 typical).
# Requirements 500-6000 (1500 typical).
The types of documents involved included the following (noting that
not all documents may contain requirements):
# Conditions of Tender (bid/proposal).
# Contract itself (or draft contract in solicitation).
# Statement of Work.
# Data Requirements (eg CDRL/TDRL).
# Specifications and Statements of Work.
# Informational documents.
Data requirements were often in specific Data Item Descriptions (DIDs) and Tender DIDS (TDIDs).
It should be noted that I reviewed each document set in 4 hours (which needed some special tools and techniques). Most document sets were in PDF, Word and/or Excel.
The requirements were broken down by 'level' as follows, noting that some are rather subjective:
# High level functional and performance requirements - these are
expressed directly in terms of the higher level operational needs,
noting that 'operational' is awkward to define for some projects.
These will normally be expressed in user terms and address specific
missions, roles and objectives.
# Medium level functional and performance requirements -
requirements which are evidently related to and derived from
operational requirements, but are expressed at a relatively detailed
level in terms of the functions needed to meet the higher level
objectives.
# Detailed functional and performance requirements - requirements
which are evidently related to and derived from operational
requirements, but are expressed in detailed technical terms or
assume specific technical solutions. These may include the
following, for example: highly mathematical requirements, specific
solutions, and requirements with no apparent obvious link to
operational requirements (although they may be based on detailed
analysis of operations).
# Technical requirements - requirements which are obviously not
related to functions and performance. These may include engineering
and design requirements, access to design data, review requirements
(but not test and evaluation requirements for operational functions)
and so forth.
# Data Requirements - requirements on what data deliverables should
contain. These should normally be in the SOW or CDRL, not in a
specification.
# Work requirements - particularly applies to in-service support,
but may also apply elsewhere (e.g. training). Other work
requirements should normally be in the SOW (but often are in
specifications (incorrectly)).
An average breakdown across the requirements levels was as follows:
# High level functional requirements: 1-5%
# Medium level functional requirements: 5-60%
# Detailed functional requirements: 20-50%
# Technical requirements: 5-50%
# Data Requirements: 1%
# Work requirements: 1-15%
The findings of the survey can be summarised as follows:
# There is some correlation between project cost and the size of the
RFT or Contract package in pages and requirements.
# There is considerable variation in the size and structure of
document sets for the different projects.
# Contractors may have difficulty in identifying all the
requirements for the project due to poor structure, inconsistencies
and duplication in the document set.
# There is considerable variation in the level at which requirements
are defined in different RFTs and Contracts, and in the ratio of
functional to technical requirements.
While this variation was due in part to individual project preference and local (or traditional tribal) policy, I felt that the *type* of product and/or project was also a strong factor. For example, upgrades and simulation systems tended to result in more technical requirements, perhaps understandably. This was a small sample to comment on, however.
Enjoy. I'll answer any questions I can, without being too specific, unfortunately.
Andrew
-- Andrew Gabb email: agabb@tpgi.com.au Adelaide, South Australia phone: +61 8 8342-1021, fax: +61 8 8269-3280 ----- ------------------------------------------------------------------------------- To send a message to this mailing list send it to re-online@it.uts.edu.au. To unsubscribe from this mailing list, email majordomo@it.uts.edu.au with the message `unsubscribe re-online' in the BODY of the mail.
This archive was generated by hypermail 2.1.6 : Wed Oct 15 2003 - 14:23:02 EST