After I left Big Oil Company, I embarked on a career as an independent contractor. About 5 years later, as fate would have it, I was hired to do some consulting work for another division of Big Oil Company. It was then that I ran into the business executive who was the head of the aforementioned program. He was still head of the program. He looked lost and disoriented. I later learned that the program was implementing a mainframe system in conjunction with a large consulting organization.
I did some back-of-the-envelope calculations and estimated that this program had probably burned about 100 million USD over the 5 years. It was later scrapped and replaced with SAP. It is hard to imagine anything but a catastrophic negative return on investment. This obviously excludes the shattered careers and psychological suffering endured by many of the program’s participants.
I often asked myself what I would have done differently to change a negative outcome that was, from my perspective, predestined. There are no simple answers. Canceling the project early in its inception was not an organizational option, although it would have been the rational thing to do. Given the immature technologies (despite sophisticated vendor propaganda), the technical challenges alone may have doomed the effort.
But more than technology, Big Oil Company did not have a software development culture that would allow for the success of that project. Subsequent chapters will explain what I mean by “software development culture,” but you can rest assured that it does not mean game rooms, pool tables, Nerf gun fights, or a host of other dot-com bullshit pseudo-substitutes for a legitimate culture.
Life as an independent contractor was significantly more rewarding for several reasons. I was making more money. I was constantly working on the leading edge. I did not care about organizational issues that plague most projects. That doesn’t mean I ignored them. You can’t ignore organizational issues and be successful; I just cared less about specific outcomes (i.e. who won which turf war). I was a mercenary, and my job was to deliver as much value as I possibly could, period. Although life was better, economically speaking, I was still less than satisfied. I was looking for a project that I could bleed for, one for which I could really give a damn about the outcome. I wanted to create something that I could call my own. I learned a lesson: be careful what you ask for.
This was in 1989, and a couple of things happened that year that provided the opportunity I was looking for. I was doing some contract work for an engineering company that was developing a multi-user product that ran on a LAN. The product was being developed entirely in ‘C’. The database was an ISAM file handler called Ctree, from FairCom. At the time, the fact that Ctree was lightening fast and supported multi-user access across a Novell LAN was a big deal, technology wise. (SQL databases came on the PC scene 2 or 3 years later.)
My better half (introduced in this book’s dedication) was working at a large insurance company, providing technology support to the law department. She was tasked with reviewing PC based case management packages. I helped her with the review. At the time, this was a very immature space, and yet the packages were selling for upwards of $25K. From this review was born the idea of The Lawyer’s Desktop, a commercial product that we would spend the better part of 2 1/2 years bringing to market.