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

בתוכנת 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 הן:

Defined, Managed, Optimizing, Supported, Agile

Initial, Repeatable, Defined, Managed, Optimizing

Managed, Defined, Optimizing, Supported, Repeatable

Initial, Optimizing, Defined, Managed, Repeatable

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

,Piercing, Storming Skimming, Flooding

Skimming, Storming, Flooding, Piercing

Storming, Flooding, Piercing, Skimming

Skimming, Storming, Piercing, Flooding

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

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

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

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

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

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

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

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

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

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

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

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

Resources, Process, Gap, Taper, Negotiate

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

RFI, Taper, RFQ, Negotiate, Deliver

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

תרשים הגאנט.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ב"המחרה":

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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