在IT行业，人员的跳槽是非常普遍的现象，甚至可以说非常频繁。人员的频繁变动对一个正在运行的项目来说是很大的风险。现实生活中有很多这样的例子：某个公司的业务或项目非常依赖于某个具体的人，一旦这个人因为某种原因离开这个公司，那么这个公司的业务或项目会受到非常大的影响，甚至可能会是毁灭性的打击。
一个好的公司不应该出现这样的情况，或者至少我们的项目管理人员应该防范这样的风险，把损失降到最低，或者让这种人员的变动不成为风险。
那么在项目中如何防范这种风险呢?如何做到当一个人离开项目后，其他的人能很快地补充上来，接替离开者的工作，team也能很容易做相应调整?这就要求在项目在Planning阶段就考虑人员变动的风险，简单地说就是做好Backup Plan。 一方面人员所掌握的Knowledge，Backup也需要掌握;另一方面，所有项目需要的Knowledge都要有相应的Document，而不是仅仅掌握在某个人或某几个人的头脑中;最后，要有清晰的process保证Backup Plan的顺利执行。 这样做的目的是我们加强对Knowledge的管理，弱化人与项目的耦合关系。
比如说，项目的PL(Project Leader)必须定义他的Backup PL，并有文档记录。公司在进行PL培训时，Backup PL也要参加。在定义了Backup PL后，PL要制定KT(Knowledge Transition) plan，通过一对一的具体的工作说明，让Backup PL掌握必要的项目Knowledge。
一个member从被挑选，到进入项目，再到独立胜任项目工作，把这个过程定义成正式的process，以让member尽快掌握项目所需knowledge为出发点。
下面来说说我们这个的维护项目的人员check-in process是如何做的。 (这篇文章主要说的是人员变动的风险防范，所以假设项目已经在运行，项目团队也已经存在)
我们假设项目中的人员A要离开项目，现在已经确认B能加入项目。我们要做的就是启动Induction Process。
首先，新进入的member需要阅读项目定义的Induction Manual，以掌握必要的信息。Induction Manual主要包括项目的概述，项目组织结构，项目中的配置管理，客户介绍，项目涉及到的技术，必要的培训，和项目中的主要活动等等。 主要是一些一般介绍，具体的内容有专门的文档，Induction Manual中有链接。
其次，新进入的member需要阅读Project Plan。这是项目中最重要的文档，每个member必须仔细阅读。Project Plan中对项目有详细的说明。
接下来A就要对B做KT(这里假设每个member要离开项目都需要提前一段时间提出，这样可以有时间寻找新的人员和KT。这点需要在每个人员进入项目时就规定好了的)。首先A要指定KT Plan，PL审批通过后，KT就可以开始了。KT的内容不仅仅包括A维护业务系统的具体技术与业务逻辑，还要包括维护过程中的Process介绍，各种项目相关工具的介绍，正在做的工作、遗留的问题、即将到来的工作等等。KT的内容还包括B申请项目，维护业务系统必要的，以及各种必要的权限。
KT过程中，工作仍以A为主;到KT的后期，要以B为主，A只是给以必要的帮助。KT后期还要做的一个重要的事情是A想业务系统的关键用户和相关team的人员正式通知他的工作将由B正式接替。
KT的最后一步是对KT进行验收。根据checklis