Usually a team members have different skills of work (coding, communication, analyse and others). What PM can do to minimize the difference of skill in the team? Especially to grow average of skills level.
Usually PM doesn't have direct superior-subordinate relation with a project team so they can't just tell people to improve specific skills. What you can do is you can encourage people and try to convince them it would be good for them. After all they do grow as professionals that way, don't they?
You can also propose practices and techniques which are valuable for a project and at the same time they foster learning process among team members. Code review is something which comes to my mind in the first place. It helps to share knowledge about project itself but is also a great platform to exchange technical experience.
Having said that, you can't force people to adopt specific practices. As long as they don't see value for themselves they will either skip the practice or do it just for the sake of doing it, which basically makes it worthless.
Of course you can try to talk about the problem with functional manager(s) of discussed people. They have more power and often more authority over people so it's easier for them to convince people to adopt specific methods. Having the same background, e.g. a development manager who was once a developer, also plays its role here.
Having said that, I'm not sure you set the right goal. Personally I wouldn't try to minimize differences between people's skill sets. Actually vast majority of teams can leverage skills which are completely different. I would rather look for methods to help people to excel in their areas of competency than look for get everyone on average level with everything they do.
Find out what people are good at - the areas in which they are strong, rather than weak or merely average. Then encourage them to grow their strengths.
This will help them to know that you value their skill, rather than their weaknesses, and will make them feel safe. Safety helps learning!
Because they will be growing their strongest skills, others will get to see those skills in action too - so even weaker team members get stronger as a result. Weaker team members will have role-models for those skills, and will be able to act as role-models in the skills in which they are good, so confidence will grow too.
Rather than minimising the difference in skills, I would focus on maximising the overall skill of the team - which means using the strongest skills appropriately, and letting those strong people share their skills. Encourage teaching and mentoring (especially novice/expert pair-programming if you're in software). Allow the team to admit their weaknesses and use other team members to cover them. For instance, I am awful at estimating. Rather than being better at estimating, I would ask others how long it would take. Their better estimating skills make up for mine, and allow me to be free to do things I am better at.
In one project, we put up a list of skills and areas of code, languages, etc. and allowed people to write in other team members' names if they thought they were good, so that everyone knew who they could learn from if they needed help.
This also has the side-effect of letting the team bond and self-organise. Bonus!
If you would like to read more, I wrote about building experts with the Dreyfus model.
Training and practice with a good feedback loop can grow competencies to some degree. Each of us presents with varying limitations, motivations, and personalities so results can vary to no growth to a lot of growth in some or more areas.
But like Pawel, I question why you want to do this. All projects should have some training aspect to it, but I think a PM smartly limits its scope to training only those things necessary to do THAT project at THAT time, e.g., project's methods, processes and procedures, not a general growth in a person's skill set. They would get that as collateral damage, but that should not be a PM's goal. An operations manager would have that goal, but a PM is dealing with constrained resources, including time. It is a make or buy decision and, for projects, I think in most cases you buy it.
Your team comes with varying strengths and weaknesses. You would get more bang for your buck by simply aligning your work with the strengths of your team, allowing one team member to make up for a weakness of another.