Professional Services Growth

**やり直しは実際のお金をコストします。**あなたの平均的なプロジェクトが200時間で時給200ドルで実行される場合、それは40,000ドルの収入です。20%がやり直し作業に使用される場合(間違いの修正、見落とされた要件への対処、分析のやり直し)、請求可能な時間の8,000ドルをゼロ値に生成するのに費やしました。これを50のプロジェクト全体でやって、1年間に400,000ドルを浪費してしまいました。

しかし、直接やり直しのコストは開始にすぎません。品質の失敗は段階的な問題を作成します:

**クライアント満足度が打撃を受けます。**すべてのエラーは、全体的な仕事が強い場合でも、不注意を示します。クライアントは47ページの素晴らしい洞察よりも、エグゼクティブサマリーのタイプミスを覚えています。公正? いいえ。現実? はい。これはあなたのクライアント満足度管理努力に直接影響します。

**あなたの評判が苦しむ。**プロフェッショナルサービスはリファレルと評判に住んでいます。1つの失敗したデリバラブルは「私は彼らがXYZプロジェクトで問題を持っていたと聞きました」になり、それはあなたを何年も続きます。品質の問題は品質の勝利よりも速く広がります。

**価格設定力が浸食します。**クライアントが品質の問題を経験するとき、彼らはあなたの価値を割引きます。あなたがすべてを修正したとしても、彼らの精神数学は「この企業は高価で、彼らはミスを作ります。」それは素晴らしい組み合わせです。

**チーム士気が低下します。**誰もやり直しが好きではありません。あなたの最高の人々は夜を過ごしてやり直し作業を行うことで気落ちしていて、興味深い仕事をする代わりに予防可能なエラーを修正しています。それはあなたが才能を失う方法です。

反対側は同じくらい説得力があります。品質で知られている企業はプレミアム率を請求でき、競争入札に勝つことができ、より良いクライアントを惹きつけることができます。品質はただのコストセンターではなく成長エンジンになります。

予防対検査: 基本的な選択

ほとんどの企業は品質に逆向きでアプローチします。彼らは検査に依存しています-仕事が終わった後のエラーをキャッチしています。それは高価で不完全です。あなたは完成した仕事をレビューし、問題を見つけ、修正のために戻し、再度レビューする人々に支払っています。これは損傷管理としての品質です。

より良いアプローチは予防です-エラーが決して起こらないようにプロセスに品質を組み込みます。つまり、明確な標準、適切なトレーニング、仕事の最後だけではなくチェックポイント、および一般的な間違いを防ぐツールです。

このように考えてください: 検査は欠陥の60-80%をキャッチします。予防は発生する前に90%以上を停止します。1つはあなたにいくつかの苦しみを救います。もう一つはそれを完全に排除します。

しかし、ここに落とし穴があります-あなたは両方が必要です。予防はエラーを劇的に減らしますが、人間はまだ間違いを作ります。だから、あなたは予防システムを構築し、レビューチェックポイントを作成します。奥行きの防御。

サービスタイプ別の品質標準の定義

「高い品質」は、何を提供するかに応じて異なるものを意味します。コンサルティングレポートはソフトウェア実装またはクリエイティブキャンペーンとは異なる品質基準を持っています。

コンサルティングデリバラブル(戦略、分析、推奨):

洞察品質: 発見は実際に価値があり、非明白ですか?
実行可能性: クライアントは実際に推奨事項を実装できますか?
ビジネス影響: 推奨事項は測定可能な成果に接続していますか?
証拠のサポート: 分析は徹底的で十分に文書化されていますか?
プレゼンテーション品質: クリア、プロフェッショナル、消化しやすいですか?

テクノロジーデリバラブル(ソフトウェア、システム、実装):

機能性: これはそれが行うことになっていることをしていますか?
パフォーマンス: スピードとスケーラビリティ要件を満たしていますか?
セキュリティ: 脆弱性に対処され、データが保護されていますか?
保守性: クライアントのチームはそれを理解して修正できますか?
ドキュメント: 他の誰かが機能しているかを理解できますか?

クリエイティブデリバラブル(デザイン、コンテンツ、キャンペーン):

有効性: これは望まれた応答または成果を達成しますか?
ブランド配置: これはクライアントのブランドガイドラインと声と一致していますか?
オリジナリティ: それは新鮮ですか、それとも一般的でテンプレートのように感じますか?
技術的な実行: 生産品質はプロフェッショナルですか?
オーディエンス適切性: ターゲットオーディエンスに対して機能しますか?

法的デリバラブル(契約、提出、法的分析):

徹底性: すべての関連する問題が識別および対処されていますか?
コンプライアンス: すべての規制および法的要件を満たしていますか?
調査品質: 法的分析は最新で十分にサポートされていますか?
リスク識別: 潜在的な問題は明確にフラグが付けられていますか?
明確さ: クライアントは何を言われているかを理解できますか?

プロセスデリバラブル(新しいワークフロー、運用手順):

効率向上: これは現在のプロセスを実際に改善していますか?
持続可能性: クライアントはあなたなしでそれを維持できますか?
採用準備: 組織が実装するのは現実的ですか?
ドキュメント品質: 誰かが手順に従うことができますか?
変更管理サポート: 人々の問題は対処されていますか?

共通のスレッド: 品質は単なる「タイプミスなし」ではありません。それは「このデリバラブルはクライアントの問題を実際に解決する方法で彼らが使用できるか」です。

あなたが生成する各デリバラブルタイプのために「優秀」、「許容可能」、「許容不可能」がどのように見えるかを定義することから始めてください。具体的に取得。「実行可能な推奨事項」はあまりに曖昧です。「推奨事項には特定のアクション、責任のある当事者、タイムライン、および成功メトリクスが含まれます」はあなたがチェックできる標準です。

マルチステージ品質レビューフレームワーク

クライアントに到達する前にエラーをキャッチする方法はここにあります: 複数のレビュー段階異なる目を異なるものを探しています。

ステージ1: 自己レビュー - 作業を作成した人は、品質チェックリストを使用して独自の出力をレビューしています。これはタイプミス、フォーマッティングエラー、不完全なセクション、破損したロジックをキャッチします。自己レビューは最速で、最も安い品質ゲートです。

問題: 私たちは自分たちの仕事をレビューするのが下手です。私たちは実際に書いたものではなく、書くことを意図したことを見ています。だから追加の段階が必要です。

ステージ2: ピアレビュー - チーム内の誰か他の仕事をレビューしています。彼らは新鮮な目をもたらし、元の著者が逃した問題を見ることができます。彼らはまた異なる専門知識をもたらします-多分彼らはクライアントをより良く知っています、または深い主題の知識を持っています。

ピアレビューは、レビューアーが明確な基準を持っている場合に最も機能します。「これは良く見えますか?」ではなく「これはあなた分析基準を満たしていますか? 推奨事項は実行可能ですか? 証拠は十分ですか?」

ステージ3: QAレビュー - 専任の品質プロフェッショナル(または品質フォーカスされたパートナー)は、品質標準について具体的にデリバラブルをレビューしています。この人は分析が素晴らしいかどうかをチェックしていません-それは彼らの専門知識ではありません。彼らは、それが構造、フォーマッティング、およびプレゼンテーション標準を満たしているかどうかをチェックしています。

プロの編集者のようにこれを考えてください。彼らはあなたの企業の基準に従うこと、引用がフォーマットされています、展示物は一貫して標識されている、エグゼクティブサマリーは実際にコンテンツを要約します。

ステージ4: クライアントレビュー - クライアントはデリバラブルをレビューして承認します。これは品質保証のためのオプションではありません-それはあなたが実際にはが彼らが望むのを提供したことの最終的なチェックです。クライアントレビューは誤合致をキャッチします: 「これは技術的に正確ですが、間違った質問に対応しています。」あなたのプロジェクトキックオフプロセスの間にクリアなレビューサイクルを確立してください。

プロセスドキュメント: 各段階は明確なエントリー/出口基準を持つべき。自己レビューが完了し、チェックされるまで、ピアレビューに移動することはできません。すべての内部レビューがサインオフされるまで、クライアントに配信することはできません。これはスケジュールの厳密さのようなショートカットを防ぎます。

品質チェックリストフレームワーク

チェックリストは、かっこいいではありませんが、効果的です。彼らは疲れているとき、急いでいるとき、または自信を持つときに人々がする誤りをキャッチします。

ユニバーサル品質チェックリスト(すべてのデリバラブルに適用):

スコープ完全性: これはスコープ/SOWのすべてに対処していますか?
事実的正確性: すべての事実、データポイント、引用は正確ですか?
クライアント名と詳細: 正しい企業名、綴り、ブランディング全体?
プロフェッショナルプレゼンテーション: 適切なフォーマッティング、一貫したスタイル、タイプミスなし?
必須セクション: コントラクトがすべてが含まれています?
クリアコミュニケーション: プロジェクトに不慣れな人がこれを理解しますか?
アクションアイテム定義: 次のステップが存在する場合、明確に述べられていますか?
最終デリバラブル形式: これはクライアントが要求した形式にあります(PDF、PowerPoint、など)?

コンテンツ固有のチェックリストアイテム:

分析/コンサルティング用:

データソースが引用され、最新
方法論が説明され、音
仮定は明確に述べられている
代替案が考慮される
リスク要因が特定される
実装可能性が対処されている

テクノロジー/実装の場合:

機能要件が満たされている
セキュリティスキャンが完了し、合格
パフォーマンステストが実施されている
ユーザードキュメントが含まれている
コードは標準に従う
配置プロセスが文書化されている

クリエイティブワーク用:

ブランドガイドラインが従われている
クライアントフィードバックが組み込まれている
複数の形式が指定されたとおりに提供される
使用権が明確
すべてのアセットがまとめられてラベル付けされている
改訂履歴が文書化されている

クライアント固有のチェックリストアイテム:

クライアントの優先用語が使用されている
以前に述べた設定が尊重されている
敏感なトピックが適切に処理されている
キーステークホルダーの懸念が対処されている
特定の受け入れ基準が満たされている
クライアント固有のフォーマッティング要件が従われている

チェックリストは、実際のエラーをキャッチするほど具体的であるべき。しかし、そのために人々はそれをスキップするほど詳細ではない。10-15の重要なアイテムで始め、実際に起こるエラーに基づいて改善します。

クライアントの期待管理について

品質の問題は、実際の欠陥ではなく、しばしば誤合致期待から生じます。クライアントはXを期待して、あなたはYを配信し、Yは技術的に優秀ですが、彼らは失望しています。

前もって現実的な期待を設定する。 スコーピングと契約の間に、「完了」がどのように見えるかを定義します。デリバラブルはどのような形式をとるでしょうか? 何回のレビューサイクルが含まれていますか? どのレベルの詳細が期待されていますか? 市場分析を提供している場合、彼らは20ページまたは200ページを期待していますか?

プロジェクト開始時に受け入れ基準を定義する。 クライアントと協力して、デリバラブル受け入れのための特定の測定可能な基準を確立します。「新しいシステムは1時間あたり1,000のトランザクションを処理する必要があります」はあなたがテストできる受け入れ基準です。「新しいシステムは高速である必要があります」ではありません。

これは両側を保護しています。あなたはあなたが保持されている内容を知っています。彼らはプロジェクト中にゴールポストを移動することはできません。

スコープと品質トレードオフを明示的に管理する。 クライアントがより多くの予算やタイムなしでより多くの仕事を求めるとき、単にはいと言って最高を望まないでください。トレードオフを説明する: 「当分析を追加できますが、品質レビュー用に時間が減るわけです。そのリスクで快適ですか、それともタイムラインを調整する必要がありますか?」あなたの変更注文プロセスを使用してこれらの決定をドキュメント化します。

ほとんどのクライアントは、トレードオフを明示的にするとき、スコープよりも品質を選びます。しかし、彼らがそうでない場合、少なくともあなたは品質リスクがその選択だったことを文書化しました。

品質通信リズムを確立する。 最終配信まで待たないで、あなたが構築しているクライアントを見せてください。定期的な仕事中のレビューは、早期の誤合致をキャッチできます。「ここは私たちのドラフト分析フレームワークです。これは正しいアプローチですか?」 100ページレポートのようにあるよりも修正するのがはるかに簡単です。「これはあなたが望んでいたことではないという意味ですか?」

詳細については、クライアント通信リズムを参照してください。

欠陥と問題管理

品質の問題が発生した場合、それらを処理する方法は、それらを防ぎ、最初に同じくらい重要です。

欠陥分類は、最初に修正する内容を優先順位付けするのに役立ちます:

臨界欠陥: これらはデリバラブルを使用不可能にするか、深刻なリスクを作成します。CFOのプレゼンテーションでの不正確な財務計算。配信されたソフトウェアのセキュリティ脆弱性。契約の法的誤り。重大な欠陥は修正されるまでなすべて停止します。

主要な欠陥: これらは価値または使いやすさを大幅に削減しますが、デリバラブルを完全に使用不可能にすることはありません。必須セクションがありません。データは方向的に正しいが、エラーが含まれています。指定されたとおりに機能しない機能。主要な欠陥はクライアント配信前に修正する必要があります。

軽微な欠陥: これらは価値を大幅に変えない品質の問題です。フォーマッティング不一致。意味を変えないタイプミス。提供されなかった素敵な機能。軽微な欠陥は修正する必要がありますが、あなたはしばしば配信でき、対処する計画があります。

識別とログアウトプロセス: 誰かが欠陥を見つけるときは(レビュー段階で)、一貫した方法でそれをログすべき:

何が間違っているか(「セクション3は悪い」ではなく具体的な説明)
どこで発生するか(ページ、セクション、モジュール)
重大度(重大、主要、軽微)
誰がそれを見つけたか
それが見つかったとき

これはあなたが完成まで追跡できる欠陥ログを作成します。また、改善のデータを生成します。

やり直しプロセスとタイムライン管理: 欠陥が特定されたら、誰かが彼らを修正する所有物を持つ必要があり、あなたはタイムラインを管理する必要があります。ピアレビューが15の主要な問題を見つけた場合、明日配信することはできません。クライアントに正直にしてください: 「当社の品質レビューは対処する必要がある問題を見つけました。これを正しくするためにさらに3日が必要です。」この種の透明なコミュニケーションは有効なクライアント通信リズムと整列しています。

ほとんどのクライアントは欠陥のある仕事を受け取ることより遅延を好みます。持っていない人々は通常、後で品質の問題に最も不安です。

トレンド分析と予防: 欠陥追跡からの本当の価値はパターンから来ます。同じチームメンバーが一貫してデータエラーを使用して仕事を生成する場合、それは訓練問題です。同じタイプのエラーが複数のプロジェクト全体に現れる場合、それはプロセスまたはテンプレートの問題です。

毎月または四半期ごとに欠陥ログをレビューしてください。何が起こり続けていますか? より良いテンプレート、チェックリスト、またはトレーニングで何が防止できますか?

品質メトリクスと測定

測定しないものは改善できません。品質パフォーマンスを理解するために、これらのメトリクスを追跡します:

初回パス受け入れ率: デリバラブルのどのパーセンテージがやり直し作業を必要とせずにクライアントによって受け入れられますか? あなたが95%以上にいる場合、あなたの品質システムは機能しています。70%の場合、かなりの品質ギャップがあります。

重大度別の欠陥率: 各デリバラブルあたり何多くの重大、主要、軽微な欠陥が見つかりますか? これをレビュー段階(自己レビュー、ピアレビュー、QAレビュー、クライアントレビュー)で追跡します。理想的には、欠陥数は各段階で減少-自己レビューで大部分のエラーをキャッチし、ピアレビューで少なく、ほぼクライアントに到達するもの。

やり直し時間: 欠陥の修正に費やす時間対新しい仕事を作成するのはいくら? これはあなたの直接的な品質コストです。やり直しがプロジェクト時間の20%を消費している場合、品質の改善には大規模なROI可能性があります。

クライアント満足度スコア: クライアントを特にデリバラブル品質について調査します。単純なスケール使用: 「このプロジェクトでのデリバラブルの品質をどのように評価しますか? 1-5。」時間をかけ、チーム/練習領域によってこれを追跡します。

レビューサイクル時間: 各品質レビュー段階は多くの時間がかかりますか? ピアレビューが3日かかっている場合、それはボトルネックか、デリバラブルが粗い形で到着している状態の信号のいずれかです。

時間をかけて欠陥トレンド: あなたは良くなるか悪くなっていますか? 欠陥率が増加している場合、あなたのプロセスまたはチームの何かが変わった。彼らが減少している場合、あなたの品質の投資は支払っています。

測定収集方法: 品質メトリクスをプロジェクト管理ワークフローに構築する。デリバラブルがステージからステージに移動するとき、関連データをキャプチャする品質サインオフを要求します。プロジェクトが閉じるとき、品質メトリクスをプロジェクト回顧に引き抜きます。

測定収集を別の仕事にしないでください。人々が既に何をしているのかに統合してください。

品質ツールと自動化

テクノロジーは人々が逃す誤りをキャッチでき、品質プロセスを速くし、より一貫性を作ります。

自動化の機会:

スペルチェックと文法ツール(Grammarly、Wordのエディタ): 基本的だが本質的。これらはあなたが不注意に見える理由のタイプミスと文法誤りをキャッチします。プロフェッショナル版はより洗練された執筆の問題をキャッチします。

ドキュメント比較ツール(Wordの比較、difツール): あなたがデリバラブルの複数のバージョンを生成しているとき、比較ツールは何が変わったかを正確に強調表示しています。これは「私たちはクライアントのフィードバックに対処しましたが、誤ってセクションを削除した」のようなエラーを防ぎます。

自動テスト(テクノロジーデリバラブル用): ユニットテスト、統合テスト、セキュリティスキャン。これらは手動テストより速く、より完全に機能的な欠陥をキャッチします。ソフトウェアまたはデータ分析を配信している場合、自動テストは交渉の余地がありません。

アクセシビリティチェッカー: ドキュメントまたはデジタル体験を配信している場合、アクセシビリティツールはあなたが作成した障害のある人々が実際に使用できるかどうかをチェックします。これは倫理的ではなく-これはしばしば法的要件です。

ブランドとスタイルチェッカー: あなたのデリバラブルがクライアントのブランドガイドラインと一致することを確認するツール。ロゴは正しく表示されますか? 正しい色コードを使用していますか? フォントは一貫していますか?

データ検証ツール: データまたは計算がたくさんあるデリバラブル用、検証ツールがエラーをチェック。数学は機能しますか? 外れ値があるかもしれませんエラー? データソースが一貫していますか?

品質管理プラットフォーム: Monday.com、Asana、または専任のQAソフトウェアなどのツールは、品質レビューワークフローを管理できます。彼らはあなたがレビューしたことのない人、どの欠陥が見つかり、何が修正され、まだオープンしているのかを追跡しています。彼らはクライアント(および独自のパートナー)に品質が事故ではないことを示す監査証跡を作成します。

配信ワークフローとの統合: 最高の品質ツールは、人々が既に動作する方法に無縫に統合します。ドキュメントをレビューする別のプラットフォームにエクスポートする必要がある場合、採用は悪くなります。品質チェックが通常のワークフローの一部として自動的に発生する場合、彼らはちょうど起こります。

後プロジェクトレビューを通じた継続的改善

すべてのプロジェクトは、あなたがおもしろいを気にすればあなたに品質について教えます。

プロジェクト後の品質レビュー: プロジェクトが閉じるとき、品質について具体的な会話を持ってください:

どのような品質の問題が起こりましたか?
どのようにキャッチされたか(どのレビューステージ)?
影響は何でしたか(クライアントが気づいた? 内部のみ)?
何が引き起こしたのか(不明確さ、時間制限、スキルギャップ、悪いテンプレート)?
次のような防止どのような方法でできることはありますか?

これは非難についてではありません。学習についてはそれです。目標は、個別の失敗ではなく、体系的な問題を特定することです。

品質標準進化: あなたの品質標準は、あなたが何が重要かについて学ぶと変わるべき。クライアントが何かの側面をしっかり気にすることを発見した場合は、それをあなたの標準に追加してください。何かをチェックしている場合は、決してエラーをキャッチしておらず、価値を追加しない場合は、それを削除します。

品質チェックリストと標準を四半期ごとにレビューして更新します。彼らは正しいことをキャッチしていますか? 人々が実際に使用できるほど明確ですか?

プロセスへの改善の構築: 単に学習の教訓を収集するのではなく-実際に実装します。プロジェクト後のレビューは、特定のデリバラブルタイプが品質の問題を一貫して特定する場合、テンプレートを再設計し、追加のトレーニングを作成し、または品質チェックポイントを追加する信号です。

閉じたループを作成: 問題識別→→→ ルート原因を理解する→修正を実装→修正が機能したことを確認する。

知識管理とベストプラクティス: 誰かが一般的な品質の問題を回避する方法を考え出すとき、その知識をキャプチャします。テンプレート、チェックリスト、トレーニングに構築します。品質改善は1人の頭の中に住んでいてはいけません。

詳細については、プロジェクト終了を参照してください。

一般的な品質落とし穴

善意のある企業もこれらのミスを作ります:

最終段階検査の仕組み品質: 仕事が「完了」するまで待つ品質をチェックしています。それは高価で不完全です。その時点で、エラーの修正は重要なやり直しを意味します。プロセスに品質チェックを構築し、単なる最終段階ではなく。

タイトなタイムラインのスキップ品質ステップ: スケジュール外にある場合、品質レビューは余裕が見えます。それはちょうど逆です。品質をスキップするとエラーを修正するのに遅延を作成したり、さらに悪くても、クライアントが配信を拒否する場合。

時間圧力への正しい応答はスコープを削減することです、品質ではなく。効果的なスコープクリープ管理は、これらの状況が最初に起こるのを防ぐのに役立ちます。

曖昧な基準と不十分なコミュニケーション: 「高い品質」は、定義していない場合、何も意味しません。そしてあなたがそれを定義しましたが、チームと通信していない場合、人々は知らないスタンダードを満たすことはできません。

品質標準を明示的で、アクセス可能で、オンボーディングの一部にしてください。誰かがあなたのチームに参加した場合、彼らは最初の1週間以内に正確に品質が何を意味し、どのように達成するかを知ってしないでください。

説明責任または測定なし: 品質の失敗に結果がなく、品質の成功に報酬がない場合、人々は品質よりもスピードに最適化します。これは過ちを罰することを意味しません-それは品質を追跡し、見える、そして一貫して優れた仕事を提供するチームを認識することを意味します。

品質は、パフォーマンスレビュー、プロジェクト回顧、およびリソース配分の要因であるべきです。あなたの最高の人々は、彼らが優秀または平凡な仕事を提供するかどうかに関わらず報われます。平凡さを期待します。

すべての欠陥が等しく扱われる: すべてのエラーが等しく重要ではありません。47ページのタイプミスと主要な推奨事項の重要な分析エラーは同じことではありません。焦点を当てるあなたの品質エネルギーを高影響領域に。深く欠陥的な分析での完璧なフォーマットは無駄です。

品質が自然に起こると仮定する: スマートな人はスマートな人です時間圧力下で自動的に高品質の仕事を生産しません、なじみのないトピックに取り組んでいるかまたはクリアでない要件に対処しています。品質には、才能だけでなく、システムが必要です。

次に行くべき場所

品質保証は配信とは別ではありません-それはあなたが価値を提供する方法の中核部分です。品質が体系的になると、いくつかのことが起こります:

あなたのやり直しのコストは劇的に低下します。それは直接プロジェクトの利益性と利用を改善します。

クライアント満足度が改善し、滞在と紹介を駆動します。クライアントは最初に正しくそれを取得する企業を覚えています。

あなたのチームの士気が改善します。人々は良い仕事をすることを誇りに思い、避けられる間違いの修正を憎みます。

あなたの評判が強化されます。あなたは品質を提供する企業として知られるようになり、それに応じて請求することができます。

品質は、プロフェッショナルサービス配信のいくつかの他の重要な領域に接続しています:

プロジェクト管理方法論 - 品質チェックポイントはあなたの全体的なプロジェクトアプローチに統合
クライアント通信リズム - 定期的なコミュニケーションは品質の誤合致を防ぐ
スコープ定義とステートメントオブワーク - 明確なスコープは「完了」についての品質の不同意を防ぐ
クライアントオンボーディングプロセス - 品質の期待設定はオンボーディングで開始
プロジェクト終了 - 品質レビューは改善洞察を生成

1つの改善を開始: あなたの最も重要なデリバラブルタイプのための2段階のレビュープロセス(チェックリスト付きの自己レビュー、次にピアレビュー)を実装します。前後のアクセプタンス率の最初のパス測定。数個のプロジェクト内で影響を見てます。

品質は完璧についてではありません。それはあなたの標準を満たすそしてクライアントの期待を超える仕事を一貫して提供することについてです。それは闘争する企業と繁栄する企業の間の違いです。

Tara Minh

Operation Enthusiast