A hatókör kúszása a projekt által nyújtott teljesítmény fokozatos, ellenőrizetlen bővülése, amely egyenként apró kiegészítések sorozatán keresztül történik, amelyeket soha nem értékelnek az ütemtervhez, a költségvetéshez vagy a célkitűzéshez képest. Minden egyes kiegészítés önmagában ésszerűnek tűnik, pontosan ezért marad észrevétlen a felhalmozódás, amíg az eredeti kötelezettségvállalás már nem teljesíthető.
A kúszás és a jogos alkalmazkodás közötti különbség fontos és gyakran elmosódott. Az irányváltás azért, mert a bizonyítékok az eredeti terv hibásnak bizonyult, egy tudatos döntés, amelyet a költségek tudatában hoznak meg, és pontosan ezt hivatott lehetővé tenni az iteratív fejlesztés. A kúszás ennek a döntésnek a hiánya: munkát adnak hozzá anélkül, hogy bárki felmérné, mit helyettesít, így a kompromisszum soha nem kerül explicit módon megkötésre, és a következmények inkább elmulasztott határidőként, mintsem választásként jelennek meg.
A mechanizmus általában inkább társadalmi, mint eljárási jellegű. Egy érdekelt fél megemlít egy apró kiegészítést egy felülvizsgálat során, egy fejlesztő munka közben észrevesz egy kapcsolódó fejlesztést, egy specifikációs kétértelműséget nagylelkűen feloldanak, és minden egyes lépésszám túl apró ahhoz, hogy indokolja egy hivatalos változtatási kérelem okozta súrlódásokat. Sok ilyen lépésszám kumulatív hatása jelentős, és mivel egyetlen kiegészítést sem követtek nyomon, a túllépést nem lehet semmi konkrétnak tulajdonítani.
A kétértelmű követelmények a legmegbízhatóbb strukturális okok. Ahol a „teljes” definíciója homályos, a munka kibővül, hogy kitöltse a felmerülő értelmezést, és a megvalósítás során megoldott minden kétértelműség általában a továbbiak felé fordul. A kifejezett elfogadási kritériumok és a hatókörön kívül eső dolgok egyértelmű megfogalmazása megszünteti ezt a mozgásteret, és a kizárások megadása lényegesen hatékonyabb, mint a belefoglaltak felsorolása.
A túlburkoltság (gold plating) egy belsőleg generált változat, amelyet gyakran figyelmen kívül hagynak, mivel a kivitelező csapattól, nem pedig az érdekelt felektől származik. A fejlesztők és tervezők a kért mennyiségen túl finomítást, konfigurálhatóságot és robusztusságot is hozzáadnak, azon az ésszerűnek tűnő indokon, hogy végül szükség lesz rá. Gyakran nem így van, és a további bonyolultság tartósan a karbantartási költségekben nyilvánul meg.
A megoldás nem a merevség, amely pont az ellenkező irányban vall kudarcot, ha valami köztudottan hibásat hoz létre. Ami viszont működik, az egy könnyűsúlyú mechanizmus, amely láthatóvá teszi a kiegészítéseket, és egyértelművé teszi azok költségét: minden új elem rögzítésre kerül, hatását felmérik, és vagy elfogadják a megfelelő eltávolítással vagy elhalasztással, vagy elutasítják. A követelmény egyszerűen az, hogy a kompromisszumot valaki kötse meg, akinek van felhatalmazása rá, ahelyett, hogy a csapat csendben magába szívná.
A fix hatókörű, fix dátumú és fix erőforrású kötelezettségvállalások azok a strukturális feltételek, amelyek mellett a kúszás a legkárosabb, mivel nincs érvényes nyomáscsökkentő szelep, és a nyomást a minőség nyeli el. Ahol mindhárom valóban fix, az egyetlen változó a munka elvégzésének minősége, és az ebből eredő rövidítések később hibákként és átdolgozásként jelennek meg. A hatókör rugalmas dimenzióvá tétele teszi lehetővé a többi kötelezettségvállalás fennmaradását.
Mivel az irányítás attól függ, hogy kinek van felhatalmazása és hajlandósága elutasítani a kiegészítéseket, a probléma általában inkább irányítási, mint projektmenedzsment jellegű. A gyakorlatban a mechanizmus a projekten belül jön létre. termékfejlesztés a szállítási folyamat mellett a rangsorolási fegyelem, amely eldönti, hogy mi írja felül azt, ami a ... révén fenntartott bizonyítékokra támaszkodik termékkutatás, és a termékstúdió A megbízás során a munka megkezdése előtt általában megállapodnak arról, hogy mi esik a hatókörön kívül, ahelyett, hogy a munka megkezdése után tárgyalnák meg.