An unrepeatable success?

Back in the very old days (early 80’s), I was on a team (of 24, I think) that delivered a successful software system on time, on budget, and with every feature the customer had requested.  The schedule had been tight, 18 months from inception to use, as I recall. 

This happened right in the middle of the “software crisis”, when failure after failure plagued the industry, especially on government projects.

After the balloons and toasts to our success, our management wanted us to tell them why we had succeeded so that they could try to apply these lessons to future projects (and bids).

One executive told me that he didn’t think this could ever happen again.  His reasoning was that we had had the opportunity to pick the best and brightest software engineers and hire a few bright new grads, and that isn’t always the case. (What he was telling me, in effect, is that sometimes you’re stuck with who you have on hand and can’t hire smarter people.)

I was pleased that they had asked for lessons learned on a success, so I happily went about trying to figure out everything that had gone right, and I tried to prove them wrong: that by doing some specific things we could have more such successes.

Here’s what I found:

●       We did have the very best, most experienced software engineers working on our team. 
●       These engineers turned out to be great teachers as well, and happily trained the new hires.
●       We all got along, liked each other, respected each other, and worked well together.
●       The project involved Space Shuttle communications, and was thus very prestigious and sexy.
●       We were given some software to “reuse” in our user interface, and it turned out to have been well-designed, well-implemented (very few bugs), and well-documented.  We got the source and were free to make any changes or copy techniques that we liked into our own design.  It was actually a reuse success story.

OK, those were factors that probably couldn’t be duplicated, the ones that were mostly luck and circumstance.  But there were more:

●       We were allowed to choose the hardware platforms that made sense for our application.  Along with this came the best operating systems of the era for the type of real-time application we were building, as well as a great tools, key factors in our decision.
●       We were able to choose the programming language: important if you remember the Air Force’s language mandates of the time.
●       We were allowed to create our own process.  We picked practices that made sense (design, code, test reviews that allowed progress to be measured, for example).
●       We decomposed the system design as far down as we could, and estimated the work for every piece we could think of (bottom up estimating), including documentation and time for attending peer reviews of others.
●       When we realized that some of the features couldn’t be done in time without more resources than were originally budgeted, we were given additional resources (a little more time and staff). 
●       We scheduled the development, person by person, using post-it notes on a conference room wall.  â˜º
●       We phased the development so that early versions of the system would be operational and we could see parts of the system working early on, giving us faith in our design and a platform for further testing.

The customer needed this system badly, and they knew that they were asking for an optimistic schedule.  They were therefore willing to give a little on the budget, and they were remarkably cooperative when we asked for clarifications, meetings, documents, and reviews.  I cannot emphasize enough how refreshing it was to work with an Air Force customer who understood the importance of prioritizing requirements and working with us, the contractor, to distill the project down to what they had to have and what we could build in the timeframe they needed it.  The trust they showed us was extraordinary, and perhaps, unusual.   I might have considered this “luck and circumstance” because it was so unusual for government projects; but for in-house, commercial products, this is a repeatable process.

So, what happened next?

Happily, all the good practices were refined and made standard for our organization, giving us an already-proven process that was accepted by management and engineers alike.

However, there remained the government-contract bid process which forced contractors to be overly optimistic (on price and schedule) with no opportunity for negotiation after a contract is won and more information uncovered.  And there were the government-mandated languages and hardware that often didn’t fit into the solution but had to be obeyed, nonetheless.

So, if I told you that the future included technically superior products that were delivered late and cost more than originally expected, would you be surprised?

Didn’t think so.

Anita Wotiz
www.duckpondsoftware.com (see the Consulting tab)
Instructor, UCSC Extension, SEQ Program
Software Requirements Engineering and Management (next class starts Aug 5 2008)
Software Project Planning, Monitoring, and Management (next class Oct/Nov 2008)