Years ago, I used an internal Work Implementation Plan for a DOD sponsor who unfortunately did not understand, and would not understand, DOD-STD-2167A.
After the contract was awarded and published, by sheer coincidence I attended a meeting together with the proposal managers of two of the three bidding compa- nies. The two managers had known me from my assignment at SHAPE in Belgium.
They knew that I had prepared the requirements, the architectural design, and the
interfaces; they also knew my habit from the military that I prepared a Work Imple- mentation Plan and figured the cost of the system to within10%. After the meet- ings of the day were over, when they were about to depart, they couldn’t help but ask me what I had estimated the system at, and said that if I told them, they’d tell me how much their companies had bid. I was intrigued for many reasons. For one, I wanted to know how close our estimates had been, and they, being professionals, also wanted the information. Secondly, as a JPL designer and manager, this was an opportunity for me to see how close industry was to estimating true software costs.
We agreed to write down two items of information on pieces of paper and put them into a cup. The two items of information were (1) total cost in dollars, and (2) total development time in calendar months. Mind you, these guys were serious pro- fessionals; one represented one of the largest American aircraft companies, and the other, one of the largest software and hardware contractors in industry. The result of our little exercise was not only impressive, but encouraging. My estimate after completing the requirements and design was $62.5 million, with a development time of 6 years. The other two estimates were $64 million, and $67 million. I can’t recall the schedule of either, but they were close, perhaps 8 to 12 months more than mine. Yet, the contract that the DOD agency awarded had been announced in the papers at just $16.7 million; those two guys were miffed, to say the least.
We talked about the difference for some time over coffee and donuts. The con- clusion was, of course, that the winning company couldn’t complete the system on that schedule and on that budget, especially with the management that was in place at the sponsoring agency. In fact, the system was never completed, and the con- tractor ended up suing the sponsor for mismanagement. For me it was a big lesson learned. It showed that most bidders are honest, hard working folk, who are proud of their products and are willing to put forth a true best effort. It also showed that when going out on a bid, you must have completed the FRD, SRD, SDD, and SISD before you can determine what your budget is. If you need the system, prepare these documents professionally. Then, if the budget doesn’t stretch, descope your require- ments and design by 10%. It is up to the successful bidder whether his people want to work as cost-effectively as we do, and have a greater profit margin, or to try to complete the project at the pace they select as being suitable for their workforce.
COST BIDDING TOO EARLY 199
14 Four Case Studies of Low-Cost Systems
For those who have managed or designed and participated in the development of software systems, it is nothing new to say that each system is unique, as each one carries with it its own special problems. For those who are young software pro- fessionals and computer scientists starting out on their careers, it is important to understand the pitfalls and inhibitors to low-cost development and how to deal with them. In fact, it is important to have at least an idea why things don’t get done. No one told me when I started out in computer science what to expect from the workplace environment, from the sponsor, or from colleagues and subor- dinates. It would have been easier for me to have known beforehand.
I have added this chapter with the intention of sharing with the reader informa- tion elements that are generally only found in military ‘‘after-action’’ reports. As mentioned in Chapter 4, an after-action report is a detailed description of what went right and what went wrong in an exercise (FTX/CPX) or combat action. It highlights interesting items, incidents, and activities that went according to plan and those that did not. These after-action reports are the tools that provide the participants of an exercise or combat operations the insight into events that are overlooked in the heat of actually participating in an event. The presentation of an after-action report is to be as objective as possible. What is important, however, is that it is through the after-action report that the analysis starts in the mind and forms the formalized template or hypothesis in the database of the mind. It increases the information in the files Immanuel Kant refers to as ‘‘wells of experi- ence,’’ and provides the foundations for decisions, botha priorianda posteriori, for future events. This exercise of information sharing is also the partial template that is the foundation of methodology in the toolbox of great engineers and scientists.
Unforeseen events are dealt with by referring to a number of similar experiences in the past, whereas the process of inferring solutions to new problems and applying them effectively is called creativity.
I didn’t start collecting data on systems development until the JTLS project, and these have survived only in summaries. As I started to build GDSS, I was more aware of the need to keep a good record of events and technical problems so I
The Cognitive Dynamics of Computer Science: Cost-Effective Large Scale Software Development, by Szabolcs Michael de Gyurky
Copyright#2006 by John Wiley & Sons, Inc.
200
wouldn’t make the same mistakes twice. This of course proved to be very valuable, because I found that even if I didn’t make the same mistakes twice, I made other mistakes to replace the ones I had avoided. Thus, it is my conclusion that the manager-architect who makes the fewest mistakes will be the one whose software quality is highest and whose product is cheapest. There are no perfect managers, engineers, or developers.
There are many reasons for overrunning a budget, slipping a schedule, and having many bugs in one’s software releases. The main reason of course is the relative expertise of the manager-architect, which includes lack of experience, dynamic energy, a work ethic, and the lack of positive leadership attributes. The other inhibitors are the lack of understanding and experience on the part of the sponsor or customer, and interference in the work process on the part of peer groups and ‘‘stakeholders,’’ as well as subordinates and employees. The poor approach to systems engineering and the interference with and outmaneuvering of the manager are not always badly motivated or done with malice; they are often the result of a mental limitation. All brains are not programmed the same way, nor have the same databases or well-developed reason as others. There are very intelligent, well-intentioned people who lack expertise in certain fields who try to force their will on a methodology. A design and implementation organization that is not appropriate can cause great harm in terms of budget, schedule, and product quality. These people can pose enormous problems to getting the job done.
For example, back in 1968 in Vietnam I was engaged in the only really terrible ambush I have ever been caught in. I and my platoon were so busy fighting that I had not even been aware that my reserve platoon, which I had hidden in a dry gully, had been pulled out and airlifted by my commanding officer, my own bri- gade commander. He was flying in his command helicopter over my position at about 3,000 feet, looking at the battle below. I was surrounded, and with all the gunfire, artillery, and close air support noise, I was unaware of the airlift HU1-Es coming in behind my back and airlifting out my reserve platoon. He was playing company commander, and put them down in another surprisingly devastating ambush of a large North Vietnamese unit, well entrenched just for that purpose.
Unaware of this, I called my reserve platoon, because I needed their help to rein- force the platoon I was with, and they were not where I thought they were. Now the platoon leader of my reserve platoon was asking for help, and he and his men were in trouble about a mile away from where I was, separated by jungle and a wide river, totally out of my reach to help them in any way. It was a terrible two days.
Clearly, my commanding officer did not have the intention of endangering me or my men. He was just a man of limited ability, an engineer type, managing and try- ing out some ill-conceived hypothesis from his perch at 3,000 feet. His hypothesis turned out to be wrong, ana prioridecision that was as wrong as Arthur Schopen- hauer predicteda prioridecisions to be, for he and his staff nearly got me and my men wiped out. This doesn’t mean that his intentions were not good; he just was not an expert in his field. He had been in the Corps of Engineers and had made a branch transfer to the Infantry to be able to make general.
FOUR CASE STUDIES OF LOW-COST SYSTEMS 201
So keep in mind that just because a project manager is inept, and just because corporate management interferes with negative impact on your work, they are not always trying to keep you from getting your job done. They may simply be well-intentioned morons, who kissed their way to the top.
So here are four case studies of systems that I managed, from start to comple- tion. Each could have a 300-page book written on it, but I present only the high- lights for the purpose of reinforcing the other chapters in this book.
A note is in order here. The following four case studies necessarily involve many technical issues particular to the software trade. Some of these issues are discussed at length. The reader who is not interested in such details may safely skip over them without loss of understanding.