وقتی برنامه جبرانی تهیه می‌کنیم چه اتفاقی برای ارزیابی عملکرد می‌افته؟
قبل از جواب دادن به این سوال باید به سوال خیلی مهم‌ترین جواب داد: اصلا چرا برنامه جبرانی تهیه می‌کنیم؟
ماجرا اینه که تو هر پروژه باید به نوعی حدود رواداری در نظر گرفت. مثلا پروژه (یا مرحله‌ای از پروژه) قراره تو شش ماه با حداکثر سه هفته رواداری تموم بشه، با هزار تومن هزینه و رواداری صد تومن. این می‌شه ساده‌ترین حالت تعریف بودجه و رواداری پروژه (بودجه هم به پولی گفته می‌شه که برای اون کار کنار گذاشته شده و هم زمانی که براش در نظر گرفته شده). حالا وقتی کار داره پیش می‌ره دایما تاریخ پایان پروژه (یا مرحله) و هزینه تخمینی زمان پایان اون رو محاسبه می‌کنیم و اگه اون حدود رواداری رو رد کنه، وقت تهیه برنامه جبرانی می‌شه که اصلاحا به اون رویداد می‌گیم exception. تو این حالت قرار نیست یه برنامه‌ریز تک و تنها بره بشینه تو اتاق، در رو ببنده و با زمان‌ها و روابط بازی کنه تا برنامه فشرده بشه؛ اتفاقی که می‌افته اینه که فهمیدیم با سیاست‌های اجرایی برنامه‌ریزی شده نمی‌تونیم به هدف‌های تعریف شده برسیم و در نتیجه باید دوباره تیم پروژه جمع بشن (مثل روز اولی که همه با هم برنامه رو تهیه کردن) راه حلی پیدا کنن؛ یه روش جدید کار کردن که بتونه ما را به هدف‌هامون برسونه، تجدید نظری تو هدف‌ها یا هر چیز دیگه. نیروهای برنامه‌ریز به نمایندگی …
ماکس پلانک بعد از این‌که جایزه نوبل رو تو سال ۱۹۱۸ می‌گیره یه تور دور آلمان می‌ذاره و تو شهرهای مختلف درباره کوانتوم مکانیک صحبت می‌کنه. چون هر دفعه دقیقا یه محتوا رو ارائه می‌کرده، دیگه راننده‌ش کاملا اونها رو حفظ شده بود. یه بار راننده‌ش بهش می‌گه که «شما از تکرار این حرف‌ها خسته نمی‌شین؟ من الان دیگه به حدی حفظ شدمشون که می‌تونم به جای شما ارائه کنم. اصلا بیاین تو مقصد بعدی که مونیخه من سخنرانی کنم و شما لباس من رو بپوشین و بشینین تو جلسه؛ برای هردومون تنوع می‌شه». پلانک هم قبول می‌کنه!
شوفر خیلی خوب تو جلسه درباره کوانتوم مکانیک صحبت می‌کنه و شونده‌ها هم خیلی لذت می‌برن. ولی آخرش یه فیزیک‌دان بلند می‌شه و سوال می‌پرسه. شوفر هم در نهایت خونسردی می‌گه «من تعجب می‌کنم که تو شهری پیشرفته مثل مونیخ سوال‌هایی به این اندازه ساده می‌پرسن که حتی شوفر من هم می‌تونه جواب بده! شوفر عزیز، شما به ایشون جواب بدین».
بر اساس همین داستان اسم اثر خاصی رو گذاشتن «اثر شوفر»؛ جایی که متخصص واقعی و مجری غیر متخصص جابجا می‌شن. به نظر اکثر آدم‌ها مجری‌های (منظور مفهوم کلی مجریه، نه مجری تلویزیون) غیر متخصصی که مثل اون شوفر فقط چیزهایی رو حفظ هستن متخصص‌تر میان تا اون‌هایی که واقعا متخصص هستن، چون یه متخصص واقعی به خودش اجازه نمی‌ده در مورد هر چیزی با قطعیت اظهار نظر کنه، در حالی که مجری در مورد همه …
بعضی از اصطلاحات مدیریت پروژه تو بازه‌های خاصی مد می‌شن. مثلا تو سال‌های گذشته PMBOK بیشتر از هر چیزی به گوشمون می‌خورد. الان حقیقتا هیچ چیزی از نظر مد بودن به پای PMO نمی‌رسه. نکته جالب هم اینه که این ماجرا به ایران محدود نمی‌شه و عملا یه مد جهانیه. به همین خاطر می‌خوام تو این مطلب توضیح‌های خلاصه ولی جامع در مورد این مفهوم بدم.
ترکیب عبارت
PMO می‌تونه مخفف یکی از این عبارت‌ها باشه:
Project Management Office
Program Management Office
Portfolio Management Office
و این سه‌تا انقدر شباهت دارن که عملا تو یه سرفصل بررسی بشن و به همین خاطره که مهم‌ترین استانداردی که در مورد PMOها هست اسمش P3O گذشته شده که مخفف این عبارته:
Portfolio, Programme, and Project Offices
و این استانداردیه که ما عملا برای پیاده‌سازی PMOها استفاده می‌کنیم.
مفهوم عبارت
PMO تعریف خاص و روشنی نداره. به یه دفتری می‌گن که معمولا به چند پروژه سرویس می‌ده و این سرویس‌ها برای همسان‌سازی و استاندارد کردن فعالیت‌های مدیریت پروژه‌س. با این حال یه کم جلوتر با هم می‌بینیم که تنوع فعالیت‌ها خیلی بیشتر از این هم می‌تونه باشه.
در هر حال باید در نظر داشته باشین که معنی‌دار ترین حالت یه PMO وقتیه که به چندین پروژه سرویس بده (نه یه پروژه) و هدفش هم تعالی مدیریت پروژه باشه. شاید می‌دونین که تکرارپذیر کردن فرآیندهای مدیریت پروژه …
تولید تو کارخانه از مثال‌های رایج برای «عملیاته»، چیزی که پروژه نیست و قرار نیست از ابزارهای مدیریت پروژه براش استفاده بشه. ولی اوضاع برای بعضی تولیدهای مبتنی بر سفارش یه کم پیچیده می‌شه.
به نظر من اگه سفارشی که کارخونه می‌گیره صرفا به معنی نوعی پیش‌خرید برای تولید محصول روتین کارخونه باشه، باید عملیات در نظر گرفته بشه. اگه این سفارش منجر به نوعی طراحی و تولید اختصاصی می‌شه که البته در عین حال درجه‌ای از روتین بودن رو هم حفظ می‌کنه، ماجرا جایی بین پروژه و عملیات قرار می‌گیره. تو این حالت تصمیم‌گیری در مورد ماهیت کار زیاد ساده نیست و حتما باید عوامل مختلفی رو در نظر گرفت. حتی شاید لازم باشه برعکس عمل کنیم، یعنی ببینیم که روش‌ها و ابزارهای مدیریت پروژه برای اون کار موثرتره یا عملیات و بر اون اساس روی کار برچسب پروژه یا عملیات بزنیم. من خودم تو اکثر موارد توصیه می‌کنم که کار عملیات دونسته بشه.
اگه این نوع کارها رو پروژه دونستین هم حتما در نظر داشته باشین که سیستم مدیریت پروژه‌ای که براش اختصاصی‌سازی (tailor) می‌کنین حتما باید خیلی ساده باشه.
در نهایت آخرین نکته‌ای هم که وجود داره اینه که توجه داشته باشیم تمایز بین عملیات و پروژه معمولا تو سیستم‌های کلاسیک اهمیت داره و خیلی از متودها مثل بعضی از متودهای چابک هم برای پروژه و هم برای عملیات قابل استفاده هستن. در نتیجه اگه گرایش به اون …
کتاب «راهنمای جامع برنامه‌ریزی و کنترل پروژه با Primavera P6» که چهار سال پیش برای نسخه ۶ نرم‌افزار تهیه و منتشر شده بود رو برای نسخه 8.3 به‌روزرسانی کردم و نسخه الکترونیکیش رو می‌تونین از این آدرس تهیه کنین.
این کتاب مشابه نسخه قبلیش حالت مرجع داره و نه خودآموز. محتوای کلی هم مثل قبله و فقط تغییرات نرم‌افزار توش منعکس شده. در نتیجه اگه نسخه قبلی رو داشته باشین نیازی نیست که دوباره تهیه‌ش کنین؛ البته مگر این‌که الکترونیکی بودنش رو ترجیح بدین.
نسخه چاپی کتاب هم تا چهار پنج ماه دیگه منتشر می‌شه.
همونطوری که می‌دونین یکی از موسسه‌های غیرانتفاعی مدیریت پروژه IPMA هست. این موسسه بیشتر گرایش اروپایی داره، ولی تو کل دنیا فعاله؛ البته دست‌اندرکارای مدیریت پروژه زیاد نمی‌شناسنش.
به هر حال این موسسه تو ایران هم رسما فعالیت می‌کنه و آزمون‌های موسسه رو هم برگزار می‌کنه.
چهار گواهی تعریف شده، IPMA-D و IPMA-C و IPMA-B و IPMA-A، که به ترتیب حرفه‌ای‌تر می‌شن. ساده‌ترین آزمون‌ها که سطح C و D هستن قراره پنجشنبه ۲۸ شهریور ۱۳۹۲ تو ایران برگزار بشن. آزمون به زبان فارسی برگزار می‌شه.
اگه علاقه‌مند بودین می‌تونین به سایت انجمن مدیریت پروژه ایران مراجعه کنین و اطلاعات تکمیلی رو پیدا کنین و اگه مایل بودین ثبت نام هم بکنین.
استاندارد انجمن که ICB هست رو هم می‌تونین به رایگان از سایت دریافت کنین. البته سوال‌های آزمون محدود به ICB نمی‌شه و باید خیلی چیزهای دیگه هم مطالعه کنین. علاوه بر اون نمونه سوال هم هست که می‌تونه خیلی به دردتون بخوره.
کلا دو روش برای بحرانی به حساب آوردن فعالیت‌ها و در نتیجه تعیین «مسیر بحرانی»، یعنی مجموعه فعالیت‌های بحرانی – که از قدیم علاقه داشتیم تو یه مسیر باشن – وجود داره:
بر اساس حداکثر شناوری کل فعالیت‌ها
بر اساس قرار گرفتن روی طولانی‌ترین مسیر
روش اول برای اکثر افراد آشناتره و معمولا جاهایی که تئوری CPM رو توضیح می‌دن از همین روش استفاده می‌کنن. تو این روش زودترین و دیرترین تاریخ‌های شروع و پایان هر فعالیت تو دو مرحله رفت و برگشت محاسبه می‌شه و تفاضل زودترین و دیرترین تاریخ‌ها دو مقدار شناوری شروع و شناوری پایان رو به وجود میاره. نرم‌افزارهای مختلف یا یکی از این دوتا رو شناوری کل می‌شناسن، یا حداقل اونها رو، یا حتی انتخاب اون رو به شما بدن؛ البته این دو مقدار تو حالت‌های معمولی با هم برابر هستن. حالا حدی برای اونها در نظر گرفته می‌شه و هر فعالیتی که شناوری کلش از اون مقدار بیشتر نباشه بحرانی به حساب میاد.
شناوری کل فعالیت‌ها تو برنامه‌ای که آزاد باشه از صفر کمتر نمی‌شه و این فرض تو حالت‌های قدیمی که تو تئوری‌ها توضیح داده می‌شه هم وجود داره. برای همین رسم بر این بوده که شناوری صفر بحرانی به حساب بیاد. حالا تو پروژه‌هایی که مدت زمانشون زیاد باشه و مدت زمان فعالیت‌هاشون هم خیلی کم نباشه، شناوری‌هایی مثل یک روز چندان با صفر فرق نمی‌کنه. به همین خاطر این گزینه هم وجود داره که حداکثر …
خیلی‌ها در مورد امتیاز قبولی تو آزمون PMP سوال دارن. ماجرا اینه که امتیاز قبولی یه زمانی ۶۲٪ بود، خیلی ساده و سرراست. ولی الان مدت زیادیه که دیگه امتیاز مشخص و ساده‌ای برای قبولی تو آزمون وجود نداره و کسایی که دارن برای آزمون آماده می‌شن نمی‌دونن که دقیقا باید چه انتظاری داشته باشن.
PMI سیستم فعلی رو رسما توضیح نداده و قصد هم نداره بده، ولی ظاهرا ماجرا اینطوریه: بانکی از سوال‌ها وجود داره که تعدادی از اونها برای آزمون هر کسی انتخاب می‌شه. حالا الان تو اون بانک برای هر سوال یه پارامتری هم وجود داره که سختیش رو مشخص می‌کنه. امتیاز قبولی هر کس بسته به ترکیب سختی سوال‌هایی که به طور رندم براش انتخاب شده تعیین می‌شه. به همین خاطر امتیاز قبولی همه یه جور نیست و اگه احیانا سوال‌هاتون سخت باشن خیالتون راحته که با امتیاز کمتری قبول می‌شین و به عبارت دیگه ماجرا منصفانه‌تر می‌شه. امتیازهای قبولی ظاهرا بین ۶۰ تا ۶۵ (و از نظر بعضی ۶۰ تا ۶۸) قرار داره.
البته وقتی که آزمون تموم می‌شه امتیازتون اعلام نمی‌شه و فقط می‌فهمین که قبول شدین یا نه و این‌که تو هرکدوم از گروه‌های فرآیندی چه وضعیتی داشتین. یه شایعه‌ای که وجود داره اینه که باید تو هرکدوم از گروه‌ها هم حداقلی از امتیاز رو بگیرین تا قبول بشین. با این‌که نمی‌شه کاملا به این شایعه اطمینان داشت، ولی به هر حال خوبه که وضعیت خودتون رو تو تک تک …
هدف خیلی از پروژه‌های بزرگی که می‌بینیم کمابیش واضح هستن، ولی بعضی وقت‌ها هدف پروژه به اندازه کافی واضح نیست و تا وقتی که اون رو به خوبی مشخص نکنیم نمی‌تونیم پروژه رو درست برنامه‌ریزی و اجرا کنیم. مثلا فرض کنین شما متخصص پیاده‌سازی سیستم‌های مدیریت اسناد هستین و یه شرکتی شما رو برای این کار استخدام کرده. الان هدف چیه؟ اگه بگیم هدف پیاده‌سازی سیستم مدیریت اسناده زیاد دقیق صحبت نکردیم، چون اون خودش منجر می‌شه به این سوال که هدف از پیاده‌سازی سیستم مدیریت اسناد چیه. جوابی هم که به این سوال می‌دیم خیلی روی تعریف محصول پروژه و به تبع خود پروژه اثر داره، پس باید تو این کار جدی باشیم.
پروژه تو PRINCE2 تعریف و مشخصاتی داره که یکی از جنبه‌های اون می‌تونه خیلی تو شفاف کردن محصول پروژه بهمون کمک کنه:
پروژه چیزیه که تغییری تو دنیا به وجود میاره
این نکته خیلی جالبیه. اگه مجموعه کاری تعریف بشه که حتی به لحاظ تئوریک هم پتانسیل ایجاد تغییری تو دنیا رو نداشته باشه، نمی‌شه اسمش رو گذاشت پروژه.
حالا می‌تونیم از همین رویکرد PRINCE2 برای شفاف‌تر کردن محصول پروژه استفاده کنیم. اولین سوالی که باید بپرسیم اینه که «انتظار دارین محصول این پروژه چه تغییری ایجاد کنه؟»، یا تو مثالی که زده بودم «انتظار دارین که سیستم مدیریت اسناد چه چیزی رو براتون تغییر بده؟». جواب‌هایی که برای چنین سوال‌هایی می‌گیرین مسایلی …
پنجشنبه گذشته تو کلاس مجازی رفع اشکال PMP بود و همینطور بر اساس تعدادی ایمیل که به تازگی دریافت کردم، متوجه نکته‌ای شدم: این‌که بعضی از کسایی که تو این حوزه دارن فعالیت می‌کنن و درباره مدیریت پروژه مطالعه می‌کنن خیلی اختصارهای عجیب و غریب استفاده می‌کنن. اکثر اختصارهایی که گفته می‌شد برای من آشنا نبود و تنها کاری که می‌تونستم بکنم این بود که بر اساس موضوع حدس بزنم که این چه عبارتیه که بعد از مختصر شدن به این شکل در اومده.
توی PMBOK و PRINCE2 و تمام استانداردها و منابع معتبری که می‌شناسم به هیچ وجه از اختصار استفاده نمی‌کنن و اصولا این کار تو مدیریت پروژه توصیه نمی‌شه. علت اصلیش هم اینه که مدیریت پروژه حوزه‌ایه که باید با همه کسایی که تو پروژه‌ها کار می‌کنن سر و کار داشته باشه و باهاشون ارتباط برقرار کنه. برای این‌که بهتر بتونه باهاشون ارتباط برقرار کنه باید زبان ساده و موثری داشته باشه که همه بفهمنش و هم راحت‌تر بتونن ارتباط برقرار کنن و هم جبهه‌گیری نکنن.
اگه به PMBOK نگاه کنین می‌بینین که حتی اختصار خیلی رایجی مثل WBS رو هم ترجیح می‌ده کامل بنویسه و عملا فقط تو شکل‌ها و جاهایی مشابه اون که فضای کافی وجود نداره اون رو «WBS» می‌نویسه.
حالا من نمی‌دونم این گرایش به مختصر کردن عبارت‌ها از کجا ریشه گرفته، ولی به هر حال شدیدا به همتون توصیه می‌کنم که اختصار به کار نبرین.
کتاب قواعد زمان‌بندی پروژه که قبلا به صورت ایبوک منتشر شده بود جدیدا چاپ هم شده و در نتیجه کسایی که کتاب‌های چاپی رو به کتاب‌های الکترونیکی ترجیح بدن می‌تونن اون رو از سایت انتشارات دیباگران تهران، یا کتاب‌فروشی‌ها بخرن.
یکی از اولین کتاب‌هایی که به صورت ایبوک منتشر کرده بودم، راهنمایی ساده در مورد نسخه چهارم PMBOK بود، که عده زیادی اون رو تهیه کرده بودن. با توجه به این‌که هنوز عده‌ای در حال تهیه کتاب بودن، در حالی که نسخه جدید PMBOK منتشر شده، احساس کردم که بهتره نسخه به‌روز شده اون رو هم تهیه کنم.
کتاب PMBOK 5 به زبان ساده عملا نسخه به‌روز شده کتاب قبلیه و فرق خاصی نکرده، به جز مسایلی که به تغییرات این نسخه PMBOK مربوط می‌شده؛ که البته بخشی از اون تغییرها هم تو کتاب تاثیر خاصی ندارن، چون کتاب وارد خیلی از جزئیات نمی‌شه.
به نظر شما تغییر تعداد فرآیندهای پم‌باک چه معنایی داره؟ یعنی کارهایی بوده که تو نسخه قبل از قلم افتاده بوده و الان اضافه شده؟
هر فرآیند مجموعه‌ای از اقدامات مدیریتیه؛ معمولا هر فرآیند چندین اقدام مختلف رو تو خودش جا داده. یعنی عملا می‌شه اینطوری گفت که فرآیندها راهی برای دسته‌بندی اقدامات مدیریتی هستن.
شیوه دسته‌بندی اقدامات تو نسخه‌های مختلف تغییر می‌کنه تا بعضی مفاهیم رو بهتر منتقل کنه و این تغییر تو دسته‌بندی اقدامات معمولا باعث کاهش یا افزایش تعداد فرآیندها می‌شه (بله، تعداد فرآیندهای نسخه چهارم کمتر از نسخه سوم بود). بنابر این باید بدونین که تغییر تعداد فرآیندها اصلا به معنی افزایش یا کاهش اقدامات مدیریتی نیست و معمولا فقط یه تغییر ساختاره.
به عنوان مثال تو نسخه پنجم پم‌باک فرآیند جدیدی داریم به اسم «برنامه‌ریزی مدیریت هزینه» که کارش تهیه برنامه مدیریت هزینه هست. اقدامات این فرآیند قبلا همگی تو فرآیند «تهیه برنامه مدیریت پروژه» تو حوزه یکپارچگی بودن و الان از اونها جدا شدن و تو فرآیند جداگانه‌ای قرار گرفتن. تو این مورد هدف این بوده که هرکدوم از برنامه‌های مدیریتی اصلی حوزه‌ها فرآیند مستقلی داشته باشن.
بعد از فعالیت‌های اخیر تو حوزه PRINCE2 خیلی‌ها ازم می‌پرسیدن که چرا کتابی در مورد PRINCE2 نمی‌نویسم. این شد که اولین کتاب که یه راهنمای خیلی ساده و خلاصه درباره متودولوژی مدیریت پروژه PRINCE2 هست رو نوشتم و الان می‌شه از سایت ایبوک‌ها تهیه‌ش کرد.
اگه از این کتاب استقبال بشه تو فرصتی بیشتر یه راهنمای جامع در مورد استاندارد می‌نویسم.
تعریف مدیر پروژه تو نسخه جدید PMBOK تغییری کرده که خیلی جالب و قابل توجهه.
مدیر پروژه تو نسخه چهارم اینطوری تعریف شده بود:
The project manager is the person assigned by the performing organization to achieve the project objectives
مدیر پروژه کسیه که از طرف سازمان انجام دهنده پروژه برای تحقق اهداف پروژه منصوب می‌شه.
و الان چنین تعریفی جای اون رو گرفته:
The project manager is the person assigned by the performing organization to lead the team that is responsible for achieving the project objectives
مدیر پروژه کسیه که از طرف سازمان انجام دهنده پروژه برای رهبری تیمی که مسئول تحقق اهداف پروژه هست منصوب می‌شه.
قبلا مدیر پروژه کسی بود که مسئول تحقق اهداف پروژه بود، یعنی تکمیل پروژه در قالب گستره، زمان، هزینه، کیفیت، و … مشخص شده. حالا این آدم تو پروژه‌هایی که خیلی کوچیک نباشن افرادی رو به کمک می‌گیره که اسمشون رو می‌ذاریم تیم مدیریت پروژه.
الان پم‌باک وزن بیشتری به تیم مدیریت پروژه می‌ده و ترجیح می‌ده به جای این‌که اقدامات مدیریت پروژه رو به عهده مدیر پروژه بذاره و بهش اجازه بده که اونها رو به تیم منتقل کنه، اونها رو مستقیما وظیفه تیم مدیریت پروژه می‌دونه و مدیر پروژه رو صرفا مسئول رهبری اون تیم معرفی می‌کنه. البته شکی نیست که اگه پروژه کوچیک باشه تیم مدیریت پروژه خلاصه می‌شه تو مدیر …