As Byte56 said in the comment, whatever you choose to do first, goes first. There is no single rule that everyone should follow when it comes to developing a project. Different teams have different capabilities and needs. You might not have the available resources to do module A, but while you're working on getting the resources, you can do module B and save lots of time. If you build them properly, with a great enough degree of re-usability and independence, it won't be a problem at all.
Since we're pretty much in the same situation (right from the top, down to Unity 3D and Blender), I can tell you a few things. It might not do the job for you, even though it did for my team. And it would be best if you treated them as pieces of advice from someone else out there in the trenches.
- Build a test level, not related to your actual game content, and work on different module prototypes & features here. See what works and what does not. Only include the things that work in your actual game. If you're not sure about a particular feature, keep on testing it in-between schedules even if the team moved on to other things. Knowing what NOT to add to your game is just as important as knowing what to add to it.
- Concentrate on most of the player - environment interaction. Get the player's character to respond to the player's commands, and make sure he's able to interact with the world: pick up objects, examine objects, use objects, drop items etc.
Unity's editor will help you a lot in this case: before you actually get to work with dynamic content, you can see how things go with static content, inserted via the editor.
Basic dialogues go here too. While working on the dialogue system, the player can talk to a rock. It does not matter that much.
- If you've got a specialized programmer in the area of AI, get him a list of all of the AI behavior you're expecting to have in the game. Then, ask him to prepare a list of algorithms and methods to solve the given problems. While you go on with the player-environment interaction, the AI can be prototyped on paper. Or, as a library, outside your game.
- Leave the actual storyline and game content for later, when you've got at least a solid base built.
- This might be obvious: DON'T waste time asking your 3D artists to do extremely good looking models, until you've got the solid base I've been talking about earlier. Use ugly (or somewhat good looking, heh) placeholders for everything. Those X hours you save this way can be used to get yourself and the team to concentrate on other, more important things. Like the solid base.
This is a rough outline to get you started. You're saying that your game is comprised at around 60% of puzzles. Perhaps while someone else is prototyping the AI and combat, you can get those puzzles to be doable in the test level? As an indie developer, this can offer you tremendous advantages: you get to show people a PLAYABLE game, even if comprised only of puzzles and some basic GUI. You can consider getting some financing (on-site donations or kickstarter) this way.
Short version to always keep in mind: split your game in lots of smaller games, or iterations. Every time you add something to the game, try to obtain a playable something from it. You've built some traps? Try to make a real world, puzzle-like level with traps, and see how well they work. You've built a system that combines items? Try to invent a few simple puzzles that require the combination of items, and see how it feels. These are both playable somethings. Or playable parts of your grand game. Furthermore, at any point during development, you'll be having a playable something to look forward to, and a playable something which you built a short while back, that shows your actual progress. It helps with staying focused and keeping the morale of the whole team high.