تفاوت طرح، پروژه و پرتفولیو
چند سوال از من شده بود که مجموعا به این برمی‌گشت که چطوری می‌شه تشخیص داد که یه چیزی پروژه‌س یا طرح و این‌که کلا این برچسب‌ها چه اهمیتی دارن. به همین خاطر می‌خوام ماجرا رو کامل توضیح بدم. در ضمن، اگه سوالی داشته باشین می‌تونین تو بخش جدیدی که سمت چپ همه صفحه‌ها اضافه شده ثبتش کنین که اگه می‌تونست برای عموم مفید باشه این‌جا توضیح بدمش.
تعریف‌هایی که برای سه سطح پروژه، طرح و پرتفولیو تو استانداردهای PMI هست چندان راهگشا نیست و عملا باهاشون نمی‌شه مشخص کرد که چه چیزی پروژه‌س، چه چیزی طرحه، و چه چیزی پرتفولیو. به همین خاطر ماجرا رو بر اساس تعریف استانداردهای AXELOS (پرینس۲ و امثال اون) توضیح می‌دم، که از نظر من خیلی خوش‌ساخت‌تره.
به عنوان مثال، این موارد رو ببینین:
- ساخت یه سد
- افزایش تعداد بازدیدکننده یه وب‌سایت
کدوم پروژه‌س و کدوم طرح؟
تعریف سطوح
تعریف AXELOS بر اساس این توالیه:
- کارهایی انجام می‌شه،
- اون کارها محصولی تولید می‌کنن،
- از اون محصول نتیجه‌ای حاصل می‌شه،
- از اون نتیجه منافعی به دست میاریم.
مثلا:
- انواع کارهای طراحی و تامین و ساخت و نظارت و غیره رو انجام می‌دیم،
- و بعد از مدتی یه سد ساخته می‌شه،
- و به خاطر وجود اون سد، آبرسانی به مزارع اون محدوده بهتر می‌شه و سیستم آب آشامیدنی هم دیگه دچار کمبود نمی‌شه، که این‌ها خودشون باعث افزایش درآمد ناشی از کشاورزی و کاهش بیماری‌های ناشی از آشامیدن آب آلوده می‌شه،
- که در نهایت درآمد ناخالص استان رو فلان قدر در سال افزایش می‌ده و کیفیت زندگی رو هم بهمان واحد در فلان مقیاس مخصوص ارزیابی کیفیت زندگی افزایش می‌ده.
هر چهار سطحی که گفته شد اهمیت داره و باید مدیریت بشه. با این حال، شیوه مدیریتی که نیاز دارن یکسان نیست، چون طبیعت یکسانی ندارن؛ به عبارت دیگه، مدیریت کارها، مدیریت محصول‌ها، مدیریت نتایج و مدیریت منافع یکسان نیست. به همین خاطره که برای این‌ها اسم‌های مختلفی انتخاب شده و سیستم‌های مدیریت متفاوتی براشون شکل گرفته:
- کارها: برای این مورد اسمی که کاملا رایج باشه وجود نداره و سیستم‌های مدیریتی هم خیلی متنوع و حتی تا حدی پراکنده‌ان.
- محصول‌ها: سطحی که عمدتا با مدیریت محصول سر و کار داره اسمش پروژه‌س و سیستمی که لازم داره، مدیریت پروژه.
- نتایج: سطحی که عمدتا با مدیریت نتایج سر و کار داره اسمش طرحه و سیستم‌های مناسبش با عنوان مدیریت طرح شناخته می‌شن.
- منافع: این سطح اسمش پرتفولیوس و سیستم‌های مدیریت پرتفولیو اون رو بهینه می‌کنن.
آیا اندازه اهمیتی داره؟
با این حساب، می‌تونیم برگردیم به سوال اولیه و ببینیم اون دو مثال چه جنسی دارن:
- ساخت یه سد: این درباره یه محصوله، در نتیجه یه پروژه‌س.
- افزایش تعداد بازدیدکننده یه وب‌سایت: این مورد درباره یه نتیجه‌س؛ نتیجه‌ای که می‌خوایم بگیریم افزایش بازدیدکننده‌س. پس، این یه طرحه.
خیلی‌ها فکر می‌کنن که تمایز پروژه و طرح تو اندازه اون‌هاس، در حالی که اینطور نیست. تو این مثال، اونی که طرح به حساب میاد به مراتب کوچیک‌تر از اونیه که یه پروژه به حساب میاد.
سلسله مراتب
اگه چیزی که در نظر داریم طرح باشه، باید ببینیم با چه محصول‌ها و کارهایی می‌تونیم به نتیجه‌ای که می‌خوایم برسیم، و محصول‌هایی که در طی مسیر طراحی و تعریف می‌شن در قالب تعدادی پروژه ساخته می‌شن. به همین خاطره که هر طرح شامل تعدادی زیرطرح، پروژه و احیانا کارهای عملیاتی می‌شه.
از طرف دیگه، تو لایه مدیریت منافع (پرتفولیو)، برای این‌که بتونیم به منافعی که می‌خوایم برسیم، نتایجی رو طراحی و برنامه‌ریزی می‌کنیم (تعدادی طرح) یا این‌که مستقیما روی محصول‌ها کار می‌کنیم (پروژه). به این ترتیبه که هر پرتفولیو ترکیبی می‌شه از تعداد زیرپرتفویلو، طرح، پروژه و احیانا کارهای عملیاتی.
همپوشانی‌ها
این‌که تمرکز اصلی پروژه روی محصوله، تمرکز اصلی طرح روی نتایج و تمرکز اصلی پرتفولیو روی منافع، به این معنی نیست که هیچکدوم از این سطوح با اونیکی مفاهیم سر و کار ندارن. مثلا، تو پروژه تمرکز اصلی روی محصوله، ولی کماکان باید به نتایج و منافع هم فکر کنیم. با این حال، فقط در حدی که برای تصمیم‌گیری‌های کلی پروژه و پشتیبانی از سطوح بالاتر لازمه، نه به عنوان وظیفه اصلی. همین ماجرا در مورد دو سطح دیگه هم صادقه: اون‌ها هم به محصول توجه دارن، ولی تمرکز اصلیشون روی چیز دیگه‌ایه.
این روزها بعضی‌ها سعی می‌کنن همه چیز رو در پروژه خلاصه کنن، که کاملا اشتباهه. مثلا، مدیریت منافع هیچوقت نمی‌تونه به طور کامل تو لایه پروژه انجام بشه، چون گذشته از این‌که نیاز به تخصص‌های خاص خودش داره، به طور کلی منفعت مفهومی غیر خطیه که باید به شکل کلی ارزیابی و مدیریت پروژه. اینطور نیست که هر پروژه‌ای منافع رو در گستره خودش بهینه کنه و نتیجه این باشه که منافع تو سطح سازمان بهینه بشن؛ این بهینه‌سازی حتما باید در سطح سازمان و با دید کلی انجام بشه و به خاطر طبیعت غیر خطیش، وضعیت بهینه سازمان می‌تونه با ترکیبی از وضعیت‌های غیر بهینه پروژه‌ها به وجود بیاد.
دلیل اصلی این‌که بعضی‌ها فکر می‌کنن می‌شه همه چیز رو در سطح پروژه خلاصه کرد اینه که سال‌های اخیر بعضی شرکت‌هایی که به خاطر سیستم‌های مدیریتیشون معروف شدن (مثلا Netflix و Spotify)، شرکت‌هایی تک محصولی هستن، که توشون عملا این سه لایه در هم ادغام می‌شه. با این حال، اکثر شرکت‌ها چنین وضعیتی ندارن.
آیا همیشه مدیریت طرح لازمه؟
برگردیم سراغ مثال ساخت سد. جوابمون به این سوال که مدیریت طرح لازمه یا نه، برمی‌گرده به زاویه دیدمون:
- برای پیمانکاری که داره این پروژه رو انجام می‌ده، نتیجه اصلی اینه که می‌تونه کارفرما رو راضی کنه و برسه به منافعش. نتیجه انقدر ساده‌س که عملا فاصله چندانی بین محصول و منافع باقی نمی‌مونه و در نتیجه نیاز چندانی به یه سیستم ساخت یافته مدیریت طرح نیست.
- برای کارفرمایی که این پروژه رو به پیمانکار سفارش داده وضعیت کاملا فرق می‌کنه: اون کارفرما قاعدتا این محصول رو برای رسیدن به نتیجه‌ای خاص در نظر گرفته (مثلا بهبود سیستم آبرسانی فلان استان) و برای رسیدن به اون نتیجه هم احتمالا چندین محصول لازمه. برای همین از زاویه دید کارفرمایی سیستم مدیریت طرح لازمه.
در کل، به لحاظ تئوریک می‌شه گفت که مدیریت طرح همیشه به نوعی وجود داره، ولی در عمل همیشه نیازی به مدیریت طرح نیست؛ تو بعضی شرایط انقدر ساده و پیش پا افتاده می‌شه که عملا می‌شه گفت وجود نداره.
آیا همیشه مدیریت پرتفولیو لازمه؟
همیشه، صد در صد، بدون استثنا!
هر شرکتی که می‌خواین رو فرض کنین. به نظرتون هر پروژه‌ای که پیش بیاد رو انجام می‌دن؟ هر ایده‌ای که به ذهنشون برسه رو پیاده‌سازی می‌کنن؟ قطعا نه. این‌که چنین کاری نمی‌کنن و فقط بعضی پروژه‌ها رو اجرا می‌کنن دقیقا همون مفهوم مدیریت پرتفولیوس: کاری که می‌کنن اینه که منافعی که احتمالا از اون پروژه حاصل می‌شه رو برآورد می‌کنن (حداقل به طور ضمنی) تا ببینن از هزینه پروژه بیشتر هست یا نه، و از اون مهم‌تر، از منافع پروژه‌های دیگه‌ای که می‌تونن به جای اون انجام بدن (چون منابع همیشه محدوده) بالاتر هست یا نه.
فرقی نمی‌کنه که به چه نوع شرکتی فکر کنیم، بزرگ یا کوچیک، کارفرما یا پیمانکار، یا هر تفکیک دیگه‌ای؛ سیستم مدیریت پرتفولیو همیشه لازمه و همیشه هم وجود داره. گاهی ممکنه این سیستم ساخت‌یافته و موثر نباشه، ولی باز هم وجود داره. کاری که باید بکنیم اینه که اون رو در حد نیازهای شرکت بهبود بدیم تا بتونیم منافع رو بهینه کنیم.
پس چرا بعضی جاها از پروژه‌های مستقل صحبت می‌شه؟
پروژه مستقل (stand-alone) چیزیه که ممکنه تو بعضی منابع ببینین، به مفهوم پروژه‌ای که زیرمجموعه‌ای از هیچ طرح یا پرتفولیویی نیست. این‌که پروژه‌ای زیرمجموعه هیچ طرحی نباشه مشکلی نداره (طبق توضیحی که بالاتر دادم)، ولی هیچ پروژه‌ای نیست که زیرمجوعه هیچ پرتفولیویی نباشه. منابعی که درباره چنین مفهومی صحبت می‌کنن مرتکب اشتباه شدن.
این مفهوم تو آخرین نسخه PRINCE2 و PRINCE2 Agile وارد شده، و زمانی که تدوین می‌شدن بحث خیلی طولانی‌ای در این مورد با سایر افرادی که دست‌اندرکار بودن کردم (مسئولیت من بررسی استانداردها بود، نه تالیف اون‌ها)، ولی متاسفانه به نتیجه‌ای نرسید. تو MSP (استاندارد مدیریت طرح) این مفهوم به طور خیلی جزئی وجود داشت و خوشبختانه تو نسخه جدید که الان در حال تدوین هست و هنوز منتشر نشده، کاملا حذف شده. تو چند نسخه اخیر PMBOK هم این مفهوم وارد شده بود، ولی تو نسخه هفتم که به جای بهبود نسخه‌های قبلی کلا اون رو از ابتدا نوشتیم، خوشبختانه هیچ کسی پیشنهاد نداد چنین مفهومی وارد بشه که بخوایم وارد بحث بشیم!