Definition of Risk is "The possibility of suffering a loss" but that is pretty non-useful (IMHO) better is to describe the key elements of a risk. That is, when you can fill in each of these fields, you have a decent handle on "what is the risk?"
Condition - what is the circumstance, situation or setting that is causing concern, doubt, anxiety or uncertainty
Consequence - what is/are the possible outcomes of the current conditions
From there, additional elements can be attached, but getting each risk into the condition/consequence form helps find the essence and keeps the risks well scoped/managed.
In your example: "the programmers miss their estimates"
I would get the person who raised that to focus first on the condition: "The engineers aren't good at estimating" is different than "We don't understand enough of the system" Get them to be specific about the situation. Also, keep scope small... what is the hardest part to estimate? Is there anything that is less uncertain to estimate? 10 small but manageable risks are better than 1 risk that "the whole project is doomed" After they have the situation, then the consequence can be identified. In general these boil down to "cost, time and quality" (e.g. cost increases) Don't mix these tho. If the programmers miss their estimates, then the schedule is impacted (costs too, but the schedule is the primary impact and is what you will be managing directly)
Getting buy in: A few points...
- only add risks that can be managed. "The project is doomed" is
- Use the risk register to build a buffer that you
expose and manage visibly
- review the risk register (top 5-10) periodically (each week/2 week/month period)
- be relentless about closing risks and asking the team "what can we do about this risk?" the team will care if you care
Best risk reference I've ever encountered is the SEI's Continuous Risk Management Guidebook tough to find, but a great reference book!