I just had my yearly Performance Assessment Review.
The yearly Performance Assessment Review is an exercise in wishful thinking. It is supposed to assist employees in setting goals and evaluating their progress on achieving those goals. But when you are working in an industry that focuses on product rather than process (or people), what is the point?
Companies are not in business to promote the welfare of their employees. They are in business to provide an income stream for owners and investors. If a by-product of this effort is to improve the marketability of their employees, that's a bonus effect, not a targeted goal. The ideal situation (for a Company) would be one in which the employees remain as fixed costs and known entities, producing a specific, targeted level of Quality at a known price, forever.
Companies, for the most part, admit that there is some advantage in giving some attention to employee satisfaction. Contented employees perform their jobs well. Discontented employees cause problems. The trick is balancing the contentedness and discontentedness without spending a great deal of money.
The industry in which I find myself is at a particular disadvantage in this regard because it requires employees with special knowledge, i.e. embedded systems. Most 'programmers' being trained in Universities these days are not learning embedded systems, at least not in school, not unless they are also in an Electrical Engineering course. They are learning Windows or Unix or Web-based programming. These are not directly applicable to embedded systems and avionics, although we could certainly use people with that knowledge base. We'd prefer people with backgrounds in aeronautics, microprocessor design, and hardware, though, since those are the issues that arise in the day-to-day operations of the company.
Specialized employees require special treatment. The Company's answer to this requirement is to pretend that they actually give a rip about their employees' career goals. So they stage these Performance Assessments under the guise of 'Career Management', when in actuality they're looking to see who is producing and who is not, so they can 'trim the fat'.
But we're already at a disadvantage because of the way contracts work in this industry.
How Contracts Work in Aerospace
Theoretically, contracts for avionics systems are bid and selected based on technical merit, risk factors, and cost/schedule projections. In reality, they are based on cost/schedule projections and sales/marketing hype.
Here’s the way it works.
Some customer – the Air Force, for example – decides that it’s time for an airplane to be brought up-to-date. The avionics in the airplane are over twenty years old. The cockpit is still using old-fashioned mechanical dials and instruments. Yuck! But the commercial world has lots of wonderful new technology that could greatly simplify navigation and communication. So somebody in the Air Force with friends in Congress pushes a Modernization Plan. Congress funds a Study to review the aircraft, and says, My Goodness! How could we let our Brave Boys in Blue fly those ancient museum pieces? Let’s get them some new equipment! And we’ll assign X million dollars for the effort.
And, oh, by the way, there’s this company in my constituency that would be perfect for the contract...
So then they (the Air Force, or “Customer”) put a bunch of pilots in a room and asks, What needs to be changed on this plane? And the pilots start listing all the things they’d like to have, and they come up with a preliminary Wish List. Then the Customer sends out this Wish List to a set of Industry Consultants who decide what is and isn’t possible. Unfortunately, some of these Consultants are also Sales and Marketing folks, or “S&M”, as we like to call them.
The S&M folks have a tendency to ignore Reality in lieu of Sales Projections. In fact, they generally operate by taking the rough budget figure assigned by Congress (this is a draft number which reflects the estimate of how much Congress can afford rather than a locked-down number tied to a specific product) and saying, What can we come up with that will cost this much money?
The reason they do this is that the yearly budget allocations are based on history of past spending rather than on projected costs; so if you don’t spend all the allocation from the last budget, they’ll cut it for the next budget. After all, you didn’t really need all that money last year, so why should we give you more this year? They ignore the obvious things, like inflation, maintenance, unexpected loss, etc.
So they break down the X million dollars into a sequence of Scheduled Milestones, like Developing Requirements, Getting Bids, Developing Prototypes, Developing Real Hardware, Testing, Acceptance, etc. They spend a few months writing up papers describing what they want, and they put these out in the “Public Arena” so the major avionics contractors can take a look at them and come up with proposals. Then they review all the proposals to decide which contractor has the best one.
Typically, they select the contractor with the lowest bid on the system which is closest to what they think they want. Unfortunately, all they have so far is a bunch of Sales and Marketing spiel which was based on offhand remarks by engineers who were sitting around dreaming one day, thinking, if we had unlimited time and money, what kind of system could we put together?
[These are the same engineers who, in 1995, when asked how long it would take to design and build an embedded operating system version of Windows 3.1, said, "About two weeks." Really. I actually worked for a company that staked their future on this statement. Two years later, they were still not done. Eventually, the project was shelved without ever seeing the light of day.]
So S&M folks write up this nifty-keen proposal, based on hearsay from the engineers, and create a way-cool PowerPoint dog-and-pony show, and perhaps even a preliminary prototype sample system that has blinky-blinky lights and some cool PC simulations to show the “pilot’s view” with CRT instrumentation instead of those clunky old hardware instruments, and the Customer swoons and claps and signs the first Big Check, and the project is off and running.
The Development Process
Now comes the Development Process. This is where we parse the project up into its requisite "Phases", like Requirements Phase, Design Phase, Implementation Phase, Test Phase, and Delivery Phase.
In this beginning, the pilots who came up with the first Wish List are key to the Requirements Phase. Their palms start sweating and their tongues start hanging out when they see the fancy CRT instrumentation and the flight simulations and the clutter reduction and the wonderful, seamless cockpit management system that will (obviously) solve all their problems and make mission planning a snap. But ... once they’ve signed on the dotted line, that’s the last you’ll hear from them until the Test Phase. Because they’ve already written their Wish List, and as far as they’re concerned, that’s the Requirements. Make it do what we want it to do. And don’t bother us with all the little details.
So you take their Wish List and have a few meetings to convert it into something resembling Requirements. And for a while everyone is happy. Once Requirements are documented, preliminary design begins. The Company's engineers start figuring out how to do the things they've been asked to do. It's just a matter of time before they get it all done. Just time. Right?
The Hidden Agenda
Well, not quite. You see, there's this thing called The Hidden Agenda. The Company, you see, has a Vision, and this Vision does not involve creating a host of little customized systems for each of their Customers. That is plainly not efficient use of the technology. No, they want to leverage the technology to create a System that will solve everyone's problems, something that they can spend a lot of money on at one time - hopefully someone else's money - and then make duplicates of it to sell to everyone else, with extremely high profit margins.
So the whole time the Customer was chattering about What They Want, the Company was politely nodding their collective heads, all the while wondering how to shape this project to be as generic as possible. They are thinking about other Customers' needs, and how it might be possible to make this new project work for everyone.
This, in and of itself, is actually a good thing, because having a single platform solution for multiple Customers is very efficient, reducing costs for each subsequent development effort. But - and this is a big but - they did not bid the project to be generic. The Customer would never have signed on for a project of that magnitude, because the Law of Software Development states that The More Generic the Software, the More Complex It Must Be. And that is a Law that cannot be subverted.
Why is this? you might ask. Simply put, it is more difficult to write a software function that can handle multiple circumstances rather than one that is designed to handle a specific circumstance.
For example, imagine you are writing software for a stop light. The simplest stop light is one which operates via a synchronized delay, turning green for a specific number of seconds, then amber, then red. Each color has a specified number of seconds of "on" time, and the color sequence is specific: green, then amber, then red.
Testing the software is simple. It can be done by observation with a stopwatch. It either follows the timed sequence, or it doesn't. Pass/Fail. Yes/No.
But what if you want to design it so that it handles different traffic flow patterns at different times of the day? Now you have to have a real-time clock controlling different time patterns. Now you have to verify that the real-time clock value is valid. Now you have to test it under varying traffic situations, at different times.
Generic functions are complex, and complex software development is very risky, both to costs and schedules.
And Customers don't like Risk.
So sometimes the Company isn't completely honest in revealing the Risk. Because that might reveal their Hidden Agenda to the Customer.
The Customer’s intent was to save oodles of money by utilizing a “commercial off-the-shelf” (COTS) system, which normally means a system which is already proven, available, with a known success record. But there is no COTS system yet - the Contractor wants to create the system with the Customer’s money. Do you see the obvious conflict here? You can’t save money – in fact, you never save money – by being the first customer for a new product. You get to endure all the Growing Pains. You get to find all the bugs. You get to spend all the up-front money. You get to be the Guinea Pig.
The Triangle Law
There is a rule in the Software Industry called The Triangle Law. It states that there are three variables that constitute a project: Cost, Quality, and Schedule. You can control one or two of them, but not all three. That is, you can specify a cost and aim for a Quality, but once those values are set, your schedule is determined and cannot be adjusted without affecting the other two. If you afterward try to adjust the schedule – say, to cut back on the hours assigned to complete the project – you will affect Quality negatively. If you try to increase Quality, you will push up the Costs or move out the Schedule. It is a three-way balancing act. There are no exceptions.
If you are the first customer for a product, there is no way to estimate Costs or Schedule or even Quality. There are too many unkowns. How will you know how much it will cost to build something if you’ve never built one before? How can you project a schedule when you don’t know how long it will take to test a product you’ve never built before? How can you determine the Quality of a product when you aren’t really sure what it’s going to do when you start testing it?
There is a sublevel to that Triangle Law which is specific to Avionics projects, or any project which mixes hardware and software. That is, both hardware and software are subject to their own Triangle Laws for development (Cost x Quality x Schedule), and these effects are reciprocal. It works like this: You can estimate a software schedule if you are developing software on a known hardware platform (that is, one that has been previously developed and tested). You can estimate a hardware schedule if you are going to run already-working software on a new hardware platform. But you cannot estimate a schedule for software or a hardware development if you are developing new software and new hardware at the same time. There are too many variables. If you run into a hardware problem, fixing it will impact the software – which means you have to stop software development in order to evaluate the impact to the software of any changes you’ve made to the hardware. And if you decide that you can’t fix the hardware due to costs or technical reasons, then you have to come up with a fix in software. And that’s the worst kind of fix, because it’s really a kludge to work around a hardware limitation which was not apparent during the initial design phase.
Either way, you’ve impacted the Schedule. And the Cost. And the Quality.
The Actuality
So. The hardware is designed. Some preliminary software is designed to work on it. It doesn’t work quite like we’d expected. There are a few hardware design changes required in order to get the software to work correctly. The hardware is redesigned (or “patched”). The software is changed. It almost works. A few software patches are thrown in to make things work a little better.
The Customer wants something in their lab, something they can start testing. They have their own schedules to meet. A preliminary set of hardware and software is delivered. It doesn’t work quite like they’d thought – because they failed to mention some critical design requirements to the Contractor. Meetings are held. Voices are raised. Designs are reviewed in more detail. More changes. New hardware. New software. New schedules.
It’s impossible to make anything useful out of this kind of project. No matter what you do, you’re tied to a millstone. You can't catch up. You can never deliver anything of Quality, because there simply isn't time. You establish a reputation for being late, or being shoddy, or both. And how do you overcome the stigma of the millstone project when that Annual Review comes around?
Oh, sure, everyone knows how hard you work, and they know that you are doing your best to put out Quality product, but none of that really helps when the Big Picture is a project heading south. Because you are too distracted by putting out fires and keeping up with impossible schedules to give a flying flip about career advancement and skill set enhancement and process improvement and all the other buzzwords that come up during a Performance Assessment. Because it is all based on the goals you set last year when you thought things were under control and you would be able to spend some time thinking about those pie-in-the-sky things.
My Review in Review
I had three main goals last year:
1. Support Internal and External Customers with Documentation and Training.
2. Train the new guys (2) in my group so they could be useful.
3. Update the Training Curriculum to keep it up-to-date with the changes in the Software, which included converting the Training Materials from classroom-based to web-based.
Of those three goals, only one was accomplished with any great success: training the new guys. Unfortunately, it was accomplished so well that the new guys were assigned more duties which eventually precluded their being of any use in the Training and Support group, which put it back entirely into my hands.
The Support task continues because the project continues; it is difficult to judge the quality of the job at this point, given that the software hasn't stabilized to the point of being reasonably supported yet.
The Curriculum has been sidelined by more "important" issues.
So the Performance Assessment was a bit of a let-down. I looked at my goals and realized that, in reality, there wasn't any solid evidence of accomplishment, other than the fact that the Customer hadn't complained about my level of Support (in fact, they had been somewhat complimentary).
In reality, my goal over the past year has been to keep feeding and housing my family. And other than the fact that the pay is good and the people are nice and the toys are fun, there’s really nothing career-enhancing about this job. It’s just a job.
But I suppose it beats sweeping floors for a living.
No comments:
Post a Comment