Do you really want to commit resources to projects?
Or is the real objective to assure that resources are available to work project tasks when they are needed?
These are two very different things. The dedication of resources to projects can have undesirable side-effects, including...
...their non-availability to other projects which might benefit from their involvement, or
...the mis-assignment of scarce high-skilled resources to tasks that lesser mortals could easily do (or learn from) simply because they're assigned to the project and have nothing to do for the moment and are nervous about having nothing of real value to do.
Rather than obtaining commitments of resources to projects, you might want to consider commitments of lead time for requesting resources to work on specific tasks, so that when there's 3 weeks (or months) until the task in question, a "head's up" is given to let the resource manager know that the need is coming.
In the CC world, this mechanism is known either as a resource buffer or a resource alert, and is usually limited to use for resource on critical chain (path) tasks, or for particularly tough to manage "outside" resources like clients or users. It could also be used in a non-CC context, but since you won't have project or feeding buffers to absorb delays in resource availability, it might be even more useful.
Keep in mind that if the goal of the larger organization is to get maximum benefit from completed projects, staffing should be such that resources are waiting for tasks far more than tasks wait for resources.
One more thing -- the goal of either of these solutions -- your dedication to projects, or my dedication to tasks -- will be threatened if multi-tasking (expecting resources to be working on more than one non-trivial task in the same time frame, applying partial head-counts to eac, and bouncing back and forth between tasks before completing any of them) is seen as an appropriate approach to work.
But you knew that, right?
