プロジェクトスタート直後がのんびりしているプロジェクトはとても不安なのです
プロジェクトの立ち上げの時期って一番忙しいんじゃないかっておもうんです。実際、一番忙しいですよね。忙しいはずですよね。忙しハズなんです。だって、計画が8割とか言うじゃないですか。ワタシは8割じゃなくて9割くらいあるんじゃないか、って思っていますけど。それくらい、立ち上げの、最初が肝心なのです。
だから、立ち上げの時期にのんびりスタートしているプロジェクトを見ると目を疑います。「ほんとにそれで納期に間に合うの？」って。最初の工程、それが要件定義なら要件定義を如何にスタートダッシュするか、基本設計からなら如何に基本設計フェーズをスタートダッシュするか。
どうしてプロジェクトをスタートしたタイミングから、そんなのまったりと始めたら、と思うかもしれないけれどそんな余裕がない理由はこんなことがあるからです。
システム開発手法を決め作業計画を立てる
そうそう、これはアレですアレ。ウォータフォールでシステム開発するのか、スクラムで開発するのか、そういった開発手法を決めて、それに見合ったプロセスも決めて、工程を切ったり、マイルストーンを計画したり。そういったのです。
仕事は学校の試験じゃないですから、一から十まで覚えている記憶で考える必要はないです。参考資料を見ながらでもいいですが、新しいことを取り入れたいなら、最初は小さくフィージビリティで試して検証結果を見て判断してからがいいです。
例えば、100人月超えのプロジェクトをやったことがなく、ウォーターフォールしかやったことがないからいきなりスクラムを取り入れるのはギャンブラーじゃないかな、と。どうしても顧客要件で指定のある場合は、プロジェクト開始直後にプロトタイプとしてシステム開発のしくみのフィージビリティを検証して実効性があるかを検証した方がいいです。それでまずければその開発のしくみになんらかの欠陥があるのでそのしくみを改善しないといけないし。
話を戻して、つまり、システム開発手法の仕組み、作業の標準の仕組みを決めて計画を立てよう、ということです。既存のしくみとか組織の開発標準が決まっているなら成れたそれを使えばしくみを構築する手間が省けますね。
とはいえ、システムの特性を考慮してテーラリングは必要ですけど。
プロジェクト管理計画を立てる
プロジェクト「管理」計画って「なん？」って感じでしょうか。でも、みなさんよく知っているみなさんはあまり好きじゃないかもしれない、
などなどの、システム開発をしていくうえで、契約を中心とした場合のプロジェクトの進行が計画した中心値から外れないようにコントロールするための管理手法です。
で、これが何時必要かと言うと、プロジェクトを開始した直後からすぐに必要になるところが地味に見えない負担なんですよね。割とみなさん先送りしてしまうのは、プロジェクトが始まるとその直近の日程の作業を回すためにそっちに注目してしまうし実際リソースもドカッと投入してしまいがちです。
それで進んでしまうと何が拙いかと言うと、管理、コントロールするということは、計画に対して実際のプロジェクトの作業で計測して計画と実績に較差がないか、ずれの兆候がないかを検証し続けていく必要があるところをネグってはじめてしまうので困った事象が起きてからプロジェクト管理計画を蔑にしていたことに気づくというパターンに陥るというケースです。
まぁ、今時はこれだけプロジェクト管理も普及しているわけで、そういったことも「稀でしょ？」って思うかもしれないですが、人は時間で更新される、つまり世代交代が続いていることを忘れてはいけないんですよね。だから、「そんなの当たり前なのにやってなかったの？」って事態が起きるわけです。
経験のあるプロジェクトマネージャなら、過去モノとか組織標準とかを「どこから」持ってくればいいのかを知っているし、ベテランになれば「自分の」アセットとして自分流にカスタマイズというか洗練したプロジェクト管理計画のパーツを持っているものです。
それがないと調達から始める必要があるし、その調達したパーツを理解するところからになってしまう。そうしたことが初期のプロジェクトの立ち上げではとても負担なんですよね。
最初の工程のWBSをスケジュール化(日付を確定)する
メンバが居たら作業を始めてもらわないといけないので日付を入れることは急ぎの仕事だし、そもそもWBSをdeliverableに合わせて設定しないといけないし。
でも、こうしたWBSのタスクもシステム開発手法の上に載るものだし、そのシステム開発手法だってプロジェクト管理の上に載るものだし。
ファシリティを確保する
ファシリティは最低限の必要なものから準備すればいいですが、コミュニケーションを促進するものは早々に確保しましょう。あと、環境は大事なのでプロジェクトルームがあるならきれいな状態から使用して、いつも綺麗にしておきましょう。
きれいな作業環境が作業品質の一因になることもあるのですよ。経験談ですが。
キックオフミーティングを開く
キックオフミーティングを開くためには、その準備もしなくてはいけないし、プロジェクト管理計画もあらまし準備できていないとagendaは充足されません。
そして、キックオフミーティングが顧客と同じ立ち位置に立てる最初のチャンスだし、メンバと同じ方向を向くための動機づけに絶対必要です。メンバに対する意味づけのもう一つにプロジェクト管理計画を最初に説明して理解してもらう、と言うのがあります。初めから知っていれば、文句は言いません。いや、いうかもしれないですが、後出しよりいいです。
こんなんなんでプロジェクト開始直後がのんびりしているプロジェクトはとても不安なのです。
