ITプロジェクトの大部分が失敗に終わることは誰もが知っています。 これらの失敗の理由はさまざまですが、この問題に対処するすべての人が1つのことに同意します。注意深い準備により、失敗のリスクが軽減されます。
問題は、このトレーニング中に何をすべきかです。 正常に終了するようにプロジェクトを準備する方法は？
プロジェクトが失敗するのはなぜですか？
伝統的に、すべてのステップを計画し、タスクをペイントする必要があり、すべてがうまくいくと信じられています。 ただし、失敗したプロジェクトを分析すると、そのような予備作業のほとんどすべてが実行され、すべてが慎重に計画されたことが明らかになります。
ITプロジェクトが失敗する主な理由は、詳細な計画ではありません。 大部分のプロジェクトは、変化に対する抵抗を過小評価しているために失敗します。 その後、デブリーフィング中に「ヒューマンファクター」として認定されます。
各ITプロジェクトの特異性は、無形のアイデアを実装することです。 各プロジェクトの過程で、新しいユニークな製品、ビジネスプロセス、または他の何かが作成されます。重要なことは、プロジェクトの終わりまで、最終製品の正確なパラメーターが誰にも知られないことです。 これは、高度な不確実性につながります。
ITプロジェクトの2番目の特徴は、人々のやり方、秩序、または労働条件の変化を常に伴うことです。 結局のところ、これらはコンピューター上のプログラムで作業する人々です。 つまり、ITプロジェクトの大部分は組織の変更の必要性につながります。
これらの2つの要因：組織の変更の不可避性と変更に対するフォームの抵抗に加えて不確実性が高い。 どのITプロジェクトでも、どの企業でも常に発生します。 この抵抗の重要性は高いほど、このプロジェクトの影響を受ける人々の数は多くなります。 ITプロジェクトに対する変化に対する抵抗の影響は常に大きい。
変更前に抵抗を克服する
先ほど 、変化に対する抵抗の性質と、この抵抗を克服する方法について書いた 。
いくつかの重要なことを簡単に思い出します。
- 変化に対する抵抗の基礎は人間の心理学であり、悪意ではないため、抵抗は避けられません。
- 抵抗を克服することは、変化曲線の段階を素早く通過するための適切な動機を作り出すことにあります。あなたは新しい方法で生きることを命じることはできません
ITプロジェクトは多くの場合、多くの従業員に影響を与えるため、変化に対する抵抗の強さも大きくなってきており、それを克服するには多くの努力が必要です。 プロジェクトが失敗しないようにするには、組織の変更の開始時に、他の人の例として機能し、変更に対する抵抗を減らすことに興味があるサポーターが必要です。 サポーターはIT部門の実装チームであるだけでなく、サークルの幅を広げる必要があり、プロジェクトの開始時にこのサークルの形成に取り組む必要があります。
アイデアは非常に単純です。主要な従業員をプロジェクトの準備に関与させ、プロジェクトの準備中に「紙上で」の変更の影響の主なマイナス要因を乗り切るようにします。 その後、アクティブフェーズでは、変更が実際に行われると、変更の準備が整い、抵抗の代わりに追加のサポートが提供されます。
なぜこれが可能ですか？
変化の曲線を思い出すと、変化の発表後の急激な失敗は、意識の低さと将来の不確実性が原因です。これは、反映と生産性の低下につながります。 人が準備され、すでに将来のアイデアを持っている場合、このプロセスでの彼の役割を理解し、ステージ1、2、3を振り返る代わりに、すぐにステージ4に落ちます-他の人の行動や反応を考慮して、変化する条件に適応し始めます。 したがって、変化に興味を持っている彼は、バラストではなくプロセスのエンジンになります。
グラフィカルに、これは次のように説明できます。
プロジェクトを準備する適切に編成されたプロセス中に、ワーキンググループの各参加者は、将来の変更をモデル化して試行します。同僚の提案を拒否し、自分の経験を保持し、主張するなどして、変更プロセスのすべての段階を変更なしで体験します。 彼は改革が始まる瞬間にもっと準備ができ、同僚の否定的な反応に備えています-彼自身がそれらを経験し、変化を支持する議論を見つけました。 これにより、抵抗を大幅に減らすことができます。
実際に何をすべきか？
理論は良くて美しいですが、実際にこれを達成する方法は？ これを行うには、プロジェクトの準備中に、非常に簡単な推奨事項に従う必要があります。
1.顧客を特定します。
顧客なしで成功するITプロジェクトはありません（正確には大文字で）。 顧客は常に「はい」と答える人です。「このプロジェクトの結果が必要ですか？」という質問に答えてください。そして、簡単な言葉で、結果が何であり、彼らがもたらすメリットを簡単に説明できます。
あなたがIT企業であり、外部顧客向けにプロジェクトを実施している場合、顧客は先験的であるように思われます。 しかし、これは常にそうではありません。 多くの場合、契約下の顧客はITサービスであり、これは社内の請負業者です。
各ITプロジェクトには、IT部門ではなく、機能部門の顧客、できれば複数の顧客が必要です。 これにより、プロジェクトの成功の可能性が劇的に高まります。 プロジェクトの開始が注文によって修正され、IT部門だけでなく作業計画に組み込まれると、非常にクールになります。
2.目標を宣言する
プロジェクトには明確な目標が必要です。 これは当たり前のように思えますが、「なぜ私たち全員がこれを一緒にやっているのか」という質問は、必ずしも答えを見つけられません。 具体的で測定可能な目標を紙に固定する必要があります。 「作業効率の改善」ではなく、「処理時間の短縮...」。 これは、参加者からのプロジェクトのサポートの基礎として機能する目標の達成であるため、非常に重要です。
3.チームを編成する
IT専門家自身がITプロジェクトを準備し、「何が必要か」という質問で全員を苦しめ、その後TKを長時間書くと、このTKは完了し、誰も結果を必要としないのが一般的です。 このテーマに関する漫画や出版物がたくさんあります。 これを回避するには、プロジェクト準備チームが、部門長および/または自動化のメリットを享受する部門の主要な従業員で構成される必要があります。 準備段階のITワーカーは、プロジェクトリーダーとしてではなく、専門家として、方法論者として行動する必要があります。
4.未来の画像をキャプチャする
圧倒的に、ITプロジェクトの目標は、ビジネスプロセスまたは個々の手順を変更することです。 つまり、明らかに人々の仕事が変わると想定されています。 情報の入力と使用の責任は間違いなく変わり、注文も変わります。 多くの場合、実装チームまたは「リーダーシップ」、つまり変更プロセスの推進者は、これを当たり前のことだと考えています。「まあ、作業が異なる必要があることは明らかです」と彼らは言います。
しかし、これは従業員にとって最悪のことです。 参加者を将来の変化のプロセスに没頭させることは非常に重要です-作業がどのように編成されるか、どのような新しいツールを使用するか、どのように紙片を相互に転送するかなどを考えて説明します。
さらに。 ビジネスプロセスを実際に変更するときではなく、ビジネスプロセスをモデル化して説明するときに、最初に変更を経験することが重要です。 これにより、変更に対する抵抗が大幅に減少します。
5.すべての人にメリットを見つける
「どのように改善されますか？」、「あなたにとって何が重要ですか？」、「何が許されませんか？」、「どう思いますか？」-これらは、ITプロジェクトマネージャーが実装チームメンバーおよびプロジェクトに関与する部門の従業員に尋ねるべき主な質問です未来のモデリング-ビジネスプロセスの説明。 グループメンバーはそれぞれ、プロジェクトが彼にもたらすメリットを独自に見つけて修正する必要があります。これにより、変換の成功が保証されます。
6.書くことを怠らないでください
「ペンで書かれたものは、withで切ることはできません」-民俗の知恵。
紙に固定されていないものは存在しないことを考慮してください。 スーパープロセスを思いついたら、座って、熱く議論し、うなずきましたが、それを誰もが理解できる形式で文書化することを気にしませんでした-誰もが1日でそれについて忘れて、次の議論をゼロから始めます-何もないように したがって、あなたのアイデアが失われないようにしたい場合は、文書化してください！
7.他人のために考えないでください
あなたが他の人よりも良いことを知っていると思い込まないでください。 あなたが思いついたことが便利で便利だと思うなら、これを確認して、実装まで遅らせないでください。 人々を驚かせる必要はありません。あなたが何を思いついたのかを教えて、すべてがどうなるかを説明し、評価を注意深く聞いてください。 アセスメントがあなたが期待したものでなかったとしても、議論しないでください。 これに注意して、プロジェクトに必要な修正を加えてください。 それは重要です
実装の結果、人々は期待したものを手に入れました！ この場合にのみ、サポートを提供します。
8.決定を下す
意思決定を避けることは、ITマネージャーのよくある間違いです。 「最高だと思うものは何ですか？」と尋ねられた場合、「まあ...それはあなたにとってより良いことです...」というスタイルで答えないでください。 あなたの意見を聞かせてください、私はあなたがそれを持っていると確信しています。
9.結果を修正するまで実装を計画する
非常に単純なルール：「完了」-これは「私がやった」という意味ではなく、「私がやったことが有用だと言われた」という意味です。
彼らはこれについて多くのことを言いますが、プロジェクトの結果が需要であり、誰かに利益をもたらしたという確認を得るのを気にする人はほとんどいません。 これは非常に重要です。 したがって、プロジェクトを計画するときは、開発と承認に限定されるべきではなく、顧客による結果を評価するための時間とリソースを置く必要があります。
彼が結果をどのように評価するかについて事前に考えてください。
10.レポートを書く
求められず、受け入れられない場合でも、プロジェクトの最後にレポートを作成します。 まず、終了したことが明確に通知されます。 多くの場合、この点は非常に見逃されます。 次に、これはプロジェクトの結果の明示的な宣言であり、評価する必要があります。 結局、結果がない場合、評価はありません。
紛争、失望、眠れぬ夜の中で、会社全体が考えたすべてを行うためにせざるを得なかった巨大な努力を背景に、プロジェクトの目標と目的はしばしば解消され、その結果は当たり前になります。 そして、そのような結果の記録がなければ、プロジェクト参加者は自分の仕事に不満を抱く可能性があります。
プロジェクトの目的を簡単に説明し、目的が達成されたかどうかを評価してください。 成果と失敗の分析を実行し、プロジェクトに関係する各ユニットが受け取ったものについて書き、変更を評価し、プロジェクト参加者にマークを付け、強調したいものをハイライトします。 会社で受け入れられない場合でも、実装グループとマネージャーにレポートを送信します。これにより、結果がどの程度プラスになるかがわかります。