Gene I have sent you some lesson learned from the technical side via e-mail. I think I used the first template you sent out. Not major ones, but there were some.
Comment by edaviles — February 24, 2008 @ 10:01 pm
Please remove the information about PHP and have it instead point to the Architecture & Design Document. Everything else looks great. Thanks!
Initiation
*Kickoff meeting
What Worked: Suggest a time/date for the kickoff meeting, and ask for consensus among the team members.
What did not Work: Wait for someone to decide for the date/time.
Lessons for Next Projec: Attend all meetings. Being reactive instead of proactive.
*Weekly meeting
What Worked: Bring all problems to the table for discussion during the meeting.
What did not Work: Asking question after the meeting.
Lessons for Next Project: Verbal communication is much effective than the written communication, especially in seeking the team agreement.
Planning
*Scope planning
What Worked: Study the predefined user requirements.
What did not Work: Browse through the requirements and do not pay attention to the requirements’ detail.
Lessons for Next Project: It costs 1000 times as much to fix errors once the project is deployed than to fix that same error during the requirements phase. Confusion surrounding the scope of the project is possibly the key single reason why project fails.
*Create WBS
What Worked: The project activities should be in agreement with the WBS.
What did not Work: When buffers are added to the schedule, Parkinson’s Law will kick in and the work will expand to fill the time allocated to it.
Lessons for Next Project: We need to define the work first and then estimate the work.
Execution
*Db Design and Creation
What Worked: Design the actual Db base on the predefined scope, in order to avoid scope creep, and ruing the coding phase.
What did not Work: Design the Db without taking the web server /engine compatibility issue into consideration.
Lessons for Next Project: Seek input from coding team on preferable Db structure before creating the Db.
Control & Monitoring
*Scope Verification and Control
What Worked: Post partial deliverable on the blog for team members’ review.
What did not Work: Post final deliverable on the blog without involving team members’ review in the intermediate development stage.
Lessons for Next Project: Clear specification statement and members’ input are beneficial tools for controlling scope creep.
*Review schedule
What Worked: Review and communication with team members through out the project life cycle on the final deadline and additional resources when needed.
What did not Work: Post final deliverable on the blog without involving team members’ review in the intermediate development stage.
When run into problem, wait and submit what you can without thinking of the consequences that it might fail the entire project.
Lessons for Next Project: Schedule issues cause the most conflict over the life of a project.
Gene I have sent you some lesson learned from the technical side via e-mail. I think I used the first template you sent out. Not major ones, but there were some.
Comment by edaviles — February 24, 2008 @ 10:01 pm
Please remove the information about PHP and have it instead point to the Architecture & Design Document. Everything else looks great. Thanks!
Comment by MI — February 24, 2008 @ 10:53 pm
Lessons Learned:
Initiation
*Kickoff meeting
What Worked: Suggest a time/date for the kickoff meeting, and ask for consensus among the team members.
What did not Work: Wait for someone to decide for the date/time.
Lessons for Next Projec: Attend all meetings. Being reactive instead of proactive.
*Weekly meeting
What Worked: Bring all problems to the table for discussion during the meeting.
What did not Work: Asking question after the meeting.
Lessons for Next Project: Verbal communication is much effective than the written communication, especially in seeking the team agreement.
Planning
*Scope planning
What Worked: Study the predefined user requirements.
What did not Work: Browse through the requirements and do not pay attention to the requirements’ detail.
Lessons for Next Project: It costs 1000 times as much to fix errors once the project is deployed than to fix that same error during the requirements phase. Confusion surrounding the scope of the project is possibly the key single reason why project fails.
*Create WBS
What Worked: The project activities should be in agreement with the WBS.
What did not Work: When buffers are added to the schedule, Parkinson’s Law will kick in and the work will expand to fill the time allocated to it.
Lessons for Next Project: We need to define the work first and then estimate the work.
Execution
*Db Design and Creation
What Worked: Design the actual Db base on the predefined scope, in order to avoid scope creep, and ruing the coding phase.
What did not Work: Design the Db without taking the web server /engine compatibility issue into consideration.
Lessons for Next Project: Seek input from coding team on preferable Db structure before creating the Db.
Control & Monitoring
*Scope Verification and Control
What Worked: Post partial deliverable on the blog for team members’ review.
What did not Work: Post final deliverable on the blog without involving team members’ review in the intermediate development stage.
Lessons for Next Project: Clear specification statement and members’ input are beneficial tools for controlling scope creep.
*Review schedule
What Worked: Review and communication with team members through out the project life cycle on the final deadline and additional resources when needed.
What did not Work: Post final deliverable on the blog without involving team members’ review in the intermediate development stage.
When run into problem, wait and submit what you can without thinking of the consequences that it might fail the entire project.
Lessons for Next Project: Schedule issues cause the most conflict over the life of a project.
-Leong.
Comment by Leong — February 25, 2008 @ 12:54 am
Thanks Leong, that’s very good.
Comment by admin — February 25, 2008 @ 1:07 am