まず、プロジェクト管理とカオスの関連ですが、この記事の筆者が述べているようにプロジェクト管理においてそのステークホルダー(利害関係者)が増えることによってプロジェクトの複雑さが増すことは経験的にも明らかです。これは、この記事が指摘している組み合わせの複雑さよりも、想定と現実の差がプロジェクトの誤差として許容できなくなるという言い方のほうが(カオス理論的にも)しっくりくる気がします。
あと、この筆者がカオスの淵といっているものは、その誤差が許容できるかどうかの淵であり、カオス理論的にリヤプノフ数から推定されるカオス状態との淵とは異なるということから、そもそも論で言えばカオスに対する認識が違うのだろうというところに落ち着きますが、それでもなんとなく違和感を感じます。

カオス理論を少しだけかじっていた(思い切りやっていなかった、ということでボツねた扱いです ;-) ので、もう少しそちら方向の視点で考えます。プロジェクト管理はカオスだ、という仮説を立てると、プロジェクト管理を行うためには線形的なアプローチではなく、非線形的なアプローチをとらなければ収束しないということが容易に想像できます。
ここで言う線形的なアプローチというのは要素還元論的に(物事は細かく分割できるとするような理論; たとえばフーリエ変換みたいに) 物事を細かく分割して管理していくという手法で、非線形の場合にはそれ以外の方法（どれが適切かはまた別途)を使用すると考えてよいでしょう。

普段、プロジェクトに参加していて感じるのはPMBOK的なプロジェクト管理は、(規模の大きい)ソフトウエア開発には不向きということです。これは、線形的なアプローチである、WBS(Work Breakdown Structure)のように要素を分割して管理したとしても、それらのリスクや複雑度は製造業ほど均一ではないということが原因であると感じています。

まだ非線形的なアプローチとして、今回取り上げた記事の「プロジェクトを管理しない」というのがいい手法なのかはよくわかりませんが、少なくとも思えるのはソフトウエア開発ではアーンドバリュで算出するようなコストや出来高以外に、非線形的な要素として現場の暖まり方(チーム内コミュニケーションの円滑さや、作業の加速度)や、顧客との距離感といった要素が、長期または大規模なプロジェクトでは無視できなくなり、少なくともPMBOKやPrince2あたりは通用しないし、結局そのあたりは現場のプロジェクトマネジャのカンにゆだねられている気がしてなりません。