70% projektów w IT kończy się porażką. Tak się przyjęło mówić i traktować to jako prawdę objawioną, a czasem jako drogowskaz. Utarło się to do tego stopnia, że nikogo w branży to już nie rusza. No może poza faktycznymi interesariuszami tego projektu, którzy tracą pieniądze, reputację czy cenny czas. Dlaczego tak jest? Są tacy, którzy próbowali analizować problem, ale w tej analizie brakuje wniosków, które mogą prowadzić do zmiany sytuacji. Moim zdaniem dzieje się tak, ponieważ w IT odpowiedzialność jest rozmyta na każdym poziomie struktury organizacji. Nikt nie odpowiada za straty i wpadki, bo w IT niczego nie da się udowodnić. Ta prezentacja ma za zadanie zwiększyć szansę na przeżycie Twojego projektu. Zgłębimy metody ułożenia odpowiedzialności w strukturze firmy, tak aby zniwelować rozmyte obszary i wprowadzić przejrzystość na wszystkich poziomach. Sprawdzimy, jak zaprojektować kulturę i etykę pracy zespołu oraz dopasować je do specyfiki biznesu. Popracujemy nad likwidacją kontroli ego w zespole oraz wykorzystamy militarne taktyki do zwinnego adaptowania się do środowiska biznesowego. Na koniec dorzucimy trochę AI, które pomoże nam w badaniu wpływu decyzji na interesariuszy projektu. Moje doświadczenie w branży IT obejmuje pracę w każdym z obszarów oraz na różnych stanowiskach. Od szeregowego programisty, przez presale, audyt projektów i firm IT, pełnienie roli CTO czy głównego architekta aż do zarządzania własnymi firmami. Brałem udział zarówno w projektach, które się udały, jak i tych, które upadły, a także tych, które przez aktywną minimalizację strat udało się wyciągnąć na zero, ratując fundusze interesariuszy. Dzięki temu mogę przedstawić unikatowe spojrzenie na temat, przekazując Ci praktyczne narzędzia i strategie, które zwiększą szansę na sukces Twoich projektów.

1. Misja jest najważniejsza.
Stworzyć ten 1 projekt w IT,
który nie skończy się klapą.
Jakub Sikora
CTO | Tech Leader | Speaker
www.mstechsummit.pl/en
ORGANIZER:

2. 2
CONTEXT
70% projects fail [1]
56% delivers less value
than expected [2]
45% ends up over budget
[2]
13% unclear goals [1]
11% bad planning [1]
6% team conflicts [1]
[1] https://teamstage.io/project-management-statistics/
[2] https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/delivering-large-scale-it-projects-on-time-
on-budget-and-on-value

3. 3
CONTEXT
70% projects fail [1]
56% delivers less value
than expected [2]
45% ends up over budget
[2]
44% miscommunication
business - team [2]
[1] https://teamstage.io/project-management-statistics/
[2] https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/delivering-large-scale-it-projects-on-time-
on-budget-and-on-value

4. 4
CONTEXT – FAILURE COSTS
Client / Investor
• Money loss
• Reputation loss
• Time loss
Provider
• Reputation loss
• Client loss
Team
• Stress

5. 5
CONTEXT – AFTER DOING ANYTHING WITH THE PROBLEM
20% [1]
[1] https://teamstage.io/project-management-statistics/
[2] https://www.mckinsey.com/capabilities/mckinsey-digital/our-insights/delivering-large-scale-it-projects-on-time-
on-budget-and-on-value

6. 6
WHY ME?
 Before
 Lead dev & internal consultant for a big
Software Agency
 CTO of own VC funded startup
 CTO of international startup from the UK
 Now
 Consultant with big projects for DACH & polish
public companies
 Chief Architect in the UK Healthcare & BI
company
 Organizer of community events in IT as board
member of Gruba.IT
linkedin.com/in/jakubsikorapl/

7. 7
MAIN PROBLEMS IN FAILING IT PROJECTS
 Team focused on building up CV
 “Agile”
 Responsibility

8. 8
TEAM – BUILDING SENSE OF OWNERSHIP
source: http://www.quickmeme.com/meme/35ykp6

9. 9
TEAM – BUILDING SENSE OF OWNERSHIP
Not bad teams.
Bad leaders.
source: https://www.digitalmomblog.com/boss-memes/

10. 10
TEAM – BUILDING SENSE OF OWNERSHIP
My effort matters.
source: https://tenor.com/search/im-helping-gifs/

11. 11
TEAM – BUILDING SENSE OF OWNERSHIP
Decentralized
command.
https://imgflip.com/memegenerator/Two-Buttons

12. 12
TEAM – BUILDING SENSE OF OWNERSHIP
Decentralized
command.

13. 13
TEAM – BUILDING SENSE OF OWNERSHIP
Decentralized
command.
https://imgflip.com/memegenerator/Two-Buttons

14. 14
TEAM – BUILDING SENSE OF OWNERSHIP
Ego is the enemy.
https://www.rvcj.com/15-hilarious-insult-memes-must-send-
enemies/

15. 15
TEAM – SUMMARY
 People follow leaders
 Bigger picture
 Ego is the enemy

16. 16
TEAM – SUMMARY
• Extreme Ownership Jocko Willink
• https://www.youtube.com/watch?v=ZbkiF-Tx-
RQ&pp=ygUaamFrdWIgc2lrb3JhIGJvaWxpbmcgZnJvZ3M%3D
• https://www.amazon.com/Competitive-Engineering-Requirements-Software-Planguage/dp/0750665076
• https://jockopodcast.com
• https://hive.com/blog/extreme-ownership-principles/

17. 17
AGILE
source: https://fearlessagility.com/agile-memes

18. 18
AGILE
source: https://www.historynet.com/air-force-maverick/
Colonel
Boyd and his
OODA loop.

19. 19
AGILE
Observe
Orient
Decide
Act

20. 20
AGILE
Observe
Orient
Decide
Act
 Zbieranie feedbacku
 Wiedza o otoczeniu biznesowym i domenie
 Wiedza o zespole
 Monitorowanie postępów
 Zbieranie wymagań

21. 21
AGILE
Observe
Orient
Decide
Act
 Analiza zebranych informacji
 Redukcja szumu informacyjnego
 Synteza w dane potrzebne do decyzji

22. 22
AGILE
Observe
Orient
Decide
Act
 ”Hypothesis phase”
 Forming & choosing the decision
 First-conclussion bias & bayesian updating

23. 23
AGILE
Observe
Orient
Decide
Act
 „Test phase”
 No overthinking - acting
 Agility in adapting to changes

24. 24
AGILE
Observe
Orient
Decide
Act
 Zbieranie feedbacku
 Wiedza o otoczeniu biznesowym i domenie
 Wiedza o zespole
 Monitorowanie postępów
 Zbieranie wymagań

25. 25
AGILE – OODA W PROJEKCIE
Stakeholder
analysis.
source: http://concepts.gilb.com/
1. Observe.

26. 26
AGILE – OODA W PROJEKCIE
Impact
Estimation
Table.
2. Orient.

27. 27
AGILE – OODA W PROJEKCIE
Event
storming.
2. Orient.
source: https://mrpicky.dev/design-level-event-storming-with-
examples/

28. 28
AGILE – OODA W PROJEKCIE
3. Decide.
source: https://www.meme-
arsenal.com/en/create/meme/2595566

29. 29
AGILE – OODA IN A PROJECT
4. Act.

30. 30
AGILE
 Single iteration (OODA in OODA)
 Project meta-level (methodology etc.)
 Life decision

31. 31
AGILE
What’s the difference?

32. 32
AGILE
What’s the difference?
 Abstraction level
 Adapt to changes, not report progress
 Bring Your Own Structure

33. 33
AGILE
How to implement OODA loop? With OODA loop.

34. 34
AGILE
How to implement OODA loop? With OODA loop.

35. 35
AGILE
• https://dostarczajwartosc.pl/post/2020/2020-03-27-podcast-
dostarczajwartosc-17-dlaczego-warto-nagrac-podcast-z-szafy-w-czasach-
izolacji-zastosowanie-petli-ooda-w-praktyce/
• https://www.artofmanliness.com/character/behavior/ooda-loop/
• https://fs.blog/john-boyd-ooda-loop/

36. 36
OWNERSHIP
source: https://krystof.litomisky.com/2021/03/23/extreme-
ownership-book-notes/

37. 37
OWNERSHIP
Vertical responsibility?

38. 38
OWNERSHIP
source: https://www.allaboutlean.com/hoshin-kanri-3/bird-shit-
hierarchy/

39. 39
OWNERSHIP
source: https://www.allaboutlean.com/hoshin-kanri-3/bird-shit-
hierarchy/

40. 40
OWNERSHIP
DM
Area 1
Area 2
Area 3
PM
Leader & team
Horizontal
responsibility.

41. 41
OWNERSHIP
Implement horizontal responsibility.
1. Observe
 current environment, structure
 existing processes
 culture

42. 42
OWNERSHIP
Implement horizontal responsibility.
2. Orient
 Identify problems
 Workout strategies
 Define targets / goals

43. 43
OWNERSHIP
Implement horizontal responsibility.
3. Decide
 Workout action plan with milestones
 Plan for required resources like traning days and
handbooks
 Make a decision

44. 44
OWNERSHIP
Implement horizontal responsibility.
4. Act
 Conduct tranings
 Communicate progress and goals
 Introduce post-mortems and invite people to join

45. 45
OWNERSHIP - SUMMARY
 Vertical vs horizontal responsibility
 Project post-mortems
 Implement post-mortem action points

46. 46
SUMMARY
 Read about main principles of Extreme Ownership
 Eliminate toxic behaviours
 Decentralize planning and decision making
 Implement OODA loop
 https://codefile.io/f/JdTbKm4Ubr

47. www.mstechsummit.pl/en
Thank you for watching!
Feel free to ask your questions
and rate the presentation.
ORGANIZER: