تأخیرات و ادعا

روانشناسی کلیم، ادعا و لایحه توجیه تأخیرات پروژه

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

۱- حجم زیاد پرونده توجیه تأخیرات و claim (تعداد صفحات زیاد)

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

۲- عدم اشاره به هزینه‌های مالی ناشی از تأخیر در پروژه تا زمان اخذ تأیید تأخیرات زمانی

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

۳- قرار دادن مواردی جهت خط زدن توسط کارفرما در پرونده توجیه تأخیرات

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

۴- مرتب و زیبا بودن گزارش توجیه تأخیرات

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

۵- عدم استفاده از واژه کلیم-Claim

باید قبول کنید اینجا ایران است و در برخی از موارد روحیات ایرانی‌ها با بقیه ملت‌ها متقاوت است و ناچاریم بپذیریم که برخی از کارفرماها و مشاوران به خود واژه “کلیم” حساسیت و آلرژی دارند و اصولن در هیچ کدام از مراحل پروژه بهتر است که پیمانکار حتی اسم این واژه را به کار نبرد تا حساسیت بیجا ایجاد نشود. حتی نام پوشه‌ای که مدارک و مستندات توجیه تأخیرات یا ادعای کلیم و افزایش هزینه در این پوشه برای کارفرما ارسال می‌شود را نباید claim یا امثالهم گذاشت و بهتر است از واژه‌های جایگزین مانند پرونده توجیه تأخیرات و امثالهم استفاده کرد. یا حتی بعضی‌ها به جای واژه “توجیه” تأخیرات از عبارت “دلایل تأخیر پروژه” استفاده می‌کنند.

۶- شناخت دقیق روحیات و سبک کاری بررسی‌کنندگان کلیم

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

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

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

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

سایر مطالب مرتبط:

مدیریت پروژه

وقتی تیم پروژه، دوست ندارند پروژه به موقع تمام شود

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

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

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

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

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

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

آن‌ها برای خود استدلال‌هایی هم داشتند، مثلن:

– اگر پروژه سریع و به موقع به اتمام برسد، عده‌ای زیادی از نان خوردن می‌افتند!
– این پروژه و پروژه قبلی نزدیک شهرهای محل سکونت ماست و خوب است که با کار کردن در دو پروژه به موعد بازنشستگی می‌رسیم و دیگر لازم نیست مثل بقیه افراد شاغل در پروژه‌‌ها، هر یکی دوسال از پروژه‌ای به پروژه دیگر نقل مکان کنیم و اینجا آرامش و ثبات داریم!
– کارکردن سریع در پروژه و به اتمام به موقع آن، سبب افزایش هزینه‌ها می‌شود!

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

خواهش می‌کنم بدون ذکر منبع (نام نویسنده، آدرس سایت و آدرس کانال تلگرام) کپی نکنید!

 

در همین ارتباط بخوانید:

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

همه چیز در مورد شناوری منفی در پروژه

کنار گذاشتن باورهای غلط:

از تیتر این مطلب مشخص است که ما می‌توانیم در برنامه زمان‌بندی پروژه، شناوری منفی داشته باشیم. پس این تعبیر غلط که “شناوری منفی کلن نداریم یا کلن نباید باشد” را فراموش کنید.

نکته بسیار مهم: شناوری مسیر بحرانی همیشه صفر نیست و ممکن است صفر، منفی یا مثبت باشد.

چه زمانی در برنامه زمان‌بندی شناوری منفی داریم؟

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

سوال: آیا شناوری منفی (یا شناوری غیر صفر مسیر بحرانی) فقط در فاز کنترل پروژه هست و آیا در فاز برنامه‌ریزی پروژه و در ابتدای پروژه هم ممکن است شناوری منفی داشته باشیم؟

جواب: بله

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

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

آیا شناوری منفی مهم است؟

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

معمولن در چه پروژه‌هایی شناوری منفی ایجاد می‌شود؟

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

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

به عبارتی در این پروژه‌ها اولویت‌های اصلی استراتژی جبران از عقب ماندگی و جبران تأخیر پروژه به ترتیب و به این صورت تعریف می‌شود:
۱- فعالیت‌های با شناوری منفی
۲- فعالیت‌های با شناوری صفر
۳- فعالیت‌های با شناوری مثبت ولی مقدار کم
۴- و در نهایت سایر فعالیت‌های پروژه

بنابراین باز هم تأکید می‌کنم که صفر کردن شناوری منفی در هنگام تهیه برنامه جبرانی کار اشتباهی است مگر اینکه بیس‌لاین پروژه تغییر نماید یا تاریخ پایان پروژه تغییر کند.

آیا وجود شناوری منفی در برنامه زمان‌بندی نشان دهنده یک مشکل در برنامه‌ریزی است؟

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

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

 

خواهش می‌کنم بدون ذکر منبع (نام نویسنده، آدرس سایت و آدرس کانال تلگرام) کپی نکنید!

مدیریت پروژه

ویژگی‌های یک مدیر پروژه سنتی

در مطلب قبلی با عنوان “ده نکته طلایی برای مدیران پروژه‌ها“، ده مورد مهم برای مدیران پروژه‌ها ذکر کردم. اما همه مدیران پروژه‌ها به یک شکل عمل نمی‌کنند. به نظر من مدیران پروژه در ایران دو دسته هستند:

۱- مدیران پروژه سنتی
۲- مدیران پروژه مدرن

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

۱- مدیران پروژه سنتی معتقدند برنامه‌ریزی و کنترل پروژه امری زائد، بی‌فایده، لوکس، تشریفاتی، غیرکاربردی و کلن بی فایده است و معمولن هم توجهی به برنامه‌ریزی و کنترل پروژه ندارند و اگر هم در جایی از این دانش یا متخصصین این دانش استفاده کنند، از روی اجبار است و نه اختیار و علاقه.

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

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

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

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

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

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

۸- پروژه را به صورت هیأتی مدیریت می‌کنند. بعدن در پستی جداگانه و به صورت مفصل در مورد “سبک مدیریت پروژه هیأتی” خواهم نوشت.

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

۱۰- معتقدند در پروژه دموکراسی نیست و مدیر پروه باید یک دیکتاتور مطلق باشد و نظر سایر افراد و تیم پروژه ذره‌ای اهمیت ندارد و تنها نظر آن‌هاست که درست و صحیح است و باید اجرا شود.

۱۱- به فاز اختتام پروژه اعتقادی ندارند، معتقدند اصل کار همان نود درصد پیشرفت پروژه بود که خودشان انجام داده‌اند و فعالیت‌های فاز اختتام پروژه مهم نیست و قبل از فاز اختتام پروژه، موفقیت خودشان و پروژه‌شان را جشن می‌گیرند!

خوشحال می‌شوم شما هم اگر موارد دیگری به ذهنتان میرسد، عنوان کنید.

خواهش می‌کنم بدون ذکر منبع (نام نویسنده، آدرس سایت و آدرس کانال تلگرام) کپی نکنید!

 

سایر مطالب مرتبط:

ده نکته طلایی برای مدیران پروژه‌ها

آیا پروژه‌های سازمانتان، شما را به یاد داستان “پنج مرد نابینا و یک فیل” نمی‌اندازد؟

مدیریت قند و چایی در پروژه‌ها

مهم‌ترین تفاوت‌های برنامه‌های زمان‌بندی در ایران با سایر کشورها

 

برنامه ریزی و کنترل پروژه , عمومی

آیا در تعطیلات عید نوروز، پروژه‌ها باید فعال باشند یا خیر؟

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

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

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

۱- کار نکردن نیروهای مستقیم پروژه در تعطیلات

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

۲- عدم مجوز بتن‌ریزی در برخی از شهرها و جلوگیری از تردد ماشین آلات سنگین در برخی از مناطق و راه ها

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

۳- تعطیلی و نیمه تعطیلی بسیاری از ادارات، فروشندگان و تأمین کنندگان منابع و ماشین آلات

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

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

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

 

خواهش می‌کنم بدون ذکر منبع (نام نویسنده، آدرس سایت و آدرس کانال تلگرام) کپی نکنید!

برنامه ریزی و کنترل پروژه , مایکروسافت پراجکت

چهل سوالی که ممکن است در یک مصاحبه شغلی در خصوص نرم‌افزار مایکروسافت پراجکت msp از شما بپرسند.

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

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

۱- این سوالات لزومن شاید همه سوالات درست و صحیح و با کاربرد واقعی نباشند، اما تجربه ثابت کرده است که برخی از آن‌ها که شاید چندان منطقی هم نیستند ممکن است در جلسات مصاحبه استخدامی پرسیده ‌شوند.
۲- تمام سوالاتی که در مصاحبه شغلی در مورد نرم‌افزار مایکروسافت پراجکت پرسیده می‌شود، تنها محدود به موارد زیر نیست و شاید سوالات دیگری نیز باشد که از قلم افتاده‌اند.
۳- حتی اگر قصد حضور در یک مصاحبه شغلی را ندارید، خواندن این سوالات و جواب دادن به آن‌ها باعث می‌شود یک تخمین کلی از مهارت خودتان در نرم افزار MSP به دست بیاورید. (اگر فرض کنیم هر سوال نیم نمره دارد، بعد از خواندن هر چهل سوال حساب کنید از ۲۰ نمره به خودتان چه نمره‌ای می‌دهید.)

اما سوالات:
۱- آیا تا به حال یک ساختار شکست و یک برنامه زمان‌بندی را در MSP تهیه کرده‌اید؟ مراحل کار را از ابتدا تا انتها قدم به قدم توضیح دهید.
۲- نحوه انتقال یک WBS تهیه شده از اکسل به مایکروسافت پراجکت چگونه است؟
۳- در خصوص انواع تقویم Calendar و انواع قیدها Constraint در MSPتوضیح دهید.
۴- در خصوص Task Type و Effort Driven در نرم افزار MSP توضیح دهید.
۵- چگونه می توان در نرم افزار مایکروسافت پراجکت، یک تقویم اختصاصی ساخت؟ به عنوان مثال یک تقویم بسازید که هفت روز هفته، کاری و روزی ده ساعت کار است.
۶- نحوه تعریف و تخصیص baseline در MSP چگونه است؟
۷- چه روش‌هایی برای آپدیت کردن و به روز نمودن و Actual کردن برنامه زمان‌بندی در MSP وجود دارد؟ مراحل آپدیت کردن یک برنامه زمان بندی را از ابتدا تا انتها توضیح دهید.
۸- نحوه فرمول نویسی جهت محاسبه درصد پیشرفت برنامه‌ای در نرم افزار مایکروسافت پراجکت را توضیح دهید. در خصوص فرمول محاسباتی ضریب وزنی (W.F) زمانی در MSP توضیح دهید.
۹- نحوه استخراج S CURVE برنامه Baseline از یک برنامه زمان‌بندی در MSP را توضیح دهید.
۱۰- نحوه استخراج S CURVE برنامه Actual از یک برنامه زمان‌بندی در MSP را توضیح دهید.
۱۱- نحوه استخراج منحنی موزی از یک برنامه زمان‌بندی در MSP را توضیح دهید.
۱۲- در خصوص گروه بندی فعالیت ها در نرم افزار مایکروسافت پراجکت توضیح دهید.
۱۳- نحوه استخراج Cash flow از برنامه زمان‌بندی در پراجکت چگونه است؟
۱۴- در خصوص فیلدهای سفارشی در پراجکت توضیح دهید. (نحوه سفارشی‌سازی یک فیلد و کاربرد آن)
۱۵- چگونه می‌توان فعالیت‌های دو هفته آینده را از برنامه زمان‌بندی فیلتر و استخراج کرد؟
۱۶- چگونه می‌توان فعالیت‌هایی که در مسیر بحرانی پروژه هستند و هنوز آغاز نشده‌اند، اما طی دو ماه آینده طبق برنامه باید آغاز شوند را فیلتر و استخراج کرد؟
۱۷- در خصوص ابزارهای فیلتر و هایلایت در نرم افزار مایکروسافت پراجکت توضیح دهید.
۱۸- میزان “انحراف” پروژه از برنامه زمان‌بندی بیس‌لاین چگونه در msp محاسبه می‌شود؟
۱۹- میزان “تأخیر” پروژه از برنامه زمان‌بندی بیس‌لاین چگونه در پراجکت محاسبه می‌شود؟
۲۰- در اواسط پروژه چگونه می‌توانید پیش‌بینی تاریخ پایان پروژه را در msp محاسبه کنید؟
۲۱- برای محاسبه و آنالیز تأخیرات پروژه در msp از چه روشی استفاده می‌کنید؟
۲۲- نحوه انتقال یک برنامه زمان‌بندی از msp به اکسل و یا به پریماورا و بالعکس چگونه است؟
۲۳- نحوه تخصیص و تسطیح منابع در MSP چگونه است؟ (توضیح دادن ابزار تسطیح منابع، تسطیح منابع یک فعالیت، تسطیح تمام منابع، حذف اثر تسطیح، تنظیم‌های تسطیح و فیلدهای مربوط به تسطیح منابع)
۲۴- در خصوص مدیریت هزینه ها در پراجکت توضیح دهید. (توضیح در مورد تعریف هزینه‌ها، روش‌های تعریف هزینه، مفهوم هزینه ثابت آیتم‌ها، تعریف هزینه ثابت آیتم‌ها، تعریف هزینه منابع، تعریف هزینه متغیر، مفهوم منابع هزینه، تعریف منابع هزینه، تعریف بودجه، بررسی بودجه مالی و بررسی بودجه کاری)
۲۵- در خصوص کاربرد جدول Task usage و Resource Usage توضیح دهید.
۲۶- در خصوص ارتباط بین دو پروژه در نرم افزار مایکروسافت پراجکت توضیح دهید.
۲۷- چگونه می‌توان هیستوگرام منابع را از برنامه زمان‌بندی نوشته شده در پراجکت استخراج کرد؟
۲۸- چگونه می‌توان در یک برنامه زمان بندی و در msp فعالیت‌های open end را شناسایی کرد؟
۲۹- تفاوت‌های محاسبه پیشرفت برنامه‌ریزی شده، پیشرفت واقعی، در فیلدهای فیلد Physical % Complete، فیلد % Work Complete، فیلد % Complete، فیلد % Allocation در msp چیست و هر کدام چگونه محاسبه می‌شود؟
۳۰- نحوه انجام محاسبات EVM در مایکروسافت پراجکت چگونه است؟
۳۱- روش های نمایش دو یا چند رقم اعشار Complete% در MSP توضیح دهید.
۳۲- در خصوص شیوه ساخت یک فیلد اختصاصی برای نمایش مقدار گرد شده مدت زمان فعالیت توضیح دهید.
۳۳- تا چه حدی با مایکروسافت پراجکت سرور آشنایی دارید؟
۳۴- در خصوص شناسائی فعالیت Driving (محرک) در MSP با ابزار Inspector توضیح دهید.
۳۵- Elapsed Duration در نرم افزار MSP چیست؟
۳۶- در خصوص ایجاد فعالیت LOE در نرم افزار MSP توضیح دهید.
۳۷- در خصوص استفاده از Split در نرم افزار MSP توضیح دهید.
۳۸- در خصوص ایجاد فعالیت “غیر فعال” در پراجکت توضیح دهید.
۳۹- روش‌های شمسی‌سازی تاریخ‌ها در نرم‌افزار msp را توضیح دهید.
۴۰- از کدام یک از گزارشات خروجی نرم افزار پراجکت تا کنون استفاده کرده‌اید؟

خواهش می‌کنم بدون ذکر منبع (نام نویسنده و آدرس سایت و کانال تلگرام) کپی نکنید!

سایر مطالب مرتبط با این نوشته: