Każdy z nas lubi mieć komfort wyboru. Przypomina to trochę budowę domu marzeń z garażem i ogrodem. Bez ogrodu i garażu też można zamieszkać, a na garaż i ogród poczekać lub wcale ich nie robić. Przemyśl więc biznesową kolejność prac i daj sobie oraz sponsorowi szansę zamieszkania w domu marzeń. W przeciwnym wypadku możesz wybudować świetne fundamenty, które bez tego, co na nich powstanie, nie są warte wydanych pieniędzy.

Cnota 4: Miej rezerwy

Nawet bardzo skromna armia nie rzuca na pole boju wszystkich sił od razu. Przebieg bitwy rzadko bywa taki, jak przewidzieli generałowie. W projektach jest podobnie. Skoro zakres nie może być precyzyjnie zdefiniowany, to również budżet i harmonogram realizacji traktować trzeba raczej jako przybliżenie przyszłości. W związku z tym musimy w projekcie mieć dobry plan bazowy, obejmujący rzeczy przewidywalne i znane. Ten plan trzeba uzupełnić rezerwami na zmiany, ryzyko i typowe odstępstwa. Niemal każda metodyka mówi o rezerwach. Np. Standard PMI wprost wymienia tzw. buffers, a w obszarze zarządzania ryzykiem definiuje pojęcia known unknowns i unknown unknowns z zaleceniami, jak do nich podejść. PRINCE2 literalnie nawiązuje do tolerancji projektu, którego prognozowane przekroczenie wymaga specjalnej obsługi (eskalacji).

Zobacz również:

• 9 cech wielkich liderów IT

Kierownik projektu musi mieć rezerwy, aby nie używać specjalnej obsługi przy każdym prognozowanym odchyleniu. PRINCE2 definiuje sprawę rezerw prosto, przywołując pojęcia: change budget, contingency reserve i wspomniane wcześniej tolerancje. Pozostaje więc używać tej wiedzy. Najlepszą drogą jest ustalenie projektowej polityki rezerw, która da kierownikowi projektu wystarczającą swobodę, a sponsorom nie ograniczy kontroli. Polityka rezerw musi również uwzględniać specyfikę organizacji zaangażowanych w projekt.

Cnota 5: Kupuj kota w worku

Nieprecyzyjny zakres skutkuje poważnym dyskomfortem dla decydentów. Można powiedzieć, że w trakcie inicjowania projektu określany jest worek i to, co spodziewamy się w nim znaleźć. Nie ma gwarancji, że kot w worku okaże się taki, jak chcemy. Znacznie ważniejsze w projekcie IT jest dobre zorganizowanie pracy niż dobre określenie zakresu. Co nie oznacza, że najważniejsze cechy produktów mają pozostać nieokreślone. Produkty projektu powinny być określone tak dobrze, jak tylko możliwe. Wszyscy zaangażowani muszą być jednak świadomi, że zarówno lista produktów, jak i ich szczególne cechy mogą ulec zmianie.

Dla projektów o szczególnie trudnym i nieokreślonym zakresie wymyślono dedykowane standardy zarządzania, np. extreme programming.