<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/2.3.2" -->
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	>
<channel>
	<title>Comments on: Final Project Report VER 1.2</title>
	<link>http://www.boston-recruiting.com/archives/106</link>
	<description></description>
	<pubDate>Tue, 06 Jan 2009 05:27:48 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.3.2</generator>
		<item>
		<title>By: admin</title>
		<link>http://www.boston-recruiting.com/archives/106#comment-145</link>
		<dc:creator>admin</dc:creator>
		<pubDate>Mon, 25 Feb 2008 06:07:40 +0000</pubDate>
		<guid>http://www.boston-recruiting.com/archives/106#comment-145</guid>
		<description>Thanks Leong, that's very good.</description>
		<content:encoded><![CDATA[<p>Thanks Leong, that&#8217;s very good.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Leong</title>
		<link>http://www.boston-recruiting.com/archives/106#comment-144</link>
		<dc:creator>Leong</dc:creator>
		<pubDate>Mon, 25 Feb 2008 05:54:35 +0000</pubDate>
		<guid>http://www.boston-recruiting.com/archives/106#comment-144</guid>
		<description>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 &#038; 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.</description>
		<content:encoded><![CDATA[<p>Lessons Learned:</p>
<p>Initiation<br />
*Kickoff meeting<br />
What Worked: Suggest a time/date for the kickoff meeting, and ask for consensus among the team members.<br />
What did not Work: Wait for someone to decide for the date/time.<br />
Lessons for Next Projec: Attend all meetings. Being reactive instead of proactive.</p>
<p>*Weekly meeting<br />
What Worked: Bring all problems to the table for discussion during the meeting.<br />
What did not Work: Asking question after the meeting.<br />
Lessons for Next Project: Verbal communication is much effective than the written communication, especially in seeking the team agreement.</p>
<p>Planning<br />
*Scope planning<br />
What Worked: Study the predefined user requirements.<br />
What did not Work: Browse through the requirements and do not pay attention to the requirements’ detail.<br />
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.</p>
<p>*Create WBS<br />
What Worked: The project activities should be in agreement with the WBS.<br />
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.<br />
Lessons for Next Project: We need to define the work first and then estimate the work.</p>
<p>Execution<br />
*Db Design and Creation<br />
What Worked: Design the actual Db base on the predefined scope, in order to avoid scope creep, and ruing the coding phase.<br />
What did not Work: Design the Db without taking the web server /engine compatibility issue into consideration.<br />
Lessons for Next Project: Seek input from coding team on preferable Db structure before creating the Db.</p>
<p>Control &#038; Monitoring<br />
*Scope Verification and Control<br />
What Worked: Post partial deliverable on the blog for team members’ review.<br />
What did not Work: Post final deliverable on the blog without involving team members’ review in the intermediate development stage.<br />
Lessons for Next Project: Clear specification statement and members’ input are beneficial tools for controlling scope creep.</p>
<p>*Review schedule<br />
What Worked: Review and communication with team members through out the project life cycle on the final deadline and additional resources when needed.<br />
What did not Work: Post final deliverable on the blog without involving team members’ review in the intermediate development stage.<br />
When run into problem, wait and submit what you can without thinking of the consequences that it might fail the entire project.<br />
Lessons for Next Project: Schedule issues cause the most conflict over the life of a project.</p>
<p>-Leong.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: MI</title>
		<link>http://www.boston-recruiting.com/archives/106#comment-143</link>
		<dc:creator>MI</dc:creator>
		<pubDate>Mon, 25 Feb 2008 03:53:00 +0000</pubDate>
		<guid>http://www.boston-recruiting.com/archives/106#comment-143</guid>
		<description>Please remove the information about PHP and have it instead point to the Architecture &#038; Design Document. Everything else looks great. Thanks!</description>
		<content:encoded><![CDATA[<p>Please remove the information about PHP and have it instead point to the Architecture &#038; Design Document. Everything else looks great. Thanks!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: edaviles</title>
		<link>http://www.boston-recruiting.com/archives/106#comment-142</link>
		<dc:creator>edaviles</dc:creator>
		<pubDate>Mon, 25 Feb 2008 03:01:47 +0000</pubDate>
		<guid>http://www.boston-recruiting.com/archives/106#comment-142</guid>
		<description>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.</description>
		<content:encoded><![CDATA[<p>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.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
