שלב הייזום הוא שלב ראשוני בו מועלית דרישה בסיסית למערכת חדשה, או לשינוי משמעותי במערכת קיימת (מהדורה חדשה). ייזום יכול גם להיות התנעה של הכנסת אוסף שינויים למערכת קיימת, אשר נעשים בצורה מסודרת ומתוכננת. ייזום הוא למעשה ההרשאה להתחיל בפרויקט והוא שלב חובה בכל מחזור חיים וכל שיטת ניהול לפיהן ינוהל הפרויקט בהמשך. מטבעו, זהו שלב היולי בו המידע לגבי סוג המערכת או המהדורה הנדרשת, אופייה וטיבה, הוא מעורפל. למרות זאת, נדרשת התייחסות מובנית לשלב זה וכל המידע הידוע מתואר ומתועד במסמך מסודר, קרי מסמך ייזום. לא רק מערכות חדשות, אלא גם שכתובים והכנסת "שינויים ושיפורים" במערכות קיימות, היינו מהדורות חדשות, יעברו שלב זה, כמו את שאר שלבי מחזור החיים.

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

לא נסקור במסגרת זו את כל הפעילויות אלא את המרכזיות המתבצעות בשלב זה (עפ"י נוהל מפת"ח):

הגדרת הלקוח 

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

הגדרת יעדים/מטרות, בעיות, תועלות וחסכונות

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

בדיקת ישימות (היתכנות) ועלות/תועלת

בשלב זה נתקפות שאלות כמו:

• מה התועלות שסביר לצפות מהמערכת (שירותים שהמערכת תיתן)?
• האם צפויים קשיים/מגבלות בתחום הגדרת היישום?
• האם מדובר בטכנולוגיה חדשה ובלתי מוכרת?

בחירת הגורם שיאפיין

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

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

סיכום

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