WBS הוא תשובה לשאלה 'מה צריך לעשות כדי לסיים את הפרויקט'. הוא לא לוח זמנים (אין בו תאריכים), הוא לא הקצאת משאבים (אין בו שמות). הוא רשימה היררכית של כל העבודה. הוא בנוי כעץ הפוך: בראש - מטרת הפרויקט. תחת זה - 5-8 ענפים גדולים (תכנון, פיתוח, בדיקות, השקה, וכו'). תחת כל ענף - 4-8 משימות קונקרטיות. סה'כ 20-40 משימות לפרויקט SMB טיפוסי. WBS גדול מ-60 משימות זה כנראה פרויקט שצריך להתחלק לשניים.

כל משימה ברמה 3 חייבת להיות בין 4 ל-40 שעות עבודה. למה? פחות מ-4 שעות = יותר מדי פירוט, מקבלים WBS של 200 משימות שלא ניתן לנהל. יותר מ-40 שעות = משימה גדולה מדי, ההתקדמות שלה לא ברורה, וקל לפספס איחור של שבועות. טכניקת פירוק: התחל מלמעלה (מטרה), שאל 'אילו 5-8 דברים גדולים חייבים להיגמר?'. תחת כל אחד שאל 'אילו 4-8 משימות נדרשות?'. אם משימה גדולה מ-40 שעות - פצל ל-2-3. אם פחות מ-4 שעות - אחד עם משימה קרובה.

קליניקת שיניים השיקה אפליקציה לקביעת תורים. WBS: רמה 1 - אפליקציית תורים זמינה ללקוחות. רמה 2 (6 ענפים): עיצוב UX, פיתוח Backend, פיתוח Frontend, אינטגרציה עם המערכת הקיימת, בדיקות, השקה. רמה 3 דוגמה לענף עיצוב: 1) מחקר משתמשים (8 שעות), 2) Wireframes (12 שעות), 3) Mockups (16 שעות), 4) Prototype אינטראקטיבי (8 שעות). סה'כ 44 שעות לענף עיצוב. כל 6 הענפים יחד = 280 שעות = 7 שבועות עבודה לצוות של 2. WBS שלם הוכן ב-3 שעות, הצוות הסכים, והפרויקט יצא לדרך בלי ויכוחים.

1) לערבב WBS עם לוח זמנים. WBS אומר מה צריך לעשות, לא מתי. אל תוסיף תאריכים בשלב הזה - זה השלב הבא. 2) לכלול ב-WBS משימות תפעוליות חוזרות. 'ישיבת צוות שבועית' זה לא משימה ב-WBS, זה תפעול. WBS כולל רק עבודה חד-פעמית של הפרויקט. 3) לרדת ליותר מ-3 רמות. רמה 4 ו-5 הופכות את ה-WBS לבלתי ניהולי. אם משימה דורשת פירוק נוסף - היא עצמה תת-פרויקט, וצריך WBS נפרד עבורה.