在實際工作中，開發人員的考核一定要結合他們自己對工作的評估，即要求開發人員主動對自己的工作進行進度預期，并對組織進行進度承諾。也有可能出現下面的情況：開發人員為了逃避責任，故意将進度預期估算的過長。這時需要采用諸如“六頂帽子”、“平衡撲克”、“靈活故事”、“Delphi法”等多種方法求得近似真實的預期值。總的說，這個進度要得到受領任務人和整個團隊的基本認可。
當進度出現偏差時，管理者不應急于下結論，而應該綜合項目中新出現的各種可能影響進度的因素加以分析和權衡，譬如“客戶又提了一個新的需求，而且是優先級很高，是以原計劃進度做了變更”，再譬如“硬體還未到位，現在隻能在本地機上做示例代碼”等等現象。
在我的經驗中，當出現進度重大延誤（超過20%的進度延期時），在考核之前應主動與項目組相關成員約談，向他們指出目前進度延期的事實，聽取他們的陳述，很多時候開發人員會說具體的客觀原因，這時需要管理人員去據實判斷這些原因是否是由開發人員業務能力不夠或不夠勤勉造成的，因為開發的工作時間并不是固定不變的，存在很多加班或其它追加上班的情況，這時可以綜合考慮此段時間開發人員的加班時數的情況，如果進度落後又不追加工時，且沒有彙報的情況，據此可以綜合判斷屬于開發人員的進度延誤。在會上，不需要留情面，而應該嚴格指出問題。
需要注意的是，考核并不是結果，考核的目的是為了更好的促進員工工作的效率和主動性，是以，在會議結束前，還應商讨如何将進度改善的措施和手段。在會議上，管理者應當多聽、多看、多想，适當的時候應當讓成員自己提出整改方案，滿足成員的合理化要求和建議。
同時，管理者應注意對那些難度大、資源少、周期長的項目，要經常給予鼓勵和關注，在進度考核上，應适當放松尺度，對項目組成員的階段性成果，應在部門内進行公開表彰，很多時候，開發人員的自尊心是比較強的，對于他們努力的尊重和認可，也是績效激勵的一種手段。
另外，在崗位認定上，同一崗位應該細分職級，譬如同為“軟體開發工程師”，應當依據在企業内的工作态度、業務能力、服務年限、綜合素質等進行職級劃分，應該在企業内部培養“多勞者多得”的良好氛圍，避免假、大、空的報喜不報憂的人員反而被管理層看好的情況出現。
四）績效管理中品質如何管理、如何進行教育訓練、責任與權力如何平衡
針對開發的品質，因為項目普遍存在一個漸進式完善的過程，是以，品質需要靠項目組共同負責和推動。通常情況下，我會和項目組協商數個疊代版本，并在每一個版本進行整體品質檢查，而不是頻繁的對項目進行品質檢查，當然必要的品質跟蹤還是需要的，但日常的品質跟蹤不作為考核依據，隻作為項目組改善品質的提醒報告。這樣項目組可以把平時的工作專注在開發上，隻有在臨近品質監測點時，才會進行反複的檢查，以確定送出的版本是品質正常的。
針對教育訓練流于形式的問題，可以事先劃撥一定的教育訓練經費由項目組管理，項目組可以通過申報後核準要采取的教育訓練，并按教育訓練要求做教育訓練記錄與小結，由管理層對教育訓練成員進行教育訓練回報調查和抽查。這樣可以保證所有的教育訓練是項目組所必須的教育訓練，主動權掌握在項目組後，項目組教育訓練的積極性也大大增加了。
責任與權力的平衡其實還是離不開前面所描述的績效輔導，隻有在績效實施過程中不斷聽取員工的回報意見，才能獲得更加貼近企業戰略。
