Consultant

1995 to 1999

Negotiating settlements: In 1995, SBRC outsourced its IT department to the Computer Science Corporation (CSC )and CSC immediately put me to work at their client site. This meant the possibility of consulting with companies around the world. I was delighted. Although I never made it to places like Paris or Tokyo, I did get to see horse racing in Kentucky and taste fried scallops in Boston. One of my last gigs was with Western Data Systems (WDS), a software developer located closer to home (Calabasas). They were way behind schedule on releasing their next-generation ‘enterprise system’ – and there was plenty of blame going around. WDS was accusing the customers of delaying the beta-test while the customers were accusing WDS of shoddy work. They didn’t feel like it was their job to find system problems. They felt their responsibility was to ensure compliance. Now they were both pointing the finger at me for slowing things down even more. The line from a Bruce Springsteen song was going through my head “I’m caught in a cross-fire that I don’t understand.” I didn’t feel like a consultant at all. I figured the best thing I could do was roll-up my sleeves and start testing in-house, instead of waiting for the customer. WDS agreed to let me do this and even lent me a staff of QA folks. Now, the QA folks were good at testing things like graphical interfaces, but they didn’t have experience testing enterprise-software. I had us begin by simulating business operations (like ordering, shipping and billing) then started breaking down each operation into a set of business rules we could test for (like order-fulfillment and revenue-recognition). The QA folks were actually enjoying this while I was afraid we were getting farther behind. We couldn’t exhaustively test every possibility. I arranged for us to meet with the software developers and had them point out where the upgrades were made, especially the ones that changed the way the system was originally designed to work. Experience told me that this is where problems are most likely to occur. We went back and refined the test plans to target those areas for repetitive, scenario-like testing, while reducing everything else to a one-time set up. It worked. We were testing the system where it was most likely to fail, identifying more problems and getting faster turn-around from programming. At the same time, I was banking on the beta-site customers finding errors that we weren’t catching, and hoping we could get away with saying things like: ‘those are out-of-scope’ or ‘that’s best dealt with in the next service pack’. It was a bluff, but it worked. It even made us sound a little like Microsoft, which they considered to be a center of excellence (?) and it made me feel like a consultant again.