روند پذیرفته شده برای بررسی توجیه‌پذیری پروژه چنین چیزیه:
اولین کار اینه که توجیه‌پذیری پروژه رو خیلی کلی و ساده بررسی کنیم؛ مثلا تو یه هفته. این اطلاعات رو همراه با خیلی چیزهای دیگه تو پیش‌نویس منشور پروژه می‌ذاریم.
منشور پروژه بررسی می‌شه و اگه تایید بشه پروژه رسما شروع می‌شه.
بعد از شروع پروژه خیلی دقیق و کامل توجیه‌پذیری پروژه رو مطالعه می‌کنیم و تمام برنامه‌ریزی‌های پروژه (زمان‌بندی، برنامه‌ریزی هزینه، ریسک‌ها، تدارکات و …) رو هم انجام می‌دیم. دلیلش اینه که هیچوقت نمی‌شه یه توجیه‌پذیری دقیق تهیه کرد، مگر این‌که پروژه برنامه‌ریزی شده باشه.
توجیه‌پذیری پروژه همراه با برنامه‌ها بررسی می‌شن و تصمیم می‌گیریم که کار اجرایی پروژه رو شروع کنیم یا نه.
این ترکیب رو می‌شه با چرخه حیات‌های مختلف پیاده‌سازی کرد. مثلا می‌شه کار اجرایی و مطالعات تو دو پروژه متفاوت باشن، می‌تونن دو فاز از یه پروژه باشن، یا حتی دو مرحله از یه پروژه خیلی ساده؛ ولی به هر حال بهتره روندی که گفته شد تو چرخه حیات وجود داشته باشه.
دلیل این‌که مطالعه توجیه‌پذیری رو دو قسمت می‌کنیم اینه که مطالعه دقیق توجیه‌پذیری کار پر هزینه‌ایه. به جای این‌که هر ایده‌ای به نظرمون می‌رسه دو سه ماه براش وقت بذاریم ببینیم بهتره انجامش بدیم یا نه، برای هر کدوم مثلا یه هفته وقت می‌ذاریم، اگه نتیجه اون یه هفته مثبت بود اونوقت مطالعه …
یه پروژه کوچیک رو فرض کنین؛ مثلا قراره تو شرکت یه نرم‌افزار مدیریت اسناد راه‌اندازی کنین. ماجرا اینه که مدیر عامل و مدیرای ارشد شرکت جلسه‌ای دارن و دارن به این فکر می‌کنن که این کار رو انجام بدن یا نه. در نهایت دسته‌جمعی به این نتیجه می‌رسن که این کار به نفع شرکته و بهتره انجام بشه. مدیر عامل از مدیرهای ارشد شرکت می‌پرسه که چه کسی حاضره مسئولیت این کار رو به عهده بگیره و یکی از اون‌ها این مسئولیت رو قبول می‌کنه. اون مدیر ارشد و مدیر عامل بلند می‌شن، با هم دست می‌دن و مدیر عامل ضمن این‌که ازش تشکر می‌کنه براش آرزوی موفقیت هم می‌کنه.
الان اینجا چه اتفاق‌هایی افتاد؟
اول این‌که پروژه به عهده یه مدیر ارشد گذاشته شد. این به این معنی نیست که اون آدم مدیر پروژه می‌شه؛ نه، اون می‌شه مالک پروژه. دلیلش هم اینه که هر پروژه‌ای نیاز نفوذ و قدرت یه مدیر ارشد داره. تو پم‌باک به این آدم می‌گن Sponsor (حامی پروژه) و تو پرینس۲ بهش می‌گن Executive.
اون جایی که تو جلسه بحث نرم‌افزار پیش کشیده شد و بررسی پروژه رو شروع کردن هم می‌شه project mandate (جرقه پروژه).
مرحله بعدی اینه که اون مدیر ارشد باید مدیر پروژه انتخاب کنه. مثلا می‌ره با مسئول واحد IT، مسئول واحد کنترل پروژه، مسئول دبیرخونه یا کس دیگه‌ای صحبت می‌کنه و توافق می‌کنن. از حالا به بعد اون آدم می‌شه مدیر پروژه.
قبل از هر چیز باید تجربه به دست بیارین، تجربه دقیق، هدایت شده، واقعی و موثر. حالا چطوری می‌شه کسی که مدیر پروژه نیست تجربه مدیریت پروژه به دست بیاره؟ خیلی ساده‌س، با به عهده گرفتن کارهایی که به مدیریت پروژه نزدیکن، همکاری موثر با مدیر پروژه، به عهده گرفتن مسئولیت، دقیق شدن تو کارها و تصمیم‌ها و حرفای مدیر پروژه‌ها و پیگیری و تحلیل کردن اون‌ها.
بعضی شغل‌هایی که می‌تونین داشته باشین تا مدیریت پروژه رو به خوبی درک کنین این‌ها هستن:
برنامه‌ریزی و کنترل پروژه – برنامه‌ریزی و کنترل پروژه جزئی از مدیریت پروژه‌س و کسی که این مسئولیت رو داره باید خیلی به مدیر پروژه نزدیک باشه. البته متاسفانه چون خیلی وقت‌ها سیستم‌های برنامه‌ریزی و کنترل پروژه تو ایران صوری هستن و کار موثری انجام نمی‌دن، ارتباط کافی هم با مدیر پروژه ندارن. پس اگه می‌خواین از طریق این کار تجربه مدیریت پروژه به دست بیارین حتما مطمئن بشین که امکانش رو دارین که ارتباط کافی برقرار کنین. بعضی وقت‌ها این …
وقتی برنامه جبرانی تهیه می‌کنیم چه اتفاقی برای ارزیابی عملکرد می‌افته؟
قبل از جواب دادن به این سوال باید به سوال خیلی مهم‌ترین جواب داد: اصلا چرا برنامه جبرانی تهیه می‌کنیم؟
ماجرا اینه که تو هر پروژه باید به نوعی حدود رواداری در نظر گرفت. مثلا پروژه (یا مرحله‌ای از پروژه) قراره تو شش ماه با حداکثر سه هفته رواداری تموم بشه، با هزار تومن هزینه و رواداری صد تومن. این می‌شه ساده‌ترین حالت تعریف بودجه و رواداری پروژه (بودجه هم به پولی گفته می‌شه که برای اون کار کنار گذاشته شده و هم زمانی که براش در نظر گرفته شده). حالا وقتی کار داره پیش می‌ره دایما تاریخ پایان پروژه (یا مرحله) و هزینه تخمینی زمان پایان اون رو محاسبه می‌کنیم و اگه اون حدود رواداری رو رد کنه، وقت تهیه برنامه جبرانی می‌شه که اصلاحا به اون رویداد می‌گیم 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 مربوط می‌شده؛ که البته بخشی از اون تغییرها هم تو کتاب تاثیر خاصی ندارن، چون کتاب وارد خیلی از جزئیات نمی‌شه.