Governance wymagań (requirements governance) to ustalone zasady zarządzania wymaganiami w projekcie lub organizacji: kto zatwierdza, jak zgłasza się i ocenia zmiany, kto ma jaki głos przy priorytetyzacji, jak wymagania są wersjonowane i śledzone. W BABOK temat żyje w obszarze wiedzy Requirements Life Cycle Management.
Analityk ustala governance na początku projektu - i robi to z premedytacją, bo brak zasad nie oznacza wolności, tylko chaos: wymagania zatwierdza wtedy ten, kto głośniej krzyczy, a zakres rośnie korytarzowymi ustaleniami.
MediFlow przerobiło to na własnej skórze. Przez pierwsze tygodnie każdy z 12 kierowników przychodni dopisywał życzenia bezpośrednio deweloperom - na czacie, telefonicznie, raz na karteczce. Po miesiącu nikt nie wiedział, co jest w zakresie. Wprowadzono prosty governance: każda zmiana wymagań przechodzi przez analityka z oceną wpływu na termin i budżet, decyzje podejmuje trzyosobowa rada (dyrektor operacyjna, lider IT, analityk) na cotygodniowym spotkaniu, a rejestr decyzji jest jawny dla wszystkich kierowników. Liczba „pilnych" zmian spadła o połowę w trzy tygodnie - połowa pilności brała się z tego, że zgłoszenie nic nie kosztowało.
Częsta pomyłka: utożsamianie governance z biurokracją i deklarowanie, że „w Agile tego nie ma". Jest - nazywa się inaczej: Product Owner jako jedyny właściciel backlogu, refinement jako proces oceny, Definition of Ready jako kryterium wejścia. Druga skrajność też boli: governance tak ciężki, że zmiana przecinka wymaga komitetu. Zasady mają chronić projekt, nie zatrzymać go.