Założenie projektowe (assumption) to stwierdzenie przyjęte za prawdziwe bez dowodu - na potrzeby planowania, wyceny lub projektowania rozwiązania. W BABOK założenia rejestruje się razem z ograniczeniami (assumptions and constraints), bo jedne i drugie kształtują przestrzeń rozwiązań, tylko z różną pewnością.
Każde założenie to ukryte ryzyko: jeśli okaże się fałszywe, plan na nim zbudowany się sypie. Dlatego praca analityka z założeniami ma trzy kroki: wyłapać (najtrudniejsze - założenia zwykle siedzą w głowach jako oczywistości), zapisać w rejestrze z właścicielem i terminem weryfikacji, zweryfikować możliwie wcześnie. Im później założenie upada, tym drożej.
Przykład z MediFlow: business case e-rejestracji przyjął założenie „producent systemu HIS udostępni API do grafików lekarzy w ramach obowiązującej umowy serwisowej". Brzmiało rozsądnie - integracje były w umowie wymienione. Po dwóch miesiącach okazało się, że API do grafików to osobny moduł licencyjny: 40 tysięcy złotych rocznie ekstra. Business case trzeba było przeliczyć, a projekt stanął na czas negocjacji. Założenie było przynajmniej zapisane w rejestrze, więc nikt nie udawał zaskoczenia - ale weryfikacja w pierwszym tygodniu zamiast w dziewiątym oszczędziłaby dwa miesiące.
Częsta pomyłka: mylenie założenia z ograniczeniem. Ograniczenie (constraint) jest narzucone i pewne: „budżet to 300 tysięcy", „start przed październikiem ze względu na kontrakt NFZ". Założenie jest niezweryfikowane: „dostawca zdąży", „API istnieje". Ograniczeń się pilnuje, założenia się sprawdza. Druga pomyłka: niezapisywanie założeń, bo „wszyscy to wiedzą". Po pół roku okazuje się, że każdy wiedział co innego - a najdroższe zdanie w projektach IT brzmi: „myślałem, że to oczywiste".