この段階での作業には手順らしきものもなく場当たり的に行われます。良くいえば全面的に担当者の善意に委ねられていると言うことも出来ます。
作業を見積る方法も持っていないし、プロジェクト管理も行なわれていません。ただスケジュ−ルを現す「ガン・チャ−ト」が一枚あるだけで、そのチャ−トからは具体的な作業は殆ど見えてきません。ましてや、何処に問題が潜んでいるのか、どの作業の中にスケジュ−ルを遅らせる原因が隠れているのか全く分かりません。実際に遅れが現実のものとなって初めてそのことに気付くのです。そこにあるスケジュ−ルが表しているのは、全てのことが期待通りに運べば、そして作業が抜けていなければ、この様な予定で完了するということだけで、実際にはこの通りに進むことは有り得ないのです。
面白いことに、このような組織にかぎって、そこで書かれるスケジュールには、１日の余裕もなく納期の前日に全ての作業を終了するようになているのです。これまでスケジュール通りに実現したことは１度もないのに、見事なスケジュールを書いているのです。
そこでは、予定されている作業が予定通りに終わるかどうかは担当者もやってみなければ分からないのです。ましてその場の管理者がスケジュールを外部に約束できるはずはないのです。ソフト会社の管理者は、実際に納期が迫ってくると、担当者が入院でもしてくれないかと願いたく（？）なったり、客先から渡された仕様書の“欠陥を探し始める”人もいるほどです。
スケジュールを外す原因の一つは、最初から「要求」を外していることです。要求を鵜呑みにしたり、折り返し確認しないで作業に入ってしまうのです。その結果、期間の後半になってリワークが頻発します。特に、要求の誤解は、最後のテストの段階まで誰も気付かないため、最大級のリワークになります。このレベルの組織は、このように要求を確認し、管理する方法を持たないのです。それは「分かる」という行為に潜む解決不能な問題に気付いていないことも一因なのです。
この段階の組織はツ−ルも旨く整備されていません。それは誰も本気でツ−ルを使うための調査をしないし、どの様なツ−ルがあれば、何が改善されるのか、といったことを考えている人は一人もいないからです。いや、一時期はその様な人もいたかも知れませんが、このレベルはそのような人をもスポイルしてしまう空気をもっているのです。時々、そのような組織のなかに、自分でツールを持ち込んで作業をうまくやっている人がいても、それはその人だけの世界であって、周りに広がることはほとんどありません。
プログラムの変更制御も担当者に任されるだけで、組織的にコントロ−ルされていません。バグが報告されたのを受けて、最も可能性のある人（どうやって判断するのか？）がその原因を追及し、ときには何日もかけて見事にその問題を解決するのです。この時、その解決方法が適切なものかどうかは問題になりません。問題にするのは報告されたバグの現象が消えたかどうかだけです。したがってその時に新しいバグの仕掛けを埋め込んでしまうことがしばしばあります。
そしてこの段階の組織は、どうしても早くコ−ディングやテストに入ろうとします。プロジェクト管理や変更管理が行なわれていない分、少しでも前に進めておきたいと思うのか、或いは管理者の単なる安心の為なのか。勿論本当にコ−ディングに入れる状態なら、早く入ればよいのですが、このレベルの組織の管理者や担当者は、精神的安定を求めて早くコ−ディングに取り掛かりたいと思うのです。
このレベルでは「外注管理」も出来ていません。自分たちの作業も計画できない組織に、外注管理ができることは有りえないでしょう。にもかかわらず、このレベルの組織は、自分たちの作業が手一杯の状態になるため、作業を外部に発注することが多くなるのですが、結果は、自分たちの作業の状況以上に惨憺たるものとなるのが普通です。
組織の全員が開発作業に専念しているのも、このレベルの組織の特徴です。組織のあるべき姿や、もっと効率のよい開発方法などについて組織として取り組めないのです。そこには開発作業に勝る作業は存在しないのです。したがって、過去の過ちから学ぶということもできません。第一、「過ち」をフィードバックする仕組みが存在しません。
一般に、企業の組織の中には「市場原理」は働きません。そのために、このような組織でも、代わりがないために使い続けるしかないのです。当然、事態は何時まで経っても改善しません。それどろころか、市場の要請からはどんどん離れていくのです。またそのような組織に愛想をつかして優秀な人は去っていくことも、事態を悪化させることになります。
そのような組織に、一体「仕事の喜び」は感じられないでしょう。そして、現実の殆どの開発組織はこのレベルなのです。
このレベルの特徴は、スケジュ−ルや費用や変更制御をある程度厳格に管理することによって、プロジェクト管理の一部を組織（チーム）として身に付けていることです。従って初期のレベルと違って、約束したことは“ほぼ”実現されます。
ただしこの段階での「約束」は、自らの経験則に基づいている部分が多く、まったく新しい案件に対しては、同じ様に“約束できる”とは限りません。「反復可能な」レベルというのは、過去に体験したことのあることなら、経験則を適用して、何とか対応するレベルという意味です。しがって体験者（達）の直感に依存している部分があるのです。
それでも初期のレベルと違うのは、要求を正確に把握し、スケジューリングができることによって、この「直感」を個人の領域から組織の領域に引っ張り出す方法を持っていることです。このことによって、担当者だけでなく管理者も“約束できる”状態に居られるのです。
しかしながらこの段階の組織は、自分達の能力を過信する可能性が高く、そのため新しいツ−ルを導入した途端に経験則が使えなくなって混乱したり、管理者が交代でもしようものなら、経験則を引き出す糸口を失ってしまう可能性を持っています。
この段階の開発組織は、プロセスの在り方を考える人（あるいはグループ）を確保している可能性があります。もちろん、明確に“独立”していないかも知れませんが、その必要性は認識されており、外部のコンサルタントを持ってくることも考えられます。この手配を怠れば、簡単にレベリ１に戻ってしまいます。
また、このレベルの組織の特徴は外注管理ができていることです。どのような形で依頼すればいいのか、何を管理しチェックすればいいのか、といったことが理解されているのです。
そして、ソフトウェアのソースやドキュメントの構成管理や変更制御も、有る程度出来ているのも、このレベルの特徴です。そのため、組織の混乱がレベル１と比べて格段に少ないはずです。
おそらく、組織のメンバーも、仕事の楽しさを実感しながら開発作業に取り組めるでしょう。
このレベルでは開発のための定義された標準プロセスを持っています。
分析手法を取り入れることで対象システムの問題点を早い時期に把握し、作業単位が明確になっています。さらにスケジュ−ルをＰＥＲＴ等で表すことで、作業の遅れや新たに発生した問題の影響を掌握しやすくなっています。設計技法や、テスト技法、さらにはウォ−クスル−（ピア・レビュー）といった技法を導入していることで、次第に作業のやり方が定着してくるでしょう。
そして新しいプロジェクトに対しても、何とか定義したプロセスを使おうとするし、プロジェクトが思いがけないトラブルを出したとしても、所定の手続きを経て解決しようとするでしょう。したがって、このレベルから先は“安定”したレベルになっていきます。
「定義されたプロセス」のプロセスとは、例えば、分析はこのようにする、設計はこのようにする、テストや、エラ−の対応はこのようにする、といった作業の「やり方＝手順」が定義されていることを意味しており、一人のスーパーマンに依存する部分が小さくなっているはずです。
言い換えればレベル２までは、このような「やり方」が個人任せで、組織として定義されていないということです。したがって、ＣＲ（クリーンルーム）手法がうまく運用されるとすれば、おそらくこの段階の組織であると考えられます。
このレベルのもう一つの特徴は、このような「定義されたやり方」はもっているのですが、その“効果”を測定するためのデ−タを意識して収集していないことです。
このレベルでは収集されたソフトウェア開発に関するデ−タを「評価」し、現在のプロセス・レベルを落とさないようにするのと、それによってさらに改善する必要のあるプロセスを見つけることができるでしょう。
そのためにも、集めるプロセス・データは正確に定義する必要があります。例えば、ソースコードの行数という簡単なデータも、コメント行をどうするか、或いは形式上はコメント行であるが、関数の定義部分や関数の頭に付けられている機能の説明に関する行をどう扱うか、また“｛”だけの行をカウントするか、等を正確に定義しなければなりません
「管理されたレベル」では、自分達の開発組織にとってどの様な尺度が有効なのかを探す段階でもあります。その為には正確な見積りの技術も必要になってくるでしょう。そして現実の作業工数に関するデータを収集し、データベースに集積し、当初の見積りと現実との乖離を検討することで、更に見積りの技術を磨くことができるでしょう。またソースコード行数やドキュメントのページ数から、期間当たりの生産性を知ることが出来るでしょう（これらの取り組みはレベル２の段階から取り組めると思います）。
或いは、ピア・レビューやウォークスルーの状況を記録したり、バグの報告書の内容を改善することで、バグの対応にウォークスルーがどの様に作用するかを、知ることが出来るでしょう。
このレベルの組織では、プロセス・データを分析することで、事前に製品や作業の成果物、あるいはプロセスの傾向を予測し、許容範囲を越えそうなときには、適切な行動を執ることができるでしょう。そのけっか、この組織から産み出される製品は高い品質が見込まれます。
しかしながら現実問題として、このレベルから先は、殆どのソフトウェア開発組織にとって、当分は手の届かないレベルかも知れません。恐らく多くのソフトウェア開発組織では「定義されたレベル」に移行し、そこを何とかして維持するのが、当面の目標と成るでしょうが、それでも「管理されたレベル」や「最適化できるレベル」とはどんなレベルかを知ることは無駄ではないでしょう。
また、それらのレベルで提案されている取り組みの一部を、それ以前のレベルに於て実施してみることは、その効果を過大に期待しない限りにおいて、必ずしも非難されることではありませんが、その取り組みに深入りしないことが大事です。（「レベルに適さない取り組みについて」を参照）
ここに達するまでの段階で、製品の品質と生産性を向上させるためには、ソフトウェア開発のプロセスそのものを改善することの方が効果的であることが既に理解されているでしょう。したがってこの段階の組織では、収集されたデータから、単に作業の手順を変えたり、テスト・ツールやＣＡＳＥツールを導入するための根拠を得るだけでなく、必要なら“プログラミング・チーム”を導入したり、開発組織の運用自体をも変更する事が出来ます。勿論その前提としては、常にプロセス・データの収集が行なわれていなければなりません。
この段階ではプロセスに関して既に多くのデータを持っており、それらのデータから開発プロセスのウィークポイントを見つけだし、その場面を改善すべく手法や技術を適用するための判断が行なわれます。一般にレベル３以上のプロセスでは、常に開発手法や技法に対する学習が行なわれています。そして実際の開発に投入する時間が節約出来る分だけ、新しい技法やソフトウェア・メトリクスについても積極的に研究され、プロセスのレベルが上がる程、それらが随時メンバーに広められていきます。
確かにこの段階のプロセスの姿は、多くの組織にとっては「理想」かも知れません。しかしながら「理想」であればこそ、それを目標にして進むべきでしょう。ただここで問題なのは、目標に至るための手順を間違えないようにすることです。