プロジェクトマネージャー以外の人のためのプロジェクト管理

ビジネスケースを作成する

解決しようとしている問題と、それを解決することで得られる価値を定義します。問題の範囲を完全に理解できるように、社内外のターゲットの顧客と対話します。プロジェクトのビジネス ケースを作成する際は、顧客にできるようになってもらいたい点に集中します。具体的な方法については、後でチームと解決策をブレーンストーミングするときに決定します。

推奨されるアクティビティ

• 問題のフレーミング – 問題の範囲とそれが顧客に与える影響を探り出します。
• 顧客インタビュー – 究極の共感ツール。

「成功」を定義する

目指すべき測定可能な成果と、それらに向けた進捗状況を追跡するための指標について合意します。企業が追い求めている、より大きな目標にプロジェクトが貢献していることを確認します。そうでない場合、このプロジェクトは不適切である可能性があります (または適切なプロジェクトであっても、タイミングが悪い可能性があります)。

推奨されるアクティビティ

• 目標、シグナル、指標 – チームとして目標を設定して、進捗状況を測定する方法について合意します。

解決策をブレインストーミングする

問題解決スキルを発揮しましょう。今こそ特定のソリューションをどのように導入してどう顧客が最終製品と関わりあうかについて考えるときです。この段階では、チーム全体の関与を促して目標を高く掲げましょう。大胆なアイデアを後からシンプル化する方が、安全なアイデアを革新的なものに変えるよりも簡単です。

推奨されるアクティビティ

• 創造的破壊 – 短時間で多くの優れたアイデアのリストを作り出します。
• マインドマップ – 問題のさまざまな側面を調べて、解決に向けてアイデアを整理します。

プロトタイプとテスト

プロジェクトの性質に応じて、プロトタイプは紙ナプキンの裏に書いたフローチャートでもにわか仕立ての (しかし動作する) コードでも何でも構いません。プロトタイプをターゲットの顧客に提示して、フィードバックを早めにもらいます。ここが試行錯誤する最適なタイミングです。

推奨されるアクティビティ

• エンドツーエンドのデモ – フィードバックを簡単に得られるように、コンセプトを視覚化します。
• エクスペリエンス キャンバス – コンセプトがユーザー重視かつ実行可能で、顧客とビジネスの両方にとって価値があることを確認します。

プロジェクトのスコープを特定する

初期テストのフィードバックに基づいて、そして成功指標を念頭に置いて、プロジェクトに何を含めるべきか優先順位を付けます。想定されるトレードオフについて明らかにします。たとえば、使いやすさに向けて最適化すると、スケジュールが延びたり予算が増えたりする可能性があります。

推奨されるアクティビティ

• トレードオフ スライダー – スライドするスケールを作成して各指標の重要度を示し、優先するべき項目について合意を得ます。
• ジャーニー マッピング – 既存のジャーニーについて理解して、より優れたエクスペリエンスをデザインできるようにします。

ロードマップとバックログを構築する

リスクを予測し、低減する

今後の頭痛の種を減らすためにも、プロジェクトを失敗させる要因を熟慮して防止しましょう。また、まだ考えてもいない驚くような成功の可能性も特定しておきましょう。機会の逸失もある種のリスクです。

推奨されるアクティビティ

• 事前分析 – 悪い方向に進む可能性を想定して、回避策を立てましょう。

コミュニケーション計画の作成

チームのミーティングの頻度を確立して関係者に最新情報を報告し、周囲にシェアしましょう (ミーティングの回数は最小限に抑えると尚よしです)。繰り返し発生するミーティングをスケジュールに組み込んでカレンダーにリマインダーを設定し、プロジェクトの計画やダッシュボード (または社内ホームページ) を定期的に更新します。

推奨されるアクティビティ

• スタンドアップ – チームが毎日進捗状況を共有してブロッカーについて話し合う機会です。

• プロジェクト ポスター – 目標、ステータス、スケジュールを共有するための簡単な方法です。定期的に更新すれば、ステータス レポートとして機能します (しかも労力はずっと少なく済みます)。

イテレーティブに作業する

アジャイル手法はソフトウェア開発の世界で生まれたものですが、IT、マーケティング、人事など、どんなプロジェクトにも役立ちます。「ほどほどの」計画で各サイクルを開始して、作業を片付けましょう。各イテレーションの最後に簡単なふりかえりを実施するようにします。ふりかえりは、うまくいったこと (そしてうまくいかなかったこと) を共有して、次のイテレーションをさらに良いものにする機会となります。

推奨されるアクティビティ

• スプリント計画 – 次の 1、2 週間の作業を優先順位の高いものから順に計画します。
• ふりかえり – チームが今後の改善に向けて、うまくいっていること (そしてうまくいっていないこと) をふりかえって共有できる安全な場所を提供します。

テストを実施してフィードバックを取り込む

各イテレーション サイクルの最後に、完了した作業が反映されるようにエンドツーエンドのデモを更新して、それを関係者に (できれば顧客にも) 見せます。関係者や顧客からのフィードバックを取得して、次のイテレーションを計画する際に反映できるようにします。Y に移る前に X の再作業を行うことをお勧めします。

推奨されるアクティビティ

• エンドツーエンドのデモ – コンセプトを視覚化して、フィードバックを簡単に得られるようにします。
• スパーリング – 自分のアイデアに対する反対意見を他者に述べてもらい、新しいアイデアの着想を得ます。

「最低限の機能を持った製品」(MVP) をデリバリーする

いよいよ、大事な瞬間です。成果物がようやく公に (または社内で) 利用できるようになります。顧客が社内にいるか、直接やり取りするクライアントである場合は、プロジェクトが完了したことを承認してもらってください。道のりがどれだけ順調だったか、または険しかったかに応じて、書面で了承してもらうことをお勧めします。その後、チームとちょっとしたお祝いをしましょう。

推奨されるアクティビティ

• お祝いしよう! – 「チーム ランチ」を企画してもいいでしょう。

プロジェクトのふりかえりを行う

うまくいったこと、恐ろしく悪い方向に進んだこと、学んだことなどを、プロジェクト チームとの議論で取り上げます。教訓を集めて同僚と共有し、彼らがそれらの教訓を活かせるようにしましょう。完成したばかりの成果物について、改善するにはどうすればよいかについて話し合うのを忘れないでください。

推奨されるアクティビティ

• ふりかえり – 今後の改善のために、うまくいっていること (そしてうまくいっていないこと) をふりかえって話し合います。失敗は、そこから学べるのであれば問題ありません。

自慢する

成果物に満足していますか? そう願いましょう。プロジェクトに関する短い会社発表をまとめ、チームにお礼を言います。プロジェクトが外部向けである場合は、メールやブログ投稿で顧客にそのニュースを伝えるとよいでしょう。