درحال مشاهده: مهندسی و مدیریت ساخت پروژه

ادعونی
اهدای خون
موسسه محک
اهداء عضو

محاسبه تفاضل تاریخ آخرین صورت وضعیت و دریافت اولین پیش پرداخت؟؟؟

1396/06/9
07:24
امیرحسین ستوده بیدختی
محاسبه تفاضل تاریخ آخرین صورت وضعیت و دریافت اولین پیش پرداخت؟؟؟ 
احتمالا اگه با بخشنامه های محاسبه تاخیرات مالی آشنایی نداشته باشید عنوان این مطلب یکم براتون گیج کننده باشه ولی خب تو بخشنامه 5090 یه فرمولی وجود داره در مورد محاسبه تاخیر در پرداخت قسط دوم و سوم پیش پرداخت که بعضی اوقات وقتی قسط اول تو چند مرحله توسط کارفرما پرداخت میشه مشکل سازه، حالا میخوام برای اینکه نحوه محاسبه تفاضل تاریخ آخرین صورت وضعیت و دریافت اولین پیش پرداخت رو در این شرایط خاص توضیح بدم از یه سئوال کمک بگیرم و بعد چند نکته تکمیلی رو هم در پایان بگم. 
سوال) در صورتیکه قسط اول پیش پرداخت در سه مرحله پرداخت شده باشه تکلیف تفاضل تاریخ ارسال آخرین صورت وضعیت و دریافت اولین پیش پرداخت چی میشه؟ آیا باید تاریخ پرداخت مرحله اول را در نظر بگیریم و یا مرحله آخر رو؟
پاسخ : خیر هیچکدام، باید سعی کنید با میانگین گیری وزنی و بر اساس میزان مبالغ پرداختی کارفرما تاریخ متوسط پرداخت را بدست آورید و آن را مبنای محاسبه تاخیرات قرار دهید.
تو سناریوی زیر قصد دارم نحوه محاسبه میانگین گیری وزنی را توضیح بدم:
سناریو: فرض کنید مبلغ قسط اول 1500 واحد پولی بوده است و طی سه مرحله به شکل زیر به پیمانکار با مبالغ متفاوت توسط کارفرما پرداخت شده است، حال چطور باید با میانگین وزنی تاریخ پرداخت قسط اول را بدست آورد؟
تاریخ پرداخت قسط اول طبق پیمان: 06/02/96
تاریخ پرداخت مرحله اول: 01/03/96 به مبلغ 750 واحد پولی (50% کل مبلغ) که 24 روز تاخیر دارد.
تاریخ پرداخت مرحله دوم: 15/03/96 به مبلغ 250 واحد پولی (17% کل مبلغ) که 38 روز تاخیر دارد.
تاریخ پرداخت مرحله سوم: 28/03/96 به مبلغ 500 واحد پولی (33% کل مبلغ) که 51 روز تاخیر دارد.

 (50%*24+17%*38+33%*51)=35+96/02/06=96/03/12
با توجه به فرمول فوق که بصورت میانگین گیری وزنی انجام شده است مشخص گردید که کل پول با 35 روز تاخیر در تاریخ 12/03/96 پرداخت شده است و باید برای تفاضل تاریخ ارسال صورت وضعیت ارسالی و تاریخ دریافت اولین پیش پرداخت این تاریخ را در نظر گرفت.
نکته اول: توجه کنید که در طرف اول کسر منظور از کارکرد آخرین صورت وضعیت قبل از تسلیم ضمانت نامه، مبلغ تجمعی تایید شده کارفرما می باشد نه مبلغ دوره ای کارکرد.
نکته دوم : توجه کنید که در مخرج کسر اول منظور از تفاضل تاریخ ارسال آخرین صورت وضعیت تاریخ نامه پیمانکار می باشد و منظور از تاریخ دریافت اولین پیش پرداخت تاریخ واقعی پرداخت می باشد نه تاریخ پرداخت طبق پیمان

دلایل بدبینانه بودن تخمین پایان پروژه به روش زمان کسب شده ((ES در اواخر پروژه

1396/06/7
09:39
امیرحسین ستوده بیدختی
دلایل بدبینانه بودن تخمین پایان پروژه به روش زمان کسب شده ((ES در اواخر پروژه
قبل از اینکه بخوام برم سراغ اصل مطلب نیازه که یه مقدمه کوتاه بگم و بعد بحث اصلی ام رو شروع کنم،
خب احتمالا همونطوری که میدونید میشه گفت سه روش برای محاسبه تخمین پایان پروژه وجود داره (شاید هم من فقط همین سه تا را بلدم)، اولیش میشه نظر کارشناس خبره (یعنی اینکه از یه نفر یا گروهی از آدم های خبره بپرسید که با توجه به شواهد و براساس تجربیاتشون بگن که احتمالا پروژه کی تموم میشه، استفاده از این روش جواب های سریعی به شما میده ولی خوب اصلا دقت خوبی نداره و معمولا این تاریخ در قالب صورتجلسات بعد از یه کم چکش کاری توسط بقیه نفرات حاضر در جلسه مشخص میشه). دومیش میشه استفاده از تکنیک CPM و محاسبه تاخیرات روی مسیر بحرانی (تو این حالت برنامه رو به تاریخ بروز آوری ریسکجول می کنید و با جابجا شدن تاریخ پایان پروژه مشخص میشه که اگر از این به بعد بتونیم  مطابق برنامه پیش بریم احتمالا پروژه کی تموم میشه، خب البته استفاده از این روش زیاد از حد خوشبینانه ست چون مخصوصا تو پروژه های کشور ما این اتفاق بندرت هم نمیفته که بخوایم منبعد مطابق برنامه عمل کنیم). سومیش میشه استفاده از روش زمان کسب شده یا همون (Earned Schedule) (این روش زمانیکه پیشرفت واقعی پروژه معمولا بالای 20% هست نتایج فوق العاده عالی و نزدیک به واقعیت داره، تو این روش فرض بر اینه که اگر منبعد با سرعتی معادل سرعتی که از ابتدا تا حالا داشتیم پیش بریم تو چه تاریخی پروژه را تموم می کنیم). 
نکته: بهتون پیشنهاد میدم برای یه مدت از هر سه روش در کنار هم استفاده کنید و پس از اینکه پروژه تحویل موقت شد به عقب برگردید و نتایج رو تو بازه های مختلف بررسی کنید تا ببینید کدوم روش جواب های مناسبتر و نزدیک به واقعیت بهتون میداده.
من خودم از هر سه روش تو پروژه های که مشغولم استفاده میکنم و همیشه نتیجشون رو نسبت به هم ارزیابی میکنم و البته معمولا زمانیکه پیشرفت پروژه بین 20 تا 93 درصد هست استفاده از تکنیک زمان کسب شده (ES) بهترین نتایج رو داشته و همچنان داره، ولی جدیدا متوجه شدم که هر چی به سمت پایان پروژه (تحویل موقت) بیش از 93 درصد پیشرفت پیش میریم تخمین های که این تکنیک داره بهم نشون میده بیش از حد بدبینانه هست و شاید بگم بهتره که در بعضی موارد از ارائه شون صرفنظر می کنم، به همین خاطر تو این برهه معمولا میرم سراغ استفاده از تکنیک مسیر بحرانی چون بنظرم واقع بینانه تر میاد، من کلی در این مورد با خودم فکر کردم و گفتم که چطور میشه استفاده از این تکنیک با وجود اینکه هر چی پیشرفت پروژه بیشتر میشه باید نتایجش دقیقتر بشه ولی در آخر کار این اتفاق نمیفته و تونستم به چند نتیجه جالب البته از نظر خودم برسم، که قصد دارم بگم.
1-  تخمین های که این تکنیک (ES) داره میده، واقعا تا زمان پایان و تکمیل 100% و نهایی پروژه هست در حالیکه ما معمولا پروژه را بالای 95% (همینکه قابل بهره برداری باشه) تموم شده می دونیم و اون رو تحویل موقت می کنیم.
2-  حالا اگر مدت زمان صرف شده واقعی جهت رفع نواقص رو هم به تاریخ تحویل موقت اضافه کنیم متوجه میشیم که بازهم نتایج زمان کسب شده به مراتب نسبت به سایر روش ها خیلی به واقعیت نزدیک تر بوده، (الان دارم متوجه میشم که تخمین های این روش تا زمان تکمیل 100 درصدی پروژه هست و نه تا زمان تحویل موقت).
3-  در بسیاری از مواقع در طول اجرای پروژه بنا به یسری دلایل منطقی و غیر منطقی مشاور و کارفرما درصدهای پیشرفت واقعی پیمانکار رو کمتر از آنچه که هست برآورد میکنن و تخمین میزنن، برای همین نتایج این روش در پایان با اضافه کردن یک مرتبه پیشرفت ها بهم میخوره.
4-  با توجه به اینکه روش مسیر بحرانی بیانگر این است که منبعد با سرعتی معادل سرعت برنامه کار کنیم و زیاد از حد خوشبینانه است ظاهرا اینجور بنظر میرسه که داره تخمین رو تا زمان تحویل موقت در نظر میگیره نه تا پایان رفع نقص همه موارد و تحویل نهایی به کارفرما، برای همین این تخمین بنظر بهتر میرسه (هر چند که این تخمین هم پروژه را تا تکمیل 100% در نظر میگیره ولی تو اواخر پروژه بخاطر خوشبینانه بودنش انگار منطقی تر بنظر میرسه).
نکته: زمانیکه میخواید یه گزارش رو ارائه بدید حتما در مورد هر تخمین توضیحات لازم رو بدید و در بعضی موارد خاص هم که فکر می کنید تخمین ها زیاد از حد پرت هستن باید سعی کنید از شهود خودتون هم کمک بگیرید تا راحت تر متوجه بشید که کدام تخمین به واقعیت نزدیک تر هستن (که البته این هم برمیگرده به اینکه شما چقدر نسبت به پروژه آشنا هستید).
مواردی که در بالا گفته شد صرفا تجربیات فعلی بنده هست ولی به احتمال خیلی زیاد در آینده با تست موارد گفته شده روی یسری پروژه نمونه، نتایج آن بصورت کاملتر در دسترس عزیزان قرار میگیره.

مسیربحرانی

1396/06/5
10:57
امیرحسین ستوده بیدختی
مسیربحرانی

کلا دو روش برای بحرانی به حساب آوردن فعالیت‌ها و در نتیجه تعیین «مسیر بحرانی»، یعنی مجموعه فعالیت‌های بحرانی که از قدیم علاقه داشتیم تو یه مسیر باشن وجود داره:
بر اساس حداکثر شناوری کل فعالیت‌هابر اساس قرار گرفتن روی طولانی‌ترین مسیر


روش اول:
 برای اکثر افراد آشناتره و معمولا جاهایی که تئوری CPM رو توضیح می‌دن از همین روش استفاده می‌کنن. تو این روش زودترین و دیرترین تاریخ‌های شروع و پایان هر فعالیت تو دو مرحله رفت و برگشت محاسبه می‌شه و تفاضل زودترین و دیرترین تاریخ‌ها دو مقدار شناوری شروع و شناوری پایان رو به وجود میاره. نرم‌افزارهای مختلف یا یکی از این دوتا رو شناوری کل می‌شناسن، یا حداقل اون‌ها رو، یا حتی انتخاب اون رو به شما بدن؛ البته این دو مقدار تو حالت‌های معمولی با هم برابر هستن. حالا حدی برای اون‌ها در نظر گرفته می‌شه و هر فعالیتی که شناوری کلش از اون مقدار بیشتر نباشه بحرانی به حساب میاد.

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

اگه برنامه‌تون آزاد نباشه می‌تونه شناوری منفی هم داشته باشه، که در این صورت منفی‌ها هم بحرانی به حساب میان. البته می‌دونین که بهتره از برنامه‌های غیر آزاد استفاده نکنین و در نتیجه نباید انتظار شناوری منفی داشته باشین.


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

به هر حال، کار از انتهای برنامه شروع می‌شه. فعالیت انتهایی به عنوان آخرین عنصر «طولانی‌ترین مسیر» انتخاب می‌شه و بعد مسیر بر اساس روابط حاکم دنبال می‌شه و فعالیت‌های دیگه دونه دونه انتخاب می‌شن. مجموعه این فعالیت‌ها می‌شن طولانی‌ترین مسیر برنامه و می‌تونن بحرانی به حساب بیان.

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

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

نویسنده: نادر خرمی راد

تهیه منشور پروژه

1396/06/5
10:55
امیرحسین ستوده بیدختی
تهیه منشور پروژه:

منشور پروژه از اولین سند‌هایی است که در پروژه تنظیم می‌شود و معمولا کوتاه نیز هست؛ با این حال اهمیت بسیار زیادی دارد. این سند به پروژه و مدیر پروژه رسمیت می‌دهد و بعد از تصویب آن پروژه رسما شروع می‌شود. 

برخی از اطلاعات که معمولا در منشور پروژه قرار می‌گیرند از این قرارند:

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

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


مهندسی و مدیریت ساخت پروژه

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