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

22.jpg (364×96)11.jpg (364×96)

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

مهندسی نجومی

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) پرینس۲.

 

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

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



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

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