必ず行ってください、間違ったら取り返しがつきません。自分で何度も見直すことも重要ですが、ほかの人と比べる、ほかの手法と比べることをしてください。

見積もりが違ったら、その原因を探る、難しさの見積もり誤りがあったり、見積もり漏れがあるかも知れません。

できれば、主観的見積もりと客観的見積もりをくらべ食い違いがあった場合に規模、生産性、見比べて差の原因を探ってください。何等か見落としや前提条件の思い込みなどがあるかもしれません。

不安がある場合は、その分をリスク費として原価に追加しておくことも必要です。

ただし、不安だからと言って見積もりを膨らませるとそもそも受注できなくなります。

連休なのでこの辺で・・・

見積もりは重要な仕事の一つです。これはすべての計画に関わる問題になりますので正確にできる必要があります。
かかった工数だけあとから清算してよいという契約であれば、無駄がないことを証明するだけでよいのですが、通常は実現する機能に対して見積もりを行い、その金額がいくらになるかを提示したうえでその金額で契約となります。見積もりに誤りがあったとしても、お客様の責任でない限り費用の増加は認められません。
ここでいうチームリーダに求められる見積もりは「作業工数見積」です。見積もりには物の原価・管理費・リスク費・作業工数・経費・運用工数・機能外作業・外部委託作業などを積み上げた原価積算による原価見積などもありますが、ＰＭになる段階で学べばよいでしょう。まずは工数見積もりです。工数見積もりには大体、開発見積もりと構築作業見積もりがあります。(ほかにも管理や運用がありますがそれは別途)
工数見積もりの場合「まーこのくらいだろう！」という感じで見積もることも多いと思います。最終的にはそれでいいのかもしれませんが、だめです。
チームリーダとしての見積もりは、実現する機能単位の詳細な積み上げによる見積もりになります。個別見積もりの積み上げですね。
前提条件として、何を作るかわかっていることが必要です。ここに関してはお客様業務をわかっていること、お客様の言葉が理解できること、仕様の行間が読めることが重要です。これらができて初めて見積もることができます。「そんなこと言ったら初めての案件は何も取れないじゃないか！」とおっしゃるかもしれませんが、わからない案件はとらないでください。お互いに不幸になります。
業界の人をＰＪに入れるとか、類似システムを作ってきた人で構成するなどできないのであればやめるべきです。と！このレベルはマネージャレベルのはなしでしたね。(その案件をとるかの営業戦略だからです。)

開発見積もり手法を紹介していきます。どこぞのマネージメント本やコンサルの言うかっこいい書き方ではありません。
実態としてどう見積もるのかを書いています。わかりにくかったら解説しますので詳細は質問してください。こうあるべきだというあるべき論はあまり書かれていないのであしからず。(個人の見解です)

開発工数見積もり手法
(イ)規模生産性からの見積もり
(ロ)機能分割による見積もり
(ハ)類似類推による見積もり
(ニ)ＦＰ法
(ホ)相見積
(ヘ)タスク積みあげによる見積もり

その他見積もりをするうえで考慮すべきこと
スキルレベルの考慮
スケジュール
リスク
見積もり検証

について述べていきます。例によって、気ままに書きますので順番の前後等あります、気長にお待ちください。