NetscapeのブラウザNavigator 3.0, 4.0、MicrosoftのブラウザExplorer 3.0, 4.0、Yahoo!のMy Yahoo!サービスなどを含む17社の完了した29プロジェクトをサンプルとしている。被説明変数は、14人の専門家パネルによる2段階のデルファイ法によって7点法で評価した「製品品質」で、その平均は4.46、標準偏差は0.49、最小3.50〜最大5.52。説明変数としては、

1. 資源投入(resources): 開発・試験全体の総資源投入(人日); 平均5369人日……コントロール変数
2. アーキテクチャ設計努力(architecture design effort): 開発・試験全体への総資源投入(人日)に占めるアーキテクチャ設計の割合; 平均0.26
3. 市場フィードバック1: 最初のプロトタイプに含まれていた機能の割合; 平均41%
4. 技術フィードバック: 最初のシステム統合時に含まれていた機能の割合; 平均61%
5. 市場フィードバック2: 最初のベータ版リリース時に含まれていた機能の割合; 平均77%
6. 世代的経験: 2世代以上のプロジェクト経験をもっているチームの割合; 平均52%

　重回帰分析の結果を示したTable 3により、次のように仮説は検証されたことになるらしい。

1. アーキテクチャ設計努力が大きいほど、製品品質は高かった。(仮説1の通り)
2. 市場フィードバックが早い段階で行われるほど、製品品質は高かった。(仮説2の通り)
3. 世代的経験があるほど、製品品質は高かった(仮説3の通り)。

　ただし、aを額面通りに受け取ることは難しい。アーキテクチャ設計の位置づけは不明なのだが、仮に、コンセプト開発(concept development)の一部だとすると、この論文は、Figure 2の製品開発の「より柔軟なモデル」(a more flexible model)で考えている(p.136)という割には、aがいえるということは、そもそもウォーターフォール的なFigure 1の方(a stage-gate model)が良いと言っているようなもので(実際、冒頭の要約で、柔軟な開発プロセスでは、製品パフォーマンスも開発プロセスの柔軟性も、アーキテクチャの選択次第だと明言している)、台無し感はぬぐえない。しかも、よく見ると、a.アーキテクチャ努力は0のものもあり(Table 1)、これは仮説1 (p.136)で示唆されているように、アーキテクチャ設計にきちんと投資をしておけば製品品質が良くなる……という類のお話ではなく、そもそも製品のカテゴリーによってアーキテクチャ設計の必要の有無が決まっている可能性があり、そうなるとaの主張自体が無意味ということになる。

　また、重回帰分析の結果を表したTable 3自体も疑問点が多い。機能的にどの程度揃えた段階でフィードバックを求めているかを説明変数の3、4、5で見ているが、そのうち市場フィードバックの3、5は一つの合成指標にまとめられ、bの結果とされているが、合成の仕方の記述(p.141, 脚注19)を読んでも再現可能なほどには理解不能なものの、少なくとも説明変数3、5のように単純に解釈できる代物ではないことだけは分かり、そもそもTable 3の結果をbのように読めるのか分からない。3の技術フィードバックは、Table 2にはあったのに、Table 3では市場フィードバックと相関が高い(0.643; Table 6)という理由で分析から除かれているが(p.144)、入れておいたら結果が違っていたのではないかという疑念も生じる。また、c.世代的経験は、単回帰では有意にならないのに(Table 2)、重回帰にしたら有意になることもある(Table 3)という不思議(普通は逆)かつ微妙な結果で、強く主張するのはいかがなものか。しかも、有意ではないどころか、Table 2のモデルVIIの決定係数が0というのも、自由度調整済みとはいえ不思議。ついでに指摘すると、Table 2とTable 3で回帰係数に括弧付きで標準誤差が表示されているが、なぜか資源投入だけがt値で表示されている。標準誤差で示してもt値で示しても情報量は同じだが(t値＝回帰係数/標準誤差 なので)、統一していないのは解せない。意味を理解していないのではないだろうか。