Q:

How to make better software developers out of less-than-average ones? 

I've asked this before in other places, and I'm now turning to you guys to see what sort of advice you can offer. 
Some background: I'm a project manager at an offshore company.  I’m in no way the best that’s out there.  Most important (or so I believe) is that I am just as good as my team is.  I've been at it for the last 3 years.  
I don't get to choose the people I work with (can't hire or fire people).  We are using all sorts of methodologies (agile, scrum, waterfall, RUP, you-name-it).  We are holding both weekly and milestone meetings in which we are trying to learn what went wrong/right.  So,this is not a question of motivation (my employer is paying them more than fair, they get full employment benefits, etc ), nor one of simply teaching them new skills.  This is more about addressing a problem within the mind-set of the average developer. 
I've worked with a lot of people both good and bad during the years.  There were a few of them exceptional, but most of them were less-than average.  Most of the times I'm usually confronted with guys that are getting stuck way to often, guys that are skipping solutions as they are not careful enough to see past their own coding mistakes and guys that are simply drifting away from the tasks to wherever their day-dream takes them.  
I was wondering if (and how) can they be determined to properly pay attention to their work, to be able to determine solutions and to unstuck themselves without me having to check on their work 24/7.  
I would really love to worry myself that I'm intervening in their work too much, that I'm always giving them the solution without letting them think.  But at this point, I can't see this happening
Some ways I've been suggested to try so far are:

Make them read “Addison Wesley – Pragmatic Programmer”
and "Clean Code: A Handbook of Agile Software Craftsmanship" – hold periodic meetings for each chapter and discuss what they have learned so far. 
Hold some sort of "Quick&Great Code of the Week competition", using a new/unknown language for implementation – given that this would be a new language for everyone, this should give me/us an idea over who is missing what. 
Get the rest of the management team to analyze "a great TED talk about motivation by Dan Pink" and see if we find anything that works for further motivating them. 

So, I'm now wondering: is there anything else?  would this approach work?  
I'm also worried that even though I'll eventually set them on the right track, once the current project closes and the development team gets reassigned, they'll revert back to their old habits.  How can I make the knowledge "stick" and prevent this from happening? 

A:

The first question I have back at you is, what benchmark are you using to establish "average."   You say, 'most are below average.'   I would bet the performance of your most is your average.   I would further bet that your population of workers fits nicely into the standard performance curve, which means your MODE = Median = Mean.   I am going into this not to teach you statistics but to get you to re-examine your expectations and the stick against which you are measuring performance.   This is absolutely critical!   Because if you are measuring against a false stick, you will never get your team to improve; in fact, you may have adverse consequences. 
Here's the deal, the performance curve and probabilistic distribution say that you most likley have an average team with average individual performers.   Every now and again, you will get lucky, but you will also get unlucky and get a dud.   But you should plan assuming average performance by your human capability enablers.   Planning assuming otherwise will result in a likley too optimistic, unachievable plan and is not much more than wishful thinking. 
And since you cannot pick 'em, then you need to accept the level of performance you are getting and build internal quality controls to control defects and incrementally improve performance over time.   Throwing a ton of money into trying to make a change under this dynamic is a waste.   Any blip you might see may be nothing more than stochastic, with a return blip back to the mean (regression to the mean). 
That said, the three leading drivers to performance are purpose, autonomy, and mastery.   Make sure you understand what these are and starting building a culture that enables them.   If you are experiencing a special cause in lower performance, this may help.   (Making your team read a book, by the way, is not an enabler of any of these three.) 

A:

From what you are saying the issue is with attention to detail, review, and scope creep?  Whilst the points you mention above are useful and provide insight they won't give your team the kind of skills they need to master the development points you are raising.  That comes over time with the right direction (I'm assuming the resources you're working with are relatively junior, here). 
I'd also say that, whilst it's great to have a knowledge of the various methodologies you mention, it could be confusing to the developer as to what mode they should be operating in.  For example, the behaviours I'd expect from a programmer in a scrum environment would be very different from those expected in a more rigid ITIL based methodology.  Be careful not to confuse or give mixed messages. 
Can I suggest a few things that have worked for me in the past?  The key to all of them is to make them regular and reliable.  Repetition emphasises importance, and it will also ensure that the knowledge sticks. 

Work at hand / scope review: A once weekly session to review the work for the week, where it is assigned and, importantly, relate that back to the agreed scope.  This gives developers the 'big picture' view that they need in addition to the direction that limits their scope.  It also shows how what they do interacts with the work of those around them.  Minute that session so that people can refer back to it.  The disadvantage with this is that people tend not to shout up if the work defined in that session is completed early ;)
Peer review: People will learn greater attention to detail if they are encouraged to perform regular peer reviews of work.  We generally create checklists for particular deliverables to kick start this for resources who are already not quite hitting the required standard (eg.  Common mistakes to look for in every technical specification).  This should also start helping you with reducing your involvement over time as they improve. 
360 feedback: Feedback to anyone should be instant in order to have the greatest effect, and should be delivered in a constructive way.  Easier said than done, and requires some effort on your part to be willing to be direct.  Your developers, depending on the culture in which you are based, may feel less comfortable giving feedback to you, though.  Part of making this work is allowing them to let you know what their issues are.  You'd be surprised how often there's another reason for poor attention to detail and you should seek to tease this out of them in order to ensure your team is more effective.