محدودۀ پروژه پادشاه است!
عبارت «محتوا پادشاه است» یا Content is king تکیه‌کلام بازاریاب‌های اینترنتی و متخصصان سئوست. این جمله اولین‌بار در ژانویۀ ۱۹۹۶ در عنوان مقالۀ بیل گیتس در وب‌سایت مایکروسافت منتشر شد. به همین ترتیب، می‌توانیم دربارۀ مدیریت پروژه نیز عبارتی مشابه به‌کار ببریم: محدودۀ پروژه پادشاه است!
در بدنۀ دانش مدیریت پروژه یا PMBOK که همچون کتاب مقدس مدیریت پروژه می‌ماند، ۹ حوزۀ دانش بحث شده است؛ یکپارچه‌سازی [۱]، محدوده [۲]، زمان [۳]، هزینه [۴]، کیفیت [۵]، منابع انسانی [۶]، ارتباطات [۷]، ریسک [۸] و کارپردازی [۹]. هرکسی که برای گرفتن گواهی PMP مطالعه کرده باشد به‌خوبی می‌داند که PMBOK به تمام این حوزه‌ها به یک‌میزان می‌نگرد. درواقع PMI تمام حوزه‌های دانشش را کودکان خود می‌داند که هریک را به‌یک‌میزان دوست دارد. اما در دنیای واقعی یکی از حوزه‌ها توجه مضاعفی را به خود جلب کرده و آن محدوده یا Scope است.
بیشتر افرادی که بر پروژهها، با هر ظرفیتی، کار کرده‌اند با این طرزفکر آشنا هستند که پروژهها همیشه تحت‌کنترل سه‌گانۀ محدودیتیِ زمان، هزینه و محدوده است. هرکدام از این دو عامل اول را می‌توانید کنترل کنید و سومی برای شما تعریف می‌شود. هرگز شروع به انجام پروژهها با مقدار تعیین‌شدۀ زمان و بودجه نمی‌کنید؛ وگرنه سازمان نمی‌داند که با این پول و زمان چه کند. پروژهها آغاز می‌شوند زیرا به برطرفی و حل یک مشکل یا فرصتی برای ادراک یک مشکل نیاز است، و این یعنی محدوده.
محدوده باید اولین رأسی باشد که تعریف شود و در یک شرح محدودۀ [۱۰] رسمی محدود شود. بعدازآن تعیین می‌کنید که زمان و هزینه کافی برای تحویل مناسب محدودۀ کار پروژه چیست. چشم‌پوشی از زمان‌بندی، بودجه، کیفیت، ارتباطات، مسائل منابع انسانی یا مدیریت ریسک می‌تواند به پروژه آسیب جدی بزند، اما چشم‌پوشی از مدیریت محدوده موجب ازبین‌رفتن پروژه خواهد شد؛ زیرا محدوده برای تعریف موفقیت پروژه ضرورت دارد. محدوده به معنای «کاری است که برای اجرای پروژه انجام می‌دهید». می‌توانید سرعت و هزینۀ معقول دستاوردهای خوبی است، اما اگر در محدودۀ اشتباهی کار کنید موفقیتی در کار نیست.
ازلحاظ روابط عمومی، محدوده یکی از حوزه‌هایی است که بیشترین پتانسیلِ سردرگم‌کردن را دارد؛ بنابراین مدیران پروژه باید آنچه را که در محدوده و خارج از آن هست به ذی‌نفعان بسیاری، که چه در تیم پروژه و چه در خارج از آن، مخاطب آن‌ها هستند بفهمانند. در یک پروژه یکی از بدترین کشنده‌های روحیه وقتی است که یک ذی‌نفع مهم، دیرهنگام، در یک پروژه اعلام می‌کند: «من فکر کردم که از پروژه نتیجۀ X را می‌گیرم!». منشور پروژه و مستند پیشرفتۀ شرح محدوده ابزار مناسبی برای کمک به ارائه‌ها و اعلان‌ها هستند. وقتی که شرح‌کار خط‌مبنای محدوده با جزئیات مشخص شد، حامی مالی پروژه باید رسماً تأییدش کند، به دیگران بفهماندش و دائماً کنترلش کند. برای کنترل محدوده پیشنهاد می‌شود که از فرمی استفاده شود که از همان ابتدا درخواست‌های تغییر محدوده در آن ثبت شده، و باید یک کمیته از ذی‌نفعان حامی پروژه (به غیر از مدیر پروژه) تشکیل شود که مسئول تأیید تغییرات باشند. درخواست‌دهندگان تغییر باید تغییر و مزایای مفروض را مستند کنند و تیم پیاده‌سازی باید فرصت مستند کردن تأثیر آن بر زمان‌بندی و بودجه فعلی را داشته باشد. سپس این بسته برای تصمیم‌گیری به کمیتۀ تأییدکنندۀ تغییرات ارسال می‌شود. مدیر پروژه باید تصمیم نهایی را به تمام ذی‌نفعان ارسال کند و تأثیر آن را بر برنامۀ پروژه اعلام کند. به‌این‌ترتیب حامیان مالی می‌توانند کنترل منابع را حفظ کنند و اگر تصمیم منفی باشد مدیر پروژه را تبدیل به «مقصر اصلی داستان» نکنند. به‌علاوه سازوکاری به‌وجود می‌آید که مانع می‌شود تیم متحمل کار بیشتر، بدون زمان و منابع بیشتر برای تکمیل آن شود.
بنابراین به فرصت‌هایی لازم است که مدیران پروژه بتوانند محدوده را، تا جای ممکن، به دیگران بفهمانند. در زیر عنوان چند جلسۀ معمولی برای کمک به فهماندن محدوده به ذی‌نفعان را مشاهده کنید:
| جلسه | مخاطب | وسایل کمکی برای شناساندن محدوده |
| جلسۀ بررسی منشور | عموم ذی‌نفعان | منشور پروژه |
| جلسۀ بسط شرح محدوده | تیم پروژه | شرح محدوده |
| جلسۀ توسعۀ WSB | تیم پروژه | WSB (ساختار شکست کار) |
| جلسۀ تخمین‌زنی | تیم پروژه | WSB (ساختار شکست کار) |
| جلسۀ شروع پروژه | تیم پروژه | منشور پروژه، شرح محدوده، ماتریس نقش‌ها و مسئولیت‌ها (R&R) نمودار سازمانی پروژه |
| جلسات حامی مالی اجرایی
| حامیان مالی اجرایی | منشور پروژه، شرح زمان‌بندی، ماتریس نقش‌ها و مسئولیت‌ها (R&R) نمودار سازمانی پروژه |
| جلسات ذی‌نفعان | عموم، ذی‌نفعان | زمان‌بندی پروژه، ماتریس نقش‌ها و مسئولیت‌ها، نمودار سازمانی پروژه، درخواست‌های تغییر |
| جلسات کنترل تغییر | هیئت تأییدکنندۀ تغییرات | درخواست‌های تغییر، زمان‌بندی تغییر |
| جلسات تیم پروژه | تیم پروژه | شرح محدوده، ساختار شکست کار، درخواست‌های تغییر |
بهترین کار برای تیم پروژه این است که ذی‌نفعان را ازابتدا از محدودۀ تأییدشده و تغییرات پسایند آن آگاه نگه دارند تا جلوتر به‌هیچ‌صورت غافلگیر نشوند.
[۱] Integration
[۲] Scope
[۳] Time
[۴] Cost
[۵] Quality
[۶] Human resources
[۷] Communication
[۸] Risk
[۹] Procurement
[۱۰] Scope statement
