Project Management

Project Management Central

Please login or join to subscribe to this thread
Lessons Learned
Hello to all members of PM I would like to create a database and I need YOUR help. I would like to gather as much lessons learned you have encountered during your career? I am not necessarily looking for something specific but everything related to project. Eventually I would love that this database is shared with everyone. you can either post it here or send it to me via e-mail at mikes.macneils@gmail.com? I appreciate you taking the time and helping all of us in becoming better PM.
Sort By:
Page: 1 2 next>
I can't speak for others, Michael, but most of my lessons learned are bound by confidentiality.

If you want us to provide generalized lessons learned, I suspect most of them can be traced back to the PMBOK. I'm not sure how much more we can add.
Michael -

I'd echo Stéphane's cautions. To be of true value, lessons need to have sufficient context and that tends to be organization-specific. Without that, you are left with a set of good project management practices which can be harvested from a number of books and online resources.

Now, if you decided to create a database focused on a very specific type of project, that might be a different story...

Kiron
Stephan and Kiron thanks for your reply. I should of said project related to project not specific. I agree most of these will be in the PMBOK but it could be less generalized... General example:

I.e.Wording/ Communication
I could of confused people by writing the word specific. So be clear and precise.
or
If i say shut the valve, someone replies you mean close the faucet and then i say just shut off the water this can get very confusing and now we are lost in conversation and one can assume i was talking about the faucet when I was trying to get the valve/ waterline shut.
Always control a conversation by using same terminology and be specific and don't switch terminology.

But Maybe you guys are right. I wouldn't want anyone to cross over confidentiality.
Most lessons learned are talked about in general through forums like this website. There is a way around confidentiality limitations by changing names, companies, some specifics (that can't be generalized). However, a database of anything worth its salt will need so many entries to make the data worthwhile, especially a broad area such as lesson learned. Further, a proper db setup isn't going to retrieve information via an email address. I imagine this would be a nightmare to collate for the recipient (you) ;-)
MM-
I am going to give this my best shot today:
1) Problem:
I find that Project Architects performing Detailed Engineering and Design (All) are failing to perform the checks required by the ISO 9000+ rules and issuing them to Contractors unverified. They also Fail to coordinate between their own Vendors. Underground utilities, MEP, Structural, Fire Suppression, Finishes always arrive to our field offices without any kind of Coordination or BIM Model checks.
The Problem seems to originate with the Architect who merely collects the Discipline Design files (sometimes not in CAD due to proprietary disputes) and passes them along. I suspect that the Designers do not possess the skillset of Constructability in- house.
Our Solution:
We Now gather our SME's at the Project level together and process the plans for a constructability review and commentary, even if we are not the Team that will manage the Project. We identify as many major conflicts and send the plans back for redesign. Unfortunately, this production of poor work product delays the start of many Projects, and causes conflicts with the Designers. I could name names ( I will not) but this problem is inherent across the Industry, including some of the most well respected Design Houses in the World.
That is my lessons learned the hard way- Do not trust the designer! (especially with BOQ's)!!!!
MM-
There are many LL examples we could supply without reference to specifics and without violating confidentiality.
I will attempt to visit this subject on a regular basis. This topic is a requirement for every Construction PM, and we all have LL Contributions to make...............
I have often contributed to several Team Members working on their Subject Matter Doctoral Thesis within our organizations or municipalities!
It's too easy!

M
MM-
The Problem:
A Company signed an EPC/LSTK Contract with a Client. Part of the process inherent in these Contracts (as you probably know) is that We are required to produce Detailed Engineering Design, based upon the Plans and specs already provided to us by the Client and the FEED (Front End Engineering Design) at the Bid Stage.
After Award, our Firm was convinced by the Client (reluctantly) to utilize the FEED for the Detailed design also. At the time, this idea was "sold" to us as a matter of convenience.
Problem:
The FEED made some major errors on the FEED design and utilized our DED time to correct those problems. Since the Major Errors were located in the Drainage design, the whole Site elevation needed to be revised. The FEED only discovered this error at the 90% completion of the DED. Our ability to reclaim the time delay and additional costs due to the raised elevation of the whole Project were obfuscated by the fact that we employed the FEED for the DED. When did the FEED responsibility stop and the DED begin?
The Lesson:
Always hire a separate designer to perform the third party check of the FEED Design to discover the major flaws in the FEED design! Never use the FEED for DED!
Always provide the best SME's within your organization to perform the thorough Constructability Review and supervision of the DED!
Always separate the DED!
( Constructability Reviews are always a top priority for me- I was not assigned to this particular Project until the completed DED- I have never allowed a DED to occur without my close direction-this reduces Execution problems in the field dramatically)


M
Mike I like your initiative and you are on the right track - but "Lessons Learned" (LL)- not the right tool. My previous employers religiously collected LLs only to file away to be forgotten or once pulled up found to be incoherent or completely irrelevant to the current project. Being one who hates to dwell on the past, I take my LLs and incorporate them into my Design Risk Register and categorize by Specifications. If I take all historic problems (By Specifications) and include them on my initial risk register, then the designers can address the historic problems or the Owner can manage the potential exposure and finally the contractors can address those missed by the designers-Owner. By getting out in front - you might actually make lessons learned obsolete.

Your list doesn't have to be specific just detailed enough to generate discussion in the risk meetings.
Mine too have confidentiality issue. However generalize lesson learnt can be shared,You require of which industry?
MM-
Do you have a specific area of interest? I can certainly supply you with LL in every category!
Give me an idea of your Area of Concern.

MM
Page: 1 2 next>  

Please login or join to reply

Content ID:
ADVERTISEMENTS

"The best way to become boring is to say everything."

- Voltaire

ADVERTISEMENT

Sponsors