この記事では小規模なプロジェクトだからといって、プロジェクト・マネジメントの基礎を怠ると確実に失敗する、という自戒の念を込めて「少人数の社内プロジェクト」で気をつけること5つをまとめています。

プロジェクト・マネジメントの技法、とくにPMBOKは大型の受注型プロジェクトを想定されているなんて言われます。小さいプロジェクトはそこまでプロジェクトマネジメントの知識がなくても成功できる、なんて考えている人も少なくないでしょう。というか、小さなプロジェクトだと、「プロジェクト」が何なのか、とか、「プロジェクトマネジメントの基礎」なんて知らなくてもなんとかなることが多いな、と10年以上社会人をやっていると感じます。

でも、本当にそうなんでしょうか？？最近経験した小規模な仕事を通じて、小さいプロジェクトほどプロジェクトマネジメントの基礎が大事というのを痛感してきました。

 

小さな社内プロジェクトは罠が多い

この記事では、小さいプロジェクトを「5名程度のコアメンバーが行う、3-4ヶ月の仕事」と想定します。メンバーは原則同じ会社の正社員で、複数部署にまたがるという想定です。

社内の業務プロセスを改善したり、各部署を代表したメンバーで新事業を検討したり、新しいツールを社内導入したり、そんなプロジェクトだと、コアメンバーが5名程度で推進することが多いと思います。

難易度は高くないし、メンバーもそこそこ優秀なので、誰もが失敗など想定しない、簡単な仕事です。

しかし、こういうプロジェクトって思っている以上に失敗する可能性が高い、と周りをみて気づきました。

小さな社内プロジェクトの罠

私が観測した範囲では、小さなプロジェクトの罠は次のものがあります。

  • チームが小さいのでリーダーや意思決定者が曖昧になる
  • とくにプロマネの役割が曖昧で明確なプロマネがいない
  • 片手間に推進する案件なので、メンバーの予定が揃いづらく、なかなか集まれない
  • 集まって議論をすると「あれ？前回どこまでいったっけ？」と記憶喪失が多発する
  • コアメンバーは少ないけど、その上司からの横槍で方針がコロコロ変えられる
  • 案件が小さいので変更要求が多発し、納期がアヤフヤになる

心当たりはありませんか？（これは全て自分が体験した実話です）

そんなわけで「小さい仕事だから…」とたかをくくっていると、何一つ成し遂げられずにプロジェクトがうやむやになって解消され、チームメンバーも「片手間の仕事だったから…」とトータルすると決して少なくない工数を投じた事実から目を背けがちです。

小さな社内プロジェクトがなぜ失敗するのか？

せっかく仕事をする以上、無駄な時間を過ごしたくはありませんよね？なぜ小さな社内プロジェクトは失敗するのでしょうか？

先程列挙した「罠」が全てを物語っているんですが、全ての理由は「小さな社内プロジェクト」という単語に詰め込まれています。

小さいからみんな油断します。小さいからみんな他の用事を優先します。社内だから納期に対する意識が低くなりがちです。社内だからスコープの拡大にも寛容になりがちです。

 

…プロジェクトマネジメントの基礎を学んだかたならもうお気づきでしょうか？これ、すべてプロジェクト・マネジメントが必要な理由ですよね。

小さな社内プロジェクトがうまくいかない理由は、全て「プロジェクト・マネジメントが機能していない」ことに尽きます。

「小さいから」とか「社内案件だから」という言い訳でごまかしていますが、単に「プロジェクトマネジメントが機能していないからプロジェクトが失敗した」のです。

小さな社内プロジェクトを失敗させないための予防策

じゃあ、どうすれば失敗を避けられるのか、避けられそうか、というのを自分の失敗経験をもとにふりかえりました。ようは「プロジェクトマネジメントをしっかりやろうよ」ということに尽きるのですが、あえて大事な項目を並べると全部で5つでした。

    1. メンバー全員がプロジェクトマネジメントの基礎を理解する
    2. プロジェクト憲章作ってスコープをしっかり決めておく
    3. プロジェクト・マネージャーを1人絶対に決めておく
    4. 短期間で終わらせるべく、仕事をやりくりして優先度をとにかく上げる
    5. ステークホルダーマネジメントにとにかく時間をかける

簡単に解説していきましょう。

1.メンバー全員がプロジェクトマネジメントの基礎を理解する

メンバーがプロジェクト・マネジメントの基礎を知っているか、最初の顔合わせの時間で確認しましょう。

「プロジェクト憲章って何かわかる？」「品質・コスト・納期のトレードオフって知ってる？」などの質問に即答できなかったら、チーム全員で3-4時間時間をつくって、プロジェクトマネジメント(PMBOK)の基礎を叩き込みましょう。この段階でPM知識にばらつきがあると、内部からチームが崩壊するので、寄り道に思えてもやりましょう。

2.プロジェクト憲章作ってスコープをしっかり決めておく

プロジェクト憲章をしっかり作る組織って日本では稀なんじゃないでしょうか。ただ、名前こそ違えど似たようなものを作ることはあると思います。名前はなんでもいいので、PMBOK的なプロジェクト憲章をしっかりつくって、上司や関係者にしっかりチェックしてもらいましょう。とくに「不完全なまま作ってリリースして改善するのか」「完璧なモノを作るまでいくらでも納期を延期するのか」など、QCDの何を最優先するのか、徹底的に確認してください。

3.プロジェクト・マネージャーを1人絶対に決めておく

5人くらいのプロジェクトだと「お互いしっかり自分のToDoを管理して、いい感じにチームで進めて行こう」となりがちです。結局誰もが進捗管理をしなくなりがちなので、1人だけ、必ず全体の進捗をチェックする「係」を決めましょう。プロジェクトマネージャーと名乗る必要はないんですが、PMBOK的なPMの仕事をする1人の担当者を絶対におきましょう。

4.短期間で終わらせるべく、仕事をやりくりして優先度をとにかく上げる

働き方改革だの不景気だので、どんな社会人も限られた時間で沢山やることがあります。小さな社内のプロジェクトを専従でやらせてもらえるラッキーな環境は少ないでしょう。仮に自分が専従だったとしても、チームメンバーは他の仕事を兼任しているかもしれません。

「あたしゃ忙しいんだから、この案件は後回しだよ！」と言う人がいるかもしれません。毎日打ち合わせをしたくても、週に1~2回打ち合わせをすることしかできないかもしれません。

でも、6ヶ月間、週4時間、合計で約100 時間の時間をかけて何も成し遂げないプロジェクトに関わって嬉しい人なんていないはずです。それならいっそ、他の予定をやりくりして、2ヶ月毎週、火曜と水曜の9割の時間を一つの仕事に専念した方が、確実に成果が出せるんじゃないでしょうか。

5.ステークホルダーマネジメントにとにかく時間をかける

社内案件なので、上司や偉い人たちは好き勝手言いがちです。意識的に上司への報告時間をとりましょう。PMBOK的にはステークホルダー・エンゲージメント・マネジメントをしっかりやりましょう。そういう偉い人たちとやりとりをするからには、スコープコントロールや統合変更管理を徹底しましょう。

 

まとめ

小さい案件にプロジェクトマネジメントの知識を振る動員する必要はない、という旨のことをPMBOKを学び始めた時に耳にした記憶があります。たしかにその通りなこともあります。ただ、「小さな社内プロジェクト」という一番PMBOKの知識が要らなさそうな案件ほど、自分や自分の周りの案件で失敗している(というか、失敗とも気づかれないぐらいナチュラルにフェードアウトしている）ことに気づいて、この記事を書きました。

PMBOKの知識は、PMPに合格した人でも使いこなすのが難しいと感じています。

「自分は大規模案件のPMは関係ないから」と思っているプロマネ経験者、「PMBOK？なにそれ？」という反応をするプロジェクトの一般メンバー、それぞれ最低限のPMBOKの基礎をすり合わせたうえで、小さな社内プロジェクトの成功確率をあげていきましょう。

投稿タグ
, , ,