BMT Procurement

8/7/2019 BMT Procurement

http://slidepdf.com/reader/full/bmt-procurement 1/28

WHITE PAPER:THE PROCUREMENT OF NAVAL

AND GOVERNMENT SHIPS

Abstract

The acquisition o warships, or specialist government ships, is acomplex undertaking that is increasingly dependent on specialist

skills that some governments may not possess within their own

procurement organisations. This White Paper describes activities

that may be undertaken as part o a ship procurement programme.

While it applies primarily to naval and other government ships, the

principles are also applicable to commercial vessels. Though the

overall approach is centred on the development o a set o structured

requirements supported by rigorous cost modelling, other aspects

o the approach can be pursued separately. The paper recognises

the wide dierences between various national programmes and

seeks to describe a generic approach that can be tailored to meet

a government’s own specic requirements.



WHITE PAPER:

THE PROCUREMENT OF NAVAL AND GOVERNMENT SHIPS

Contents Page

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Developing and Managing the Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Operational Research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Programme Costing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Programme Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

Procurement Specication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Tender Evaluation and Clarication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Design Assurance and Design Agent Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

Construction Assurance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Acceptance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Warranty Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Post Acceptance Support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Closing Remarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27




INTRODUCTION

Modern warships are increasingly complex vessels, as are other government ships such as Exclusive

Economic Zone (EEZ) management or oceanographic survey vessels. Buying ‘o the shel’ will

inevitably require the procuring government to make inormed decisions on a wide variety o options.

Larger navies can draw on signicant deence or government specialist support. Some navies may

not have the national inrastructure to support the acquisition o complex ships.

This White Paper describes a generic approach to the procurement o naval and government ships,

although the approach can also be applied to commercial vessels. It covers the principal elements

associated with the complete procurement cycle, while recognising that dierent countries have evolved

national procurement systems suited to their own needs. The paper does not rely on adherence to

specic standards and methodologies; it addresses the principles, and recognises that dierent projects

can ‘mix and match’ the various elements to best meet the Customer’s particular need.

The process o ship procurement is not linear and the sequence o the sections o this paper has

been chosen to best represent the overall methodology. The paper addresses the ront-end activities

(Requirements Development, Operational Research, and Programme Costing). These are described

separately, but inevitably they are closely linked. Their outputs will eed into the Procurement

Specication, the Contract and on to the nal Acceptance. In reality a number o phases will show

an overlap o activities. This is unavoidable in order to aid the decision-making at the ront end, and

in the period between design, construction and acceptance. It is not possible to compartmentalise

activities into neat bounded packages as some are interdependent on each other. To not overlap

activities would run the risk o increased project timescales, inecient use o resources, creeping

obsolescence and unavoidable increases in programme costs.

In the same way that reerence to specic government procurement methodologies is avoided; so

too is reerence to commercial or bespoke sotware programs, except or a small number o illustrative

examples. The importance o sotware tools should not be underestimated, as these will provide the

link between the Requirements and Acceptance. Most organisations will have their own preerences

or particular sotware toolsets, and these should be agreed during the contact negotiation phase.

three




our

The paper has been written with the assumption that the government has a ‘Need’ or the new

ship(s). The ‘Need’ can be dened in quite general terms, or it may be comprehensively described in

terms o the exact ship types, and numbers to be procured.

Whatever; the ‘Need’ is the starting point or the project. In ullling the ‘Need’ there will be the active

involvement o the Sponsor, the Customer and the Supplier, and at some stage the operational

duties will all to the User. There are numerous project management denitions or the above roles.

In some organisations dierent departments will carry out the roles. In others some o the roles may

be combined, particularly Sponsor and Customer, or Customer and User. There may be examples

where a Customer role is carried out by another government department, or even a specialist

contractor engaged by the Government. For the purpose o this White Paper the roles will be

discussed under the ollowing descriptions.

Sponsor… A person, or group, that is responsible or the business case that sets out the

means by which Government strategy is to be achieved through the denition and ullment

o the ‘Need’. The Sponsor is the custodian o the business case and overall strategy, and

will work closely with the Customer, User and other Stakeholders.

Customer… The procurement group responsible or acquiring ships that meet the

‘Need’ within the timescale and budgets agreed with the Sponsor. The Customer will

undertake the day-to-day management o the programme and the interace with Suppliers.

Supplier… The company responsible or delivering ships that meet the ‘Need’ as

dened by the Customer’s contract requirements.

User… The authority that will be responsible or operating the ships, thus ensuring that

Government policy dened by the ‘Need’ is ullled.

There will be signicant interaction during all phases o a ship programme between the above parties

and other interested parties, oten collectively reerred to as the stakeholders. The intensity o that

interaction will vary between the phases o the lie cycle, and this is explained within the paper.




DEVELOPING AND MANAGINGTHE REqUIREMENTS

“ The last ten percent of performance sought generates one-third of the cost

and two-thirds of the problems.” Augustine’s Law Number VII

1

Requirements can be dened in many ways and their use on a particular project will oten be guided

by the corporate governance demands o the organisation procuring the ship(s). The topic is one o

continual evolution as well as reliance on previous experience.

For example, up to the 1980s the norm or Government ships was to develop a detailed technical

specication that eectively xed the design and subsequent cost and perormance; the majority

o the risk being taken by the Customer. The use o Cardinal, or Key Point Specications turned the

balance through 180 degrees and eectively let the Customer with minimal input.

The 1990s saw the use o structured requirements emanating rom the National Aeronautics and

Space Administration (NASA) and European Space Agency. These sought to demarcate between

dening the use, outputs and characteristics required by the Sponsor and/or Customer (User Re-

quirements) and the System Requirements that may be owned by the system developer (Supplier),and which can be used to model an abstract solution to the ‘Need’.

However, it should be recognised that on some programmes the higher levels o the System

Requirements may be ‘owned’ by the Customer and the lower levels may be ‘owned’ by the Supplier.

The complexity o some programmes saw an even higher level o requirement being introduced, these

are the Key User Requirements, which then cascade down into User and System Requirements.

Some Deence organisations have now moved away rom Requirements and towards Capability

Acquisition. In reality this is another increment in a set o cascaded requirements, and denes the

‘Need’ in a dierent manner.

To some degree or other, all o the above provide a means o structured and auditable communication

between the Sponsor, Customer and Supplier. The detailed Customer technical specication

approach is successul providing the Customer has the expertise to develop the specication, but it

may not allow the Supplier scope to innovate. It also eectively xes the majority o the programme

cost, perormance and risk within the Customer’s sphere. It can be successul in procuring ships

where the Customer has the knowledge to carry out preliminary studies, or where the ships to be

procured are based on a known design and perormance.

1 Augustine’s Laws by Norman R Augustine ISBN 1-5634-7239-2

fve




The Cardinal, or Key Point Specication reverses that position and with its higher level o denition

is most suited or simpler projects probably based on Military (MOTS) and/or Commercial O The

Shel (COTS) solutions.

So where does that leave us? Well, or any project to proceed a Sponsor must have a ‘Need’. Suitably

dened by the Customer in consultation with the uture End Users, this will eventually orm the basis

o an Oer rom one or more prospective Suppliers. The Requirement based approach is now

generally recognised as the most suitable or the use in a government contracting scenario where

there is a dened ‘Need’, and the Supplier has the skill and resources to provide a solution to ull

that ‘Need’.

Requirements Denition is probably the most crucial part o the project. Incorrect, inaccurate, or

excessive denition o requirements must necessarily result in schedule delays, wasted resources, or

Customer dissatisaction. The Requirements Analysis should begin with business or organisational

requirements and translate these into project requirements. I meeting stated requirements would be

unreasonably costly, or take too long, the project requirements may have to be traded, or de-scoped

through discussion between the parties involved.

Any discussion o requirements analysis methods will quickly become specic to the type o project

involved. Many industry areas have specic, proven techniques or obtaining thorough and accurate

denition o requirements. Sometimes it is useul to write a ‘Concept o Operations’ (CONOPS)

paper and/or a ‘Concept o Use’ paper as a way to aid the development o requirements.

A CONOPS paper addresses how the new ships will operate alone or as part o a task orce, and

in the context o the missions and tasks they are expected to undertake. A Concept o Use paper

would address how the internal organisation o the ship unctions during specic operations. For

example, the Concept o Use paper or an amphibious warare ship could describe how the

embarked orce would muster their personal kit, weapons and stores through debarkation and

eventual re-embarkation. Such a paper inorms the Requirements developers and designers and

aids the wider understanding o specialist subjects.

While the methods may dier, the principles remain the same across all types and sizes o projects.

The Requirements Analysis should cover the whole scope o the project, i.e., ship perormance,

sotware, logistics, project management, saety, environment, human resources, test and acceptance,etc.. It must be comprehensive and thorough and it must consider the views and needs o all the

stakeholders.

Using a Requirements based approach allows the Sponsor (and Customer) to control technical

developments without necessarily needing to know the ull complexities o the solutions. It will also

provide a logical basis or maintenance o the design intent and change management throughout

the whole lie cycle. It also ensures that stakeholder inputs and priorities are identied early.

Constructing an early set o User Requirements is essentially a modelling activity; taking the urther

six




step o dening System Requirements allows the modelling o abstract solutions. It is quite acceptable

to develop a conceptual design, but this is very much an early breadboard or visualising the potential

results o the requirements set, and or testing budgets.

Dening User Requirements is a key task and requires a systematic approach. Generally the ollowing

steps can describe it:

a. Drat requirements capture exercise using interviews, workshops, analogous

systems, eedback reports, modelling and simulation, and existing solutions;

b. Involvement o Users and Stakeholders to maximum extent possible;

c. Ensure that the requirements are quantiable and measurable;

d. Prioritise requirements by importance early in the exercise;

e. Allow margin or requirements growth;

. Establish a process or change management;

g. Dene requirements or all aspects o the programme;

h. Re-iterate the requirement set and re-validate a number o times during the

early programme phases.

It is essential to have a management system or User Requirements and the linkages to System

Requirements, and then through to the eventual design specications through to the ormal Acceptance

activities.

There are numerous ways in which this can be achieved. The simplest management tool is the

spreadsheet; greater capability is oered by industry standard packages such as Telelogic’s DOORS®

and IBM® ’s Rational® RequisitePro® . These more powerul tools provide interaces with other

industry standard sotware that will allow archiving, video, Computer-Aided Design (CAD) visualisations,

update o programme management and planning inormation, and even risk, saety and environmental

management inormation.

The leading tools can be used well below their capability, but have the advantage that they will

accommodate expansion as their potential is realised. Whatever approach is decided upon, the

Customer’s Requirements will orm the basis o the contract and its acceptance, and they can then

be used to manage support o the ships through lie.

In concluding this section on Requirements it should be emphasised that the development o

Requirements is an iterative exercise such that the developing Requirements are tested against the

programme budgets and timescales, in order to establish the degree o risk that may be presented.

This can be undertaken using Operational Research supported by Whole Lie Cost Modelling.

As each iteration is completed the results will be analysed and the Requirements reviewed, and

probably re-cast until the overall balance o perormance, cost and timescale is within the programme

budget. This process o iteration will involve the Sponsor, Customer, User and stakeholders, and

may also extend to potential Supplier(s).

seven




OPERATIONAL RESEARCH

Developed during World War 2 in Great Britain and the USA, Operational Research applies scientic

techniques to analyse the behaviour o complex systems. It is known as Operational Research in the

United Kingdom2 and as Operations Research in most other English-speaking countries, though OR

is a common abbreviation everywhere.

Operational Research is distinguished by its ability to look at and improve an entire system rather than

concentrating only on specic elements. Operational Research at its widest use is the application o

the methods o science to complex systems. It utilises mathematics, simulation and reasoning to

provide the answers to complex real-world systems. It can however bring advantage to the decision-

making process and support to business cases even when applied to less complex systems.

Operational Research is a method o examining the current and historical perormance o systems

and measuring that perormance against a set o parameters, or eectiveness measures. It is

creative in nature, and should trigger considerations o how the objectives could be better met, how

costs could be saved, and whether, indeed, that particular organisation should even be perorming

a given unction at all.

Operational Research should demonstrate that there has been a thorough examination o the need

or the investment, the perormance being achieved by the investment, the advisability o continuing

the investment, and alternative methods o achieving the same investment results. The comparison

and analysis o the results achieved by Operational Research and Programme Costing can be

combined into an activity known as a Combined Operational Eectiveness and Investment Appraisal(COEIA) study.

Examples where Operational Research will support the decision making process or a ship

programme are:

a. The size, range, speed, crew, costs and ship type needed to achieve a desired capability;

b. The ability to examine whether a capability is best achieved using ships o the same

type, a mix o types or even by using manned aircrat, or unmanned vehicles;

c. Consideration o geographic and environmental aspects to support the required

sea-days or deployed capability o the dierent platorm types being considered;

d. Comparisons looking at weapon types, munitions quantities, sensors and

the comparative advantages o hard versus sot kill;

e. Military operations involving the ‘new ships’ and other orce elements including

land, air and allied nations;

. Integrating the logistic support acilities and support requirements or the ship types and

numbers being considered. This could address the need to upgrade bases, increased use

o contractor support and the logistic costs or support against a desired level o availability;

g. Interaces with inormation technology systems ashore or in other air and sea vehicles;

h. Human resource aspects relating to training, retention, and gender mix and

career options, imposed by the ship types being considered;

i. Analyse the socio-economic impact o the dierent procurement options.

2 Operational Research is known as OA, or Operational Analysis, within the UK military and Ministry o Deence to avoid conusion with OR, which is taken to mean Operational Requirements

eight




A major benet o Operational Research is that it allows many dierent options to be considered

in a systematic and auditable manner. It allows unattractive options to be justiably ruled out early,

thus allowing the resources to be concentrated on the more important options. While Operational

Research is mathematically based, its use does not necessarily mean vast amounts o data, with

time-consuming computer runs. The capability o spreadsheets and databases has led to the

development o commercial sotware, or bespoke packages that will run eciently on modern

desktop computers.

The Operational Research leader will guide the manner in which a particular analysis is to be carried

out, but it will need considerable input rom the stakeholders. It presents an opportunity to innovate,

introduce new technology, and to challenge accepted thinking in ensuring that the project will meet

the ‘Need’ at the least cost and on time.

nine




PROGRAMME COSTING

“ Getting it “wrong” at the outset dooms a program to delays, cost overruns,incessant oversight and realignment,

accusations of mismanagement,and perhaps even program cancellation

…and indictment.” US PODAC

3Program Manager 2001

From the very onset o a programme there is a need or cost estimating; how else will the overall

budget be set?

Initially the budget will be set by the results rom some early concept work, or by analysing similar

past programmes, or by using public data on other countries’ programmes. In reality there will be a

mix o activities to set the initial high-level budgets. Then as the programme moves along its early

phases the budgets will be rened in line with the developing requirements and the outputs o the

Operational Research. This renement will support the business case submissions or approval to

proceed to the next phase(s), until eventually there will be a budget to support the Production,

Operating and Disposal phases.

Given that the Operational phase takes around 70 percent o the whole programme budget, and thatmore than two thirds o whole lie costs are xed by the time that Denition has completed, it can be

seen that the oten limited unds expended during the early programme phases x the vast majority

o the whole lie programme costs (Production, Operating and Disposal). While these gures

are necessarily broad they do indicate that i attention is not paid to whole lie costs early in the

programme, as the programme extends there will be a signicant risk o major delays caused by

budget versus perormance problems.

Programme costing studies may address a number o specic areas, such as:

a. Research Balance o Investment;

b. Cost Capability Trade O;

c. Future Expenditure Plans;

d. Acquisition Strategy alternatives;

e. Investment Appraisal;

. Risk quantication;

g. Related equipment programmes;

h. Platorms and systems concept development;

i. Cost estimating;

j. Value engineering.

3 ‘Navy Develops Product Orientated Design and Construction Cost Model’, Program Manager, January 2001, by Dr Scott C Truver.

ten




Inorming the cost studies will be assumptions regarding systems (Capability and Availability,

Reliability and Maintainability), build strategies, upkeep strategies, manning levels, standards,

procurement approach and mission options.

The cost studies will use the developing Requirements and will also eed into the development o

Requirements and support the Operational Research. The level to which any o the cost studies,

Requirements or Operational Research is conducted will be dependent on the complexity o the

Programme and the Customer’s own preerences. These are all tools to help de-risk the programme

and can be applied to various depths. What is important is to ensure that data interaces and

linkages exist between them.

A typical package o work or cost modelling would be:

a. Provide a baseline (independent estimate) against which dierent User Requirement sets

can be analysed in order to allow the Customer to decide on the best way orward.

The cost drivers can be identied and the work used to support trade studies.

Trade studies are required to obtain the best compromise between cost and capability.

These would address both acquisition costs and the whole lie costs. The outputs can

also be used to support business case submissions, and subsequently to allow tenders

to be compared;

b. Identiy gaps in the tenders and the likely costs o lling those gaps. A typical example

would be the provision o an adequate support package (spares, documentation and

training). Another area could be inrastructure, i.e., shore based acilities required to

operate and maintain the vessels. The tenders may not cover this, but it would be

a real cost to the programme;

c. Identiy risks to the programme and their potential cost impact should they mature.

A typical example would be exchange rate risk. This work would provide a starting point

or the Customer’s risk assessment.

Trade o studies can be as simple or as complex as required to meet the needs o a particular

programme. There are well-publicised examples o complex studies relating to the US National

Missile Deence debate to the more technically biased European Space Agency’s Aurora programmestudies into optical links versus radio requency communications links rom spacecrat.

The cost estimate should be built up using a proven cost model to estimate the build and whole lie

cost estimates. This cost model could be structured around the UK Ministry o Deence De Stan

08–140, Classication o weight groups or surace warships, or the similar US Department o

Deense MIL-HDBK 881.

eleven




These sub-divide the ship into the one-digit areas shown in Table 1. Each group is urther broken

down into two-digit (major systems) and three-digit (major equipments) or cost estimating purposes.

The advantage o this structure is that all the items are ully dened and ship designers routinely use

it. All estimates would normally be broken down as labour hours and material cost. To the estimates

o build cost would be added other programme costs (non-recurring costs, such as design, overall

management o the programme, and acilities, etc.) with costs proled over time to assess the

reasonableness o any proposed nancial plans.

Cost modelling studies oten require access to commercially sensitive inormation such as the potential

Tenderers’ estimated prices, the labour resources, acility utilisation, overhead structure, etc. This is not

a unique position and most government departments can use their in–house specialists, or retain an

independent, specialist cost estimating company.

The benets and outputs o cost modelling will be:

a. Increased condence in the cost estimates or the programme and as a

consequence a more robust business case or approval to proceed. This is a

major benet when aiming to achieve an aordable programme that best meets

the Requirements;

b. Support to trade-o studies. Initially this could be a list o cost drivers, i.e., the major

candidate areas or any cost reduction work. This could be extended, dependent

on the scale and need or trade o;

c. Inormation on those cost requirements that will be included within a Procurement

Specication so that all Tenderers are required to respond with the same level

and ormat o inormation;

d. A Customer-owned cost estimate or the programme at a level o detail sucient to

support trade o studies. This estimate is likely to be ar more detailed than that

provided by Tenderers. The estimates would be supported by a commentary

documenting all the estimates and supporting assumptions;

e. An assessment o the estimates or prices supplied by Tenderers. This assessment

would identiy any anomalies in the estimates (omissions or overpricing) and seek

to compare each estimate on a common basis;

. A risk register, dening and quantiying the risks identied in the programme.

Cost modelling and estimating are specialist skills and, as with the Requirement Development and

Operational Research, there are a variety o sotware tools to support studies. These range rom Excel

spreadsheets with Visual Basic interaces to support graphical output, to bespoke models developed

to meet specic needs. Having a toolset that interaces with a common project data source will allow

more rapid and accurate progress in the Requirements Development and Operational Research tasks.

In common with those tasks the cost modeller will need to liaise widely with the Sponsor, Customer

and stakeholder communities to ensure a meaningul interpretation o the data.

twelve




Table 1: Typical Classifcation o Weight Groups or a Warship

thirteen

Group Item Areascovered Comment

1 Hull Hull, superstructure, structural Both labour and materials

bulkheads, decks, doors & generally estimated on a

hatches, seats & masts, control cost/tonne basis

suraces, castings & orgings,

ballast, astenings

2 Propulsion Propulsion units & control Usually estimated at major

equipment, shating & bearings, equipment level, with some

intakes & uptakes, cooling & minor areas costed by weight,

eed water, uel oil, lub oil. e.g. uptakes and downtakes.

3 Electrical Power generation, distribution Cabling is usually the major

equipment, cabling, lighting cost driver in this area.

4 Controland Nav systems, internal & external Sensors, comms and control,Communications comms, machinery control, estimated at equipment level.

weapon control, protective

systems. All military systems

equipment, sensors and weapons.

5 Auxiliary HVAC, uel transer, sea & resh HVAC and all pipe work systems.

Systems water, air & gas, hydraulics, This group also includes aircrat

aircrat, waste disposal, lub oil. systems (sub group 55).

6 Outftand General ttings, boats & liesaving, Paint coverings are normally the

Furnishings partitions linings & coverings, dominant cost in this weight

storerooms, living spaces, oces group.

& medical, galleys, laundries,

workshops, portable re ghting,

RAS gear.

7 Armament All military systems generally costed Estimated at equipment level.

as part o Group 4. NOTE – does not include the

cost o munitions.

8 Variableload Fuel, stores, etc. – not costed

9 Design& First o class costs (design, Shipyard white-collar labour

Construction jigs, etc.), drawing oce (support to (primarily management and

Services production), management services drawing oce support)

(management, planning, estimating, plus misc. costsQA, etc.), testing, ad hoc support Worst case, white collar can

(e.g., temporary services), sundries be 25% o the blue-collar and

(travel), disbursements hence a cost driver.

(e.g., insurance).




PROGRAMME MANAGEMENT

The term ‘Programme Management’ has been used in preerence to Project Management as or

most government ship acquisition endeavours there are a number o inter-related projects being

managed under a single Programme Leader, viz the ships, the combat systems, inormation

systems/technology inrastructure, support and base acilities, training schools, etc. However,

or the purpose o this paper the terms ‘Programme’ and Project’ can be considered to be

synonymous, as the applicable management principles are similar.

Programme management is the process o managing a portolio o multiple ongoing inter-dependent

projects. In an organisation Programme Management also refects the emphasis on coordinating

and prioritising resources across projects, departments and entities to ensure that resource confict

is managed rom a global perspective.

Programme management provides a layer above project management and ocuses on selecting

the best group o programmes, dening them in terms o their constituent projects and providing an

inrastructure where projects can be run successully.

Project Management is the discipline o dening and achieving targets while optimising the use

o resources over the course o a project. Project Management is quite oten the province and

responsibility o an individual project manager. In contrast to on-going unctional work, a project is a

nite set o activities undertaken to deliver a specic product or service. The duration o a project is

the time rom its start to its completion, which in the case o ship programmes can encompass the

whole lie cycle rom Concept through to Disposal.

Project Management is composed o several dierent types o activities such as:

a. Dening the objectives;

b. Developing the requirements;

c. Planning the work;

d. Assessing risk;

e. Estimating resources;

. Organising the work;

g. Acquiring resources;

h. Assigning tasks;

i. Directing activities;

j. Controlling project execution;

k. Managing change;

l. Reporting progress;

m. Analysing the results.

ourteen




The Programme and individual Project Managers are required to keep the ollowing our variables

under control: time, cost, quality (Requirements scope and perormance) and risk. There are

national and international standards in use (e.g., ISO 10006:1997 ‘Quality management — Guidelines

to quality in project management, V-Modell and HERMES), together with such sources o advice

as the Project Management Institute ‘Project Management Book o Knowledge’. However, most

government agencies and Suppliers will have their own preerred approach.

It is important not to oist unamiliar approaches onto the various parties as this may increase risk.

The key aspect being that the various parties can access and use accurate and timely programme

data and inormation to support their own management and reporting needs.

The cost o Programme Management activities will be dependent on the complexity and risk o the

overall programme, but all should contain some key eatures viz:

a. The core o the Programme/Project(s) will be the User Requirements, and possibly a

Customer developed set o System Requirements. These will cover all aspects o the

Programme (Perormance, Logistics, Programme Management, Commercial, etc.);

b. The structured and hierarchical set o Requirements will orm the input to a

Work Breakdown Structure (WBS);

c. The WBS allows all activities to be described in terms o task, resource and

timescale estimates;

d. The WBS should link the Requirements hierarchy to the programme planning and

control systems;

e. Project Planning and Cost Control tools will allow updated inormation transer

between the parties;

. An eective Change Management process linked back to the Requirements and WBS,

and which can keep up with the programme timescales or decision-making;

g. An eective communication and documentation strategy and process;

h. Risk Management methodology that allows the parties to see the key risks and

which encourage a joint approach to risk management.

There are many other acets o Programme Management such as Partnering, Capability Maturity Model

Integration, Shared Data Environments and Earned Value Analysis, etc. The scope and level o Programme

Management activities or the Supplier will dier rom those o the Customer, but the parties will agree the

areas that need to be seen as inormation interaces between the two organisations. In this overall area

the Customer may decide to supplement the in-house skills and resources via support rom specialist

companies to better allow the Customer to match the overall workload o a varying programme.

fteen




PROCUREMENT SPECIFICATION

When governments procure ships the expectation is or them to be available at a dened time and to

be capable o ullling their role at the lowest cost o ownership. Ship programmes are characterised

by generally being low requency, high complexity, high value and strategic. Apart rom a straight ‘Build

to Print’ activity, the style and content o the Procurement Specication will emanate rom the selected

Procurement Strategy, and this itsel will be governed by actors such as government policy, type o

programme, and the supplier base. Factors that may have to be taken account o might include:

a. National shipbuilding and associated core skills must be retained;

b. Government policy on industry and regional development;

c. Government and international obligations to competition;

d. Government co-operation with other nations;

e. Number and track record o would-be Suppliers;

. Number o the ships required and timescale;

g. Technological complexity o ships and development needs;

h. Knowledge and resources o government team;

i. Use o specialists to support government;

j. Is it a ship, or service being procured?

k. Government nances and budgetary constraints.

There are dierences in the approach used by governments and commercial ship owners when it

comes to procuring ships, although there are some common acets:

a. The ‘Need’ has to be dened and approved;

b. There will be an inormation-gathering period, when early requirements are being

generated and contact is made with the potential Suppliers;

c. Budgets will be tested against the developing Requirements and initial Supplier

estimates and benchmarked against available source inormation;

d. Supplier inormation will be sought against Requests For Quotation, Requests For

Inormation, or Requests For Proposal;

e. The Procurement Specication will be developed during this period such that Suppliers

too can have visibility and provide inputs;

. A Pre-Qualication assessment may be undertaken to allow the Government to

short-list the Suppliers.

The activities arising rom the above allow both the Customer and potential Supplier(s) to develop

their overall understanding o the programme, and to better understand the risks. The Procurement

Specication will be progressively developed during this period. Generally Procurement Specications

address the Requirements or the project (Perormance, Programme Management, Logistic and

Acceptance etc) but not the Commercial and Financial contract Terms and Conditions. Examples

o Procurement Specications are available rom Government Departments, Proessional Societies,

specialist consultancies and past acquisition programmes. The Programme Manager will decide

style, ormat and content or the Procurement Specication.

sixteen




The Procurement Specication is an intrinsic part o the process o getting into contract, and must

not be seen as a stand-alone document. Its structure must link back to the Requirements such that

when tenders are being assessed the proposals can be evaluated against the Requirements. It has

to be seen as part o the overall process and should address the ollowing:

a. It should ensure that Tender Evaluation would be conducted in a systematic,

objective and auditable manner such that decisions can be justied;

b. It should ensure ull carry through o Requirements so that tenders can be assessed

to ensure that no Requirements or Conditions have been missed;

c. It should have an Evaluation Plan and Evaluation Guide developed in parallel, and the

sensitivity to the proposed assessment weightings should be modelled prior

to the Procurement Specication being issued;

d. It should be a ormally controlled document;

e. It should be capable o being broken down or distribution to the Tender Evaluation Team;

. It should allow or rapid ltering o tenders such that unsatisactory tenders can be

put aside, and the decision justied;

g. It should allow or the value (or money) to be evaluated and not just price alone;

h. Its compatibility with Tender Evaluation sotware (i being used) should be established;

i. It should ensure that like or like comparisons can be made between tenders. Examples

being the labour resources available to build ships in the stated timescale, or to allow

comparison o Whole Lie Cost between tenders?

j. It should be structured to aid the generation o reports supporting investment decisions,

and hence will reduce the workload on the Customer team, while still ensuring

ull auditability.

The eort expended in developing a cohesive Procurement Specication will bring benets bothduring the Tender Evaluation and Negotiation phases, as well as during the Contract Execution

phase. Like all o the other aspects o an acquisition programme it must be tailored to be compatible

with the complexity and risk o the overall programme. It may be possible to use the developing

Procurement Specication to ‘price’ the Project based on industry eedback, or by independent

review o ‘Should Cost’ estimates.

seventeen




TENDER EVALUATION AND CLARIFICATION

Given a Procurement Specication that captures the Requirements, and that has an associated set

o evaluation criteria the Customer will need to plan the Evaluation Team’s activities in order to

obtain the best possible outcome. The Evaluation Team must have available to them the Procurement

Specication and Evaluation Criteria. These criteria should be developed prior to the Invitation To

Tender (ITT) being issued. In most cases the Evaluation Team will have been involved in developing

the Evaluation Criteria, and communicating with stakeholders to ensure that the criteria capture

the important elements o the Requirements. These are the objective questions against which the

Evaluation Team will decide on the marks to be awarded against each Requirement. Note that the

Commercial and Price inormation and evaluation should be kept separate rom the other aspects o

the evaluation. This ensures that early knowledge o price does not prejudice the objective evaluation

o other inormation provided by the Tenderers in response to the ITT.

The Evaluation Team may well comprise a number o Panels, i.e., Ship Platorm, Combat System,

Shipbuilder, Logistic Support, Cost Analysis, Commercial and Finance. Some o these Panels may

be sub-divided to cover specialist areas. The Team will work to a Tender Evaluation Plan and

Evaluation Guide to ensure that the timescales are achieved, and that there is a consistent approach

across the Evaluation. Supporting the Team may be specialist stakeholders or independent companies.

These may provide technical support or they could be undertaking the mechanics o the Tender

Evaluation process thus reeing the Team to concentrate on the actual evaluation o the tenders.

The Tender Evaluation Team will be seeking the ollowing generic types o evidence:

a. Does the proposal ull the aims/objectives o the project? b. Will it meet the needs o the User?

c. Is there evidence o innovative practice and/or thinking?

d. Have they undertaken similar project(s) in the past?

e. Were the projects successully implemented?

. Is there evidence that they have knowledge o the subject areas?

g. Does the Tenderer’s project team have experience o the subject areas?

h. Does the Tenderer’s project team have technical experience to carry out the work?

i. Do any subcontractors have the appropriate experience and a sound working

relationship with the Tenderer?

j. Are they able to meet the timescale?

k. Is this a realistic schedule o work?

eighteen




Some organisations will provide the Tenderers with details o the Evaluation process and also some

inormation on key weightings; this can be helpul to both parties. The Evaluation must be done on

the basis o the tenders submitted and not on any extraneous inormation known or received unless

that inormation is received as clarication o a point raised with a Tenderer. Care must be taken

during the evaluation phase to treat the tenders, as commercial-in-condence. The Evaluating Team

member(s), or Panel must record the evaluation results in writing. Unsolicited proposals, or non-

compliant tenders cannot be evaluated as a part o the Tender Evaluation Plan, and it is under the

Programme Manager’s discretion i these are to be evaluated separately.

Non-compliant tenders should only come into consideration ater the evaluation o compliant tenders

has identied a ront-runner against which it can be compared. A non-compliant tender can be

dismissed or many reasons (or example, that the idea is considered unworkable; it is below an

acceptable standard; it oers no advantage to the Specication as issued; or it involves unacceptable

risks). A non-compliant tender should not be accepted i the other Tenderers could equally well havepriced the proposal had they known that it would be given consideration. I this was the case, it would

call into question the wording o the original Procurement Specication and the other Tenderers should

be invited to submit their corresponding oer.

Where a tender is ambiguous, or where the conditions set out in the ITT otherwise allow, the Evaluation

Team may seek to clariy with the Tenderer. Assumptions must not be made to ll in gaps in a tender.

I the tender is not clear in any aspect, clarication must be sought and recorded in writing. In some

cases it may be desirable to ask each o the Tenderers to give a presentation on their tender. It may

be appropriate to arrange site visits or a complicated, multi-disciplinary activity such as a ship

procurement programme. Inormation received at such presentations must be documented and can

be used in clarication. Tenderers must be treated equally and airly in respect o the opportunity to

give a presentation and the exchange o inormation arising out o submitted tenders.

nineteen




Clarication must be completed beore the Tender Evaluation Report is nalised, so that tenders can

be properly ranked. While the basis or pricing may be claried, there must be no negotiation in relation

to the overall price submitted by a Tenderer. I a Tenderer was allowed to alter the price, the tender

process may be invalidated as a result. Price negotiation can be conducted under the auspices o

a ‘Revise and Conrm’ approach where there are still potential changes to the tender, or by ‘Best

and Final’, where no urther negotiation is envisaged. As a result o the evaluation the Tenderers will

be ranked in value-or-money order. Sensitivity analysis should be carried out where appropriate to

veriy the ranking where the selection is close. The rankings must be justiable on the basis o the

evaluation criteria that support the value or money recommendation.

The Tender Evaluation Report documents the way in which the tenders were evaluated, the

assessment o the tenders, the resulting ranked list o tenders and makes a recommendation to the

decision authority. It must also identiy any tenders that are unacceptable. It is an important record

or any uture review o how the tendering process was conducted and will be an important toolin debrieing the Tenderers. The report must be based on demonstrable evidence and the

inal recommendation should have been base lined using a sensitivity analysis. It should show the

strengths and weaknesses o all tenders evaluated and should contain actual and demonstrable

evidence. I there was not a clear winner how does the report justiy the recommendation to proceed?

Is there a basis or proceeding without undue risk? Perhaps in such cases the Customer may have

to re-visit the Requirements, budgets or timescales, and may have to go around the cycle, or a part

o it, again. In some cases the Procurement Strategy may have to be re-visited such that perhaps it

is decided to keep two Tenderers in competition or longer until a clear winner is identied.

What the Customer is looking to achieve is best value or money in ullling the ‘Need’. In a complex

process such as ship procurement ‘Value or Money’ does not rest solely on the price to deliver a ship.

It can take account o osets, retention o key skills, government industrial strategy and regional

polices. It can look at nancing options, technology transer, etc., all o which will have a bearing on

the nal decision on award o contact. A well developed and managed Evaluation process will aid

the decision making, but there will still be many areas where qualitative proessional judgment is

required in order to arrive at the nal recommendation.

A robust Tender Evaluation Report will support the debrieng o the unsuccessul Tenderers and

can also be a useul starting point with the successul Tenderer too. It supports the philosophy

o Continuous Improvement and will help all parties in the way in which uture programmes are

tackled.

twenty




DESIGN ASSURANCE ANDDESIGN AGENT SERVICES

Larger navies can draw on signicant deence or government specialist support. Smaller naviesmay not have the national inrastructure to support the acquisition o complex ships. Yet the deence

supply industry is consolidating such that it can provide a turnkey service, albeit sometimes with

government support.

In order to ensure that the Customer retains the ‘Intelligent Decider’ role there is a trend towards

navies calling on the services o specialist companies that provide scientic, technical and programme

management skills. Such specialist services are committed to supporting the Customer in areas o

key skills, acilities or available manpower to meet the programme. The provision o Design

Assurance and Design Agent Services will underpin the Customer’s own skills. Design Assurance

will typically involve the provision o proessional services in the eld o Naval Architecture, Marine

and Combat Engineering. It may also need to provide skills in other areas such as Logistics, Human

Engineering, Materials, Saety, and Environmental. The output o Design Assurance will support the

development o a balanced set o Requirements, the development o the Procurement Specication

and Tender Evaluation Criteria, through to support to the Tender Evaluation process itsel.

The provision o Design Assurance may co-ordinate, but could also conduct laboratory or simulation

tests to support the development o Requirements, or Evaluation o bids. Examples being combat

system eectiveness, hydrodynamic estimates, vulnerability assessment, upper deck airfow,

removal routes and complementing. The aim o the Design Assurance provider(s) is to provide

condence to the Customer that what is being sought is compatible with the overall level o risk and

budgets, and also to ensure that the tenders are also capable o being technically delivered.

Once into contract the Design Assurance provider can review deliverables and provide an independent

view into the Customer team. Such support could include attendance at Design Reviews, review o

the design against the Requirements, assessment o the Supplier’s proposed acceptance activities,

and support to technical investigations. The scope o the Design Assurance role is innitely fexible,

and can be tailored precisely to complement the Customer’s own resources.

To understand the role o the Design Agent, it is necessary to establish the nature and scope

o the Ship Design Authority (SDA) role, and where it is to be established. An SDA is generally the

organisation with the authority or making decisions about the ship design and is responsible or ormally

signing o the design, and the achievement o that design, against the contract requirements.

Within the SDA, the overall responsibility or the saety and perormance o the design and the built ship

is normally vested in a single person. The SDA may change as the project progresses rom design

and build towards in-service. Once in service, the SDA is responsible or maintaining the saety and

perormance against the original requirements and design intent. It is also responsible or managing any

changes throughout the lie o the ship to ensure that saety and design intent are not compromised.

twenty one




The SDA must have authority over all technical aspects o the design, and thus provides a high

level ocus or all technical trade-o and risk decisions (against contracted perormance, cost and

programme). The SDA may or may not have management responsibility or the design activities

depending on how the project management team within the Supplier is organised.

A ship project will potentially have a number o hierarchical Design Authorities (DA). In this situation, the

top-level SDA will eectively delegate responsibility (under contract) or the design o the component

parts to other DAs. However, the SDA will always retain direct authority or requirement statements

associated with the component parts and their respective interaces with the rest o the system.

As a contracting principle, the SDA and lower level DAs retain contractual responsibility or their

elements o the ship design in working to meet Contract perormance, costs and programme targets.

A Design Agent is the person (or body) engaged by an SDA to provide proessional services on behal

o the SDA. A Design Agent is normally contracted on the basis o providing Suitably Qualied

and Experienced Personnel who will perorm work to the necessary levels o competence in their

respective areas o specialisation.

In certain circumstances, by contractual agreement, it is possible to partially combine the two roles

o Design Agent and Ship Design Authority whereby the Design Agent may choose to take limited

responsibility or delivering elements o contract perormance, budget or programme. In this situation,

the responsibility is extended to accepting a degree o consequential liability in meeting contract

requirements. E.g., taking partial liability or liquidated damages or ailure to meet a stipulated gure

or ship speed.

Where the Customer is eectively the Ship Design Authority, the role o Design Agent is sometimes

reerred to as the ‘Customer Friend’. In this situation, shared contract liability or meeting perormance

targets is not usually a consideration, although it is possible to develop incentivised arrangements.

For some ship programmes the role o Ship Design Authority remains with the Supplier, while the

overall responsibility or operating, maintenance and saety lies with the Customer (Owner). The

recent moves towards Classication Society Naval Rules will help in the maintenance o the design

intent, but they do not cover all areas o the ship. Each government will have to decide its own

approach to the management o the Ship Design Authority throughout the lie o the ships.

twenty two




CONSTRUCTION ASSURANCE

Construction Assurance should be seen as an integral part o the Programme Management role, and

should adopt a risk based approach. The level and style o Construction Assurance will be dened

within the Programme Strategy documents, and should be embodied within the contract. It will be

dependent on actors such as:

a. The track record o the Supplier;

b. Inormation gained during the tender evaluation phase that showed areas o possible risk;

c. Whether the ship design is proven, or whether it is new and innovative;

d. The build strategy;

e. The location o build, the acilities and the experience o the labour orce;

. The involvement o the Classication Society, and the government’s own maritime

saety authorities; g. The need or progressive acceptance and support to milestone payments;

h. The Customer’s need to train the crews, and/or amiliarise the support teams.

There are a number o approaches to Construction Assurance ranging rom large Customer Teams

in the build yard(s) (United States Navy), to an audit based approach sometimes with only 2-3 sta

within the shipyard (Japanese Maritime Sel Deence Force). Sometimes the Customer will not have

the resources to undertake the assurance role, and so may engage specialist companies who will

act as the Customer’s agent. Some Classication Societies are also now oering assurance services

in addition to their established Classication role.

In negotiating the contract it is necessary or the Customer and Supplier to agree what the assurance

requirements will be and what each party’s obligations are. A risk based assurance plan will be

required, together with guidance on how assurance will be conducted. The aim is to provide

assurance to the Customer that the contract is being satisactorily ullled, and to provide a route

or resolving areas o concern. It is extremely important that the sta undertaking the contract

assurance role are amiliar with the contract, and that they are objective when it comes to assessing

those outputs that are within the Supplier’s area o responsibility.

The Construction Assurance outputs will provide progressive assurance in the verication o the

material state, and can also include the support to Shipbuilder and Original Equipment Manuacturer

(OEM) trials, managing the supply o Government Furnished Equipment/Inormation, resolving issues

locally, dealing with concessions and production permits, and the co-ordination o the ship sta

(designate) activities, and government sponsored visits and attendance. The benets o a positive

approach to Construction Assurance can be signicant, and it will be or the Programme Manager

to decide what scope is required.

twenty three




ACCEPTANCE

Acceptance starts at the very beginning o a programme, and should be seen as a continuous and

progressive activity throughout the whole programme. Lack o a sound approach to Acceptance

will cause major problems at the end o the programme between the Customer and Supplier,

and possibly between the Customer, Sponsor and the User. The key to a successul outcome is

good planning and expectation management exercised through the process o using a Requirement

based approach. Some key steps that will help to avoid problems are:

a. Start the process o getting acceptance rom the beginning o a project. Set the

expectation that at every key step o the process ormal sign-o procedures will be used.

Establishing and communicating an approach early will change the perception o ormal

acceptance rom a major event to just another step in the process;

b. Dene the acceptance criteria very early in the process. The Requirements (User and

System) should all have acceptance criteria, and the contract should state how the

Supplier would demonstrate the achievement. Clearly this is an evolutionary process

and some criteria may change over the course o a project, but it is the process that

is the key to a successul outcome;

c. Develop an Integrated Test Evaluation and Acceptance Plan (ITEAP) describing the

methodology and allowing the achievement o the Requirements to be identied

against the contract specications;

d. The Customer should prepare ormal closure documents collaboratively with both the

Supplier and Sponsor. Initiate the process o creating the documents well in advanceo the ormal closure meetings so that there is time to review, negotiate and revise.

These closure documents may well be signed o at dierent dates dependent on the

overall programme strategy. Both User and stakeholder involvement throughout

will be important;

e. Allow or some sign-os to have caveats, or comments. Because o the progressive

nature o Acceptance, and that there may be inter-links between events, the Customer

may be uneasy about giving ull sign o. As the project progresses the loose ends

will be cleared up. Any signicant unease must be dealt with as it occurs.

The Acceptance Plan should scope not only the tasks contracted to the Supplier, but may also include

downstream acceptance or weapons, communications, ranging etc, or which the Supplier may

not have had ull, or any, contractual responsibility. In addition to the close out o the Requirements

through a ormal Acceptance Plan, there will also be the lower level acceptance o the ship associated

with eatures that were not totally dened within a Requirement. Despite the use o Design Reviews,

Walk Through Models and Simulations, etc., there will invariably be some aspects o the ship that the

Customer is not happy with. These will have to be dealt with as they are identied, and a pragmatic

approach taken to resolving them.

twenty our




There will be occasions when the Customer cannot agree ull Acceptance, but the ship is suciently

completed to continue with downstream programme activities. This will have to be agreed between

the Customer, Supplier and User in light o the overall benets, or risks, to the programme. The status

o each party’s outstanding obligations will have to be careully recorded, as will any impact on the

contact liability.

WARRANTY MANAGEMENT

The warranty period will vary between dierent contracts. Sometimes it will be a straightorward

warranty against deects arising, other options may seek to achieve a set level o availability, or specic

aspect o perormance. The selection o warranty will infuence the price, as the Supplier will need

to hedge the risk. Within the warranty period there will probably be the on-going need to close out

acceptance issues that carried over rom the contract acceptance agreement. These could includeclearing agreed deects and the close out o caveats and conditions to acceptance events.

The Customer and Supplier need to have an agreed process or the close out o pre-warranty actions,

and the management o new warranty claims as they arise. In the warranty period the ship may

be out o area and not available to the Supplier. Ship sta may well be required to undertake

the remedial work using spares provided under the contract. Alternatively a local contractor may

be required to provide assistance to a warranty event, or the Classication Society Surveyor may

become involved. The process must address all likely situations and have people responsible or

making decisions with the inormation available. Inormation capture is important, as this will impact

the downstream agreement o liability and costs. The action taken to correct a problem must be

captured to ensure that the possible implications on saety, operability or subsequent ships are ully

understood. There will be a need to ensure that there is a positive interace with the conguration

management process as documentation, handbooks and spares holdings etc may need to be

updated. The Ship Design Authority may need to be involved i any changes impact on the design

intent, or saety o the ship.

Active warranty management will bring benets to the introduction into service o the rst o class

and ollow on ships.

twenty fve




POST ACCEPTANCE SUPPORT

From the moment o Acceptance there is every likelihood that the Customer will want, or need, to make

changes to the ship. These may embrace equipment to address new threats/roles, obsolescence and

aspects that the Requirements ailed to address adequately. Such changes may require Classication

Society approval, and will have to be reviewed by the Ship Design Authority to ensure that they do not

undermine the design intent o the ship. Over time ships use their margins and weight increases, or

they are required to operate or longer between upkeep periods. Some Customers will manage all o

these in-service activities in-house, while others will retain the Supplier or some or all o these activities.

In some cases a Customer may use an independent specialist to provide a turnkey service (much as a

Design Agent), while still taking overall responsibility or saety and perormance. The turnkey services

will work under the Customer’s direction and to their programme.

The tasks that could be undertaken may cover: a. Development o design drawings to support system and equipment alterations;

b. Submitting change packages or Customer and Classication Society approval;

c. Programme planning or change implementation and upkeep;

d. Costing the programme;

e. Procurement and supply chain management;

. Review o changes against the original Requirements and datum design;

g. Conguration management;

h. Logistics update;

i. Management o the acceptance o changes; j. Surveys and inclining;

k. Technical investigations;

l. Development o trials programmes and management o trials;

m. Maintenance o the datum drawing pack and emergency response pack;

n. Obsolescence management (hardware, sotware and legisative).

Such turnkey contracts can be incentivised against agreed targets, and can be used to identiy ways

o obtaining better overall value in the costs o operating the ships. The most extreme orm o this

service is where the Customer leases the ship rom the Supplier. In this case the Supplier is highly

incentivised to obtain lowest whole lie cost, consistent with oering the Customer best value or

money.

Post-Acceptance Support is an area that each Customer will decide what is required. It can be looked

at as a menu driven approach, with the key aspect being that all choices rom the menu should be

addressed. Where, how and by whom will be at the Customer’s discretion.

twenty six




CLOSING REMARkS

In principle ship programmes are not dissimilar to other major procurements within both government

and commercial sectors. What makes ships especially challenging is that they have to undertake

a wide range o missions in changeable weather and sea conditions, while at the same time being

home and workplace to the crew. These aspects combined with the long service lie, obsolescence

and upgrades demand a structured approach to their procurement, combined with a high level o

communication between all o the involved parties. Achieving best value or money over the Whole

Lie Cycle is a dicult objective to achieve. However, it is believed that the approach described

in this paper will help signicantly in achieving that objective.

twenty seven




AbOUT THE PUbLISHER

bMT Group

BMT Group is an international design, engineering and risk management consultancy, working

principally in the deence, energy and environment, marine risk and insurance, maritime transport

and ports and logistics sectors.

BMT invests signicantly in research. Its customers are served through a network o international

subsidiary companies. The assets are held in benecial ownership or its sta.

www.mt.org

bMT Defence Services

BMT Deence Services is the leading independent centre o naval design excellence and through-lie

support in Europe, with expertise in platorm design or surace warships, submarines and auxiliaries.

A wide range o government and industry customers engaged in the development o technically

complex, highly integrated systems rely on BMT Deence Services or its systems engineering and

inormation systems expertise.

The company is based in Bath and Weymouth in the United Kingdom. It employs over 200 naval

architects, marine engineers, engineering consultants and support sta.

Wesite - www.mtdsl.co.u

COPYRIGHTS AND ACkNOWLEDGEMENTS

© BMT Deence Services Limited 2006. All trade and service marks are the property o their

respective owners. Images are copyright several sources and permission to use is grateully

acknowledged, including © BMT Deence Services Limited; © US Oice o Naval Research;

© Crown Copyright/MOD (Photographs supplied rom www.photos.mod.uk and reproduced with

the permission o the Controller o Her Majesty’s Stationery Oce).

twenty eight

Americas

2120 Washington Boulevard

Suite 200

Arlington

VA 22204-5717, USA

Tel: +1 703 920 7070

Fax: +1 703 920 7177

Europe

Maritime House

210 Lower Bristol Road

Bath

BA2 3DQ, UK

Tel: +44 (0)1225 473 600

Fax: +44 (0)1225 448 714

AsiaPacifc

Level 5, 99 King Street

Melbourne

VIC 3000

Australia

Tel: +61 (0)3 8620 6100

Fax: +61 (0)3 8620 6105

BMT Procurement

Documents