این اتفاق در خیلی از پروژه‌های توسعه سیستم‌ها رخ داده است. در ادامه توضیحی از هر یك از مراحل فوق برای كسانی كه با مراحل توسعه سیستم آشنا نیستند ارائه می‌شود.

● طوری كهمشتریتوضیح داد:

معمولاً مشتری از آنچه واقعاً نیاز دارد آگاهی كاملی ندارد. او فكر می‌كند كه آگاهی لازم را دارد. او ویژگی‌هایی را در نظر می‌گیرد كه هرگز از آنها استفاده نخواهد كرد. او این ویژگی‌ها را لازم می‌داند برای اینكه می‌ترسد بعداً آنها را اضافه نكند.

● طوری كه مدیر پروژه فهمید:

مسئول پروژه معمولاً برخی جزئیات كلیدی را اشتباه می‌فهمد. این اشتباهات اغلب باعث می‌شود كه پروژه غیر قابل استفاده شود و خیلی از نكات آن، مبهم یا خنده‌دار شوند.

● طوری كه تحلیل گر طراحی كرد:

تحلیل گر مجبور است طوری طراحی كند كه اشتباهات مسئول پروژه را برطرف نماید. یك راه معمول حذف برخی از بخش‌ها و ویژگی‌هاست به گونه‌ای كه بتواند با طرح فعلی كار كند.

● طوری كه برنامه‌نویس نوشت:

برنامه‌نویسان معروف به نفهمیدن ویژگی‌های ضروری یك پروژه هستند. آنها موارد را دقیقاً مو به مو پیاده‌سازی می‌كنند، گاهی اوقات.

● طوری كه مشاور بازرگانی توصیف كرد:

ایل و تبار بازاریابی كابوس مهندسان هستند. آنها ویژگی‌های مربوط به شیك بودن و راحتی پروژه را به مشتری القاء می‌كنند و هیچ توجهی به شرایط واقعی و عملی ندارند.

● طوری كه پروژه مستند شد:

مستند سازی چیزی است كه بعداً به فكر آن می‌افتند یا اینكه هرگز انجام نمی‌شود.

● چیزی كه اجرا شد:

گاهی اوقات ماهها روی ویژگی‌های خاصی كار می‌كنیم كه متوجه شویم این ویژگی‌ها به مشتری ارائه نشده‌اند زیرا آنها در عمل كار نكردند، مجری نفهمیده كه آن ویژگی‌ها چگونه كار می‌كنند یا كسی دیگری تصمیم گرفته است كه آنها انجام نشوند.

● قیمتی كه بهمشتری اعلام شد:

چی فكر كردی! نرم‌افزار گران است. هزینه تمام اشتباهات و نقایص باید در پروژه منظور شود.

● طوری كه پشتیبانی شد:

«به نظر تو اگر این ویژگی را اضافه كنیم باعث نمی‌شود كه مشتری تقاضای پشتیبانی فنی كند». فكر می‌كنم لازم باشد این قسمت را حذف كنیم. سرانجام پروژه با ارائه ویژگی‌های اولیه پایان می‌یابد.

● چیزی كه مشتری واقعاً نیاز داشت:

خیلی آسان تر بود اگر می‌توانستیم نیاز را به درستی تشخیص دهیم. اما هرگز این كار را انجام نمی‌دهیم . . .