This festive season, I’ll probably find myself pressed into the company
of people who don’t know what I do, and who will make the mistake of asking.
I’ll tell them I’m a Systems Engineer, and few, not even other engineers, will
know what that means. Some will abruptly excuse themselves to find another
drink to go with the perfectly good one they’re already holding; others may
smile and nod and suddenly recognise an old friend that they must catch up with
right now on the other side of the room; most will simply feign imminent
illness. A few, however, will experience that critical lapse of verbal control
familiar to all social drinkers, and will unthinkingly ask for an explanation,
which I’ll be happy to launch into even as their words catch, falter and die in
their regretful throats. At the start of the evening, this will be relatively
straightforward, but those asking in the whimsical after-hours will be on the
receiving end of something more like what follows.
The Intractable Nellie
Way back in the day, when men
were real men, analogies were tortured and metaphors were mixed like drinks, a
bunch of blindfold engineers got together to eat an elephant.
And because they were seasoned
professionals, not some bunch of blindfold academics or west-coast wannabe-billionaire
teenage beanbag-dwellers, they appointed a project manager and so became a
team. And the project manager did the stuff project managers are supposed to
do, worrying at the money, tracking timescales, dividing the task into smaller
and smaller chunks and directing each eager resource at an appropriately-sized
portion of the problem, according to long experience of similar jobs over an
extensive career of circus animal consumption.
And so the job began. Each
engineer groped his or her way to the assigned body part, took out the
appropriate tools of his or her peculiar discipline and began his or her
appointed task with admirable vigour. And everything went well for a while, the
sound of productive knives, forks, spoons, nail clippers, hair trimmers, gardening
tools and teeth and so on drowning out the regular milestone screams of payment
being extracted from the budget-holder in arrears.
Then, abruptly, the sounds
changed. The scrape of stainless steel on bone, the tearing of wrinkly grey
flesh gave way to the sounds of clashing cutlery, professionally-acceptable but
still expressive swearing and the laceration of many fingers. The engineers had
reached the interfaces of their component limbs, beginning to meet in an unplanned
and undocumented fashion. Human, rather than pachyderm, blood was beginning to
flow and work slowed to a crawl. Also, the left ear eater had been doing some
exploratory scoping, and had begun to form the suspicion that the ear was somewhat
larger than originally predicted. The self-appointed manager of the
right-rear-leg-and-buttock team was reporting similar issues, and the less said
about the emerging scale of the firmware, the better.
Faced with a looming elevation in
workload, the project manager went by the book, issuing an early warning to the
customer that the task was more mammoth than understood, and that something may
have to give. The customer expressed bewilderment, accepting that estimation is
tough but wondering how it was that, with the elephant supposedly three-quarters-eaten
already, the team had only just discovered such an error in scale. The project
manager explained, quite reasonably, that blindfold elephant-eating is a tricky
business, and these things, more often than not, just happen. And experience
told that this was hardly the worst underestimation of a problem ever seen –
after all, there was that time when the elephant had turned out, on initial
prodding, still to be alive! That had been character-building.
The customer was unimpressed.
Contracts were contracts, he said, and, he said, he had accepted the risk of
time and materials with his eyes open. But, he said, he had rather assumed that
the team would take steps to manage the scale of the job from the outset, not
just from eight months in. So what was the problem?
And the project manager asked (tentatively,
because it was too late, but you should always ask even if it is too late) for
confirmation that the animal being eaten really was an elephant. An Indian
elephant, yes? And the customer said no, Indian elephants are old hat. And we are
aggressively pursuing the African elephant space these days. And is that going
to pose a problem?
And the project manager wished
they’d had a Systems Engineer on the team in the first place.
Enter the Systems Engineer
The Systems Engineer’s jobs are many,
you see, but the central function to which it all amounts is the management of
information flow between those with no business understanding each other’s work
– between the customer and the engineering team, and between engineers
concentrating on different parts of the solution or working in different
disciplines.
And it is this function that can
save a project from horrendous, costly, painful and embarrassing collapse at
that point where it appears to be at its most productive. It’s said that the
faster you go, the bigger the mess, and it’s generally at the point that
development is in fullest swing that interactions between team members require only
the very tiniest trip to cause a magnificent pile-up. The Systems Engineer
works as far as possible to ensure such trips can’t occur, and, if they do
occur, that the project is sufficiently and promptly slowed, caught and righted
before it gets a mouthful of tarmac. And the best way to prevent the trip and /
or to be in the best position to catch it is to understand everything about the
project at a level just sufficiently ignorant of the detail that one person (or
a small, structured team) can take it all in and monitor it competently. This
is the foundation of Systems Engineering.
Requirements and Architecture
To maintain constant
understanding of a development project, the Systems Engineer keeps an eye on
both the goal and the solution. They build understanding of the customer’s problem
and formalise it in the shape of the project requirements, and they supervise
the architecture which is developed to solve that problem.
By structured translation of the
requirements between the customer’s field of expertise and the engineer’s,
followed by formal or informal elaboration of the requirements to describe
partitioned portions of the solution to be worked on by engineers in different
fields (as set out in the architecture), the Systems Engineer provides a clear
interface from the customer’s field of expertise down to the individual
detailed designers working on the solution. And by feeding reported problems
from the detailed designers back up to the architectural level for impact
analysis, and then relating unavoidable consequences back to the customer’s
domain in the context of the original requirements, the Systems Engineer
provides feedback on how the job is going, and enables rapid and clear
decision-making by the customer if things do go wrong: Do we fix it, what would
be the consequences of not fixing it, and if we do fix it, how much is it going
to cost?
An Engineer You Can (and Should) Hug
As a customer of an engineering
team, you’d hope to have a good relationship and frequent contact with the Systems Engineer, especially when working to a tight deadline. And the ideal
relationship is often not the most straightforward – if your Systems Lead
swallows your suggested requirements whole and never challenges any of them,
you should suspect a failure of communication. Experience suggests that only
after some friendly argument over the detail is a problem ever fully understood
by both sides, so you should hope for some deep conversations rather than blind
acceptance. But in the end, remember: The Systems Engineer is the customer’s
best friend on the development team. Assuming you are faced with a separate
Systems Lead and project manager, the Systems Lead is usually responsible for representing
your needs to the team (including to the PM), and will never present you with a
bill. He or she is wholly and constantly concerned with ensuring you get what
you need, and with reducing risk to its delivery.
The Silent Masters of Churn
And that’s it. The Systems
Engineer worries constantly at the requirements, architecture and various other
bits and bobs such as driving the integration process, system testing (which is
extraordinarily important, but not the sort of thing you talk about in polite
company), risk management (both to project delivery and to end users stepping
into the line of fire of the product), and any associated design documentation
required by the relevant regulatory bodies troubling themselves with your
product. Lots of conversations, lots of checking of understanding, no obvious
hard output much of the time. Like a sort of prayer wheel, the Systems Engineer
is often invisible, whirling away in the background, with no apparent impact on
the project – they don’t appear to produce much of the final design (a good
architecture rapidly becoming invisible in the face of debugging the fiddly
minutiae) and most of their output is in the form of paperwork nobody ever
reads after the project is completed. In fact, some might argue nobody reads it
during the project either, but the fun thing about it is that this generally
doesn’t make it any less worthwhile – it’s the iterative process of creating it
that counts. But the day that prayer wheel is stopped (usually on budgetary grounds),
the vengeful and needy God of Project Delivery begins to take an interest, and
his hairy familiar, Unexpected Change, will not be far behind. It’s probably waiting
for you just round the next corner right now. It craves cash to fill its
cavernous belly and carries a big stick.
The Leftovers
And what of the blindfold engineers
and their unexpectedly-African elephant? Well, the project manager called in a
Systems Engineer, a classical hero, bulging of biceps and clear of vision, who briefly
took the project right back to the requirements stage. He removed his blindfold
and thus formalised the customer’s needs through rapid but careful discussion: African
elephant, male, middle-aged, normal limb-count, medium-rare. Then he formalised
the architectural partitioning and interfaces and a performed brief gap
analysis, leading to instructions to the rear leg people that the thighs were
henceforth to be assigned to the buttock teams, with an emergency doubling of
ear specialists and partial outsourcing of the software to a 3rd
party (at considerable expense). The budget-holder grumbled, but accepted a
significantly increased bill in order to hit the original deadline, and
everyone except the elephant survived to repeat the same mistakes many, many
more times before retiring to tell the tale.
And how is eating an elephant,
the total deconstruction of a working thing into nothing, at all relevant to
the construction of an aeroplane / car / satellite / baggage handling system /
medical device? Well, it’s a poor analogy. An after-midnight analogy. But it
models in reverse a utopian vision of development that will rarely be achieved.
The ideal in building a thing is not, as often happens, to set out with nothing
but a vague idea of some imagined outcome and keep adding and fettling bits until
it looks finished. It is more efficient and elegant to start out knowing
precisely what the end result should be, and to assemble it from a known number
of precisely planned parts that all just fit together. No extraneous work, no
missteps or blind alleys, no parts left over, nothing missing. In other words,
to dismantle it backwards. Nobody ever cut up an elephant and found a random
bit of extra Bakelite or fifty lines of unreachable code in there. I could have
gone with blindfold cannibalistic engineers for my analogy, but humans have an
appendix so that would have been absurd.
Anyway, the take-away from all
this is that the Systems Engineering discipline operates with appropriate
freedom from the detail so as to be able to keep an eye on the prize throughout,
and concentrates on the final closing of the gap between product and dream,
keeping development close to the ideal, waste-free path. It is the client and
the engineering team’s best friend. And it is a must-have on any complex product
development.
Or maybe I just dislike
elephants. At this time of night, it’s hard to tell.
