Scott points out Software Product Delivery – 20 Rules? that you should do the riskiest part of the project first. (He explains that you modify that given what's most important.)
I'd add a further refinement: that what's most important better provide the most value. If it doesn't, do the most valuable parts first. You might not have to do the riskiest parts.
I saw this in action yesterday. I taught my pragmatic project management workshop, where part of the workshop is to do a project. The project takes somewhere from an hour to two to complete, and has a tricky architectural part. The idea is that PMs need to be able to see if the architecture is working.
One team got stuck on an architecture that cannot work–the resulting product is not stable under any circumstances. They came to me for more materials. I'd already given them more materials than they needed. With my customer hat on, I said, “If I give you more materials, how do I know I'm not throwing good money after bad? It doesn't look to me as if this architecture will work.”
They were perturbed, to say the least. When we debriefed, they were still thinking that if I'd given them more materials, they would have succeeded. They were focused on the riskiest part of the project.
But if they'd thought about what was most valuable, I bet they would have developed another architecture–and they would have been successful.
Sometimes, release criteria can help you articulate what's most valuable. Sometimes you have to ask someone. But starting with the riskiest part of the project may not actually solve the value problem. If you start with what's most valuable, you're more likely to succeed.