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

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

Delegation and Escalation

-
-
امیرحسین ستوده بیدختی

No one likes being micromanaged. When you do so, and when you fail to delegate, you will face multiple problems, including:

  • You won’t have enough time for more important things
  • You’re not using the potentials in your team
  • You’ll miss the buy-in of team members

We should delegate. However, there are also some problems with delegation. Most notably, sometimes important decisions are made in lower levels of hierarchy, where people do not have the required high-level understanding.

The fifth core principle is Manage by Exception.

It provides you with a structured system of delegation and escalation. We recognize the project targets (time, cost, scope, quality, etc.) and define tolerances for each level. For example, we say that the team leader is responsible for making decisions that do not have monetary consequences larger than €10,000. Then, if the monetary consequence is lower than that, we expect the higher manager to let the team leader handle it, and when it’s higher, we expect the team leader to escalate it to the higher level.

That’s it for the fifth principle. Let’s move on to the next one… for tomorrow of course. My question this time is: what should be your focus, the work, or the product? What’s the consequence of each approach?


چگونه اثربخشی برنامه ریزی و کنترل را در پروژه تضمین کنیم؟

-
-
امیرحسین ستوده بیدختی

چگونه اثربخشی برنامه ریزی و کنترل را در پروژه تضمین کنیم؟
این صحنه را تصور کنید؛ در جلسه هفتگی همراه با دیگر دست اندرکاران پروژه مشغول ارزیابی عملکرد سازمان های مختلف هستید. شما به عنوان برنامه ریز و کنترل کننده همان برنامه، مغایرتها را به دیگران تذکر می دهید: "شما قرار بوده این فونداسیون را دو روزه تمام کنید ولی اینک یک هفته می گذرد و همچنان ناتمام مانده است!"
پاسخ می آید:"معلوم است که این مدت باید طول بکشد. بچینگ به دلیل خرابی یک قطعه سه روز است که از کار افتاده و به هر دری می زنیم نمی توانیم قطعه یدکی را پیدا کنیم. اگر می توانید در این زمینه به ما کمک کنید."
شما در جواب ادامه می دهید:" آخر این هم شد دلیل؟ خوب تا بچینگ راه بیفتد می رفتید از سایت همسایه مقداری بتن قرض می کردید، بعد برمی گرداندید. آقا مثل اینکه شما این کاره نیستید! این که مشکل حساسی نیست."
پیمانکار می گوید:"اصلاً سیمان در منطقه نایاب شده، چون نزدیکترین کارخانه سیمان به علت تعمیرات اساسی، کوره خود را خاموش کرده و اگر بخواهیم از جای دیگر سیمان تهیه کنیم دو برابر قیمت را باید پرداخت کنیم. این مشکل فقط با دخالت کارفرما حل می شود."
بحث بالا می گیرد و هر یک از طرفین به ابراز نظر ادامه می دهند. نهایتاً شما که برنامه ریز هستید می پرسید:"بالأخره کی کار را تمام می کنید؟"
پاسخ می آید:"اگر امکانات اجازه دهد تا اول هفته آینده."
شما در پایان می گویید: "دفعه بعد نیایید و همین موضوعات را به ما تحویل دهید. آقا این پروژه را مدیریت کنید."
در سناریوی بالا چه اتفاقی افتاد؟ کار ساخت یک فونداسیون به تعویق افتاد و موضوعات متعدد بدون تعیین عواقب معلق ماندند. اشکال کار کجاست؟ اشکال اصلی این کار در این است که برنامه ریز به وظایف عملیات خود آشنا نیست. برنامه ریز برای اینکه به پیمانکار اثبات کند حداقل به اندازه وی به دانش ساخت فونداسیون آشناست به جای اینکه دغدغه برنامه را داشته باشد به بحث راجع به مسائل فنی می پردازد. شاید به این طریق می خواهد پیمانکار را از زدن انگ اینکه "برنامه ریز با امور پروژه آشنا نیست" بازدارد. اما این، کار برنامه ریز و کنترل کننده همان برنامه نیست. بسیار خوب، پس از عارضه یابی بهتر است بگوییم که کار برنامه ریز چیست.
برنامه ریز و کنترل کننده پروژه باید کارهای زیر را انجام دهد:
برنامه ریزی پروژه
پایش پروژه به صورت دوره ای در سطوح متناظر برنامه
کنترل پروژه به صورت دوره ای در سطوح متناظر برنامه
محاسبه اثربخشی اجرای برنامه بر پروژه
تعیین عواقب اجرای کار بر برنامه
همانگونه که مشاهده می نمایید برنامه ریز پروژه، اولین مدافع و نگاه دارنده برنامه در پروژه محسوب می شود. برای مباحث فنی و مهندسی، ناظرین حضور دارند. اما قبل از نتیجه گیری، یک موضوع دیگر را نیز باید به این بحث اضافه کنیم و آن، فلسفه تسهیم ریسک برنامه است. توجه کنید که هر برنامه ای با ریسک مواجه است. یعنی اینکه با احتمالی آنچه پیش بینی شده است، اتفاق نمی افتد. این ماهیت برنامه است، در غیر این صورت برنامه ریزی به جای پیش بینی به پیشگویی می پرداخت.
اما ریسک را چگونه مدیریت کنیم؟ قدم اول این است که روش تسهیم ریسک را تعریف کنیم. مثلاً می توانیم فعالیت های مربوط به یک برنامه را به قدری دقیق تعریف کنیم که هر فعالیت دارای یک مجری باشد. در آن صورت توافق می کنیم که چنانچه به هر دلیل مجری نتواند فعالیت را در زمان مقرر انجام دهد، به میزان معینی خسارت بپردازد. این مجری می تواند در بدنه کارفرما باشد یا پیمانکار یا مشاور یا مدیریت. نحوه تسهیم ریسک برنامه در قرارداد پروژه باید ذکر گردد تا برنامه پروژه دارای تضمین اجرایی باشد. با توجه به این موضوع و قدم هایی که در بالا به آنها اشاره شد، سناریوی اول این نوشتار به این صورت بازنویسی می گردد:
برنامه ریز: "قرار بوده که امروز ساخت فونداسیون به اتمام برسد ولی هنوز تمام نشده است. این را مدارک ما و ناظرین پروژه شهادت می دهند (قدم 1)."
پیمانکار: "درست است ولی بچینگ ما سه روز است که خراب است."
برنامه ریز: "بسیار خوب، شما 3 روز در اجرای این فعالیت تأخیر دارید (قدم 2). این عقب ماندگی پیشرفت پروژه را در این دوره 2/0 درصد کاهش خواهد داد (قدم 3). این 2/0 درصد به واحد امور قراردادها عرضه خواهد شد تا در صورتحساب شما برای این دوره منظور گردد (قدم 4). باید زمان جدید در برنامه دوره آینده منظور شود (قدم 5)."
همانگونه که مشاهده می کنید تمامی صحبت ها در زمان کنترل برنامه در سناریوی دوم در مورد برنامه است نه در مورد ساخت فونداسیون، آنگونه که در سناریوی اول به آن پرداخته شده است.

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

چگونه اثربخشی برنامه ریزی و کنترل را در پروژه تضمین کنیم؟


چابکی در پروژه - واژه‌ها و معانی‌شون

-
-
امیرحسین ستوده بیدختی

اولین قدممون اینه که با چنتا واژه کلیدی آشنا بشیم. اولین قاعدتا اینه: Agile
«اجایل» تو انگلیسی صفته و به دو معنی به کار می‌ره:

  1. سریع و ساده حرکت کردن
  2. سریع و هوشمندانه فکر کردن

اگه دوست دارین می‌تونین معنیش رو تو دیکشنری محبوب من، Oxford Advanced Learner’s چک کنین: http://www.oxfordlearnersdictionaries.com/definition/english/agile?q=agile
مثلا The turtle was nothing compared to the agile rabbit: لاکپشت در مقابل خرگوش چابک هیچی نبود.
یا With your agile mind, solving the puzzle is a piece of cake: با سرعت و توانایی استدلالی تو، حل کردن این معما مثل آب خوردنه.

تو فارسی «اجایل» رو به «چابک» ترجمه می‌کنیم، که به نظرم خیلی هم ترجمه قشنگیه، چون نوعی ظرافت و هوشمندی رو هم در کنار سرعت می‌رسونه. علاوه بر اون، «چابک» کمتر از «سریع» استفاده می‌شه و در نتیجه برای نام‌گذاری یه مفهوم خاص مناسب‌تره.

یه عبارت دیگه هم که کمابیش استفاده می‌شه و خصوصا من خیلی بهش علاقه دارم Agility هست، به معنی «چابکی». فرقش اینه که این عبارت اسمه و نه صفت، در نتیجه تو خیلی از جمله‌ها بهتر و قشنگ‌تر قرار می‌گیره. ولی فرق دیگه‌ای ندارن، فقط بستگی داره آدم بخواد تو چه نوع جمله‌ای ازشون استفاده کنه.

این دو واژه Agile (چابک) و Agility (چابکی) تو سال‌های اخیر هم به عنوان صفت و اسم به کار می‌رن و هم برای اشاره کردن یه مفهومی تو اجرای پروژه. قاعدتا از اینجا به بعد دیگه کاری به کاربرد اولشون نخواهیم داشت ;) البته یه چیزی هم که خوبه بدونین اینه که از این دو واژه تو گفتار روزمره و خارج مفهوم پروژه‌ایشون چندان استفاده نمی‌شه.


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


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

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