[Twoey Award]
Twoey's Coolest Links
Engineer Your Love Life

Part 2

Meeting the Right Person

In June 1994, I placed an ad in Washingtonian Magazine. This was definitely not the first time I had done this, although this ad perhaps described me the best, and was probably my most specific one in terms of constraints and requirements. It read, "Enthusiastic, eclectic engineer. 40, athletic, irreverent, dependable, affectionate SWM seeks fit, witty nonsmoking SWF unswayed by typical Washington yuppiness. Happiness is marrying your best friend and sharing a spontaneous, childfree, lifelong romance. Failing that, free chocolate."(14)

I received approximately 25 responses from the ad, one of them from Cathy. One of the biggest plusses about our relationship was that there was full communication right from the start. We could then, and still do, talk about anything and everything. To this day, our friends are amazed at how much we say to each other and how direct our discussions are. None of them really seems to understand our style, although they all say we are perfect for each other. This is one of the most important requirements for relationships as well as for well managed system engineering projects, it is critical to have effective communication among all the participants.

It became clear to me fairly early on that this relationship had a real chance to go somewhere. Fortunately, we each independently had very similar schedules, we both agreed that approximately six months was long enough to make a decision about permanence, if we got that far.

The stage of the relationship at this point was one of design refinement and multi-criteria analysis. The biggest potential for failure appeared to be Cathy's hesitancy to make a final decision on permanence, based on various past experiences. As part of a design analysis (and to objectively show her the final design was good), I had us both make compatibility lists as described by DeAngelis.(15) I was virtually certain that the results would verify that each of us was satisfying the other's partner requirements list while our overall relationship expectations (system operational requirements) were similar.

The compatibility list breaks down the requirements into ten general areas, and uses a method to assign a compatibility factor for each area, and an overall score. The ten areas are:

  1. Physical Style - appearance, eating habits, fitness habits, hygiene.
  2. Emotional Style - romance and affection, how partner treats you, expression of feelings.
  3. Social Style - personality traits, interaction with others.
  4. Intellectual Style - educational background, attitude toward learning and culture, creativity
  5. Sexual Style - attitude, skill, ability to enjoy
  6. Communication Style - how, attitude, other forms of expression
  7. Professional/Financial Style - money management, attitude toward success, work habits
  8. Personal Growth Style - self improvement, ability to change, willingness to work on relationship
  9. Spiritual Style - morals, philosophy of life, religious practices
  10. Interests and Hobbies

Fortunately (for me), the results confirmed my beliefs. We each rated the other as between 90% and 95% compatible, which is an exceptionally high score. The lowest category for each of us was physical style, not unexpected because we knew that each of us was not the other's physical ideal. However, we had already discussed this early on and it was clear that each of us was willing to trade off a less than ideal physical partner for other traits that were of greater importance. The basic requirement was met, although the ideal objective was not. This often occurs when incorporating the results of tradeoff analyses into the design.

Other detailed design, tests and evaluations were being performed during this time. We spent a lot of time at each other's places sharing everyday activities, things a couple would be doing at least 75% of the time. One test that was important for Cathy (but not for me) was to meet each other's parents. We did this about five months into the relationship, on nearly successive weekends we flew to Miami to meet mine; then hers happened to be here in DC on other business. The Miami trip, in particular, was about as stressful as anything I can imagine (for a variety of reasons), but looking back, it showed how well the system could function under harsh conditions.

From a systems engineering perspective, there was no formal test plan, nor any attempt to test each individual requirement. Most of the requirements were not "testable" in the usual sense; success or failure was a subjective determination by each partner and could not be quantitatively measured.

Preparing for Permanence

Toward the end of 1994, Cathy and I made the mutual agreement to make things permanent. At that point, our partnership system entered the stage of refinement of the system operational specifications, along with final acceptance testing. Final acceptance testing is normally performed before the system is deployed in the field; in our case the distinction between final acceptance and operational testing is somewhat blurred since we have already bought a house together. We plan on a May 1996 wedding, which will be the equivalent of system deployment.

During our final acceptance phase we have essentially been operating the system under real world conditions. While we had mutually established a set of ideal operational requirements before moving in together, now that we are actually living with each other we are getting an idea of how things will work firsthand. Instead of each person being 100% responsible for their own house and associated upkeep, we now have to share and allocate those responsibilities. In addition, differences in living styles and schedules must be addressed.

A prime example of an operational requirement that would have been difficult to verify and test up until this point is the allocation of cleaning chores, and what the standards will be. I'm much more tolerant of messiness than she is. We have had to compromise on the cleanliness standards for common spaces, while rooms that belong to an individual (like her study or my downstairs recreation room) are primarily the responsibility of that person.

Our biggest difference (we have known about this since the beginning) is that biologically we are total opposites. Cathy is a morning person and gets up at 5:15 to swim before work, while I am a night owl and like to stay up late. She gets cold at 70 degrees while I will wear shorts outside as long as it's above 50. Mostly, we have been able to work out compromises. In the morning she uses one of the spare bathrooms so I can fall back asleep, and at night I cuddle with her when she goes to bed (around 9:30) and then get up after she is asleep. We kept her heated waterbed so she can use that on nights when I get home late, then I wake her up and she moves to our regular bed.

For the most part, any changes or new requirements have been implemented by agreement, and everything has proceeded smoothly. I believe a large part of the reason was the careful selection process used to choose the two partners who function within the system. Having properly matched individual components of a system with respect to the overall system functional requirements is one of the by-products of a well managed project.

System Deployment

For the purposes of this paper, system deployment is defined as the wedding on May 11, 1996. (See our wedding page for details on this outrageous event) Since we view getting legally married as merely a formality that will have little practical impact on our present lives, I have limited the scope of the system deployment tasks to the wedding itself (non- deployment legal issues such as consolidating insurances are considered part of long term maintenance and support). We have developed a schedule that addresses various self-imposed constraints on when tasks need to be accomplished. Our primary scheduling constraints deal with our work and school schedules. We both expect to be very busy in late spring and hope to complete most of the tasks well before May. Since our wedding is going to be very informal, the necessary tasks and schedule are shown in the following table. I have identified and obtained a computer program to support this effort.

TaskSchedule
Obtain location Already done
Entertainment (DJ)Booked.
Meeting to discuss music needs to be scheduled
InvitationsPrepare and mail by Feb. 11, process as received
Guest accommodations
(hotel block reservation)
Feb. 11
Flowers Make arrangements by March 11
Wedding attire Select material by Jan 1
Place order by Feb. 1
Receive by April 1
License and officiant As soon after 60 days prior to deployment as possible
(constraint imposed by the state of Virginia)
Food and cake Pick caterer by Jan 1, order cake by April 1

Marriage and Beyond - An Ongoing Process

"Marriage is not a product, it's a kit. You don't buy it, you build it."(16) All the evidence to date indicates that Cathy and I have done a good job in preparing the system for actual deployment. However, good systems engineering management includes more than just deploying a working system. "A complicating aspect of evolutionary systems is that requirements satisfied in earlier stages of evolution may no longer be viewed by users as necessary, while entirely new ones may arise."(17) In order to periodically perform system assessment, various measures of effectiveness must be defined and measured. Then, a procedure for managing and implementing changes based on these assessments must be designed and followed. Support and maintenance plans must be established and followed to keep the system functioning smoothly. Finally, no system lasts forever. Plans must be made for eventual system retirement or disposal.

Assessment and Measures of Effectiveness

Cathy and I have discussed various criteria by which our relationship can be assessed for success. Not all can be easily quantitatively measured; in some cases the measurement is simply positive or negative feedback from one person to the other. Here is our current list:

Measure of EffectivenessCriteria for Satisfaction
Partner's happiness Reported qualitatively
Financial StatusNeeds better periodic measure, long term goal is retirement in 15 years
Number of fights per monthOne, at most. Target is zero.
Number of romantic encounters per week 3, minimum. May vary depending on external factors
Number of days per week having at least one hour of "together" time for talking or just relaxing 3, minimum. Target would be 5.

By these measures, we have been very successful to date. I am quite happy with our relationship, and I believe Cathy is also. We have a solid financial base to start from, and I estimate our incomes and net worth place us well above average for our age group (based on general knowledge I have from keeping up with financial news). In one and a half years we have not had a single fight or even a serious disagreement (hard to believe, but true). And we have easily satisfied the last two items.

At present, Cathy and I have no formal schedule for performing system assessments. Given the frequency at which we talk, most of our measures of effectiveness will be addressed informally at least a couple of times per month. While this may appear to be an unstructured plan, it is consistent with our mutually developed system requirements, and more importantly, has been tested and proven to work. There is a recognition that a more quantitative measure of financial status is needed in order to stay on track for the long term goal and various options have been discussed, including consulting a financial planner.

Maintenance and Support

Systems engineering management includes more than just acquiring a system that meets the original need. "Although a system may be designed and produced with the required effectiveness characteristics incorporated, these characteristics need to be retained for the duration of the life cycle through the accomplishment of good maintenance and support practices."(18) As I see it, there are three main activities for our system that fall into the maintenance and support category. These are staying employed, staying in good health, and keeping up with our individual hobbies.

Although Cathy and I presently have good jobs, the future is by no means certain (although since she works as a teacher for the county her job is fairly secure). I work as a systems engineer for MITRE; my job security is probably above average given the status of the contract I am presently working under and MITRE's corporate history. As part of a long term plan, both of us are presently enrolled in masters programs at GMU to increase both job security and job mobility. In fact, my decision to go back to school this fall was probably 80% knowing I should and 20% really wanting to. I had to trade off losing some of my free time vs. improving my job potential and decided that it was more important to go back to school.

Maintaining good health involves such things as exercise and having a good diet. I belong to a health club; Cathy swims nearly every morning, and we often go for walks together (a dual function, since we can also use that time for system assessment if we choose). Future plans may include taking cooking classes that will help us prepare interesting and healthy meals.

Keeping up with our independent hobbies is important since it represents a large part of us each maintaining a separate life outside the relationship. One of our primary operational requirements is that one person will not necessarily be responsible for entertaining the other, and to support this it is important that each person independently keep our own interests that we can do separately.

System Retirement

No system lasts forever, and good systems engineering management practice requires that plans be formulated for system retirement and disposal. Our system can end in two ways: either in divorce or when one partner dies. Both of us have estimated the probability of divorce to be very low, despite general statistics to the contrary. This is a reliability issue, and in our case the reliability of the system has been built into the design by choosing components wisely.

Our contingency plan for divorce is simple; we are relying on the other person to act reasonably if it does happen. This assumption is based on many of the personal attributes that we both required of the other person. Since we will not have children, the only real issue is how assets would be divided. The only real planning that could be done to address this contingency is to have a pre-nuptial agreement on managing assets. Since nearly all the financial risk with respect to this issue is mine (assetwise, I have significantly more than Cathy does), I have to weigh the dollar (and emotional) cost of having a legal agreement against the probability of us ever getting divorced and trusting Cathy to act in the manner that she has told me she would. I have decided a pre-nuptial agreement is not necessary.

Planning for the other case of system retirement falls under the category of estate and tax planning, plus various retirement plan and insurance issues. We have done no formal planning to date other than some related activities that support planning for retirement. There is no schedule or formal plan to address these issues, although we both realize that one will eventually be necessary. Given other management activities that will be happening in the next year, I doubt any action will be taken on this issue before then. With a few tasks related to this issue already completed (insurance coverages through work, beneficiary changes, etc.), we feel delaying the planning is an acceptable risk.

Conclusions and Recommendations

I thought the first part of the process (up until Cathy and I decided to be permanent) lent itself very well to a systems engineering management approach but after that it became much more difficult to apply an orderly process. I believe part of that is due to the fact that the first half was centered around my requirements only, while once Cathy and I became a couple there were two simultaneous evaluations (hers and mine) being performed. In addition, our interpersonal relationship dynamics tend to be anything but orderly, since the basis for our interaction is flexibility and tolerance.

Individual aspects of our relationship have system engineering parallels but our unstructured (but effective) approach to the relationship makes it difficult to apply the entire systems engineering management process as a whole. I did not feel that every system engineering management principle was applicable to this process. For example, a life cycle cost analysis was not needed since monetary cost was not an issue (I was not buying anything, and any associated "costs" to my lifestyle were reflected in my requirements).

From a systems engineering management point of view, I believe this has been as well managed a project as realistically possible, given the constraints of dealing with real people. The probability of the system meeting or even exceeding operational expectations appears quite high. This estimate is based on the extremely successful ongoing final acceptance testing and the fact that all effectiveness measures are being satisfied. To date, no significant problems or even potential for problems has arisen. We also have supporting data from observing and comparing our system to other systems, as well as obtaining independent feedback from our friends.

The only recommendations would be to adhere to the established plans, schedule and then execute future tasks that have been identified, continue system assessments, and modify the system as necessary based on assessment results.

Postscript

It's now several years later and everything is going great. We have had very few, if any, real fights, and only a couple of serious disagreements, and life together is always fun. This is no doubt highly related to our sensible decision to remain 100% CHILDFREE, and raise plants instead of rugrats.

Back to Part 1 Send email to me: larrykahn AT alum DOT mit DOT edu Back to my home page

References

  1. Miles, Ralph, F., Jr., Systems Concepts: Lectures on Contemporary Approaches to Systems, John Wiley & Sons, Inc., 1973.
  2. Federal Acquisition Regulation, U.S. Government Printing Office, 1988.
  3. Sage, Andrew, Ph.D., "The Many Faces of Systems Engineering", Journal of NCOSE, Vol. 1, No 1, July-Sept. 1994, p 45.
  4. Blanchard, Benjamin S., Systems Engineering Management, John Wiley and Sons, Inc., New York, 1991, p 21.
  5. Trotter, Robert, "The Three Faces of Love", Psychology Today, Sept. 1986.
  6. ibid. (quote from Robert Sternberg)
  7. Sills, Judith, How to Stop Looking for Someone Perfect and Find Someone to Love, Ballantine Books, New York, 1984.
  8. Sills, Judith, A Fine Romance, Ballantine Books, New York, 1987.
  9. DeAngelis, Beverly, Are You the One for Me, Dell Publishing, New York, 1992.
  10. Rechtin, Eberhard, Systems Architecting: Creating and Building Complex Systems, Prentice Hall, Inc., New York, 1991.
  11. Pugh, S., Total Design, Addison-Wesley, Menlo Park, 1991.
  12. Beam, Walter, Ph.D., "Evolutionary Systems: Arguments for Altered Processes and Practices", Journal of NCOSE, Vol. 1, No 1, July-Sept. 1994, p 115.
  13. Sills, How to Stop Looking for Someone Perfect and Find Someone to Love, p 46.
  14. Washingtonian Magazine, July 1994.
  15. DeAngelis, Are You the One for Me, p 366.
  16. Sills, A Fine Romance, p 265.
  17. Beam, p 115.
  18. Blanchard, p 61.
1