We are building a fairly large HR application in ASP.NET MVC, and so far our controllers are becoming quite large. For example, we have an Employee controller, and all employee
I would organize the controllers roughly around the use cases and their logical grouping. E.g. if you have multiple administrative/HR-type use cases which are likely to be available to a limited group of people, bundle those in one controller. Other controllers could be organized around specific domain model objects - e.g. self-service leave management, salary queries etc. There's no hard and fast rule, you have to create a balance between not putting too much responsibility into a single controller vs. reuse of common internal structures.
Remember also that as much as possible you shouldn't have core business logic in your controllers. They really implement the front-end behavior while the real system rules should be in your domain model and service layer. As long as you keep things roughly within the right layer and reasonably decoupled, you can't go too far wrong with how you place the individual operations within your controllers.