实践证明这些计划都是纸上谈兵，有的严重超期，有的质量不过关，有的功能遗漏，很少按预期完成的。这也难怪，就是精心制定的计划都有偏差，何况是随便给出的呢。

这里总结一些个人经验，这是对简单任务而言的。所谓简单任务指的是能分到某个人头上的任务，不包括需要一个小组协同完成的任务（当然部分也适用于小组任务的）。

1.         对任务尽可能的细划。任务分得越细，考虑得越周到，遗漏的可能越少。同时我们对细小任务的估计更准确，我想这也是大家钟爱WBS的缘故吧。

2.         建立任务的风险列表。外在环境、技术难点、甚至近一段时间工作状态，都会影响任务的进度。风险很多，列出我们能处理的风险就差不多了，至于第三次世界大战之类的风险完全可以抛开。根据风险列表，在理想的计划上，加上一定的风险储备。

3.         征求做过类似任务的同事的意见。我们不是神仙，对从未有类似经验的任务，很难估计准确，征求做过类似任务的同事的意见是明智的做法，至少我们能从中了解一些潜在的风险。

4.         不断调整计划。计划不是不变的，早期的估计或多或少的有些偏差。随着任务的进展，一些风险的消除，以及这期间的经验积累，我们可以更准确的估计时间了。一般来说在任务预定时间过去30%左右时，重新评估一下任务计划是比较好的习惯。

5.         及时反馈任务的执行情况。特别是研究性任务，出现计划与实际较大差异的情况是很常见的。让你的上司清楚任务的执行情况，很有必要，一旦出现较大偏差，他可以对你提供帮助，或者对整体计划进行调整。切记不要在时间快完了，才报告出了大问题。

6.         计划要实事求是，不是估计时间越短越好。不要因为面子上的问题，把时间估计得过短。否则你的任务太重，不但会影响你的正常休息和工作情绪，最终无法完成时，面子丢了是小，影响整体计划是大。

7.         采用PSP中一些方法，评估自己的效率。记录在执行任务过程，你的时间分配情况，估计你在做某类事情时的效率，为以后类似的任务提供经验数据。

</XML> 
或者在XML标签中通过SRC属性引用： 
<XML ID="XMLID" SRC="customer.xml"></XML> 
也可以使用<SCRIPT>标签来创建一个数据岛： 
<SCRIPT LANGUAGE="xml" ID="XMLID"> 
  <customer> 
    <name>Mark Hanson</name> 
    <custID>81422</custID> 
  </customer> 
</SCRIPT>