Systems engineering and project management –

partners in successful projects

Thales Case Study

Jim Luffman

Thales January 2013

© Thales UK 2011

Introduction and objectives

My objective is to try and inspire the syndicate and discussions & provoke the debate to look at root causes, not just take the next obvious steps.

Agenda Set the context Using a case study, illustrate the 10 main lessons learned recovering engineering

projects. Demonstrate that effective communication and behaviours between PMs and SEs

are critical success factors for current and future (Thales) projects. Map these lessons to a set of PM/SE capability improvement enablers and propose

some areas to look for solutions now and in the future.'.

Why me? I am a systems engineer…… …..I also happen to be Thales UK Director, Bids and Projects Thales effectiveness and efficiency at this kind of thing is fundamentally my

current vocation.

© Thales UK 2011

Some Thales projects in the UK3 /

© Thales UK 2011

Scene setting: The Thales UK challenge

Organisational Complexity

Process complexity

“Traditional” programme centric

systems engineering

Product Line systems

engineering

New system types (and new

organisational relationships)

Model Based Systems

Engineering

Increasing complexity demands increased people competence

and organisational maturity

To grow profit & market position in an ever more competitive, budget constrained market place.

So what does this mean for our project management and systems engineering?

• Budget constraints require agile, tailored PM & SE solutions• Increasing need for internal collaboration (with associated governance)• More complex, collaborative customer /partner/supplier environments

© Thales UK 2011

Project Summary Information

The project was a tactical communications system providing situational awareness at various levels of encryption.

The project was built upon a legacy Tetra radio code-base and hardware design and delivered in three increments.

Inc 1 and the first part of Increment 2 (Initial Operating Capability) were fundamentally the same (the key differences being the IOC had increased capability and different, more stringent, non-functional requirements).

The second part of Increment 2 (Full Operating Capability) had a revised radio and enhanced operational capabilities.

© Thales UK 2011

Lessons Learned Process

SYS, ITEA, ILS, IA+

SW+ MMS, Radio,

Peripherals

SCM &

Procurem’t

CM, Governance

Cust. PM

Senior Stakeholders

Customers

Misc. Others

Output(1)

Output(2)

*1 Questionnaires

requiring minimum effort

*1

Draw Conclusions

Leads + QA + Independents (inc. some Chorus 2

Process team members)

Consolidation & Tidy Up

Output(1) Output(1) Output(1) Output(1)

Add Value (eg map to Chorus) Email distribution to team, independents and Seniors

Small select teams led by CAM to provide best value. Focus on area, but gather any wider comments if team wants to contribute

© Thales UK 2011

Distribution of Lessons learned by discipline

Results by Discipline

Estimating2.4%

Systems10.1%

IA1.5%

ILS/Training1.1%

Production0.4%

Procurement4.1%

ITEA4.7%

Hardware3.0%

Software4.9%

Governance11.6%

Other3.4%

CM/DM8.6%

Project Mngt (PM)10.5%

R&O (PM)1.5%

Planning (PM)7.1%

Organisation (PM)18.5%Customer

4.1% Finance (PM)2.4%

Governance

Project Mngt (PM)

R&O (PM)

Planning (PM)

Organisation (PM)

Finance (PM)

Customer

Estimating

Systems

Software

Hardware

ITEA

IA

ILS/Training

Production

Procurement

CM/DM

Other

© Thales UK 2011

Improvement lessons outside the process set

Of the lessons not addressable in the process set

Practices20.6% Behaviours

22.1%

Infrastructure23.0%

Comms & Culture34.3%

Addressed by Chorus 2 ?

Not Covered by Chorus 2

46.7%

Not Covered by Chorus 2, but now WIP

3.0%

Covered by Chorus 2

50.3%

© Thales UK 2011

Success depends critically on early phase “thinking” & quality…

Need

Requirements

Design

Detail design/Manufacture/Procure/Code

Accept

Integrate

Verify

Validate Operate

Transition to Support

Transition to production

A short-cut, omission or defect

here

causes failure here

here

Should be caught here

Specify

A short-cut, omission or defect

here

causes failure here

And if not, causes failure

hereor here

or here

or here

or here

“most mistakes are made on the first day!”

“money saved on design and test is paid for many times over in rework before acceptance

and/or due to warranty claims”

Cost of fixing errors in your project, by phase

requirements x1 (reference)design x5build x12test x40operations x250

© Thales UK 2011

…..and the right communication structures & behaviours

Objectives misalignment: communication issues

PM<>development team members behaviours

Systemic issues Planning too detailed, too early WBS WPs too granular too early?

Admin o/h inc as square of no WPs Inter team interfaces vs task complexity Prove architecture design before breakdown using model validation & MDE

What is WP optimum size?

Product oriented WBS may actually drive cost up…… WPM cost= f(No of WPs) WP I/F mgmt cost = f(No of WPs) 2

C wp = f (Admin, No VA people, T)

Above the optimum team size, the potential for mistakes increases:

Increases rework (risk impact) cost and rework avoidance (risk mitigation) cost

Maintaining business organisation alignment

© Thales UK 2011

PM & SE Added Value Goals: become boring!

Oxford English DictionaryBoring (adj) not interesting, tedious 

Lamri DefinitionBoring (adj) deliver on time, to budget with no last minute surprises. 

Become a high performing team.

do the right design and definition work to the right quality

here

so the right things happen at the right time here

manage change, uncertainty and transitions

throughoutto deliver a safe, secure, valued, trusted system

do the right thinking, analysis and synthesis

here

detect and eliminate defects as quickly as possible here

understand the options, risks and

cost drivers

understand customer needs, purpose, goals, culture - -

do the right lifecycle

planning here

And we can do copy and paste re-use for future

projects

© Thales UK 2011

Lean Enablers for PM & SE*

Value (V) promote a robust process of establishing the value of the end solution to the

customer with crystal clarity, and frequently involving the customer.

Map the Value Stream (M) prepare the personnel and processes for efficient workflow & healthy

stakeholder relationships. Plan in detail, frontload, use leading KPIs/metrics.

Flow (F) promote the uninterrupted flow of robust, competent, quality work that is right

first time, avoiding crises & hero behaviour by excellent coordination, concurrency; frequent clarification and making progress visible to all.

Pull (P) promote pulling tasks and outputs based on need and better coordination

between those at the end of each transaction. Reject others as waste.

Perfection (Pr) promote excellence in the enterprise processes, use lessons learned,

collaborate & drive out waste via standardization & continuous improvement.

Respect for People (R) promote a culture of trust, openness, respect, empowerment, cooperation,

teamwork, synergy, good coordination to enable people for excellence.

* The Guide to Lean Enablers for Managing Engineering Programs, Oehmen et al, v1, May 2012

© Thales UK 2011

10 key messages mapped to lean enablers

The battle to maintain schedule and cost will be won or lost by whether you have the right resources and they operate effectively [R, V, M, F, Pr]

Always make sure that you have the best view of the status of the programme and communicate this honestly [R, Pr]

When work is split across teams the risk to the schedule and cost escalates and becomes pronounced when teams are not co-located. [R, M]

Make sure that you thoroughly understand the obligations and implications when signing up to all (esp non functional) requirements, [V]

Success will only be achieved and less pain felt if there is a good relationship with the Customer and User [R,V]

The effective operational management of Risk and Opportunity is critical to protecting the schedule and cost. [F,P]

Despite subsystem testing, the majority of serious defects will usually be uncovered during System Testing & may peak again during User validation. Plan accordingly. [Pr, M]

Unusual subcontractors (eg Accreditors) need to managed accordingly. [F,P] A schedule, no matter how big and impressive, is no use unless it can be

maintained and understood by all users. [Pr] The estimating, maintaining and tracking of project costs is undermined by

reporting cycle coherence issues that are not always obvious. [M, Pr]

© Thales UK 2011

Internal cost of management: OBS/WBS Optimisation

Benefit of a good WBS: everyone doesn’t have to talk to everyone all the time!

Mgmt

Cost/

Benefit

No of WPs

Cost of1 WP

Comms Cost/ Effectiveness

No of People

Optimum WBS

Team of 16Optimum split ?

Needs Knowledge

Time

Target

Customer

Supplier

Change

ASAP!

Optimum Team Size

© Thales UK 2011

Product Delivery Phase

Another dimension and orientation?

When promised (T)At acceptable cost (C)

Sufficient performance (P)

T

C P

Zero Defects (D)?

Fixed

Flex

Concept Development Phase

C T

P C T

P

© Thales UK 2011

Future goals??

Team accountability rather than singular accountability : Parallels to xtreme programming paradigms where, in 96% of cases 2

complimentary people do the same job in 40% of the time it takes 1 competent person. An unrealised opportunity??

What are the characteristics of “Xtreme PM” necessary to enable this higher

level of collegiate responsibility?

Play individual strengths to a common purpose in order to deliver maximum value.

Objectives aligned and translated. What must I do for my project? Enabling structures optimised

A ‘value to customer’ oriented WBS ? May be better for benefits tracking and driving value than simply delivery

oriented to time, cost & quality