شیوه اختصاصی‌سازی استاندارد
این ماجرا که اختصاصی‌سازی (tailoring) برای اکثر استانداردها، از جمله PMBOK و PRINCE2، الزامیه، باعث می‌شه که اهمیت زیادی پیدا کنه، در حالی که شیوه انجام این کار برای خیلی‌ها مبهمه. تو این مطلب می‌خوام یه مقدار اختصاصی‌سازی رو توضیح بدم.
اولین نکته اینه که برای استفاده از استاندارد تو پروژه‌ها دو مرحله کار لازمه:
- انطباق استاندارد با سازمان، که اصطلاحا بهش می‌گن embedding
- انطابق نسخه اختصاصی‌سازی شده سازمان با پروژه‌ای که قراره شروع بشه، که بهش می‌گن tailoring
البته این رو باید بدونین که خیلی جاها به هردوی این‌ها tailoring می‌گن.
کلمه tailor وقتی حالت اسمی داشته باشه به معنی خیاطه؛ البته معمولا خیاطی که کت شلوار می‌دوزه. وقتی حالت فعل داشته باشه معنیش می‌شه: چیزی رو به شکلی بسازیم که برای کار یا فرد خاصی مناسب باشه یا چیزی که وجود داره رو به شکلی تطبیق بدیم که کاملا برای فرد یا کاری که در نظر داریم مناسب باشه. وقتی درباره tailor کردن استاندارد صحبت می‌کنیم هم همین معنی در نظره.
مرحله ۱: embed کردن استاندارد در سازمان
اولین مرحله embed کردن استاندارد تو سازمانه، یعنی نسخه‌ای اختصاصی‌سازی شده از استاندارد بسازیم که برای سازمان و پروژه‌های مختلفی که توش اجرا می‌شه مناسب باشه. ماجرا اینه که پروژه‌های مختلفی که تو یه سازمان انجام می‌شن از نظر مدیریتی خیلی به هم نزدیکن، چون سازمان انجام دهنده پروژه عامل محیطی خیلی مهمیه. به همین خاطر لازم نیست که تمام مراحل اختصاصی‌سازی رو برای تک تک پروژه‌ها تکرار کنیم. خیلی راحت می‌تونیم هفتاد تا هشتاد درصد رو که مشترک هستن جدا کنیم، یک بار برای سازمان انجام بدیم و بعد وقتی قراره پروژه جدیدی شروع بشه فقط بیست تا سی درصد باقیمونده اختصاصی‌سازی رو انجام بدیم.
اختصاصی‌سازی استاندارد برای سازمان خودش یه طرحه (program) که باید مثل هر طرح دیگه‌ای مدیریت بشه. البته خیلی‌ها اون رو به شکل پروژه پیش می‌برن، ولی طرح گزینه بهتریه. وقتی این طرح انجام می‌شه و استاندارد اختصاصی‌سازی می‌شه معمولا یه PMO هم ساخته می‌شه که مراقبت از اجرای درست اون رو به عهده بگیره.
این کار بسته به شرایط بین چهار ماه تا یه سال وقت می‌بره. البته بعد از این زمان هم چیزی که به وجود میاد فقط نسخه اولیه سیستمه و بعد از اون تا سال‌ها باید اون رو با جدیت بهبود داد تا به بلوغ کافی برسه. اگه سازمان خیلی خوب و جدی تو این حوزه عمل کنه، به بلوغ رسیدنش ۵ تا ۷ سال زمان می‌بره.
مرحله ۲: tailor کردن استاندارد برای پروژه
بعد از اینکه استاندارد برای سازمان اختصاصی‌سازی بشه، برای هر پروژه جدیدی که تعریف بشه باید اون نسخه اختصاصی‌سازی شده رو یه مرحله دیگه هم اختصاصی‌سازی کرد و بعد به کار گرفتش. مبنای این کار هم عوامل محیطی پروژه، مثل عدم قطعیت‌هاش، حساسیت کلی پروژه، ذی‌نفعان و امثال اون‌هاس.
معمولا انتظار داریم که این کار همراه با بقیه برنامه‌ریزی‌ها تو کمتر از ۱۰ درصد زمان پروژه انجام بشه. زمان شروعش هم قاعدتا اول پروژه‌س و جزئی از برنامه‌ریزی به حساب میاد. البته قاعدتا از اولین اقدامات برنامه‌ریزیه، چون شیوه برنامه‌ریزی رو تحت تاثیر قرار می‌ده. نتایج این کار تو PMBOK جزئی از برنامه مدیریت پروژه می‌شه و تو PRINCE2 جزئی از سند آغازش پروژه (PID). مسئولیت اصلیش هم مثل اکثر برنامه‌ریزی‌های دیگه به عهده مدیر پروژه‌س.
چطوری می‌شه استاندارد رو اختصاصی‌سازی کرد؟
تو ترکیب embed کردن و tailor کردن اتفاق‌های زیادی می‌افته، از جمله:
- تعیین نام‌ها! بله، خیلی وقت‌ها باید اسم عناصری که تو استاندارد هست رو عوض کرد تا برای مخاطب مفهوم‌تر باشه یا جلوی بعضی سوتفاهم‌ها رو بگیره. مثلا نقشی به اسم executive تو پرینس۲ وجود داره که اسمش معمولا ابهام ایجاد می‌کنه، چون تو هر شرکت عده‌ای مدیر ارشد وجود داره که بهشون می‌گن executive. اگه چنین مشکلی باشه، برای اینکه سوتفاهم ایجاد نشه می‌تونیم اسمش رو عوض کنیم و مثلا بذاریم sponsor (مشابه اون چیزی که تو پم‌باک وجود داره).
- تعیین محصول‌های مدیریتی. خوب، برای مدیریت هر پروژه باید تعدادی محصول مدیریتی تولید کرد که معمولا بهشون می‌گن سند، ولی ترجیح می‌دیم بهشون بگیم محصول مدیریتی، چون ممکنه به شکل سند نباشن. اینکه چه سندهایی قراره تولید بشه و تو هرکدوم چه محتوایی وجود داشته باشه یکی از مهم‌ترین جنبه‌های اختصاصی‌سازیه. مثلا اگه موضوع اختصاصی‌سازی پم‌باکه، آیا لازمه ۱۳ سند مختلف برای ۱۳ نوع برنامه مدیریتیش داشته باشیم؟ اگه پروژه‌های سازمان خیلی پیچیده نباشن معمولا یه سند نسبتا ساده برای این کار کفایت می‌کنه، که البته محتواش تمام ۱۳ موضوع رو دربرمی‌گیره.
- تعیین فرآیندها و فعالیت‌ها و اقدام‌ها: تو هر استاندارد تعدادی فرآیند، فعالیت و اقدام داره که همه این‌ها باید اختصاصی‌سازی بشن، یعنی مشخص بشه که به چه ترتیبی می‌خوایم اجراشون کنیم و جنبه‌های عملیشون چیه.
- تعیین نقش‌ها و مسئولیت‌ها: اگه استانداردی که داره اختصاصی‌سازی می‌شه از نوع متودولوژی باشه و نقش و مسئولیت داشته باشه، باید اون‌ها رو هم اختصاصی‌سازی کنیم.
هرکدوم از این‌ها رو به شکل‌های مختلفی می‌شه اختصاصی‌سازی کرد:
- حذف و اضافه: بعضی وقت‌ها می‌شه عناصری رو حذف و اضافه کرد. البته باید خیلی مراقب بود، چون موارد خیلی کمی رو می‌شه حذف کرد و مطمئن بود که به استاندارد صدمه نمی‌زنه. تحلیل کمی ریسک مثال خیلی خوبی از فرآیندهای پم‌باکه که اگه تناسبی با پروژه نداشته باشه می‌شه حذفش کرد. با این حال مثلا اگه فرآیند برنامه‌ریزی واکنش به ریسک رو حذف کنیم عملا سیستم رو ناقص کردیم. گاهی هم لازمه چیزهایی رو اضافه کنیم. مثلا اگه داریم پرینس۲ رو اختصاصی‌سازی می‌کنیم، استراتژی‌های مدیریتی پیش‌فرضش تمام جنبه‌های پروژه رو پوشش نمی‌ده و می‌تونیم از پم‌باک کمک بگیریم و استراتژی‌های باقیمونده رو بهش اضافه کنیم.
- بزرگ و کوچیک کردن: حالا هر عنصر رو تا چه حد قراره تفصیلی کنیم؟ مثلا اگه صحبت از بودجه‌بندی پروژه‌س، تا چه حد قراره وارد جزئیات بشیم؟ یه مشکل خیلی رایج اینه که وقتی سعی می‌کنن استانداردی رو به کار بگیرن تو همه چیز زیاد از حد وارد جزئیات می‌شن و انقدر زحمت خودشون رو زیاد می‌کنن که عملا نمی‌تونن به نتیجه برسن. تو خیلی از موارد لازمه که ابعاد یه عنصر ساده‌تر و کوچیک‌تر از اون چیزی بشه که تو استاندارد توضیح داده شده و گاهی هم لازمه که اون رو خیلی بزرگ‌تر و کامل‌تر کنیم که با پروژه تناسب داشته باشه.
- رسمی و غیررسمی کردن: قرار نیست همه چیز تو پروژه رسمی باشه. مثلا منشور پروژه پم‌باک یا حکم پروژه پرینس۲ لازم نیست حتما یه سند رسمی باشه؛ می‌تونیم یه جلسه نیم روزه بذاریم که همه افراد کلیدی توش باشن، درباره تمام جنبه‌هایی که لازمه صحبت کنیم و نتایج رو هم صورت جلسه کنیم. این صورت جلسه می‌شه خلاصه‌ای از محتوایی غیررسمی که کار منشور پروژه یا حکم پروژه رو می‌کنه. نمونه دیگه گزارش‌های پروژه‌س. مثلا اگه حساسیت زیاد نباشه می‌شه تعیین کرد که checkpoint reportها (گزارش‌های مدیران تیم‌ها به مدیر پروژه) صرفا یه تماس تلفنی باشه که هر هفته دو شنبه‌ها، حدود ساعت ۱۰ صبح انجام می‌شه و تو این مکالمه درباره فلان مسایل صحبت می‌کنن. این می‌شه اختصاصی‌سازی: دلیلی نداره همه چیز رسمی باشه.
- ترکیب و تجزیه کردن: گاهی لازمه چند عنصر رو با هم ترکیب کنیم یا یه عنصر رو تجزیه کنیم به چنتا. مثلا ممکنه پروژه ساده باشه و بخواین مدیر ارشد و کاربر ارشد رو با هم ترکیب کنین؛ اگه شرایط خاصی رو رعایت کرده باشین هیچ اشکالی نداره. از طرف دیگه ممکنه شرایط ایجاب کنه که نقش هیات پروژه رو مثلا به دو سطح تجزیه کنین و یه سطح جدید به تصمیم‌گیری‌های پروژه اضافه کنین.
- جانشین کردن: گاهی، تو شرایط خاص، ممکنه بعضی عناصر استاندارد رو با عناصر دیگه‌ای جانشین کنیم. مثلا ممکنه استانداردی که ۶ فرآیند داره رو اختصاصی کنیم و به جای اون ۶ فرآیند، ۴ فرآیند مخصوص خودمون رو بذاریم که هیچ ارتباط مستقیمی با فرآیندهای اصلی ندارن، ولی وقتی اون‌ها رو چک می‌کنیم ببینیم که تمام عملکردهای فرآیندهای پیش‌فرض توشون وجود داره. این کار رو البته باید با احتیاط انجام داد.
اختصاصی‌سازی کار ساده‌ای نیست. هم زمان زیاد می‌بره و هم انرژی. فرد یا گروهی که مسئول این کاره باید عده خیلی زیادی رو به مشارکت بگیره، نظرهاشون رو بشنوه، اون‌ها رو تو پروژه اعمال کنه، بازخورد بگیره، اصلاح کنه و …
کسی که این مسئولیت رو به عهده می‌گیره باید دانش خیلی عمیق و کاملی از استاندارد داشته باشه، طوری که بدونه هر چیزی که تو استاندارد گفته شده چه هدف و نتیجه‌ای داره، اصلا چرا وجود داره، و چطوری به بقیه بخش‌های استاندارد ربط داره. اگه چنین دانشی وجود نداشته باشه هیچوقت نمی‌تونیم مطمئن باشیم که اون چیزی که ساختیم واقعا با استاندارد سازگاره و اگر هم کاملا سازگار نباشه ریسک خیلی زیادی وجود داره که به نتیجه نرسه.