Most people run from the eye of the storm. The minions are like that, too. Take Squire Hardcastle, for instance. He sees Hurricane (M)Ike, the 'm' is silent, coming and packed his bags for KSC. Having made his mess on the SE&I carpet, he's now sticking his tail between his legs and heading away from the predicted path of destruction.
Squiress Hansen also sees her overweight, overwraught lunar lander headed for the crater and accepts the opportunity to try and clean up Hardcastle's poo. If she succeeds, she dodged the lander program manager's bullet that was inevitably headed her way. If she fails, well it was too far gone to begin with.
Her candidate replacement ran home to board up the windows, hoping to avoid the inevitable storm damage. We suspect this is still a disaster coming in the not too distant future. Thank goodness hurricane season is over in November.
Subscribe to:
Post Comments (Atom)
11 comments:
There is a 50% probability that a season of reason will follow the hurricane season on November 4, 2008.
Waiter! My glass is half full!
For the newly arrived on the scene, what did Hardcastle do? Just mildly curious given his background and apparent backing from the higher ups.
Perhaps the question is: "What didn't Hardcastle do?" Anyone? Bueller?
Fail to establish and enforce a system engineering process for Cx perhaps?
Hummm...very interesting! That was his long suit! Dude supposedly walked on water where SE was concerned. For years, managers have really taken a shine to him. Of course, I never saw anything of substance because he was on a vertical training program.
One thing is for certain, there is no SE process on Cx and like the shuttle, it is too late - the horse didn't leave the barn, he was never in the barn in the first place.
"[SE] ... was his long suit."
Oh, yeah! That's why NASA bent almost every hiring reg in the book the bring him in in late '05.
Can't entirely blame him for the lack of SE in Cx, though. He might as well have been speaking Mandarin to the management at JSC. They have absolutely no experience with SE, but they are sure they don't need it.
Cx doesn't need SE. Just walk the hallways and look at the pictures on the wall. Those didn't come off table napkins. The design is done and parts are being bought using unreleased engineering.
Now we are driving the SE process in reverse to justify the pretty pictures. The associates are saying that if we want SE, we can do our own when we take over! It's okay, we've got CRADLE - just ask any manager because that is the cure all according to them.
Just once, I would like to find a program headed by an SE type instead of a designer! I've done it before. It does work as advertised if used properly.
you don't want a systems engineer as the
lead for the project, but, you don't want
the SE as the deputy or in the same office
to arbitrate disputes and to make sure
the reequirements are translated into
design
I would disagree with your premise to a certain extent. The problem lies in the steady stream of designers that go into management and the bean counters that occasionally make it there. The designers just start designing and use SE as floor sweepers that gather up bits and pieces of knowledge that the designers lose track of.
This condition is easy to spot. Look at the program schedule. If all functions start simultaneously, walk away. SE must start first because, and as you correctly point out, it is the technical management arm of the program and as such, must lead the effort.
A second tell-tale is if SE is not a part of the organizational structure from the beginning, trying to incorporate it later will result in failure. Many projects, run by designers, have SE because the customer required it. However, as you have seen, it is an empty shell, giving the impression of having done real work. That is until PDR when the design and the requirements look like they came from different planets.
I am new so what do you mean by "designer" as there are none in management. There maybe some self-proclaimed "interior decorators" but not rocket designers. And as far as SE goes, don't think that saves the day either when all you are doing is tracking and arguing over process. Requirements must mean something and there are hard gut-wrenching choices to be made in development. It comes down to knowing the engineering reason for the requirements and how that really influences the schedule, cost and everything else the SE teams control. It means being good at Rocket Science! Where is the steady steam of those people into management?
The bulk of the managers are former catalogue designers or bean counters. "We don't need no stinkin' requirements!" types.
You are dead on when describing what SE is being used for. It is grossly misused by management. Fussing over process and procedure is not SE by any stretch. I like the quip. "Process and procedures are the last refuge for those who lack the wit and wisdom to do their jobs properly in the first place."
You are also right on target with the fact that one must have an idea what they are doing in order to do a competent job. Management openly admits that they are dumping people into SE that they don't know what to do with. Freshouts from college are not SE material. I have mentored a number of them to get into test or design and development to learn what works and what doesn't before trying to play the system synthesis or requirements game.
What I have tried to get across to management is that I can teach the mechanics of SE in a very short time. What cannot be taught is the art. That takes time, it takes specialized talent and not everyone has it. The art is something that they just cannot codify or mash into a cookbook approach to SE. I tell them that if they cannot "fly the mission in the theater of the mind, then find something else to do."
That said, it is time for us to find other venues through which to flourish and grow.
The best systems engineers came up through
the process and then spent a few years
in other disciplines.
Back in the 50's and 60's to be a SE,
you needed to have 3 masters, and at least
15 years experience. (Mechanical,
[electrical|controls], [Thermal|Aero]) and
and then you had to have a real feel for
mission and interaction.
Those people made awesome systems engineers.
Sticking some kid in, and giving them mass properties is a joke for training.
Post a Comment