aa02 ta Farncombe

Characteristics of communication failures between Project Management and Systems Engineering – and a route map for correction: 

Characteristics of communication failures between Project Management and Systems Engineering – and a route map for correction JBA Limited Visiting Professor of Systems Engineering: Cranfield University Andrew Farncombe andrew@jba.net

Impediments to effective SE: 

Impediments to effective SE Novices running big projects  no experience of SE added value People don’t seem to see through or do ‘big projects’ more than once Lack of follow-through from ‘lessons learned’ to process improvement 'Strong management will suffice'; 'Systems Integration is the key' Organisational ‘silos’ Casting projects in ‘contractual concrete’ too early Tools and ‘silver bullets’ seen as the solution 'We’re a COTS project and don’t need SE.' Ditto ‘New Economy’ projects 'Doing it right takes too long – we’re in a hurry. No budget for SE, anyway' Too few good systems people available up front where it matters ‘Initiative fatigue’/SE seen as a management fad du jour Some SE people are not seen as being very businesslike SE is seen as something that happens ‘over there’ Maybe the name ‘Systems Engineering’ is wrong Can you think of others? Not all organisations have discovered the need for PM, let alone SE!

These boil down to…: 

These boil down to… Knowing the cost of not doing decent SE Organisational factors Bad SE process thinking SE image problems

Knowing the cost of not doing decent SE: 

Knowing the cost of not doing decent SE

Things that go wrong: 

Things that go wrong Weak/non-existent basis to requirements Inadequate costing and time-scale estimation Weak control of suppliers/sub-contractors Integration problems Inadequate test and acceptance strategy What goes wrong in your organisation?

A project whose turn it is to be ‘it’: 

A project whose turn it is to be ‘it’ Scope problems No overall orchestrated cracking of the whip No idea of costs at the outset No system-wide vision: An ‘odds andamp; sods’ approach Bitten by unproved technology

The cost/benefit case for SE: 

The cost/benefit case for SE It costs less to solve problems sooner rather than later 1:10:100 between project stages (eg concept, design andamp; development, manufacture) are common cost ratios (maybe more!) Management has much more control to act early in the life-cycle; this becomes much less later on You commit 60%+ of the cost base in the first 15% of the project SE is the discipline with most leverage in the early stages So…explore, find and solve problems as early as possible in the life-cycle

Organisational factors: 

Organisational factors

Joined-up organisations: 

Joined-up organisations The organisation often gets in the way of effective SE SE can only do so much unilaterally Organisations need to be tuned to use SE SE needs to be integrated – not something ‘over there’ Organisational functions need to be ‘de-siloed’ Processes need to be aligned and integrated

Organisational Silos: 

Organisational Silos Finance Marketing Engineering Contracts

A ‘joined-up’ organisation: 

A ‘joined-up’ organisation

Supply Chain also needs to be ‘joined-up’: 

Supply Chain also needs to be ‘joined-up’ Don’t pour in ‘contractual concrete’ too early!

Sub-systems as ‘orphans’: 

Sub-systems as ‘orphans’ …but who’s thinking systemically at this level and managing things? Often – no-one Leaving these as ‘orphans’ working in isolation – with predictable consequences!

Bad SE process thinking: 

Bad SE process thinking

Defining effective processes: 

Defining effective processes There need to be two equally-important levels at work: Life-cycle level (aka ‘in the large’/‘macro level’) Systems Engineering activity level (aka ‘in the small’/‘micro level’) You need to reflect both levels explicitly Common mistakes: Choosing one level and ignoring the other (both occur) Drawing Sys Eng Activity Level with Life-cycle level implicitly struggling to get out Getting ‘religious’ about one particular Life-cycle model, and insisting there’s only one correct one ‘Horses for Courses’ thinking should prevail Reduction of uncertainty and risk is the predominant driver Once selected, the Life-cycle level has to be mapped onto the Systems Engineering Activity level ‘Lessons learned’ should be a routine part of the process

Tailor processes to project needs: 

Tailor processes to project needs Tailoring Process Project Specific Plan Project Specific Profile Generic SE Knowledge and Process Models Meta Process

SE image problems: 

SE image problems

Tips for System Engineers: 

Tips for System Engineers Don’t turn SE into a high priesthood Don’t make SE look like your personal hobby Don’t do your SE ‘over there’ in the corner Don’t become a process-fundamentalist Do show you understand the business world Do get stuck in with real projects Do be adaptive and flexible to real situations

What’s in a name?: 

What’s in a name? Systems Engineering – redolent of the ‘oily rag’? Systems Integration – connotation of just making the bits fit together Systems Thinking – may be better; does it come across as too laid back? Systems Management – may mean different things to different people Any suggestions?

An agenda for improvement: 

An agenda for improvement Understand where your projects go wrong Sell SE’s added value and risk reduction to PM Encourage PM and the organisation genuinely to understand SE’s added value Develop flexible processes to minimise project risks with PM, SE, QA and other functions as stakeholders Apply SE at the appropriate levels Ensure SE is led and resourced by respected and experienced people with business sense