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



مدیر وبلاگ : عباس مقدسی
نویسندگان
سه شنبه 12 دی 1396 :: نویسنده : عباس مقدسی

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


https:// abbasmoghadasi.com





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

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

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

برای بررسی مشکل آپدیت کردن در پراجکت به سناریو زیر توجه کنید.

فرض بگیرید یه پروژه داریم که مدت اولیش 24 ماهه و الان در ماه دهم هستیم، طبق گزارش تهیه شده در آخر این ماه پیشرفت واقعی پروژه 22% بوده در حالیکه پیشرفت برنامه ای پروژه 40% هست، یعنی اینکه از برنامه 18%- انحراف داریم و بازم فرض رو بر این بگیرید که این انحراف سبب 95 روز تاخیر شده است (امیدورام داستان تکراری تفاوت انحراف و تاخیر رو خاطرتون باشه)، خب با توجه به انحراف و تاخیر پیش آمده در پروژه فرضی ما، طی یک جلسه ای ارکان پروژه به این نتیجه میرسن که باید یه برنامه جبرانی پیمانکار ارائه کنه و مکلفه که تاریخ پایان پروژه را جابجا نکنه، خب در ادامه اگر قصد داشته باشید از روش آپدیت کردن برنامه برای محاسبه پیشرفت برنامه ای استفاده کنید این مشکلات رو دارید.

1-     زمانیکه دارید دکمه آپدیت رو به تاریخ امروز میزنید فعالیت های که هنوز شروع نشده اند، یا در حال تکمیل هستند و یا شاید هم تکمیل شده اند و تاریخ شروع یا پایانشون قبل از امروز هست نرم افزار بهشون مقدار میده یعنی اینکه اگه فعالیتی حتی درصد پیشرفت واقعیش صفر هم باشه ولی تاریخ پایانش (Finish و نه Base Line Finish) قبل از امروز باشه مقدار 100% در فیلد %Complete میگیره، که معنیش این میشه که این فعالیت به لحاظ واقعی تکمیل شده، پس وقتی مقدار این فیلد صد میشه برنامه اون رو ریسکجول نمیکنه و بحث بحرانی بودن رو هم برای فعالیت های تکمیل شده در نظر نمیگیره.

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

3-     وقتی از این روش استفاده می کنید ناچارا بخاطر بحثی که در قسمت شماره 2 گفتم نمی تونید تاریخ های شروع و پایان واقعی رو وارد نرم افزار کنید.

4-     وقتی برنامه را ریسکجول می کنید و از برنامه بیس لاین مجدد می گیرید، قاعدتا نباید انتظار داشته باشید که فعالیت های تکمیل نشدتون به جلو کشیده بشن و درصدهای پیشرفت واقعی و برنامه ایتون نزدیک به هم بشن.

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

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





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

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

چگونگی تخمین مدت زمان فعالیت ها و نکات کاربردی آن:

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

هفت روش تخمین زمان فعالیت ها:

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

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

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

۴- پیش بینی سه نقطه ایی: استفاده از زمان های خوش بینانه، بد بینانه و محتمل جهت تخمین زمان فعالیت. که می بایست از این زمان ها معدل گیری کرد. البته این مطلب در مبحث پرت PERT هم هست ولی در اون مبحث میانگین وزنی ملاکه. تجربه شخصی من نشون داده که این روش برای برنامه های مستر و کلی کاربرد بیشتری داره. به این صورت که در خصوص پروژه های مشابه قبلی میان از بیشترین زمان، کمترین زمان و زمان محتمل معدل گیری می کنند تا بتونند به زمان های کلی فعالیت ها برسند. توی پروژه های بزرگ که ممکنه هر ردیف فعالیت برنامه زمان بندی خودش بعداً یک برنامه زمان بندی تفصیلی بشه و ما در حال برنامه ریزی کلی کار باشیم خیلی کاربرد داره. اگه بخوام محاوره این روش رو براتون بگم میتونه اینجور باشه که: توی فلان پروژه پیمانکار X اومد 100 متر زیر سازی مسیر رو توی فلان ماه انجام داد. شرکت Y هم قطعه بعدی کار میکرد ولی 2 هفته بیشتر زمان برد. شرکت Z هم که توی پروژه دیگه ایی کار میکرد همون 100 متر رو توی فلان ماه تموم کرد.

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

۶- آنالیز داده: این روش از دو بخش تشکیل شده است. بخش اول آنالیز گزینه ها و بخش دیگر آنالیز رزرو. در این روش می بایست گزینه های اولیه زمان فعالیت ها را با روش های کوتاه کردن زمان ( مانند کرش و فست ترک) بررسی کرده و با در نظر گرفتن ریسک انجام همزمان فعالیت ها و هزینه منابع مورد نیاز جهت کاهش زمان اجرای فعالیت، به زمان مطلوب فعالیت برسیم و پس از آن با توجه به عدم قطعیت در فضای اجرای پروژه و متناسب با آن اقدام به اعمال ضریب افزایشی جهت زمان آن فعالیت کنیم. ( مثلا بگوییم با توجه به فضای عدم قطعیت، ۱۰٪ به زمان فعالیت اضافه کنیم که این موضوع بعنوان رزرو در نظر گرفته میشه). در واقع این روش میتونه یجور کار تکمیلی برای روش های دیگه هم باشه. یعنی روش های قبلی تخمین زمان رو داشته باشیم و بعد با این روش موازنه هزینه-زمان و مدیریت ریسک های زمانی داشته باشیم تا کیفیت تخمین رو بالا ببریم.

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





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

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

ادامه مطلب رو با طرح یه سناریو شروع میکنم، فرض بگیرید یه پروژه داریم که مدت اولیش 24 ماهه و الان در ماه دهم هستیم، طبق گزارش تهیه شده در آخر این ماه پیشرفت واقعی پروژه 22% بوده در حالیکه پیشرفت برنامه ای پروژه 40% هست، یعنی اینکه از برنامه 18%- انحراف داریم و بازم فرض رو بر این بگیرید که این انحراف سبب 95 روز تاخیر شده است (امیدورام داستان تکراری تفاوت انحراف و تاخیر رو خاطرتون باشه)، خب با توجه به انحراف و تاخیر پیش آمده در پروژه فرضی ما، طی یک جلسه ای ارکان پروژه به این نتیجه میرسن که باید یه برنامه جبرانی پیمانکار ارائه کنه و مکلفه که تاریخ پایان پروژه را جابجا نکنه (یعنی اینکه هنوز کارفرما و سایر عوامل اعتقاد دارن که میشه پروژه را سر 24 ماه تموم کرد)، خب در ادامه بصورت قدم به قدم چگونگی تهیه برنامه جبرانی آمده است.

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

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

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

نکته دوم: سعی کنید نوع فعالیت هاتون حتما Fixed Duration باشه، تا راحت بتونید مدت زمان ها رو تنظیم کنید.

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

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

نکته: شما زمان تهیه برنامه جبرانی همزمان باید از هر دو تکنیک موازی کاری (Fast tracking) و کاهش مدت زمان (Crashing) استفاده کنید.

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

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

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

و اما چند نکته مهم آخر:

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

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

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

نکته چهارم: تهیه برنامه جبرانی تو پریماورا یکم متفاوته که بعدا در موردش خواهم نوشت.





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

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

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

تصویر شماره 1

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

تصویر شماره 2

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

تصویر شماره 3

در پروژه فوق چنانچه بخواهیم مطابق تصویر شماره 4 تاخیرات آن را با در نظر گرفتن بیس لاین ثابت بررسی کنیم (با این فرض که تاخیرات فعالیت A مجاز بوده و سایر تاخیرات نیز غیر مجاز بوده است)، تحلیلی که صورت خواهد گرفت به این صورت است که درست است که تاخیرات فعالیت A مجاز بوده، ولی خوب به چه دلیل فعالیت B ( سه روز تاخیر) و فعالیت C ( پنج روز تاخیر) دارند؟  و سئوال مهم دیگری که مطرح است این که آیا با توجه به اینکه تاخیرات فعالیت A مجاز است آیا واقعا همه تاخیر ایجاد شده در اجرای فعالیت B و C غیر مجاز است یا خیر؟ (به تاخیرات نشان داده شده در ستون Finish Variance دقت کنید، ضمنا یادآوری می گردد که مبنای محاسبه تاخیرات پروژه Finish Variance همیشه تفاضل تاریخ Finish و Base Line Finish است).

تصویر شماره 4

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

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

تصویر شماره 5

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

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





نوع مطلب :
برچسب ها : تفاوت خط مبنای ثابت و خط مبنای متغیر برای محاسبه تاخیرات پروژه، چگونگی محاسبه تاخیرات فنی،
لینک های مرتبط :

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

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

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

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





نوع مطلب :
برچسب ها : پیاده سازی سیستم مدیریت پروژه، استانداردهای مدیریت پروژه، 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-  شما براحتی متوجه دغدغه اصلی مدیران ارشدتون در خصوص هر پروژه میشید، مثلا یه پروژه زمانش خیلی بحرانیه، یکیشون کیفیت توش خیلی مهمه، یکیشون ضرر نده باید کلاهمون رو بندازیم هوا، یکیشون سود کم بده مصیبته و ...

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

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





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


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