نخستین گام مدیریت ریسک، شناسایی ریسک‌هاست. باید در آغاز پروژه کارگاه‌هایی برگزار کرد و با کمک اعضای تیم پروژه به عدم‌قطعیت‌ها اندیشید. با این همه، هرچه هم که در آغاز کار زمان صرف شناسایی ریسک‌ها کنیم، باز هم مواردی شناسایی نشده باقی می‌مانند و فقط هنگامی که به آن‌ها نزدیک‌تر شویم از آن‌ها آگاه می‌شویم. گاهی هم ریسک‌های تازه‌ای به دلیل تغییر شرایط محیطی به وجود می‌آیند. از این رو، لازم است که روند شناسایی ریسک‌ها دایما تکرار شود.
یک راه خوب این است که بخش کوچکی برای شناسایی ریسک‌های تازه به انتهای بیشتر جلسه‌ها و کارگاه‌ها بیفزایید.
در P3.express مجموعه فعالیت‌هایی برای آغازش پروژه و پایان پروژه وجود دارد. در میان این دو، چرخه‌هایی ماهانه برای انجام کار پروژه وجود دارد، با گروه فعالیت‌هایی برای آغازش ماهانه و پایان ماهانه. درون چرخه‌های ماهانه نیز فعالیت‌هایی برای مدیریت هفتگی و مدیریت روزانه وجود دارد. پس از پایان پروژه شماری فعالیت مدیریت پساپروژه برای ارزیابی منافع پروژه و طراحی اقدام‌های تازه وجود دارد.
برای آغازش پروژه باید اعضای کلیدی تیم منصوب و به کمک آن‌ها برنامه‌ای کلان آماده شود. برنامه برای حامی پروژه فرستاده می‌شود تا درباره اجرا کردن یا نکردن پروژه تصمیم بگیرد.
ترجیح بر این است که برنامه نخستین کلان باشد و سپس در هر آغازش ماهانه بازبینی شده، برای ماه پیش رو تفصیلی شود. اطلاعات بازبینی و تفصیلی شده در پایان آغازش ماهانه برای حامی پروژه فرستاده می‌شوند تا درباره ادامه دادن یا متوقف کردن پروژه تصمیم بگیرد.
در طول ماه بر روی محصول پروژه کار می‌کنیم و هر هفته پیشرفت آن را ارزیابی کرده، به انحراف‌ها واکنش نشان می‌دهیم. فعالیت‌هایی روزانه نیز برای تایید تحویل‌شدنی‌های کامل شده و پیگیری اقلام قابل‌پیگیری (ریسک‌ها، مسایل، درخواست‌های تغییر، برنامه‌های بهبود، و درس آموخته‌ها) وجود دارد.
در زمان پایان ماهانه، رضایت ذی‌نفعان را ارزیابی کرده، بر آن پایه برنامه‌هایی برای بهبود پروژه در ماه بعد طراحی می‌کنیم. …
وقتی ایده پروژه‌ای شکل می‌گیرد و به نظر جالب می‌رسد و پیش از آن‌که تصمیم نهایی درباره آن گرفته شود، فرآیند راه‌اندازی پروژه اجرا می‌شود. در این فرآیند برخی اعضای کلیدی تیم منصوب می‌شوند و همراه هم اطلاعاتی کلان گردآوری می‌کنند که در پایان در سندی با نام خلاصه پروژه (project brief) ذخیره خواهند شد. این سند اطلاعاتی تقریبی درباره توجیه‌پذیری پروژه و شیوه اجرای مناسب آن دارد.
مدیر ارشد و سایر افراد تصمیم‌گیرنده بر پایه اطلاعات گردآوری شده تصمیم می‌گیرند که پروژه ارزش بررسی دقیق‌تر دارد یا خیر. اگر داشته باشد، فرآیند آغازش پروژه اجرا می‌شود.
در آغازش پروژه برنامه کلان آماده می‌شود و بر آن پایه می‌توان توجیه‌پذیری پروژه را با اطمینان بیشتر برآورد کرد. این اطلاعات در سندی با نام سند آغازش پروژه (project initiation documentation) ذخیره می‌شود. این سند نیز در اختیار مدیر ارشد و سایر تصمیم‌گیرندگان گذاشته می‌شود که تصمیم نهایی را برای آغاز کردن یا نکردن کار اجرایی پروژه بگیرند.
همان‌گونه که می‌بینید، پروژه در دو مرحله ارزیابی می‌شود. در مرحله نخست به‌سرعت و با صرف توان محدود آن را بررسی می‌کنیم تا پروژه‌هایی که اصلا توجیه‌پذیر نیستند حذف شوند. در مرحله دوم، با صرف زمان و انرژی بیشتر، پروژه را به دقت بررسی می‌کنیم و بر آن پایه تصمیم نهایی را می‌گیریم.
برخلاف بیشتر سیستم‌ها، اسکرام آغازش و پایانی رسمی و ساخت‌یافته تعریف نکرده است و فقط بر روند مناسب برای زمان اجرای پروژه تمرکز دارد. دلیل این مسئله این است که اسکرام برآن نیست که همه جنبه‌های مدیریت پروژه را پوشش دهد.
در آغاز پروژه، مالک محصول با ذی‌نفعان گفتگو می‌کند و فهرستی ساده و نخستین از قابلیت‌های مدنظرشان فراهم می‌کند. فهرست محصول (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 نیاز به اختصاصی‌سازی نخستین ندارند چنین پیشنهادی نیز نمی‌کنند. با این‌همه، حتی در مورد دوم هم اگر حوزه‌ای وجود دارد که حساسیت‌های ویژه‌ای در پروژه دارد، بهتر است برایش در آغاز متابرنامه آماده کنید. برای نمونه، اگر تدارکات پروژه چالش‌برانگیز است، شیوه برنامه‌ریزی، ارزیابی و کنترل آن را تعیین کرده، در سندی با …
اگر سیستم مدیریت پروژه خود را شکل دهید و سپس به این بیندیشید که چگونه می‌توان عناصری برای مدیریت کیفیت به آن افزود، احتمالا چندان موفق نخواهید بود. مدیریت کیفیت باید عنصری یکپارچه در سیستم بوده، از آغاز در شکل‌دهی آن لحاظ شده باشد.
منابع ساخت‌یافته درباره مدیریت پروژه را به دو دسته می‌توان تقسیم کرد:
متدولوژی‌ها راه مناسب را در پروژه نشان می‌دهند.
راهنماها به شما کمک می‌کنند که متدولوژی خود را کارآتر کنید.
نخستین عنصری که نیاز دارید متدولوژی است. پس از استقرار متدولوژی مناسب، می‌توانید از راهنماها برای افزایش کارآیی سیستم کمک بگیرید.
پم‌باک راهنماست و نه متدولوژی. همواره کسان زیادی کوشش کرده‌اند که آن را به‌شکل یک متدولوژی به کار ببرند و هیچ‌گاه نیز موفق نبوده‌اند. این مسئله چنان حاد بود که توضیحی به مقدمه ویرایش‌های پیشین افزوده شد و متدولوژی نبودن پم‌باک و لزوم بهره‌مندی از یک متدولوژی در کنار آن را توضیح داد. بااین‌همه، رویکرد فرآیند محور پم‌باک همچنان سوتفاهم ایجاد می‌کرد و کماکان کسان زیادی آن را با یک متدولوژی اشتباه می‌گرفتند. یکی از اهداف تدوین نسخه هفتم این بود که به‌گونه‌ای زیربنایی جلوی این اشتباه گرفته شود و گمان می‌کنم در این کار موفق بوده‌ایم! ساختار اصل محور نسخه هفتم را دیگر نمی‌توان با متدولوژی اشتباه گرفت.
پم‌باک به دو شکل می‌تواند به شما کمک کند:
اصل‌ها کمک می‌کنند که تعبیر و تفسیر بهتری از متدولوژی‌های مدیریت پروژه داشته باشید.
حوزه‌های عملکردی کمک می‌کنند که متدولوژی خود را کارآتر کنید.
از این رو، در ادامه کتاب این سه فصل اصلی وجود دارد:
دو راه کلی برای ساخت محصول پروژه وجود دارد، متعین (predictive) و تطبیقی (adaptive):
در روش متعین، در آغاز پروژه به همه جنبه‌ها می‌اندیشیم، محصول را به‌دقت طراحی می‌کنیم و سپس آن را می‌سازیم. پروژه‌ای برای ساخت و فرستادن یک مریخ‌نورد را در نظر بگیرید. مریخ‌نورد باید در محیطی کاملا متفاوت با محیط عادی ما کار کند، با گرانش، نوع اتمسفر و بسیاری از شاخص‌هایی که مانند زمین نیستند. چنین پروژه‌ای بسیار پرهزینه هم هست و نمی‌توان با آزمایش و خطای فراوان به نتیجه رسید، بلکه باید با بهره‌مندی بهینه از دانش موجود پیش‌بینی همه مسایل را در آغاز کرد و سپس محصول را ساخت. به‌عنوان نمونه‌ای ساده‌تر، ساخت یک پل را در نظر بگیرید: چنین محصولی هم باید به شکل متعین ساخته شود.
در برخی پروژه‌ها که به شدت وابسته به برداشت و سلیقه مشتری هستند نمی‌توان محصول مناسب را پیش‌بینی کرد، چون رفتار انسان‌ها پیش‌بینی‌ناپذیرند. از این رو، به‌جای شیوه متعین از شیوه تطبیقی استفاده می‌کنیم. در این شیوه به‌جای این‌که همه‌چیز را در آغاز طراحی کنیم و سپس بسازیم، ترتیبی فراهم می‌کنیم که بتوان بخشی کوچک و در عین حال معنادار از محصول را ساخت و به کاربران نهایی یا گزیده‌هایی از آن‌ها ارائه کرد و از رفتار و برخوردشان بازخورد گرفت. با کمک آن بازخورد حدس می‌زنیم که بهترین گام بعدی برای محصول چیست و با آن دانش نسخه بعدی را می‌سازیم. …
یکی از معیارهای مهم در ارزیابی وضعیت پروژه، توجیه‌پذیری آن است. دایما باید این مسئله را کنترل کنید و هرگاه پروژه توجیه‌پذیری خود را از دست داد مسئله را به حامی پروژه اطلاع دهید.
متدولوژیتان احتمالا کنترل‌هایی دوره‌ای برای توجیه‌پذیری پروژه دارد. اگر اینگونه نیست، لازم است آن را بیفزایید.
درباره متغیرهای پروژه چه باید کرد؟
متغیرهای پروژه جنبه‌هایی مانند گستره، زمان، هزینه، و کیفیت هستند. برخی منابع متغیرهای دیگری مانند مجموع ریسک و منافع را نیز اضافه می‌کنند. همه این متغیرها را باید دایما ارزیابی کرد و توجیه‌پذیری پروژه معمولا ترکیبی از همه آن‌هاست.
هریک از متغیرهای پروژه‌تان تا چه اندازه حساسند؟ برای نمونه، اگر قرار است مجموعه‌ای بسازید که برای همایشی ملی به کار برود، هیچ‌گونه تاخیری پذیرفتنی نخواهد بود و نیاز به کنترل‌های دقیق‌تری برای زمان خواهید داشت. در چنین مواردی، کنترل‌های لازم را در متدولوژی خود تقویت کنید.
هر متدولوژی زمان مناسب و روند برنامه‌ریزی را توضیح می‌دهد، ولی گاهی محتوای برنامه‌هایشان چندان روشن نیست.
نسخه‌های پیشین پم‌باک مجموعه‌ای از حوزه‌های دانش داشتند که از برخی جهات مانند حوزه‌های عملکردی نسخه هفتم (موضوع این فصل) بودند، ولی یکسان نیستند. به نظر من حوزه‌های دانش دسته‌بندی بسیار خوبی برای شرح آنچه قرار است برنامه‌ریزی شود هستند:
یکپارچگی
گستره
زمان
هزینه
کیفیت
منابع
ارتباطات
ریسک
تدارکات
ذی‌نفعان
این دسته‌بندی یکی از انواع دسته‌بندی است که می‌توانید در نظر داشته باشید. همه این موارد باید به‌نوعی در برنامه‌هایتان وجود داشته باشند. متدولوژیتان احتمالا همگی را پوشش دهد، ولی شاید برخی از این جنبه‌های پروژه‌تان حساس‌تر باشند و بنابراین نیاز باشد که آن‌ها را بسته به پیش‌فرضی که در متدلوژی وجود دارد قوی‌تر کنید.
فراموش نکنید که برنامه زمان‌بندی فقط یکی از این ۱۲ مورد است.
پشتیبانی از رهبران نامرئی که در بخش پیش مطرح شد مبحث مهمی در حوزه رهبریست، ولی از آن گذشته، باید بر رشد توانایی‌های رهبری خودتان نیز تمرکز کنید.
برای نمونه، به‌عنوان یک رهبر، باید بتوانید در افراد انگیزه ایجاد کنید. فرض کنید یکی از اعضای تیم کار درخشانی در پروژه انجام داده است و می‌خواهید از او قدردانی کنید. چگونه این کار را خواهید کرد؟ با پرداخت پاداش مالی؟
پاسخ بستگی به مسایل فراوانی دارد. پاداش مالی هنگامی کارآمد است که مقدارش نسبت به نیاز مالی فرد مناسب باشد، وگرنه اثر معکوس خواهد داشت، زیرا کم بودن پاداش به معنی دست‌کم گرفتن کار فرد به شمار خواهد رفت. فرض کنید بودجه بسیار محدودی دارید و فقط می‌توانید معادل چهار پیتزا برای قدردانی از آن فرد هزینه کنید. پرداخت چنین پاداشی شایسته نیست، ولی با همان بودجه می‌توانید خودکاری برازنده سفارش دهید که نام آن فرد رویش حک شده باشد، آن را هدیه دهید و با چند جمله زیبا قدردانی خود را نشان دهید.
سوتفاهم‌های فراوانی درباره مفهوم رهبری وجود دارد. برای نمونه، داشتن کاریزما برای رهبران سودمند است، ولی کاریزما محدود به داشتن شخصیتی سرسخت، پرابهت و گاهی بداخلاق نیست. شکل‌های مختلفی از کاریزما وجود دارد و برخی از آن‌ها وابسته به دانش، مهربانی، دلسوزی و هماهنند آن‌ها هستند. بهتر است به جای الگوبرداری از شخصیت‌های کاریزماتیک فیلم‌ها، نوع کاریزمای مناسب …
چابکی رویکردی در ساخت محصول است. برخی از متدولوژی‌ها فقط برای ساخت چابک طراحی شده‌اند، برخی هم برای ساخت چابک و هم متعین، و برخی نیز بیشتر مناسب ساخت محصول متعین هستند.
بیشتر روش‌های چابک نسل نخست، مانند DSDM و XP، نقشی به‌عنوان مدیر پروژه دارند یا دست‌کم مخالفتی با چنین نقشی ندارند. با این‌همه، اسکرام چنین نقشی ندارد و افزودنش به اسکرام نیز سازگاری درونی آن را نابود می‌کند. این مسئله اهمیت فراوانی دارد، زیرا برخی گمان می‌کنند که با افزودن مدیر پروژه به اسکرام آن را تقویت کرده‌اند، با این‌که آن را ضعیف‌تر کرده‌اند.
از سوی دیگر، به دلیل گستردگی فراوان اسکرام و این واقعیت که بسیاری از روش‌های چابک نسل دوم از اسکرام الگوبرداری کردند، برخی می‌پندارند که وجود مدیر پروژه با ذات چابکی ناسازگار است، که کاملا اشتباهست. بسیاری از روش‌های چابک نیاز به مدیر پروژه دارند.