پروفایل برنامه‌ریزی و کنترل پروژه
نادر خرمی راد

توجیه‌پذیری

همه راهنماها و متدولوژی‌های مدیریت پروژه بر اهمیت درک چرایی پروژه‌ها پافشاری می‌کنند، ولی آن را به شکل یکسانی در سیستم‌ خود بازتاب نمی‌دهند. راه متداول این است که بر توجیه‌پذیری پروژه تمرکز کنیم که یکی از اصل‌های پرینس۲ هم هست. توجیه‌پذیری پروژه معمولا در سندی با نام انگیزه تجاری (business case) ثبت می‌شود. این سند باید دایما بر پایه تازه‌ترین پیش‌بینی‌های زمان و هزینه و دیگر متغیرهای پروژه بازبینی و سپس برای مدیران ارشد فرستاده شود تا درباره توجیه‌پذیری پروژه تصمیم بگیرند.

توجیه‌پذیری دایمی پروژه

فقط پروژه‌هایی که توجیه‌پذیر باشند را باید آغاز کرد. با این‌همه، توجیه‌پذیر بودن در آغاز پروژه کافی نیست، زیرا گاهی با شناخت بهتر پروژه می‌توان برداشت واقع‌بینانه‌تری از بازگشت سرمایه آن به دست آورد و گاهی هم به دلیل تغییر شرایط بیرونی پروژه توجیه‌پذیری‌اش تغییر می‌کند. از این رو، باید دایما توجیه‌پذیری پروژه را بازنگری کرده، بسته به نیاز پروژه را متوقف کرد.

بسیاری از پروژه‌های در حال انجامی که توجیه‌پذیری خود را از دست می‌دهند به دو دلیل متوقف نمی‌شوند:

  1. سیستم مدیریت پروژه مناسبی ندارند که متوجه تغییر توجیه‌پذیری بشود. از این‌رو، می‌گوییم که متوقف کردن پروژه‌های نیمه‌کاره نشانه‌ای از مدیریت پروژه و مدیریت پرتفولیوی قویست.
  2. گاهی سازمان‌ها متوجه از بین رفتن توجیه‌پذیری می‌شوند، ولی به دلیل هزینه و کوششی که تا آن زمان صرف پروژه شده است ترجیح می‌دهند کار را ادامه دهند که در عمل باعث تباهی کوشش و پول بیشتر می‌شود. این ضعف ناشی از فریبی ذهنی به نام sunk cost effect است.

باید توجیه‌پذیری هر پروژه‌ای را دوره‌ای کنترل کرد. این کار هم به یافتن پروژه‌هایی که توجیه‌پذیریشان را از دست داده‌اند کمک می‌کند و هم به همگان دایما هدف پروژه و لزوم هم‌راستا شدن با آن را یادآوری می‌کند.

تیم‌سازی نامحسوس

به فعالیت‌هایی که وضعیت تیم را بهبود می‌دهند «تیم‌سازی» (team building) گفته می‌شود. برخی سازمان‌ها فعالیت‌هایی ویژه این کار ترتیب می‌دهند. این فعالیت‌ها معمولا با کمک مربی‌هایی انجام می‌شود که در تیم‌سازی خبره هستند. برای نمونه، همه افراد تیم به یک بازی دست جمعی یا برنامه‌ای آموزشی مانند آشپزی دعوت ‌می‌شوند و تیم‌سازی در خلال این کار انجام شود.

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

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

امتیاز اصلی ترکیب تیم‌سازی با فعالیت‌های معمول این است که آهسته و پیوسته انجام می‌شود.

حامی پروژه

برخی مدیر پروژه را بالاترین نقش پروژه می‌دانند، ولی بیشتر متدولوژی‌ها نقش دیگری بالاتر از مدیر پروژه دارند؛ مدیری ارشد که می‌تواند

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

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

نقشی که در راس پروژه قرار می‌گیرد، در بسیاری از منابع، ازجمله P3.express، حامی پروژه (sponsor)، در پرینس۲ مدیر ارشد (executive) و در DSDM حامی کسب و کار (business sponsor) نامیده می‌شود.

حقیقت و نتایج را بر تعصب‌ها و وابستگی‌های شخصی ترجیح دهید

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

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

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

دانلود کل مطالب سایت

در این بخش می‌تونین نسخه کاملی از تمام مطالب سایت رو دانلود کنین. البته در نظر داشته باشین که مطالب سایت سالی یک بار بررسی می‌شن و مواردی که صرفا ارزش مقطعی داشته باشن (مثلا آگهی‌های استخدام) حذف می‌شن. بعد از هر بار رسیدگی حدودا ۲۵٪ مطالب سایت باقی می‌مونن و در این بخش همون موارد قابل دانلود هستن.

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

دانلود نسخه PDF

درک مسایل فنی

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

آیا به نظرتان مدیر پروژه باید اطلاعات فنی داشته باشد؟

سه پاسخ برای این پرسش ممکن است:

  1. بله، مدیر پروژه باید اطلاعات فنی داشته باشد.
  2. الزامی نیست که مدیر پروژه اطلاعات فنی داشته باشد، ولی اگر داشته باشد شاید بهتر باشد.
  3. خیر، بهتر است که مدیر پروژه اطلاعات فنی نداشته باشد.

نخستین پاسخ رویکردی سنتیست که چه‌بسا در بسیاری از سازمان‌ها دیده باشید. این رویکرد محدود به ایران هم نیست و در همه کشورها وجود دارد.

رویکرد دوم کمابیش نوین و بااین‌همه کمی محافظه‌کارانه است. این رویکرد با آنچه تاکنون گفته شد هماهنگ است و می‌توان گفت که PMI هم چنین دیدگاهی دارد.

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

فرض کنید مدیر پروژه‌ای هستید که در جنبه‌های فنی‌اش نیز تخصص دارید. اگر ببینید که کاری …