پشتیبانی از رهبران نامرئی که در بخش پیش مطرح شد مبحث مهمی در حوزه رهبریست، ولی از آن گذشته، باید بر رشد تواناییهای رهبری خودتان نیز تمرکز کنید.
برای نمونه، بهعنوان یک رهبر، باید بتوانید در افراد انگیزه ایجاد کنید. فرض کنید یکی از اعضای تیم کار درخشانی در پروژه انجام داده است و میخواهید از او قدردانی کنید. چگونه این کار را خواهید کرد؟ با پرداخت پاداش مالی؟
پاسخ بستگی به مسایل فراوانی دارد. پاداش مالی هنگامی کارآمد است که مقدارش نسبت به نیاز مالی فرد مناسب باشد، وگرنه اثر معکوس خواهد داشت، زیرا کم بودن پاداش به معنی دستکم گرفتن کار فرد به شمار خواهد رفت. فرض کنید بودجه بسیار محدودی دارید و فقط میتوانید معادل چهار پیتزا برای قدردانی از آن فرد هزینه کنید. پرداخت چنین پاداشی شایسته نیست، ولی با همان بودجه میتوانید خودکاری برازنده سفارش دهید که نام آن فرد رویش حک شده باشد، آن را هدیه دهید و با چند جمله زیبا قدردانی خود را نشان دهید.
سوتفاهمهای فراوانی درباره مفهوم رهبری وجود دارد. برای نمونه، داشتن کاریزما برای رهبران سودمند است، ولی کاریزما محدود به داشتن شخصیتی سرسخت، پرابهت و گاهی بداخلاق نیست. شکلهای مختلفی از کاریزما وجود دارد و برخی از آنها وابسته به دانش، مهربانی، دلسوزی و هماهنند آنها هستند. بهتر است به جای الگوبرداری از شخصیتهای کاریزماتیک فیلمها، نوع کاریزمای مناسب …
چابکی رویکردی در ساخت محصول است. برخی از متدولوژیها فقط برای ساخت چابک طراحی شدهاند، برخی هم برای ساخت چابک و هم متعین، و برخی نیز بیشتر مناسب ساخت محصول متعین هستند.
بیشتر روشهای چابک نسل نخست، مانند DSDM و XP، نقشی بهعنوان مدیر پروژه دارند یا دستکم مخالفتی با چنین نقشی ندارند. با اینهمه، اسکرام چنین نقشی ندارد و افزودنش به اسکرام نیز سازگاری درونی آن را نابود میکند. این مسئله اهمیت فراوانی دارد، زیرا برخی گمان میکنند که با افزودن مدیر پروژه به اسکرام آن را تقویت کردهاند، با اینکه آن را ضعیفتر کردهاند.
از سوی دیگر، به دلیل گستردگی فراوان اسکرام و این واقعیت که بسیاری از روشهای چابک نسل دوم از اسکرام الگوبرداری کردند، برخی میپندارند که وجود مدیر پروژه با ذات چابکی ناسازگار است، که کاملا اشتباهست. بسیاری از روشهای چابک نیاز به مدیر پروژه دارند.
مدیر پروژه واقعی رئیس نیست! هر چه باشد، بیشتر سازمانها کمبود رئیس ندارند. آنچه بهعنوان مدیر پروژه نیاز داریم، کسانی هستند که بتوانند از تیم پروژه پشتیبانی کنند و با تسهیلگری و گرهگشایی زمینهای فراهم کنند که اعضای تیم پروژه بتوانند کارهای تخصصی خود را به بهترین شکل انجام دهند.
هر برچسبی بار معنایی ویژه خود را دارد که در طی سالها بر پایه تجربهها و رویدادهای فراوان شکل گرفته است. اگر گمان میکنید برچسب «مدیر پروژه» بار معنایی مناسبی در سازمانتان ندارد، میتوانید بهجای آن از برچسب دیگری استفاده کنید. پیشنهاد همیشگی من برای جانشینی این برچسب، «تسهیلگر ارشد پروژه» است. بهرهمندی از چنین برچسبی دایما مفهوم واقعی مدیر پروژه را به او و دیگران یادآوری میکند. البته به یاد داشته باشید که این پیشنهاد من بیشتر برای شرکتهای نرمافزاریست که تصویر ناپسندی از مدیر پروژه دارند، وگرنه مفهوم مدیر پروژه در سایر پروژهها، بهویژه در ایران، بار معنایی منفی ندارد (دستکم تا جایی که من اطلاع دارم) و بنابراین نیازی به این راهکار نخواهند داشت.
همیشه باید به شکل مناسب تفویض اختیار کنید، وگرنه هم حجم کارتان بیدلیل بالا میرود و هم مشارکت اعضای تیم و درنتیجه احتمال موفقیت کاهش مییابد.
در پرینس۲ برای هر سطح مدیریتی مجموعهای از حدود تصمیمگیری بر پایه زمان، هزینه، گستره، کیفیت، ریسک و منافع ناشی از تصمیم لحاظ میشود. پس از آن، اگر اثر تصمیم کمتر از آن حد باشد، فرد پاییندست مسئول تصمیمگیری خواهد بود، وگرنه باید مسئله را بهعنوان موردی ویژه (exception) به فرد بالادست ارجاع داد.
معمولا نمیتوان پروژههای طولانی را از آغاز بهتفصیل برنامهریزی کرد، زیرا برخی جزئیات را فقط زمانی میتوان دانست که به آنها نزدیک شده باشیم. از این رو، روند معمول برنامهریزی در پرینس۲ این است که در آغاز پروژه برنامهای کلان و پیش از آغاز هر دوره برنامهای تفصیلی برای آن دوره آماده شود.
برخلاف آنچه برخی میپندارند، این شیوه برنامهریزی بسیار رایج و فراگیر است. برنامهریزی در P3.express نیز به همین ترتیب است. P3.express چرخههای ثابت ماهانه دارد، ولی مدت زمان دورههای پرینس۲ متغیرند.
در بخش پیشین، دوگانگی تغییر و نتیجه را بررسی کردیم: آنچه واقعا انتظار داریم نتیجه است و نه تغییر. بیشتر منابعی که درباره تغییر سخن میگویند درواقع منظورشان نتیجه تغییر است و نه خود تغییر. متاسفانه پمباک هم مستثنا نیست. موضوع واقعی این اصل نتایج تغییر است و نه خود تغییر.
آنچه در پروژه ساخته میشود محصول یا خروجی آن است. خروجی پروژه پتانسیلی برای ایجاد نتایج دارد، ولی تحقق نتایج معمولا به مسایل فراوانی، گاهی بیرون محدوده پروژه، وابسته است (برای نمونه، آموزش مناسب برای استفاده از سیستمی که در پروژه ساخته شده است). برای تحقق نتایج معمولا باید بیشتر از یک پروژه انجام داد و بیشتر از یک خروجی ایجاد کرد. در بسیاری از موارد، یکی از پروژهها بهمراتب بزرگتر از پروژههای دیگر است، در حدی که پروژههای دیگر در سایه آن پروژه اصلی گم میشوند و خیلی اوقات غیررسمی و بدون پروژه نامیده شدن انجام میشوند. از آنجایی که دستیابی به نتایج وابسته به انجام چند پروژه است، تحقق نتایج نیز موضوع اصلی مدیریت طرح است و نه مدیریت پروژه.
پیش از این مبحث دیگری درباره توجیهپذیری پروژه داشتیم و اینکه ارزیابی و مدیریت ارزش، منافع و توجیهپذیری پروژهها را باید در سطح مدیریت پرتفولیو انجام داد و مدیریت پروژه برای این کار کافی نیست را بررسی کردیم. سیستم مدیریت پروژه باید در این فرآیند با سیستم مدیریت پرتفولیو همکاری …
دلیل از طرح مسایل و پیچیدگیهای بخش پیش این بود که مشخص شود بررسی ارزش، منافع و توجیهپذیری پروژه را نمیتوان تماما درون مرزهای پروژه انجام داد. این کار باید در سطح مدیریت پرتفولیو انجام شود. این سطح مسئول انتخاب و اولیتدهی پروژههاست و اعضای آن معمولا از مدیران ارشد و سهامداران سازمان هستند.
با اینهمه، چرا در پمباک و سایر منابع مدیریت پروژه چنین مسایلی را بررسی میکنیم؟ دلیلش این است که با اینکه ارزیابیها و تصمیمگیریهای اصلی باید در لایههای بالاتر سازمان انجام شوند، وابسته به اطلاعاتی هستند که از سوی پروژهها فرستاده میشوند و مدیر پروژه باید بتواند با ارائه اطلاعات مناسب به مدیریت پرتفولیو کمک کند. از سوی دیگر، همه افراد دستاندرکار پروژه باید با این موارد آشنا باشند و خود را با آن همسو کنند.