D-CDF: ADAPTING ESA'S CONCURRENT DESIGN FACILITY FOR USE IN THE
DEFENCE SECTOR
James A. White (1), Sam Gerené (2)
(1)
The Defence Innovation Greenhouse, Veurseweg 42, 2252AB Voorschoten, Netherlands
(2)
RHEA Group, Schuttersveld 2 2316 ZA Leiden, Netherlands
ABSTRACT
Defence organization across Europe face challenges
providing modern capabilities to deployed troops. One
of the main reasons for this is outdated project
management procedures that have been designed for
civil works activities such as building runways or the
acquisition of major weapons systems. These serial
processes are a contributing factor to high project failure
rates for Defence Projects – especially IT intensive
projects that must deliver on short timeframes before the
technologies being acquired become obsolete. The use
of Concurrent Design (CD) in Defence offers the
opportunity to accelerate projects and build a stronger
connection between capability developers and the end-
users they intend to serve. In this paper, we explore CD
and how it should be adapted for optimal use in a
Defence environment.
1. BACKGROUND
For much of the 20th century, the Defence sector played
a leading role with respect to technology innovation.
Indeed, products such as the microwave oven, GPS and
even the Internet all evolved from innovations spawned
from Defence requirements. Today, this is no longer the
case. In fact, in many areas Defence lags behind
industry. Defence must adapt and find alternatives that
will help to close the widening technology gap between
Defence and commercial industry.
An important part of this process is for Defence to look
beyond its own borders for non-traditional solutions
provided by non-traditional actors. One obvious choice
is the Space sector, and more specifically, the European
Space Agency (ESA). The overall success rate of
complex space missions executed by ESA is
significantly higher than that of complex Defence
projects. Furthermore, ESA is public sector,
multinational, deals with complex projects that have to
deliver into a harsh environment and has a mandate to
outsource much of its work to industry.
The logical question for Defence is: what is ESA doing
that is not being done in Defence with respect to
capability delivery? Concurrent Design is a best practice
embedded in the culture of the Space sector that has not
yet gained a foothold in Defence that we believe could
transform Defence capability delivery in the same way
that it has benefitted Space organizations since the early
2000s.
2. CURRENT CHALLENGES FOR DEFENCE
Currently, most Defence establishments use a
documentation-heavy, serial process throughout the
project lifecycle (Fig. 1). Unfortunately, this serial
approach has significant drawbacks that lead to
excessive costs, long project life cycles and ultimately a
negative impact on the quality of the final product -
especially for the procurement of IT systems that have a
very limited lifespan and benefit from rapid delivery.
The most serious problem is that written documents are
subject to interpretation. It is extremely difficult to
capture complex user requirements completely in
written documents. There are ample cases in Defence
where the product delivered was not fit-for-use because
the original requirements were incorrectly interpreted by
capability developers.
The next problem relates to the process itself. A lengthy
set of requirements can often include incomplete,
ambiguous and conflicting requirements. But project
managers - who are frequently under considerable time
pressure - are often reluctant to consult with the writers
of the original requirements for clarification out of fear
that this consultation will introduce delays. Instead,
assumptions are made by project teams that can
seriously undermine the quality of the final product.
Finally, in a typical Defence project there is usually a
milestone where the requirements are "locked" before
the design process begins, suggesting that trade-offs are
no longer possible. As a result, solution designers have
less latitude to consider alternatives that may have been
equally suitable to the end-users but that would be
easier, less expensive or quicker to implement.
3. SPACE SECTOR AS AN EXEMPLAR
ESA has addressed many of these problems with a
process known as Concurrent Design (CD). Through
CD ESA has been able to reduce the time required to
complete a high-level design by a factor of four, and the
cost of this activity by a factor of two. But the benefits
don't stop there: in a longitudinal study that reviewed 30
projects before and 30 projects after ESA started using
CD, ESA determined that the number of engineering
change proposals (ECPs) during project execution was
reduced by more than 30%. This is a significant factor
which allows projects to be executed more quickly and
at far less cost. This reduction is possible because ESA
is able to provide industry with better specifications -
essentially becoming a better customer. Industry
 Figure 1: Comparison of Process Types

appreciates this as well; it is far easier to provide an
accurate bid against high-quality set of specifications
than against ones that are weak.
The good news is that CD is not a radical departure
from the way things are done today in Defence. High
level requirements are still the starting point for all
projects. These are then given to a team who translates
the requirements into a high-level design. One big
difference, however, is that the requirements are not
"locked down" as they usually are in Defence projects.
This provides opportunities to adjust the requirements
later during CDF sessions. (Fig 2.)
process are not working concurrently, the conflict might
not be identified, or it would go unresolved resulting in
a weaker specification which ultimately results in added
time and cost to the project.
By the end of a typical four-hour session, all
stakeholders have had the opportunity to present their
specific domain areas with plenty of time left for
discussion. Of course, the customer is actively involved
during the entire activity - which is one of the reasons
why the CD process is so effective. Most CDF
Activities require at least 4 sessions to result in a final
design.

Once the initial high-level design has been completed,

all of the stakeholders are physically gathered together
at ESA's Concurrent Design Facility in Noordwijk in
The Netherlands. During CDF sessions, there is direct
engagement between designers / engineers and the end-
users of the capability being developed. This provides
invaluable opportunities for designers to "get into the
heads" of the end-users and also for designers and end-
users to discuss any trade-offs that might be required to
achieve an optimal design.

It is a normal and expected part of the process that

during a CDF session conflicts will arise that need to be
resolved through discussion. In many cases, these issues
can be addressed immediately, and the CDF process
moves on. In some cases, however, the issue requires
more thought and the issue can be "parked" for later
consideration after the CDF session has been completed.
It is very important to realize that each time a conflict
arises in a CDF session, a similar conflict would have
also likely been present in the serial process used by Figure 2: Concurrent Design Process
Defence. But because the stakeholders in the serial
As mentioned previously, one of the key advantages of
CD is that the requirements can evolve alongside the
design. Often times when the customer is involved in
discussions about the design, they are able to not only
provide clarification on the requirements, but - in some
cases - even adapt the requirements as necessary to fit
optimally with the design. In the end, the result is a set
of requirements and a design that are "perfectly
matched".
In Defence, project managers sometimes accept weak
requirements as mentioned previously, hoping that this
will not result in any delays or have a big impact on the
final project, but in reality, they are often just deferring
a problem until later in the process until after contract
award. Resolving these conflicts between requirements
and design at the earliest stages in the project could be
the main factor allowing ESA to achieve a reduction in
engineering change proposals later in the project by
more than 30%.
4. THE POWER OF MODELING
One of the guiding principles of ESA CDF sessions is
that PowerPoint use should be limited. As much
information as possible is documented in a set of
models that are ultimately shared via a central
repository. This helps to ensure that vital information is
not lost "on slide 12 of a 50 slide PowerPoint deck" as
can easily happen in a typical Defence project.
Models are an essential part of any successful CDF
activity. Models evolve over time to capture key
elements of each of the domain areas covered during the
CDF activity. The beauty of having explicit models is
that design teams can achieve a level of consistency and
quality from project to project that is impossible to
achieve with projects that are designed in isolation - as
is the case with many Defence projects. In most cases,
the models are contained within Microsoft Excel
spreadsheets. This is a step in the right direction, but
simply modeling each of the aspects of a project in
Excel only provides a partial solution. This is where the
CDP software suite plays a vital role. CDP (Concurrent
Design Platform) is a unique open source software
product that allows the models to be both configuration
managed and also synchronized.
Since the concept of models can be a bit abstract, it is
best to demonstrate with an example. For a satellite
mission, you can imagine that the type of instruments
onboard are crucial to answering the questions posed by
the scientists. The instrument package can be
represented in a model that focuses on the satellite's
payload. Of course, instruments require electricity to
operate, so any change to the instrument package will
have a cascading impact on the amount of power
required, which then impacts the size of the battery, the
solar array and wiring harnesses. With the CDP, when
the payload model is updated, the changes to electrical
requirements are automatically cascaded to the model
that deals with electrical systems. The expert in charge
of electrical subsystems then adapts his or her model to
include which type of battery and solar cells will be
used, which then impacts physical size requirements.
These are then cascaded to the model dealing with
satellite structure and further cascaded from there. Since
these dependencies are modeled in the CDP, changes in
one part of the mission can be cascaded in near-real
time where the changed can be assessed based on its
global impact to the mission. Having these models
update in near-real time during discussion about the
project saves an incredible amount of time and
ultimately results in a much higher quality design.
5. APPLYING CD TO DEFENCE IT
To give a brief example for Defence IT projects, three
of the planned models are for interoperability, testing
and cost. In the interoperability model, as more
interfaces are specified, these will be automatically
reflected in the models for both testing and cost.
Obviously, the more external interfaces a system has,
the higher the testing requirements become and
therefore the higher the cost. If there is a point where
the budget estimate exceeds the available funds, the
customer can immediately be consulted as to the priority
of the external interfaces supported. It is then up to the
customer to decide which ones to remove. In the current
serial processes used in Defence, this type of interaction
and decision making is nearly impossible.
6. THE D-CDF PROJECT
On May 29th, the Netherlands Defence Material
Organization (DMO) and The Defence Innovation
Greenhouse (The DIG) signed a contract to begin the
process of developing a Defence variant of ESA's CDF.
RHEA Group is a key subcontractor in this effort.
Although the project is small, it is an important first step
on the long road of building an advanced "Deployable
Defence Concurrent Design Facility" D2CDF. In this
project, members of The DIG will team up with the
RHEA Group, Europe's leader in CD software and
facilitation, and work closely with the DMO to begin
developing Defence specific models to support CD
activities for Defence projects.
This small project with the DMO, The DIG and RHEA
is just a start. A much larger effort is envisioned that
will bring in other nations and hopefully maybe even
NATO into a comprehensive effort to create a full
D2CDF capability. On the surface, it may seem trivial
to take what has been developed at ESA and replicate it
in a Defence setting, but this is not the case. Defence
has many unique characteristics and constraints that
differentiate it from space missions.
The first obvious difference is the models. Complex
models required to design space missions will be of
little use for most defence projects. One large activity
within the project will be to develop models that take
into account the unique characteristics of the following
military specific disciplines (these can be considered the
equivalent of different "payloads" in a satellite)
• Intelligence
• Situational Awareness
• Operational Planning
• Logistics
• Command and Control
• Air, Land & Maritime
• Special Operations
• Cyber as a Military Discipline
Models will also have to be developed to cover the
following generic aspects of any Defence IT project
(these are the equivalent of the non-payload aspects of a
satellite such as the solar array, the satellite's structure,
etc.)
• Interoperability and Federation
• Cyber security
• Information security
• Data modeling
• Network environment
• Human machine interface
• Training
• Testing
• Compute and storage infrastructure
• Adaptive maintenance / O&M
Another key difference between ESA's CDF and the
D2CDF is the span of use of the facility. While ESA's
CDF is primarily used for the design of space missions,
we envision that the D2CDF will eventually be used to
support a wider range of activities, including:
• Capability Development
• Multinational Defence Requirements
Arbitration
• Complex Defence Project Troubleshooting
• Military Exercise Planning
The use of the D2CDF for Capability Development is
very similar to ESA's use cases for its CDF as described
above. So, it will not be covered again here.
Multinational Defence Requirements Arbitration is a
process whereby nations come together to develop a
common and agreed set of high level requirements to
meet a specific operational challenge. This can be quite
complex considering that each nation has its own
Defence needs and yet nations must find ways to work
together to achieve economies of scale.
Complex Defence Project Troubleshooting is another
area that is rich in opportunity for D2CDF use. The
D2CDF will give all of the key stakeholders a seat at the
table and equip them with a repeatable methodology for
identifying the root causes of failure. The D2CDF can
then be used to develop mitigation plans for getting
projects back on track.
Military Exercise Planning could benefit greatly from
having access to the D2CDF equipped with exercise
related models. Just as in space missions and Defence
capability development, every military exercise is
unique, yet most exercises share a large number of
common characteristics that can be modeled. Over time,
as these models mature, exercise planning can be
simplified and streamlined.
7. THE DEPLOYABLE CDF
While there are many aspects that make the D2CDF
compelling, one that is most interesting is increased
engagement with end users. And, one of the best ways
to achieve this is to bring the D2CDF to the end user
instead of having the end user come to the D2CDF. For
this reason, our aim is to build our first D2CDF facility
so that it can be rapidly packed up and shipped to a
location where the end users operate. We do not
envision that all D2CDF sessions will happen within an
operational environment, but it would be ideal if the
first one or two sessions could happen in a deployed
setting. This gives all of the participants in the D2CDF
activity the unique opportunity to directly observe and
experience the actual environment in which the project
will ultimately be deployed.
The wider adaptation project as described above is
estimated to take approximately three to four years and
has a rough order of magnitude cost of €6-€8 million,
although a detailed cost analysis still needs to be
completed. The good news is that the D2CDF project is
a prime candidate for a multinational Defence
innovation project enabling nations the ability to spread
the costs. Justifying the cost of the adaptation project
should be easy; ultimately, if the D2CDF can be used to
de-risk complex Defence projects and prevent just one
medium to large project from failing, the loss
prevention value from the D2CDF adaptation project
will far exceed the money invested to build it.
8. CONCLUSION
The time for Defence to try something new is now. The
future of Defence is multinational. Applying lessons
from a sister industry, the Space sector, makes sense. It's
time for our forces to have technologies on the
battlefield that are as good or better than the ones we
use every day in our homes, offices and schools. It's
time for the Deployable Defence Concurrent Design
Facility.