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


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

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

 

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

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

 

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

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

 

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

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

 

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

 

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

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

 

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

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

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