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

سال نو مبارک

متدولوژی P3.express

1395/12/25
15:16
امیرحسین ستوده بیدختی
آشنایی با متدولوژی P3.express
مشکلات PMBOK و Prince2
بسیاری از ما با استانداردهایی مانند PMBOK و Prince2 آشنا هستیم. همه‌ی ما بعنوان فعالان یا مدیران پروژه در پروژه‌ها در صدد به‌کارگیری این استاندارها هستیم. این‌که چقدر این استاندارها و مدیریت پروژه می‌تواند در پروژه‌ی ما ارزش را افزایش دهد و کمک حال ما باشد امر بدیهی است ولی مشکل این‌جاست که چگونه این استاندارها را به کار ببریم؟؟ شاید در فکر کنید که این مشکل فقط مشکل شماست ولی این مشکل بسیاری از مدیران پروژه است. در ایران مدیران پروژه هنگام پیاده‌سازی می‌گویند این استاندارها به درد ما نمی‌خورد این‌ها برای شرایط کشورهای پیشرفته غربی است. همین موارد را در اروپا مشاهده می‌کنیم که مدیران پروژه اعتقاد دارند این استاندارها برای آمریکاس! آمریکایی‌ها هم از این قاعده مستسنی نبوده و این موارد را مربوط به کشورهای ماشینی مثل آلمان می‌دانند. پس شما تنها نیستید و خیلی‌ها مثل شما دنبال راه حل این مساله هستند.

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


مشکلات مدیران پروژه در اجرای PMBOK و Prince2
یک مدیر پروژه با مسائل و مشکلات زیادی در پروژه درگیر است. مسائلی مانند کمبود بودجه، نبود منابع انسانی، تغییرات زیاد در پروژه و … در این موارد نیاز به کمک دارد. استانداردها باید بتوانند به وی کمک کنند. حال آن‌که آیا مشکلات را حل می کنند یا این‌که مدیران پروژه را با انبوه جدیدی از کارها و مشکلات پیاده‌سازی روبه‌رو می‌کنند جای تامل دارد. مشکل عظیمی در پیاده‌سازی داریم. چرا که موارد بسیاری داخل استاندارد وجود دارد که حجم کار را بالا می‌برد. مشکل بعدی این است چگونه این موارد را در کنار هم بگذاریم! گاهی کنترل کار از دست ما بعنوان مدیرپروژه خارج می‌شود. این استاندارها یک روش کار به ما ارائه نمی‌دهند و ما برای پیاده‌سازی آن‌ها نیاز به متدولوژی داریم. مثلا باید بدانیم پیشرفت را چگونه اندازه بگیریم و آن را با دیگر بخش‌های پروژه هماهنگ کنیم. مشکل بعدی نداشتن ابزار یا بهتر بگویم ابهام در مورد نرم‌افزاری که باید در پروژه استفاده کنیم است. البته انتخاب نرم‌افزار سخت نیست. این‌که چگونه PMBOK یا Prince2 را در نرم‌افزار پیاده کنیم مشکل ماست.

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

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

P3.xpress به اختراع دوباره چرخ نپرداخته و بر اساس استاندارهای PMBOK و Prince2 تهیه شده است. یعنی نسخه‌ی اختصاصی شده آن‌هاست. برخی از تهیه‌کنندگان آن اعتقاد دارند P3.express یک مثال پیاده شده PMBOK و Prince2 است. در این متدولوژی روش‌ها و ابزارهای مورد نیاز مدیران پروژه در نظر گرفته شد است.

express برای پروژه‌های کوچک و متوسط
استاندارد P3.express
استاندارد P3.express یک متدولوژی رایگان جهت استفاده عموم است. این متولوژی بر اساس استاندارهای PMBOK و PRINCE2 تهیه شده است. این متولوژی را در مدت کوتاهی می‌توانید یاد بگیرید و در پروژه‌هایتان به کار ببرید.
متودولوژی P3.express
استاندارد P3 کار غیر معمول و پیچیده‌!
استاندارد P3.express به اختراع دوباره چرخ نپرداخته بلکه بر اساس استانداردهای PMBOK و PRINCE2 و مزایای استانداردهایی مانند DSDM® و Scrum شکل گرفته است.
متدولوژی واقع‌بینانه
استاندارد P3.express یک متدولوژی است که شما در عمل می‌توانید استفاده کنید. استاندارهای پایه‌ای بسیار گرانند و در عین حال برای پروژه‌های معمولی بسیار پیچیده‌اند. به این دلیل بسیاری از مردم نمی‌توانند از آن‌ها استفاده کنند.
یکپارچگی کامل
استاندارد P3.express یک پکیج یکپارچه کامل از متدولوژی‌ها، شیوه‌ها و ابزارها می‌باشد. شما نیاز به فراهم‌آوردن تکنیک ویژه برای اجرای آن ندارید. شما با استفاده از یک سری متد ساده و با کمک نرم‌افزاری مثل Exel می‌توانید آن را اجرا کنید. همه‌چیز آمادس عجله کنید.
Unknown
استاندارد P3 با در نظر گرفتن منابع انسانی
در این استاندارد مشکل اولیه همه‌ی پروژه‌ها، یعنی جنبه‌های نرم و انسانی در نظر گرفته شده است. این عامل، P3.express را از استانداردهای دیگر متمایز می‌کند. یک رویکرد مناسب جهت اجرا با جنبه‌ی انسانی به جای محدود کردن به جنبه‌های ماشینی در این ساختار ارائه شده است.
تحت مجوز Creative Commons
این استاندارد تحت لیسانس Creative Commons است. این یعنی می توانیم رایگان آن را فرا بگیریم، استفاده کنیم و آموزش دهیم. به همین دلیل از استعداد، توانایی و تجارب همه‌ی فعالان این حوزه جهت بهبود آن در طول زمان بهره می‌برد.
۲۰/۸۰ پارتو
ایده‌آل‌گرایی همیشه دشمن خوب بودن است. در P3.express توصیه اکید رسیدن به ۸۰ درصد از خواسته‌ها با ۲۰ درصد تلاشمان هستیم. اگر بدنبال ۱۰۰ باشید ناامید شده و کار را به مقصود نمی‌رسانید.
متدولوژی P3
جامعه هدف استاندارد P3.express
این استاندارد با بیشتر پروژه‌های کوچک و متوسط که در صنایع مختلف ایجاد می‌شوند سازگاری دارد. توصیه این است که در پروژه‌های پیچیده اصلا از این استاندارد استفاده نکنیم.
آغاز به کار با متودولوژی P3.express
در مقاله قبلی به مشکل بسیاری از مدیران پروژه در پیاد‌ه‌سازی استانداردهای بنیادین مدیریت پروژه مانند PMBOK و Prince2 پرداختیم. همچنین دلیل این مشکلات را ریشه‌یابی کرده و راه‌حل احتمالی آن را در پیاده‌سازی و استفاد از متودولوژی P3.express یافتیم. حال در این مقاله می‌خواهیم یک نگاه جامع و کلی به کلیات متودولوژی P3.express بیاندازیم تا فهم اولیه جهت بکارگیری آن داشته باشیم.
چهار ویژگی اصلی متودولوژی P3.express
متودولوژی P3.express بر اساس استانداردهای موجود اخصصاصی سازی شده است. شما این‌طور در نظر بگیرید که یک مثال عملی از PMBOK یا Prince2 است. پس نگران نباشید نکات اصلی و عملی این استانداردها در متودولوژی P3.express موجود است.
در متودولوژی P3.express روش‌ها جهت استفاده شما فراهم شده است. مثلا شما می‌دانید که چگونه باید زمانبندی کنید. چگونه ساختار سازمان را تهیه کنید یا …
متودولوژی P3.express در مورد ابزارها راه‌حل عملی به شما ارئه می‌دهد. استفاده از ترکیب‌های مختلف نرم‌افزار را به شما پیشنهاد می‌دهد. پس کارتان بسیار ساده‌تر است.
نکته‌ی دیگر و مهم متودولوژی P3.express در نظر گرفتن جنبه‌های انسانی در اجرای مدیریت پروژه‌ است. در برخی از استانداردها اصلا بحث جنبه‌های انسانی پروژه در نظر گرفته نشده است، در برخی دیگر که این مباحث موجود است، فقط بیان شده و در اجرا شاید زیاد به ان پرداخته نشده باشد. حال آن‌که متودولوژی P3.express با در نظر گرفتن این موارد شکل گرفته است.
کلیات متودولوژی P3.express
اصل پارتو در متودولوژی P3.express
قانون ۲۰\۸۰ به دو شکل در متودولوژی P3.express موجود می‌باشد.
ایده‌آل ما این است به ۱۰۰ درصد منافع مدیریت پروژه در پروژه خود دست پیدا کنیم. به نظر شما آیا دست‌یابی به این خواسته در شرایط دینامیک پروژه‌ها دشوار نیست؟ نیاز به یک تلاش زیاد و جامع دارد. در بسیاری از موارد به علت سخت بودن دست‌یابی به ۱۰۰ درصد در نیمه‌ی راه خسته شده و آن را رها می‌کنیم. شاید به ۱۰یا ۲۰ درصد ایده‌آل برسیم. حال متودولوژی P3.express بر اساس دست‌یابی به ۸۰ درصد منافع با ۲۰ درصد تلاش شکل گرفته است. می‌گوید با تلاش کم و استفاده از منابع به بهترین شکل ۸۰ درصد آسان را به‌دست بیاورد. پیشهاد وسوسه‌انگیزی است.
متودولوژی P3.express برای پروژه‌های معمولی که افرادی مثل من و شما انجام می‌دهند طراحی شده است. مثل پروژه‌های IT یا ساخت و ساز. این متدولوژی برای پروژه‌های خاص مثل ارسال انسان به ماه کاربرد ندارد. در حالی PMBOK می‌تواند این پروژه‌ها را نیز پشتیبانی کند. پس متودولوژی P3.express هشتاد درصد پروژه‌ها را می‌تواند پشتیبانی کند.

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



PMBOK همراه پروژه‌های ساخت (الحاقیه صنعت ساخت PMBOK)

1395/12/25
14:49
امیرحسین ستوده بیدختی
الحاقیه صنعت ساخت PMBOK
اولین الحاقیه PMBOK در سال ۲۰۰۲ تحت عنوان الحاقیه دولتی، برای تکمیل نسخه‌ی ۲۰۰۰ کتاب برای این نوع پروژه‌های خاص منتشر شد. هدف از انتشار این الحاقیه بیان یک سری مطالب خاص موضوع در کنار PMBOK بود. دومین الحاقیه برای PMBOK، برای صنعت ساخت منشتر شد. در سرتاسر جهان پروژه‌های بسیاری در صنعت ساخت اجرا می‌شود که لزوم وجود یک راهنمای خاص و تکمیلی در کنار مرجع اصلی کاملا احساس می‌شود. موسسه PMI این نیاز را تحت عنوان pmbok construction extension منتشر کرده است.
راهنمای PMBOK یک دانش پذیرفته شده در مورد اکثر پروژه‌ها فارغ از زمان‌ و مکان‌ پروژه می‌باشد. از این جمله می‌توان این اسنتباط را کرد که این دانش به مباحثی می‌پردازد که در تمامی پروژه‌ها و در همه‌ی زمینه‌ها یکسان باشد. پس ما باید شرایط خاص پروژه‌ها در زمینه‌های دیگر را نیز به آن بیافزاییم. الحاقیه صنعت ساخت افزون بر راهنمای اصلی است. یعنی ما در کنار راهنمای اصلی الحاقیه را قرار داده و به پیاده‌سازی آن‌ها در پروژه می‌پردازیم.
pmbok construction extension یک دانش پذیرفته شده در مورد اکثر پروژه‌های صنعت ساخت فارغ از مکان و زمان است. این دیدگاه درست است که بیشتر موارد موجود در استاندارد اصلی در مورد صنعت ساخت صادق است. ولی با پیشترفت جوامع و تکنولوژی نیاز به یک استاندارد ویژه در این بخش ضروری است. این اسناندارد علاوه بر ۱۰ حوزه اصلی در PMBOK ، چهار حوزه را به صورت اختصاصی به مدیریت پروژه‌های صنعت ساخت افزوده است.

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


کتاب الحاقیه ساخت pmbokحوزه دانش مدیریت ایمنی (Safty management)
حوزه دانش مدیریت محیطی (ٍEnvirnmental management)
حوزه دانش مدیریت مالی (Financial management)
حوزه دانش مدیریت ادعا (Claim management)
حوزه دانش مدیریت ایمنی
راهنما در این حوزه به بیان فرآیندهایی پرداخته که با انجام آن‌ها این اطمینان را داشته باشیم که پروژه بدون هیچ حادثه‌ای خاتمه می‌یابد. حادثه می‌تواند منجر به آسیب باشد یا زمینه‌ی آن را فراهم کند.
حوزه دانش مدیریت محیطی
راهنما در این بخش به فرآیندهایی که بتوان با انجام آن‌ها، تاثیرات پروژه بر محیط زیست را کاهش داد پرداخته است.
حوزه دانش مدیریت مالی
در حوزه دانش مدیریت هزینه، صرفا هزینه اجرای پروژه برنامه ریزی و کنترل می شد اما اینجا مباحثی همچون روال دریافتی ها و پرداختیها، بالانس جریان نقدینگی، سودآوری قراردادهای اجرایی پروژه و جذابیت اقتصادی کل طرح سرمایه گذاری نیز مورد مدیریت قرار می گیرد.
حوزه دانش مدیریت ادعا
دعاوی از موارد لاینفک پروژه های اجرایی است. مدیریت حرفه ای آن اثربخشی اجرای پروژه قطعا بالا خواهد برد. این حوزه دانش ارتباط تنگاتنگی با حوزه دانش تدارکات دارد و در خصوص پیشگیری، برنامه ریزی و کنترل و اختتام و به سرانجام رسانی دعاوی قراردادهای پروژه موضوعاتی را مطرح می نماید.
الحاقیه ساخت PMBOK ۲۰۱۶ و کاربرد آن در صنعت
هدف از معرفی الحاقیه ساخت: ارایه نکات کاربردی جهت پیاده‌سازی نظام مدیریت پروژه بر اساس استاندارد PMBOK
مخاطبان: متخصصینی هستند که درگیر در پیاده سازی نظام مدیریت پروژه اند و به دنبال درک عمیق تر مفاهیم مدیریت پروژه و راهکارهای عملیاتی و مفید هستند.
کاربرد مدیریت پروژه در انواع صنایع در جهان
کاربرد پی ام باک در صنایع مختلف از جمله صنعت ساخت Construction industry می باشد. از پروژه‌های مسکونی تا پروژه‌های عمرانی و پروژه‌های صنعتی و نیمه صنعتی، همگی زیرمجموعه این صنعت قرار می‌گیرند.
صنعت ساخت
معرفی الحاقیه ساخت – PMBOK سیر تکاملی
با توجه به اهمیت این صنعت موسسه pmi، در سال ۲۰۰۳ الحاقیه ساخت را انتشار داد، نسخه دوم در سال ۲۰۰۷ و در سال ۲۰۱۶ نسخه سوم را ارائه نمود.
الحاقیه ساخت PMBOK
مخاطبان الحاقیه ساخت PMBOKچه کسانی هستند؟
کارفرمایان (Owners)
مهندسین مشاور (Engineers)
پیمانکاران (Contractors)
مدیران پروژه (Project Managers)
پیمانکاران جز (Sub-Contractors)
نهادهای قانون‌گذار و دولت (Regulatory Agencies and Governments)
گروه‌های فعال در حوزه محیط زیست (Environmental Groups)
فروشندگان و تامین کنندگان کالاها و تجهیزات (Material and Equipment Vendors and Suppliers)
موسسات بیمه، بانکداری و مالی (Insurance, Banking, and Financial Institutions)
و …
محتوای الحاقیه ساخت (PMBOK)
بخش اول: مقدمهالحاقیه ساخت PMBOK 2016
بخش دوم: شرایط محیطی پروژه های ساخت
بخش سوم: مدیریت پروژه در صنعت ساخت: نگاه اجمالی و پیشرفت ها ( ۱۵فصل) ( ساختاری مشابه به ساختار PMBOK، از فصل ۴ به بعد به حوزه‌‌های۱۲ گانه دانش مدیریت ساخت می‌پردازد، ۱۲ حوزه دانش، ۱۰ حوزه مشابه حوزه‌های PMBOK با این تفاوت که حوزه منابع انسانی به حوزه منابع تغییر نام یافته، و ۲ حوزه جدید نیز اضافه شده است: یک حوزه HSSE و حوزه مدیریت مالی پروژه.)
ضمیمه الف (Appendix A1) : مدیریت دعاوی پروژه در صنعت ساخت (در ویرایش‌های گذشته این قسمت جز حوزه‌های دانش بوده که در این ویرایش در قسمت پیوست گنجانده شده است.)
پیوست ۱ (Appendix X1): تغییرات ویرایش جدید نسبت به ویرایش گذشته
پیوست ۲ (Appendix X2): اسامی افرادی که در تدوین این الحاقیه نقش داشته اند
پیوست۳ (Appendix X3): مهمترین علل وقوع ریسک ها در پروژه های ساخت
پیوست ۴ (Appendix X4): مراجع بیشتر
ابعاد توسعه نظام مدیریت پروژه در سازمان
واقعیت این است که تمرکز ما رو فرآیندهای مدیریت پروژه است و بیشتر سعی داریم که این فرآیندها را به دستورالعمل‌های کاربردی تبدیل نماییم و آنها در سازمان پروژه به کار بگیریم. اما این عمل به تنهایی کافی نمی باشد. دو بعد دیگر این نظام، بعد کارکنان و بعد ساختار سازمانی است. رشد این سه بعد به طور همزمان مفید و موثر خواهد بود. نمی‌توان ادعا کرد که ما در سازمان خود فرایندها را تهیه می کنیم و پیاده سازی می‌کنیم در حالیکه کارکنان ما بینش خود را بالا نبرده اند و ساختار سازمانی هم تغییری نکرده باشد و انتظار داشته باشیم که سیستم مدیریت پروژه به درستی کار کند. آنچه که این چرخه به حرکت در می آورد، تعهد مدیریتی می‌باشد.مدیریتی که قاطعانه از این چرخه حمایت کند.توسعه نظام مدیریت پروژه در سازمان
توسعه کارکنان – اثر هاله نور (Halo Effect)
هاله نور
مهندسین و متخصصین پس از چندین سال صرف وقت در حوزه کاری خود و صاحب سبک شدن، بالای سر خویش هاله نوری را می‌بینند!
حال در سازمانی می‌خواهیم نظام مدیریت پروژه را پیاده کنیم، در فضایی که اکثر کارکنان و مهندسان دچار هاله نور هستند.
هاله نور: حالتی که حرف کسی را گوش نمی دهد و به خود اجازه می‌دهد در سایر حوزه‌ها اظهار نظر کند، از جمله حوزه‌های مدیریتی.
Halo Effect: the tendency for an impression created in one area to influence opinion in another area.
اما درمان اش چیست؟ آموزش های کاربردی به کارمندان.
توسعه ساختار سازمانی
توسعه ساختار سازمانی
هدف این است از ساختار وظیفه ای به سمت ساختار پروژه‌ای حرکت کنیم.
اکثر ساختارهای سازمان‌ها در ایران ساختار وظیفه‌ای یا ماتریس ضعیف دارند. خیلی کم پیش آمده که ساختار سازمان ما پروژه‌ای یا ماتریس قوی باشند.
در ساختار وظیفه‌ای، پیاده سازی نظام مدیریت پروژه امکان پذیر نیست. ساختار وظیفه‌ای حالت بخشی دارد و هر کس کار خود را انجام می‌دهد.واحدها با یکدیگر هماهنگ نیستند. هر کسی کار خود را انجام داده و رویکرد بخشی حاکم است. در حالیکه برای پیاده سازی نظام مدیریت پروژه نیازمند رویکرد فرآیندی هستیم. رویکرد فرآیندی، رویکردی افقی است که با ذات ساختار وظیفه‌ای در تعارض و تضاد می‌باشد.
ساختار وظیفه ای (functional)
حداقل ساختار مورد نیاز، ساختار ماتریسی ضعیف است.
در ماتریس ضعیف، مدیران پروژه در سطر قرار گرفته و مدیران وظیفه‌ای یا معاونین در ستون ها هستند . درایه‌ها کارکنان هستند.
در چنین ساختاری، قدرت دست معاونین است. مدیر پروژه در این ساختار، تنها نام مدیرپروژه یدک کشیده و در حقیقت نقش Expediter و یا Coordinator را بازی می‌کند. اما تمایز این سه عنوان در چیست؟
ساختار ماتریسی ضعیف
Manager، مدیر، کسی است که در حوزه کاری خود قدرت و اختیارات کامل را دارا می‌باشد، Coordinator کسی است که در بعضی حوزه‌ها حق امضا و قدرت دارد و در بعضی حوزه‌های دیگر قدرت و اختیار کافی ندارد.
Expediter کسی است که قدرت و اختیار نداشته و فقط یا الله یا الله کننده هستند، در حقیقت کار را در سازمان فقط پیگیری می‌کنند.
پیشنهاد می شود که اگر ساختار سازمان وظیفه‌ای است، به سمت ماتریسی ضعیف حرکت کرده و حداقل سعی شود در این ساختار، Project Coordinator داشته باشیم، در واقع سطح اختیارات مدیران پروژه را مقداری افرایش دهیم.
بنای توسعه فرایندهای مدیریت پروژه در پروژه های ساخت کشور
بنای توسعه فرایند مدیریت پروژه در پروژه های کشور
۱۱ ستون، ۱۱ حوزه دانش.فونداسیون بنا، قرارداد پروژه است. در واقع تمامی این حوزه‌ها در بستر قرارداد واقع می‌باشند.قرارداد پروژه خود نیز بخشی از مدیریت تدارکات پروژه می‌باشد.مدیریت یکپارچگی، مانند سقفی است که همگی این موارد در زیر این سقف اتفاق می‌افتد و مانند چتر در بالا قرار داشته و سایر حوزه‌ها را به یکدیگر می‌دوزد.
مدیریت تدارکات پروژه (Project Procurement MGT.) در PMBOK
برای شروع به کار می‌بایست ابتدا از مدیریت تدارکات و قرارداد شروع کرد.
مدیریت تدارکات پروژه
در مدیریت تدارکات در PMBOK مانند شکل، یک Seller و یک Buyer داریم. Seller کسی است که خدمات، کالا و یا نتایج رو به Buyer ارایه می‌کند. Seller در صنعت ساخت چه کسی است؟
نمونه‌هایی از انواع فروشندگان در پروژه‌های صنعت ساخت کشور
فروشندگان صنعت ساخت
تفاوت vendor و Manufacturers در چیست؟ اولی عامل فروش است و دومی سازنده است. تمامی ارکان بالا، به عنوان Seller در صنعت ساخت شناخته می‌شوند.
مدیریت تدارکاتی که در pmbok است، برای صنعت ساخت ناکافی است. به عنوان مثال، در ویرایش ششم، فرآیند Close Procurement حذف شده است در حالیکه فعالیت های گسترده‌ای در این حوزه در صنعت ساخت اتفاق می‌افتد.
مثال دیگر می‌توان به جایگزین کردن توافق (Agreement) به جای Contract اشاره کرد. در این تعریف توافق هر شکلی است که هدف پروژه را مشخص می‌نماید.می‌تواند شفاهی باشد، ایمیل باشد و یا حتی قرارداد. در حالیکه ما چنین چیزی در صنعت ساخت خود نداریم. در صنعت ساخت بحث جدی Contract یا قرارداد مطرح است و برای توافق جایگاهی وجود ندارد.
Agreements: Any document or communication that defines the initial intentions of a project. This can take the form of a contract, memorandum of understanding (MOU), letters of agreement, verbal agreements, email, etc.
خریداران و فروشندگان چند لایه‌ی سلسله مراتبی
خریداران و فروشندگان جند لایه سلسله مراتبی
در این تصویر، کارفرما کار را به Gc واگذار کرده، Gc کار را داده به پبمانکار جز، پیمانکار جز کار را داده به پیمانکار خرد و به همین ترتیب. تمام اینها ارتباطشان از طریق Contract برقرار می‌شود. آنچه که باعث پیوند می‌شود، قرارداد است. قراردادی که رسمی است.
ماهیت دوگانه‌ای که در عناصر ساخت درگیر هستند. Gc، هم خریدار است و هم فروشنده. در مقابل کارفرما فروشنده و در قبال پیمانکار جز خریدار است و همینطور در ادامه. این ماهیت دوگانه کار طراحی قرارداد را پیچیده می‌نماید.


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

1395/12/25
14: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)

منافع و مزایای مدیریت پروژه در سازمان

1395/12/25
14:40
امیرحسین ستوده بیدختی
منافع و مزایای مدیریت پروژه در سازمان را با چه چیزی بسنجیم؟
مزایای مدیریت پروژه
زمانی که سعی می‌کنیم موفقیت یک سازمان در پیاده سازی مدیریت پروژه و دست‌یابی آن به مزایای مدیریت پروژه را بسنجیم، با یک ضدیت (پارادوکس) رو‌به‌رو می‌شویم.
اندازه‌گیری چه چیزی؟
مزایای مدیریت پروژه
سازمان چگونه می‌تواند پیشرفتی را اندازه گیری نماید درحالیکه یا در گذشته چیزی وجود نداشته که اندازه‌گیری شود یا بسیار ناچیز بوده است؟
این مساله با این واقعیت گره می‌خورد که بسیاری از سازمان‌ها می‌خواهند به سرعت به سمت پیاده‌سازی هجوم ببرند بدون آنکه خط مبنایی (Base line) ایجاد کنند تا موقعیت کنونی‌شان را به‌طور دقیق نشان دهد.

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


خط مبنا

وقت و پول بزارم برای چی؟
بسیاری از سازمان‌ها از اینکه زمان و منابع مالی‌شان را برای اندازه‌گیری جایگاه اولیه هزینه کنند، مردد هستند.
غالبا سازمان‌ها می‌گویند: ” یا علی، بریم تو کار ببینیم چی میشه! فقط زود شروع کنیم.” این عمل چیزی برای اندازه‌گیری ندارد ، فقط حرکتی است به سوی جلو.
از قضا، منافع و سود، تنها دلیلی است که یک پروژه به‌خاطر آن شکل می‌گیرد.
هر که طاووس خواهد جور هندوستان کشد
زمان و هزینه در مدیریت پروژه
سازمان برای اینکه بتواند یک مورد کسب و کار قوی (Solid Business Case) راه‌اندازی کند و طی آن عملکردها و توانایی‌هایش را قبل از اجرا، ارزیابی نماید، ضروری است که برای این کار از وقت خود هزینه نماید.
اگر سازمان بدینگونه عمل کند، (که اکثرا نمی‌کنند!) هنگامی که شروع به پیاده‌سازی می‌نماید، جهت اندازه‌گیری منافع محسوس و نامحسوس تجاری در موقعیت بهتری قرار خواهد گرفت.
برنامه مدیریت پروژه
صرف زمان وتلاش برای این ارزیابی اولیه فرصتی برای برنامه‌ریزی بهتر جهت پیاده‌سازی ارائه می‌دهد.
هرچه ارزیابی دقیق‌تر باشد، چالش‌ها و ریسک‌های واقعی پیش‌روی سازمان به روش بهتری مورد رسیدگی قرار گرفته که منجر به برنامه اجرایی صحیح‌تر همراه جزئیات بیشتر می‌شود.
پس از یک پیاده‌سازی موفقیت‌آمیز، یک سازمان می‌تواند ارزیابی اولیه را به عنوان خط مبنایی برای اندازه‌گیری نتایج به کار گیرد.

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

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

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