در این بخش می‌تونین نسخه کاملی از تمام مطالب سایت رو دانلود کنین. البته در نظر داشته باشین که مطالب سایت سالی یک بار بررسی می‌شن و مواردی که صرفا ارزش مقطعی داشته باشن (مثلا آگهی‌های استخدام) حذف می‌شن. بعد از هر بار رسیدگی حدودا ۲۵٪ مطالب سایت باقی می‌مونن و در این بخش همون موارد قابل دانلود هستن.
هر وقت مطلب جدیدی به سایت اضافه می‌شه، فایل قابل دانلود این صفحه هم به طور خودکار به‌روزرسانی می‌شه؛ در نتیجه، همیشه می‌تونین با مراجعه به این صفحه کامل‌ترین نسخه قابل دانلود سایت رو دریافت کنین.
اگر انتظارمان از مدیر پروژه پشتیبانی و تسهیل‌گری غیرفنی باشد، قاعدتا بسیاری از این افراد اطلاعات فنی کافی برای برنامه‌ریزی و کنترل پروژه یا تصمیم‌گیری‌های کلان فنی نخواهند داشت. از این رو، به‌جای این‌که شخصا چنین کارهایی را انجام دهند، باید از اعضای تیم پروژه کمک بگیرند. باید با مهارتی که در برنامه‌ریزی، تسهیل‌گری و سایر موارد مدیریتی دارند به این افراد کمک کنند تا خودشان پروژه را به شکل مناسب بسازند. منظور از مدیریت پروژه واقعی این است.
آیا به نظرتان مدیر پروژه باید اطلاعات فنی داشته باشد؟
سه پاسخ برای این پرسش ممکن است:
بله، مدیر پروژه باید اطلاعات فنی داشته باشد.
الزامی نیست که مدیر پروژه اطلاعات فنی داشته باشد، ولی اگر داشته باشد شاید بهتر باشد.
خیر، بهتر است که مدیر پروژه اطلاعات فنی نداشته باشد.
نخستین پاسخ رویکردی سنتیست که چه‌بسا در بسیاری از سازمان‌ها دیده باشید. این رویکرد محدود به ایران هم نیست و در همه کشورها وجود دارد.
رویکرد دوم کمابیش نوین و بااین‌همه کمی محافظه‌کارانه است. این رویکرد با آنچه تاکنون گفته شد هماهنگ است و می‌توان گفت که PMI هم چنین دیدگاهی دارد.
سومین پاسخ رویکردی کاملا پیشروست که درکش برای بسیاری از افراد چالش‌برانگیز است. گروهی، ازجمله من، از آن طرفداری می‌کنند.
فرض کنید مدیر پروژه‌ای هستید که در جنبه‌های فنی‌اش نیز تخصص دارید. اگر ببینید که کاری …
بسته به شرایط، شاید کارهای دیگری هم برای بهبود وضعیت تیم نیاز باشد. برای نمونه، وقتی تیم زیاد از حد کوچک نباشد بهتر است که انتظارهایی که از هرکس می‌رود و انتظارهایی که آن فرد از دیگران می‌تواند داشته باشد مشخص و شفاف باشد. به عبارت دیگر، باید نقشها و مسئولیت‌ها را به‌خوبی تعریف کنید. این نکته یکی از اصل‌های متدولوژی مدیریت پروژه پرینس۲ (PRINCE2) نیز هست.
افزون بر نقش و مسئولیت‌ها، شاید نیاز باشد که فرآیندهای کارهای رایج پروژه را نیز تدوین کنید. برای نمونه: «هر سندی که طراحی می‌شود باید برای بررسی نخستین به …… فرستاده شود، این بررسی باید در …… روز کامل شده و پس از آن…»
نکته دیگری که شاید نیاز باشد تدوین قواعد رفتاری (ground rules) است . برای نمونه، «با صدای بلند پشت تلفن صحبت نکنید.»
شاید به این بیندیشید که تدوین و ابلاغ چنین قواعدی تحکمی و برخلاف آنچه در اصل پیش بررسی کردیم است. وضعیت اینگونه خواهد بود اگر این موارد را به تنهایی یا همراه با عده‌ای انگشت‌شمار آماده کرده، به همگی حکم کنید. راه مناسب این است که با تسهیل‌گری مناسب از خود اعضای تیم درخواست کنید که چنین مواردی را برای خودشان تدوین کنند. اینگونه، هم قواعد واقع‌بینانه‌تر و کاراتر خواهند بود و هم امکان موفقیت بیشتری خواهند داشت چون به افراد تحمیل نشده‌اند. برای نمونه، آیین‌نامه اخلاق …
چگونه و تا چه اندازه می‌تواند بر پروژه اثر بگذارد؟
جبه‌گیری‌اش در برابر پروژه مثبت است یا منفی؟
چه انتظاری از پروژه دارد؟ چه مسایلی برایش خوش‌آیند و چه مسایلی آزاردهنده است؟
و …
وقتی در جستجوی پاسخ به چنین پرسش‌هایی هستید، به‌تدریج برنامه‌ای هم برای مشارکت‌دادن و جلب حمایت آن‌ها تدوین کنید. وقتی چنین کاری می‌کنید مراقب توجیه‌پذیری برنامه نیز باشید: آیا منافعی که از مشارکت و حمایت ذی‌نفع دریافت می‌کنید بیش از توانی که صرف می‌کنید هست؟ آیا بازگشت سرمایه در این فرآیند بیشتر از هزینه فرصت (opportunity cost) شما هست یا خیر؟ به عبارت دیگر، آیا کار دیگری با بازگشت بالاتر هست که بتوان به‌جای آن انجام داد؟
استثنایی که در تحلیل توجیه‌پذیری مشارکت ذی‌نفعان وجود دارد، مسایل اخلاقیست. فرض کنید قرار است ساختمان کوچکی در همسایگی پیرزنی بسازید. پیرزن نمی‌داند که چنانچه سر و صدا و مزاحمت کار بیش از اندازه یا بی‌موقع باشد می‌تواند از شما شکایت کند و شاید توان و حوصله این کار را نداشته باشد. آیا این مسئله به این معنیست که نیازی به محدود کردن آلودگی صوتی کارگاه ندارید؟ نه؛ باید جنبه اخلاقی مسئله را هم در نظر بگیرید.
اطلاعاتی که درباره تحلیل و برنامه‌ریزی ذی‌نفعان گردآوری کرده‌اید را برای ارجاع‌های بعدی مستند کنید. برخی متدولوژی‌ها سندی برای این کار …
از آنجایی که ارزش عینی نیست و برای هرکس متفاوت است، برای ارزیابی ارزش پروژه باید دیدی همه‌جانبه داشت و آن را در بستر کلی سازمان سنجید و نه تنها درون پروژه.
ارزش هر پروژه‌ای، گذشته از مشخصات خود پروژه، بستگی به دیگر پروژه‌ها و عملیات سازمان نیز دارد، هم موارد کنونی و هم مواردی که شاید در آینده به وجود آیند. گاهی سیاست‌های کشور و مسایل جهانی هم بر ارزش پروژه اثر می‌گذارند. شاید برای پروژه‌تان در آغاز ارزشی پیش‌بینی کنید، ولی کمی بعد با افزوده شدن پروژه‌ای تازه برهمکنشی رخ دهد که ارزش پروژه پیشین نیز بیشتر شود.
سال‌های آغازینی که ترجمه و تالیف می‌کردم با دو ناشر بسیار خوب کار می‌کردم. از روند کار خرسند بودم، ولی محدودیت‌های طبیعی نشر سنتی، از جمله این‌که دسترسی به کتاب‌ها در برخی شهرها دشوار بود، باعث شد که کم‌کم به فکر نشر الکترونیکی کتاب‌هایم بیفتم. این گزینه به نظر خیلی‌ها ترسناک بود، ولی در عمل نتیجه بسیار خوبی داشت و منافع برآمده از نشر الکترونیکی برایم حدود ۲۰ برابر بیشتر از نشر سنتی شد. سال‌ها ماجرا اینگونه پیش رفت تا این‌که ارزش فرصت و معیارهای ارزشم به‌گونه‌ای تغییر کرد که درآمدزایی از نشر کتاب دیگر گزینه توجیه‌پذیری برایم نیست و از این رو اکنون کتاب‌ها را آزاد و رایگان منتشر می‌کنم.
از همه این مسایل که بگذریم، هدفم ارائه نمونه‌ای جالب از برهمکنش‌ها بود: به ازای هر کتاب …
زمانی با سازمانی همکاری می‌کردم که در کنار پروژه‌های خودش از برخی پروژه‌های غیرانتفاعی هم پشتیبانی مالی می‌کرد. یکی از این پروژه‌ها ساخت پناهگاهی کوهستانی بود. هر از چندی نماینده‌ای از آن پروژه به دفتر ما می‌آمد، گزارشی از کارهای انجام شده و پیش رو و برآوردی از بودجه لازم برای دوره بعد ارائه می‌کرد. زمانی متوجه شدم که مدت زیادی می‌گذرد و خبری از نمایندگان آن پروژه نیست. هنگامی که با آن‌ها تماس گرفتیم، باخبر شدیم که سازمان میراث فرهنگی پروژه را متوقف کرده است، زیرا پناهگاه بر روی جاده‌ای باستانی قرار گرفته بود. متاسفانه هزینه فراوانی که صرف ساخت بخشی از پناهگاه شده بود از دست رفته (هزینه ساخت در کوهستان بسیار زیاد است) و جاده‌ای باستانی هم آسیب دیده بود.
جاده باستانی را به‌سختی می‌شد تشخیص داد و تفاوت چندانی با پاکوبه‌هایی که به‌تدریج با رفت و آمد کوهنوردان به وجود می‌آمد نداشت. با این‌همه، همان اثر جزئی از جاده هم بازتاب تاریخی طولانی بود و میراثی فرهنگی که نیاز به حفاظت داشت.
چگونه می‌شد از بروز چنین چالشی در پروژه جلوگیری کرد؟
پیش از اجرای چنین پروژه‌ای، می‌توان مدتی به محل رفت و با کوهنوردان خبره‌ای که در آنجا رفت و آمد می‌کنند گفتگو کرد و دیدگاهشان را جویا شد. بی‌گمان برخی از کوهنوردان از جاده اطلاع داشتند و می‌توانستند در آن باره اطلاع‌رسانی کنند. افزون بر آن، شاید بتوان …
آزمون PMP درباره اطلاعات عمومی مدیریت پروژه بود. پس از مدتی، PMI برآن شد که این اطلاعات را سازمان‌دهی و در قالب راهنمایی منتشر کند. نخستین پیش‌نویس آن در ۱۹۸۷ و ویرایش نهایی‌اش پس از اصلاح‌های زیربنایی در ۱۹۹۶ منتشر شد. پس از آن هر چهار تا پنج سال یک‌بار ویرایش تازه‌ای جانشین پیشین شد:
۱۹۹۶ – نخستین ویرایش رسمی
۲۰۰۰ – ویرایش ۲۰۰۰
۲۰۰۴ – ویرایش ۳
۲۰۰۸ – ویرایش ۴
۲۰۱۳ – ویرایش ۵
۲۰۱۷ – ویرایش ۶
۲۰۲۱ – ویرایش ۷
ویرایش نخست پم‌باک مدیریت پروژه را با ۳۷ فرآیند توضیح می‌داد. هر فرآیند شماری ورودی، ابزار و روش، و خروجی داشت. فرآیندها به دو شکل دسته‌بندی شده بودند:
گروه‌های فرآیندی: دسته‌بندی بر پایه جایگاه فرآیند در چرخه حیات پروژه
آغازش
برنامه‌ریزی
اجرا
کنترل
پایان
حوزه‌های دانش: دسته‌بندی بر پایه موضوع فرآیند
یکپارچگی
گستره
زمان
هزینه
کیفیت
منابع انسانی
ارتباطات
ریسک
تدارکات
پنج ویرایشی که پس از آن منتشر شدند همگی ساختار نخستین را بهبود می‌دادند. شمار فرآیندها به‌تدریج از ۳۷ به ۴۹ رسید. حوزه دانش ارتباطات به ارتباطات و ذی‌نفعان تقسیم شد و برخی عنوان‌ها نیز اصلاح شدند. سرانجام، کتاب از ۱۷۶ صفحه در ویرایش نخست به ۷۵۶ صفحه در ویرایش ششم رسید.
برخلاف ویرایش‌های پیشین، محتوای ویرایش هفتم بهبودیافته و دقیق‌شده محتوای پیشین نبود، بلکه کار را …
بسیاری رهبری را از ویژگی‌های مدیران می‌دانند، ولی در ادبیات مدرن به هرکسی که افراد را به سمت نتایج مطلوب هدایت کند رهبر گفته می‌شود.
این تعریف نوین از این رو اهمیت دارد که در هر گروهی عده‌ای علاقه‌مند به رهبری وجود دارد که گذشته از سمت و مسئولیت خود به همگی کمک می‌کنند زیرا این رفتار برایشان خوشایند است. متاسفانه این افراد در بسیاری از سازمان‌ها نادیده گرفته می‌شوند، با این‌که اگر از آن‌ها پشتیبانی کنیم و قدرت بیشتری در اختیارشان بگذاریم می‌توانند بیش از پیش به سازمان یا پروژه کمک کنند. دست‌کم، اگر از آن‌ها پشتیبانی نمی‌کنید، چنان زیر فشارشان نگذارید که مانند خانمی که در نمونه پیشین گفته شد بگذارند و بروند.
بسیاری از منابع امروزی درباره روش‌های ترکیبی (hybrid) سخن می‌گویند؛ روش‌هایی که از ترکیب روش‌های متعین و چابک به وجود می‌آید. در عمل نمی‌توان چنین ترکیبی داشت، زیرا برای تطبیقی بودن در پروژه باید همه عناصر آن تطبیقی باشند و همین‌که جنبه‌ای از آن را ثابت و متعین کنیم، انعطاف‌پذیری و انطباق‌پذیری همه بخش‌ها از بین می‌روند. اگر بتوان بخشی را متعین کرد بدون این‌که تطبیق‌پذیری بخش‌های دیگر را از بین ببرد، آن دو بخش استقلال مفهومی، عملکردی و تولیدی کامل دارند و درنتیجه با دو محصول سروکار داریم که نیاز به دو پروژه مختلف دارند، و هیچ منعی برای استفاده از دو روش ساخت متفاوت در دو پروژه وجود ندارد، ولی آن را نمی‌توان «روش ترکیبی» دانست. وقتی با یک پروژه و یک محصول سروکار داریم، روش ساخت یا متعین خواهد بود، یا تطبیقی.
کسانی که از روش‌های ترکیبی سخن می‌گویند معمولا توجهشان معطوف ظواهر است و هرگاه ترکیبی از برچسب‌ها، اسناد، و مراسم که از دو روش آمده باشند بینند، آن را روشی ترکیبی می‌نامند. مدیر پروژه خبره می‌داند که توجه به ظواهر بارپرستی است و باید به‌جای آن به عملکردهای واقعی و ذات مسایل توجه داشت.
متاسفانه پم‌باک ۷ نیز پیروی سوتفاهم رایجی که در این باره وجود دارد درباره روش‌های ترکیبی سخن می‌گوید. کوشش من برای قانع کردن تیم و حذف این اشتباه نیز به جایی نرسید.
داستان تاسف‌آوری که تعریف کردم نتیجه یکی از عدم‌قطعیت‌های پروژه بود؛ این‌که در مدتی که دیوار بیرونی طبقه‌ای ساخته نشده باشد، احتمال دارد کسانی که در آن طبقه کار می‌کنند به پایین پرت شوند.
عدم‌قطعیت‌هایی که می‌توانند بر پروژه اثر مثبت یا منفی بگذارند ریسک نامیده می‌شوند. شیوه مدیریت این موارد با آنچه قطعیت دارد (برای نمونه، این‌که می‌دانیم حتما باید دیوار بیرونی آن طبقه را بسازیم) تفاوت دارد و از این رو مبحثی برای مدیریت ریسک وجود دارد.
مدیریت ریسک مانند مدیریت کیفیت و سایر جنبه‌های مدیریتی منافع فراوانی دارد، ولی هرگاه به لزوم مدیریت ریسک شک کردید، آن جوانی که گفته شد را به یاد بیاورید و به این نکته بیندیشید که اگر مدیریت ریسک بهتر انجام شده بود شاید هنوز زنده می‌بود و در کنار همسر و دو فرزندش زندگی می‌کرد.
تحویل یک‌باره در پایان پروژه ریسک‌های فراوانی دارد، زیرا اگر عنصری از پروژه مناسب نباشد و در زمان تحویل کشف شود، اصلاحش می‌تواند بسیار پرهزینه باشد. پروژه‌های تطبیقی که تحویل تدریجی دارند چنین ریسکی ندارند، اما در پروژه‌های متعین باید مراقب آن بود.
با این‌که در بسیاری از پروژه‌های متعین نمی‌توان تحویل در میانه کار داشت، بازهم می‌توان روندی دوره‌ای برای بررسی وضعیت تازه محصول و دریافت تاییدی ضمنی از کارفرما داشت. این مسئله چنان مهم است که بسیاری از متدولوژی‌ها روندی برای این منظور دارند. اگر متدولوژیتان چنین جنبه‌ای را پوشش نداده باشد، بهتر است آن را بیفزایید، به‌ویژه اگر پیش‌بینی می‌کنید که میان کارفرما و پیمانکار اختلاف‌نظر به وجود خواهد آمد.
چه زمانی باید سیستم را اختصاصی‌سازی کرد؟ پاسخ بستگی به متدولوژی‌ای دارد که انتخاب کرده‌اید:
در سیستم‌های ماکسیمالیستی، مانند پرینس۲، عناصر فراوانی وجود دارد که کمابیش هر نوع پروژه‌ای را پوشش می‌دهد. از این رو، لازم است که در آغاز و پیش از به کارگیری سیستم آن را اختصاصی‌سازی کرد.
سیستم‌های مینیمالیستی، مانند P3.express، حداقل عناصری که در پروژه‌های مخاطبشان کلیدی و مشترک باشند را پوشش می‌دهند. از این رو، نیازی نیست که در آغاز سیستم را اختصاصی‌سازی کرد و به‌جای آن باید پس از مرور زمان و بر پایه بازخورد محیطی به تدریج دست‌به‌کار اختصاصی‌سازی شد.
حتی زمانی که سیستم نیاز به اختصاصی‌سازی آغازین داشته باشد، باز هم لازم است که اختصاصی‌سازی تدریجی در هنگام کار داشته باشید. از سوی دیگر، اختصاصی‌سازی آغازین کار پر ریسکی است؛ چالش رایج این است که اختصاصی‌سازی‌های نخستین غیرواقع‌بینانه و زیاد از حد پیچیده و سنگین می‌شوند و کارکرد سیستم را مختل می‌کنند. از این رو، بهتر است که اگر نیاز به اختصاصی‌سازی آغازین دارید، آن را ساده و حداقلی انجام دهید و باقیمانده آن را در هنگام کار پیش ببرید.
دیر یا زود، محصول نهایی پروژه، شامل همه تحویل‌شدنی‌هایش، به کارفرما تحویل می‌شود و در اختیار کاربران نهایی قرار می‌گیرد. با این‌همه، زمان، چگونگی، و بسامد تحویل همیشه یکسان نیست:
پروژه‌های متعین: به دلیل روند کمابیش خطی این نوع پروژه، معمولا محصول نهایی پروژه یک‌باره و در پایان کار تحویل می‌شود. برخی پروژه‌های متعین چند بخش کمابیش جدا از هم دارند و در فازهای مختلف انجام شده، جداگانه و در طول انجام پروژه تحویل می‌شوند.
پروژه‌های تطبیقی: در هنگام اجرای پروژه‌های تطبیقی باید نسخه‌های قابل استفاده محصول نهایی ساخته شده، در اختیار همه یا بخشی از کاربران نهایی قرار گیرد تا بر پایه بازخوردهای دریافتی مسیر پیش روی پروژه تعیین گردد. این نسخه‌ها باید قابل استفاده باشند، وگرنه بازخورد فراهم شده اطمینان‌پذیر نخواهد بود. از آنجایی که نسخه‌ها قابل استفاده هستند، می‌توان آن‌ها را تحویل نیز داد و عملیاتی کرد. اینگونه، تحویل در پروژه‌های تطبیقی می‌تواند تدریجی باشد.
پروژه‌ای که نتواند نسخه‌های قابل استفاده محصول را بسازد نمی‌تواند تطبیقی باشد. فراموش هم نکنید که هر نسخه قابل استفاده مجموعه‌ای از تحویل‌شدنی‌هاست، ولی هر مجموعه‌ای از تحویل‌شدنی‌ها نسخه‌ای قابل استفاده نیست.
حامی پروژه: این فرد یکی از مدیران ارشد سازمان با رویکرد کسب و کار است که تصمیم‌گیری‌های کلان و مسئولیت فراهم کردن منابع را بر دوش دارد.
مدیر پروژه: این فرد مسئول مدیریت مسایل روزمره است.
رهبران تیم‌ها: چنانچه پروژه تیم‌هایی متشکل از افراد درونی سازمان داشته باشد، برای هر تیم رهبری انتخاب می‌شود که در مسایل مدیریتی با مدیر پروژه هماهنگ شود.
مدیران پروژه پیمانکار: اگر پروژه پیمانکارانی داشته باشد، هر پیمانکار جز مانند یک تیم عمل خواهد کرد و فردی که در راس آن تیم باشد مدیر پروژه پیمانکار نامیده می‌شود.
توجه داشته باشید که هرکدام از ارکان پروژه که از P3.express استفاده کنند زاویه دید خود را خواهند داشت و ساختار، اسناد، و فرآیندهایش نیز بر همان پایه خواهد بود. برخلاف آن، در حالت پیش‌فرض پرینس۲، ساختاری یکه برای ترکیب همه ارکان پروژه وجود دارد.
اگر لازم باشد می‌توانید نقش‌های بیشتری به سیستم بیفزایید، ولی مراقب باشید که این کار را به تدریج، بر پایه بازخوردهایی که از محیط دریافت می‌کنید و بدون پیچیده کردن سیستم انجام دهید.
در پرینس۲ سه سطح مدیریتی درون پروژه، پایین‌تر از سطح مدیریتی سازمان وجود دارد. نقش‌های متعددی در این لایه‌ها تعریف شده است، ازجمله:
لایه هدایت
هیئت پروژه
مدیر ارشد: یکی از مدیران ارشد سازمان با گرایش کسب و کار است که مسئولیت تصمیم‌های کلان پروژه و فراهم‌آوری منابع را بر دوش دارد.
کاربران ارشد: این افراد نمایندگانی از کاربران نهایی محصول پروژه هستند یا کسانی که درک کاملی از کاربران نهایی دارند و این اطلاعات را به هیئت پروژه می‌آورند.
تامین‌کنندگان ارشد: این افراد یا نمایندگان کسانی هستند که محصول پروژه را می‌سازند، یا کسانی که درک کاملی از آن‌ها دارند و این اطلاعات را به هیئت پروژه می‌آورند.
لایه مدیریت
مدیر پروژه: این فرد مسئول مدیریت مسایل روزمره پروژه است.
پشتیبانی پروژه: این افراد در مدیریت پروژه به مدیر پروژه کمک می‌کنند.
لایه ساخت
رهبران تیم‌ها: این افراد تیم‌های اجرایی درونی و بیرونی را رهبری می‌کنند و با مدیر پروژه در ارتباط هستند.
می‌توانید با شکستن هرکدام از نقشها، نقش‌های تازه‌ای به وجود آورید یا با ادغام کردن آن‌ها در هم سیستم سیستم را ساده‌تر کنید. برای این کار محدودیت‌هایی نیز وجود دارد؛ برای نمونه، نباید نقش مدیر پروژه و مدیر ارشد در هم ادغام شوند زیرا هم تضاد منافع به وجود می‌آید و هم این‌که برای یک نفر دشوار است که هم به جنبه‌های بسیار کلان توجه کند و …
اسکرام مستر: این فرد شیوه کارکرد تیم را زیر نظر دارد و آن‌ها را هدایت می‌کند که از اسکرام به‌درستی استفاده کنند. افزون بر آن، مسئولیت تسهیل‌گری و رفع چالش‌ها را نیز بر دوش دارد.
مالک محصول: این فرد درک کاملی از کسب و کار دارد و از یک سو با دیگر اعضای تیم در تماس است و از سوی دیگر با ذی‌نفعان بیرونی تیم. با پیگیری‌هایش نیازهای کارفرما را درک کرده، در تیم بازتاب می‌دهد. افزون بر آن، نیازها را بر پایه پتانسیل ارزششان اولویت‌بندی می‌کند تا تیم همیشه بر باارزش‌ترین قابلیت‌ها متمرکز شود.
توسعه‌دهندگان: این افراد کسانی مانند برنامه‌نویسان، طراحان رابط کاربری، و معماران نرم‌افزار هستند که ساخت محصول را بر دوش دارند. البته در کنار کار فنی، مسئولیت‌هایی مدیریتی نیز دارند.
سیستم مدیریتی اسکرام غیرمتمرکز است؛ به این معنی که به‌جای داشتن فرد و گروهی که مسئولیت اصلی هماهنگی‌ها و مدیریت پروژه را بر دوش داشته باشند، این مسئولیت‌ها در میان همه اعضای تیم پخش شده است.
به دلیل ساختاری که اسکرام دارد، افزودن نقش‌های دیگر به سازگاری درونی آن آسیب می‌زند و بنابراین مجاز نیست.