تبلیغات
وبلاگ انجمن مدل سازی اطلاعات ساختمان ایران - مطالب ابر پروژه

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


موسسه محک
اهداء عضو

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

چهارشنبه 13 اردیبهشت 1396
11:53
امیرحسین ستوده بیدختی
وقتی به تعریف واژگان استاندارد مدیریت پروژه می پردازیم عمدتاً راجع به موارد تکنیکی توضیح می دهیم. اینکه مسیر بحرانی چه معنی دارد یا اینکه ارزش کسب شده درست است یا ارزش افزوده (منظور معادل واژه انگلیسی Earned Value)؛ اما به مهمترین واژه هایی که در پروژه ها مورد استفاده قرار می گیرند، اشاره ای نمی کنیم. واژه های عدالت، حق، ظلم و اینگونه عبارات که باعث و بانی موفقیت یا عدم آن در پروژه ها می شوند. یا رفتار یکی با یکی دیگر عادلانه نیست! یا اینکه پیمانکاری حق کارکنانش را می خورد! یا اینکه در هنگام پرداخت ها به همان پیمانکار ظلم شده است. اما بدون تعریف این دسته از واژگان کلیدی در محیط پروژه ها، تنها داستان ها و بلکه افسانه ها هستند که می مانند و هر یک از طرف های درگیر، به فراخور حال خود داستانی را از به حق بودن، عادل بودن و ظلم نکردن خودش تعریف می کند. اینک من تعاریفی را خدمت شما ارائه می کنم که فکر می کنم پرداختن به امور پروژه را برای تمامی ذینفعان راحت تر خواهد کرد.
همه چیز از تفاهم شروع می شود. این واژه که بر وزن تفاعل است به معنی "فهم متقابل" می باشد. یعنی اینکه دو طرف راجع به انجام موضوعی، که در مورد ما بخشی از محدوده پروژه است، ابتدا به درکی متقابل می رسند. تفاهم در قدم بعدی، تبدیل به توافق می شود. یعنی آنچه را که مورد درک مشترک قرار گرفته به اطلاع یکدیگر رسانده و در صورت احراز اطمینان از یکسان بودن درک، تصمیم به متعهد بودن به آن می گیرند. لذا توافق، "داشتن تصمیم به متعهد بودن نسبت به درک مشترک" می باشد. با داشتن این تصمیم، توافق در اکثر اوقات در پروژه ها، مکتوب می گردد که به آن قرارداد می گوییم. توافقات به عمل آمده و مکتوب شده در قرارداد برای اجرا در قالب برنامه خودنمایی می کند. لذا برنامه پروژه تبلور توافقاتی است که بین طرفین یک قرارداد به عمل آمده است. اما می رسیم به واژه کلیدی عدالت. عدالت رعایت توافقاتی است که براساس قرارداد در برنامه درج شده است. لذا عدالت یک خروجی مانند برنامه، یا یک مایل استون، مانند توافق، نیست بلکه یک فرآیند است که تا انتهای پروژه در حال انجام می باشد. اندازه عدالت به میزان تفاوت بین آنچه به وقوع می پیوندد و آنچه که توافق شده به وقوع بپیوندد می باشد. به زبان پروژه کاران، عدالت همان تفاوت بین وضعیت واقعی (actual) و برنامه است. هر چه این تفاوت کمتر باشد، عدالت بیشتر جاری شده است و برعکس آن نیز صادق است. لذا برای اینکه بخواهیم راجع به عدالت دعوا کنیم که برقرار است یا نه، و اینکه سینه چاک کنیم که ما حامی عدالت هستیم، باید توجه کنیم که عدالت، فعل رعایت توافق است. بنابراین بدون داشتن توافقی، رعایت عدالت بی معناست. اول باید طرفین راجع به هر محدوده ای که مورد نظرشان است، مانند محدوده پروژه، به تفاهم رسیده و راجع به آن توافق نمایند؛ آنگاه در دوران پایش پروژه، در مقایسه آنچه اجرا شده با آنچه که توافق شده، به میزان گسترش عدالت و عدالت محور بودن طرفین پی خواهند برد.
در انتها از تمامی خوانندگان تقاضا دارم در صورت امکان نظرات خود را پیرامون تعاریف فوق اعلام نمایند تا شاید به نوعی اجماع برسیم. فکر می کنم که در این صورت می توانیم این واژگان را نیز در قالب واژگان و تعاریف کلیدی در هر قراردادی گذارده و نگرانی های خود را در مورد نحوه تعامل بین ذینفعان برطرف کنیم.

 مهندسی و مدیریت ساخت  (ICEMA)  Construction Engineering Management



ارسال شده در:

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

چهارشنبه 6 اردیبهشت 1396
04:34
امیرحسین ستوده بیدختی
تعریف تاخیرات
تاخیر، عمل یا رویدادی است که زمان مورد اشاره در قرارداد برای انجام عملی خاصی را طولانی تر کند. به‌طور کلی تاخیرات ناشی از علل مختلفی هستند که از عملکرد گروه‌های درگیر پروژه ایجاد می شوند. موفقیت پروژه رسیدن به اهداف از پیش تعیین شده تعریف می‌شود. در یک پروژه موفق، اجرای فنی پروژه به خوبی صورت گرفته، زمان‌بندی حفظ شده و هزینه های بودجه بندی شده نیز حفظ شده‌اند (امامی زاده، ۱۳۸۳).


تاخیرات چرا؟
دلایل تأخیر در کشورهای مختلف می‌تواند به دلایل زیادی متفاوت باشد ازجمله تفاوت‌های فرهنگی، اجتماعی، نوع قرارداد و روش ساخت، مسائل سیاسی و قوانین دولتی، شرایط زمین‌شناختی و آب‌وهوایی و… اما برخی از علل مانند کمبود نیروی انسانی و مصالح، مشکلات مالی و ضعف در مدیریت در میان کشورها مشترک بوده و لذا حل‌وفصل این مشکلات دغدغه‌ای عمومی است (وطن‌خواه ۱۳۸۳).

مقاله مرتبط: زمان‌بندی پروژه

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

مقاله مرتبط: تعریف ادعا

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

تاخیرات در طرح‌ها را می‌توان بر مبنای معیارهایی مانند منبع ایجاد، قابلیت جبران‌پذیری و زمان رخداد آن‌ها تقسیم‌بندی و تفکیک نمود. (تروهید، ۱۳۸۳) در شکل -۱ تقسیم‌بندی تا خیرات بر اساس منبع بروز، قابلیت و میزان جبران‌پذیری تاخیر به وجود آمده آورده شده است.


شکل ۱- تقسیم‌بندی تأخیرات بر اساس منشأ بروز
در ادامه به برخی از دلایل بروز تاخیر در پروژه که مرتبط به هریک از متصدیان پروژه است اشاره می‌گردد.

تاخیرات مرتبط با کارفرما:
بخشی از دلایل بروز تأخیرات مرتبط با کارفرما را می‌توان به‌صورت زیر برشمرد:

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

تاخیرات مرتبط با مشاوران:
عوامل زیر را می‌توان به‌عنوان بخشی از دلایل بروز تاخیر مرتبط با مشاوران بیان نمود:

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


تاخیرات مرتبط با پیمانکاران:
دلایل زیر بخشی از عوامل بروز تأخیر مرتبط با پیمانکاران می‌باشند:

مشکلات مالی،
مسائل ناشی از سوء مدیریت،
موجود نبودن مواد اولیه،
برنامه‌ریزی و زمان‌بندی نامناسب،
ضعف در مدیریت تجهیزات،
کمبود نیروی انسانی ماهر.
عوامل دیگری نظیر شرایط

دشوار آب‌وهوایی،
قوه قهریه (همچون سیل و زلزله)،
و عوامل طبیعی (آب‌وهوای نامناسب)،
آلاینده‌های محیطی،
مشکلات زمین‌شناسی پیش‌بینی‌نشده،
مسائل سیاسی،
مشکلات در صنعت یا اقتصاد کشور،
تغییرات جهشی و ناگهانی قیمت مواد و مصالح و …
نیز به‌عنوان دلایلی در ایجاد تاخیر وجود دارند که از آن‌ها به‌عنوان دلایل عوامل غیرقابل‌کنترل (عوامل محیطی) یاد می‌شود و تقریباً از ید کنترل طرفین خارج است. (مانسی، ۲۰۰۷)


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


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

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

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


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

تاخیرات مجاز – غیرقابل‌جبران[۱]:
این تاخیرات به سبب و درنتیجه فاکتورها و عواملی خارج از کنترل کارفرما و پیمانکار به وجود آمده است. تاخیری که نه پیمانکار و نه کارفرما پاسخگو نباشد غیرقابل‌جبران نامیده می‌شود که در بخشهای قبلی به آن‌ها اشاره شد. بلایای طبیعی و نامساعد بودن آب‌وهوا نمونه این تاخیرات هستند. (رضازاده، ۱۳۸۴)

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

 طبقه‌بندی تاخیرات مجاز:

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

افزایش احجام کارهای موجود در برنامه زمان‌بندی، مانند افزایش حجم خاک‌برداری یا خاک‌ریزی،
افزایش فعالیت‌های جدید به برنامه، مانند اضافه شدن فضای جدید به فضاهای قبلی پروژه،
تاخیر در ابلاغ نقشه‌ها و تعیین تکلیف دیتیلهای اجرایی از جانب کارفرما،
تأمین نشدن پیش‌نیازهایی که بر عهده کارفرما است. (وون سون، ۲۰۰۸)
تاخیرهای مجاز را برحسب زمان بروز تاخیر می‌توان به گروه‌های زیر تقسیم کرد:

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

تاخیراتی که تاریخ تأثیرشان وابسته به زمان وقوع آن‌هاست؛ مانند تغییر نقشه‌های اجرایی تأثیر این‌گونه تاخیرات با توجه به واقعیت اجرا ملاحظه می‌شود. به‌طور مثال شرایط نامناسب جوی با توجه به اینکه کار در کدام مرحله اجرا است ممکن است جزو تاخیرات مجاز یا غیرمجاز در نظر گرفته شود. مثال دیگر تاخیر در تعیین تکلیف دیتیلهای اجرایی است که هم‌اکنون استعلام شده، زمان تاخیر جواب کارفرما از زمان استعلام پیمانکار (با احتساب فرجه زمانی پاسخ) محاسبه می‌شود. (برای ماه، ۲۰۰۸)

مقاله مرتبط: تعهدات پیمانکار در شرایط عمومی پیمان و فیدیک قرمز

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

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

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

شرایط فیزیکی نامناسب:

مقاله مرتبط:بررسی مقایسه ای شرایط عمومی پیمان بین المللی فیدیک و شرایط عمومی پیمان ایران

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

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

[۱] Non-EXCUSABLEDELAYS

[۲] EXCUSABLE DELAYS

ارسال شده در:

آیا با قانون اساسی می توان پروژه را اداره کرد؟

یکشنبه 3 اردیبهشت 1396
11:44
امیرحسین ستوده بیدختی
آیا با قانون اساسی می توان پروژه را اداره کرد؟

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

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

 مهندسی و مدیریت ساخت  (ICEMA)  Construction Engineering Management


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

ارسال شده در:

منش مدیریت پروژه و مک دونالد

یکشنبه 27 فروردین 1396
11:56
امیرحسین ستوده بیدختی
منش مدیریت پروژه و مک دونالد

پارچه نوشته های بزرگی بر سردر رستوران های مک دونالد نصب می شود که بر روی آنها نوشته شده "یک ساندویچ بیگ مک فقط 99 سنت". 99 سنت دقیقاً همان قیمت تمام شده این ساندویچ است. پس شرکت مک دونالد سود خود را از کجا به دست می آورد؟ مشتری وارد رستوران می شود به خیال اینکه غذای امروز وی ارزان تمام خواهد شد. اما در هنگام پرداخت باید 6 دلار پرداخت کند! واقع مطلب این است که آن ساندویچ را نمی شود بدون نوشابه خورد، و قیمت نوشابه مثلاً دو دلار است. با اضافه شدن سیب زمینی و شاید یک دسر سیب مجموع هزینه ها به همان 6 دلار بالغ می گردد.
این تکنیک بازاریابی را به نام روش مک دونالد می شناسند. در این روش، مشتری را با معروف ترین محصول جذب کرده، بعد با فروش محصولات مکمل، به قیمت بالا، سود مورد نظر را به دست می آورند. از طرف مشتری، اگر توجه لازم به این شیوه نشود در انتها خیلی دلخور خواهد شد و از این معامله گله مند. از داستان مک دونالد این نتیجه را می گیرم که به عنوان یک مشتری باید حواسم جمع باشد و بدانم که اصل مطلب کجاست. با تشخیص درست می توان هم به هدف رسید و هم دلخور نشد.
اکثر تکنیک های مدیریت پروژه، آنهایی که در کتب استانداردهای مدیریت پروژه ثبت شده اند، در دهه پنجاه و شصت میلادی تولید شده اند؛ تکنیک مسیر بحرانی، PERT، ارزش کسب شده، آنالیز مشتریان و بقیه آنها. شاید به غیر از زنجیره بحرانی که در اواخر دهه نود به میان آمده دیگر نتوان از تکنیک جدیدی اسم برد. نرم افزارها نیز با توجه به رشد پیکربندی سیستم ها رشد کرده اند. آنچه در کتب مدیریت پروژه بیشتر درج می شود همین تکنیک ها هستند. شاید ما به عنوان خواننده بیشتر به همین تکنیک ها توجه می کنیم. ولی واقعیت این است که تکنیک ها حکم بیگ مک را دارند و اصل سود در جای دیگری نهفته است. آموزش تکنیک های مدیریت پروژه چه در غالب تئوری و چه در غالب نرم افزاری در کوتاه مدتی امکانپذیر است. این کاری است که ما سالهاست به آن مشغولیم، اما به طرز قابل ملاحظه ای نمی توانیم از "فواید" این آموزش ها بهره مند شویم! چرا؟ به دلیل اینکه اصل قضیه در بهره مندی مورد انتظار در جای دیگری قرار دارد که بر روی پارچه نوشته های بزرگ تبلیغاتی دیده نمی شوند. بهره مندی از تکنیک های مدیریت پروژه مدیون استقرار "منش" و رفتار پروژه ای است. سازمان ها حاضر هستند که برای آموزش تکنیک ها هزینه کنند، که این هم خود جای قدردانی دارد! اما برای تغییر رفتار و استقرار منش پروژه ای تا به امروز سازمانی را در کشور مشاهده نکرده ام که جرأت لازم را داشته باشد. توجه کنید! نمی توان تکنیک مسیر بحرانی را در سازمان مستقر کرد وقتی که نظم لازم برای انجام کارها وجود ندارد. نمی توان قراردادها را مدیریت کرد در حالیکه ثبت وقایع پروژه اهمیتی ندارد. نمی توان پروژه را مدیریت کرد در حالیکه معلوم نیست ذینفع مالک است، مدیر است یا پیمانکار!
ما در اوک برای چند وقتی است که با شرکت های بزرگ پروژه ای دنیا در حال تبادل افکار هستیم، آنها بیشتر می گویند و ما بیشتر گوش می کنیم!! در بُعد تکنیک ها و اطلاعات، به نظر می آید که ما نسبت به آنان چیزی کم نداریم. شاید در بسیاری از اوقات دانش و اشراف شرکت های معتبر نسبت به تکنیک ها تعجب ما را بر انگیخته باشد. اما در بُعد منش کار پروژه ای، دنیایی از یادگیری وجود دارد. هنگام تهیه ساختار های تقسیم کاری قبل از اینکه به معیارهای تجزیه بپردازند به مالکیت آن توجه می کنند، چه ارگانی در تهیه، نگهداری و توزیع آن مسئولیت دارد و در انتها باید پاسخگو باشد. برای تشکیل جلسات باید دستور جلسه نوشت و در پایان هم صورت جلسه تهیه کرد. مهمتر از همه چیز، در مقابل تأمین اهداف پروژه در داخل سازمان باید مسئولین و پاسخگویان مشخص گردند. بعد از اتمام پروژه زمانی را برای استراحت و بازیابی انرژی تخصیص می دهند.
رفتار و منش پروژه ای کار کردن نیاز اصلی موفقیت در پروژه هاست، نه بیگ مک تکنیک ها؛ توجه کنیم.

 مهندسی و مدیریت ساخت  (ICEMA)  Construction Engineering Management



ارسال شده در:

مدیریت پروژه، نانو تکنولوژی، اخلاق

سه شنبه 8 فروردین 1396
11:55
امیرحسین ستوده بیدختی
مدیریت پروژه، نانو تکنولوژی، اخلاق

اندازه جرم مواد در محدوده علم نانو به اندازه یک میلیاردیم (9-10) متر است. در این اندازه، اثر قوه جاذبه بر روی اجرام ناچیز بوده، در عوض اصطکاک سطح افزایش می یابد. با استفاده از تکنولوژی نانو می توان به موادی دست یافت که به لحاظ استحکام و انعطاف، باورنکردنی باشند. مهم این است که بتوان جرم را در این اندازه تولید نمود و سپس محیطی را فراهم نمود که با یکی از متدولوژی های متداول بتوان آنها را به هم پیوند زد.
این مفهوم کوچک سازی اجرام، البته در اندازه های بسیار کوچک، همان مطلبی است که می تواند در تدوین متدولوژی های مؤثر مدیریت پروژه در ایران کارآیی داشته باشد. اگر بتوان کارهای پروژه را به اندازه های کوچک تقسیم کرد، خیلی کوچک، حالا اگر به اندازه نانو نباشند حداقل سایز مایکرو داشته باشند، چه اتفاقی می افتد؟ اگر کارها کوچک شده باشند تأثیر "قدرت جاذبه" بر روی آنها کمتر خواهد شد. اما قدرت جاذبه در این محیط چیست؟ به نظر من قدرت جاذبه در محدوده مدیریت پروژه همان "تخصص" است. یعنی اگر کارها را به اندازه های کوچکتری تقسیم کنیم برای اجرای آنها به تخصص کمتری نیاز خواهیم داشت. این موضوع چندان پیچیده نیست! وقتی که کار تجزیه گشته و به اندازه کوچکتری در می آید، از پیچیدگی آن کاسته و ساده تر خواهد شد. کار ساده تر را با تخصص کمتر نیز می توان انجام داد. این عمل با مفهوم نانو کاملاً مطابقت دارد. از طرف دیگر به علت اینکه کارها ساده تر شده اند، و به تبع آن تعداد آنها نیز بیشتر گشته، لذا اصطکاک بین کارها بیشتر خواهد شد. درست مانند همان پدیده ای که در نانو انتظار آن می رود. تبلور اصطکاک سطحی در محدوده مدیریت پروژه "ساختار سازمانی" پرو ژه است. پس با تجزیه کارها به اندازه های کوچکتر می توان نیاز به تخصص را کاهش داد، و این خود کمک بسیار بزرگی برای اجرای پروژه هایی است که به متخصصین با تجربه زیادی نیاز دارد، و برای مدیریت اصطکاک ناشی از افزایش کارها باید ساختار سازمانی مناسب را طراحی کرد.
بسیار خب، اینک که مفاهیم نانو را در طراحی متدولوژی مدیریت پروژه مطرح کرده و قرینه های آنها را ترسیم کردیم به الزامات اجرایی نیز توجه می کنیم. آنچه از اجرایی کردن مفاهیم فوق به دست می آید احتیاج کمتر به تخصص و در نتیجه جبران ریسک های متناظر با آن می باشد. اما لازمه موفقیت، طراحی سازمان مناسب خواهد بود. سازمانی که به علت حضور تعداد زیادی از کارشناسان کم تجربه، از ضعف ثبات سازمانی رنج خواهد برد. بسیاری از کارشناسان جوان در مصاف با پروژه ها به اصطلاح "کم" می آورند. از دوری خانواده گرفته تا انتظاراتی که تأمین کننده نظریه "یک شبه ره صد ساله رفتن" باشد. چگونه این اصطکاک سطحی را مدیریت خواهیم کرد؟ کلید موفقیت سازمان پروژه در همین موضوع نهفته است. در چنین شرایطی که از یک طرف کشور از کمبود متخصصین باتجربه رنج می برد، و از طرف دیگر با جوانانی سر و کار دارد که باید تحت نظر مراقبت های "ویژه" قرار گیرند، چگونه می توان سازمانی مؤثر و کارآ را با همین نیروها تدارک دید؟ پاسخ این سؤال جاری نمودن فرهنگ مناسب توسط مدیران ارشد سازمان های پروژه ای است. فرهنگی که اخلاق را در رأس توجهات خود قرار دهد، و مدیرانی که به آن فرهنگ عمل نمایند. باز هم برمی گردیم به موضوع اساسی ایجاد صلابت سازمانی؛ اخلاق. می خواهم از نانو شروع کنم و یا از هر نقطه دیگر ولی لاجرم تضمین اجرای مناسب تمامی تئوری هایی که در زمینه مدیریت سازمانی می دانم، بر می گردد به اخلاق. اینک شما قضاوت کنید، در مجموعه دروس مدیریت پروژه، در دانشگاه های معظم دنیا، و یا دانشگاه های خودمان، که اینک بعضی از آنها به عنوان بهترین دانشگاه های مهندسی دنیا شناخته می شوند، کدام یک به اخلاق در پروژه توجه می کنند؟ خودتان را خسته نکنید، صفر! ما در طی سال ها کار کردن در ایران مسائل مدیریت پروژه را شناسایی کرده ایم، در همین مدت نیز در محیط پروژه ها کار کرده ایم، و اینک به شما خوانندگان محترم می گوییم که تجربه ما می گوید که از بی اخلاقی، بد اخلاقی، کج اخلاقی رنج می بریم و به دلیل نبود و یا رقیق بودن مبانی اخلاقی در پروژه ها سازمان های محکم و مؤثر پروژه ای نیز نداریم. مسئله را می دانیم، راه حل را نیز می بینیم، اما نمیدانم چه بلاهتی است که همچنان بر تکنیک های "سیب زمینی" تأکید داریم. تنها چیزی که می تواند این روحیه را توجیه نماید بی علاقگی به پیشرفت کشور است. رمز موفقیت در اجرای موفق مفاهیم نانو در متدولوژی های مدیریت پروژه، استقرار مبانی و فرهنگ اخلاقی سازمانی است.

 مهندسی و مدیریت ساخت  (ICEMA)  Construction Engineering Management


ارسال شده در:

مدیریت ذی‌نفعان پروژه

چهارشنبه 25 اسفند 1395
01:42
امیرحسین ستوده بیدختی
مدیریت ذی‌نفعان پروژه
مطابق تعریف موسسه PMI، مدیریت پروژه شامل به کارگیری دانش، مهارت‌ها، ابزارها و تکنیک‌ها در ارتباط با فعالیت‌های پروژه، برای تأمین نیازها و انتظارات ذی‌نفعان است. بنابراین بدون توجه به نیازها و انتظارات ذی‌نفعان مختلف، احتمال دارد پروژه موفق تلقی نشود، هرچند در زمان و محدوده مشخص و با هزینه تعیین شده تمام شود.
ذی‌نفعان،متشکل از افرادی با زمینه‌های متفاوت از علایق،پیشینه و مهارت‌ها هستند. ذی‌نفعان ممکن است خواسته های معارضی در پروژه داشته باشند. بنابراین مدیریت ذی نفعان باید بتواند تعادلی را در ارتباط با منابع موجود بین خواسته‌های مختلف و بعضاً متعارض بخش های مختلف پروژه برقرار کند.
شرایط محیطی پیچیده و غیر قطعی، دستیابی به تعادل و مدیریت ذی‌نفعان را دشوار می‌کند. لیکن برای رسیدن هماهنگی بین ذی‌نفعان و تیم پروژه، باید از درک صحیح اهداف پروژه توسط افراد مطمئن شده و بازخوردهای آن‌ها دریافت و بررسی شود. به این ترتیب با مشارکت دادن ذی‌نفعان در مرحله برنامه‌ریزی می‌توان از بسیاری از مشکلات آتی پیش‌گیری کرد.
به طریق ذکر شده، برنامه‌های ذهنی و پنهان افراد آشکار شده و اولویت‌بندی‌های پروژه شکل می‌گیرد. بنابراین مدیران پروژه برای شناسایی ذی‌نفعان و همکاری با آن‌ها به منظور درک ارتباطات و تاثیرشان بر موفقعیت پروژه، نیاز به مهارت‌های تحلیلی و درک عینی دارند.
تعریف ذی‌نفعان
مشارکت دادن ذی‌نفعان در پروژه می‌تواند فواید زیر را به‌دنبال داشته باشد:
افزایش تعهد ذی‌نفعان
کاهش هدر رفتن تلاش، زمان و سایر منابع
کاهش ریسک ایجاد تضادها و در پی آن کاهش دعاوی و اختلاف‌ها
ارائه خدمات بهتر به مصرف‌کنندگان نهایی
پیش‌بینی بهتر موضوعات آتی
انگیزش بهتر افراد

 مهندسی و مدیریت ساخت  (ICEMA)  Construction Engineering Management


تعاریف دیگر مدیریت ذی‌نفعان

نخستین بار فریمن در سال ۱۹۸۴ مفهوم “ذینفعان” را در قالب یک ساختار و تعریف منسجم مطرح کرد و برای آن هویتی منحصر‌به‌فرد، در بحث مدیریت، قائل شد:
فرد یا گروهی که می‌تواند بر دست یابی یک سازمان به اهدافش تأثیرگذار باشد یا از دست یابی سازمان به اهدافش تأثیر می‌پذیرد.
دیگر از تعاریف‌ نیز توسط محققان دیگر نیز به شرح زیر ذکر شده است.
فرد یا گروهی که از موفقیت پروژه و محیطی که پروژه در آن اجرا می‌شود، انتظار منافعی دارند. (Mc Elory & Mills. 2007)
رابطه آن ها با سازمان را نمی‌توان محدود به رابطه‌ی قراردادی یا اقتصادی دانست بلکه روابطی اجتماعی با سازمان دارند. (Clarkson Centre for Business Ethics 1999)
افرادی که سرمایه ای در سازمان دارند که در معرض ریسک قرار دارد و به واسطه آن و درنتیجه فعالیت‌های سازمان ممکن است چیزی را به‌دست آورده یا از دست بدهند. (Clarkson Centre for Business Ethics 1999)
افراد یا گروهی که نسبت به بعضی جنبه‌های ماهوی پروژه یا ادعای مشروح دارند و یا تصور می‌کنند که ادعای آن‌ها مشروع است. مفهوم ذی‌نفع، یک علاقه یا سهم یا ادعا در یک پروژه است. دامنه این نفع ممکن است از یک علاقه غیررسمی تا یک ادعای قانونی مالکیت را شامل شود. (Cleland. 1998)
افراد یا گروه هایی که ادعاهای آن ها در سازمان مشروعیت یا فوریت داشته و قدرت تأثیرگذاری بر تصمیمات سازمان را دارند. (Mitchell, Agle, & Wood 1997)
کسانی که تجربه منافع و یا ضررهای بالقوه ای درنتیجه فعالیت های سازمان را دارند. (Donaldson & Preston 1995)
ذی‌نفعان داوطلب، گروه یا افرادی هستند که با سرمایه گذاری مالی و یا انسانی در پروژه، متومل ریسک شده‌اند. ذی‌نفعان غیرداوطلب، به علت فعالیت های پروژه درمعرض ریسک قرار گرفته‌اند. بدون فاکتور ریسک، ذی نفعی تعریف نمی‌شود. ( Clarkson, M. 1994)
گروه هایی که بدون پشتیبانی آنان حیات سازمان متوقف می‌گردد. (Standard Research Institute. 1963)
افرادی هستند که می توانند به سازمان کمک کرده و یا به آن آسیب برسانند. (Miller and Lewis1991)

ارسال شده در:

علل شکست پروژه‌ها

چهارشنبه 25 اسفند 1395
01:20
امیرحسین ستوده بیدختی
علل شکست پروژه‌ها
چرا پروژه‌ها موفق نمی‌شوند؟

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

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

 مهندسی و مدیریت ساخت  (ICEMA)  Construction Engineering Management


علل شکست در فاز اجرا:

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

علل شکست پروژه‌ها در فاز کنترل و اختتامی:

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

3 تکنیک برای مدیریت محدوده پروژه

یکشنبه 15 اسفند 1395
09:12
امیرحسین ستوده بیدختی
3 تکنیک برای مدیریت محدوده پروژه

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

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

    در پروژه های بزرگ، یک کمیته کنترل تغییر تشکیل دهید. گاهی اوقات در پروژه های بسیار بزرگ، حامی مالی پروژه نمی تواند به تنهایی در مورد تغییر محدوده، تصمیم بگیرد. این مورد خصوصاً زمانی اتفاق می افتد که تغییر، سازمان های دیگر را نیز تحت تأثیر قرار دهد؛ یا زمانی که چندین سازمان در سرمایه گذاری برای پروژه، همکاری یا مشارکت داشته باشند و بخواهند در ارزیابی درخواست های تغییر محدوده، نظر بدهند. در اینگونه موارد، ممکن است لازم باشد تا گروهی از افراد، تغییر محدوده را تصویب نمایند. معمولاً به این گروه "کمیته کنترل تغییر" گفته می شود.

 مهندسی و مدیریت ساخت  (ICEMA)  Construction Engineering Management


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

مهندسی نجومی

یکشنبه 15 اسفند 1395
08:38
امیرحسین ستوده بیدختی
2 تکنیک برای کمک به برنامه ریزی پروژه

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

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

 مهندسی و مدیریت ساخت  (ICEMA)  Construction Engineering Management


ارسال شده در:

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

پنجشنبه 12 اسفند 1395
06:36
امیرحسین ستوده بیدختی
چطوری منشور پروژه تهیه کنیم؟

 

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

 

الان اینجا چه اتفاق‌هایی افتاد؟

اول این‌که پروژه به عهده یه مدیر ارشد گذاشته شد. این به این معنی نیست که اون آدم مدیر پروژه می‌شه؛ نه، اون می‌شه مالک پروژه. دلیلش هم اینه که هر پروژه‌ای نیاز نفوذ و قدرت یه مدیر ارشد داره. تو پم‌باک به این آدم می‌گن Sponsor (حامی پروژه) و تو پرینس۲ بهش می‌گن Executive.

اون جایی که تو جلسه بحث نرم‌افزار پیش کشیده شد و بررسی پروژه رو شروع کردن هم می‌شه project mandate (جرقه پروژه).

 

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

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

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

 

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

 

از نظر پرینس۲ همه این کارها می‌شن بخشی از فرآیند راه‌اندازی پروژه (starting up a project).

 

در نهایت، بعد از این‌که قرارداد بین مدیر ارشد و سازمان بسته شد، یعنی منشور پروژه تایید شد، نوبت به قرارداد بین مدیر پروژه و مدیر ارشد میرسه. میدونین این قرارداد چیه؟ این قرارداد همون برنامه پروژس که تو پرینس۲ بهش می‌گیم Project Initiation Documentation (سند آغازش پروژه) و تو پم‌باک Project Management Plan (برنامه مدیریت پروژه). این برنامه تهیه می‌شه و وقتی به تایید برسه یعنی قراردادی بین مدیر پروژه و مدیر ارشد بسته شده؛ مدیر پروژه محصول پروژه رو تهیه می‌کنه و مدیر ارشد منابع رو در اختیارش می‌ذاره. این قرارداد رو می‌شه نسخه تفصیلی منشور پروژه دونست، که در هر حال باید با هم سازگار باشن.

 

 مهندسی و مدیریت ساخت  (ICEMA)  Construction Engineering Management


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

 

این بخش از کار می‌شه فرآیند آغازش پروژه (initiating a project) پرینس۲.

 
ارسال شده در:

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

پنجشنبه 12 اسفند 1395
06:25
امیرحسین ستوده بیدختی
رویکرد چابک به محدودیت‌های سه‌گانه پروژه

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

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

رویکرد چابک اترن

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

تو رویکرد چابک اترن (DSDM Aten) برعکس عمل می‌کنیم، یعنی هزینه و زمان و کیفیت رو از ابتدا مشخص و ثابت می‌کنیم و گستره رو کم و زیاد می‌کنیم.

به نظرتون عجیب میاد، نه؟ مثلا یه پیمانکار با کارفرماش قراردادی می‌بنده که توش مدت زمان و هزینه و کیفیت کار به دقت مشخص شده، ولی گستره کار اجازه داره که تغییر کنه!

 

 مهندسی و مدیریت ساخت  (ICEMA)  Construction Engineering Management


کاری که با گستره می‌کنیم اینه که با تکنیک اولویت‌بندی مسکو مدیریتش می‌کنیم:

 

 مهندسی و مدیریت ساخت  (ICEMA)  Construction Engineering Management


MoSCoW Prioritization

 

حروفی که تو مسکو (MoSCoW) هستن ابتدای این عبارت‌هان:

    Must have – اون بخش‌هایی از گستره که حتما باید تولید بشن و اگه نباشن محصول نهایی پروژه اصلا به درد نمی‌خوره.
    Should have – اون بخش‌هایی از گستره که واقعا بودنشون لازمه، ولی اگه نباشن باز هم می‌تونیم از محصول نهایی پروژه استفاده کنیم، فقط ممکنه لازم باشه یه راه حل‌های جانبی برای بعضی کمبودها در نظر بگیریم.
    Could have – اون بخشی از گستره که خیلی خوشمون میاد تو محصول نهایی باشه، ولی نباشه هم اتفاقی نمی‌افته.
    Won’t have this time – اون چیزهایی که فعلا قصد نداریم تو محصول نهایی پروژه باشه؛ هرچند که ممکنه به نظر مرتبط بیاد.

 

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

برعکسش، اگه محصول همه Mustها و Shouldها و Couldها رو داشته باشه، می‌شه محصول ایده‌ال.

 

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

 

از این روش تو پروژه‌هایی استفاده می‌شه که:

    تغییرات و عدم قطعیت زیاد باشه
    و تا وقتی کارفرما بخش‌هایی از کار رو ندیده باشه نتونه انتظارهای خودش رو به روشنی مشخص کنه

 

که عمدتا می‌شه:

    پروژه‌های نرم‌افزاری
    پروژه‌های تحقیقاتی
    پروژه‌های تغییر سازمانی

 

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

 

ایده‌ای که پشت همه این‌ها هست همون قاعده ۲۰/۸۰ هست؛ این‌که حدود ۸۰ درصد ارزش محصول نهایی پروژه با حدود ۲۰ درصد گستره اون ایجاد می‌شه. پس چرا:

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

 

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

ایجاد ظرفیت های لازم کاری

سه شنبه 10 اسفند 1395
01:00
امیرحسین ستوده بیدختی
 پروژه کاران عزیز، چه آنهایی که مدتهاست در این راه گام برمی دارید و چه آنانی که به تازگی به این جرگه پیوسته اید: اصل اساسی ظرف و مظروف را شناسایی کنیم و محترم بداریم. ظرفیت کاری یک پروژه فقط محدود به دانش فنی و توانایی اجرایی نمی گردد؛ ظرفیت های قراردادی، مالی و بانکی، تجاری و امور بین الملل، مدیریت نیروی انسانی، روحی و روانی، روابط عمومی و سازمانی همه در تعریف ظرفیت پذیرش کار توسط پروژه کاران نقش بسیار مهمی ایفا می نمایند. متأسفانه نمی توانم به هر یک از این عوامل مؤثر وزنی بدهم و لذا تعیین اینکه کدام مهمتر است اساساً برای من امکان پذیر نیست. تنها می دانم که برای انجام پروژه، و مهمتر از آن، جایگاهی که یک پروژه کار در پروژه خواهد داشت، این عوامل تأثیر به سزایی خواهند داشت. سازمانی که تنها دانش فنی و توانایی اجرای کار را داشته باشد و در جهات دیگر خود را توسعه نداده باشد نمی تواند به عنوان شریک مهم پروژه فعالیت نماید. این مطلب را به خصوص برای تازه واردان متذکر می شوم که توجه داشته باشند برای توسعه دادن و وزنه ای در بین بزرگان شدن می باید به این عوامل، به مجموعه آنها، توجه داشت. بهتر است با منابع مالی ارتباطات خوب برقرار نماییم، حتماً در تدوین قراردادها و مدیریت بر آنها از کادر ماهر بهره ببریم و روابط عمومی را با بودجه تعریف شده اداره کنیم. این عوامل در اینکه ما چه جایگاهی در عرصه بازار پروژه ها می توانیم داشته باشیم، به خصوص اگر به دنبال بازارهای فراملی هستیم، بسیار مهم خواهند بود. پیمانکار جزء می تواند کار را اجرا کند، پیمانکار اصلی می تواند کار را مدیریت کند، اما شرکت مادر می تواند در آنِ واحد حداکثر سود را در پروژه به دست آورده، اعتبار خود را ارتقا دهد.

 مهندسی و مدیریت ساخت  (ICEMA)  Construction Engineering Management



منادله!!!

سه شنبه 3 اسفند 1395
02:43
امیرحسین ستوده بیدختی
 چه خاطراتی که از منادله ها در جریان پروژه ها ندارم! نه اشتباه ننوشتم، منظورم دقیقاً منادله بود، هر چند که به گوش بسیاری، این واژه ای اشتباه است. در طی جلسات هدایتی پروژه وقتی طرفین روبروی هم قرار می گرفتند، به جای اینکه راجع به "آنچه که باید انجام می شده"، در مقابل "آنچه که انجام شده" (در اصطلاح پروژه کارها مقایسه بین Plan و Actual) صحبت کنند، راجع به "درد دل ها" بحث می کردند. برای همین جلسه ای که باید صرف بیان نظرات طرفین می گردید به جلسه ای پیرامون درد دل های طرفین تبدیل می شد. برای همین اسم این جلسات را منادله گذاشتیم؛ یعنی به جای "نظر" بهتر است از "دل" بگوییم. اصلاً مثل اینکه واقعاً ما تافته ای جدابافته هستیم، چرا که "منادله" را درک نمی کنیم و به سادگی گیچ می شویم؛ در حالی که این فرهنگ غالب در جامعه ما محسوب می شود. به هیچ عنوان مهم نیست که چه باید انجام می دادی، شاید هم هیچوقت نگفته باشی که چه می خواهی انجام دهی، اما تا می توانی درد دل کن، بدین ترتیب شنوندگان نسبت به موضع شما (این همه پرانتز، چون نمی شود یک راست به اصل مطلب بپردازیم، آخر اسم بردن از واژه "موضع" نیز به نوبه خود خیلی خنده دار است ) بیشتر احساس همدردی می کنند. چه بسا که در حین ابراز درد دل ها بسیاری از عقده ها نیز سر باز کنند و روح شنوندگان نیز آرام گیرد.
باز یادم می آید که گروهی از پیمانکاران علیه ما "ادعا" داشتند. هر چه به ایشان گوشزد می کردیم که ادعای شما باید تفاوت بین آنچه توافق کرده ایم با آنچه انجام داده ایم باشد، باز هم به سراغ مجموعه جفاهایی می رفتند که در طی پروژه بر سرشان آمده بود، آن هم جفاهایی که خود تشخیص می دادند. من این نگرش، یعنی مجالس منادله را، در دانشگاه دیدم، در پروژه ها دیدم، در جلسات خانوادگی دیدم، در جلسات مذاکره بین کاری دیدم، و چند شب پیش هم دیدم. مثل اینکه تئوری اندازه گیری (Measure Theory)، تلاش بشریت، من جمله دانشمندان ایرانی، برای اندازه گیری و مهندسیِ اقلام و اعمال، هیچ جایگاهی نزد امروز ایران ندارد. بخوانیم "وَ وَضَعَ المیزان" ولی بدون میزان، بدون خط کش، بدون Measure برای تحقیر یکدیگر از روش هایی استعانت بجوییم که در فرهنگ خود ما نیز قباحت دارد.
مناظره فرمول ساده ای دارد:

 مهندسی و مدیریت ساخت  (ICEMA)  Construction Engineering Management


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

باور کنید که اجرای این روش نیازی به مدرک دکتری ندارد، مهندس هم باشید کافی است، اما حیف از اینکه مهندس و دکتر راضی به اجرای مناظره نمی شوند و روش های منادله را بیشتر می پسندند. 
ارسال شده در:

آیا پروژه شما امکانپذیر است؟

پنجشنبه 21 بهمن 1395
12:23
امیرحسین ستوده بیدختی
آیا پروژه شما امکانپذیر است؟

برای بررسی امکانپذیری، لازم است پروژه از چند جنبه مورد تجزیه و تحلیل قرار گیرد:

    فنی: آیا پروژه از لحاظ فنی، امکانپذیر است؟ اگر بله، باید ریسک های مرتبط با پروژه را بیان کنید.

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

    عملیاتی: آیا راه حل پروژه را می توان عملیاتی کرد؟ ممکن است خودِ پروژه، امکانپذیر باشد، اما عملیاتی کردن راه حل پس از پایان پروژه، ریسک زیادی به همراه داشته باشد.

    جغرافیایی: آیا پروژه با توجه به مکان فیزیکی تیم پروژه یا مشتری، عملی است؟

    زمان: آیا پروژه با توجه به مقدار زمانی که از دست اندر کاران نیاز دارد، شدنی است؟ در پروژه های بزرگ، این یک نگرانی بزرگ است. ممکن است شما بودجه اجرای پروزه را داشته باشید، اما نتوانید زمان تیم پروژه را به اندازه کافی آزاد کنید تا پروژه را اجرا نمایند.

    منابع: آیا افراد، تجهیزات، لوازم و سایر منابع مورد نیاز برای تکمیل پروژه را در اختیار دارید؟ یا می توانید تأمین کنید؟

    حقوقی: آیا هیچگونه مشکل حقوقی وجود دارد که پروژه را غیرعملی سازد؟

    سیاسی: آیا هیچگونه مشکل سیاسی داخلی (یا خارجی) وجود دارد که پروژه را غیرعملی سازد؟

 مهندسی و مدیریت ساخت  (ICEMA)  Construction Engineering Management


ارسال شده در:

چگونگی تغییر دادن برنامه پروژه

یکشنبه 17 بهمن 1395
07:57
امیرحسین ستوده بیدختی
چگونگی تغییر دادن برنامه پروژه

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

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

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

 مهندسی و مدیریت ساخت  (ICEMA)  Construction Engineering Management


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

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

    برنامه کامل جدید را منتشر کنید. اعضای تیم و سایر افراد درگیر را از تغییر مطلع سازید. اجازه بدهید که همه بدانند برنامه پروژه، اکنون مجدداً کامل شده است.
ارسال شده در:

وبلاگ انجمن مدل سازی اطلاعات ساختمان ایران - مطالب ابر پروژه


وبلاگ انجمن مدل سازی اطلاعات ساختمان ایران - مطالب ابر پروژه,
تمامی حقوق این وب سایت متعلق به وبلاگ انجمن مدل سازی اطلاعات ساختمان ایران است. |طراحی و توسعه:امیرحسین ستوده بیدختی|