Funkcijų šliaužimas, dar vadinamas apimties šliaužimu, reiškia projekto reikalavimų tendenciją viršyti pradinius įvertinimus. Tai įprasta kuriant didelius kompiuterių projektus, kai inžinieriai nusprendžia, kad prieš išleidžiant gaminį reikia pridėti papildomų funkcijų, kad jis būtų patogesnis ir malonesnis tikslinei rinkai. Taip pat gali atsitikti, kai užsakovas, sudarantis sutartį dėl projekto, vis papildo pageidavimų sąrašą. Funkcijų pasislinkimas gali turėti įtakos bendram projekto biudžetui, taip pat gerokai atidėti išleidimo laiką, sukeldamas įmonės vadovų nusivylimą. Tai taip pat gali susilpninti gaminį, užkimšdama jį įdomiomis, bet nereikalingomis funkcijomis, todėl įmonės turi pasirūpinti, kad to išvengtų.
Problemą galima sumažinti turint glaudžiai organizuotą projekto komandą, kuri atpažįsta tikslius projekto reikalavimus ir dirba kartu, kad juos atitiktų. Projekto vadovas, žinantis apie funkcijų slinkimo riziką, gali padėti ją įveikti perkeldamas komandą arba primindamas klientui pirminius projekto tikslus. Retkarčiais iš tikrųjų reikia viršyti įvertinimus, ypač vykdant didelius projektus, kuriuose inžinieriai tiria naujas koncepcijas. Tokiais atvejais keli komandos nariai turėtų susitikti, kad įvertintų vykstantį bruožų šliaužimą ir nuspręstų, ar tai yra tinkamas projekto krypties rezultatas, ar ne.
Ypač programinės įrangos atveju pagunda pasiduoti funkcijų slinkimui dažnai būna didelė. Programinės įrangos kūrėjai nuolat galvoja apie naujus būdus, kaip patobulinti savo produktus, o tam tikru momentu projektų vadovai turi tai sustabdyti. Funkcijų šliaužimą šiuo atveju galima sumažinti dažnai rengiant projekto susitikimus, kad projekto dalyviams primintų pradžioje iškeltus tikslus. Kuriant bet kokį naują produktą, komanda visada turėtų susitikti prieš pradedant darbą, kad susitartų, kas yra kuriama, ko komanda nori, kad tai darytų ir kaip produktas pasieks šiuos tikslus.
Pastangos atgrasyti nuo slinkimo nėra skirtos bausti už kūrybiškumą. Atvirkščiai, komandos nariai turėtų užsirašyti papildomų funkcijų, kurios, jų nuomone, būtų įdomios ir naudingos, ir pateikti jas kartu su savaitiniais projekto užrašais. Jei kiti komandos nariai sutinka, kad funkcijos yra gyvybiškai svarbios, jos gali būti įtrauktos į projekto plėtrą. Jei funkcijos yra įdomios, bet nebūtinos su konkrečiu projekto leidimu, jas galima pateikti tolesniam plėtrai vėlesniuose projekto leidimuose, nesvarbu, ar tai būtų nauja programinė įranga, automobilis ar bet koks kitas įrenginys.