برخلاف بیشتر سیستم‌ها، اسکرام آغازش و پایانی رسمی و ساخت‌یافته تعریف نکرده است و فقط بر روند مناسب برای زمان اجرای پروژه تمرکز دارد. دلیل این مسئله این است که اسکرام برآن نیست که همه جنبه‌های مدیریت پروژه را پوشش دهد.
در آغاز پروژه، مالک محصول با ذی‌نفعان گفتگو می‌کند و فهرستی ساده و نخستین از قابلیت‌های مدنظرشان فراهم می‌کند. فهرست محصول (product backlog) به هیچ وجه کامل نیست و در طول اجرای پروژه دستخوش دگرگونی‌های فراوانی خواهد شد.
مالک محصول هم مسئول تدوین آیتم‌های فهرست است و هم مرتب کردن آن‌ها بر پایه ارزششان. آیتم‌های باارزش‌تر و مهم‌تر در بالای فهرست قرار می‌گیرند.
اسکرام نیز مانند پرینس۲ و P3.express چرخه‌ایست و چرخه‌هایش Sprint نام دارند. این چرخه‌ها مدت‌زمان ثابتی دارند و همیشه در زمان معین پایان می‌پذیرند، حتی اگر کار چرخه کامل نشده باشد. تعیین مدت‌زمان چرخه‌ها بر دوش تیم است، ولی این مدت نباید بیشتر از یک ماه باشد. برای مدت‌زمان چرخه‌ها هر بار تصمیم‌گیری نمی‌کنیم، بلکه همه چرخه‌ها را با مدت یکسان اجرا می‌کنیم، مگر این‌که پس از مدتی متوجه شویم که مدت تعیین شده برای نوع پروژه مناسب نیست و بهتر است آن را برای چرخه‌های بعد اصلاح کنیم.
هر چرخه با جلسه‌ای حداکثر ۸ ساعته برای برنامه‌ریزی چرخه آغاز می‌شود. اعضای تیم گرد هم می‌آیند و درباره آیتم‌هایی که در بالای فهرست قرار دارند …
کار در DSDM با فاز پیشاپروژه آغاز می‌شود. در این فاز توجیه‌پذیری پروژه را به‌کوتاهی بررسی و نتیجه را همراه با اطلاعات تکمیلی در سندی با نام terms of reference ذخیره می‌کنیم. تصمیم‌گیرندگان با کمک این اطلاعات فرمان توقف کار یا اجرای فاز بعدی را می‌دهند.
فاز بعدی، توجیه‌پذیری است. در این فاز زمان بیشتری صرف شناسایی پروژه و جنبه‌های کسب و کار، فنی، و مدیریتی آن می‌کنیم. اطلاعات گردآوری شده در سند ارزیابی توجیه‌پذیری ذخیره می‌شوند و برای تصمیم‌گیرندگان فرستاده می‌شوند تا فرمان توقف پروژه یا اجرای فاز بعد را بدهند.
فاز سوم شالوده است. در این فاز برنامه کلان پروژه را آماده می‌کنیم که شالوده پروژه به شمار خواهد رفت. بر پایه برنامه کلان می‌توان درک بهتری از توجیه‌پذیری آن نیز پیدا کرد و همه این اطلاعات در قالب سندی با نام چکیده شالوده در اختیار تصمیم‌گیرندگان قرار می‌گیرد.
اگر پروژه توجیه‌پذیر باشد، آن را در فازی تکرار شونده با نام توسعه تکاملی اجرا خواهیم کرد. در هر چرخه این فاز نسخه تازه‌ای از محصول پروژه آماده می‌شود و مانند همه پروژه‌های چابک برای گردآوری بازخورد و روشن کردن مسیر پیش رو به کار می‌رود.
فاز دیگر، انتشار است. این فاز را می‌توان پس از هر چرخه توسعه تکاملی یا با بسامدی کمتر تکرار کرد. در هر تکرار، تازه‌ترین نسخه نرم‌افزار در اختیار کاربران نهایی قرار می‌گیرد.
اختصاصی‌سازی سیستم بحثی کمابیش طولانیست و در فصل چهارم با تفصیل بیشتری به آن خواهیم پرداخت. اکنون بر موضوع دیگری تمرکز می‌کنیم: فرآیند و روش اختصاصی‌سازی.
در پم‌باک ۷ روشی دومرحله‌ای برای اختصاصی‌سازی پیشنهاد کرده‌ایم:
پروژه‌هایی که در یک سازمان اجرا می‌شوند همانندی‌های فراوانی دارند. از این رو، به‌جای این‌که هربار متدولوژی مدیریت پروژه را درون پروژه اختصاصی کنید، بهتر است که یک‌بار آن را کلان و نیمه‌کاره در سطح سازمان و برای جنبه‌های مشترک پروژه‌ها اختصاصی‌سازی کنید. اگر نیاز باشد می‌توانید بیشتر از یک حالت نیمه اختصاصی‌سازی شده در سطح سازمان داشته باشید تا انواع مختلفی از پروژه را پشتیبانی کنند.
هرچه هم که پروژه‌های سازمان همانند باشند، باز هم دقیقا یکسان نیستند و باید حدی از اختصاصی‌سازی درون پروژه انجام شود. از این رو، اختصاصی‌سازی سازمانی نیمه‌کاره است و قسمت دوم آن جداگانه در هر پروژه انجام می‌شود.
برای نخستین مرحله اختصاصی‌سازی نیاز به مرکزی در سازمان دارید. این مرکز را می‌توان مرکز تعالی (center of excellence) نامید. بسیاری علاقه وافر به عبارت PMO دارند (مخفف project management office یا عبارت‌های دیگر). اگر سازمان PMO داشته باشد، مدیریت نخستین مرحله اختصاصی‌سازی می‌تواند از وظایف اصلی آن به شمار برود.
پم‌باک و سایر استانداردهای PMI با روندی مطابق با آنچه برای تدوین استانداردها در موسسه استاندارد آمریکا (ANSI) تعریف شده مدیریت می‌شوند. در ویرایش‌های نخستین تلاش بر این بود که این روند تا جای ممکن با آنچه موسسه بین‌المللی استانداردسازی (ISO) انتظار دارد نیز همخوان باشد، ولی متاسفانه این توجه در سال‌های اخیر کمتر شده است.
متاسفانه PMI در عمل موسسه‌ای بین‌المللی نیست، بلکه موسسه‌ایست آمریکایی که بیشتر نقاط جهان فعال و شناخته‌شده است. این مسئله از سوی بسیاری کمبودی زیربنایی به شمار می‌رود.
تیم تالیف پم‌باک دوازده عضو داشت و من هم یکی از این افراد بودم. اعضای تیم از نقاط مختلف جهان و با پس‌زمینه‌ها و مهارت‌های گوناگون انتخاب شده بودند و تدوین استاندارد را بردوش داشتند. تیمی هم برای رهبری پروژه وجود داشت که مسئول هماهنگی‌ها، نظارت بر مطابقت کارها با الزامات موسسه و همانند آن بود.
گروهی حدودا هفتاد نفره مسئولیت مرور خروجی‌های تیم تالیف را در زمان کار داشت. در پایان، پیش‌نویسی از محتوا در اختیار عموم قرار گرفت و حدود ششصد نفر دیدگاه‌هایشان را در اختیارمان قرار دادند. دیدگاه‌ها گونه‌ای میان اعضای تیم تالیف بخش شد که هر دیدگاه را دو نفر مستقل از هم بررسی کنند و درباره آن تصمیم بگیرند. اگر تصمیم آن دو عضو یکسان نمی‌بود، نفر سومی هم دیدگاه را بررسی می‌کرد و بر پایه رای اکثریت در میان این سه …
باوجود استدلال‌های بخش پیش، چه‌بسا هنوز هم احساس بهتری درباره بازی نخست داشته باشید که طبیعیست و ترس از دست دادن (loss aversion) نام دارد. بار احساسی از دست دادن بیشتر از به دست آوردن است. این نسبت در فرهنگ‌ها و افراد مختلف یکسان نیست، ولی این مقدار برای بسیاری افراد حدود دو و نیم است. در نمونه پیشین، امید ریاضی گزینه دوم دو برابر گزینه نخست بود که کمتر از آستانه دو و نیم برابر است و از این رو، بسیاری از افراد گزینه نخست را ترجیح می‌دهند.
ترس از دست دادن گرایشی طبیعیست که در همه ما وجود دارد. این گرایش به شکل تکاملی در اجدادمان که در جنگل و غار زندگی می‌کردند و جانشان دایما درخطر بود شکل گرفته است و در دنیای امروزی کاربرد کمتری دارد. این گرایش یکی از فریب‌های ذهنی (cognitive bias) است. موارد زیر نمونه‌های دیگری از فریب‌های ذهنی‌اند:
گاهی هنگامی که ایده‌ای داریم و درستی آن را ارزیابی می‌کنیم، ناخودآگاه تنها شواهد تایید کننده را می‌بینیم (confirmation bias).
گاهی کارهایی که آغاز کرده‌ایم توجیه‌پذیری خود را از دست می‌دهند، ولی به دلیل هزینه یا کوششی که پیشتر برایشان کرده‌ایم ادامه‌شان می‌دهیم تا به پایان برسند، با این‌که این کار فقط باعث اتلاف هزینه و توان بیشتر می‌شود (sunk cost effect).
گاهی افراد و شرایط را فقط بر پایه کلیشه‌هایی که درباره‌شان وجود دارد قضاوت می‌کنیم …
محصول این دو لایه را می‌توان به ترتیب برنامه و متابرنامه نامید. برای نمونه، برنامه ریسک فهرستی از ریسک‌های شناسایی شده و واکنش‌هاییست که برایشان طراحی کرده‌اید. این برنامه می‌تواند در صفحه‌گسترده‌ای در اکسل و نرم‌افزارهای همانند آن باشد و فهرست ریسک (risk register) نامیده شود. از سوی دیگر، متابرنامه ریسک سندیست که شیوه مدیریت ریسک را توضیح می‌دهد: تکنیک‌هایی که استفاده می‌کنید، جریان کار، اسناد، و …
هر متدولوژی شیوه مدیریت هرکدام از حوزه‌ها را توضیح می‌دهد و اینگونه بخشی از متابرنامه‌ها در متدولوژی وجود دارد، ولی همه جنبه‌ها را نمی‌توان در متدولوژی لحاظ کرد و از این رو گاهی پیشنهاد می‌شود که برای هر حوزه متابرنامه‌ای نیز بسازید.
معمولا متدولوژی‌هایی مانند پرینس۲، که نیاز به اختصاصی‌سازی نخستین دارند، ساخت متابرنامه‌ها را نیز پیشنهاد می‌کنند، ولی آن‌هایی که مانند P3.express نیاز به اختصاصی‌سازی نخستین ندارند چنین پیشنهادی نیز نمی‌کنند. با این‌همه، حتی در مورد دوم هم اگر حوزه‌ای وجود دارد که حساسیت‌های ویژه‌ای در پروژه دارد، بهتر است برایش در آغاز متابرنامه آماده کنید. برای نمونه، اگر تدارکات پروژه چالش‌برانگیز است، شیوه برنامه‌ریزی، ارزیابی و کنترل آن را تعیین کرده، در سندی با …
اگر سیستم مدیریت پروژه خود را شکل دهید و سپس به این بیندیشید که چگونه می‌توان عناصری برای مدیریت کیفیت به آن افزود، احتمالا چندان موفق نخواهید بود. مدیریت کیفیت باید عنصری یکپارچه در سیستم بوده، از آغاز در شکل‌دهی آن لحاظ شده باشد.