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


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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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


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

مهندسی نجومی

1395/12/15
20:38
امیرحسین ستوده بیدختی امیرحسین ستوده بیدختی
2 تکنیک برای کمک به برنامه ریزی پروژه

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

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

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



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

1395/12/12
18: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) پرینس۲.

 

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

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