ניהול פרויקטים

בתוכנת Project-MS משמעות הפקודה Respect היא:

לכבד את כמות המשאבים ולא לאפשר הקצאת יתר שלהם

לכבד את מרכיבי הפרוייקט (SOW (ולוודא שכל המטלות בפרוייקט מטופלות.

להתייחס לקשרים בתרשים הרשת לשם חישוב הנתיב הקריטי

לכבד את עלויות המשאבים ולהתריע על הקצאת חסר שלהם.

אבני דרך חוזיות בפרוייקט חשובות לספק מכיוון ש:

מתבצע בהן תשלום. הפרתן עלולה לגרום להפסקת הפרוייקט

בהן מעורבים משאבים קריטיים

בהן נבחנת האינטגרציה של הפרוייקט

הן עוזרות בחיזוי מועד הסיום של הפרוייקט.

בעיצוב מסכי ניהול ל-4 כרטיסים כיצד עדיף להקצות את המשימה?

לעצב ארכיטקטורה משותפת לכל הכרטיסים, להעביר ל-QA ,במקביל לפתח כרטיס ראשון – להעביר ל-QA וחוזר חלילה

להקצות את פיתוח ארבעת הכרטיסים כמשימה אחת שלמה. לקבל רק פתרון שלם לכולם

לפתח את ארבעת הכרטיסים. אח"כ לעצב ארכיטקטורה משותפת. לנהל איכות בגישת המפל.

להקצות כרטיס אחד. לבדוק איכות. להקצות כרטיס נוסף וחוזר חלילה.

כיצד מתמודדים עם פרוייקט שאורך זמן מעבר למועד שהובטח ללקוח?

מחלקים את כלל מרכיבי הפרוייקט (SOW (בין כל אנשי הצוות.

בשלב ראשון מפתחים רק תכונות חיוניות. במהלך ההטמעה מפתחים תכונות נוספות חיוניות פחות.

מודיעים בשלב מוקדם שהגדרת הפרוייקט אינה ישימה.

מנהלים את הדרישות בשיטת Pull - Kanban כך שהעובדים מושכים את המשימות.

המהלך להשבחת ערך הפרוייקט שעל מנהל הפרוייקט לעשות הוא:

לדמיין דרישות שעדיין לא אופיינו אך צפויות לעלות בעתיד.

לממש את כלל הדרישות של אנשי השיווק.

Minimum Viable Product להגדיר

לבצע Overspecification וכן Overdesign

מרכיבי פרישת פונקציית האיכות – Deployment Function Quality הם:

1 .הגדרה איכותית של המוצר. 2 .פרישה של סוגי לקוחות פוטנציאליים. 3 .הגדרת הפער. 4.בחינת תכונות מתחרים. 5 .הגדרת לוחות זמנים

1 .זיהויי איכויות אנשי הצוות השונים. 2 .פרישה של תכונות קריטיות להצלחת הפרוייקט. 3 .בניית עץ המוצר. 4.בחינת שביעות רצון הלקוחות. 5 .חלוקת המשימות בין אנשי הצוות.

1 .זיהוי תכונות קריטיות 2 .פרישה של סוגי לקוחות פוטנציאליים. 3 .הגדרת רמת איכות מתקבלת. 4.בחינת איכות מתחרים. 5 .הגדרת לוחות זמנים

1 .זיהוי פרסונה. 2 .זיהוי פונקציית האיכות. 3 .פרישה לתכונות. 4 .בחינת ביצועי מתחרים. 5 .הגדרת יעדי פיתוח

חמש הרמות במודל הבשלות model maturity capability הן:

Initial, Repeatable, Defined, Managed, Optimizing

Managed, Defined, Optimizing, Supported, Repeatable

Defined, Managed, Optimizing, Supported, Agile

Initial, Optimizing, Defined, Managed, Repeatable

למוצרים הבאים מהי זווית התקיפה התואמת - התשובות משמאל לימין: תרופה חדשה, מדפסת הזרקת דיו,מכונית סינית, Tesla - מכונית חשמלית

Skimming, Storming, Flooding, Piercing

Storming, Flooding, Piercing, Skimming

Skimming, Storming, Piercing, Flooding

,Piercing, Storming Skimming, Flooding

מה עקרון ה-Flow מבחינת המנהיגות של מנהל הפרוייקט?

התאמת משימות לעובד כך שיתלהב לעשות אותן. הוספת קושי עם עלית הכישורים.

הזרמת מטלות חדשות ככל שהעובד מסיים את המטלות הנוכחיות.

מעקב שוטף אחר עמידת העובד בייעדים

שמירה שוטפת על רמת קושי קבועה על המטלות בפרוייקט

חסרונות המבנה המטריציוני הם:

מחוייבות רק למשימה אחת, קו פיקודי, נהול לפי ייעדים, מהירות

יעילות הקצאת משאבים, אבטלה סמוייה, שינוי עומסים בציר הזמן, חוסר מקצוענות

דלת מסתובבת, חוסר מחוייבות, ריבוי משימות, קושי לאמוד לוחות זמנים.

יעילות, גמישות, מקצוענות, כפל מנהלים

חמשת השלבים בפרויקט Solicited מבחינת הספק הם:

Resources, Process, Gap, Taper, Negotiate

Materials & SOW, BOM, Non-Development-Items, WBS, Time

Materials, Cost, Outsourcing, Offshoring, Non-Development-Items

RFI, Taper, RFQ, Negotiate, Deliver

כאשר לפרוייקט אין מועד מסירה קשיח:

מסירה מוקדמת, הצוות מתגייס, הפלטפורמה ייקרה מידי, הביצועים בינוניים.

משאבים לא מוקצים, לוחות זמנים מתארכים, הדרישות מתווספות, בסוף נעשה קיצוץ באיפיון.

משך הפרוייקט מתארך, עובדים נוטשים למקומות עבודה חלופיים, קושי בהעברת המקל, איחור, עלות גבוהה.

יש לרכז את מלוא הדרישות, להקצות אותן למשאבים שאינם צואר בקבוק, לוודא איכות, להביא למצויינות

בפיתוח Agile ,לאחר שאופיינו דרישות בתחילת הפרוייקט:

אין הוספה או גריעה של דרישות.

יש רק גריעה של דרישות אם מתברר לקראת סיום הספרינט קושי לעמידה בייעדים

במפגש היומי (יישיבה בעמידה) מתווספות לעיתים מזומנות דרישות של הלקוח.

עלולות להתווסף דרישות נוספות של הלקוח ובעקבותיהן אי עמידה בייעדי הספרינט.

בניהול פרוייקט מסוג C:

הקפאת הדרישות בטרם תחילת הפרוייקט, שני סבבים לכל היותר, תשלום ב-Plus Cost ,הקפדה על עמידה במפרט

הקפאת דרישות בתום רבעון ראשון, שני סבבי שיפורים, תשלום בשיטת Time & Materials ,מפגשים פורמליים.

הקפאת הדרישות בשלב מאוחר, יש בנייה של הוכחת היתכנות, המפגשים תכופים, מספר רב של סבבים.

אין הקפאת דרישות, אי ודאות ברמה בינונית, בניית ארכיטקטורות חלופיות, Concept Of P

בתוכנת Project-MS כאשר חבר צוות מתחלף באחר מקובל:

עדכן כתובת דוא"ל לתכתובות במהלך הפרוייקט.

לעדכן החלקת משאבים (שרשרת קריטית).

לעדכן גרף עומס משאבים לפי כישוריהם היחסיים.

אין צורך לעדכן משום שחברי הצוות לרוב אנונימיים, התייחסות רק למקצועיות שלהם.

ניהול יומיומי של הפרוייקט מבוצע באמצעות:

חישוב פרק הזמן עד לסיום.

תרשים הגאנט.

ניהול לפי יעדים, מפגשי One on One ללא עדכון שוטף של התוכנה.

חישוב המאמץ שחלף מהייזום

אחד הכלים המקשים על "תפירת" מכרז הוא:

הפרדה בין תכונות הביצוע לבין מימד העלות.

. שיקלול "תשואה שולית פוחתת" בנתינת הציונים להצעות השונות.

אנונימיות של החברות שניגשות למכרז.

הפרדה בין הצוות המאפיין את התכונות ומשקלן לצוות שנותן ציונים לחלופות.

תופעת Multitasking Bad היא תוצאה של:

עבודה במבנה מטריציוני

עבודה במבנה פרויקטלי

מנהל פרוייקט שאינו מתעדכן בהתקדמות הפרוייקט.

מנהל פרוייקט עם נטיה ל-MicroManagement

בעיה הנגזרת מפרישׂת פונקציית האיכות– Deployment Function Quality:

עליית רמת הדרישות של הלקוחות מהפלטפורמה.

התפשרות הלקוחות עם מוצרים ברמה נמוכה.

היווצרות אוקיינוס כחול.

התכנסות כלל הייצרנים למוצרים חסרי בידול – commodity.

:כאשר Stuck in the Middle הוא מוצר

אין לו יתרון של עלות נמוכה או של בידול.

כאשר הוא גם איכותי וגם זול (דוגמת Ikea.(

כאשר האסטרטגיה הגנרית שלו אינה מובהקת.

כאשר מחירו אינו זול אך גם איננו גבוה.

ב"המחרה":

מתבצע משא ומתן מול הספקים הסופיים.

המחיר נקבע על פי העלות לייצרן.

המחיר נקבע על פי ערכו ללקוח.

מבוצע תהליך של מכרז הולנדי.

משמעות המונח פרישׂה – Deploy בפרישׂת פונקצית האיכות היא:

הגדרת ייעדי השבחה לפרוייקט – ה-Gap.

אבחון משימות שונות שביחד יביאו להשגת מרכיב בפונקצית האיכות.

זיהוי המרכיבים השונים של פונקצית האיכות.

בחירת ה-Persona שלה מייעדים את המוצר.

הבעיה ברמת הבשלות Initial היא:

לא זמינה תוכנה לתמיכה במודל זה.

בירוקרטית יתר של התהליך.

. מנהל הפרוייקט הופך לצוואר בקבוק.

חזרה על טעויות שנעשו, חוסר אחידות וחוסר שליטה.

משמעות שלב הרידוד – Taper בחיי הפרוייקט היא:

בחירה מושכלת של דרישות שהוצעו בשלב ה-RFI.

משא ומתן לאפשור שינויים מסויימים לאחר סיום הפרוייקט

צמצום המאמץ באינטגרציה עם המערכות האחרות בארגון.

צמצום דרישות הספק בנושאים של תקציב וזמינות לקוחות.

תפקיד הפלטפורמה הוא:

פיתוח מודולים שונים שצירופם יספק דרישות של לקוחות שונים.

פיתוח רכיב משותף שתומך באסטרטגיות גנריות שונות.

פיתוח משפחת מודולים שניתן למכור ללקוח גם לאחר ההתקנה הראשונית.

לאפשר ריבוי פרוייקטים מסוג B :Generation Next.

בפיתוח Agile ,לקראת סיום הפרוייקט:

במפגש היומי (ישיבה בעמידה) מתווספות לעיתים מזומנות דרישות של הלקוח.

יש רק הוספה של דרישות – Way the By Oh.

אין הוספה או גריעה של דרישות.

ש לנפות דרישות כך שהמאמץ יתרכז להשלים פונקציונליות חדשה.

בניהול פרוייקט מסוג A:

ד. לקראת סיום הפרוייקט מאבחנים דרישות שיש לוותר עליהן לשם הצגת הישגים קונקרטיים.

א. הניהול פורמלי, התקשורת בצוות לעיתים רחוקות, הדגש על עמידה מדויקת בהתחייבויות.

ב. מונעים סבבי פיתוח על ידי פירוק עבודה חוזרת לתת מכלולים.

ג. מקפידים על הוספת תכונה חדשה אחת בלבד למוצר.