[Appologies if this is the wrong place for this but it seems most applicable]
I attended Alec's talk on "Project Failures - Known, Unknown" last night. Very interesting but could have done with about twice as much time as there was a lot of good material to cover in 90 minutes.
One of the key themes, not to give too much away, was that you need to learn from past issues so you don't make the same mistakes again (or at least not in the same way). At the end someone pointed out that his organisation run so many projects that if they collated all their 'Lessons Learned' there would be thousands of items, far too many for a project manager to read before starting a new project.
I have been in a similar situation where we had 7 major transformation programmes running concurrently, each made up of dozens or even hundreds of projects which each produced a number of lessons. Each programme had it's own PMO (Programme Management Office) and there was a central PMO (which is where I was). Our solution to the huge number of lessons learned was to get each programme PMO to collate the lessons learned for their projects then look for common lessons, common themes and similar lessons. Where ever possible lessons were combined with similar lessons to get the list down to a much smaller number of unique lessons, each of which was linked to the types of project that had generated one or more of the lessons which is was derived from (projects could be broadly divided into Feasibility/Requirements Gathering, IT, Business Process, Organisational Design and Construction) and back to the projectsd that had . These lists were then taken by the central PMO and representatives of each programme PMO and again we looked for common lessons, common themes and similar lessons then combined where we could. This got the list iof lessons learned down to a manageable number but also meant that we could prioritise a lesson according to project type (if a lesson only ever came up on, say, construction type projects then it probably wouldn't be relevant to an IT project) and frequency (something that came up in one project would propbably be of lower priority than one that came up in most) and track a lesson back to it's constituent parts and original project(s).
The key to this,and many other project issues (I believe) in an organisation that runs a lot of projects is to have a Portfolio/Programme/Project Management Office that is independent of the individual projects and exists past project closure. This PMO can act as custodian of information from closed projects, owner of the project methodologies/standards used, enforcer of those methodologies/standards when required and 'critical friend'/advisor when possible. It can also inteface with the Resourcing a Learning & Development functions to ensure that project staff have the project skills they need to do their job on the project.
Stephen