GoldenLine
Zaloguj się
Rafał D.

Rafał D. Head of Production,
Locon Sp. z o.o.

Temat: Pytania o podstawy w Critical Chain Project Management

Zaproszono mnie tu z forum o zarządzaniu projektami więc spróbuję szczęścia ;)

Chodzi o konkretne wdrożenie w rozwoju oprogramowania.

1. Rozumiem że kontroling w CCPM odbywa się głownie za pomocą zarządzania buforami. Jak w praktyce się to odbywa? Jakie działania za sobą pociąga? Chodzi o zmiany priorytetów zadań? Przydzielanie dodatkowych zasobów (przecież zasoby są uważane za nasz główny constraint!)? Nie mogę znaleźć opisów jak reagować na niekorzystne zmiany, np. za szybkie "zapełnianie się" bufora, przepełnienie bufora itd.

2. Czy brak "deadline'ów" dla poszczególnych zadań, co w założeniu ma uchronić od syndromu studenta i prawa Parkinsona, czyli jak rozumiem działanie na zasadzie "ASAP" nie powoduje w rezultacie efektu odwrotnego, tj. braku motywacji do faktycznego zakończenia zadania? Wydaje mi się że równie silnym problemem jest podjęcie decyzji czy zadanie wykonane jest już "wystarczająco dobrze" z którego de facto wynika prawo Parkinsona (no może pomijając lenistwo ;) ). W podejściu "klasycznym" sprawę tę załatwia deadline, on daje pewność że jeśli zadanie jest w tym momencie zrobione "znośnie" to będzie zakończone.
Czyli reasumując, jak przekonać ludzi do przyjęcia zasady "wystarczająco dobrze" i faktycznego oddawania zadań "ASAP"?

3. (* - komentarz do założeń niżej) Jeśli dobrze rozumiem zużycie buforów monitoruję pytając się ludzi o ocenę ich "progressu", tj. pytając "ile jeszcze ci zostało?". Czy nie wracamy tutaj do problemu którego niby się pozbyliśmy tj. ustalania przesadzonych, z za dużymi buforami, dat określających koniec zadania? A może wtedy, przy powstaniu za długiego szacunku, problem zostanie załatwiony przez reakcję na zapełnianie się bufora? Wtedy jednak wracamy do pytania 1...
Ponadto, CCPM jest sugerowany do projektów gdzie ciężko oszacować nakład pracy (nazwijmy to "inwencyjnych"), np rozwoju oprogramowania. Czy nie jest tak, że maskuje on w swoim pozornym braku ustalania deadline'ów problem który potem wychodzi w niemożliwości poprawnego monitorowania buforów?

4. Czy w praktyce nie jest tak, że ludzie wiedząc o tym że projekt jest realizowany przez CCPM i znając jego zasady traktują jako deadline terminy z wzięciem pod uwagę buforów? Tj. czy nie jest tak że "samodzielnie" monitorują bufory i przez to wracają do problemu wyjściowego tj. syndromu studenta i prawa Parkinsona?

(*) Ad 3.
Wychodzę z założenia że tak monitoruję zużycie buforów że przewiduję czas skończenia łańcucha i widząc ten przewidywany czas widzę zużycie bufora. Tak wyczytałem w książce i doszedłem do wniosku który chcę rozwikłać w pytaniu 3. Podczas rozmów jednak powstała mi hipoteza, że może bufor jest penetrowany dopiero gdy faktycznie w niego "wejdziemy" datami. Tj. na przykład, mam łańcuch z zadaniami na 5, 3 i 2 dni i bufor na 5 dni. Czy penetracja bufora następuje dopiero 11go dnia niezależnie od tego które zadanie jest wykonywane czy może już 6go jeśli wciąż trwa zadanie pierwsze?

No i jeszcze link do wątku z którego kopiowałem i w którym rozwinęła się jakaś dyskusja, może kogoś zainteresuje: końcówka tego wątku.Rafał D. edytował(a) ten post dnia 04.02.09 o godzinie 19:21
Link do wypowiedziLink
Krzysztof Abramowski

Krzysztof Abramowski TOC Consulting,
partner

Temat: Pytania o podstawy w Critical Chain Project Management

Polecam lekturę artykułu
"Jak skrócić wprowadzenie nowego produktu na rynek?"
który możesz znaleźć w naszej Bibliotece TOC
Znajdziesz tam odpowiedzi na kilka swoich pytań.
Link do wypowiedziLink
Henryk M.

Henryk M. Project Management /
Lean Management /
Systems Engineering

Temat: Pytania o podstawy w Critical Chain Project Management

Witam,

Po założeniu konta i próbie pobrania wspomnianego artykułu pojawiła się taka oto informacja:

Możliwe, że nie możesz zobaczyć tej strony, ponieważ

1. Użyta zakładka jest nieaktualna
2. Twoja wyszukiwarka nie odświeżyła jeszcze mapy naszej witryny
3. Adres został wpisany z błędem
4. Nie masz uprawnień do obejrzenia tej strony
5. Joomla! nie może zlokalizować wskazanego zasobu.
6. Wystąpił błąd podczas wykonywania powierzonego zadania.

Czyli: zadziałało ograniczenie :o) Które mam wybrać? Moim skromnym zdaniem prawdopodobne są: jedynka, piątka i szóstka (nie rzucałem kostką :o)

Pozdrawiam
Link do wypowiedziLink
Szymon Włochowicz

Szymon Włochowicz Wykładowca, Wyższa
Szkoła Bankowa we
Wrocławiu

Temat: Pytania o podstawy w Critical Chain Project Management

Ogólnie: wszystkie Twoje pytania znajdują odpowiedź w praktyce wdrażania CCPM. Napisanie pełnej odpowiedzi to pół książki, pozwól więc, że się wypowiem tylko na rzeczy z mojej perspektywy najciekawsze.
Rafał D.:
Nie mogę znaleźć opisów jak reagować na niekorzystne
zmiany, np. za szybkie "zapełnianie się" bufora,
przepełnienie bufora itd.

Nie znajdziesz opisu, bo działania są zależne od konkretnej sytuacji. Ogólnie jest tak, że bufor projektu może mieć jeden z trzech kolorów, determinowany za pomocą "fever chart": zielony, żółty, czerwony. Jeżeli bufor jest w zielonym nie robisz nic, jak jest żółty planujesz działania jak jest czerwony działania te wdrażasz w życie. Jakie to są konkretnie działania to zależy od sytuacji. Najczęstsze przypadki: zrównoleglanie zadań, sprawienie aby zasoby przygotowały się do zadań przed zadaniami, zapewnienie absolutnej jednozadaniowości zasobom realizującym zadania.
Wydaje mi się że równie silnym problemem jest podjęcie decyzji czy zadanie wykonane jest już "wystarczająco dobrze" z którego de facto wynika prawo Parkinsona (no może pomijając lenistwo ;) ). W podejściu "klasycznym" sprawę tę załatwia deadline, on daje pewność że jeśli zadanie jest w tym momencie zrobione "znośnie" to będzie zakończone.

Taaa, to jest problem każdego kierownika projektu IT: dopieszczanie kodu może trwać w nieskończoność. Problem w tym, że jakość definiuje się jako "zgodność z wymaganiami użytkownika" a nie wymaganiami wewnętrznymi programisty. Sprawę załatwia albo odpowiednia postawa task managera, który nie pozwala swoim zasobom bawić się w goldplating albo (lepsze rozwiązanie, bo systemowe) Test Driven Development. W przypadku TDD sprawa jest jasna - jak się wszystkie testy wykonują poprawnie oddajemy zadanie dalej.
Czyli reasumując, jak przekonać ludzi do przyjęcia zasady "wystarczająco dobrze" i faktycznego oddawania zadań "ASAP"?

Najprościej? Zmieniając system pomiaru. "Powiedz mi co mierzysz a powiem Ci jak będę się zachowywał".
Jeśli dobrze rozumiem zużycie buforów monitoruję pytając się ludzi o ocenę ich "progressu", tj. pytając "ile jeszcze ci zostało?". Czy nie wracamy tutaj do problemu którego niby się pozbyliśmy tj. ustalania przesadzonych, z za dużymi buforami, dat określających koniec zadania?

Dobrze rozumiesz, tylko że to nie jest żaden progress. To jest pytanie odwrotne. Ile jeszcze zostało do zakończenia. Przy czym za udzielenie odpowiedzi NIGDY NIKOGO nie spotyka kara. Ta odpowiedź jedyne co ma zrobić to pozwolić na wyliczenie jaki jest obecny obraz przyszłej sytuacji w projekcie. Problem, o którym piszesz nie występuje, gdyż nie podaje się żadnych dat. Operuje się tylko i wyłącznie na długości poszczególnych zadań a nie na datach.

Jeszcze raz: w projekcie zamodelowanym metodą łańcucha krytycznego nie występują żadne daty zakończenia zadań pośrednich z projektu. Ważna jest tylko i wyłącznie data zakończenia projektu i dlatego to ją chroni się buforem.
Tj. na przykład, mam łańcuch z zadaniami na 5, 3 i 2 dni i
bufor na 5 dni. Czy penetracja bufora następuje dopiero
11go dnia niezależnie od tego które zadanie jest
wykonywane czy może już 6go jeśli wciąż trwa
zadanie pierwsze?

Penetracja bufora może nastąpić na koniec dnia pierwszego, jeżeli na koniec tego dnia task manager 1go zadania zaraportuje np., że do zakończenia zadania potrzebuje jeszcze 6 dni. I już masz skonsumowanie 2 dni bufora, co system wychwyci i pokaże kierownikowi projektu.

Uff, na razie tyle. Więcej ewentualnie na priv. Mogę dać np. linka do porządnego i dobrze zdokumentowanego software. Ale to na priv, bo nie chcę robić reklamy.

Pozdrawiam,
Szymon Włochowicz
Link do wypowiedziLink
Rafał D.

Rafał D. Head of Production,
Locon Sp. z o.o.

Temat: Pytania o podstawy w Critical Chain Project Management

Szymon Włochowicz:
Jeśli dobrze rozumiem zużycie buforów monitoruję pytając się ludzi o ocenę ich "progressu", tj. pytając "ile jeszcze ci zostało?". Czy nie wracamy tutaj do problemu którego niby się pozbyliśmy tj. ustalania przesadzonych, z za dużymi buforami, dat określających koniec zadania?

Dobrze rozumiesz, tylko że to nie jest żaden progress. To jest pytanie odwrotne. Ile jeszcze zostało do zakończenia. Przy czym za udzielenie odpowiedzi NIGDY NIKOGO nie spotyka kara. Ta odpowiedź jedyne co ma zrobić to pozwolić na wyliczenie jaki jest obecny obraz przyszłej sytuacji w projekcie. Problem, o którym piszesz nie występuje, gdyż nie podaje się żadnych dat. Operuje się tylko i wyłącznie na długości poszczególnych zadań a nie na datach.

Tu widzę największy problem. Ludzie będą szacować z zapasem, nawet podświadomie. Nie ma znaczenia czy data zakończenia czy czas pozostały, jak zapytam gościa ile mu zostało to on myśląc 2 powie 3. Mam przesadzoną penetrację bufora, mam nadmierne reagowanie, wracam do początku. Czyli sednem jest by grupa mocno uwierzyła w to jak ważne jest szacowanie.

Dzięki wielkie za odpowiedź!

Jeśli chodzi o linka to chętnie, poproszę.Rafał D. edytował(a) ten post dnia 09.02.09 o godzinie 21:25
Link do wypowiedziLink
Szymon Włochowicz

Szymon Włochowicz Wykładowca, Wyższa
Szkoła Bankowa we
Wrocławiu

Temat: Pytania o podstawy w Critical Chain Project Management

Rafał D.:

Tu widzę największy problem. Ludzie będą szacować z zapasem, nawet podświadomie. Nie ma znaczenia czy data zakończenia czy czas pozostały, jak zapytam gościa ile mu zostało to on myśląc 2 powie 3.
>

W jakim celu miałby tak mówić? Który element kultury organizacyjnej obecnej w miejscu pracy miałby zachęcać do takiego zachowania? Ewentualnie: który element miałby karać za podanie poprawnego szacunku?

Jeżeli występuje taka sytuacja, o której piszesz to zwróć uwagę, że coś jest mocno nie tak z daną organizacją. Na proste pytanie (ile czasu pozostało ci do zakończenia aktualnego zadania?) kierownik nie dostaje od swoich pracowników wiarygodnej informacji. W takim środowisku niezależnie od zastosowanej metody zarządzania projektami będziesz dostawał błędne wyniki. Jeżeli pracownik boi Ci się powiedzieć co myśli to nie jest to problem rozwiązywalny za pomocą procesów i procedur zarządzania projektami.

Link poszedł na priv.

Pozdrawiam,
Szymon
Link do wypowiedziLink
Rafał D.

Rafał D. Head of Production,
Locon Sp. z o.o.

Temat: Pytania o podstawy w Critical Chain Project Management

Raczej odwrotnie: do tej pory działali tak, że dawali zapas, co teraz miałoby ich zachęcić do podawania realnych szacunków? A nawet w najlepszej organizacji zawsze pozostanie przyczyna przeszacowywania po to by w przyszłości na podobne zadanie nie dostać mniej bo "poprzednio dało się krócej".

Z tym że rozumiem że jest to do przejścia, tylko wydaje mi się że mocno trzeba zwrócić na to uwagę, szczególnie przy wprowadzaniu metody.
Link do wypowiedziLink

konto usunięte

Temat: Pytania o podstawy w Critical Chain Project Management

Rafał D.:
Raczej odwrotnie: do tej pory działali tak, że dawali zapas, co teraz miałoby ich zachęcić do podawania realnych szacunków?
Najlepiej pokazać im korzyści. Zakładam, że pracując u was wasi informatycy mają zaspokojone podstawowe potrzeby bytowe i że lubią swoją pracą. Na tym etapie stanie się dla nich ważne praca w wyjątkowej organizacji. Udział w dobrze poprowadzonych warsztatach CCPM da im obraz potencjału korzyści płynących z zastosowania CCPM. Bo potencjał jest ogromny. Praca w firmie, która najsprawniej realizuje projekty informatyczne to by było coś... Fala entuzjazmu poszkoleniowego właściwie gwarantuje radykalne skrócenie szacunków czasowych poszczególnych etapów.
A nawet w najlepszej organizacji zawsze pozostanie przyczyna przeszacowywania po to by w przyszłości na podobne zadanie nie dostać mniej bo "poprzednio dało się krócej".
Tu wiele zależy od ciebie i "zarządu" firmy. Jak pisali koledzy wcześniej klucz jest, aby nie oceniać pracownika przez pryzmat tego w jakim terminie się wyrobił - bo takie zachowanie to bramka samobójcza. Jeżeli unikniesz tego zagrożenia, powinno być OK.
Link do wypowiedziLink

konto usunięte

Temat: Pytania o podstawy w Critical Chain Project Management

Rafał D.:
Raczej odwrotnie: do tej pory działali tak, że dawali zapas, co teraz miałoby ich zachęcić do podawania realnych szacunków?
Najlepiej pokazać im korzyści. Zakładam, że pracując u was wasi informatycy mają zaspokojone podstawowe potrzeby bytowe i że lubią swoją pracą. Na tym etapie stanie się dla nich ważne praca w wyjątkowej organizacji. Udział w dobrze poprowadzonych warsztatach CCPM da im obraz potencjału korzyści płynących z zastosowania CCPM. Bo potencjał jest ogromny. Praca w firmie, która najsprawniej realizuje projekty informatyczne to by było coś... Fala entuzjazmu poszkoleniowego właściwie gwarantuje radykalne skrócenie szacunków czasowych poszczególnych etapów.
A nawet w najlepszej organizacji zawsze pozostanie przyczyna przeszacowywania po to by w przyszłości na podobne zadanie nie dostać mniej bo "poprzednio dało się krócej".
Tu wiele zależy od ciebie i "zarządu" firmy. Jak pisali koledzy wcześniej klucz jest, aby nie oceniać pracownika przez pryzmat tego w jakim terminie się wyrobił - bo takie zachowanie to bramka samobójcza. Jeżeli unikniesz tego zagrożenia, powinno być OK.
Link do wypowiedziLink
Krzysztof Abramowski

Krzysztof Abramowski TOC Consulting,
partner

Temat: Pytania o podstawy w Critical Chain Project Management

Podpisuję się pod tym co napisał Szymon.
Dodałbym od siebie jeszcze jeden istotny element.

W środowisku konsultantów wdrażających rozwiązania TOC na świecie mówi się:

Rozwiązania Teorii Ograniczeń są proste .....
ale nie są łatwe.

Są proste bo ich mechanika nie jest skomplikowana (raptem kilka zastrzyków*).
Nie są łatwe bo wymagają zmiany paradygmatów (głęboko zakorzenionych przekonań, przyzwyczajeń).

A paradygmatów łatwo się nie zmienia (bo głęboko zakorzenione).

W związku z tym istotne jest aby proces wdrożeniowy zawierał w sobie działania ułatwiające przejście uczestników przez zmianę paradygmatu a elementy rozwiązania uwzględniały także mechanizmy pozwalające na ich utrwalenie.

Łańcuch Krytyczny zmienia kilka paradygmatów. Np. sposób szacowania czasu trwania zadania i rozliczanie zasobu z rzeczywistego czasu realizacji.
Pozdrawiam

*zastrzyk - w slangu TOC element rozwiązania [ang. injection]Krzysztof Abramowski edytował(a) ten post dnia 10.02.09 o godzinie 19:36
Link do wypowiedziLink
Rafał D.

Rafał D. Head of Production,
Locon Sp. z o.o.

Temat: Pytania o podstawy w Critical Chain Project Management

Dokładnie. Dlatego tak bardzo interesują mnie faktyczne wdrożenia, szczególnie w dziedzinie IT (z racji znajomości) no i przy analizie rozmiaru grupy i skali (w jak dużym obszarze firmy) wdrożenia.

No ale to już osobny temat :)
Link do wypowiedziLink

konto usunięte

Temat: Pytania o podstawy w Critical Chain Project Management

Sporo casów i materiałów można znaleźć na stronie najlepszego dostawcy oprogramowania do CCPM:

http://www.realization.com/

Są filmiki i krótkie fiszki casów.
Link do wypowiedziLink
Sławomir Bojan

Sławomir Bojan Credit Agricole Bank
Polska S.A.

Temat: Pytania o podstawy w Critical Chain Project Management

Rafał D.:
Raczej odwrotnie: do tej pory działali tak, że dawali zapas, co teraz miałoby ich zachęcić do podawania realnych szacunków? A nawet w najlepszej organizacji zawsze pozostanie przyczyna przeszacowywania po to by w przyszłości na podobne zadanie nie dostać mniej bo "poprzednio dało się krócej".

Z tym że rozumiem że jest to do przejścia, tylko wydaje mi się że mocno trzeba zwrócić na to uwagę, szczególnie przy wprowadzaniu metody.

Na dzień dzisiejszy jestem wciąż uczącym się teoretykiem, ale jeżeli dobrze rozumiem założenia, to podanie jak najdokładniej terminu zakończenia danego zadania ma na celu zakończenie projektu na czas. Jeśli ocenisz, że jesteś w stanie skrócić czas na realizację swojego zadania o 1 dzień to warto poinformować o tym PM, aby on mógł postawić w stan gotowości zasoby realizujące następne zadanie. Z kolei jeśli w trakcie realizacji dowiesz się, że coś przeszkodziło Tobie i prawdopodobnie czas sie wydłuży, również nie powinieneś czekać z poinformowaniem PM do ostatniego dnia (aby miał on czas na planowanie działań).

jeśli się mylę to mnie poprawcie
Link do wypowiedziLink
Rafał D.

Rafał D. Head of Production,
Locon Sp. z o.o.

Temat: Pytania o podstawy w Critical Chain Project Management

Oczywiście :) Problem w tym że ludzie zazwyczaj tak nie robią i skupić należy się na tym by robili.
Link do wypowiedziLink
Rafał D.

Rafał D. Head of Production,
Locon Sp. z o.o.

Temat: Pytania o podstawy w Critical Chain Project Management

I kolejne pytanie:

Co jeżeli w łańcuchu zasilającym spóźni się zadanie które wykonuje zasób który zaraz po zadaniu w łańcuchu zasilającym ma zadanie w łańcuchu krytycznym? Sytuacja taka wynika najczęściej jeśli rozwiążemy konflikt zasobów i zadanie w łańcuchu zasilającym przesuniemy przed zadanie w łańcuchu krytycznym. (Jeśli nie brzmi jasno to mogę wyjaśnić bardziej ;) ).

Łańcuch zasilający nie zabezpiecza takiej sytuacji. Czy zwyczajnie wtedy liczę zużycie bufora zasilającego i projektowego (wynikające z przesunięcia się zadania następnego w łańcuchu krytycznym)?Rafał D. edytował(a) ten post dnia 03.03.09 o godzinie 13:54
Link do wypowiedziLink
Szymon Włochowicz

Szymon Włochowicz Wykładowca, Wyższa
Szkoła Bankowa we
Wrocławiu

Temat: Pytania o podstawy w Critical Chain Project Management

Rafał D.:
I kolejne pytanie:

Co jeżeli w łańcuchu zasilającym spóźni się zadanie które wykonuje zasób który zaraz po zadaniu w łańcuchu zasilającym ma zadanie w łańcuchu krytycznym?
[...]

Łańcuch zasilający nie zabezpiecza takiej sytuacji. Czy zwyczajnie wtedy liczę zużycie bufora zasilającego i projektowego (wynikające z przesunięcia się zadania następnego w łańcuchu krytycznym)?

Jeżeli spóźnia się zadanie na ścieżce zasilającej to najpierw zużywa się bufor zasilający. Jeżeli zostanie on całkowicie zużyty to dopiero wtedy zaczyna się konsumpcja bufora projektu.

Jeżeli zdarzy się taka raczej nieczęsta sytuacja, że oba zadania miały robić ta sama osoba/te same zasoby to sprawa nadal jest prosta. Każde z aktualnych zadań jest codziennie uaktualnianie zgodnie z informacją o tym ile jeszcze potrwa jego wykonanie. Na tej podstawie wyliczana jest konsumpcja buforów. Wszystkich buforów. Jeżeli to będzie ten sam zasób to na logikę w takim momencie na podstawie przekazanej informacji wyjdzie, że oba bufory są konsumowane.

Zresztą w takiej sytuacji dużo też zależy od stanu samych buforów. W szczególności zależy które z zadań będzie robione jako pierwsze.

Pozdrawiam serdecznie,
Szymon
Link do wypowiedziLink
Rafał D.

Rafał D. Head of Production,
Locon Sp. z o.o.

Temat: Pytania o podstawy w Critical Chain Project Management

OK, oba (zasilający i projektu) są konsumowane, niby wszystko ok, tyle że "konsumpcja" nie wynika z tego co leży u podstaw metody czyli braku zapasu czasu tylko z... niedopatrzenia metody?

Ogólnie bufory są po to by "wyhamowywać" błędy szacowania a bufory zasobów po to by informować zasoby. W naszej sytuacji mamy opóźnianie zadania w łańcuchu krytycznym (i konsumpcję bufora projektu) nie wynikającą z błędów szacowania zadań poprzednich na tym łańcuchu, czyli niejako "dodatkową", oraz mamy błąd informowania bo zależność następstwa między zadaniem na łańcuchu zasilającym a zadaniem na łańcuchu krytycznym nie występuje w sposób jawny.

Po prostu wydaje mi się, że taka sytuacja "łamie" podstawy metody, "omija" zabezpieczenia.
Link do wypowiedziLink
Krzysztof Abramowski

Krzysztof Abramowski TOC Consulting,
partner

Temat: Pytania o podstawy w Critical Chain Project Management

"OK, oba (zasilający i projektu) są konsumowane, niby wszystko ok, tyle że "konsumpcja" nie wynika z tego co leży u podstaw metody czyli braku zapasu czasu tylko z... niedopatrzenia metody?"

Bufory są po to by "pochłonąć zmienność", która występuje w projekcie - włączając w to także przypadki konfliktu zasobów (jeden zasób musi w danym momencie robić dwa zadania)występujące w trakcie realizacji.

"Ogólnie bufory są po to by "wyhamowywać" błędy szacowania a bufory zasobów po to by informować zasoby. "

Bufory są po to by uprawdopodobnić zakończenie projektu w terminie poprzez to, że:

- kumulują rezerwę czasu tam gdzie jest to najkorzystniejsze
- "informują" o stanie projektu dając wczesne ostrzeżenia o zagrożeniach
- umożliwiają kontrolę priorytetów w sytuacjach problematycznych np. opóźnień w dwóch ścieżkach projektu

"W naszej sytuacji mamy opóźnianie zadania w łańcuchu krytycznym (i konsumpcję bufora projektu) nie wynikającą z błędów szacowania zadań poprzednich na tym łańcuchu, czyli niejako "dodatkową""

Penetracja nie wynika z błędów szacowania, tylko ze zmienności występującej w trakcie realizacji.

"oraz mamy błąd informowania bo zależność następstwa między zadaniem na łańcuchu zasilającym a zadaniem na łańcuchu krytycznym nie występuje w sposób jawny."

Występuje w sposób bardzo jawny - zadanie realizowane jest przez ten sam zasób.

W podsumowaniu: Bufory umożliwiają zarządzanie zmiennością występującą w projekcie bez względu na to jakie jest źródło tej zmienności (oczywiście w ramach zdrowego rozsądku)

PozdrawiamKrzysztof Abramowski edytował(a) ten post dnia 10.03.09 o godzinie 10:37
Link do wypowiedziLink
Rafał D.

Rafał D. Head of Production,
Locon Sp. z o.o.

Temat: Pytania o podstawy w Critical Chain Project Management

OK, rozumiem, tylko jedno jeszcze:
Krzysztof Abramowski:
"oraz mamy błąd informowania bo zależność następstwa między zadaniem na łańcuchu zasilającym a zadaniem na łańcuchu krytycznym nie występuje w sposób jawny."

Występuje w sposób bardzo jawny - zadanie realizowane jest przez ten sam zasób.

OK, zapomniałem, że przecież zadanie będące na łańcuchu krytycznym wywłaszczy zadanie na zasilającym i łańcuch nie zostanie "naruszony" i w dodatku zawodnik robiąc zadanie na zasilającym będzie ładnie informowany o tym kiedy przerwie przez bufor zasobu. To de facto jest bezpośrednia odpowiedź na mój problem (może nie potrafię dobrze wyjaśnić o co mi chodzi ale sam to widzę).

Dzięki za odpowiedź!
Link do wypowiedziLink
Krzysztof Abramowski

Krzysztof Abramowski TOC Consulting,
partner

Temat: Pytania o podstawy w Critical Chain Project Management

Właśnie!

A dodatkowo kierownik projektu ma do dyspozycji Narzędzia Logicznego Wnioskowania, a w szczególności "chmurę" (diagram analizy konfliktu), które mu pomagają w analizie sytuacji problematycznych.
Link do wypowiedziLink
« Wróć do tematów
Odpowiedz

Podobne tematy


Następna dyskusja:

TOC a management cockpit




Wyślij zaproszenie do
Anuluj