对组员的水平/能力有了较准确地认识后，项目进行过程中有可能还会碰到一些难于处理的问题：有些组员保留自己的经验、能力，不肯充分发挥。产生的原因是多方面的，如存在心理不平衡感、持有一种歪曲的竞争意识、个人的情感因素、公司在管理/待遇方面存在明显不公平的地方、项目管理方式上有一些缺陷等。项目经理要发现问题的症结，能通过项目内手段处理好地自然好办，通过项目内手段处理不了的，需要与上级沟通寻求办法，如前述方式均无助，你可能不得不重新考虑项目的组织方式，重新设计计划。这样的情况有时在项目计划前也能发现，如你从组员的态度、工作中的精神表现能发现它们。
项目内手段有很多。与组员进行深入地交流，化解他们思想上的障结/包袱；利用表扬/批评、奖励/惩罚等方式也能起到较好地作用，能给组员带来成就感、荣誉感、耻辱感、失落感等，这些精神感觉/刺激如运用得当，能强化组员的效率、提高创造性、主动性、责任性。如果组员都自觉努力，发挥效率大于90%，采取宽松的任务管理方式能获得最好的效果；如果组员有一些不佳情况（行为上的/精神上的），发挥效率降到了90%以下，可以采取定期写工作总结的方式，如月工作报告，周工作报告，这种定期报告能促使组员不断审视自己的工作效率和工作业绩，从而注意保持或提高工作效率/工作量；如果组员效率降到了70%以下，你可以要求组员写工作日志，促使其注意保持每日的工作量，不同的组员可以作不同的要求，因为对一个非常自励的组员来说，过于频繁/严格的工作要求，会降低他的工作效率、抑制其创造性和主动性。假如组员的发挥效率降到了60%以下，那你就采取直接指定每日具体工作内容的方式进行管理，如制定日工作表格，日工作表格中计划安排了组员当日应完成的具体工作，每日下班前验收其工作成果，这种方式是一种严格的保证工作效率的方式，但它要付出较大地管理成本，如制定具体的日工作内容及检查工作的实施/完成是一个较繁重的工作，日工作计划会被频繁调整，有时还会感到无法拟订具体的工作内容（软件开发中经常如此）。
技术——准确把握项目的风险
对软件项目来说，项目进展过程也就是不断解决技术问题的过程。项目中包含的技术难点可能大部分已被明显地描述出来，对这些技术问题人们都能理解要安排的资源及准备付出的成本；有一些技术难点并非一开始就能描述清楚，它们需要在项目进行到一定地步后，才能看清楚；还有些技术问题普通人不能发现，只有那些经验丰富、水平较高的技术人员才能感觉到。
项目进行过程中遭遇到的直接影响到进度的技术问题不妨称之为技术卡点。如果项目进行前对技术卡点没有全部认识到，或认识有误，带来的后果是严重的。首先是打乱了项目计划（全局的或阶段的），然后是会使公司、上级怀疑你的能力及职业忠诚度问题（他们可能认为你是在故意制造事件、拖延怠工、养患自重…），会使你在各种明暗竞争中处于被动地位，甚至直接危及你管理的项目。当然，如果你确实感到能力不济，也要坦然承认。
在一个自动控制系统中，项目经理采用了一种新型的PLC控制器。他看了控制器的一些技术资料，觉得与他以前用过的控制器基本相近，于是他排好了计划，带领组员做好了设计，开始编程实现。相当部分的程序编好了，但他的组员遇到一个问题：控制器对时钟的处理方式与他们设计时理解的不同。设计时他们认为控制器的时钟是通过中断处理的，是不断运转不受程序影响的。而实际中发现该控制器的时钟是无中断处理的（无中断控制器触发），时钟前进是在每一次程序循环的结尾才由系统扫描处理。如果在同一个程序循环中设置了时钟初值又去判断时间差的话，永远得不到等待的差值，而且要使时钟比较精确，每一循环执行的程序必须尽量简短。而时钟在自动控制系统中极为重要（如延时、定时、关联设备的次序控制等）。这一细节性的技术问题，使项目组不得不重新设计，从头再来。
在一个大型的应用系统中，应用数据的组织非常复杂，大部分用户需求也迟迟不能明确，你为了及早进入开发，并减少以后其他需求明确时带来的影响，于是计划采用将部分对象移到数据库一端的设计方式（一般对象都放在程序一端，数据库主要作数据存储），这种方式可以通过数据库对象的调整来适应需求变化及数据结构的变化，减少已完成程序的修改。在此中，你采用的数据库是否支持会话标识，是否能透明地存储/获取会话数据，对你的设计将有比较大的影响，因为它对今后的优化数据获取方式、转换慢速视图等都是非常重要的。你需要通过实际编写例子去确证。
能否准确地意识到项目中的关键技术细节，与项目经理的知识范围、经验直接相关。项目经理要虚心，多听取各个方面及组员的意见，并要多查阅相关资料。清楚地了解项目中存在的关键技术细节，对项目经理来说是需要的，项目经理才能科学地制定计划、组织人员、把握方向/整体进度、正确评价组员业绩等等。
