Dlaczego odniesiesz porażkę Czyli jak nie prowadzić biznesu Tomasz Grochowski, Project Management Institute
Tomasz Grochowski Uniwersytet Ekonomiczny metody ilościowe w zarządzaniu Analityk w firmach FMCG 4 lata Project Manager po stronie klienta FMCG 2 lata Project Manager w firmie programistycznej 2 lata Wdrożenia SAP 1 rok W międzyczasie internetowe serwisy usługowe < 1 rok Przy okazji dofinansowania z UE Obecnie Project Manager w GlaxoSmithKline Członek Zarządu PMI Poznań
Co może pójść źle? Wszystko!!!
3 Ogólne Prawa Murphy ego 1. Jeżeli coś może się nie udać - nie uda się na pewno. 2. Nie uda się nawet wtedy, gdy jednak nie powinno się nie udać. 3. Wszystko wali się naraz.
Przypadek 1.
Przypadek 1. Go Live Faktura i BUM Osiągnięto datę końcową projektu Uruchomiono system SAP Szampan, gratulacje Wysłano fakturę do klienta Klient nagle stał się formalistą Zainteresował się, za co ma zapłacić Dokumentacja nie istniała System działał jak chciał Faktura przekraczała budżet o 50%
Przypadek 1. Go Live Faktura i BUM Osiągnięto datę końcową projektu Uruchomiono system SAP Szampan, gratulacje Wysłano fakturę do klienta Klient nagle stał się formalistą Zainteresował się, za co ma zapłacić Dokumentacja nie istniała System działał jak chciał Faktura przekraczała budżet o 50%
Przypadek 1. Go Live Faktura i BUM Osiągnięto datę końcową projektu Uruchomiono system SAP Szampan, gratulacje Wysłano fakturę do klienta Klient nagle stał się formalistą Zainteresował się, za co ma zapłacić Dokumentacja nie istniała System działał jak chciał Faktura przekraczała budżet o 50%
Diagnoza Projekt był duży jak na tę firmę Był tylko jeden deadline Milestones? A po co? Nie prognozowano finansów
Diagnoza Każdy miał swoją własną listę błędów I tak poprawiano błędy bieżące Nikt nie wiedział ile było poprawek Nie było dokumentacji Koncert życzeń klienta
Diagnoza Na systemy DEV i TST brakło czasu Sandbox? Nawet tego nie znaliśmy. DEV powstał w końcu po starcie TST nigdy
Diagnoza Projekt miał stały budżet Podwykonawcy pracowali T&M Nie było formalnych zamówień Zakres umawiano na twarz
Jak podsumować ten projekt?
Lessons Learned
Dziel zadania System IT Infrastruktura Aplikacja Zakupy Montaż Funkcje Konta Użytkownika
Pracuj iteracyjnie 2mies. 1mies. 4mies. 2mies. Motel tradycyjny Klient PM Architekt Programista Tester Klient 9mies. 1mies. Agile Klient Zespół Klient Programista codziennie Tester
Zadanie równoległe są złe Czy zamiast tak nie lepiej tak?: 1 2 3 4 5 6 7 8 czas
Zadanie równoległe są złe NIE!!!!!! bo wyjdzie tak: 1 2 3 4 5 6 7 8 czas
Zadanie równoległe są złe Zadanie 1. Start: m-c 1. Koniec: m-c 7. Czas: 7 m-cy Zadanie 2. Start: m-c 2. Koniec: m-c 8. Czas: 7 m-cy 7 miesięcy 7 miesięcy 1 2 3 4 5 6 7 8 czas
Zadanie równoległe są złe Zadanie 1. Start: m-c 1. Koniec: m-c 4. Czas: 4 m-cy Zadanie 2. Start: m-c 5. Koniec: m-c 8. Czas: 4 m-cy 4 miesiące 4 miesiące 1 2 3 4 5 6 7 8 czas
Dokumentuj WBS User stories Backlog UML Ja używam: MindManager Enterprise Architect Mantis + Wiki Wiki Bugtracker Zadania
Przypadek 2.
Przypadek 2. Start Intensywna praca i BUM Mieliśmy pomysł Przeszliśmy od gadania do robienia Pomysł był opłacalny 2 spotkania na tydzień Praca po nocach Codzienne rozmowy telefoniczne Żony dały ultimatum: Zamykamy projekt, albo rozwód
Przypadek 2. Start Intensywna praca i BUM Mieliśmy pomysł Przeszliśmy od gadania do robienia Pomysł był opłacalny 2 spotkania na tydzień Praca po nocach Codzienne rozmowy telefoniczne Żony dały ultimatum: Zamykamy projekt, albo rozwód
Przypadek 2. Start Intensywna praca i BUM Mieliśmy pomysł Przeszliśmy od gadania do robienia Pomysł był opłacalny 2 spotkania na tydzień Praca po nocach Codzienne rozmowy telefoniczne Żony dały ultimatum: Zamykamy projekt, albo rozwód
Diagnoza Nie przeanalizowaliśmy interesariuszy Myśleliśmy, że nasi bliscy myślą tak jak my Myśleliśmy, że wystarczy pamiętać o klientach
Interesariusze prosty model
Podsumowanie Dziel zadania, projekty na mniejsze Pracuj iteracyjnie Nie rób zadań równolegle Zadbaj o wszystkich interesariuszy
Dziękuję tomasz.grochowski@pmi.org.pl