Technical Risk is simply the risk associated directly with the knowledge base being employed and it's technical aspects including such things as understanding, reproducability and the like.

The Rules For Assessing Technical Risk are these:

	* Has it Ever Been Done Before? Yes or No -- If NO then the risk is High to Very High (for more degrees see KnowledgeGap)
	* If it has been done before have you done it before successfully? Yes -- then risk is low, No and risk is moderate at least.  If you have done it before but not very successfully then the risk is moderate or moderate to high
	* the overall risk to the project is a function of the number of such risky factors that are associated with the project.  Even one is a problem.  By the time you have four or five high risk factors the project may be undoable.  The key is whether the payoff is high enough to even try.  --RaySchneider
----
"Has it ever been done before?" is not a simple yes-or-no question. You need a more precise way to determine the KnowledgeGap-s involved. Also, complexity is an important factor in the total risk, so determining project complexity is necessary for assessing the TechnicalRisk.  -- YonatSharon
----
EliminateRisk.  --RonJeffries
-------
Both Ron and Sharon make some good points.  The decision rules above are a skeleton and certainly admit of degrees as pointed out in KnowledgeGap. I have always found that ''technical risk is a function of the degree of ignorance about the issues at hand.''
Software is particularly that way.  

If you really know how to do something is great depth, then turning it into software is pretty straightforward.  It is only when you don't really know or only think that you know that you run into trouble.  Ron's ExtremeProgramming practices seem to address that pretty well.
----
See TopTenRisks, RisksCatalog