Red: Not only if a startup or company sticks to a

Red: Not only if a startup or company sticks to a plan that can cause trouble, but many software projects are that way too.

The project I am currently working on and have been since its inception 4 years ago is the software for the next generation Navy Reconnaissance aircraft. Since the project started 4 years ago the architecture of the system has changed drastically from the original plan/design. In fact there was an abrupt change 1 year ago when one of the large well known defense contractors on the project was fired by the Navy and my company took on their work besides what we were originally contracted to do. That company’s software was a mess and completely unstable. The customer thought we were going to “fix” or “tweak” the other company’s software. I and others realized there was no fixing that software, the best course of action was to scrap their software and redesign it from the ground up as it was unnecessarily complex for what it really needed to do. That was part of the reason it was so unstable. We had to work hard to convince the Navy that they would need a 6 month schedule slip for us to scrap that software and rearchitect/redesign it. They were not happy but begrudgingly went along with the new plan. It was a grueling 6 months to do that with long hours but the effort paid off. The resulting system is unrecognizable from when the other company got fired. The system is now highly stable and the funny part is the Navy now talks like it was their idea all along when me and others had to work hard to convince them that was the right course of action. I am convinced if we had not done that, we would still be struggling to make that software work, a year later (this happened just about a year ago now when the other company got fired). I should mention the other company is one of the big defense contractors most people know of. Their reputation certainly took a hit for the work they did on this project.

I mention all of this as another example of how sticking to the original plan would have been disastrous and caused much more than the 6 month schedule hit to redesign that buggy software from the other company. You are right most plans need to evolve, no one hardly gets it right from the very beginning. I have seen that many times throughout my career, even when I was doing integrated circuit design years ago at IBM. One time there was this chip being designed at an IBM facility up in New York. They got to a point where they thought then were going to have to remove functionality from the chip because they were unwilling to consider a different plan of attack on solving a difficult computational problem. Their customer (a govt intelligence agency) went to the location I was at in Virginia asking for a second opinion. We came up with an alternate plan that kept 100% of the functionality in the computer chip and in the end allowed that system to be deployed without any reduced functionality. If the original plan had been kept that system would have been somewhat hampered in its capabilities.

These are just two examples I have been personally involved in where a plan had to be dramatically changed or the success of the project would have been jeopardized. One was a computer hardware project and one a computer software project. One was many years ago nearly at the start of my career and one was just a year ago. I have seen other examples throughout my career.

I was traveling yesterday evening so I haven’t had a chance to listen to the CC yet but will shortly. However from what I can see on the feedback on the board here I am not surprised it sounds like it went very well! I totally expected it would and am looking forward to listening to the replay. I did not submit any questions as I was very confident others would submit good questions and any things I was curious about would be answered.