من حداقل هفته‌ای دو سه ایمیل می‌گیرم از کسایی که تو شرکت جدیدی مشغول به کار شدن و با روند کار شرکت، ساختارهای شکستی که می‌تونه توش به کار بره و فعالیت‌های برنامه‌هاشون آشنا نیستن و دنبال منبعی می‌گردن که اون‌ها رو یاد بگیرن.
خوب، منبع چیه؟ بهترین منبعی که دارین همون آدم‌هایی هستن که تو اون شرکت کارهای فنی می‌کنن. باید دونه دونه باهاشون صحبت کنین و یافته‌هاتون رو مستند کنین تا به تدریج به تصویر کاملی از کل ماجرا برسین.
متاسفانه خیلی‌ها فکر می‌کنن این کار بده و باعث می‌شه فکر کنین کار بلد نیستین. ولی این اصولی‌ترین و حرفه‌ای‌ترین شکل برخورد با کاره، چون:
حتی تو صنف‌ها و صنعت‌های یکسان هم تفاوت‌های خیلی عمده‌ای بین روش‌های کاری هست که تنها راه درکش اینه که اطلاعات رو از همون شرکت بگیرین.
تمام کسایی که تو حوزه مدیریت پروژه فعالیت می‌کنن، از جمله تو برنامه‌ریزی و کنترل پروژه، فقط لازمه که درک کامل و درستی از تمام یا بخشی از مدیریت پروژه داشته باشن و نه جنبه‌های فنی پروژه‌های خاص. به عنوان مثال چنین آدمی باید بدونه که یه ساختار شکست خوب چیه و چطوری تهیه می‌شه و به چه کاری میاد، نه این‌که بدونه ساختار شکست کار مناسب برای فلان نوع یا بهمان نوع پروژه چیه.
بعد از این‌که تمام اطلاعاتی که لازم داشتین رو استخراج کردین، می‌تونین برای بهبودشون از تجربه‌ها و الگوهای پذیرفته شده شرکت‌های مشابه هم …
خیلی وقت‌ها می‌بینیم که تو اداره یه شرکت مشکلای زیادی وجود داره و شروع می‌کنیم به ایراد گرفتن و بعضا مسخره کردن. این کار برای خیلی‌ها جزئی از فرهنگ روزمره‌شونه، یعنی سر کار که می‌رن باید چنتا نامه جواب بدن، روی کارای دوتا پروژه کار کنن، حداقل بیست دقیقه هم مدیریت شرکت رو مسخره کنن.
ماجرا اینه که:
ممکنه یه شرکت هزارتا کار خیلی اشتباه انجام بده، ولی به ازای اون ده هزارتا کار درست و حساب شده هم داره انجام می‌ده و برای همینه که هنوز سرپا مونده؛ البته مشخصا دارم در مورد شرکت‌های خصوصی صحبت می‌کنم که نوعی انتخاب طبیعی در موردشون صادقه. این‌که فقط بخوایم اشتباه‌ها رو مبنای قضاوت قرار بدیم و به کارهای درست و سنجیده توجه نکنیم خیلی بی‌انصافیه.
مدیریت یه کار یکپارچه‌س. خیلی راحته که آدم یه مورد کوچیک رو پیدا کنه که خوب پیش نمی‌ره و به روش‌های بهتری برای اجراش فکر کنه و بعد هم بگه که ببین این‌ها چقدر نادون هستن که روشی به این سادگی و موثری رو اجرا نمی‌کنن. ولی واقعا اینطوره؟ اون روش هرچی که باشه باید با بدنه کلی مدیریتی یکپارچه بشه و این ماجرا معمولا به این سادگی نیست. بعضی وقت‌ها برای یکپارچه کردن یه تغییر کوچیک باید کلی چیزها رو عوض کنیم. پس هر چیزی که به نظر ساده میاد الزاما ساده نیست.
در نهایت این‌که از حرف تا عمل راه خیلی زیاده. شاید یه روش به نظر خیلی بهتر بیاد، ولی وقتی جانشین روش …
امروز یکی از خواننده‌ها از من سوالی در مورد انگیزه تجاری (Business Case) کرد و من تازه متوجه شدم که ممکنه تو کتاب‌هام به اندازه کافی توضیح نداده باشمش. سوال این بود که این منطقیه که مدیر پروژه پیمانکار انگیزه تجاری رو خیلی واقع‌بینانه برای کارفرما به‌روزرسانی کنه، در حالی که اگه مشخص بشه پروژه توجیه‌پذیر نیست ممکنه به قیمت از دست دادن پروژه تموم بشه یا نه.
اول این‌که مبنا باید شفافیت باشه؛ اگه پیمانکار متوجه می‌شه که پروژه برای کارفرماش توجیه‌پذیر نیست باید بهش اطلاع بده و در این صورت بهتره که پروژه لغو بشه. گذشته از این‌که این‌کار اعتبار پیمانکار و رضایت کارفرما رو افزایش می‌ده و تو بلند مدت به نفع پیمانکار تموم می‌شه، جلوی بعضی مشکلات رو هم تو کوتاه مدت می‌گیره: پروژه‌ای که توجیه‌پذیر نباشه احتمال زیادی داره که پیش از اتمام به مشکلات مالی بخوره و در این صورت پیمانکار هم ممکنه نتونه مطالباتش رو به راحتی بگیره. خیلی از کارفرماهای بزرگ خودشون تامین‌کننده‌های مالی دیگه‌ای دارن (مثل سازمان‌های بالادست) که به هر حال اون‌ها دیر یا زود متوجه ماجرا می‌شن و تامین نقدینگی رو ممکنه متوقف کنن.
ولی از این‌ها که بگذریم، این نکته مهم رو باید در نظر داشته باشین که تو همه استانداردها وقتی از انگیزه تجاری صحبت می‌کنیم منظورمون صرفا انگیزه تجاری‌ایه که برای شرکت خودمون وجود داره، نه برای کارفرما یا …
من همیشه از انعام دادن خوشم میاد. این ماجرا ممکنه تو این تجربه خیلی محدود من شکل گرفته باشه که وقتی خیلی کم سن بودم چند ماه بدون این‌که خانوادم بدونن یه جایی فروشندگی کردم. انعام‌هایی که مردم می‌دادن در آخر پول خوبی می‌شد و واقعا بهم مزه می‌داد! از طرف دیگه، این‌که احساس می‌کنم با انعام دادن من یه نفر خوشحال می‌شه (هرچند کوچیک) خودش خیلی ارزش داره.
بگذریم. ماجرایی که امروز به ذهنم رسید شیوه انعام دادن بود. اکثر آدم‌ها وقتی سرویس رو کامل دریافت می‌کنن انعام می‌دن. این کار مثل این می‌مونه که آدم صبر کنه، سرویس رو ارزیابی کنه و بعد به ازای اون پولی اضافه بده. یادمه دایی من از قدیم جور دیگه‌ای برخورد می‌کرد: انعام رو اول می‌داد، تا سرویس بهتری دریافت کنه. من هم یه مدتیه که دارم از این روش استفاده می‌کنم و واقعا ازش راضی‌ام.
احتمالا می‌دونین که من همیشه گفتم اگه لازم باشه PMBOK رو تو یه جمله خلاصه کنیم، می‌شه «انفعالی برخورد نکن». مثال: شما مدیر پروژه‌ای و متوجه شدی که نتیجه طراحی یکی از مهندس‌ها مشکل داره. اولین کاری که باید کرد چیه؟
تقریبا همه می‌گن که به نوعی اون ایراد رو برطرف کنیم. این می‌شه «راه حل اصلاحی»، در حالی که قراره اولویت با «راه حل پیش‌گیرانه» باشه. اولین کاری که می‌کنیم اینه که ببینیم دلیل ریشه‌ای این مشکل چی بوده. مثلا اطلاعات درست به اون طراح نرسیده؟ با همکارانش مشکل …
وقتی حجم و فوریت کارها بالا میره باید چیکار کرد؟ شاید اکثر آدم‌ها به زبون نیارن، ولی کاری که عملا می‌کنن اینه که سعی می‌کنن سریع‌تر و بیشتر کار کنن. این یه اشتباه مطلقه!
روبرویی با بحران
وقتی تو چنین وضعیتی قرار می‌گیرین به جای این‌که بلافاصله سرعت یا مقدار کارتون رو اضافه کنین، بشینین و خیلی سر فرصت به این فکر کنین که چطوری باید عمل کنین. آیا می‌شه روش کار رو عوض کرد تا بشه اون رو به موقع تموم کرد؟ آیا می‌شه بعضی کارها رو فعلا معلق کرد و روی کارهای ضروری تمرکز کرد تا به موقع تموم بشن؟ اصلا اگه به موقع تموم نشه چه اتفاقی می‌افته؟
باید تمام راه‌حل‌ها رو سنجید و اونی که به نظر بهتر از همه میاد رو انتخاب کرد. افزایش سرعت و مقدار کار (مثلا تعداد ساعتی که تو روز کار می‌کنیم) معمولا از بهترین انتخاب‌ها نیست. یکی از مشکلاتش هم اینه که کیفیت رو می‌بره پایین و این معمولا به ضررمون تموم می‌شه.
مشکل بزرگ‌تر برای کسایی که هروقت فشار کارشون بالا میره بدون این‌که به راه‌حل‌ها فکر کنن صرفا بیشتر به خودشون فشار میارن اینه که عملا تو همین وضعیت باقی می‌مونن و هر از چندی با همین موقعیت برخورد می‌کنن و دوباره فقط به خودشون بیشتر فشار میارن؛ یه جورایی درجا می‌زنن. اگه به جای اون روی راه‌حل‌ها فکر کنین و پیاده‌سازی‌شون کنین، هر بار یه مرحله پیشرفت می‌کنین؛ پیشرفتی که برای کسایی که تو حوزه‌های …
احتمالا می‌دونین که برای PRINCE2 دو سطح آزمون هست، Foundation که اول برگزار می‌شه و عمدتا متمرکزه روی دونستن مفاهیم کلی و اصطلاحات، و بعد سطح Practitioner که پیشرفته‌س و همه چیز رو در بر می‌گیره.
هیچکدوم از این دو سطح الان پیش‌نیاز دوره ندارن؛ هر کسی می‌تونه خودش مطالعه کنه و آزمون بده. تنها پیش‌نیاز این بود که قبل از گواهی Practitioner باید گواهی Foundation رو گرفته باشین. از ابتدای ماه آینده میلادی تبصره‌ای برای این پیش‌نیاز در نظر گرفته می‌شه: کسایی که گواهی PMP یا یکی از گواهی‌های IPMA رو داشته باشن می‌تونن بدون داشتن گواهی PRINCE2 Foundation تو آزمون PRINCE2 Practitioner شرکت کنن.
پ.ن. اگه یادتون باشه قبلا اعلام کرده بودم که دیگه می‌تونیم آزمون‌های پرینس۲ رو تو ایران برگزار کنیم و البته از روی احتیاط گفته بودم که «فعلا». خوب، متاسفانه ماجراهای سیاسی بین انگلستان و ایران چندان هم خوب پیش نرفته و بعد از این نمی‌تونیم آزمون‌ها رو آنلاین برگزار کنیم. تنها حالت ممکن اینه که آزمون رو کاغذی و با حضور من (ناظر رسمی) بگیریم، که اون هم به خاطر شرایط من خیلی محدود می‌شه و از طرف دیگه تضمینی هم وجود نداره که همینش هم تا کی برقرار باشه.
یکی از خواننده‌ها از من در مورد منابع مفید برای بهبود مدیریت اسناد پروژه‌ها پرسیده بود، و این البته اولین باری نیست که چنین سوالی از من پرسیده می‌شه.
جواب من معمولا اینه که نمی‌تونین تو منابع معتبر دنبال چیزهایی باشین که تو خیلی از پروژه‌های ایرانی استفاده می‌شه و انتظار دارن. مثلا حتی عبارت DCC (مخفف document control center یا یه چیزی شبیه اون) که تو خیلی از پروژه‌های ایرانی به عنوان یه عبارت استاندارد استفاده می‌شه هم به هیچ وجه رایج نیست و تو متون به چشم نمی‌خوره. تو چنین فضاهایی، مسئله اصلی یه دانش جامع و عمیق نیست؛ بخش عمده‌ایش در مورد عرف کاریه و بخش دیگه‌ایش در مورد فرآیندهایی که مثلا تو بخش مهندسی وجود داره. بهترین منبع برای یادگیری همه این‌ها هم خود محیطیه که توش کار می‌کنین. یعنی از یه طرف باید با مدیران واحدهای مهندسی صحبت کنین و با فرآیند کارشون آشنا بشین و از طرف دیگه با کسایی که تو بخش مدیریت اسناد کار می‌کنن صحبت کنین و عرف‌هاشون رو بشناسین.
سیستم‌های رایجی که برای مدیریت اسناد تو شرکت‌های ایرانی استفاده می‌شه به اندازه کافی موثر نیست. برای آزمایش می‌تونین چک کنین که سیستمتون می‌تونه خیلی سریع جواب چنین سوال‌هایی رو بهتون بده یا نه:
کدوم اسناد تا الان تکمیل شدن، ولی هنوز تایید نشدن؟
جواب کدوم نامه‌ها رو باید حداکثر تا پایان امروز بدیم؟ جواب کدوم نامه‌ها به تاخیر …
واقعیت اینه که اکثر آدما زیاد از حد از نمودارهای دایره‌ای استفاده می‌کنن، اون هم در حالی که این نمودارها مجموعا زیاد قوی نیستن. تو این مطلب می‌خوام در مورد شیوه درست استفاده از نمودارهای دایره‌ای توضیح بدم.
هروقت می‌خوایم نمودار بکشیم باید به این فکر کنیم که هدفمون چیه و دقیقا چه چیزی رو می‌خوایم منتقل کنیم. مثلا اگه می‌خوایم تغییر یه مقدار پیوسته رو نشون بدیم (مثلا پیشرفت‌های تجمعی)، قاعدتا بهتره از نمودارهای خطی استفاده کنیم، چون پیوستگی رو خوب به تصویر می‌کشن. اگه پیوستگی نداشته باشن (مثلا مقدارهای دوره‌ای به جای مقدارهای تجمعی)، بهتره از نمودار خطی استفاده نکنیم، چون اشتباها پیوستگی رو به ذهن القا می‌کنن.
خوب، حالا چه موقع باید از نمودارهای دایره‌ای استفاده کنیم؟
ببینین نظرتون در مورد نمودار پایین چیه:
این نتیجه یه مطالعه جالبه از Standish Group، که نشون می‌ده چقدر قابلیت‌های اضافه تو نرم‌افزارها داریم. این برای کسایی که تو پروژه‌های نرم‌افزاری کار می‌کنن خیلی مهمه، چون نشون می‌ده که به اندازه کافی روی ارزش تجاری گستره پروژه‌مون تمرکز نداریم. مثلا اون ۴۵ درصد قابلیت‌هایی که تقریبا هیچوقت استفاده نمی‌شن رو می‌تونیم تولید نکنیم و در عوض هزینه و زمان پروژه رو نصف کنیم. مدیریت این ماجرا تو پروژه‌هایی که چابک اجرا می‌شن خیلی راحت‌تره.
این سوال خیلی رایجه… آیا یه مدیر پروژه باید جنبه‌های فنی پروژه رو بشناسه؟ آیا باید یه متخصص باشه؟
قدیم جواب قطعا مثبت بود. اصولا هم کسی مدیر پروژه می‌شد که متخصص خیلی باتجربه‌ای تو جنبه‌های فنی اون پروژه بود. ولی الان اوضاع فرق کرده. الان اعتقاد داریم چیزی که قبلا وجود داشته مدیریت پروژه حرفه‌ای نبوده و الان انتظار داریم که آدم‌ها واقعا متخصص تو مدیریت پروژه باشن. این امکان هم به نظر وجود داره که جنبه‌های مدیریتی پروژه‌ها رو از اون‌ها انتزاع کنیم و در نتیجه کاری کنیم که برای همه یکسان باشه. به همین خاطره که مثلا PMBOK و PRINCE2 برای هر نوع پروژه‌ای قابل استفاده هستن.
الان بین کسایی که تو این حوزه صاحب نظر هستن دو گرایش وجود داره:
این‌که «لازم» نیست مدیر پروژه جنبه‌های فنی پروژه رو بشناسه، ولی اگه آشنا باشه خیلی هم خوبه.
این‌که «لازم» نیست مدیر پروژه جنبه‌های فنی پروژه رو بشناسه و حتی بهتر هم هست که نشناسه!
شاید گرایش دوم به نظرتون عجیب بیاد. خودتون رو بذارین جای یه کسی که تو مدیریت پروژه وارده و الان مدیر پروژه‌ای شده. حالا اگه یه متخصص تمام عیار تو جنبه‌های فنی پروژه باشین چه اتفاقی می‌افته؟ آیا می‌تونین توش دخالت نکنین؟ یا این‌که دایما می‌خواین کارهای فنی رو چک کنین و هر چیزی که ایده‌آل کار نشده بود رو تذکر بدین که بهتر کنن؟ بقیه رو نمی‌دونم، ولی برای من که سخته!
خیلی‌ها این مشکل رو دارین که لازمه برآوردهایی از کارشناس‌ها دریافت کنین و برآوردها خیلی دست بالا هستن. حالا مسئله اینه که چطوری می‌شه برآوردهای واقع‌بینانه‌تری دریافت کرد.
همیشه باید قبل از انتخاب راه حل، مسئله رو ریشه‌یابی کرد. چرا برآوردها دست بالا هستن؟
دلیلش اینه که می‌رین مثلا از یه طرح می‌پرسین چقدر طول می‌کشه فلان کار رو انجام بدی، اون هم مثلا می‌گه بیست روز، بعد اگه بشه بیست و یه روز و هنوز تموم نکرده باشه می‌رین سرزنشش می‌کنین که چرا عقبی. خوب، اون هم خیال خودش رو راحت می‌کنه و از اول می‌گه سی و پنج روز!
به این می‌گن حاشیه اطمینان موضعی (padding) و خیلی چیز بدیه، چون کنترل شده نیست (هیچوقت همه کارهای پروژه در بدبینانه‌ترین حالت ممکن تموم نمی‌شن).
پرده اول
خوب، حالا چطوری می‌شه این مشکل رو حل کرد؟ قطعا اولین و مهم‌ترین قدم اینه که سرزنش کردن رو از برنامه کاریمون حذف کنیم تا خیال همه راحت باشه و احساس نکنن لازمه که حاشیه اطمینان به برآوردهاشون اضافه کنن. مثلا وسط پروژه می‌تونین یکی از دو قضاوت زیر رو در مورد واحد طراحی سازه داشته باشین:
شما کارتون عقبه و پروژه رو به تاخیر انداختین! چرا؟
الان عملکرد شما مهم‌ترین عاملیه که جلوی بیشتر به تاخیر افتادن پروژه رو می‌گیره. چیکار می‌تونیم بکنیم که کارتون سریع‌تر پیش بره؟
این دوتا عملا یکی هستن، ولی اولی سازنده نیست، فقط سرزنشه و …
ایمیلی داشتم که سوال جالبی پرسیده بود؛ این‌که نویسنده گاهی تو درج مقادیر یا سایر مراحل کار اشتباه می‌کنه و می‌خواست بدونه چطوری می‌تونه اشتباه‌هاش رو به حداقل برسونه.
این سوال واقعا خوبه، چون اکثر آدم‌ها وقتی متوجه می‌شن که گاهی اشتباه می‌کنن، تنها اقدامی که می‌کنن اینه که سعی می‌کنن بیشتر حواسشون رو جمع کنن. ولی این واقعا کافی نیست و دنبال روش بودن واقعا خوبه.
این رو هم باید در نظر داشت که کاری که صد در صد ماشینی انجام نمی‌شه احتمال اشتباه داره و همیشه باید این رو بپذیریم؛ مسئله فقط اینه که مقدار این اشتباه‌ها رو به حدی پذیرفتنی برسونیم. از اون گذشته، هر اشتباه که بکنین احتمالا یه مقدار جایگاهتون تو شرکت افت می‌کنه، هرچند جزئی.
نکته اول
شاید بشه تو روش کارتون تجدید نظر کنین. پتانسیل خطای روش‌های مختلف به یه اندازه نیست. وقتی داریم یه سیستم شکل می‌دیم این از مهم‌ترین چیزایی که در نظر می‌گیریم؛ این‌که روشی که برای کار انتخاب کردیم چقدر احتمال اشتباه داره. مثال: بعضی‌ها کل محاسبات پیشرفت رو تو اکسل انجام می‌دن، که البته من به هزار و یک دلیل باهاش مخالم. ولی از اون که بگذریم می‌شه از جنبه پتانسیل اشتباه هم اون رو بررسی کرد. تو چنین فایلی که مثلا ممکنه ده هزارتا آیتم وجود داشته باشه چندتا فرمول برای خلاصه‌سازی اطلاعات وجود داره؟ منظورم انواع میانگین‌گیری‌های وزنیه. مثلا ممکنه هزارتا …
یه مشکل خیلی رایج وجود داره که فقط هم در مورد پروژه‌ها نیست، در مورد مدیریت عملیات هم وجود داره و حتی تو مدیریت زندگی شخصی: این‌که قبل از فکر کردن به سوال‌هایی از نوع «چرا» به سوال‌هایی از نوع «چگونه» فکر می‌کنیم. مثلا وقتی قراره پروژه‌ای رو انجام بدیم، فقط داریم به این فکر می‌کنیم که چطوری باید انجامش بدیم و برنامه‌های ناقصی می‌ریزیم برای «کار» کردن.
حدس می‌زنین چرا به جای کار نوشتم «کار»؟
کسایی که PRINCE2 خونده باشن می‌دونن که یکی از اصول زیربناییش اینه که باید به جای «کار» روی «محصول» متمرکز بشیم. هدف کار کردن نیست، محصول تولید کردنه. این تمرکز روی کار مشکلای خیلی زیادی به وجود میاره؛ مثلا:
فکر می‌کنیم زیاد کار کردن ارزشه؛ در نتیجه دایما سعی می‌کنیم بیشتر و بیشتر کار کنیم و هرچقدر بیشتر کار کنیم، کیفیت کارمون کمتر می‌شه و ذهنمون بیشتر از محصول فاصله می‌گیره. در نهایت کیفیت محصول هم به تبع کیفیت کار افت می‌کنه.
انقدر برای کار ارزش قایلیم که اون رو به نوعی مقدس می‌دونیم؛ تغییرش نمی‌دیم. در حالی که وقتی تمرکزمون روی محصول باشیم، اون نقطه ثابت به جای کار تبدیل می‌شه به محصول و آماده‌ایم که روش کار کردمون رو هر وقت که لازم بود عوض کنیم، طوری که بهتر به محصول برسیم. نتیجه‌ش می‌تونه کیفیت بالاتر، سرعت بیشتر، هزینه کمتر و به طور کلی منافع بیشتر باشه.
خیلی‌ها در مورد تفاوت اصطلاح‌های plan و schedule از من می‌پرسن و دیگه به نظر میاد به جای ایمیل باید اینجا توضیح داد:
schedule یعنی زمان‌بندی و scheduling یعنی زمان‌بندی کردن… برنامه‌ریزی جنبه زمانی پروژه؛ همون چیزی که در مرکز فعالیت‌های اکثر شماهایی که کارتون اصطلاحا کنترل پروژه‌س قرار می‌گیره. معمولا رایجه که برنامه‌ریزی منابع (به جز برنامه‌ریزی‌های خاص منابع انسانی مثل آموزش) هم جزئی از زمان‌بندی دونسته می‌شه. معمولا هزینه و گستره همراه زمان‌بندی تو یه «مدل» قرار می‌گیرن، ولی مفاهیم مستقلی هستن و وقتی صحبت از زمان‌بندیه معمولا شامل گستره و هزینه نمی‌شه.
plan یعنی برنامه و planning یعنی برنامه‌ریزی. منظور از برنامه معمولا کل برنامه‌ریزی‌هاییه که برای پروژه لازمه، یعنی علاوه بر برنامه‌ریزی زمان، شامل هزینه، گستره، منابع انسانی، تدارکات و همه چیزهای دیگه هم می‌شه.
اصطلاح‌های replan و reschedule هم به معنی هر نوع بازبینی تو برنامه یا زمان‌بندی هست. این بازبینی می‌تونه برای اعمال تغییرات درخواستی کارفرما باشه، می‌تونه به این خاطر باشه که ایده‌های بهتری برای اجرای کار به ذهنمون رسیده، برای جبران عقب افتادگی‌ها و هر چیز دیگه‌ای.
اصلاح دیگه‌ای هم تو این حوزه هست که البته تو همه متون استفاده نمی‌شه، ولی باز هم عمومیت داره: catch-up plan یا catch-up schedule. این می‌شه نوع خاصی از replan …
پیش‌نیاز آزمون سه سال تجربه مرتبط، حدود یک سال تجربه پروژه و ۳۵ ساعت آموزش مرتبطه. هزینه‌ش هم برای اعضای PMI حدود ۴۰۰ دلاره. آزمون ۲۰۰ سوال چهار جوابیه و ۴ ساعت زمان داره. مطابق معمول هم تو مراکز Prometric انجام می‌شه که تو ایران نیست.
به تازگی سومین راهنمای عملی که در مورد استقرار مدیریت پروژه سازمانیه هم منتشر شده.
اولین نکته‌ای که باید بدونیم، معنی مدیریت پروژه سازمانیه که به OPM هم مخفف می‌شه. این OPM همونیه که تو ترکیب OPM3 هم قرار می‌گیره؛ یعنی موضوع مدل بلوغی که تو OPM3 تعریف می‌شه همون چیزیه که بحث این راهنمای عملیه.
طبق تعریف PMI از OPM، این مفهوم چهارچوبیه که تحقق استراتژی‌های سازمان رو از طریق پرتفولیوها، طرح‌ها و پروژه‌ها فراهم می‌کنه. به عبارت دیگه مجموعه پرتفولیوها و طرح‌ها و پروژه‌های سازمان و سیستم‌های مدیریتی اون‌ها رو با استراتژی‌های سازمان هماهنگ می‌کنه و اون‌ها رو واقعا به ابزارهایی برای تحقق این استراتژی‌ها تبدیل می‌کنه.
می‌تونین شرکت‌هایی که توشون کار می‌کنین و احتمالا تو OPM بلوغ ندارن رو تصور کنین. آیا مثلا دقیقا مشخصه که پروژه‌هایی که دارین انجام می‌دین به چه دلیل انجام می‌شن؟ یا صرفا چون می‌تونستین یه پروژه‌ای رو بگیرین و قیمتش هم «به نظر» مناسب میومده اون رو پذیرفتین؟
تو یه شرکت باید به راحتی بتونیم بگیم که چه ماهیت و هویتی داره و می‌خواد چی باشه و به کجا برسه. بعد هم سیستمی داشته …
پروژه و طرح عوامل ایجاد تغییر هستن. هر دو موقت هستن و خروجی منحصر به فرد دارن. حالا فرق این دوتا چیه؟ یه رویکرد نادرست اینه که وقتی عامل تغییر از حدی بزرگ‌تر باشه بهش بگن طرح و وقتی کوچک‌تر باشه بگن پروژه. این رویکرد زیاد درست نیست و تو این مطلب می‌خوام تفاوت‌های اساسی این دوتا رو بگم.
خروجی پروژه یه محصول، نتیجه یا خدماته که به طور کلی بهش می‌گیم محصول یا خروجی. محصول پروژه می‌تونه یه ساختمون باشه، یه نرم‌افزار، یه گزارش و امثال اون‌ها.
محصول یک یا چند پروژه بعد از تکمیل یه پتانسیل تغییر به وجود میارن و وقتی این پتانسیل بالفعل می‌شه، عملا یه «نتیجه» به وجود میاره. مثلا در مورد یه بیمارستان، خود ساختمونی که می‌سازیم می‌شه خروجی یا محصول کارمون. این خروجی پتانسیلی برای کارکرد داره که وقتی در کنار خروجی‌های دیگه‌ای مثل پرسنل بیمارستانی، احیانا سیستم تامین اجتماعی، بازاریابی و امثال اون‌ها قرار می‌گیره، «نتیجه»ای به وجود میاره: امکانات درمانی بیشتر برای مردم یا برای گروهی از مردم.
تفاوت اصلی پروژه و طرح اینه:
پروژه محصول به وجود میاره، طرح نتیجه به وجود میاره
پس مثلا ساخت یه سد بزرگ، با این‌که ممکنه سرمایه‌گذاری بزرگی باشه، پروژه‌س، چون داره یه محصول تولید می‌کنه؛ ولی مثلا فراهم کردن آب آشامیدنی برای یه ده، حتی اگه سرمایه‌گذاریش کمتر از یه سد بزرگ باشه، یه طرحه، چون با نتیجه سر و کار …
