When doing an in-house IT project, such as in a bank, it's very common to have a team with significant differences in both skill and talent among its members. As the biggest factor in project success is usually the people, this is a major project risk, and needs to be managed appropriately.
What useful strategies have you found for dealing with these big skill/talent disparities?
My biggest suggestion is to try to pair people up so you have your stronger people to help lead, teach and guide the weaker. Try to have an environment where people do not feel ashamed for asking for help or advice. The less talented and skilled people will learn and become better at what they do, and the stronger people will inevitably learn something new from the less skilled individuals as well.
Assign work according to abilities. Most projects have a mixture of work that is "hard" and work that is "easy", so if you can give the easy stuff to the less-skilled people, they can contribute, learn things, and feel challenged, and the more-skilled people will appreciate not having to work on stuff that bores them.
The only truly effective way I've ever found of dealing with team members' disparate abilities is to work by myself. Since that by definition is not an option when dealing with teams, your best bet is to parcel up the work so that the most important pieces are done by the most capable developers. I think this happens a lot, and is one of the reasons that software tends to look so awful aesthetically: the user interface is often relegated to least-important status and given to the least-capable developers.
The single, biggest, most critically important thing is for the less-skilled people to know that they are less skilled and for them to respect the opinions and guidance of the more skilled people. If the less skilled people think that they are equal to or better than the more skilled people, then they will tend to argue for stupid ideas rather than learning, and that will damage both productivity and the product.
While it is important to recognize expertise and defer to that expertise, you also need to determine what strengths each team member has. Like it or not, you have to ensure that each member contributes productively to the project efforts. This means you must motivate them to contribute, and in a sense, find a place for their sense of importance to be recognized.
Your challenge is to not let the superstars overshadow the other members in a way that reminds the lesser skilled people that they are not superstars. The trick is to not slow the project down by worrying about the emotional state of each team member while maintaining morale.
If you have good designers, let them lead the design, but you may want to consider including the non superstars backup for the A-team. Have them help Q/A the design, keep up documentation. You can also assign people who do have great design skills as part of testing team. The is a good position for the old school folks - let the non-OO people do black box testing, and in some cases when time permits, let them participate in white box testing.
You'll need to remind the less experienced team members that they have a great opportunity to learn from some skilled people. They may not get to do the things that they want, but they will have the opportunity to participate, and when possible, take direction from the subject matter experts. Real life projects with real stakes will give the junior members great experience.
In the end, you'll need to service the project, and you will have to nicely but firmly remind the team what is at stake, and seek to give them meaningful duties that demonstrably contribute to the success of the project. Good luck.