Risk Assessment

Have you ever been in the position of needing to solve a problem with lots of unknowns? I'm sure you have. In fact, that probably describes every large engineering or software project you've ever worked on. This is a risk assessment problem.

The first time you design a program, you probably didn't do it quite right. Often it's better to build a prototype just to understand the problem first. In more extreme situations, not only will you not understand the problem, but the problem may not even have a solution or at least not a good one.

I have been in this situation. I have worked on a project where there wasn't a good solution to the problem (as far as I or anyone else could tell). When this occurs, it's your responsibility as the engineer to make sure the people who are accepting the project risks, understand those risks.

The person who needs to understand the risk may be a customer or manager who isn't technically minded. Imagine what they see. Picture a black box. You put A into the box and Q comes out. You put P into the box and C comes out. That may be all your customer understands. How could they know that by putting E in, the box blows up?

My solution to the risk problem was to keep informing my boss and his boss of the unlikelihood of success. (I was, however, a lowly paid intern; so, they could afford the risk.) I realize now that this wasn't good enough. I should have been trying to repeatedly explain why I thought the features they wanted were going to be near impossible to implement given the technology at hand.

In this particular case, my bosses were engineers themselves. But they didn't posses my depth of knowledge on the subject. So you can see how if even they couldn't understand, what the level of difficulty for a layperson to understand is.

When your understanding of the problem is far greater than your customer's understanding, you need to try very hard to put some kind of image in their head that roughly resembles your understanding of the problem. You need to go beyond saying "well it might not work." Tell them it will be hard to maintain, difficult to debug, and fail only at the most inopportune times. Tell them that if you have to design it in an awkward way, it will probably work just as awkwardly. Tell them what they need to know, not what they want to hear.