Jeżeli jednak okaże (analiza) się, że zakup programu ma pomóc, to należy opisać wymagania jakie taki program musi spełnić (wymagania wobec produktu). Te wymagania są podstawą do wyboru gotowego, dostępnego na rynku oprogramowania, lub decyzji o napisaniu dedykowanego, jeżeli poszukiwania nie dadzą pozytywnego rezultatu (ale etap szukania gotowego powinien dla zasady mieć miejsce). Dedykowane rozwiązanie wymaga jego zaprojektowania, to można (zalecane) zrobić przed wyborem wykonawcy lub zlecić wybranemu wcześniej wykonawcy. Wariant drugi naraża nas jednak na utratę panowania nad projektem bo wykonawca będzie forsował metody budujące mu marże a potem sam sobie świadczy nadzór autorski. Wbrew pozorom, angażowanie audytora projektu, który nie jest autorem dokumentacji wymagań nie wnosi nic, a komplikuje cały proces: taki audytor może jedynie ocenić zgodność działań projektowych z dokumentacją wytworzoną przez (audytowanego) wykonawcę, a w przypadku sporu i tak tu "władzę" ma autor projektu a nie audytor.I teraz: ogłoszenie przetargu na całość na początku tej drogi jest jak widać idiotyzmem bo nie mamy żadnej wiedzy by ocenić wynik pracy a dostawca żadnej by cokolwiek sensownie wyceniać. Pominięcie jakiegokolwiek z tych w/w opisanych etapów to podnoszenie ryzyka projektu, co mam na dzieję widać. Każde wymaganie może być zero jedynkowe na każdym z tych etapów, wystarczy chcieć i umieć. Owszem, można je dzielić na biznesowe itp... ale to tylko sztuczne podziały, po prostu podczas realizacji mamy już tylko etap i jego wymagania. (Nieudane wdrożenie systemu biznesowego - czyli uczmy się na błędach innych | LinkedIn).I tylko tu pojawia się pytanie jak w filmie MIŚ: a może to faktycznie ma być drogie i nieprzydatne a ja zupełnie bez sensu jestem tym zdziwiony?