User requirements

Are really important. One of the lessons learnt when I was a grasshopper (maybe still am), is that this needs to be dealt with continuously and you need to lead it. If there are any ambiguities, it needs to be cleared up. This needs to be done continuously at least on a weekly basis. Constant feedback is important, with priority on the major concerns.

Development and implementation time

For IT projects, I consider this a major risk, as it is the most expensive one and increase the risk for personnel resources. For IT the highest costs are skilled developer and engineer time. Anything the requires significant development time, is high risk. From experience development isn't a case of, let's put developer x for 5 days, and he will create 5 features. In 5 days, the first iteration, those 5 features are going result in the need for testing, result in new issues and an investment in particular code. User requirements become damn important here, as you need to make sure you're doing things so that the users can test early and provide feedback. Funcationality over gloss, is important at this stage.

Beyond that developers and engineers need to look at the technical risks and match it to user requirements. You'll need to test very early on, frameworks and components that you will be using. For example, if you're storing in an RDBMS.. does it have the features that allow you to deliver on the user requirements? These will need to be early testing focuses. As a real world example, one of Inigo's projects, the requirements was integration with different web applications or systems for user authentification which were undefined. "Undefined" means it's a high risk. So it was a testing focus way back and different authentification plugins was already evaluated and a difficult requirement was researched and communicated to the client. So when there was a suggestion to implement, we can be confident in delivering a quality solution, ahead of time. It's beyond the scope, but not beyond resources, which translates into a very happy client.

If it wasn't a testing focus, it would seem like it came out of the blue, and then developers would be pushed to implement something that their existing code base doesn't support near tight deadlines. Result? Possible delays, unanticipated problems, overtime, cutting back on something the client thought was an important requirement... well you know the drill, it's a common situation.

It can be avoided with proper processes that evaluate risks and sets the right priorities.

Resources

The previous risks also tie in to a major, major one.. human resources. None of the above matters then when you have nobody around or they are not productive. The risks are even higher if you count productiveness and quality of a good team, in addition to the acquired knowledge that may be lost. Look after your skilled staff, and have teams that overlap in skills.

Hardware, by comparison is an easy risk to manage. You just need to communicate to the client, the costs and risks clearly for this. Most clients just put in 99.9% uptime, but if you communicate with them the risks and downtime they are willing to tolerate, they may be thankful that the costs can be much lower by reducing it to say 95% uptime, and explain clearly that it will be up almost all the time, but if their is a hardware failure which is rare (once a year?), it may take up to 5 days before it is up again. People are happier when they understand the choices they have to make.