برنامه ریزی و کنترل پروژه
درباره وبلاگ



مدیر وبلاگ : عباس مقدسی
نویسندگان

چند وقت پیش یه مطلب در خصوص پیاده سازی مدیریت پروژه تحت عنوان "مدیریت پروژه رباتیک در مقابل مدیریت پروژه حماسی" نوشته بودم که بازخوردهای نسبتا خوبی داشت و عمدتا این سئوال رو مطرح کرده بودن که خوب حالا چیکار باید کرد، تو این مطلب قصد دارم تا در خصوص پیاده سازی سیتم مدیریت پروژه به سبک خودم که اسمش رو شتر مرغی گذاشتم براتون بگم. (دلیل این اسم اینه که میخوام بگم باید بین این دوتا حرکت کنیم نه شتر و نه مرغ بلکه شتر مرغ، بعد یواش یواش که بالغ شدیم می فهمیم که بلاخره کدومش برامون بهتره ).

قبل از هر چیز باید داستان قانون قورباغه پخته را بهتون یادآوری کنم، تو این قانون فرض کنید قورباغه اول تو یه ظرف آبی هم دمای اتاق بوده (مدیریت پروژه حماسی یا هیاتی) و بعد قورباغه را تو ظرف آب جوش انداختند، قورباغه بر اثر شوک ناگهانی آب جوش از ظرف سریع می پره بیرون (مدیریت پروژه رباتیک)، برای بار ﺑﻌﺪ ﻗﻮرﺑﺎﻏﻪ را در ﻇﺮف آﺑﯽ ﺑﺎ دﻣﺎی اﺗﺎق ﻗﺮار دادﻧﺪ و به تدرﯾﺞ دﻣﺎی آب را ﺗﺎ ﻧﻘﻄﻪ ﺟﻮش ﺑﺎﻻ ﺑﺮدﻧﺪ. اﻣﺎ اﯾﻦ ﺑﺎر ﻗﻮرﺑﺎﻏﻪ ﻫﯿﭻ اﺣﺴﺎس ﺧﻄﺮی ﻧﮑﺮد! و آﻧﻘﺪر در آب ﻣﺎﻧﺪ ﺗﺎ ﮐﺎﻣﻼ ﭘﺨﺘﻪ ﺷﺪ. اﯾﻦ آزﻣﺎﯾﺶ نیز ﺑﺎرﻫﺎ ﺗﮑﺮار ﺷﺪ و ﻫﻤﭽﻨﺎن ﻗﻮرﺑﺎﻏﻪ ﻫﺎ ﭘﺨﺘﻨﺪ و از آب ﺑﯿﺮون ﻧﯿوﻣﺪﻧﺪ (مدیریت پروژه به سبک شتر مرغی).

خب بریم سراغ اصل ماجرا، یه چیزی که تو بهبود مستمر و پیاده سازی سیستم مدیریت پروژه خیلی خیلی اهمیت داره اینه که تا وقتی با سبک و فرهنگ سازمان آشنا نیستید نمی تونید ادعا کنید و مثلا بگید تو عرض شش ماه می تونید مدیریت پروژه رو مطابق با استاندارد پم باک یا هر متدولوژی دیگه ای پیاده سازی کنید و بعنوان مشاور براش قرارداد امضاء کنید. برای شروع پیاده سازی سعی کنید کار رو با آموزش استانداردها شروع کنید (البته منظورم فقط برگزاری کلاس های خشک و بی روح نیست، بلکه اگر بتونید پس از برگزاری هر کلاس یه کارگاه نصفه روزه رو براشون بذارید قطعا خیلی مفید تره)، پس از این مرحله باید سعی کنید همون کارهای که خودشون در حال حاضر انجام میدن رو باز هم با کمک خودشون و دانشی که الان تو این مرحله دارن رو بهبود بدید، مثلا برای شروع، بهتره کار رو با تهیه و پیاده سازی منشور پروژه شروع کنید و بازم سعی کنید تا حد امکان منشور پروژه را ساده و مختصر تهیه کنید و تمرکز رو بذارید روی قسمت های اصلی ماجرا نه جزئیات دست و پا گیر و اصطلاحات بدرد نخور، بعد از چندین جلسه که تونستید اثبات کنید که وجود چارتر در پروژه لازم و مفید هست و خودتون هم به کاربردش به معنای واقعی واقف شدید (اگر نتونستید اثبات کنید که مفید بوده بهتون پیشنهاد میکنم به مرحله بعد نرید و روی اشتباهاتتون متمرکز بشید، تا اگه قراره شش ماه آینده شکست بخورید همین حالا شکست بخورید)، میتونید برید سراغ مرحله بعد مثلا تهیه یه لیست از ذینفعان کلیدی (نه همه ذینفعان) و یا تهیه یه لیست از ریسک های مهم (نه همه ریسک ها)، یا اگر نیاز هست چارت سازمانی پروژه و یا کل سازمان رو تغییر بدید نمی تونید یدفه اینکارو انجام بدید باید همون چارت فعلی رو منظمش کنید و در مرحله اول یکم بهبودش بدید تا اینکه یواش یواش بتونید به اون سطح دلخواه برسونیدش، یه چیز دیگه ای هم که خیلی مهمه، اینه که تو بیشتر شرکت های فعلی پیمانکاری ما، مشکل تو لایه پروژه بمراتب کمتر از لایه پرتفلیو هست، پس باید مراقب باشید که از کجا قراره شروع کنید و نگاه کل نگر و جزء نگر رو با هم داشته باشید، بحث بعدی اینه که نباید شما برید تو اتاقتون و چند ماه رو صرف تهیه دستورالعمل و چک لیست کنید و بعدش برید سراغ اجرا، باید برنامه ریزی و اجرای سیستم رو با هم تواما پیش ببرید و بدونید که یکی از عوامل مهم شکست در پیاده سازی تفکیک کردن برنامه ریزی از اجرا هست. یکی دیگر از عوامل شکست، نگرفتن بازخورد بموقع از همکارنتون در خصوص مفید بودن کارهای که تا حالا انجام شده هستش که اینم باید بموقع انجام بدید و از همه مهم تر باید بدونید که پیاده سازی سیستم مدیریت پروژه برای یک پروژه، پروژه محسوب میشه و باید از ابزارهای مدیریت پروژه برای این کار استفاده بشه (منظورم اینه که شما نمی تونید سیستم مدیریت پروژه مستقر کنید در حالی که برای این کار منشور پروژه، لیست ذینفعان و تحلیل ریسک ها، مدیریت هزینه، زمان و سایر موارد رو در نظر نگرفتید) و برای پرتفلیو داستان فرق میکنه.

اگر احتمالا پس از خوندن این مطلب با خودتون فکر می کنید که پس برای یک پروژه یکساله، دوسال طول میکشه تا این قورباغه آب پز بشه به احتمال بالای صددرصد شما هم دارید رباتیک عمل می کنید، و فکر می کنید تو یک پروژه باید همه فرآیندها با عمق کامل و تمام جزئیات اجرا بشن، ضمن اینکه نباید انتظار داشته باشید مدیر پروژه همه فرآیندها را حفظ باشه، اون کسی که همه فرآیندها را با تمام جزئیات بلده طراح فرآینده نه مدیر پروژه. امیدورام تونسته باشم که مفهوم جاری سازی تدریجی مدیریت پروژه و تغییر تدریجی فرهنگ سازمان را رسونده باشم، در پایان یه خاطره هم بگم و اونم اینه که تو یکی از شرکت ها، همکارم همیشه تو جلسات می گفت که بهتره مدیر پروژه زمان مناقصه انتخاب بشه دقیقا یادمه تو اون جلسه مدیر عامل غش کرده بود از خنده و خیلی براش انجام این کار مسخره و نشد بود ولی چند وقت پیش وقتی یواش یواش پس از نزدیک به یکسال و نیم خودش به این نتیجه رسید که مگه میشه مدیر پروژه زمان مناقصه انتخاب نشه و اینقدر این موضوع براش بدیهی بود که وقتی بهش گفتیم که قبلا این موضوع رو چندین بار بهش گفتیم باورش نمیشد که قبلا نمی پذیرفت.





نوع مطلب :
برچسب ها : پیاده سازی سیستم مدیریت پروژه، استانداردهای مدیریت پروژه، PMBOK،
لینک های مرتبط :
یکشنبه 26 آذر 1396 :: نویسنده : عباس مقدسی


حدودا دوسال و خورده پیش بود که نوشتن کتاب تاخیرات رو استارت زدم، اوایل داشتم خوب پیش میرفتم که به یسری مشکل برخوردم، بعضی هاشون رو زود تونستم حل کنم ولی خوب یه مشکل خیلی جدی برام پیش اومد که باعث این همه تاخیر شد و اونم این بود که زمانیکه رسیدم به یکی از فصل ها مهم و اصلی کتاب که باید تکنیک های محاسبه تاخیرات تو نرم افزار پراجکت یا پریماورا را توضیح بدم با خودم فکر کردم که نباید منم مجددا تکرار مکررات گذشته رو مشابه همه کتاب های که تا کنون چاپ شدن رو انجام بدم و سعی کردم برم دنبال پیدا کردن یه روش ابتکاری که نه تنها نقاط ضعف روش های گذشته را تا حدود زیادی پوشش بده بلکه خیلی سریعتر، دقیق تر و عادلانه تر بشه با کمک اون میزان تاخیرات فنی پروژه را بررسی کرد، برای همین در ادامه راه با همکارم سرکار خانم مهندس آقا بابایی مشترکا روی ایجاد یک روش ابتکاری شروع بکار کردیم، خلاصه تو این مدت دوسال خیلی روش ها رو تو نرم افزار پراجکت و پریماورا امتحان کردیم و نقاط قوت و ضعف شون رو هم بررسی کردیم تا نهایتا چند ماه پیش تونستیم به یک روش ابتکاری تو پراجکت برسیم که اسمش رو "احیای مسیر بحرانی" گذاشتیم و الان هم در حال حاضر داریم روی بهبود قسمت های آخر و امتحان کردن سناریوهای مختلفش کار میکنیم، نمیخوام بگم روش های آقای تئودر ترانر و همکارانش قبل از این سوء تفاهم بوده ولی شاید به جرات بتونم بگم که استفاده از تکنیک احیای مسیر بحرانی از همه نظر با تکنیک های فعلی قابل قیاس نیست، در ادامه یسری از فرضیات، قابلیت ها و محدودیت های این روش رو نسبت به روش های فعلی نوشتم که امیدورام براتون جالب باشه، در حال حاضر پیشرفت کتاب بالای 85% هست و خیلی امیدورام قبل از پایان سال به چاپ برسه (قسمت های سخت ماجرا تموم شدن و فقط باید یکی دو فصل ساده بهش اضافه بشه و البته ویرایشش هم تموم بشه). ضمنا یه مقاله هم برای سیزدهمین کنفرانش بین المللی مدیریت پروژه فرستادیم. انشاله این کتاب که کاملا سناریو بیس و کاربردی هست بتونه جوابگوی خیلی از مشکلات فعلی کارشناسان برنامه ریزی و کنترل پروژه باشه.

فرضیات:


        از نرم افزار پراجکت (MSP) برای انجام این کار استفاده میشه و یا از خروجی سایر نرم افزارها در قالب پراجکت استفاده میشه.

        اطلاعات واقعی پروژه در دسترس هستند (تاریخ های شروع و پایان واقعی و حذف و اضافات)

        برنامه ها خوش ساخت هستند ( در غیر اینصورت باید قبل از اعمال آیتم های تاخیر اونا رو خوش ساخت کرد).

 

قابلیت ها:


        تغییرات مسیر بحرانی به درستی در نظر گرفته میشه.

        برنامه زمان بندی مبنای پویا ایجاد خواهد شد.

        تاریخ های شروع و پایان واقعی در نظر گرفته میشن.

        بازه وقوع تاخیرات به وضوح مشخص میشه.

        عامل اصلی تاخیرات به تفکیک مشخص میشه (کارفرما، مشاور، پیمانکار، سایر موارد).

        نتایج بررسی تاخیرات عادلانه و واقع بینانه هست.

        از بروز دعاوی در آینده جلوگیری بعمل میاد.

        نیازی به استفاده از چندین برنامه مبنا و یا برنامه های به روز شده متعدد نیست.

        توضیح دادنش برای کارفرماها راحت تر و قابل درکه.

 

محدودیت ها:


        تنها نقطه ضعفی که تا حالا خودم ازش دیدم اینه که تو پریماورا قابل انجام نیست (به دلیل محدودیت های فرمول نویسی تو نرم افزار پریماورا) ولی خوب میشه اون برنامه رو هم با یه اکسپورت به پراجکت منتقل کنید و کار محاسبات رو باهاش پیش ببرید.

 





نوع مطلب :
برچسب ها : آخرین وضعیت کتاب تاخیرات، روش های محاسبه تاخیرات در پروژه،
لینک های مرتبط :

شاید تا چند سال پیش که تو کشور ما مثل حالا آشنایی با استانداردهای مدیریت پروژه (مثل پم باک، پرینس 2 و ...) خیلی وجود نداشت، مدیران پروژه سعی میکردن و حالا هم البته خیلی هاشون دارن تلاش میکنن تا با توجه به توانایی ها و تجارب شخصی خودشون پروژه ها را مدیریت کنن و از نظر خیلی هاشون هم تا حدودی موفق عمل می کنن، اونا فقط با اتکا به مهارت هاشون پروژه را مدیریت می کردند و مشخصه که مدیریت پروژه انجام نمیدادن (اصطلاح پروژه را مدیریت کردن با مدیریت پروژه کردن خیلی متفاوته)، برای همین اتفاقی که میفته اینه که این دسته از مدیران پروژه (سرپرست کارگاه) به شدت به صنعت پروژه وابسته هستند، مثلا من اگه یه مدیر پروژه تو سیستم هیاتی باشم و تو پروژه های ساختمانی کار کرده باشم دیگه عمرا نمی تونم تو پروژه های مثلا صنعتی و یا نفت و گاز توفیق خاصی داشته باشم.

تفکری که بر این نوع مدیریت پروژه حاکمه اینه که بهت میگن، این مسخره بازیا رو بذار کنار، کارو شروع کن، دستورالعمل چیه؟ درس آموخته یعنی چی؟ این قرتی بازیا فقط وقت ما رو تلف میکنه، نفر بریزد کارو جمع کنید.

اینا اعتقاد دارن که تو دانشگاه ها و محیط های آکادمیک کسی کار یاد نمیگیره بلکه کف کارگاه باید چیز یاد بگیری، مثلا من خودم به یکی از همین همکارام گفتم این گزارش های تحلیلی و برنامه ها رو که برات میفرستیم ازشون استفاده میکنی؟ (خیر سرمون کلی آموزش هم دادیم)، گفت نه والا این کاغذ بازیا چیه، اگه با این مسخره بازی های شما کار جمع میشد که خوب بود.

خب نقاط ضعف این سیستم برای همه مشخصه، مثل: انحراف های زیاد از زمان و هزینه، دوباره کاری های وحشتناک، نرسیدن به اهداف از پیش تعیین شده پروژه و ...،

در مقابل سیستم مدیریت پروژه حماسی چند سالیه که به لطف موسسات مدیریت پروژه بیشتر کارشناس های تحصیلکرده میرن سراغ دوره های مدیریت پروژه و متاسفانه در اکثر موارد خروجی این دوره ها میشن یسری کارشناس خشک و انعطاف ناپذیر که من بهشون میگم "ربات"، این ربات ها که در غالب اوقات در دفاتر PMO یافت میشن و همواره مشغول زجر دادن بقیه هستن، از همه انتظار دارن و البته الزام هم میکنن که مطابق استانداردها آب بخورن چه برسه به دستشویی رفتن، مثلا جدیدا مُد شده تو قراردادها میگن پیمانکار موظف است مطابق استاندارد پم باک عمل نماید، بطور مثال پیمانکار باید برنامه مدیریت ذینفعان رو به کارفرما ظرف یک هفته ارائه بده، پیمانکار باید برنامه مدیریک ریسک را مطابق دستورالعمل ابلاغی تهیه و به کارفرما ارسال کنه و ... (شدت این داستان تو کارشناس های کارفرما و مشاور وحشتناک داره میشه، چون الان هر کسی حداقل یه ترا بایت دستورالعمل رو هارد کامپیوترش داره دیگه).

معمولا هم وقتی ازشون میخواید وقت بگیرید و یه جلسه باهاشون داشته باشید تا یسری از مسائل رو که واقعا نفهمیدی رو برات توضیح بدن، با اکراه میگن همه چیز تو دستورالعمل مشخصه، وقتی براش توضیح میدی که جناب آقای دکتر، اصلا هدف من تو این پروژه با هدف تو زمین تا آسمان فرق میکنه، ریسک های پروژه از دیدگاه من پیمانکار با ریسک های تو کارفرما خیلی خیلی متفاوت هست و همینطور ذینفعان من و شما با هم تفاوت های زیادی دارن، دیگه کاملا براشون مشخص و واضح میشه که پیمانکار قصد همکاری نداره و شروع میکنن به نامه نگاری های پوچ و بی ارزش و کار را به حاشیه بردن. متاسفانه یسری از این مدیران جدید هم برای اینکه ثابت کنن روشنفکر هستن و نمودار میفهمن چیه به این آدم ها هم تو سیستم شون پر و بال میدن و حرفاشون رو وحی منزل میدونن، دیگه نمیدونن که برخلاف اونچه که تصور میکنن ذینفع مثبت که هیچی ریسک های اصلی پروژه همین ها هستن.

در حال حاضر آسیب های که سیستم مدیریت پروژه رباتیک داره به سازمان ها و پروژه ها وارد میکنه به مراتب بدتر از سیستم حماسی هستش (و متاسفانه این فاجعه روز بروز در حال افزایشه)، چرا که تو این سیستم پس از یه مدت که مشخص میشه این دستورالعمل ها چیزی بجز یه مشت کاغذ پاره نبوده، دیدگاه مدیران و بقیه همکاران رو هم بشدت تحت تاثیر منفی قرار میده، و حتی پس از مدتی مدیران به این نتیجه میرسن که این استانداردها هم مثل ایزو بدرد نخور، بی خاصیت و تلکه پوله، برای همین باید حواسمون رو جمع کنیم که اسیر اصطلاحات و فرآیندهای پیچیده و تو در تو نشیم و به هیچ وجه هم از تیلورینگ درست نباید غافل بشید.

در پایان قصد دارم چند نکته مهم بگم:

1-     اگر در سیستم کارفرما هستید و میخواید مدیریت پروژه انجام بدید این وظیفه شماست که از دیدگاه خودتون به قضیه نگا کنید و برنامه های مثل مدیریت ریسک، ذینفعان و ... را انجام بدید.

2-     صرفا با شرکت در چند دوره و گرفتن چند مدرک نمیشه ادعا کرد که میتوانیم مدیریت پروژه مستقر و پیاده سازی کنیم.

3-      اگر دارید کارها را تو سازمان پیچیده و سنگین می کنید بدونید دارید اشتباه می کنید.

4-     اگر کارتون خروجی مشخص و مثبتی نداره باید اول از همه به خودتون شک کنید.

5-     اگر در جایگاه پیمانکار هستید به راحتی هر چیزی رو از کارفرما نپذیرید به این دلیل که کارفرماست.

6-     همدیگر رو به بی سوادی متهم نکنیم، مخصوصا جلوی مدیران مون.

7-     استقرار سیستم یه کار دسته جمعی و تیمی هست نه اینکه بشنید تو اتاقتون و برای بقیه دستورالعمل تو تلگرام از این و اون درخواست کنید و فقط سربرگ و لوگو رو تغییر بدید.

8-     استقرار سیستم یه کار پر زحمت و زمان بر هست نباید انتظار داشته باشید تو چند ماه طبق استاندارد کار کنید.

9-     تو رو خدا حواستون باشه داریم چه بلای سر این استانداردها میاریم.

10- حواستون به داستان کارد آشپز خانه باشه (استانداردها هم همین شکلی هستن).

در پایان ازتون خواهش میکنم اعتدال رو سرلوحه کارتون قرار بدید، نه هیاتی و حماسی عمل کنید و نه مثل ربات باشید، خود استانداردها دارن داد میزنن بابا تیلور کن منو و به اندازه استفاده کن.





نوع مطلب :
برچسب ها : مدیریت پروژه رباتیک در مقابل مدیریت پروژه حماسی!!!، تیلورینگ در پروژه،
لینک های مرتبط :
یکشنبه 28 آبان 1396 :: نویسنده : عباس مقدسی

همانطور که قبلا قول داده بودم قرار بود یسری مجموعه ویدیوی کوتاه در خصوص چگونگی تهیه و تدوین گزارشات تحلیلی و حرفه ای پروژه براتون بذارم، که متاسفانه بدلیل مشغله زیاد نتونستم این کار رو در قالب ویدیو براتون انجام بدم و دیدم خیلی داره دیر میشه برای همین تصمیم گرفتم که بجای کلیپ ویدیویی اونو در قالب فایل پی دی اف در اختیارتون به همراه توضیحاتش بذارم امیدورام براتون مفید باشه و از خوندنش لذت ببرید. این فایل رو می تونید از طریق این لینک دانلود و استفاده کنید. منتظر بازخوردهای ناب تون هستم.





نوع مطلب :
برچسب ها : چگونگی تهیه گزارشات تحلیلی پروژه، چگونگی تحلیل گزارشات منابع انسانی، دانلود گزارشات منابع انسانی در پروژه،
لینک های مرتبط :
پنجشنبه 25 آبان 1396 :: نویسنده : عباس مقدسی

امروز سومین سال تولد وبلاگم هستش، میانگین بازدید کنندگان در هر ماه بالای 3800 نفر بوده که داره نشون میده این وبلاگ هنوز زنده ست و داره نفس میکشه، امیدورام تو این مدت مطالبی که نوشتم براتون مفید واقع شده باشه، پیام های زیادی بدستم میرسه که چرا کم مطلب می نویسیم، مشکلی که وجود داره اینه که اولا متاسفانه حجم کارهام بالاست و دوما با توجه به اینکه نوشتن یه مطلب نیاز به وقت و صرف انرژی زیاد داره (چون قراره تا مدت زیادی بمونه و ازش استفاده بشه) خیلی نمیشه زیاد مطلب نوشت، هر چند الان هم بیش از 40 عنوان مطلب جدید تو  صف دارم که باید در موردشون بنویسم و با توجه به سئوالاتی که پرسیده میشه این تعداد داره همینجوری زیادتر میشه، به هر حال خوشحالم که تو این مدت تونستم دوستان زیادی پیدا کنم و خیلی چیزهای جدید از شما یاد بگیرم. قطعا مطالب بنده خالی از اشکال نیست به همین دلیل اگر موردی به ذهنتون میرسه که نیازه بدونم لطفا بهم پیام بدید.

راستی امسالم وب سایتم رو هم راه اندازی کردم ولی در حال حاضر دارم مطالب وبلاگ رو با یه ویرایش مختصر به اونجا انتقال میدم، تو آینده احتمالا دیگه مطالبم رو فقط تو وب سایت بذارم، ولی تا اون موقع (کمتر از دو ماه دیگه) همچنان وبلاگ برقراره.

اینم آدرس وب سایت شخصی من: http://www.abbasmoghadasi.com

با آرزوی موفقیت برای شما- مقدسی (25 آبان 1396)





نوع مطلب :
برچسب ها : تولد سه سالگی وبلاگ من، www.abbasmoghadasi.com،
لینک های مرتبط :

اگه بخشنامه 5090 رو با دقت مطالعه کرده باشید احتمالا این سئوالات براتون پیش اومده که:

اولا: نحوه محاسبه دوره توقف کار برای بند 8 چطوره؟

دوما: منظور از صورت وضعیت موقت یا ماقبل قطعی پرداخت شده چیه؟

سوما: تکلیف اون صورت وضعیت های که بعد از تحویل موقت پرداخت میشن چی میشه؟ (البته این سئوال خیلی ربطی هم به این بند نداره ولی برای پاسخ دادن و تحلیل کردن سئوال دوم بهش نیاز داریم).

یه نکته مهم که باید قبل از پاسخ دادن به این سئوالات بگم اینه که من رفرنس خاصی برای پاسخ به این سئوالات ندارم و صرفا دارم برداشت های شخصی و تحلیل های تجربی و ابتکاری خودم رو میگم.

خب حالا بریم سراغ جواب سئوال اول: احتمالا میدونید که پس از اینکه شما اومدید میزان تاخیرات مالی رو محاسبه کردید، در نهایت باید با در نظر گرفتن بند 8 بخشنامه 5090 کل مدت قابل قبول رو بدست بیارید. (یعنی اینکه تاخیرات محاسبه شده قبل از تعیین مبلغ صورت وضعیت قطعی جنبه علی الحساب دارن).

برای محاسبه دوره توقف کار بهتره که از تاریخ تحویل موقت برگردید به عقب و اونو بعنوان دوره توقف کار در نظر بگیرید. بطور مثال اگه کل تاخیر بدست اومده شما شد 120 روز، و حاصل تقسیم صورت وضعیت قطعی به ماقبل قطعی پرداخت شدش 1/1 شد، پس برای محاسبه این 12 روز اضافه شده اگر بطور مثال تاریخ تحویل موقت 22/01/96 باشه 10 روز برگردید به عقب یعنی دوره توقف کار میشه از دهم تا بیست و دوم.

پاسخ سئوال 3: اول سئوال سه رو جواب میدم و بعد میرم سراغ جواب سئوال دو، برای اینکه متوجه داستان بشید خوب به سناریو زیر دقت کنید.

سناریو: پروژه ای با مدت تاخیر 6 ماه به پایان رسیده، در زمان تحویل موقت پیمانکار جمعا ده صورت وضعیت به کارفرما ارسال کرده، ولی تا تاریخ تحویل موقت کارفرما فقط تا صورت وضعیت شماره هشت رو پرداخت کرده، حالا تکلیف این صورت وضعیت ها چی میشه؟ پاسخ این هستش که تاخیرات این صورت وضعیت ها قابل قبول نیست چرا که دوره وقوع تاخیراتشون بعد از تحویل موقت هست و به دلیل اینکه کل مدت تاخیر عبارتست از تاریخ تحویل موقت منهای تاریخ پایان برنامه ای پس پذیرفته نیستن.

حالا بریم سراغ پاسخ سئوال 2: من نظرم اینه که با توجه به اینکه در یکسری از موارد کارفرماها پس از تحویل موقت به پیمانکارشون بابت صورت وضعیت های موقت هنوز بدهکار هستن (مثل سناریو بالا) درست اینه که بند بخشنامه را اینجوری تفسیر کنیم که منظور از صورت وضعیت ماقبل قطعی پرداخت شده، صورت وضعیت ماقبل قطعی پرداخت شده قبل از تاریخ تحویل موقت هست و نه مبلغ تایید شده آخرین صورت وضعیت موقت، با این تفسیر میشه تو سناریو بالا بجای تقسیم صورت وضعیت قطعی به صورت وضعیت شماره ده، اونو باید به صورت وضعیت شماره هشت تقسیم کنیم تا تاثیر عدم پرداخت های صورت وضعیت های نه و ده رو بتونیم در بازه وقوع مورد نظر براحتی محاسبه کنیم.

تو این بند چند ابهام مهم دیگه هم وجود داره که تو کتابی که در دست چاپ دارم به تفصیل مثال ها و سناریو های مختلفی در موردشون گفتم.





نوع مطلب :
برچسب ها : بخشنامه 5090، بخشنامه 1300، چگونگی محاسبه مدت تمدید قابل قبول، تحلیل بند 8 بخشنامه 5090،
لینک های مرتبط :
شنبه 29 مهر 1396 :: نویسنده : عباس مقدسی

یکی از مباحث بحث برانگیز و پرچالش در خصوص بررسی تاخیرات موضوع مالکیت شناوریه، و این بحث خیلی به موضوع تاخیرات همزمان ارکان پروژه نزدیکه، برای همین باید مراقب باشید که این دو مسئله را با هم اشتباه نگیرید، (تو این مطلب قصد ندارم در خصوص تاخیرات همزمان چیزی بگم)، ضمنا موضوع مالکیت شناوری خودش از دو قسمت تشکیل شده: الف) دعاوی مالی فعالیت های دارای شناوری ب) دعاوی زمانی فعالیت های دارای شناوری.

الف) دعاوی مالی فعالیت های که دارای شناوری هستن: چنانچه در قرارداد موضوع مالکیت شناوری مطرح شده باشه، باید مطابق آن عمل کنید ولی چنانچه تو قرارداد چیزی مطرح نشده باشه، پیشنهاد من اینه که شناوری را به پروژه اختصاص بدید و نه به ارکان پروژه، به این معنی که تا زمانی طرفین به هم خسارت وارد نکرده باشند هر کدام از ارکان پروژه (کارفرما، مشاور و یا پیمانکار) بتواند از شناوری استفاده کنن. ولی چنانچه به طور مثال پیمانکار مطابق برنامه زمان بندی اقدام به تهیه اقدامات لازم جهت نمونه متریال کرده باشه و به هر علتی کارفرما در تایید متریال ارائه شده پیمانکار تاخیر ایجاد کنه (با اینکه اون فعالیت هم شناوری داشته)، و طی این بازه قیمت خرید آن متریال گران شده باشه کارفرما موظفه که خسارت وارد شده به پیمانکار را بپردازه، در غیر اینصورت با توجه به اینکه مالکیت شناوری متعلق به پروژه هست و کسی هم خسارت ندیده خیلی هم فرقی نمی کنه که چه کسی مالک شناوری باشه و یا از شناوری استفاده کرده باشه.

ب) دعاوی زمانی فعالیت های که دارای شناوری هستن: در خصوص دعاوی زمانی چیزی که بسیار مهم و حیاتیه اینه که قبل از هر چیز بدونیم که فعالیت های که دارای شناوری هستن هیچ وقت تا زمانیکه شناوری آنها به صفر نرسیده و بحرانی نشده باشن باعث تاخیر در پایان پروژه نمیشن، با این حال در سناریو زیر حالت های را ببینید که یک بار کارفرما مالک شناوری هست و یک بار هم پیمانکار و نهایتا متوجه خواهید شد که مالکیت شناوری در دعاوی زمانی خیلی جایگاهی بنظر من نداره.

سناریو اول: فرض بگیرید که کارفرما مالک شناوری باشد و از شناوری فعالیتی استفاده نموده و منجر به بحرانی شدن و تاخیر در اجرای پروژه شده. در این حالت نهایتا مشخصه که آن مقدار تاخیری که باعث به تاخیر افتادن پایان پروژه توسط کارفرما شده غیر مجازه. یعنی اینکه کارفرما سبب وارد کردن نوعی خسارت (و عمدتا از جنس بطول انجامیدن پروژه و افزایش هزینه های سربار) به پیمانکار شده.

سناریو دوم: فرض بگیرید که پیمانکار مالک شناوری باشد و از شناوری فعالیتی استفاده نموده و منجر به بحرانی شدن و تاخیر در اجرای پروژه شده. تو این حالت نهایتا مشخصه که آن مقدار تاخیری که باعث به تاخیر افتادن پایان پروژه توسط پیمانکار شده غیر مجازه. یعنی اینکه پیمانکار سبب وارد کردن نوعی خسارت و عمدتا از تاخیر در بهره برداری پروژه به پیمانکار شده.

با این تفاسیر مشخص میشه که بحث مالکیت شناوری خیلی هم بحث پیچیده و حساسی نیست و فقط کافیه که شناوری را متعلق به پروژه بدانیم، البته در شرایط و سناریوهای خیلی خاص و حساس که البته بندرت نیز این اتفاق می افتن موضوع مالکیت شناوری پر رنگ تر میشه و البته عمدتا این حساسیت ها مربوط میشن به بحث تاخیرات همزمان که نباید اونو با مالکیت شناوری اشتباه بگیریم، سناریو شماره سوم یکی از موارد تاخیرات همزمان رو تشریح میکنه.

سناریو سوم: فرض بگیرید یک فعالیت یا بسته کاری مثل اجرای سرامیک کف 20 روز شناوری کل داشته باشه، و از این مقدار کارفرما با تاخیر 15 روزه در تایید متریال نمونه سرامیک را تایید کرده باشه، پس از تایید متریال توسط کارفرما پیمانکار هم بنا به دلایلی مثل تاخیر در جذب پیمانکار دست دوم 10 روز تاخیر ایجاد کرده است که نهایتا این مقدار تاخیر کارفرما و پیمانکار باعث شده است که تاریخ پایان کل پروژه 5 روز جابجا بشه، حالا تو این حالت آیا مقصر تاخیر حادث شده کارفرماست و یا پیمانکار؟

پاسخ: در مواجه با چنین حالت های می توان از سه تکنیک: الف) روش تقسیم ب) روش عامل اصلی ج) روش شروع تاخیر استفاده کرد. (که بعدا در موردشون توضیح خواهم داد).

نتیجه گیری: بنظر من بهتره که همیشه شناوری را به پروژه تخصیص بدیم و نه به ارکان پروژه و تا زمانیکه خسارتی به طرف مقابل وارد نشده باشه (چه خسارت ریالی و چه خسارت زمانی) مالکیت شناوری هم معنی نداره.

 





نوع مطلب :
برچسب ها : مالکیت شناوری، مدیریت ادعا، تاخیرات همزمان، بررسی گزارش تاخیرات پروژه، لایحه تاخیرات،
لینک های مرتبط :

خوندن این مطلب 3 دقیقه زمان می خواد.

برای محاسبه تاخیرات در پروژه های که به هر علت مشمول ماده 46 و یا 48 میشن، بایستی مطابق بند 5 ماده 50 شرایط عمومی پیمان عمل کنید. در ادامه شرح این بند رو می تونید بخونید.

"بند5- در صورتی كه پیمان، طبق ماده (46) فسخ گردد یا طبق ماده (48)، به پیمان خاتمه داده شود، تأخیر كار نسبت به برنامه زمانی تفصیلی با رعایت ماده (30) بررسی شده، میزان مجاز و غیرمجاز آن تعیین می‌شود. بابت تأخیر غیرمجاز پیمانكار، طبق مفاد این‌ بند، پرداخت خسارت تأخیر به پیمانكار تعلق می‌گیرد. در این حالت، مبلغ باقیمانده كار كه در اجرای آن تأخیر شده است، عبارت است از مبلغ كارهایی كه طبق برنامه زمانی تفصیلی و با در نظر گرفتن تأخیر مجاز پیمانكار باید تا تاریخ فسخ یا خاتمه پیمان انجام می‌شد، منهای مبلغ كار انجام شده".

در بند فوق بصورت کاملا صریح به محاسبه تاخیرات نسبت به برنامه زمان بندی اشاره شده، و تو این مطلب قصد دارم تا چگونگی استخراج این تاخیرات رو از برنامه زمان بندی تفصیلی توضیح بدم.

برای مشخص کردن تاخیرات پروژه از روی برنامه زمان بندی باید مراحل زیر را به ترتیب انجام بدید.

1-     وارد کردن تاریخ شروع واقعی فعالیت ها شروع شده

2-     وارد کردن درصد پیشرفت واقعی فعالیت ها در ستون %Complete

3-     وارد کردن تاریخ واقعی پایان فعالیت ها تکمیل شده

4-     اضافه کردن ستون Finish variance به برنامه زمان بندی

نکته: باید مراقب باشید با توجه به اینکه ستون  Finish variance  فقط تاخیرات کاری را نمایش میده، برای محاسبه تاخیرات از تقویم غیر کاری استفاده کنید، چرا که ملاک محاسبه تاخیرات پروژه روزهای تقویمی ست و نه روزهای کاری، به همین دلیل می توان برای حل این مسئله از دو روش کمک بگیرید، یکی اینکه بیایم و روزهای غیر کاری تقویم تخصیص داده شده به پروژه را به روزهای کاری تبدیل کنیم (که با توجه به اینکه این کار سبب میشه که تاریخ فعالیت ها هم جابجا بشه استفاده از این روش رو اصلا پیشنهاد نمی کنم) و اما روش دوم که درست تر هم هست این هست که بیایم و با کمک یک فیلد کمکی ستون تاخیراتی مبتنی بر روزهای تقویمی ایجاد کنیم (می تونید با کمک گرفتن از ستون های مدت زمان این کار را براحتی انجام بدید).

فرمول مقدماتی این روش برابره با: Duration1 = Finish - Base line finish که در این فرمول مقدار Finish  همان ستون اصلی نرم افزاره و Base line finish برابره با تاریخ پایان برنامه ای.

پس از اینکه داده های واقعی را تا تاریخ خاتمه یا فسخ پیمان در برنامه زمان بندی وارد کردید برای فعالیت ها سه تا حالت پیش میاد. 1- فعالیت های که هنوز شروع نشدن 2- فعالیت های که شروع شدن ولی تکمیل نشدن 3- فعالیتهای که 100% تکمیل شدن. پس از این مرحله شما باید حتما حتما برنامه را Reschedule کنید تا سایر فعالیت های که دارای تاخیر هستن هم جلو کشیده بشن تا تاخیرات پروژه بدرستی محاسبه بشه، (پس از انجام این کار حالا باید تاخیرات پروژه را از فیلد Duration1 بخونید).

نکته 1: چنانچه برنامه را Reschedule نکنید تاخیرات نمایش داده شده در ستون تاخیرات کل پروژه واقعی ای نیست، چرا که بسته به نوع پروژه امکان داره که فعالیتی که هیچ گونه پیشنیازی نداشته و شروع هم نشده است به جلو کشیده نشه، ولی Reschedule کردن برنامه سبب میشه که با توجه به جلو کشیده شدن فعالیت ها تاخیرات پروژه کاملا درست محاسبه بشه.

نکته 2: به هیچ عنوان مجاز نیستید که تاخیرات پروژه را بصورت خطی و براساس درصد پیشرفت و مدت زمان سپری شده بدست بیارید، مثلا اینگونه تحلیل کنید که با توجه به اینکه مطابق برنامه تا تاریخ خاتمه یا فسخ قرارداد می باید 60% پیشرفت برنامه ای داشته باشیم ولی 40% پیشرفت واقعی داریم پس با توجه به مدت زمان اولیه و مدت زمان سپری شده پس نهایتا A روز تاخیر داریم.

نکته 3: متاسفانه بعضی از نرم افزارها مانند پراجکت خیلی خوب قادر به محاسبه تسریع زمان پروژه به راحتی نیستند، چنانچه موضوع تسریع در میان باشد شما علاوه بر کارهای بالا برای محاسبه تاخیرات باید مدت زمان تخمینی جهت تکمیل کارها را هم وارد کنید و بعدش برنامه را Reschedule کنید.

نکته 4: ظاهرا در بند 5 ماده 50 شرایط عمومی پیمان به اشتباه پرداخت خسارت به تاخیرات غیر مجاز پیمانکار تعلق گرفته است که باید بدینگونه اصلاح شود. "می بایست بجای کلمه پرداخت خسارت بابت تاخیرات غیر مجاز به پیمانکار از کلمه پرداخت خسارت بابت تاخیرات مجاز به پیمانکار استفاده بشه".

نکته 5: به نظرتون حالا چنانچه برنامه مشکل داشته باشد (بطور مثال شبکه برنامه ناقص باشد و بسیاری از پیش نیاز ها و پس نیازها تعریف نشده باشند) باید چیکارش کرد؟ 





نوع مطلب :
برچسب ها : چگونگی محاسبه تاخیرات در پروژه های ناتمام، ماده 46 شرایط عمومی پیمان، ماده 48 شرایط عمومی پیمان،
لینک های مرتبط :

یکی از سئوال های که خیلی پرسیده میشه اینه که من بعنوان کارشناس کنترل پروژه چطور باید هزینه های واقعی انجام شده پروژه (AC) را از واحد حسابداری سازمان بگیرم؟ آخه مهندس مشکل اینجاست که معمولا سیستم حسابداری ما چندین ماه عقبه، اونا اصلا نمیفهمن ساختار شکست پروژه چی هست و ...، نهایتا آخر سر هم چند تا فحش نثار بچه های حسابداری میکنن که اینا اصلا سرشون نمیشه چی به چیه، برای مدیر عامل هم که توضیح دادم تازه متوجه شدم که اون از همه اسکل تره!!!

بگذریم، بنظرتون تو این شرایط و یا شرایط مشابه دیگه باید چیکار کرد؟ آیا باید بی خیال گزارش هزینه شد؟ یا اینکه نه اتفاقا باید خیلی هم باخیال بود؟

خود من معمولا تو چند شرکتی که تا حالا وارد شدم داستان همین بوده و هست ولی نهایتا ظرف یه مدت کوتاه تونستم مشکل رو حل کنم، خب حالا چطور مشکل رو حل کردم، اینطوری:

روز اول یه گزارش یک الی دو صفحه ای از یه پروژه تهیه میکنم و برای مدیر عامل میفرستم و تو اون گزارش بصورت کاملا صریح و شفاف می نویسم که در حال حاضر هیچکس نمیدونه وضعیت پروژه چطوره، احتمالا در پایان پروژه شاید ضرر خیلی سنگینی بدیم و شاید هم نه، براش مینویسم که عقل سلیم حکم میکنه در چنین شرایطی تشکیل جلسه فوری بدیم. (معمولا تو این مرحله مدیر عامل یجوری بهتون اطلاع میده که جهت مذاکره برین پیشش و براش توضیح بدید که این دورغ های که میگین راسته یا نه)، تو این مرحله شما نباید از مدیر عامل انتظار داشته باشید و بخواید که یهوی براتون کن فیکون کنه و همه هزینه ها رو دقیقا براساس نقاط کنترلی و ساختار شکست پروژه و منطبق بر هزینه واقعی ارزش ایجاد شده (نه کل هزینه های ثبت شده) در پروژه مطابق آخرین مباحث مدیریت هزینه در استاندراد PMBOK6 در اختیارتون بذاره، شاید هم دیوانه باشید و از مدیر عامل بخواید که WBS برنامه زمان بندی رو تو همون لحظه وصل کنه به سیستم حسابداری شرکت (اونم مثلا تو یه شرکت رتبه 3و 2).

خب آخه این واقعا چه منطقیه که خیلی از همکارا دارن؟ آخه دوستان عزیز این چه قیافه حق بجانبی هست که برا خودتون قائل میشید؟ واقعا اگه اونا این چیزا رو میدونستن دیگه به وجود ماها نیاز داشتن؟

تو این مرحله بسته به بزرگی شرکت شما باید با مدیر ارشد شرکت صحبت کنید و ازشون بپرسید که آیا اصلا صلاح میدونن که کنترل هزینه و درآمد پروژه های شرکت دست شما باشه یا نه؟ آیا اصلا گزارشات دوره ای منظم کوتاه مدتی در این خصوص دارن یا نه؟ مثلا ازش بپرسید که اگه همه اطلاعات مالی بروز وجود داشته باشه به چه گزارش های برای تصمیم گیری درست نیاز داره؟ و سئوالات دیگه ای از این دست، تو همین مرحله شما باید یسری گزارش از اون چیزی که مد نظرتون هست و قراره خروجی نهایتون باشه بصورت سوری هم که شده همراهتون داشته باشید و برای مدیرتون ارائه کنید تا دیدش نسبت به هدف نهایی باز بشه تا راحت تر بتونه اطلاعاتی رو که میخواید در اختیارتون بذاره، خب اگر اینجوری برید جلو میشه امیدوار بود که در آینده نچندان دور به اهدافتون می رسید، حالا فرض کنید که تونستید توجه مدیر عامل رو نسبت به قضیه جلب کنید، حالا باید ازش بخواید با توجه به اینکه گزارشات هزینه های پروژه تون بروز نیست حداقل جهت بررسی و برای شروع اطلاعات مثلا 4 ماه پیش رو در اختیارتون بذاره (هیچ اشکالی نداره برای شروع خیلی هم خوبه)، بعد از اینکه هزینه های پروژه رو تونستید بگیرید (تو این مرحله نباید انتظار داشته باشید که هزینه ها به تفکیک در اختیارتون قرار بگیره احتمالا فقط یه عدد بهتون اعلام کنن برای کل پروژه)، باید تشکیل جلسه بدید و گزارشتون رو همونطوری که تو این لینک قبلا گفتم ارائه بدید و حتما از قسمت حسابداری هم کسانی تو جلسه حضور داشته باشن، تو جلسه باید بیان خوبی داشته باشید و بتونید با زیرکی خواسته ها و نیازهاتون رو بگید، مثلا بگید که ای کاش هزینه ها رو به تفکیک ابنیه، تاسیسات مکانیکی و برقی داشتیم تا با آیتم های صورت وضعیت 4 ماه پیش مقایسه میکردیم ببینیم داریم سود می کنیم یا ضرر، ولی در حال حاضر چون نداریم مجبوریم در سطح پروژه وضعیت رو بررسی کنیم و البته با داده های که احتمال درست بودنشون در حال حاضر بالای 75% هست، ای کاش می تونستیم 4 ماه عقب ماندگی هزینه ها رو با جذب یکنفر یا حل بعضی از مشکلات حسابداری به سه ماه می رسوندیم، اینجا باید رو کنید به مدیر حسابداری و بهش بگی راستی شما چه پیشنهادی دارید تا این مشکل حداقل یک ماه برطرف بشه چون بهرحال شما تو این زمینه از همه ما استادتر هستی ما واقعا به این اطلاعات نیاز داریم. ای کاش تیم مدیریت پروژه ما می تونست که هزینه های باقیمانده کار رو تخمین بزنه بهرحال اگه همه هزینه ها رو تا الان هم داشته باشیم باید آینده رو باهاش بررسی کرد، ای کاش میشد ما هم مثل فلان شرکت رقیب مون می تونستیم فلان آنالیز ها رو انجام بدیم (ازتون خواهش میکنم که سعی کنید اسمی از شرکت های ژاپنی و آمریکایی نگید تو این مرحله، سعی کنید شرکتی رو نام ببرید که اولا ازش خبر داشته باشید و بعدشم هم طراز شرکت خودتون باشه نه یه سر و گردن از خودتون بالاتر باشه). مطمئن باشید تو اون جلسه این ای کاش ها و این درخواست ها جواب میده و هر کسی یه پیشنهادی میده تا اون مشکل حل بشه، تو این مرحله باید پیشنهادهای رو که مورد توافق همه هست رو سریع صورتجلسه کنید و براش یه تاریخ و مسئول مشخص کنید و البته تاریخ جلسه بعد رو هم مشخص کنید تا با اطلاعات دقیق تر و مفصل تر برگزار بشه، بعد از اینکه چند جلسه برگزار شد سطح توقعات مدیران هم یواش یواش میاد بالا و اطلاعات دقیق تر ازتون میخوان و اینجاست که شما هم باید ای کاش ای کاش گفتن هاتون رو ببرید بالاتر، مثلا بگیم ای کاش میشد از فلانی دعوت کنیم یه جلسه آموزشی برامون بذاره (مثلا مقدسی)، ای کاش میشد از فلان شرکت بازدید کنیم ببینیم اونا چیکار میکنن، ای کاش میشد فلان نرم افزار رو بخریم یا بنویسیم، ای کاش میشد بودجه بندی هم داشته باشیم. پس از یه مدت می بینید که دارید به خواسته هاتون می رسید و هر آنچه رو که لازم دارید در اختیارتون میذارن و بهتون اعتماد میکنن، قبلا هم گفتم هیچ جای دنیا تو هیچ زمینه ای یادگیری و پیشرفت انقلابی وجود نداره هر آنچه که هست باید تدریجی اتفاق بیفته نه انقلابی.

و اما چند نکته مهم:

1-     شما نباید تو جلسات بخواید اثبات کنید که دانشتون از همه بیشتر هست و بقیه هیچی نمیدونن و یه شکاف بین خودتون و بقیه ایجاد کنید چون دقیقا اونا هم در مورد شما همین فکر رو میکنن.

2-     سعی کنید از خرد جمعی استفاده کنید و برای پیشنهادهای بقیه احترام قائل باشید و سعی کنید کسی که پیشنهاد رو داده را بعنوان مسئول اجرای همون کار بذارید نه کس دیگه ای رو.

3-     پس از اتمام جلسات حضوری با تک تک اعضا ملاقات کنید و نظرشون رو بپرسید و جلسات رو مدام بهبود بدید.

4-      مرتبا تو دوره های آموزشی شرکت کنید و مطالعه کنید تا مثلا بلاخره بعد از ده سال بفهمید که بهترین فاکتور برای پروژه استفاده از فاکتور ریالی هست، و فاکتورهای فیزیکی، زمانی و ... بدرد بخور نیستن.





نوع مطلب :
برچسب ها : جمع آوری داده های واقعی، هزینه های واقعی، AC،
لینک های مرتبط :

یکی از وظایف خیلی مهم بچه های برنامه ریزی و کنترل پروژه تهیه و ارسال گزارشات پروژه هست، یعنی اینکه طی بازه های مشخص مثلا روزانه، هفتگی و یا ماهیانه برای افراد مشخصی یسری گزارش روتین تهیه و ارسال میکنن و معمولا هیچ بازخورد جدی هم از طرف مقابل دریافت نمی کنن، خب من اساسا با ارسال گزارش برای مدیران مخصوصا ارشد شدیدا مخالف هستم و به شما هم پیشنهاد میکنم که به هیچ عنوان گزارشات رو تا حد ممکن سعی کنید ارسال نکنید و باید سعی کنید این گزارشات رو ارائه کنید، (البته اگه مثلا تو جایگاه پیمانکار باشید و طبق قرارداد کارفرما ازتون خواسته باشه که این کار رو انجام بدید چاره ای نیست باید بفرستید) من بیشتر منظورم ارسال گزارشات داخلی سازمان هست، بطور مثال فرض کنید شما کارشناس برنامه ریزی و کنترل پروژه تو یه شرکت پیمانکاری هستید و قراره گزارش چند تا از پروژه ها رو هر ماه برای مدیریت ارسال کنید، خب فکر می کنید پس از ارسال چه اتفاقی میفته؟؟؟ من بهتون میگم که چه اتفاقی میفته، معمولا مدیران پیشرفت واقعی پروژه و انحراف رو یه نگا میندازن و بقیشون رو ورق میزنن و میزارن کنار (و البته بندرت هم بسته به جایگاه اون مدیر هم یکسری بازخورد هم ممکنه که بهتون داده بشه).

نقاط ضعف روش ارسال گزارشات اینا هستن:

1-     مدیران مثل شما متخصص نیستن و حتی اکثر اونا تفاوت انحراف و تاخیر رو نمیتونن تشخیص بدن چه برسه به اینکه بدونن شاخص CPI و SPI چیه و به چه دردی میخورن نهایتا اینکه هر کی از ظن خویش یه برداشتی از این آمار و ارقامتون میکنه و معمولا هم فکر میکنه که درست استنباط کرده.

2-     شما پیشرفت نمی کنید چرا که هیچ بازخوردی از طرف مقابل نمی گیرید که دقیقا بدونید مدیران بیشتر دنبال چه چیزهای هستن و همیشه مدیرانتون رو به بیسوادی محکوم می کنید (و البته اونا هم همین تصور رو در مورد ماها دارند متاسفانه).

3-     اشکالات و ایرادات سیستمی هیچ وقت رفع نمیشن، مثلا اگه واحد حسابداری نتونه به شما مقدار هزینه واقعی پروژه رو بده معمولا شما هم مجبور هستید تو گزارشتون چیزی در این خصوص نیارید و فقط به انحراف، تاخیر و پیشرفت بپردازید و مدیرتون هیچ وقت این نقاط ضعف رو به وضوح نمیبینه حال اینکه اگر گزارشتون رو برای مدیرانتون دور همی ارائه بدید و بهشون آلارم بدید که وقتی هزینه واقعی اجرای کار مشخص نباشه، نه من و نه شما نمی تونید تصمیم درستی بگیرید و واقعا هیچ کس نمیدونه تو آینده چه اتفاقی میفته، برای همین همه میان تو تیم شما و با کمک خرد جمعی سعی میکنن هر جور شده اطلاعات مورد نیازتون رو در اختیارتون بذارن (مثل نرم افزار جدید بخرن و یا یه نفر اینکاره به سیستم اضافه کنن و ... ).

4-     فرمت گزارشاتتون همیشه ثابت میمونه و تغییری نمیکنه و این یعنی درجا زدن و عدم پیشرفت (اگر طی یکی دوماه با هر سال سابقه کار که هستید فرمت گزارشاتتون مدام بهبود پیدا نکنه و مثلا فیلدها و شیت های گزارشتون کم و زیاد نمیشه این اصلا نشونه خوبی نیست و داره نشون میده که حرفه ای عمل نمی کنید و کاملا آماتور هستید).

و اما وقتی گزارشتون رو ارائه میدید خیلی داستان فرق میکنه، محاسن ارائه گزارش خیلی زیاده، منتهی اگر محوریت جلسه رو شما در دست بگیرید:

1-  همه مدیران (مدیر عامل، مدیر پروژه، کارشناسان فنی، مدیر تدارکات، مدیر مالی و ...) در جلسه حضور دارند و از زوایای مختلفی پروژه ارزیابی میشه و همه تو جریان مشکلات یکدیگر و پروژه قرار میگیرن.

2-  جلسه خروجی های مشخصی در قالب صورتجلسه داره و تو این جلسات راهکارهای عملی و مورد توافق همه ارائه میشه (این یعنی حل شدن بعضی از مشکلات پروژه).

3-  شما مدام با بازخوردهای که میگیرید پیشرفت می کنید و طی یه مدت کوتاه تجارب خیلی ارزنده ای بدست میارید.

4-  گزارشات مدام اصلاح و بروز میشن و به خواسته های مدیرانتون نزدیک تر میشن و توهم باسوادی و بی سوادی و متهم کردن همدیگه از بین میره.

5-  یکسری از مشکلات سازمان بصورت ریشه ای حل میشن بطور مثال شما یه شیت آنالیز سود و زیان ارائه می کنید و قسمت هزینه های واقعی رو خالی میذارید و به همه اعلام می کنید که نداشتن هزینه های واقعی تا چه حد مشکل ایجاد میکنه. یا مثلا ممکنه که به این نتیجه برسید که واحد تدارکات نیاز به خرید نرم افزار داره و ...

6-  سطح دانش و بلوغ مدیریت پروژه تو سازمان بالا میره و یه زبان مشترک بینتون ایجاد میشه.

7-  اگر به هر دلیل جلسه و ارائه شما برگزار نشه مطمئن هستید که با ارسال گزارش به مدیران میدونن به چه چیزی اهمیت بدن و کجاها رو با دقت بخونن، چون طی جلسات دانش لازم رو بدست آوردن.

8-  شما براحتی متوجه دغدغه اصلی مدیران ارشدتون در خصوص هر پروژه میشید، مثلا یه پروژه زمانش خیلی بحرانیه، یکیشون کیفیت توش خیلی مهمه، یکیشون ضرر نده باید کلاهمون رو بندازیم هوا، یکیشون سود کم بده مصیبته و ...

تنها نقطه ضعف روش ارائه گزارشات اینه که ممکنه هماهنگ کردن جلسات یکم سخت باشه که اونم بعد از یه مدت میفته رو روال و اکی میشه.

نکته مهم: من معمولا با هر شرکتی که تا حالا کار کردم، تو اولین اقدام ابتدا گزارشات رو پرینت می گیرم و تشکیل یه جلسه میدم و تو اون جلسه مهره های کلیدی رو دور هم جمع میکنم و هر آنچه که لازم هست رو ارائه میدم و دقیقا پس از جلسه اول می بینم که شرکتی که پیش از من اصلا به این گزارشات کمترین اهمیت رو نمیداده میز کنفرانس و ویدیو پروژکتور تهیه کرده و مدام خواستار تشکیل جلسه و بحث آموزش هستش.





نوع مطلب :
برچسب ها : تهیه گزارشات حرفه ای پروژه، ارائه حرفه ای گزارشات پروژه،
لینک های مرتبط :


یکی از مواردی که همیشه تو بررسی گزارش تاخیرات فنی و اعمال آیتم های تاخیر در برنامه زمان بندی بحث زیادی ایجاد میکنه و وقت جلسات رو هم زیاد میگیره، این موضوع خوش ساخت نبودن برنامه زمان بندیه، و اغلب دلیلش هم اینه که در همون ابتدای تهیه برنامه زمان بندی پروژه، کارشناس های محترم حواسشون به پایان پروژه و بررسی گزارش تاخیرات نیست و اغلب همه ارتباطات درست بسته نمیشه، مراقب زیاد بودن شناوری ها عمدا یا سهوا نیستن (چون شناوری هم مثل تیغ دولب عمل میکنه)، روابط احتیاطی رو از قلم میندازن و احتمالا بعضی جاها قید های نابجا قرار میدن و نوع فعالیت ها رو هم درست انتخاب نمی کنن (و البته قضیه زمانی خیلی حادتر میشه که یه کارشناس خارجی از بیرون یه مبلغی رو میگیره و یه برنامه تحویل میده و میره پی کارش)، خب با این تفاسیر اگه ما تو چنین شرایطی گیر افتادیم باید چیکار کنیم؟؟؟

طبق معمول بهترین راه حل این هستش که از همون ابتدا از این داستان پیشگیری کنیم مثلا اگر در جایگاه مشاور و یا کارفرما هستیم یه دستورالعمل به پیمانکار ابلاغ کنیم و قواعد مثلا نوزده گانه زمان بندی رو از پیمانکار بخوایم که رعایت کنه و اگر هم پیمانکار هستیم که خودمون با یکم دقت مراقب خوش ساخت بودن برنامه باشیم و از استانداردهای که تو این زمینه هستن کمک بگیریم.

حالا اگه به هر دلیلی این اتفاق نیفتاد باید چیکار کرد؟

پیشنهاد من این هست که قبل از اعمال آیتم های تاخیر در برنامه زمان بندی خوش ساخت بودن برنامه رو چک کنید و اگر احیانا فعالیتی پس نیاز نداشت و یا مثلا شناوری زیادی داشت اصلاحش کنید، در یک کلام باید بجای چشم پوشی از خطا اونو اصلاحش کنید، البته متاسفانه بعضا مشاورها و یا کارفرما در این خصوص مقاومت بی مورد میکنن و بنا به دلایلی زیر بار اصلاح برنامه نمیرن، که در چنین شرایطی باید با بحث منطقی و کارشناسی و استفاده از مثال های نقض بتونید اونا رو متقاعد کنید (که کار خیلی راحتی هم نیست). بررسی خوش ساخت بودن برنامه باید پیش از اعمال آیتم های تاخیر در برنامه صورت بگیره تا یک جانبه نباشه و اگر هم قرار شد که با همون برنامه کار رو پیش ببرید دیگه نمی تونید یه تیکش رو اصلاح کنید و بقیش رو به حال خودش بذارید.

نتیجه گیری: پس یا رومی روم و یا زنگی زنگ، نمیشه هر جا به نفعتون باشه برنامه رو اصلاح کنید و هر جا به ضررتون باشه عکسش رو انجام بدید. ضمنا باید مراقب باشید که قبل از وارد کردن آیتم های تاخیر بر سر فرض کردن اینکه برنامه ایرادی نداره به توافق برسید، اگر وسط وارد کردن برنامه متوجه بشید که مثلا به دلیل داشتن شناوری های زیاد تاخیر در پایان پروژه ایجاد نمیشه دیگه خیلی دیر هست که بخواید اثبات کنید که برنامه ایراد داره، پس خیلی بهتره که باید بجای چشم پوشی از خطا اونو اصلاح کنید.

 

 





نوع مطلب :
برچسب ها : اعمال تاخیرات در برنامه زمان بندی، تاخیرات فنی پروژه،
لینک های مرتبط :

تو مطلب قبلی که در مورد واقع بینانه نبودن تخمین پایان پروژه به روش ES در اواخر پروژه نوشته بودم یه چیزهای رو اشتباه گفتم که الان میخوام درستش رو بهتون بگم.

تو مطلب قبلی گفته بودم که چون تحلیل زمان کسب شده بر اساس 100% تکمیل پروژه هست و ما پروژه را معمولا وقتی بالای 96% میشه رو تحویل موقت می کنیم، پس این باعث میشه تخمین روش ES خیلی بدبینانه باشه، خب حالا میخوام این حرفم رو به این صورت اصلاح کنم که اگه طبق تجاربتون تو پروژه ها همچین اتفاقی میفته بیاید و تحلیل زمان کسب شده را متناضر با 96% پیشرفت محاسبه کنید نه 100% که براحتی میشه این کار رو انجام داد.

یه نکته که در مورد پایان پروژه هست اینه که نسبت کارهای پیش‌بینی نشده به کارهای برنامه‌ریزی شده فرق می‌کنه و این می‌تونه نتیجه رو تحت تاثیر بذاره.

با تشکر از جناب مهندس نادر خرمی راد بابت همفکری های همیشگی شون





نوع مطلب :
برچسب ها : تخمین پایان پروژه به روش زمان کسب شده (ES)، تخمین مدت زمان پایان پروژه،
لینک های مرتبط :

قبل از اینکه بخوام برم سراغ اصل مطلب نیازه که یه مقدمه کوتاه بگم و بعد بحث اصلی ام رو شروع کنم،

خب احتمالا همونطوری که میدونید میشه گفت سه روش برای محاسبه تخمین پایان پروژه وجود داره (شاید هم من فقط همین سه تا را بلدم)، اولیش میشه نظر کارشناس خبره (یعنی اینکه از یه نفر یا گروهی از آدم های خبره بپرسید که با توجه به شواهد و براساس تجربیاتشون بگن که احتمالا پروژه کی تموم میشه، استفاده از این روش جواب های سریعی به شما میده ولی خوب اصلا دقت خوبی نداره و معمولا این تاریخ در قالب صورتجلسات بعد از یه کم چکش کاری توسط بقیه نفرات حاضر در جلسه مشخص میشه). دومیش میشه استفاده از تکنیک CPM و محاسبه تاخیرات روی مسیر بحرانی (تو این حالت برنامه رو به تاریخ بروز آوری ریسکجول می کنید و با جابجا شدن تاریخ پایان پروژه مشخص میشه که اگر از این به بعد بتونیم  مطابق برنامه پیش بریم احتمالا پروژه کی تموم میشه، خب البته استفاده از این روش زیاد از حد خوشبینانه ست چون مخصوصا تو پروژه های کشور ما این اتفاق بندرت هم نمیفته که بخوایم منبعد مطابق برنامه عمل کنیم). سومیش میشه استفاده از روش زمان کسب شده یا همون (Earned Schedule) (این روش زمانیکه پیشرفت واقعی پروژه معمولا بالای 20% هست نتایج فوق العاده عالی و نزدیک به واقعیت داره، تو این روش فرض بر اینه که اگر منبعد با سرعتی معادل سرعتی که از ابتدا تا حالا داشتیم پیش بریم تو چه تاریخی پروژه را تموم می کنیم).

نکته: بهتون پیشنهاد میدم برای یه مدت از هر سه روش در کنار هم استفاده کنید و پس از اینکه پروژه تحویل موقت شد به عقب برگردید و نتایج رو تو بازه های مختلف بررسی کنید تا ببینید کدوم روش جواب های مناسبتر و نزدیک به واقعیت بهتون میداده.

من خودم از هر سه روش تو پروژه های که مشغولم استفاده میکنم و همیشه نتیجشون رو نسبت به هم ارزیابی میکنم و البته معمولا زمانیکه پیشرفت پروژه بین 20 تا 93 درصد هست استفاده از تکنیک زمان کسب شده (ES) بهترین نتایج رو داشته و همچنان داره، ولی جدیدا متوجه شدم که هر چی به سمت پایان پروژه (تحویل موقت) بیش از 93 درصد پیشرفت پیش میریم تخمین های که این تکنیک داره بهم نشون میده بیش از حد بدبینانه هست و شاید بگم بهتره که در بعضی موارد از ارائه شون صرفنظر می کنم، به همین خاطر تو این برهه معمولا میرم سراغ استفاده از تکنیک مسیر بحرانی چون بنظرم واقع بینانه تر میاد، من کلی در این مورد با خودم فکر کردم و گفتم که چطور میشه استفاده از این تکنیک با وجود اینکه هر چی پیشرفت پروژه بیشتر میشه باید نتایجش دقیقتر بشه ولی در آخر کار این اتفاق نمیفته و تونستم به چند نتیجه جالب البته از نظر خودم برسم، که قصد دارم بگم.

1-     تخمین های که این تکنیک (ES) داره میده، واقعا تا زمان پایان و تکمیل 100% و نهایی پروژه هست در حالیکه ما معمولا پروژه را بالای 95% (همینکه قابل بهره برداری باشه) تموم شده می دونیم و اون رو تحویل موقت می کنیم.

2-     حالا اگر مدت زمان صرف شده واقعی جهت رفع نواقص رو هم به تاریخ تحویل موقت اضافه کنیم متوجه میشیم که بازهم نتایج زمان کسب شده به مراتب نسبت به سایر روش ها خیلی به واقعیت نزدیک تر بوده، (الان دارم متوجه میشم که تخمین های این روش تا زمان تکمیل 100 درصدی پروژه هست و نه تا زمان تحویل موقت).

3-     در بسیاری از مواقع در طول اجرای پروژه بنا به یسری دلایل منطقی و غیر منطقی مشاور و کارفرما درصدهای پیشرفت واقعی پیمانکار رو کمتر از آنچه که هست برآورد میکنن و تخمین میزنن، برای همین نتایج این روش در پایان با اضافه کردن یک مرتبه پیشرفت ها بهم میخوره.

4-     با توجه به اینکه روش مسیر بحرانی بیانگر این است که منبعد با سرعتی معادل سرعت برنامه کار کنیم و زیاد از حد خوشبینانه است ظاهرا اینجور بنظر میرسه که داره تخمین رو تا زمان تحویل موقت در نظر میگیره نه تا پایان رفع نقص همه موارد و تحویل نهایی به کارفرما، برای همین این تخمین بنظر بهتر میرسه (هر چند که این تخمین هم پروژه را تا تکمیل 100% در نظر میگیره ولی تو اواخر پروژه بخاطر خوشبینانه بودنش انگار منطقی تر بنظر میرسه).

نکته: زمانیکه میخواید یه گزارش رو ارائه بدید حتما در مورد هر تخمین توضیحات لازم رو بدید و در بعضی موارد خاص هم که فکر می کنید تخمین ها زیاد از حد پرت هستن باید سعی کنید از شهود خودتون هم کمک بگیرید تا راحت تر متوجه بشید که کدام تخمین به واقعیت نزدیک تر هستن (که البته این هم برمیگرده به اینکه شما چقدر نسبت به پروژه آشنا هستید).

مواردی که در بالا گفته شد صرفا تجربیات فعلی بنده هست ولی به احتمال خیلی زیاد در آینده با تست موارد گفته شده روی یسری پروژه نمونه، نتایج آن بصورت کاملتر در دسترس عزیزان قرار میگیره.

 

 





نوع مطلب :
برچسب ها : روش های تخمین پایان پروژه، CPM، ES، تخمین به روش زمان کسب شده،
لینک های مرتبط :

شاید برای شما همه پیش اومده باشه که بنا به دلایلی مثل تعلیق پروژه از طرف کارفرما و یا بخاطر برف و باران و طوفان (حوادث غیر مترقبه) پروژه تون یا بخشی از فعالیت ها برای مدتی تعطیل شده باشن، حالا کاری که همه تقریبا برای بروز آوری انجام میدن این هستش که دیگه رو برنامه هیچ کاری انجام نمیدن و پس از اینکه دوباره کارگاه یا اون فعالیت ها فعال شد میان و تاریخ های پایان واقعی رو برای فعالیت های که در حال پیشرفت بودن رو وارد میکنن و عملا مشکلی که پیش میاد اینه که مدت زمان اجرای فعالیت ها بصورت غیر واقعی زیاد میشه (مخصوصا زمانی که به پروژه برای سه ماه تعلیق میخوره)، خب تا این مرحله امیدورام متوجه داستان شده باشید حالا در ادامه میخوام بگم که باید چطور برنامه را باید خیلی حرفه ای بروز کرد.

تو این حالت باید بجای وارد کردن تاریخ های پایان واقعی، بیاید و روز های رو که پروژه تعطیل بوده رو از تقویم تخصیص داده شده به اون تعطیل کنید، اگر هم تعطیلی فقط مربوط به یکسری فعالیت بخصوص هست باید از تقویم پروژه یه کپی براشون تهیه کنید و اونو برای اون فعالیت های خاص سفارشی کنید.

نکته مهم: اگر از فرمول های محاسبه پیشرفت به روش ارزش کسب شده پیشرفت برنامه ایتون رو بدست میارید نباید نگران این قضیه باشید که با تغییر تقویم پیشرفت برنامه ایتون بهم بخوره ولی اگه از فرمول های دستی برای محاسبه پیشرفت برنامه ای استفاده می کنید چرا باید حتما نگران باشید چون پیشرفت برنامه ایتون تغییر میکنه که درست نیست، پس تو این حالت باید فرمول های محاسبتون رو تغییر بدید.

و در آخر اینکه تو پریماورا و پرت مستر هنوز تست نکردم ببینم چه اتفاقی تو این حالت برای بیس لاین میفته.





نوع مطلب :
برچسب ها : بروز کردن برنامه زمان بندی، تقویم پروژه، تعلیق در پروژه،
لینک های مرتبط :

احتمالا اگه با بخشنامه های محاسبه تاخیرات مالی آشنایی نداشته باشید عنوان این مطلب یکم براتون گیج کننده باشه ولی خب تو بخشنامه 5090 یه فرمولی وجود داره در مورد محاسبه تاخیر در پرداخت قسط دوم و سوم پیش پرداخت که بعضی اوقات وقتی قسط اول تو چند مرحله توسط کارفرما پرداخت میشه مشکل سازه، حالا میخوام برای اینکه نحوه محاسبه تفاضل تاریخ آخرین صورت وضعیت و دریافت اولین پیش پرداخت رو در این شرایط خاص توضیح بدم از یه سئوال کمک بگیرم و بعد چند نکته تکمیلی رو هم در پایان بگم.

سوال) در صورتیکه قسط اول پیش پرداخت در سه مرحله پرداخت شده باشه تکلیف تفاضل تاریخ ارسال آخرین صورت وضعیت و دریافت اولین پیش پرداخت چی میشه؟ آیا باید تاریخ پرداخت مرحله اول را در نظر بگیریم و یا مرحله آخر رو؟

پاسخ : خیر هیچکدام، باید سعی کنید با میانگین گیری وزنی و بر اساس میزان مبالغ پرداختی کارفرما تاریخ متوسط پرداخت را بدست آورید و آن را مبنای محاسبه تاخیرات قرار دهید.

تو سناریوی زیر قصد دارم نحوه محاسبه میانگین گیری وزنی را توضیح بدم:

سناریو: فرض کنید مبلغ قسط اول 1500 واحد پولی بوده است و طی سه مرحله به پیمانکار با مبالغ متفاوت توسط کارفرما پرداخت شده است (مطابق جدول شماره پایین)، حال چطور باید با میانگین وزنی تاریخ پرداخت قسط اول را بدست آورد؟

 

 

ردیف

 

شرح

تاریخ پرداخت طبق پیمان

 

تاریخ واقعی پرداخت

مبلغ پرداختی کارفرما

 

مدت تاخیر در پرداخت

نسبت پرداختی به کل مبلغ

1

قسط اول پیش پرداخت

 

96/02/06

96/03/01

750

24

50%

2

96/03/15

250

38

17%

3

96/03/28

500

51

33%

 

(50%*24+17%*38+33%*51) =35+96/02/06=96/03/12

با توجه به فرمول فوق که بصورت میانگین گیری وزنی انجام شده است مشخص گردید که کل پول با 35 روز تاخیر در تاریخ 12/03/96 پرداخت شده است و باید برای تفاضل تاریخ ارسال صورت وضعیت ارسالی و تاریخ دریافت اولین پیش پرداخت این تاریخ را در نظر گرفت.

نکته اول: توجه کنید که در طرف اول کسر منظور از کارکرد آخرین صورت وضعیت قبل از تسلیم ضمانت نامه، مبلغ تجمعی تایید شده کارفرما می باشد نه مبلغ دوره ای کارکرد.

نکته دوم : توجه کنید که در مخرج کسر اول منظور از تفاضل تاریخ ارسال آخرین صورت وضعیت تاریخ نامه پیمانکار می باشد و منظور از تاریخ دریافت اولین پیش پرداخت تاریخ واقعی پرداخت می باشد نه تاریخ پرداخت طبق پیمان.

 





نوع مطلب :
برچسب ها : قسط دوم پیش پرداخت، محاسبه تاخیرات در پروژه،
لینک های مرتبط :


( کل صفحات : 17 )    1   2   3   4   5   6   7   ...   
آمار وبلاگ
  • کل بازدید :
  • بازدید امروز :
  • بازدید دیروز :
  • بازدید این ماه :
  • بازدید ماه قبل :
  • تعداد نویسندگان :
  • تعداد کل پست ها :
  • آخرین بازدید :
  • آخرین بروز رسانی :
اگر سئوالی براتون پیش اومد و یا نیاز به همفکری داشتید خوشحال میشم بتونم کمکتون کنم، برای این کار میتونید بهم ایمیل بزنید-موفق باشید Moghadasi.tkd@gmail.com