Proiektuen kudeaketa tradizional deitzen diogu ezaugarri hauek dituzten proiektuetan egiten den kudeaketari: eskakizun-multzo itxia edo aurrekontu itxia. Mota honetako proiektuek porrot-maila handia izaten dute, eta porrotaren arrazoiak askotarikoak dira:
Eskakizun-multzoa ez dago benetan itxita. Bezeroak ezin ditu bere behar guztiak behar bezain zehatz zerrendatu, eta hornitzaileak ezin du behar bezala aurreikusi ebatzi beharreko arazoaren neurria. Horren ondorioz, bezeroaren itxaropenak ez dira betetzen, eta epeak eta kostuak arrazoizkoa baino askoz gehiago aldentzen dira, etab. Orokorrean, bezeroak gehiago ordaindu behar izaten du, edo hornitzaileak dirua galtzen du, bezeroak entregatzen zaiona onar dezan lortzeko.
Softwarearen garapena ez da eraikuntza, diseinua baizik. Baso osoak suntsitu dira softwarearen ingeniaritzari, softwarearen eraikuntzari eta software factory-ari buruzko liburuak egiteko. Izen handiusteko horiek benetako bizitzan inoiz softwarerik garatu ez duten pertsonek formulatutako teoriei dagozkie. Softwarearen garapenak ez du eraikuntzak duen errepikakortasunik, neurgarritasunik ez aurresangarritasunik. Ez du, softwarea garatzea diseinatzea delako (eraikuntzako diseinuaren eta plano teknikoen baliokidea, baina neurri askoz handiagokoa), eta softwarea eraikitzea, berriz, konpilatzea eta/edo instalatzea delako. Programatzea diseinatzea da, aurretik diseinu-zehaztasun zenbat sortu den axola gabe. Zerbait programatzean beti hartzen dira diseinu-erabakiak. Horrek esan nahi du garapen bat egiteko behar den denbora oso aurreikusezina dela, batez ere eskakizun zehatzik ez dagoenean, baina baita eskakizun horiek daudenean ere, eskakizunen azterketa nahiko sakona egitea irtenbidea diseinatzearen baliokidea baita.
Bezeroarengan bete ezin diren itxaropenak sortzen dira. Bezeroari beti esaten diogu epeak beteko ditugula eta sistemak berak nahi duen guztia egingo duela (eta, gainera, oso merkea izango dela!). Epeak ez dira inoiz betetzen eta sistemak ez du inoiz bezeroak nahi duen guztia egiten, bezeroak aplikazioa ikusi ahala egin beharko lukeen gauza berriak bururatzen zaizkiolako. Bezeroak ez du proiektuaren kostuen gaineko kontrolik: bezeroak orri zuria du esku artean, proiektuak zenbat kostatuko dion adierazten duen zifra hotz, sinple eta argia lortu duelako, eta aplikazioak bere ustez egin behar duen guztia egin dezan eskatuko du, azken xehetasunera arte. Bezeroak ez du jasotzen xehetasun bat oso garestia izan daitekeenaren informaziorik; proiektuen onerako, funtzionaltasuna eta kostua beti neurtu behar dira.
Bezeroaren beharrak aldatu egiten dira. Bezeroaren beharrak alda daitezke enpresa edo ingurunea aldatu direlako, edo beste aukera interesgarriago batzuk ikusi direlako.

Binovon Software Garapen Agilaren Manifestuari atxikitzen gatzaizkio, eta horrenbestez, pertsonak eta haien arteko harremanak balioesten ditugu prozesuen eta tresnen aurretik; funtzionatzen duen softwarea dokumentazio zehatzaren aurretik; bezeroekiko lankidetza kontratuen negoziazioaren aurretik; eta aldaketari erantzutea plan bati jarraitzearen aurretik.
Esaldien bigarren zatiek balioa duten arren, uste dugu lehen zatiak askoz gehiago duela. Horretarako, printzipio hauei jarraitzen diegu: