شاید اسم ICB رو شنیده باشین؛ ICB یه مبنای شایستگی برای مدیریت پروژه‌س، که ممکنه بعضی‌ها بهش بگن استاندارد مدیریت پروژه (زیاد اصطلاح درستی نیست).
ICB مخفف اینه: IPMA Competence Baseline
و همونطوری که از اسمش هم پیداس، مالک و مولفش IPMA (انجمن بین‌المللی مدیریت پروژه، International Project Management Association) هست.
ICB مجموعه‌ای از ۴۶ عامله که برای شایستگی مدیران پروژه‌ها لازمه. این عوامل تو سه گروه دسته‌بندی شدن:
Technical Competences (شایستگی‌های فنی) – این گروه شامل ۲۰ عامله که همگی از جنس فرآیندهایی هستن که تو PMBOK توضیح داده می‌شه.
Behavioural Competences (شایستگی‌های رفتاری) – این گروه شامل ۱۵ عامل رفتاریه؛ ویژگی‌های رفتاری، اخلاقی و شخصیتی لازم برای مدیریت پروژه.
Contectual Competences (شایستگی‌های مربوط به شرایط محیطی پروژه) – این گروه شامل ۱۱ عامله که همگی برای هماهنگ شدن اقدامات پروژه با بستری که توش قرار داره انجام می‌شه. مسایل حقوقی، مالی، منابع انسانی، سازمانی و … این‌ها همگی عواملی هستن که هیچکدوم به طور کامل داخل پروژه قرار نمی‌گیرن و در عین حال فضای پروژه رو شکل می‌دن.
به‌روزرسانی: ساختار و دسته‌بندی شایستگی‌ها تو نسخه‌های جدید فرق کرده.
یه سوال رایج در مورد تاخیرهای مجاز اینه که وقتی هم پیمانکار و هم کارفرما تو بازه‌ای مشابه تاخیر دارن، آیا باید اون تاخیر رو مجاز حساب کرد یا نه. کسایی هم که با مجاز در نظر گرفتنش موافق نیستن عموما به این فکر می‌کنن که اگه کارفرما تاخیری ایجاد نکرده بود، باز هم چیزی تغییر نمی‌کرد و تو همون بازه تاخیرهای دیگه‌ای به خاطر پیمانکار به وجود می‌اومد.
وقتی تاخیر تو بازه‌ای خاص هم به دلیلی از طرف کارفرما برگرده و هم به دلیلی از طرف پیمانکار، یکی از این دو روش استفاده می‌شه:
روش کمابیش رایج‌تر: تاخیر به نفع پیمانکار محاسبه می‌شه، یعنی حق ادعای زمانی برای پیمانکار محفوظه. با این حال حق ادعای مالی اون دوره از پیمانکار گرفته می‌شه.
روش کمتر رایج: پیمانکار و کارفرما تو تاخیر شریک دونسته می‌شن و بر اساس معیارهای مختلف سهم اون‌ها رو تو تاخیر در نظر می‌گیرن. به این ترتیب قسمتی از حق پیمانکار در مورد اون تاخیر (مثلا نصفش) محفوظ می‌مونه، با این حال می‌تونه به اندازه همون سهم ادعای مالی هم داشته باشه.
منظورم از ادعای مالی هم اینه که پیمانکار بعدا claim کنه که به ازای تاخیر مجازی که ایجاد شده علاوه بر این‌که به زمانش اضافه می‌شه، فلان مقدار هم خسارت خرده و کارفرما باید بهش پرداخت کنه.
کلا هم به ندرت می‌شه که اون زمان رو کلا تاخیر پیمانکار در نظر نگیرن. با توجه به این‌که تو ایران پیمانکارها معمولا تو …
خیلی‌ها از من می‌پرسن که روش‌های متفاوتی برای محاسبه تاخیر مجاز وجود داره یا نه. برای همین اینجا به روش‌ها اشاره می‌کنم. البته الان دارم یه ایبوک درباره محاسبه تاخیر مجاز می‌نویسم که اون هم به زودی تموم می‌شه.
شیوه محاسبه تاخیر مجاز رو همیشه می‌شه تو یکی از این چهار گروه قرار داد:
روش‌های سرانگشتی: تو این روش‌ها یا از برنامه زمان‌بندی استفاده نمی‌شه، یا اگر هم بشه خیلی استفاده محدودیه و جنبه محاسباتی نداره. می‌شه با اصلاحات پم‌باک اینطوری گفت که به جای «مدل زمان‌بندی» از «زمان‌بندی» استفاده می‌کنه. روش‌های این خانواده خیلی تنوع دارن و خیلی‌هاشون هم ابتکاری هستن. از این روش‌ها عموما قدیم استفاده می‌شد که نرم‌افزارهای برنامه‌ریزی وجود نداشتن و نمی‌شد محاسبات کامل‌تر و پیچیده‌تر رو انجام داد. الان دیگه زیاد پذیرفته شده نیست که اینطوری تاخیرها رو محاسبه کنین.
روش‌های افزاینده با الگوی ثابت: این همون روشیه که معمولا استفاده می‌کنیم. عوامل تاخیر رو به نسخه اولیه برنامه زمان‌بندی اضافه می‌کنیم و نگاه می‌کنیم که ببینیم تاریخ پایان چقدر عوض شده. مقداری که عوض شده باشه می‌شه تاخیر مجاز. امتیاز این روش به اینه که اطلاعات ورودی خیلی کمی می‌خواد و اگه برنامه زمان‌بندی هم درست و حسابی باشه دوباره کاری برای تهیه برنامه نداریم.
روش‌های کاهنده با الگوی ثابت: تو این روش کار یه مقدار برعکسه. به جای …
این مطلب روند برنامه‌ریزی رو تو حالت پیش‌فرض، حالتی که پروژه چند فاز داره و همینطور حالتی که مجبوریم از rolling wave planning استفاده کنیم، بر اساس رویکرد پم‌باک، توضیح می‌ده.
چند وقت پیش قراردادی با انتشارات بریتانیایی ونتوس (bookboon) بسته بودم که براشون کتابی درباره استاندارد پم‌باک به زبان ساده تالیف کنم. این کتاب چند ساعت پیش به صورت الکترونیکی منتشر شد و اگه مایل باشین می‌تونین اون رو به رایگان از اینجا دریافت کنین.
اول قصد داشتم کتاب رو از ایبوک فارسی‌ای که قبلا با نام PMBOK به زبان ساده منتشر کرده بودم به انگلیسی برگردونم. با این حال بعد از تالیف اون کتاب ایده‌های جدیدی برای مفهومی‌تر کردن موضوع به ذهنم رسیده بود و به همین خاطر کتاب رو از اول نوشتم و فکر می‌کنم الان بیشتر از قبل به هدف اصلیم نزدیک شدم. هدف اصلی تو هر دو کتاب اینه که خواننده با ایده‌های محوری و گرایش و مفهوم استاندارد آشنا بشه، نه این‌که با حجم زیادی اطلاعات گسسته که به نظر خشک و حتی حفظ کردنی میان روبرو بشه.
بالاخره نسخه بتای پراجکت ۲۰۱۳ هم اومد و کسایی که علاقه‌مند باشن می‌تونن از سایت مایکروسافت دانلود و بعد نصبش کنن.
ظاهر نرم‌افزار کمی تغییر کرده و می‌شه نشونه‌های اینترفیس جدید مایکروسافت رو توش دید: اینترفیس مترو. این اینترفیس اولین بار تو ویندوز فون ۷ معرفی شد و ویندوز ۸ که قراره تا چند ماه دیگه بیاد هم همین اینترفیس رو داره. ظاهرا مایکروسافت داره تمام نرم‌افزارهاش رو هم به همین سمت می‌بره.
وقتی صحبت از اینترفیس می‌شه احتمالا اولین چیزی که به ذهن همه ما میاد پریماوراس و این آرزوی همیشگی که یه روزی اینترفیس اون هم به اندازه کافی خوب و حرفه‌ای بشه! بگذریم.
قابلیت‌های جدید پراجکت ۲۰۱۳
من هنوز فرصتی نداشتم که کامل نرم‌افزار رو بگردم و به تدریج که این کار رو بکنم مثل همیشه نتایج رو هم اینجا می‌نویسم. در حال حاضر با مرور توضیحات مایکروسافت در مورد قابلیت‌های جدید می‌شه نتیجه گرفت که این دوتا قابلیت جدید انتظارمون رو می‌کشن: گزارشهای بهتر، قابلیت قوی‌تر در رهگیری روابط.
رهگیری روابط
تو نسخه ۲۰۰۷ قابلیت جدیدی بود به اسم Task Driver (اگه اسمش رو اشتباه ننوشته باشم) که وقتی فعالش می‌کردیم یه کادر باز می‌شد و وقتی روی فعالیت‌ها کلیک می‌کردیم مشخص می‌کرد که driver اون فعالیت، یعنی سخت‌گیرانه‌ترین المانی که تاریخ شروعش رو مشخص می‌کنه چیه. این المان می‌تونه یکی از پیش‌نیازهای اون فعالیت، یکی …
خیلی‌ها که در حال آماده شدن برای آزمون 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 بسازین.
و یه نکته دیگه؛ می‌دونین که می‌شه جدول و نمودار گانت پراجکت رو تو نسخه ۲۰۰۷ و جدیدتر از اون به همین شکل قالب‌بندی کرد؟
به هر حال، هر کاری می‌کنین بکنین، فقط یه همچین چیزی نسازین:
زیاد پیش میاد که در زمان برنامه‌ریزی اولیه پروژه، یا بعدا در زمان اجرا، لازم باشه که برنامه رو تغییر بدین تا مدتش کمتر یا بیشتر بشه. معمولا دغدغه اصلی کم کردن مدت زمانه، ولی گاهی هم لازمه که بیشترش کرد.
در هر حال، برای خیلی‌ها سواله که چطوری می‌شه این کار رو کرد؛ مثلا مدت زمان فعالیت‌ها رو تو ضریبی ضرب کرد، منابع رو به شیوه خاصی تغییر داد یا …
جواب هیچکدوم از این‌ها نیست. افزایش یا کاهش مدت زمان پروژه تحت شرایط معمولی، اصلا کاری صرفا ریاضی نیست که به تنهایی انجامش بدین. باید شما، همراه با مدیر پروژه و سایر افراد کلیدی پروژه بشینین و تو زمان‌ها، روابط و منابع تجدید نظر کنین؛ یعنی همون کاری که قراره در زمان برنامه‌ریزی اولیه هم انجام داده باشینش.
تو این فرآیند کمک‌های تخصصی زیادی می‌تونین به تیم بکنین. مثلا اگه قراره مدت زمان کوتاه بشه، باید تیم رو هدایت کنین تا متمرکز بشه روی فعالیت‌های بحرانی و نزدیک به بحرانی و اگه قراره تو تعداد منابع تجدید نظر کنین، می‌تونین با کمی تجربه با نگاه کردن به هیستوگرام‌های منابع حدس بزنین که کدوم‌ها تاثیرگذارتر هستن و با چند بار آزمایش و خطا مسیر مناسب رو به تیم نشون بدین. ولی در هر حال، این کار بدون مشارکت تیم پروژه اصلا درست نیست.
چیزایی که گفتم برای وقتیه که واقعا بخواین برنامه‌ریزی کنین، نه این‌که ماجرا صوری باشه.
