Standardløsninger gives kun i de allermest generelle vendinger: Erkend problemerne, og gå aktivt ind i at løse dem. Derfor udleverer vi ingen forretningshemmeligheder på denne side. Det vi sælger er ikke disse opskrifter. Det er hjælp til at gennemføre de ideer, der er skitseret på denne side.
Prisen for softwareudvikling er normalt mest løn. Med flere eller færre folk kan vi skrue på prisen. Derfor skulle det være nemt at styre et projekt hvis man har penge nok. Der er to problemer: `ni kvinder kan ikke gennemføre en graviditet på 1 måned og Brooks lov: Adding people to a late software project makes it later.
Kvaliteten kan ofres (midlertidigt) for at få noget færdigt. Desværre er det vanskeligere at arbejde videre med software af dårlig kvalitet, så gevinsten bliver ofte endog meget kortvarig.
Tiden et softwareprojekt tager bliver næsten altid for lang. Desværre er det ikke populært med tidsoverskridelser. Derfor er det ikke en god variabel at justere projekter på, mest fordi den ofte er givet af ydre faktorer.
Omfanget eller indholdet af et softwareprojekt er traditionelt det første man forsøger at lægge fast. Men hvis antagelsen om at de fire variable er er forbundne holder, og de tre andre er virkelig dårlige eller umulige at justere på, er der kun indholdet tilbage. Dette stiller til gengæld høje krav om et samarbejde mellem leverandør og kunde, hvad enten det er internt i en organisation eller mellem forskellige firmaer.
Moralen er at man ikke kan sætte alle fire variable på en gang. Hvis man prøver plejer man at opleve: hurtige genveje (dårlig kvalitet) for at nå en deadline; forsinkelser, når man skal bygge på et ringe fundament, en ekspltion i prisen når man forsæger at løse problemerne med opnomering; overskredne deadlines og manglende indhold når man alligevel ikke når det.
Hvordan opfylder man kravspecifikationen hvis man vil justere på indholdet undervejs?
Hvorfor er kravspecifikationer notorisk dårlige?
At anerkende præmissen at man ikke kan se ret meget længere end hvad der er det største problem i øjeblikket har drastiske konsekvenser for softwareudvikling.
Det underminerer fundamentet for Kravspecifikationen med stort K som en tidlig afdækning af alle de behov vi har til et IT system.
Det umiddelbare alternativ er en iterativ proces, hvor kravene løbende justeres på baggrund af den indsigt projektet allerede har genereret.
Dette åbner imidlertid døren for en justering af indhold som en gennemførlig måde at styre projektet på. Men det stiller store krav til samarbejdet mellem kunde og leverandør.