W H I T E PA P E R :

THE PROCUREMENT OF NAVAL

AND GOVERNMENT SHIPS

Abstract

The acquisition of warships, or specialist government ships, is a

complex 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 of 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 of a set of structured
requirements supported by rigorous cost modelling, other aspects
of the approach can be pursued separately. The paper recognises
the wide differences between various national programmes and
seeks to describe a generic approach that can be tailored to meet
a government’s own specific 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 Specification.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Tender Evaluation and Clarification.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

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

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

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

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

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

Closing Remarks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
 T H E P R O C U R E M E N T O F N AVA L A N D G OV E R N M E N T S H I P S

INTRODUCTION
Modern warships are increasingly complex vessels, as are other government ships such as Exclusive
Economic Zone (EEZ) management or oceanographic survey vessels. Buying ‘off the shelf’ will
inevitably require the procuring government to make informed decisions on a wide variety of options.
Larger navies can draw on significant defence or government specialist support. Some navies may
not have the national infrastructure to support the acquisition of complex ships.

This White Paper describes a generic approach to the procurement of 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 different countries have evolved
national procurement systems suited to their own needs. The paper does not rely on adherence to
specific standards and methodologies; it addresses the principles, and recognises that different projects
can ‘mix and match’ the various elements to best meet the Customer’s particular need.

The process of ship procurement is not linear and the sequence of the sections of this paper has
been chosen to best represent the overall methodology. The paper addresses the front-end activities
(Requirements Development, Operational Research, and Programme Costing). These are described
separately, but inevitably they are closely linked. Their outputs will feed into the Procurement
Specification, the Contract and on to the final Acceptance. In reality a number of phases will show
an overlap of activities. This is unavoidable in order to aid the decision-making at the front 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 of increased project timescales, inefficient use of resources, creeping
obsolescence and unavoidable increases in programme costs.

In the same way that reference to specific government procurement methodologies is avoided; so
too is reference to commercial or bespoke software programs, except for a small number of illustrative
examples. The importance of software tools should not be underestimated, as these will provide the
link between the Requirements and Acceptance. Most organisations will have their own preferences
for particular software toolsets, and these should be agreed during the contact negotiation phase.

three
THE PROC U R E M E N T O F N AVA L A N D G OV E R N M E N T S H I P S

The paper has been written with the assumption that the government has a ‘Need’ for the new
ship(s). The ‘Need’ can be defined in quite general terms, or it may be comprehensively described in
terms of the exact ship types, and numbers to be procured.

Whatever; the ‘Need’ is the starting point for the project. In fulfilling the ‘Need’ there will be the active
involvement of the Sponsor, the Customer and the Supplier, and at some stage the operational
duties will fall to the User. There are numerous project management definitions for the above roles.
In some organisations different departments will carry out the roles. In others some of 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 of this White Paper the roles will be
discussed under the following descriptions.

Sponsor… A person, or group, that is responsible for the business case that sets out the
means by which Government strategy is to be achieved through the definition and fulfilment
of the ‘Need’. The Sponsor is the custodian of the business case and overall strategy, and
will work closely with the Customer, User and other Stakeholders.

Customer… The procurement group responsible for acquiring ships that meet the
‘Need’ within the timescale and budgets agreed with the Sponsor. The Customer will
undertake the day-to-day management of the programme and the interface with Suppliers.

Supplier… The company responsible for delivering ships that meet the ‘Need’ as
defined by the Customer’s contract requirements.

User… The authority that will be responsible for operating the ships, thus ensuring that
Government policy defined by the ‘Need’ is fulfilled.

There will be significant interaction during all phases of a ship programme between the above parties
and other interested parties, often collectively referred to as the stakeholders. The intensity of that
interaction will vary between the phases of the life cycle, and this is explained within the paper.

four
 T H E P R O C U R E M E N T O F N AVA L A N D G OV E R N M E N T S H I P S

Developing and Managing

the 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 defined in many ways and their use on a particular project will often be guided
by the corporate governance demands of the organisation procuring the ship(s). The topic is one of
continual evolution as well as reliance on previous experience.

For example, up to the 1980s the norm for Government ships was to develop a detailed technical
specification that effectively fixed the design and subsequent cost and performance; the majority
of the risk being taken by the Customer. The use of Cardinal, or Key Point Specifications turned the
balance through 180 degrees and effectively left the Customer with minimal input.

The 1990s saw the use of structured requirements emanating from the National Aeronautics and
Space Administration (NASA) and European Space Agency. These sought to demarcate between
defining 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 of the System
Requirements may be ‘owned’ by the Customer and the lower levels may be ‘owned’ by the Supplier.
The complexity of some programmes saw an even higher level of requirement being introduced, these
are the Key User Requirements, which then cascade down into User and System Requirements.

Some Defence organisations have now moved away from Requirements and towards Capability
Acquisition. In reality this is another increment in a set of cascaded requirements, and defines the
‘Need’ in a different manner.

To some degree or other, all of the above provide a means of structured and auditable communication
between the Sponsor, Customer and Supplier. The detailed Customer technical specification
approach is successful providing the Customer has the expertise to develop the specification, but it
may not allow the Supplier scope to innovate. It also effectively fixes the majority of the programme
cost, performance and risk within the Customer’s sphere. It can be successful 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 performance.

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

five
THE PROC U R E M E N T O F N AVA L A N D G OV E R N M E N T S H I P S

The Cardinal, or Key Point Specification reverses that position and with its higher level of definition
is most suited for simpler projects probably based on Military (MOTS) and/or Commercial Off The
Shelf (COTS) solutions.

So where does that leave us? Well, for any project to proceed a Sponsor must have a ‘Need’. Suitably
defined by the Customer in consultation with the future End Users, this will eventually form the basis
of an Offer from one or more prospective Suppliers. The Requirement based approach is now
generally recognised as the most suitable for the use in a government contracting scenario where
there is a defined ‘Need’, and the Supplier has the skill and resources to provide a solution to fulfil
that ‘Need’.

Requirements Definition is probably the most crucial part of the project. Incorrect, inaccurate, or
excessive definition of requirements must necessarily result in schedule delays, wasted resources, or
Customer dissatisfaction. The Requirements Analysis should begin with business or organisational
requirements and translate these into project requirements. If 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 of requirements analysis methods will quickly become specific to the type of project
involved. Many industry areas have specific, proven techniques for obtaining thorough and accurate
definition of requirements. Sometimes it is useful to write a ‘Concept of Operations’ (CONOPS)
paper and/or a ‘Concept of Use’ paper as a way to aid the development of requirements.

A CONOPS paper addresses how the new ships will operate alone or as part of a task force, and
in the context of the missions and tasks they are expected to undertake. A Concept of Use paper
would address how the internal organisation of the ship functions during specific operations. For
example, the Concept of Use paper for an amphibious warfare ship could describe how the
embarked force would muster their personal kit, weapons and stores through debarkation and
eventual re-embarkation. Such a paper informs the Requirements developers and designers and
aids the wider understanding of specialist subjects.

While the methods may differ, the principles remain the same across all types and sizes of projects.
The Requirements Analysis should cover the whole scope of the project, i.e., ship performance,
software, logistics, project management, safety, environment, human resources, test and acceptance,
etc.. It must be comprehensive and thorough and it must consider the views and needs of all the
stakeholders.

Using a Requirements based approach allows the Sponsor (and Customer) to control technical
developments without necessarily needing to know the full complexities of the solutions. It will also
provide a logical basis for maintenance of the design intent and change management throughout
the whole life cycle. It also ensures that stakeholder inputs and priorities are identified early.
Constructing an early set of User Requirements is essentially a modelling activity; taking the further

six
 T H E P R O C U R E M E N T O F N AVA L A N D G OV E R N M E N T S H I P S

step of defining System Requirements allows the modelling of abstract solutions. It is quite acceptable
to develop a conceptual design, but this is very much an early breadboard for visualising the potential
results of the requirements set, and for testing budgets.

Defining User Requirements is a key task and requires a systematic approach. Generally the following
steps can describe it:
a. Draft requirements capture exercise using interviews, workshops, analogous
systems, feedback reports, modelling and simulation, and existing solutions;
b. Involvement of Users and Stakeholders to maximum extent possible;
c. Ensure that the requirements are quantifiable and measurable;
d. Prioritise requirements by importance early in the exercise;
e. Allow margin for requirements growth;
f. Establish a process for change management;
g. Define requirements for all aspects of the programme;
h. Re-iterate the requirement set and re-validate a number of times during the
early programme phases.

It is essential to have a management system for User Requirements and the linkages to System
Requirements, and then through to the eventual design specifications through to the formal Acceptance
activities.

There are numerous ways in which this can be achieved. The simplest management tool is the
spreadsheet; greater capability is offered by industry standard packages such as Telelogic’s DOORS®
and IBM® ’s Rational® RequisitePro® . These more powerful tools provide interfaces with other
industry standard software that will allow archiving, video, Computer-Aided Design (CAD) visualisations,
update of programme management and planning information, and even risk, safety and environmental
management information.

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 form the basis of the contract and its acceptance, and they can then
be used to manage support of the ships through life.

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

Requirements is an iterative exercise such that the developing Requirements are tested against the
programme budgets and timescales, in order to establish the degree of risk that may be presented.
This can be undertaken using Operational Research supported by Whole Life Cost Modelling.
As each iteration is completed the results will be analysed and the Requirements reviewed, and
probably re-cast until the overall balance of performance, cost and timescale is within the programme
budget. This process of iteration will involve the Sponsor, Customer, User and stakeholders, and
may also extend to potential Supplier(s).

seven
THE PROC U R E M E N T O F N AVA L A N D G OV E R N M E N T S H I P S

Operational Research
Developed during World War 2 in Great Britain and the USA, Operational Research applies scientific
techniques to analyse the behaviour of 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 specific elements. Operational Research at its widest use is the application of
the methods of 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 of examining the current and historical performance of systems
and measuring that performance against a set of parameters, or effectiveness measures. It is
creative in nature, and should trigger considerations of how the objectives could be better met, how
costs could be saved, and whether, indeed, that particular organisation should even be performing
a given function at all.

Operational Research should demonstrate that there has been a thorough examination of the need
for the investment, the performance being achieved by the investment, the advisability of continuing
the investment, and alternative methods of achieving the same investment results. The comparison
and analysis of the results achieved by Operational Research and Programme Costing can be
combined into an activity known as a Combined Operational Effectiveness and Investment Appraisal
(COEIA) study.

Examples where Operational Research will support the decision making process for 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 of the same
type, a mix of types or even by using manned aircraft, or unmanned vehicles;
c. Consideration of geographic and environmental aspects to support the required
sea-days for deployed capability of the different platform types being considered;
d. Comparisons looking at weapon types, munitions quantities, sensors and
the comparative advantages of hard versus soft kill;
e. Military operations involving the ‘new ships’ and other force elements including
land, air and allied nations;
f. Integrating the logistic support facilities and support requirements for the ship types and
numbers being considered. This could address the need to upgrade bases, increased use
of contractor support and the logistic costs for support against a desired level of availability;
g. Interfaces with information 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 of the different procurement options.

2 Operational Research is known as OA, for Operational Analysis, within the UK military and Ministry of Defence to avoid confusion
with OR, which is taken to mean Operational Requirements

eight
 T H E P R O C U R E M E N T O F N AVA L A N D G OV E R N M E N T S H I P S

A major benefit of Operational Research is that it allows many different options to be considered
in a systematic and auditable manner. It allows unattractive options to be justifiably 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 of data, with
time-consuming computer runs. The capability of spreadsheets and databases has led to the
development of commercial software, or bespoke packages that will run efficiently 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 from 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
THE PROC U R E M E N T O F N AVA L A N D G OV E R N M E N T S H I P S

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 3 Program Manager 2001 ”
From the very onset of a programme there is a need for cost estimating; how else will the overall
budget be set?

Initially the budget will be set by the results from 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 of activities to set the initial high-level budgets. Then as the programme moves along its early
phases the budgets will be refined in line with the developing requirements and the outputs of the
Operational Research. This refinement will support the business case submissions for 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 of the whole programme budget, and that
more than two thirds of whole life costs are fixed by the time that Definition has completed, it can be
seen that the often limited funds expended during the early programme phases fix the vast majority
of the whole life programme costs (Production, Operating and Disposal). While these figures
are necessarily broad they do indicate that if attention is not paid to whole life costs early in the
programme, as the programme extends there will be a significant risk of major delays caused by
budget versus performance problems.

Programme costing studies may address a number of specific areas, such as:
a. Research Balance of Investment;
b. Cost Capability Trade Off;
c. Future Expenditure Plans;
d. Acquisition Strategy alternatives;
e. Investment Appraisal;
f. Risk quantification;
g. Related equipment programmes;
h. Platforms 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
 T H E P R O C U R E M E N T O F N AVA L A N D G OV E R N M E N T S H I P S

Informing 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 feed into the development of
Requirements and support the Operational Research. The level to which any of the cost studies,
Requirements or Operational Research is conducted will be dependent on the complexity of the
Programme and the Customer’s own preferences. 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 interfaces and
linkages exist between them.

A typical package of work for cost modelling would be:

a. Provide a baseline (independent estimate) against which different User Requirement sets
can be analysed in order to allow the Customer to decide on the best way forward.
The cost drivers can be identified 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 life costs. The outputs can
also be used to support business case submissions, and subsequently to allow tenders
to be compared;

b. Identify gaps in the tenders and the likely costs of filling those gaps. A typical example
would be the provision of an adequate support package (spares, documentation and
training). Another area could be infrastructure, i.e., shore based facilities required to
operate and maintain the vessels. The tenders may not cover this, but it would be
a real cost to the programme;

c. Identify 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
for the Customer’s risk assessment.

Trade off studies can be as simple or as complex as required to meet the needs of a particular
programme. There are well-publicised examples of complex studies relating to the US National
Missile Defence debate to the more technically biased European Space Agency’s Aurora programme
studies into optical links versus radio frequency communications links from spacecraft.

The cost estimate should be built up using a proven cost model to estimate the build and whole life
cost estimates. This cost model could be structured around the UK Ministry of Defence Def Stan
08–140, Classification of weight groups for surface warships, or the similar US Department of
Defense MIL-HDBK 881.

eleven
THE PROC U R E M E N T O F N AVA L A N D G OV E R N M E N T S H I P S

These sub-divide the ship into the one-digit areas shown in Table 1. Each group is further broken
down into two-digit (major systems) and three-digit (major equipments) for cost estimating purposes.
The advantage of this structure is that all the items are fully defined and ship designers routinely use
it. All estimates would normally be broken down as labour hours and material cost. To the estimates
of build cost would be added other programme costs (non-recurring costs, such as design, overall
management of the programme, and facilities, etc.) with costs profiled over time to assess the
reasonableness of any proposed financial plans.

Cost modelling studies often require access to commercially sensitive information such as the potential
Tenderers’ estimated prices, the labour resources, facility 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 benefits and outputs of cost modelling will be:

a. Increased confidence in the cost estimates for the programme and as a
consequence a more robust business case for approval to proceed. This is a
major benefit when aiming to achieve an affordable programme that best meets
the Requirements;
b. Support to trade-off studies. Initially this could be a list of cost drivers, i.e., the major
candidate areas for any cost reduction work. This could be extended, dependent
on the scale and need for trade off;
c. Information on those cost requirements that will be included within a Procurement
Specification so that all Tenderers are required to respond with the same level
and format of information;
d. A Customer-owned cost estimate for the programme at a level of detail sufficient to
support trade off studies. This estimate is likely to be far 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 of the estimates or prices supplied by Tenderers. This assessment
would identify any anomalies in the estimates (omissions or overpricing) and seek
to compare each estimate on a common basis;
f. A risk register, defining and quantifying the risks identified in the programme.

Cost modelling and estimating are specialist skills and, as with the Requirement Development and
Operational Research, there are a variety of software tools to support studies. These range from Excel
spreadsheets with Visual Basic interfaces to support graphical output, to bespoke models developed
to meet specific needs. Having a toolset that interfaces 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 meaningful interpretation of the data.

twelve
 T H E P R O C U R E M E N T O F N AVA L A N D G OV E R N M E N T S H I P S

Table 1: Typical Classification of Weight Groups for a Warship

Group Item Areas covered Comment

1 Hull Hull, superstructure, structural Both labour and materials

bulkheads, decks, doors & generally estimated on a
hatches, seats & masts, control cost/tonne basis
surfaces, castings & forgings,
ballast, fastenings

2 Propulsion Propulsion units & control Usually estimated at major

equipment, shafting & bearings, equipment level, with some
intakes & uptakes, cooling & minor areas costed by weight,
feed water, fuel 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 Control and 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, fuel transfer, sea & fresh HVAC and all pipe work systems.
Systems water, air & gas, hydraulics, This group also includes aircraft
aircraft, waste disposal, lub oil. systems (sub group 55).

6 Outfit and General fittings, boats & lifesaving, Paint coverings are normally the
Furnishings partitions linings & coverings, dominant cost in this weight
storerooms, living spaces, offices group.
& medical, galleys, laundries,
workshops, portable fire fighting,
RAS gear.

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

as part of Group 4. NOTE – does not include the
cost of munitions.

8 Variable load Fuel, stores, etc. – not costed

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

Construction jigs, etc.), drawing office (support to (primarily management and
Services production), management services drawing office support)
(management, planning, estimating, plus misc. costs
QA, etc.), testing, ad hoc support Worst case, white collar can
(e.g., temporary services), sundries be 25% of the blue-collar and
(travel), disbursements hence a cost driver.
(e.g., insurance).

thirteen
THE PROC U R E M E N T O F N AVA L A N D G OV E R N M E N T S H I P S

Programme Management
The term ‘Programme Management’ has been used in preference to Project Management as for
most government ship acquisition endeavours there are a number of inter-related projects being
managed under a single Programme Leader, viz the ships, the combat systems, information
systems/technology infrastructure, support and base facilities, training schools, etc. However,
for the purpose of 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 of managing a portfolio of multiple ongoing inter-dependent

projects. In an organisation Programme Management also reflects the emphasis on coordinating
and prioritising resources across projects, departments and entities to ensure that resource conflict
is managed from a global perspective.

Programme management provides a layer above project management and focuses on selecting
the best group of programmes, defining them in terms of their constituent projects and providing an
infrastructure where projects can be run successfully.

Project Management is the discipline of defining and achieving targets while optimising the use
of resources over the course of a project. Project Management is quite often the province and
responsibility of an individual project manager. In contrast to on-going functional work, a project is a
finite set of activities undertaken to deliver a specific product or service. The duration of a project is
the time from its start to its completion, which in the case of ship programmes can encompass the
whole life cycle from Concept through to Disposal.

Project Management is composed of several different types of activities such as:

a. Defining the objectives;
b. Developing the requirements;
c. Planning the work;
d. Assessing risk;
e. Estimating resources;
f. 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.

fourteen
 T H E P R O C U R E M E N T O F N AVA L A N D G OV E R N M E N T S H I P S

The Programme and individual Project Managers are required to keep the following four variables
under control: time, cost, quality (Requirements scope and performance) 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 of advice
as the Project Management Institute ‘Project Management Book of Knowledge’. However, most
government agencies and Suppliers will have their own preferred approach.

It is important not to foist unfamiliar 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 information to support their own management and reporting needs.

The cost of Programme Management activities will be dependent on the complexity and risk of the
overall programme, but all should contain some key features viz:
a. The core of the Programme/Project(s) will be the User Requirements, and possibly a
Customer developed set of System Requirements. These will cover all aspects of the
Programme (Performance, Logistics, Programme Management, Commercial, etc.);
b. The structured and hierarchical set of Requirements will form the input to a
Work Breakdown Structure (WBS);
c. The WBS allows all activities to be described in terms of 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 information transfer
between the parties;
f. An effective Change Management process linked back to the Requirements and WBS,
and which can keep up with the programme timescales for decision-making;
g. An effective 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 facets of Programme Management such as Partnering, Capability Maturity Model
Integration, Shared Data Environments and Earned Value Analysis, etc. The scope and level of Programme
Management activities for the Supplier will differ from those of the Customer, but the parties will agree the
areas that need to be seen as information interfaces between the two organisations. In this overall area
the Customer may decide to supplement the in-house skills and resources via support from specialist
companies to better allow the Customer to match the overall workload of a varying programme.

fifteen
THE PROC U R E M E N T O F N AVA L A N D G OV E R N M E N T S H I P S

Procurement specification
When governments procure ships the expectation is for them to be available at a defined time and to
be capable of fulfilling their role at the lowest cost of ownership. Ship programmes are characterised
by generally being low frequency, high complexity, high value and strategic. Apart from a straight ‘Build
to Print’ activity, the style and content of the Procurement Specification will emanate from the selected
Procurement Strategy, and this itself will be governed by factors such as government policy, type of
programme, and the supplier base. Factors that may have to be taken account of 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 of would-be Suppliers;
f. Number of the ships required and timescale;
g. Technological complexity of ships and development needs;
h. Knowledge and resources of government team;
i. Use of specialists to support government;
j. Is it a ship, or service being procured?
k. Government finances and budgetary constraints.

There are differences in the approach used by governments and commercial ship owners when it
comes to procuring ships, although there are some common facets:
a. The ‘Need’ has to be defined and approved;
b. There will be an information-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 information;
d. Supplier information will be sought against Requests For Quotation, Requests For
Information, or Requests For Proposal;
e. The Procurement Specification will be developed during this period such that Suppliers
too can have visibility and provide inputs;
f. A Pre-Qualification assessment may be undertaken to allow the Government to
short-list the Suppliers.

The activities arising from the above allow both the Customer and potential Supplier(s) to develop
their overall understanding of the programme, and to better understand the risks. The Procurement
Specification will be progressively developed during this period. Generally Procurement Specifications
address the Requirements for the project (Performance, Programme Management, Logistic and
Acceptance etc) but not the Commercial and Financial contract Terms and Conditions. Examples
of Procurement Specifications are available from Government Departments, Professional Societies,
specialist consultancies and past acquisition programmes. The Programme Manager will decide
style, format and content for the Procurement Specification.

sixteen
 T H E P R O C U R E M E N T O F N AVA L A N D G OV E R N M E N T S H I P S

The Procurement Specification is an intrinsic part of the process of 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 of the overall process and should address the following:
a. It should ensure that Tender Evaluation would be conducted in a systematic,
objective and auditable manner such that decisions can be justified;
b. It should ensure full carry through of 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 Specification being issued;
d. It should be a formally controlled document;
e. It should be capable of being broken down for distribution to the Tender Evaluation Team;
f. It should allow for rapid filtering of tenders such that unsatisfactory tenders can be
put aside, and the decision justified;
g. It should allow for the value (for money) to be evaluated and not just price alone;
h. Its compatibility with Tender Evaluation software (if being used) should be established;
i. It should ensure that like for like comparisons can be made between tenders. Examples
being the labour resources available to build ships in the stated timescale, or to allow
comparison of Whole Life Cost between tenders?
j. It should be structured to aid the generation of reports supporting investment decisions,
and hence will reduce the workload on the Customer team, while still ensuring
full auditability.

The effort expended in developing a cohesive Procurement Specification will bring benefits both
during the Tender Evaluation and Negotiation phases, as well as during the Contract Execution
phase. Like all of the other aspects of an acquisition programme it must be tailored to be compatible
with the complexity and risk of the overall programme. It may be possible to use the developing
Procurement Specification to ‘price’ the Project based on industry feedback, or by independent
review of ‘Should Cost’ estimates.

seventeen
THE PROC U R E M E N T O F N AVA L A N D G OV E R N M E N T S H I P S

Tender Evaluation and clarification

Given a Procurement Specification that captures the Requirements, and that has an associated set
of 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
Specification 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 of 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 information and evaluation should be kept separate from the other aspects of
the evaluation. This ensures that early knowledge of price does not prejudice the objective evaluation
of other information provided by the Tenderers in response to the ITT.

The Evaluation Team may well comprise a number of Panels, i.e., Ship Platform, Combat System,
Shipbuilder, Logistic Support, Cost Analysis, Commercial and Finance. Some of 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 of the Tender
Evaluation process thus freeing the Team to concentrate on the actual evaluation of the tenders.
The Tender Evaluation Team will be seeking the following generic types of evidence:
a. Does the proposal fulfil the aims/objectives of the project?
b. Will it meet the needs of the User?
c. Is there evidence of innovative practice and/or thinking?
d. Have they undertaken similar project(s) in the past?
e. Were the projects successfully implemented?
f. Is there evidence that they have knowledge of the subject areas?
g. Does the Tenderer’s project team have experience of 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 of work?

eighteen
 T H E P R O C U R E M E N T O F N AVA L A N D G OV E R N M E N T S H I P S

Some organisations will provide the Tenderers with details of the Evaluation process and also some
information on key weightings; this can be helpful to both parties. The Evaluation must be done on
the basis of the tenders submitted and not on any extraneous information known or received unless
that information is received as clarification of a point raised with a Tenderer. Care must be taken
during the evaluation phase to treat the tenders, as commercial-in-confidence. 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 of the Tender Evaluation Plan, and it is under the
Programme Manager’s discretion if these are to be evaluated separately.

Non-compliant tenders should only come into consideration after the evaluation of compliant tenders
has identified a front-runner against which it can be compared. A non-compliant tender can be
dismissed for many reasons (for example, that the idea is considered unworkable; it is below an
acceptable standard; it offers no advantage to the Specification as issued; or it involves unacceptable
risks). A non-compliant tender should not be accepted if the other Tenderers could equally well have
priced the proposal had they known that it would be given consideration. If this was the case, it would
call into question the wording of the original Procurement Specification and the other Tenderers should
be invited to submit their corresponding offer.

Where a tender is ambiguous, or where the conditions set out in the ITT otherwise allow, the Evaluation
Team may seek to clarify with the Tenderer. Assumptions must not be made to fill in gaps in a tender.
If the tender is not clear in any aspect, clarification must be sought and recorded in writing. In some
cases it may be desirable to ask each of the Tenderers to give a presentation on their tender. It may
be appropriate to arrange site visits for a complicated, multi-disciplinary activity such as a ship
procurement programme. Information received at such presentations must be documented and can
be used in clarification. Tenderers must be treated equally and fairly in respect of the opportunity to
give a presentation and the exchange of information arising out of submitted tenders.

nineteen
THE PROC U R E M E N T O F N AVA L A N D G OV E R N M E N T S H I P S

Clarification must be completed before the Tender Evaluation Report is finalised, so that tenders can
be properly ranked. While the basis for pricing may be clarified, there must be no negotiation in relation
to the overall price submitted by a Tenderer. If 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 of
a ‘Revise and Confirm’ approach where there are still potential changes to the tender, or by ‘Best
and Final’, where no further negotiation is envisaged. As a result of the evaluation the Tenderers will
be ranked in value-for-money order. Sensitivity analysis should be carried out where appropriate to
verify the ranking where the selection is close. The rankings must be justifiable on the basis of the
evaluation criteria that support the value for money recommendation.

The Tender Evaluation Report documents the way in which the tenders were evaluated, the
assessment of the tenders, the resulting ranked list of tenders and makes a recommendation to the
decision authority. It must also identify any tenders that are unacceptable. It is an important record
for any future review of how the tendering process was conducted and will be an important tool
in debriefing the Tenderers. The report must be based on demonstrable evidence and the
final recommendation should have been base lined using a sensitivity analysis. It should show the
strengths and weaknesses of all tenders evaluated and should contain factual and demonstrable
evidence. If there was not a clear winner how does the report justify the recommendation to proceed?
Is there a basis for 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
of 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 for longer until a clear winner is identified.

What the Customer is looking to achieve is best value for money in fulfilling the ‘Need’. In a complex
process such as ship procurement ‘Value for Money’ does not rest solely on the price to deliver a ship.
It can take account of offsets, retention of key skills, government industrial strategy and regional
polices. It can look at financing options, technology transfer, etc., all of which will have a bearing on
the final decision on award of contact. A well developed and managed Evaluation process will aid
the decision making, but there will still be many areas where qualitative professional judgment is
required in order to arrive at the final recommendation.

A robust Tender Evaluation Report will support the debriefing of the unsuccessful Tenderers and
can also be a useful starting point with the successful Tenderer too. It supports the philosophy
of Continuous Improvement and will help all parties in the way in which future programmes are
tackled.

twenty
 T H E P R O C U R E M E N T O F N AVA L A N D G OV E R N M E N T S H I P S

Design Assurance and

Design Agent Services
Larger navies can draw on significant defence or government specialist support. Smaller navies
may not have the national infrastructure to support the acquisition of complex ships. Yet the defence
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 of specialist companies that provide scientific, technical and programme
management skills. Such specialist services are committed to supporting the Customer in areas of
key skills, facilities or available manpower to meet the programme. The provision of Design
Assurance and Design Agent Services will underpin the Customer’s own skills. Design Assurance
will typically involve the provision of professional services in the field of Naval Architecture, Marine
and Combat Engineering. It may also need to provide skills in other areas such as Logistics, Human
Engineering, Materials, Safety, and Environmental. The output of Design Assurance will support the
development of a balanced set of Requirements, the development of the Procurement Specification
and Tender Evaluation Criteria, through to support to the Tender Evaluation process itself.

The provision of Design Assurance may co-ordinate, but could also conduct laboratory or simulation
tests to support the development of Requirements, or Evaluation of bids. Examples being combat
system effectiveness, hydrodynamic estimates, vulnerability assessment, upper deck airflow,
removal routes and complementing. The aim of the Design Assurance provider(s) is to provide
confidence to the Customer that what is being sought is compatible with the overall level of risk and
budgets, and also to ensure that the tenders are also capable of 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 of
the design against the Requirements, assessment of the Supplier’s proposed acceptance activities,
and support to technical investigations. The scope of the Design Assurance role is infinitely flexible,
and can be tailored precisely to complement the Customer’s own resources.

To understand the role of the Design Agent, it is necessary to establish the nature and scope
of the Ship Design Authority (SDA) role, and where it is to be established. An SDA is generally the
organisation with the authority for making decisions about the ship design and is responsible for formally
signing off the design, and the achievement of that design, against the contract requirements.

Within the SDA, the overall responsibility for the safety and performance of the design and the built ship
is normally vested in a single person. The SDA may change as the project progresses from design
and build towards in-service. Once in service, the SDA is responsible for maintaining the safety and
performance against the original requirements and design intent. It is also responsible for managing any
changes throughout the life of the ship to ensure that safety and design intent are not compromised.

twenty one
THE PROC U R E M E N T O F N AVA L A N D G OV E R N M E N T S H I P S

The SDA must have authority over all technical aspects of the design, and thus provides a high
level focus for all technical trade-off and risk decisions (against contracted performance, cost and
programme). The SDA may or may not have management responsibility for the design activities
depending on how the project management team within the Supplier is organised.

A ship project will potentially have a number of hierarchical Design Authorities (DA). In this situation, the
top-level SDA will effectively delegate responsibility (under contract) for the design of the component
parts to other DAs. However, the SDA will always retain direct authority for requirement statements
associated with the component parts and their respective interfaces with the rest of the system.

As a contracting principle, the SDA and lower level DAs retain contractual responsibility for their
elements of the ship design in working to meet Contract performance, costs and programme targets.

A Design Agent is the person (or body) engaged by an SDA to provide professional services on behalf
of the SDA. A Design Agent is normally contracted on the basis of providing Suitably Qualified
and Experienced Personnel who will perform work to the necessary levels of competence in their
respective areas of specialisation.

In certain circumstances, by contractual agreement, it is possible to partially combine the two roles
of Design Agent and Ship Design Authority whereby the Design Agent may choose to take limited
responsibility for delivering elements of contract performance, budget or programme. In this situation,
the responsibility is extended to accepting a degree of consequential liability in meeting contract
requirements. E.g., taking partial liability for liquidated damages for failure to meet a stipulated figure
for ship speed.

Where the Customer is effectively the Ship Design Authority, the role of Design Agent is sometimes
referred to as the ‘Customer Friend’. In this situation, shared contract liability for meeting performance
targets is not usually a consideration, although it is possible to develop incentivised arrangements.

For some ship programmes the role of Ship Design Authority remains with the Supplier, while the
overall responsibility for operating, maintenance and safety lies with the Customer (Owner). The
recent moves towards Classification Society Naval Rules will help in the maintenance of the design
intent, but they do not cover all areas of the ship. Each government will have to decide its own
approach to the management of the Ship Design Authority throughout the life of the ships.

twenty two
 T H E P R O C U R E M E N T O F N AVA L A N D G OV E R N M E N T S H I P S

Construction Assurance
Construction Assurance should be seen as an integral part of the Programme Management role, and
should adopt a risk based approach. The level and style of Construction Assurance will be defined
within the Programme Strategy documents, and should be embodied within the contract. It will be
dependent on factors such as:
a. The track record of the Supplier;
b. Information gained during the tender evaluation phase that showed areas of possible risk;
c. Whether the ship design is proven, or whether it is new and innovative;
d. The build strategy;
e. The location of build, the facilities and the experience of the labour force;
f. The involvement of the Classification Society, and the government’s own maritime
safety authorities;
g. The need for progressive acceptance and support to milestone payments;
h. The Customer’s need to train the crews, and/or familiarise the support teams.

There are a number of approaches to Construction Assurance ranging from large Customer Teams
in the build yard(s) (United States Navy), to an audit based approach sometimes with only 2-3 staff
within the shipyard (Japanese Maritime Self Defence 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 Classification Societies are also now offering assurance services
in addition to their established Classification role.

In negotiating the contract it is necessary for 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 satisfactorily fulfilled, and to provide a route
for resolving areas of concern. It is extremely important that the staff undertaking the contract
assurance role are familiar with the contract, and that they are objective when it comes to assessing
those outputs that are within the Supplier’s area of responsibility.

The Construction Assurance outputs will provide progressive assurance in the verification of the
material state, and can also include the support to Shipbuilder and Original Equipment Manufacturer
(OEM) trials, managing the supply of Government Furnished Equipment/Information, resolving issues
locally, dealing with concessions and production permits, and the co-ordination of the ship staff
(designate) activities, and government sponsored visits and attendance. The benefits of a positive
approach to Construction Assurance can be significant, and it will be for the Programme Manager
to decide what scope is required.

twenty three
THE PROC U R E M E N T O F N AVA L A N D G OV E R N M E N T S H I P S

ACCEPTANCE
Acceptance starts at the very beginning of a programme, and should be seen as a continuous and
progressive activity throughout the whole programme. Lack of a sound approach to Acceptance
will cause major problems at the end of the programme between the Customer and Supplier,
and possibly between the Customer, Sponsor and the User. The key to a successful outcome is
good planning and expectation management exercised through the process of using a Requirement
based approach. Some key steps that will help to avoid problems are:

a. Start the process of getting acceptance from the beginning of a project. Set the
expectation that at every key step of the process formal sign-off procedures will be used.
Establishing and communicating an approach early will change the perception of formal
acceptance from a major event to just another step in the process;

b. Define 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 of a project, but it is the process that
is the key to a successful outcome;

c. Develop an Integrated Test Evaluation and Acceptance Plan (ITEAP) describing the
methodology and allowing the achievement of the Requirements to be identified
against the contract specifications;

d. The Customer should prepare formal closure documents collaboratively with both the
Supplier and Sponsor. Initiate the process of creating the documents well in advance
of the formal closure meetings so that there is time to review, negotiate and revise.
These closure documents may well be signed off at different dates dependent on the
overall programme strategy. Both User and stakeholder involvement throughout
will be important;

e. Allow for some sign-offs to have caveats, or comments. Because of the progressive
nature of Acceptance, and that there may be inter-links between events, the Customer
may be uneasy about giving full sign off. As the project progresses the loose ends
will be cleared up. Any significant 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 for weapons, communications, ranging etc, for which the Supplier may
not have had full, or any, contractual responsibility. In addition to the close out of the Requirements
through a formal Acceptance Plan, there will also be the lower level acceptance of the ship associated
with features that were not totally defined within a Requirement. Despite the use of Design Reviews,
Walk Through Models and Simulations, etc., there will invariably be some aspects of the ship that the
Customer is not happy with. These will have to be dealt with as they are identified, and a pragmatic
approach taken to resolving them.

twenty four
 T H E P R O C U R E M E N T O F N AVA L A N D G OV E R N M E N T S H I P S

There will be occasions when the Customer cannot agree full Acceptance, but the ship is sufficiently
completed to continue with downstream programme activities. This will have to be agreed between
the Customer, Supplier and User in light of the overall benefits, or risks, to the programme. The status
of each party’s outstanding obligations will have to be carefully recorded, as will any impact on the
contact liability.

WARRANTY MANAGEMENT
The warranty period will vary between different contracts. Sometimes it will be a straightforward
warranty against defects arising, other options may seek to achieve a set level of availability, or specific
aspect of performance. The selection of warranty will influence 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 from the contract acceptance agreement. These could include
clearing agreed defects and the close out of caveats and conditions to acceptance events.

The Customer and Supplier need to have an agreed process for the close out of pre-warranty actions,
and the management of new warranty claims as they arise. In the warranty period the ship may
be out of area and not available to the Supplier. Ship staff 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 Classification Society Surveyor may
become involved. The process must address all likely situations and have people responsible for
making decisions with the information available. Information capture is important, as this will impact
the downstream agreement of liability and costs. The action taken to correct a problem must be
captured to ensure that the possible implications on safety, operability or subsequent ships are fully
understood. There will be a need to ensure that there is a positive interface with the configuration
management process as documentation, handbooks and spares holdings etc may need to be
updated. The Ship Design Authority may need to be involved if any changes impact on the design
intent, or safety of the ship.

Active warranty management will bring benefits to the introduction into service of the first of class
and follow on ships.

twenty five
THE PROC U R E M E N T O F N AVA L A N D G OV E R N M E N T S H I P S

POST ACCEPTANCE SUPPORT

From the moment of 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 failed to address adequately. Such changes may require Classification
Society approval, and will have to be reviewed by the Ship Design Authority to ensure that they do not
undermine the design intent of the ship. Over time ships use their margins and weight increases, or
they are required to operate for longer between upkeep periods. Some Customers will manage all of
these in-service activities in-house, while others will retain the Supplier for some or all of 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 for safety and performance. The turnkey services
will work under the Customer’s direction and to their programme.

The tasks that could be undertaken may cover:

a. Development of design drawings to support system and equipment alterations;
b. Submitting change packages for Customer and Classification Society approval;
c. Programme planning for change implementation and upkeep;
d. Costing the programme;
e. Procurement and supply chain management;
f. Review of changes against the original Requirements and datum design;
g. Configuration management;
h. Logistics update;
i. Management of the acceptance of changes;
j. Surveys and inclining;
k. Technical investigations;
l. Development of trials programmes and management of trials;
m. Maintenance of the datum drawing pack and emergency response pack;
n. Obsolescence management (hardware, software and legisative).

Such turnkey contracts can be incentivised against agreed targets, and can be used to identify ways
of obtaining better overall value in the costs of operating the ships. The most extreme form of this
service is where the Customer leases the ship from the Supplier. In this case the Supplier is highly
incentivised to obtain lowest whole life cost, consistent with offering the Customer best value for
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 from the menu should be
addressed. Where, how and by whom will be at the Customer’s discretion.

twenty six
 T H E P R O C U R E M E N T O F N AVA L A N D G OV E R N M E N T S H I P S

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 of 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 life, obsolescence
and upgrades demand a structured approach to their procurement, combined with a high level of
communication between all of the involved parties. Achieving best value for money over the Whole
Life Cycle is a difficult objective to achieve. However, it is believed that the approach described
in this paper will help significantly in achieving that objective.

twenty seven
THE PROC U R E M E N T O F N AVA L A N D G OV E R N M E N T S H I P S

About the Publisher

BMT Group
BMT Group is an international design, engineering and risk management consultancy, working
principally in the defence, energy and environment, marine risk and insurance, maritime transport
and ports and logistics sectors.
BMT invests significantly in research. Its customers are served through a network of international
subsidiary companies. The assets are held in beneficial ownership for its staff.
www.bmt.org

BMT Defence Services

BMT Defence Services is the leading independent centre of naval design excellence and through-life
support in Europe, with expertise in platform design for surface warships, submarines and auxiliaries.
A wide range of government and industry customers engaged in the development of technically
complex, highly integrated systems rely on BMT Defence Services for its systems engineering and
information 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 staff.
Website - www.bmtdsl.co.uk

COPYRIGHTS AND ACKNOWLEDGEMENTS

© BMT Defence Services Limited 2006. All trade and service marks are the property of their
respective owners. Images are copyright several sources and permission to use is gratefully
acknowledged, including © BMT Defence Services Limited; © US Office of Naval Research;
© Crown Copyright/MOD (Photographs supplied from www.photos.mod.uk and reproduced with
the permission of the Controller of Her Majesty’s Stationery Office).

Americas Europe Asia Pacific
2120 Washington Boulevard Maritime House Level 5, 99 King Street
Suite 200 210 Lower Bristol Road Melbourne
Arlington Bath VIC 3000
VA 22204-5717, USA BA2 3DQ, UK Australia

Tel: +1 703 920 7070 Tel: +44 (0)1225 473 600 Tel: +61 (0)3 8620 6100
Fax: +1 703 920 7177 Fax: +44 (0)1225 448 714 Fax: +61 (0)3 8620 6105

twenty eight