IT部门年度计划

一是在和客户交流时可以根据情况调整自己的言论。

二是概括项目。在项目提案的开篇，先用最精炼的语言描述这个项目，一来有助于自己明确项目的内容和目的，二来可以让客户对自

己的项目更自信，有助于引导他们在下面的内容中跟着你的思路走。

三是明确项目需要的内容，可以清单的形式展现给客户。这可以明确的告诉客户，在这个项目中，我们需要在标准化流程中完成多少

内容。也可以让设计师和程序员明确自己需要完成的工作，着手开始准备。

道接下去要探讨确认执行方案。

五、给你的客户一个明确的时间表。虽然大部分项目是无法按照时间表的计划来顺利进行的，但是这仍然是非常必要的内容。要告诉

六、告诉客户在项目时间内我们的人员配置和安排。

七、多样报价方案。价格是一个项目最重要的组成部分之一，就像我以前说的，报高了不行，报低了也不行。需要在和客户沟通中了

解他们的承受能力和消费能力，不确定的时候，可以提供多种报价方案供选择，如以A方式进行是3W，以B方式进行是5W，这样第一次

提案后就可以明确客户心理价位区间，沟通后再调整方案。还有一种比较常用的方式就是价格区间，如3-5W这样。

前面的三、四、五、六部分都是为了报价做的铺垫，可以让客户清晰地知道最后报价中所包含的我们的劳动。

八、给你的客户做一个令人满意的承诺，告诉他们你有信心可以做好这个项目。

九、方案的最后不要忘记留下****和银行帐号

十、完成后重新梳理一遍，从专业的角度，以专业的语言。再编排好清晰的格式，可以打印了！

一、如何理解客户业务和客户需求

原则1:由粗到细，从宏观到微观。 必须先从宏观上了解客户业务的全貌，再逐步深入细节。因为对于客户的业务而言，我们是外行，如果从业务细节着手，很容易迷失方向，失去对业务核心的把握。同时要认识到，对于一个外行而言，我们对细节的深入也必定是有限的，不要指望自己能够无穷的彻底的了解每一个细枝末节。一是不可能有无限的时间给你了解，二是没有这个必要。因为未来的系统也不可能完全包办所有业务的细节，还有很多事情是要靠客户企业中这些具有专业技能的人来做的。

原则2:从不同层次的客户代表那里收集不同层次的需求 对于企业高层决策者，他会给你描述一个系统的大的功能蓝图，如使企业具有整体报价能力，能更好的服务于高端客户，能支持企业的重大业务决策等;对于企业各级管理者，他会给你讲述他这一层的管理需求，如能更好的进行部门员工的业绩考核、生成月度报表，更好的进行业务结算等;对于各级业务 *** 作人员，他可能给你谈及很多业务细节和 *** 作细节…… 在由上到下的逐级访谈中，对未来系统的描述就从一个大黑箱变成多个小黑箱，再变成透明、明确、详细的系统定义的过程。 客户业务调研和需求分析注定是一个不断细化的过程，不要指望一次访谈/调研就能穷尽，也不要指望一次开发过程就能得到完全满足客户梦中期待的那套系统来。因为事实上很多需求是隐性的，连用户都不清楚自己的需求。只有经过多次循环细化才可能把更多隐性的不断挖掘、暴露出来。

二、如何具体开展需求调研工作 

在RUP中定义需求工作流程的工作目的如下:

客户和其他涉众在系统的工作内容方面达成并保持一致;

2 使系统开发人员能够更清楚地了解系统需求;

3 定义系统边界(限定);

4 为计划迭代的技术内容提供基础;

5 为估算开发系统所需成本和时间提供基础;

6 定义系统的用户界面，重点是用户的需要和目标。 首先要做好业务调研。要尽早把已经收集到的业务资料熟悉起来，并在理解的基础上提炼出问题列表，制成调查问卷。业务调研的要求是一定要沉下去，深入细致的了解客户的业务流程，而不是急着赶工完成自己的需求工件设计和业务模型的建立。在了解各项业务流程的同时，与客户一同深入分析业务的实现逻辑，并记录下有关的实现案例信息，收集好、整理好、分析好有关的参考材料。 要把迭代的思想贯穿于从业务调研、需求分析，乃至项目实施的始终。

所谓迭代，就是我们老老实实承认我们没有能力一次就把事情做到尽善尽美。所以我们就先把一大部分有把握的地方做好，再在前面成功的基础上不断做好剩余的部分，最终就能无限接近于成功。设计编码过程是如此，业务调研和需求分析也是如此。 企业系统的设计开发与软件产品的设计开发有一个最大的不同，就是企业的需求肯定会变化，过去在变、调研的时候会变，系统实施后还会变。而我们要做的就是去适应这种变化。事实上，也正是因为我们采用的是面向对象的方法，才可能做到这一点。

因为面向对象的方法认为:对象的基本属性是客观的和不会频繁变化的，而对象间的关系则是可能不断变化的。所以我们在业务调研和需求分析中也要认识到这一点，把不变的沉淀下来，把可变的灵活性和变化的自主性留给客户。 各位都是做技术的，在业务调研和需求分析中难免会不由自主的考虑一些技术实现的问题。值得强调的是:需求与技术无关。在业务调研的时候要忠实的进行记录，不要因为你个人对实现的疑虑而对用户需求进行(过早的)修改和裁减。 要善于争取客户方各级人员(均是项目干系人，RUP中称为涉众)的支持。只有得到未来系统用户的充分参与，项目才有可能最终取得成功。一套缺乏用户参与的系统，即使最后做出来也是注定没有人去用的。 一是要利用客户企业的组织关系，争取到上层的支持，由上到下进行调研配合;二是要会在调研过程中为目标用户树立有针对性的愿景，让他认同愿景的同时主动、积极的支持你的调研过程。

希望可以帮到您，谢谢！

IT年度计划范文是没用的，大概给你讲讲吧。

1、首先你要摸清公司现有的的IT现状，特别是你要负责的那三个内容。如果你很清楚，可以写计划化了；如果不清楚，先去调研吧。等调研好了，就把公司现状写在计划开头吧。

2、找出最严峻那一项先做，一般都是硬件。如果硬件没问题，那就考虑软件，看看什么该买，什么该换。准备什么时候开始，计划什么时候结束，可以达到什么效果。记住，信息化是烧钱的地方，所以一定要言之有物。如果你调研的详细，甚至可以按上一年度的IT支出做一份年度预算出来。

3、“消费者会员信息管理”，这是大头。如果你们公司软硬件没太大的问题，那么这就要详细写了。如果没软件，就要花时间去采购、招标。如果有，那就要分析是否合适，是否要升级。

4、员工培训，这要按你们公司的员工水平来分析。一年要培训几次，找谁培训，大概费用。都要写清楚。

反正计划一定要写清楚原因——可能达到的效果——时间节点——预估的费用。有这些就不错了。至于日常维护什么的随手提一下就好，如果设备维护是外包的，那就多提一下外包的方式。

大概就这些吧，不过你是新组建的部门。那建议你随计划再上交一份IT管理制度吧。制度在网上可以找到范文，不外乎就是员工上网规范、日常维护的流程、关键数据的备份制度，机房的管理等。一份制度、一份预算，再加上计划就很完美了。

也就是第一年你写得麻烦，以后每年就写个当年主要项目计划和预算，就可以了。象软硬件维护、员工培训作为常态管理都可以写在制度里的，只要每年出个预算就OK。

即使在最完美的条件下，管理一个软件项目也是很困难的。不幸的是，许多新项目经理实质上没有受到任何就职培训。这里有20个成功的管理经验供项目经理参考。不过，只依靠某一两条“妙计”，是无法顺利完成项目的。

1定义项目成功的标准

在项目的开始，要保证各方对于判断项目是否成功有统一的认识。通常，跟紧预定的进度是明显的成功要素，但是肯定还有其他的因素存在，比如，增加市场占有率、获得指定的销售量或销售额、取得特定用户满意程度、淘汰一个高维护需求的遗留系统等。

2把握各种要求之间的平衡

每个项目都需要平衡它的功能、人员、预算、进度和质量目标。我们把以上五个项目方面中的每一个方面，综合成一个约束条件，你必须在这个约束中进行 *** 作;你也可以定义成与项目成功对应的驱动力，或者定义成通向成功的自由程度。可以在一个规定的范围内调整。

3定义产品发布标准

在项目早期，要决定用什么标准来确定产品是否准备好发布了。你可以将发布标准基于：还存在有多少个高优先级的缺陷，性能度量，特定功能完全可 *** 作，或其他方面表明项目已经达到了它的目的。不管你选择了什么标准，都应该是可实现的、可测量的、文档化的，并且与客户所指的“质量”一致。

4沟通

尽管可能无意中了不可能的事件，但不要做一个明知不能保证的。坦诚地和客户和管理人员沟通那些实际成果。任何以前项目的数据会帮助你做说服他们的论据，虽然这对于不讲道理的人来说没有真正的作用。

5写一个计划

有些人认为，花时间写计划还不如花时间写代码，但是我不这么认为。困难的部分不是写计划，困难的部分是做这个计划——思考，沟通，权衡，交流，提问并且倾听。你用来分析解决问题需要花费的时间，会减少项目以后会带给你的意外。

6把任务分解成“英寸大小的小圆石”

“英寸大小的小圆石”是缩小了的里程碑。把大任务分解成多个小任务，帮助你更加精确地估计它们，暴露出在其他情况下你可能没有想到的工作活动，并且保证更加精确、细密的状态跟踪。

7为大任务制定计划工作表

如果你的组经常承担某种特定的通用任务，你需要为这些任务开发一个活动检查列表和计划工作表。每个检查列表应该包括这个大任务可能需要的所有步骤。这些检查列表和工作表将帮助小组成员确定和评估与他必须处理的大任务相关的工作量。

8计划中，在质量控制活动后应该有修改工作

几乎所有的质量控制活动，如测试和技术评审，都会发现缺陷或其他提高的可能。你的项目进度或工作细分结构，应该把每次质量控制活动后的修改，作为一个单独的任务包括进去。如果你事实上不用做任何的修改，很好，你已经走在了计划的前面。

9为“过程改进”安排时间

你的小组成员已经淹没在他们当前的项目中，但是如果你想把你的组提升到一个更高的软件工程能力水平，你就必须投一些时间在“过程改进”上。从你的项目进度中留出一些时间，因为软件项目活动应该包括做能够帮助你下一个项目更加成功的过程改进。不要把你项目成员可以利用的时间100%的投入到项目任务中，然后惊讶于为什么他们在主动提高方面没有任何进展。

10管理项目的风险

如果你不去识别和控制风险，那么它们会控制你。在项目计划时花一些时间集体讨论可能的风险因素，评估它们的潜在危害，并且决定你如何减轻或预防它们。

11根据工作计划而不是日历来估计

人们通常以日历时间做估计，但是我倾向于估计与任务相关联的工作计划(以“人时”为单位)的数量，然后把工作计划转换为日历时间的估计。这个转换基于每天我有多少有效的小时花费在项目任务上，我可能碰到的任何打断或突发调整请求、会议，和所有其他会让耗费时间的地方。

12不要为人员安排超过工作时间80%的任务量

跟踪你的组员每周实际花费在项目指定工作上的平均小时数，实在会让人吃惊。与我们被要求做的许多活动相关的任务切换的开销，显著地降低了我们的工作效率。一个员工一周理论上工作40小时，但不要只是因为有人在一项特定工作上每周花费10小时，就去假设他或她可以马上做4个这种任务，如果他或她能够处理完3个任务，你就很幸运了。

13将培训时间放到计划中

确定你的组员每年在培训上花费多少时间，并把它从组员工作在指定项目任务上的可用时间中减去。你可能在平均值中早已经减去了休假时间、生病时间和其他的时间，对于培训时间也要同样的处理。

14记录你的估算和你是如何达到估算的

当你准备估算你的工作时，把它们记录下来，并且记录你是如何完成每个任务的。理解创建估算所用的假设和方法，能够使它们在必要的时候更容易防护和调整，而且它将帮助你改善你的估算过程。

15记录估算并且使用估算工具

有很多商业工具可以帮助你估算整个项目。根据它们真实项目经验的巨大数据库，这些工具可以给你一个可能的进度和人员分配安排选择。它们同样能够帮助你避免进入“不可能区域”，即将任务量、小组劳动力和进度安排组合起来一看，根本不可能成功。

16遵守学习曲线

如果你在项目中第一次尝试新的过程、工具或技术，你必须承受短期内生产力降低的代价。不要期望在新软件工程方法的第一次尝试中就获得惊人的效益，在进度安排中考虑不可避免的学习曲线。

17考虑意外缓冲

事情不会像你项目计划的一样准确地进行，所以你的预算和进度安排应该在主要阶段后面包括一些意外的缓冲，以适应无法预料的事件。不幸的是，你的管理者或客户可能把这些缓冲作为你的托辞，而不是明智地承认事实确实如此。向他们指明一些以前项目不愉快的意外，来说明你的深谋远虑。

18记录实际情况与估算情况

如果你不记录花费在每项任务上的实际工作时间，并和你的估算做比较，你将永远不能提高你的估算能力，你的估算将永远是猜测。

19只有当任务100%完成时，才认为该任务完成

使用英寸大小的小圆石的一个好处是：你可以区分每个小任务要么完成了，要么没有完成。这比估计一个大任务在某个时候完成了多少百分比要实在得多。使用明确的标准来判断一个步骤是否真正的完成了。

20公开、公正地跟踪项目状态

创建一个良好的风气，让项目成员对准确地报告项目的状态感到安全。努力让项目在准确的、基于数据的事实基础上运行，而不是从因为害怕报告坏消息而产生的令人误解的乐观主义。使用项目状态信息在必要的时候进行纠正 *** 作，并且在条件允许时进行表扬。

以上就是关于IT项目如何写提案全部的内容，包括:IT项目如何写提案、IT行业,用项目如何找需求清单、IT部门年度计划等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！