خیلی‌ها که در حال آماده شدن برای آزمون PMP بودن نگرانن که با اومدن نسخه پنجم استاندارد پم‌باک چه اتفاقی برای آزمون می‌افته.
نسخه نهایی پم‌باک ۵ قراره که در آخر سال ۲۰۱۲ ارائه بشه و بعد از اون هم کمی بیشتر از ۶ ماه طول می‌کشه که آزمون PMP تغییر کنه. در نتیجه اگه می‌خواین قبل از نیمه سال ۲۰۱۳ امتحان بدین، نیازی نیست که کاری به نسخه پنجم داشته باشین.
دیروز ایمیلی از PMI دریافت کردم که گفته بود بررسی نظراتی که در مورد پیش‌نویس نسخه پنجم پم‌باک داده شده بود تموم شده. الان تصمیم‌هایی که به ازای هرکدوم از نظرات گرفته شده برای افراد فرستاده شده و یه مدتی هم وقت هست که اگه کسی خواست اعتراض بده.
نظرهایی که من داده بودم هم اکثرا با کمی تا قسمتی تغییر اعمال شده بودن (البته دوتاشون هم رد شده بودن)، ولی آیتمی که برام از همه مهم‌تر بود به نسخه بعدی موکول شده. ظاهرا به نظرشون اعمال کردنش نیاز به تغییرات عمده‌ای داره. موردی که می‌گم در مورد فرآیند Develop Schedule هست که به نظر من منطقیه که به جای Schedule روی Schedule Model متمرکز بشه و علاوه بر تغییر توضیحات فرآیند، اسمش هم به Develop Schedule Model تبدیل بشه. این تغییر با تمایزی که PMI بین زمان‌بندی و مدل زمان‌بندی قایله و تمایز خیلی کاربردی و مهمی هم هست مطابقه.
به‌روزرسانی: الان بعد از ۸ سال باز هم وقت بررسی نظرات در مورد نسخه جدید پم‌باکه، ولی این بار خودم جزو تیم تالیف هستم و از کسایی که نظرها رو بررسی می‌کنن :)
اگه کنجکاو باشین، نظری که در مورد اون تغییر داشتم رو هنوز هم دارم، ولی در نسخه فعلی که مسئولیت داشتم فرآیندها دیگه از بخش اصلی پم‌باک خارج شدن و ما کاری بهشون نداشتیم. در نتیجه، این نظر هیچوقت اعمال نشد!
خیلی از استانداردها و منابعی که در مورد زمان‌بندی نوشته شدن درباره شناوری‌های زیاد از حد نوشتن. این‌که شناوری‌ها نباید از حدی بیشتر باشه یکی از ۱۹ قاعده‌ایه که تو کتاب قواعد زمان‌بندی پروژه هم توضیح دادم.
بعد از انتشار کتاب، خیلی از خواننده‌های ایرانی و تعدادی از خواننده‌های غیر ایرانی از من درباره‌ش سوال کردن و به این نتیجه رسیدم که توضیحات بیشتری به ویرایش بعدی کتاب اضافه کنم؛ ولی تا اون زمان این مطلب رو نوشتم که برای همه توضیح داده باشم.
زیاد بودن شناوری به خودی خود هیچ مشکلی ایجاد نمی‌کنه. شناوری‌های زیاد از حد دلیل ایجاد مشکل نیستن، ولی نشونه‌ایه که به ما می‌گه احتمالا جای دیگه‌ای مشکلی وجود داره. مثل این می‌مونه که یه دکتر مثلا نشونه‌ای رو روی ناخن شما ببینه و مشکوک بشه. اون نشونه روی ناخن به خودی خود مشکلی برای شما ایجاد نمی‌کنه (مگر این‌که خیلی حساس به ظاهرتون باشین)، ولی ممکنه جای دیگه‌ای مشکل مهمی داشته باشین و به همین خاطر باید ماجرا رو بررسی کرد.
طبیعت اکثر پروژه‌ها اینه که فعالیت‌هاشون در عمل شناوری‌های خیلی زیاد ندارن و اگه داشته باشن هم تعدادشون از حدی بیشتر نمی‌شه. به همین خاطر انتظار داریم که فعالیت‌های برنامه هم همینطور باشن. اگه نباشن، باید شک کنیم و برنامه رو یه چک آپ کامل بکنیم. شاید واقعا طبیعت پروژه اینطور باشه و در این صورت نیازی نیست که چیزی رو اصلاح کنیم؛ …
خواننده‌های فارسی زبان از کتاب قواعد زمان‌بندی پروژه خیلی خوب استقبال کردن، ولی نکته مهم در اینه که استقبال خواننده‌های انگلیسی زبان به مراتب بیشتر بوده و به همین خاطر می‌خوام پیشنهاد کنم که اگه هنوز این کتاب رو مطالعه نکردین، حتما نگاهی بهش بندازین. نسخه فارسی رو می‌تونین از اینجا و نسخه رایگان انگلیسی رو از اینجا تهیه کنین. البته این دو نسخه دقیقا مشابه هم نیستن؛ توصیه‌هایی بومی که برای خواننده‌های ایرانی لازم بودن رو تو نسخه انگلیسی حذف کردم.
گذشته از وجود چند هزار نفری که نسخه انگلیسی رو دریافت کردن، چندین موسسه مدیریت پروژه با دریافت مجوز اون رو از طریق خبرنامه‌هاشون در اختیار مشتری‌هاشون گذاشتن، به دو نسخه پرتقالی و روسی ترجمه شده، یک مدرس مدیریت پروژه اون رو در آمریکا تدریس می‌کنه و تا حالا مجموعا ۸۰۰ پیام تشکر به دستم رسیده (بیشتر از پیام‌های تشکری که تو ده سال گذشته بابت کتاب‌های فارسیم گرفتم).
سیستم‌های مدیریت پروژه کلاسیک، مشابه اون چیزی که تو پم‌باک و پرینس۲ توضیح داده می‌شه، طوری طراحی شدن که برای همه نوع پروژه قابل استفاده باشن. با این حال پروژه‌های نرم‌افزاری تفاوت‌هایی با پروژه‌های دیگه دارن و احساس می‌شه که سیستم‌های کلاسیک برای مدیریت اون‌ها به اندازه کافی موفق نیستن. تلاش‌هایی که تو این زمینه شده، منجر شده به تدوین گروهی از سیستم‌های مدیریت پروژه مدرن که عموما تم و رویکرد مشابهی دارن و به همشون Agile (چابک) گفته می‌شه. موفق‌ترین و پر استفاده‌ترین سیستم اجایل هم Scrum (اسکرام) هست.
حالا بریم سراغ تفاوت‌های پروژه‌های نرم‌افزاری و غیر نرم‌افزاری. دلیل ریشه‌ای که باعث ایجاد این تفاوت شده، تغییرات خیلی زیاد تو پروژه‌های نرم‌افزاریه. مثلا وقتی یه پروژه ساخت کارخونه، بیمارستان یا راه دارین، از اول پروژه تعریف می‌شه و معمولا تا آخر کار تغییرات زیادی نمی‌کنه؛ ولی پروژه نرم‌افزاری اینطوری نیست. مشتری نرم‌افزاری رو سفارش می‌ده و به هر شکلی که هست محصول تعریف می‌شه، ولی با جلو رفتن کار انقدر نظرش عوض می‌شه و با دیدن قسمت‌های انجام شده انقدر ایده‌های جدید به نظرش میاد یا چیزهایی که از قلم افتادن یادش می‌افته، که عملا محصولی که در آخر کار به وجود میاد ربطی به محصولی که از اول تصور کرده بودیم نداره.
حالا چه دلیلی وجود داره که کسایی مثل من که تو پروژه‌های غیر نرم‌افزاری کار …
برنامه فعلی من تالیف تعدادی کتاب کاملا تخصصی در مورد پریماوراس و الان اولین جلد از این مجموعه کتاب، با عنوان ساختار مقادیر پیشرفت در Primavera P6 منتشر شد.
این کتاب شیوه محاسبه پیشرفت برنامه‌ریزی شده و واقعی رو به طور کامل تو پریماورا توضیح می‌ده. مفهوم و نوع ارتباطی که بین فیلدهایی مثل Schedule % Complete، Performance % Complete، Duration % Complete، Units % Complete و Physical % Complete هست رو به تفصیل آموزش می‌ده.
این کتاب زمینه کاملی فراهم می‌کنه تا دو مبحث مهم دیگه تو جلدهای بعدی آموزش داده بشن؛ یکی محاسبه پیشرفت فیزیکی (به سبک ایرانیش) و دیگری ارتباط بین مقادیر مدت زمان، کار و تخصیص.
می‌تونین برای تهیه کتاب به ایبوک‌های مدیریت پروژه مراجعه کنید.
کتاب الکترونیکی جدیدم، راهنمای تدوین گزارشهای پیشرفت پروژه منتشر شد.
تو این کتاب ۲۱ نوع از رایج‌ترین محتوایی که تو گزارشهای پیشرفت پروژه کاربرد داره معرفی شده، برای هرکدوم یک یا چند شیوه ارائه پیشنهاد شده و در نهایت به اینجا ختم می‌شه که با انتخاب انواع محتوا و شیوه نمایش، گزارش یا گزارشهای پیشرفت پروژه رو تهیه کنیم.
کتاب پیوستی هم داره که تکنیک‌های پیشرفته ترسیم نمودار رو تو اکسل توضیح می‌ده.
نظرتون در مورد این جدول چیه؟
وقتی تعداد ستون‌های جدول زیاد باشه، دنبال کردن مقادیری که تو یه ردیف هستن خیلی سخت می‌شه. یه راه حل که بعضی‌ها استفاده می‌کنن، اینه که ردیف‌ها رو به تناوب پس‌زمینه می‌دن تا بشه اون‌ها رو دنبال کرد. اینطوری:
یه مقدار بهتر می‌شه. ولی چیزی که می‌خوام بگم، اینه که بهتره اینجور مواقع ردیف‌ها رو یکی در میون رنگی نکنین، اون‌ها رو دوتا در میون رنگی کنین:
به نظر شما اینطوری دنبال کردن ردیف‌ها راحت‌تر نیست؟ تعداد ردیف‌های رنگی کمتره و فاصله‌شون با هم بیشتره، در نتیجه ردیف‌های رنگی رو راحت‌تر می‌شه دنبال کرد. ردیف‌های غیر رنگی هم دو دسته هستن، اون‌هایی که زیرشون ردیف رنگی هست و اون‌هایی که بالاشون ردیف رنگی هست و با همین قاعده ناخودآگاه به راحتی می‌شه دنبالشون کرد.
می‌شه به جای رنگی کردن پس‌زمینه خط‌های افقی پررنگ‌تر بذارین:
الان ردیف‌ها تو ناخودآگاه بیننده سه گروه می‌شن: اون‌هایی که وسط هستن، اون‌هایی که بالاشون خط پهن هست و اون‌هایی که پایینشون خط پهن هست.
هر دو حالت رو می‌تونین به جای این‌که دستی قالب‌بندی کنین، با conditional formatting بسازین.
و یه نکته دیگه؛ می‌دونین که می‌شه جدول و نمودار گانت پراجکت رو تو نسخه ۲۰۰۷ و جدیدتر از اون به همین شکل قالب‌بندی کرد؟
به هر حال، هر کاری می‌کنین بکنین، فقط یه همچین چیزی نسازین:
زیاد پیش میاد که در زمان برنامه‌ریزی اولیه پروژه، یا بعدا در زمان اجرا، لازم باشه که برنامه رو تغییر بدین تا مدتش کمتر یا بیشتر بشه. معمولا دغدغه اصلی کم کردن مدت زمانه، ولی گاهی هم لازمه که بیشترش کرد.
در هر حال، برای خیلی‌ها سواله که چطوری می‌شه این کار رو کرد؛ مثلا مدت زمان فعالیت‌ها رو تو ضریبی ضرب کرد، منابع رو به شیوه خاصی تغییر داد یا …
جواب هیچکدوم از این‌ها نیست. افزایش یا کاهش مدت زمان پروژه تحت شرایط معمولی، اصلا کاری صرفا ریاضی نیست که به تنهایی انجامش بدین. باید شما، همراه با مدیر پروژه و سایر افراد کلیدی پروژه بشینین و تو زمان‌ها، روابط و منابع تجدید نظر کنین؛ یعنی همون کاری که قراره در زمان برنامه‌ریزی اولیه هم انجام داده باشینش.
تو این فرآیند کمک‌های تخصصی زیادی می‌تونین به تیم بکنین. مثلا اگه قراره مدت زمان کوتاه بشه، باید تیم رو هدایت کنین تا متمرکز بشه روی فعالیت‌های بحرانی و نزدیک به بحرانی و اگه قراره تو تعداد منابع تجدید نظر کنین، می‌تونین با کمی تجربه با نگاه کردن به هیستوگرام‌های منابع حدس بزنین که کدوم‌ها تاثیرگذارتر هستن و با چند بار آزمایش و خطا مسیر مناسب رو به تیم نشون بدین. ولی در هر حال، این کار بدون مشارکت تیم پروژه اصلا درست نیست.
چیزایی که گفتم برای وقتیه که واقعا بخواین برنامه‌ریزی کنین، نه این‌که ماجرا صوری باشه.
طبق نظرسنجی سایت ایبوک‌هام، کتاب راهنمای تدوین گزارشهای پیشرفت پروژه پرطرفدارترین کتاب بین کتاب‌هایی بود که برای آینده در نظر داشتم. به همین خاطر تالیف این کتاب رو شروع کردم و تا الان متن اصلی کتاب تموم شده و چیزی که باقی مونده، چند نمونه گزارش پیشرفت فرضیه که تو پیوست‌هاش قرار می‌گیره.
تو این کتاب گزارشهای پیشرفت پروژه به این شکل بررسی می‌شن که باید اول انواع محتوایی که قراره گزارش بشه رو انتخاب کنیم (پیشرفت تجمعی، پیشرفت دوره‌ای، تاخیر، عملکرد مالی، آمار نیروی انسانی و …) و بعد یک یا چند شیوه نمایش برای اون‌ها انتخاب کنیم. با ترکیب‌های مختلف این شیوه‌های نمایش انواع گزارشهای پروژه به وجود میان.
تو این کتاب انواع محتوایی که برای گزارشهای پیشرفت رایج هست رو فهرست کردم، درباره بایدها و نبایدهاشون صحبت کردم و در نهایت برای هرکدوم یک یا چند شیوه نمایشی ارائه کردم. در آخر درباره ترکیب و تدوین گزارش‌ها بر اساس این عناصر صحبت کردم و این‌که چطور باید گزارشهای مناسب برای هر گروه از ذی‌نفعان رو تولید کرد. چون فکر می‌کنم که هیچ چیزی جای نمونه‌های کامل رو نمی‌گیره، از هرکدوم از سه نوع گزارش کلی‌ای که توضیح دادم هم یکی تو پیوست ارائه می‌کنم.
این کتاب تا قبل از نوروز به صورت ایبوک ارائه خواهد شد.
برای خیلی از کسانی که پروژه‌هاشون فهرست بهاییه این سوال پیش میاد که می‌شه ساختار شکست کار رو با فهرست بها منطبق کرد یا نه و اگه می‌شه، چطوری.
جوابش از نظر من منفیه؛ ساختار شکست کار و فهرست بها دو مقوله کاملا متفاوت هستن و نمی‌شه اون‌ها رو با هم ترکیب کرد.
اگه ایبوک رایگان راهنمای تدوین ساختار شکست کار رو مطالعه کرده باشین، می‌دونین که یه نکته خیلی مهم در مورد ساختار شکست کار اینه که محصول محور باشه؛ این در حالیه که فهرست بها کاملا کار محوره.
اگه بخواین ارتباط موثری بین فهرست بها و برنامه‌هاتون برقرار کنین (که خیلی هم خوب هست)، راهش اینه که آیتم‌های فهرست بها رو به عنوان منبع برای فعالیت‌ها وارد کنین. ترکیب خیلی خوب و موثری به وجود میاد که اصولی هم هست.
امروز ظهر پیش‌نویس نسخه پنجم استاندارد مدیریت پروژه PMBOK منتشر شد.
از این مرحله به بعد نظر افراد گردآوری می‌شه و بعد از اون ویرایش نهایی نسخه پنجم در پایان سال ۲۰۱۲ میلادی منتشر می‌شه.
تغییرات این نسخه نه خیلی زیاد بود و نه خیلی کم. مهم‌ترین ماجرا اینه که حوزه‌های دانش از ۹ حوزه به ۱۰ حوزه تبدیل شدن. حوزه جدید «مدیریت ذی‌نفعان پروژه» است.
اگه با پم‌باک آشنا باشین می‌دونین مدیریت ذی‌نفعان قبلا هم وجود داشت و زیرمجموعه‌ای از مدیریت ارتباطات بود. تو این نسخه استاندارد هم مدیریت ارتباطات و هم مدیریت ذی‌نفعان کمی تفصیلی‌تر شدن و هم این‌که از هم جدا شدن.
در مورد اکثر تغییرات این نسخه باید در نظر داشته باشین که مطلب جدیدی اضافه نشده، بلکه عمدتا ساختار عوض شده. قبلا ۴۲ فرآیند وجود داشت که انواعی از کارها و مهارت‌ها رو تو خودشون جا داده بودن. این مهارت‌ها و کارها الان با کمی تغییر در قالب ۴۷ فرآیند ارائه شده.
| نسخه چهارم | نسخه پنجم | |
|---|---|---|
| فرآیندها | ۴۲ | ۴۷ |
| گروه‌های فرآیندی | ۵ | ۵ |
| حوزه‌های دانش | ۹ | ۱۰ |
اگه کتاب پم‌باک به زبان ساده رو خونده باشین، دیدین که تاکید زیادی روی تفکیک برنامه‌ریزی به دو سرفصل برنامه‌ریزی مدیریتی و برنامه‌ریزی کاری داشتم. برنامه‌ریزی مدیریتی شیوه برنامه‌ریزی کاری و شیوه کنترل کارها رو مشخص می‌کنه.
تو پم‌باک ۱۲ برنامه مدیریتی وجود داره که در نهایت همراه …
کتاب جدیدم به صورت الکترونیکی منتشر شد: قواعد زمان‌بندی پروژه
این کتاب مجموعه‌ایه از ۱۹ قاعده که از استانداردها و آیین‌نامه‌های PMI و وزارت دفاع آمریکا استخراج شدن. رعایت اون‌ها کیفیت برنامه‌های زمان‌بندی رو به طور چشمگیری افزایش می‌ده.
رعایت بعضی از این قواعد خیلی ساده‌س و اعتراف می‌کنم که رعایت بعضی‌هاشون هم خیلی مشکله؛ ولی ارزشش رو داره.
حداقل هفته‌ای یک دو نفر به من ایمیل می‌دن تا صحبت کنیم و بین گرفتن مدرک PMP و فوق لیسانس یکی رو انتخاب کنن.
سوال اصلی اینه که کدوم یکی از این دو مفیدتره.
این‌که کدوم مفیدتره از فردی به فرد دیگه فرق می‌کنه، من فقط یه سری از مبانی تصمیم‌گیری که مشترک هست رو می‌گم.
گرفتن مدرک PMP به نظر من کمتر وقت می‌بره. فکر می‌کنم اکثر افراد با ۱۰۰ تا ۳۰۰ ساعت مطالعه یا آموزش می‌تونن می‌تونن موفق بشن، ولی برای گرفتن فوق لیسانس مدت زمان کلاس‌ها و مدت زمانی که صرف رفت و آمد به دانشگاه می‌شه از این مقدار بیشتره.
برای مدرک PMP باید حدود ۵۰۰ دلار برای آزمون هزینه کنین و یه مقداری هم برای سفر به امارات، ترکیه یا کشورهای دیگه. می‌شه حدود ۱۰۰۰ دلار. البته کسایی که ترجیح می‌دن کلاس برن یا پکیج‌های امتحانی بگیرن یه مقدار بیشتر باید هزینه کنن.
این هزینه مجموعا از هزینه فوق لیسانس‌هایی که رایگان نباشن (دوره‌های شبانه، دوره‌های مدیریت صنعتی و …) ارزون‌تر و از فوق لیسانس‌های رایگان گرون‌تره.
حالا نمی‌دونم کلا هزینه براتون چقدر اهمیت داره.
سختی هرکدوم از این دوتا یه جوره. برای من گرفتن یه فوق لیسانس خیلی سخت‌تر از مدرک PMP هست، چون برای اولی باید خیلی چیزهای متنوعی بخونم، بین اون‌ها حتما چیزهایی هست که خیلی نپسندمشون و در این صورت خوندنشون برام خیلی سخت می‌شه. با این حال سخت‌گیری تو …
ظاهرا فعالیت جدی و برنامه‌ریزی شده تیم PMI برای تهیه نسخه جدید (پنجم) استاندارد پم‌باک شروع شده. احتمالا پیش‌نویسش تا اواسط سال ۱۰۱۲ و نسخه نهاییش تا آخر سال ۲۰۱۲ منتشر می‌شه.
صحبت‌های فعلی درباره اینه که احتمالا نوع و تعداد فرآیندها تغییر چندانی نمی‌کنه و احتمالا گرایش‌های مدرن مثل سیستم‌های Agile هم تا حدی وارد استاندارد می‌شن.
این دومی خودش خبر جالبیه؛ پم‌باک بهترین نمود سیستم‌های مدیریت پروژه کلاسیکه که در مقابل شیوه‌های جدید (چابک، اجایل) قرار می‌گیره. من همیشه این ایده رو داشتم که باید سنتزی بین این دو نوع سیستم به وجود بیاد. حالا خیلی‌ها امیدوارن که این سنتز به صورت تدریجی و قدم به قدم تو استاندارد پم‌باک انجام بشه.
الان یکی از اهداف بزرگ من اینه که بتونم تیم مرکزی بازنگری رو قانع کنم که سهم بالاتری به تمایز زمان‌بندی و مدل زمان‌بندی بدن. به عنوان مثال فرآیندی که الان اسمش «تهیه زمان‌بندی» هست، اصولا باید «تهیه مدل زمان‌بندی» باشه و این تمایز باید تو متن راهنمای اون فرآیند هم منعکس بشه.
در هر حال، امیدوارم نسخه بعدی استاندارد تو این حوزه قوی‌تر بشه.
به‌روزرسانی: لطفا توجه کنین که این مطلب در مورد نسخه قدیمی پم‌باک هست. به زودی مطلب جدیدی برای معرفی پم‌باک بر اساس نسخه هفتم خواهم نوشت.
پم‌باک معروف‌ترین استاندارد جهانی در مدیریت پروژه است و رایج‌ترین معیار برای شکل‌دهی و ارزیابی سیستم‌های مدیریت پروژه به شمار می‌رود. بسیاری از رایج‌ترین تعاریف، اصطلاح‌ها و طبقه‌بندی‌هایی که امروزه در مدیریت پروژه به کار می‌روند از این استاندارد برداشت شده‌اند. به عبارت دیگر، پم‌باک زبان مشترکی جهانی در مدیریت پروژه است. عبارت پم‌باک (PMBOK) مخفف Project Management Body Of Knowledge است و در فارسی به گستره دانش مدیریت پروژه، پیکره دانش مدیریت پروژه یا به صورت ساده‌تر به دانش مدیریت پروژه ترجمه شده است. منظور از Body Of Knowledge مجموعه‌ای جامع از اطلاعات و مهارت‌هاست که یک حرفه را شکل می‌دهند.
پم‌باک را موسسه‌ای بین‌المللی و غیر انتفاعی با نام موسسه مدیریت پروژه (PMI) تدوین کرده است. این استاندارد با تلاش گروه بسیار بزرگی از دست‌اندرکاران مدیریت پروژه گردآوری شده و مبنای تدوین آن نیز الگوهای موفق و تجربه‌های این اشخاص بوده است و نه تئوری محض.
اولین پیش‌نویس استاندارد در سال ۱۹۸۷ تهیه شد و نسخه‌های مختلف آن در سال‌های بعد منتشر شدند. آخرین نسخه آن، یعنی نسخه ۴، در اواخر سال ۲۰۰۸ منتشر گردید.
استاندارد پم‌باک ۴۲ فرآیند …