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


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

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

1395/12/12
18: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ها رو تولید می‌کنه. ولی به هر حال زمان و هزینه و کیفیت ثابته.

 

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

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

 

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

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

 

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

 

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

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

 

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

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

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

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




منادله!!!

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

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


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

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

فراخوان هفتمین دور جایزه ملّی مدیریت پروژۀ ایران

1395/11/7
19:25
امیرحسین ستوده بیدختی امیرحسین ستوده بیدختی
 پیرو برگزاری موفقیت آمیز شش دوره از جایزه ملّی مدیریت پروژه و استقبال شرکت های پروژه محور کشور از این جایزه، انجمن مدیریت پروژۀ ایران برگزاری هفتمین دورۀ این جایزه ملّی را در دستور کار قرار داده و ثبت نام پروژه های داوطلب از نیمه دیماه 1395 آغاز شده است.

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


رئیس کمیتۀ جایزه ملی مدیریت پروژه، با اعلام این خبر از کلیۀ شرکتهای پروژه محور کشور دعوت نمود تا با معرفی پروژه های برتر خود، در این رقابت ملّی شرکت نمایند.
http://file.mihanblog.com//public/user_data/user_files/626/1877697/awardbanner.jpg
پروژه هایی که تا 30 بهمن ماه ثبت نام قطعی خود را انجام دهند از 10% تخفیف برخوردار خواهند شد. برنامه زمانبندی و فرم ثبت نام دور هفتم را از اینجا  دریافت نمایید. همچنین علاقه مندان می توانند جهت کسب اطلاعات بیشتر به آدرس اینترنتی www.award.ipma.ir مراجعه و یا با شماره های 88229370 و 88229406 تماس حاصل فرمایند.



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

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