Most of us like technology and like to show rapid progress. This combination tempts us to focus on the easy fun tasks in a project and to defer the challenges. There is certainly a place for rapid prototyping, agile programming, scrum, and mock-ups, especially when these tools are used to learn and resolve questions at minimal investment. Unfortunately I have seen many cases where these relatively empty shells are perceived as substantial progress..The end result is often described as the last 20% of the work takes 80% of the time. The reality is that by focusing on the easy work the accomplishments are overestimated and the remaining work which may even be impossible is grossly underestimated, but you look good because you’ve completed 90% of the tasks on the list.
I encountered a perfect example of this when I was interviewing a programmer with a masters degree for a business I owned. He listed a failed robotics venture on his resume and I asked him where he’d focused his effort and what critical challenges had to be addressed for that venture to succeed. He’d been spending investors’ money 20 years ago to develop a humanoid bipedal robot. I was thinking balancing on two legs, processing visions information, recognizing shapes, and coordinating hands and fingers would be on the list. His reply was that fast processors could handle that complexity. He had found a plastic material which looked like skin because he felt that people wouldn’t be comfortable working around a robot that didn’t have lifelike skin. I repeated my question about solutions to the fundamental challenges. He didn’t acknowledge any issues with these critical tasks which are still not well implemented today. Looking at the requirements bipedal motion wasn’t necessary. Wheels would work fine for a robot in an industrial environment. A hand which could do useful work coupled with vision to accommodate a varying environment should have been at the top of the list. Skin should not have occupied a single brain cell. At least I didn’t waste too much time on the interview. I wonder what the investors who had backed his venture were thinking.
The DOD had an atomic powered airplane project which is another example of focusing on noncritical tasks while trivializing deferring the impossible. An incredibly detailed set of plans was produced including menus for the crew which listed which days prunes would be served. Critical issues such as thrust versus weight were also on the table, but were not resolved before the extraneous details were generated. The issues which killed it centered on thrust versus weight which was probably not insoluble, and more intractable issues such as shielding a flying reactor and what happens to a lightweight reactor in a plane crash. There was some need for some basic data on weight and floor space required to support the long missions made possible by nuclear power, but this data already exists since every ship in the navy has to accommodate crews for weeks or months at a time. These questions could have been answered with a quick estimate of calories per day, weight per calorie, and volume per calorie. The money spent detailing crews quarters, menus, etc should have been spent on the fundamental go-no go issues.
The best way I know to avoid this is to identify the critical requirements. Then understand what must happen to meet these requirements, and finally ask yourself what might go wrong? A requirements tree is a quick visual way to begin this process. The requirements tree can be extended many levels and can include potential failures or a tabular Failure Mode Effects Analysis (FMEA) process can evaluate the risks. I usually add the failure risks to the tree during brainstorming and use the FMEA as a checklist for tasks, reviews, and to close out a safety analysis procedure.
Ironically one of the more maligned speeches of this decade said it well-There are known knowns. These are things we know that we know. There are known unknowns. That is to say, there are things that we know we don’t know. But there are also unknown unknowns. There are things we don’t know we don’t know. And if one looks throughout the history of our country and other free countries, it is the latter category that tend to be the difficult ones. I think in a separate speech he also referred to things we think we know which are wrong. I’m not going to discuss politics in this blog, but I have to admit I was surprised by the honesty. The points are to be aware of what you don’t know, where you might be wrong, how certain you can be in your decisions, and to focus some effort on analyzing, resolving, and managing the possibilities.
If all you have are simple tasks by all means dive in and go full speed ahead. If you have a difficult project with some uncertainty take the time to identify and face the uncertainty head on at the beginning. Don’t create a false sense of progress by doing lots of easy tasks and avoiding the ones you know might be show stoppers.
