به لطف این واقعیت که ایرانی‌ها روز به روز بیشتر دارن به کشورهای مختلف مهاجرت می‌کنن، این هم داره به یه سوال رایج تبدیل می‌شه که من فلان کشور زندگی می‌کنم، کدوم گواهی رو بگیرم برای آینده شغلیم بهتره.
الان می‌خوام به جای جواب معمولی، یه مقدار «ماهی‌گیری» رو تو این ماجرا توضیح بدم.
قدم اول: پیدا کردن اون چیزایی که مهمه
اولین قدم اینه که این دو کار رو بکنین:
تو سایت‌های مختلف آگهی‌های استخدام مرتبط با شغلتون که برای اون کشور هست رو پیدا کنین و ببینین چه قابلیت‌ها و مهارت‌ها و گواهی‌هایی انتظار دارن.
برین تو لینکدین آدم‌هایی که تو اون کشور تو حوزه کاری شما فعال هستن رو پیدا کنین و ببینین که چه قابلیت‌ها و مهارت‌ها و گواهی‌هایی دارن.
یه لیست از این موارد بسازین.
قدم دوم: اولویت‌بندی لیست
حالا بر اساس بسامد اون موارد تو آگهی‌ها و پروفایل‌ها و همینطور سادگی یا مشکل بودن به دست آوردن اون مهارت یا گواهی، رده‌بندی‌شون کنین. برای این‌که مثلا بدونین گرفتن هر گواهی چقدر مشکله هم قاعدتا باید تو اینترنت جستجو کنین. چون فرض بر اینه که ایران زندگی نمی‌کنین خوشبختانه کار کردن بدون مشقت با اینترنت امکان‌پذیر خواهد بود.
وقتی لیست رو اولویت‌بندی می‌کنین رتبه‌ها رو از ۳ شروع کنین. رتبه ۱ همیشه تسلط به زبان و رتبه ۲ آشنایی با فرهنگ کشور مقصده.
تا حالا یادداشت‌های زیادی در مورد پیشرفت اینجا بوده. مثلا توصیه همیشگی من که هیچوقت کاری رو دو بار یه جور انجام ندین. هر وقت کاری روتین مثل تهیه گزارش باید انجام بدین به این فکر کنین که چطوری می‌شه یه کم روش کار رو بهتر از دفعه قبل کرد.
یه نکته دیگه که از زاویه دیگه‌ای می‌تونه به پیشرفت کمک کنه اینه که هروقت کسی ازتون می‌خواد کاری رو انجام بدین، یه قدم اضافه بر اون چیزی که ازتون خواسته شده هم بردارین. مثلا اگه ازتون خواستن گزارش خاصی تهیه کنین با محتوای مشخص، می‌شه در کنارش یه گزارش تک صفحه‌ای خلاصه هم براش تهیه کنین تا برای مخاطب‌های خاص مفید باشه. یا در کنار تحلیل‌هایی که ازتون خواستن انجام بدین یه تحلیل اضافه هم که به نظرتون برای هدفشون مناسبه انجام بدین و نتیجه رو اعلام کنین.
وقتی می‌خواین این کار رو بکنین حتما دو نکته رو در نظر داشته باشین:
اون محصول اضافه نباید تداخلی با محصول اصلی داشته باشه. یعنی محصول اصلی به همون شکلی که انتظار داشتن باید تهیه شده باشه و یه محصول مرتبط جانبی کنارش قرار بگیره. در هر حال ممکنه اون محصول جانبی بر خلاف انتظار شما همسو با نیازها و انتظارهاشون نباشه.
وقت خیلی زیادی نباید صرف محصول جانبی بکنین، چون به هر حال وقت و انرژی شما برای مجموعه مهمه و ترجیح می‌ده تو مسیری که تشخیص می‌دن برای پروژه مناسبه بره و ممکنه ایده شما همیشه همسو نباشه. پیشنهاد من …
مدتیه که انرژی زیادی روی مبحث اشتباه‌های تصمیم‌گیری و اثری که روی مدیریت پروژه می‌ذارن گذاشتم که هم موضوع بعضی دوره‌های آموزشیم برای مدیران رده بالای شرکت‌ها بوده و هم سخنرانی تو کنفرانس‌های PMI. بحث خیلی جالبیه که اثرش هم اصلا محدود به مدیریت پروژه نیست و به شکلی خیلی موثر و جدی کل زندگیمون رو تحت تاثیر می‌ذاره. کلا هم مطالعه در مورد این مبحث رو شدیدا به همه توصیه می‌کنم، هم برای بهتر شدن تو مدیریت پروژه و هم برای داشتن زندگی بهتر.
یکی از اشتباه‌ها، توهم کنترله. آزمایش کلاسیکش اینه که عده‌ای رو تک تک می‌برن تو یه اتاق و یه سری سیم بهشون وصل می‌کنن و توضیح می‌دن که هدف آزمایش اینه که آستانه تحمل آدم‌ها در برابر شوک الکتریکی اندازه‌گیری بشه. به آدم‌ها می‌گن که شوک رو از مقدار خیلی کم شروع می‌کنن و به تدریج بالا می‌برن و طرف هروقت که دید دیگه نمی‌تونه تحمل کنه اعلام کنه که بلافاصله آزمایش قطع بشه.
آدم‌ها تو این آزمایش دو دسته می‌شن، به یه گروهشون می‌گن که هروقت نمی‌تونستی تحمل کنی برای ما دست تکون بده تا بلافاصله آزمایش رو قطع کنیم. برای گروه دوم اوضاع متفاوته. جلوی دست این آدم‌ها یه دکمه قرمز بزرگ هست و بهشون می‌گن هروقت نمی‌تونستی تحمل کنی این دکمه رو فشار بده تا آزمایش بلافاصله قطع بشه.
استاندارد پرینس۲ نقش‌ها و مسئولیت‌ها رو خیلی دقیق تعریف می‌کنه، چون یه متودولوژیه. نقش‌هایی که تعریف کرده رو هم با رعایت شرایطی می‌شه تغییر داد. مثلا می‌شه بعضی‌هاشون رو شکست به چنتا، یا برعکس، چنتاشون رو با هم ترکیب کرد. مثلا دو نقش مدیر پروژه و مدیر تیم اجرایی رو می‌شه با هم ترکیب کرد؛ اگه پروژه کوچیک و ساده باشه. با این حال بعضی‌ها رو نمی‌شه با هم ترکیب کرد، مثلا مدیر ارشد (حامی) و مدیر پروژه.
تو حالت کلی کمترین تعداد افرادی که می‌تونیم تو تیم مدیریت پروژه‌مون داشته باشیم دوتاس، مدیر پروژه و مدیر ارشد. بقیه رو می‌شه کامل با این دوتا ترکیب کرد. حالا سوال خیلی‌ها اینه که چرا نمی‌شه این دوتا رو با هم ترکیب کرد. مثلا اگه پروژه خیلی خیلی ساده و کوچیک باشه، چه دلیلی داره که دو نفر مسئولیت مدیریتی براش داشته باشن؟
جواب همیشگی من اینه: مسئولیت مدیر ارشد جنبه‌های کلان پروژه و مسئولیت مدیر پروژه مسایل جزئی‌تر و نسبتا روزمره‌س. طبیعت آدم اینه که اگه دو نوع مسئولیت متفاوت به این شکل داشته باشه، ناخودآگاه اونی که انتزاعی‌تر و کلان‌تره رو فراموش می‌کنه و فقط متمرکز می‌شه روی مسایل روزمره. به همین خاطر اگه پروژه کوچیک باشه و این دو نفر رو تبدیل کنیم به یه نفر، به اندازه کافی به جنبه‌های کلان پروژه توجه نمی‌شه و از این بابت دچار مشکل می‌شیم.
یه آزمایش خیلی سال پیش‌ها انجام شده بود که الان خیلی …
به این سوال راحت نمی‌شه جواب داد، چون PMO تعریف مشخصی نداره. معمولا کسایی که چنین سوالی می‌پرسن قصد دارن سیستم‌های مدیریتی مربوط به پروژه رو بهبود بدن و به همین خاطر هم به این سوال که کامل‌تره جواب می‌دم.
روند کلی کار اینه که اول باید وضعیت فعلی رو ارزیابی کنیم. برای این کار باید با افراد کلیدی شرکت مصاحبه کرد، اسناد رو بررسی کرد، حتی اگه امکانش باشه با ذی‌نفعان خارجی مصاحبه کرد و امثال اون. از مدل‌های بلوغ مدیریت پروژه یا مدل‌های سلامت مدیریت پروژه هم می‌شه برای این کار کمک گرفت. قطعا اگه کسی از نیروهای داخلی شرکت این مسئولیت رو به عهده داشته باشه خیلی کار سریع‌تر می‌شه، ولی نباید میانبر زد. از طرف دیگه، معمولا مشاورهای خارج شرکت بهتر می‌تونن تو این زمینه کمک کنن، چون از یه طرف با دید باز و بی‌طرفانه وارد شرکت می‌شن و از طرف دیگه، تجربه بیشتری می‌تونن تو این ماجرا داشته باشن؛ هرچی باشه کسی که تو یه شرکت کار می‌کنه مشغول مسئولیت‌های مدیریتیه، نه طرح‌های بهبود سیستم‌های مدیریتی. در هر حال، من معمولا وقتی چنین مسئولیتی دارم بین یک تا سه ماه زمان صرف گردآوری اطلاعات می‌کنم، که به نظر شرکت‌ها زیاد میاد، ولی کاملا لازمه. نباید سریع نتیجه‌گیری کرد. اگه کسی خیلی سریع بعد از چند هفته شروع به «طراحی» و پیاده‌سازی کنه مسلما داره یه نسخه بی‌ربط می‌پیچه.
خیلی وقت‌ها از من درباره روش مناسب کار کردن سوال می‌شه و برای همین تصمیم گرفتم این مطلب رو بنویسم. این یه راهنمایی کلی نیست، چون من تو این ماجرا متخصص نیستم؛ فقط قصد دارم جنبه‌هایی که در مورد خودم برقراره و در طی سال‌ها بهش رسیدم رو براتون تعریف کنم.
وقتی آدم تو کار موفقه که ازش لذت ببره. به این فکر کنین که صبح‌ها که از خواب بلند می‌شین (خصوصا شنبه‌ها) با خودتون دارین فکر می‌کنین که «وای، بازم باید برم سر کار»، یا برعکس، یه حسی درونتون هست که می‌خواین هرچه سریع‌تر برین سراغ کار؟ معمولا آدم‌های موفق از گروه دوم هستن. این هم چیزی نیست که با تغییر رویکرد آدم به کار شکل بگیره، معمولا باید نوع کار رو طوری عوض کرد که خود به خود چنین حسی به وجود بیاد.
چیزهایی که کار رو برای من لذت‌بخش می‌کنن و اگه نباشن هم موفق نخواهم بود و هم زندگی برام جالب نمی‌شه این‌ها هستن:
دست‌آورد: من باید به ازای هر کاری که می‌کنم دست‌آوردی داشته باشم. چیزی که واقعا با ارزش باشه و رسما بشه اون رو محقق شده دونست. وجود چنین چیزی به من انرژی می‌ده که کارم رو خوب انجام بدم و براش انرژی بذارم. اگه یه مدتی مجبور باشم روی چیزهایی کار کنم که دست‌آورد خاصی ندارن، به شدت از نظر کاری افسرده می‌شم و بازده‌ام افت می‌کنه. مثال کمابیش تکراری: اگه قرار باشه هر ماه یه گزارش تهیه کنم، برام حس دست‌آورد رو نداره؛ یه کار تکراری و …
چند وقت پیش تو مطلبی درباره biasهای فکری نوشته بودم و این‌که چطوری باعث می‌شن تصمیم‌گیری‌های اشتباه بکنیم. تو این مدت چند نفر به من ایمیل دادن و پرسیدن که چطوری می‌شه باهاشون مقابله کرد. سوال خیلی خوبیه و می‌خوام خیلی خلاصه رویکرد خودم رو براتون بگم.
برای این‌که جلوی مشکلات ناشی از biasهای فکر رو بگیریم سه روش و سه مرحله وجود داره:
مرحله اول: درک و پذیرش
درک این‌که biasها چی هستن و چرا وجود دارن و پذیرفتن این‌که خودمون هم دچارشون هستیم، نه این‌که فقط مشکلیه برای بقیه. برای این ماجرا باید در موردشون تحقیق و مطالعه کنین و بعد سعی کنین رد پای اون‌ها رو تو تصمیم‌گیری‌های دیگران و خودتون پیدا کنین.
همین که آدم این کار رو بکنه خودش نوعی ایمنی ایجاد می‌کنه و تصمیم‌گیری‌ها بهتر می‌شن.
علاوه بر اون مطالعه این کتاب‌ها رو هم پیشنهاد می‌کنم:
Thinking, Fast and Slow، از Daniel Kahneman – این کتاب خیلی خوبیه و گذشته از این‌که اطلاعاتش خیلی به بهبود تصمیم‌گیری‌ها کمک می‌کنه، درک خیلی خوبی هم از مبنای وجود و مکانیزم عملکرد biasها می‌ده.
The Art of Thinking Clearly، از Rolf Dobelli – این کتاب مجموعه‌ای از مهم‌ترین biasها رو با مثال‌های خیلی خوب توضیح می‌ده.
این ماجرا که اختصاصی‌سازی (tailoring) برای اکثر استانداردها، از جمله PMBOK و PRINCE2، الزامیه، باعث می‌شه که اهمیت زیادی پیدا کنه، در حالی که شیوه انجام این کار برای خیلی‌ها مبهمه. تو این مطلب می‌خوام یه مقدار اختصاصی‌سازی رو توضیح بدم.
اولین نکته اینه که برای استفاده از استاندارد تو پروژه‌ها دو مرحله کار لازمه:
انطباق استاندارد با سازمان، که اصطلاحا بهش می‌گن embedding
انطابق نسخه اختصاصی‌سازی شده سازمان با پروژه‌ای که قراره شروع بشه، که بهش می‌گن tailoring
البته این رو باید بدونین که خیلی جاها به هردوی این‌ها tailoring می‌گن.
کلمه tailor وقتی حالت اسمی داشته باشه به معنی خیاطه؛ البته معمولا خیاطی که کت شلوار می‌دوزه. وقتی حالت فعل داشته باشه معنیش می‌شه: چیزی رو به شکلی بسازیم که برای کار یا فرد خاصی مناسب باشه یا چیزی که وجود داره رو به شکلی تطبیق بدیم که کاملا برای فرد یا کاری که در نظر داریم مناسب باشه. وقتی درباره tailor کردن استاندارد صحبت می‌کنیم هم همین معنی در نظره.
مرحله ۱: embed کردن استاندارد در سازمان
اولین مرحله embed کردن استاندارد تو سازمانه، یعنی نسخه‌ای اختصاصی‌سازی شده از استاندارد بسازیم که برای سازمان و پروژه‌های مختلفی که توش اجرا می‌شه مناسب باشه. ماجرا اینه که پروژه‌های مختلفی که تو یه سازمان انجام می‌شن از نظر مدیریتی خیلی به هم نزدیکن، چون سازمان انجام …
بعضی‌ها تو تشخیص تفاوت بین enterprise environmental factors و organizational process assets تو PMBOK مشکل دارن که بخشی از این مشکل برمی‌گرده به درک تفاوت واژه‌های enterprise و organization. از طرف دیگه بعضی‌ها هم احتمالا کنجکاوین که به شکل کلی تفاوت این دو رو بدونین.
organization
کلمه organization که معمولا به سازمان معادل می‌شه به هر ترکیبی از آدم‌ها گفته می‌شه که برای رسیدن به هدفی گرد هم اومدن. معمولا منظور از سازمان یه شرکت یا یه ترکیب غیر انتفاعی یا ترکیبی دولتیه، ولی می‌تونه به چیزهایی خردتر از اون‌ها هم گفته بشه. مثلا خود پروژه هم می‌تونه یه سازمان به حساب بیاد یا حتی زیرمجموعه یه پروژه هم می‌تونیم سازمان‌های مختلفی مثلا برای مدیریت، برای اجرای بخش‌های مختلف و امثال اون‌ها در نظر بگیریم.
کلمه organization تو پم‌باک معمولا به معنی شرکت یا موسسه‌های مشابه اون به کار می‌ره و تو عبارت organizational environmental factor صرفا به معنی سازمانیه که داره پروژه رو اجرا می‌کنه (مثلا پیمانکار).
enteprise
کلمه enterprise دو معنی کلی داره. معنی اول مشابه organization هست، با این تفاوت که ترکیب‌های خردتر رو در بر نمی‌گیره؛ یعنی به شرکت یا سازمان‌های غیر انتفاعی و دولتی و امثال اون‌ها گفته می‌شه. قدیم (مثلا بیست سال پیش) فقط به سازمانی enterprise گفته می‌شد که بزرگ و پیچیده باشه، ولی الان …
امسال هم مثل سال گذشته برای سخنرانی تو کنفرانس PMI بلژیک انتخاب شدم. عنوان موضوع امسال من اینه: Project managers are biased too.
مطلبی خاص و متفاوت در مورد اشتباه‌هاییه که به خاطر گرایش‌های ناخودآگاهمون تو تصمیم‌گیری‌های مدیریتی می‌کنیم و ریشه‌های اون موارد. این عوامل البته به مدیریت پروژه محدود نمی‌شن و بحث مفصلیه تو اندیشه انتقادی (critical thinking) و رشته‌های دیگه. با این حال تو این مطلب ماجرا از زاویه دید مدیران پروژه‌ها بررسی می‌شه.
به عنوان نمونه، تکنیک دلفی، که احتمالا اسمش رو شنیده باشین (مثلا تو پم‌باک هم بهش اشاره می‌شه) روشیه برای جلوگیری از بعضی مشکلات اینچنینی. ماجرا اینه که اگه برای پیدا کردن ایده‌های جدید یا راه‌حل‌های بدیل تو یه جلسه شروع کنیم از آدم‌ها نظرشون رو بپرسیم، نظر هر کسی روی نظر بقیه اثر می‌ذاره و جواب کاملی نمی‌تونیم بگیریم. برای همین می‌شه مثلا با تکنیک دلفی پیش رفت و اول از همه نظرهاشون رو مکتوب و بی‌نام گرفت و بعد از این‌که نظرها جمع‌آوری و مرتب شد به بحث بذاریمشون.
حالا یه مثال: به شما این فرصت داده شده که بازی A یا بازی B رو انتخاب کنین و این بازی یک بار براتون اجرا می‌شه. مشخصات بازی این پایین اومده و بهتره که تو حداکثر ۱۰ ثانیه جواب بدین. حتما هم صادقانه جواب بدین، طوری که انگار واقعا قراره بازی رو انجام بدین و پول رد و بدل بشه. یه سکه می‌ندازیم …
وقتی کتاب راهنمای جامع پراجکت ۲۰۱۳ منتشر شد مجبور شده بودم بخش پروژه‌های نمونه رو ازش حذف کنم که تعداد صفحه‌ها از حدی که برای ناشر مناسبه بیشتر نشه. از طرف دیگه وعده داده بودم که کتابی مستقل و خیلی مفصل‌تر برای پروژه‌های نمونه تهیه کنم،که متاسفانه تا الان فرصتش پیش نیومد.
چون خیلی‌ها به دنبال پروژه‌های نمونه بودن، به این نتیجه رسیدم که بهتره فعلا دو پیوست انتهایی کتاب پراجکت ۲۰۱۰ که پروژه‌های نمونه‌ش بود رو در اختیار خواننده‌ها بذارم تا زمانی که کتاب اصلی رو بتونم تهیه کنم.
یکی از اصول مدیریت پروژه اینه که باید درس آموخته‌های (lessons learned) پروژه رو ثبت و نگهداری و بازاستفاده کرد. وقتی می‌خوایم پروژه جدیدی رو شروع کنیم، یکی از اولین کارهامون اینه که درس آموخته‌های مرتبط رو از پروژه‌های قبلی جمع کنیم.
ولی واقعا چطوری باید این کار رو کرد؟
قبل از هر چیز باید به هدف این کار فکر کنیم. ماجرا اینه که تو هر پروژه با مسایل مختلفی مواجه می‌شیم و بر اساس تصمیم‌هایی که می‌گیریم نتیجه‌های مناسب یا نامناسبی می‌گیریم. همه این تجربه‌ها هم با سرمایه شرکت داره انجام می‌شه و دانشش باید برامون ذخیره بشه تا بتونیم بعدا ازش استفاده کنیم و دایما درجا نزنیم.
برای این‌که بتونیم این کار رو بکنیم شرایطی وجود داره:
همه باید تو این ماجرا مشارکت کنن
این کار باید تو برنامه روزانه باشه، نه مثلا موقع تموم شدن پروژه که هم حواسمون به جای دیگه‌س و هم درست همه چیز یادمون نمیاد.
اطلاعات باید طور مناسبی ذخیره بشن که بشه بعدا ازشون استفاده کرد.
حالا چطوری؟
راه حلی که من همیشه پیشنهاد می‌کنم استفاده از ویکی (wiki) یا انجمنه (forum). اولی برای تیم‌هایی که مهارت‌های کامپیوتری بالاتری دارن مناسبه (مثلا اعضای تیم پروژه‌های نرم‌افزاری) و دومی برای بقیه تیم‌ها.
یه نرم‌افزار ویکی (مثلا مشابه اون چیزی که برای ویکیپدیا استفاده می‌شه) یا یه نرم‌افزار انجمن (تالار گفتگو) مشابه اون چیزهایی که همه …
من حداقل هفته‌ای دو سه ایمیل می‌گیرم از کسایی که تو شرکت جدیدی مشغول به کار شدن و با روند کار شرکت، ساختارهای شکستی که می‌تونه توش به کار بره و فعالیت‌های برنامه‌هاشون آشنا نیستن و دنبال منبعی می‌گردن که اون‌ها رو یاد بگیرن.
خوب، منبع چیه؟ بهترین منبعی که دارین همون آدم‌هایی هستن که تو اون شرکت کارهای فنی می‌کنن. باید دونه دونه باهاشون صحبت کنین و یافته‌هاتون رو مستند کنین تا به تدریج به تصویر کاملی از کل ماجرا برسین.
متاسفانه خیلی‌ها فکر می‌کنن این کار بده و باعث می‌شه فکر کنین کار بلد نیستین. ولی این اصولی‌ترین و حرفه‌ای‌ترین شکل برخورد با کاره، چون:
حتی تو صنف‌ها و صنعت‌های یکسان هم تفاوت‌های خیلی عمده‌ای بین روش‌های کاری هست که تنها راه درکش اینه که اطلاعات رو از همون شرکت بگیرین.
تمام کسایی که تو حوزه مدیریت پروژه فعالیت می‌کنن، از جمله تو برنامه‌ریزی و کنترل پروژه، فقط لازمه که درک کامل و درستی از تمام یا بخشی از مدیریت پروژه داشته باشن و نه جنبه‌های فنی پروژه‌های خاص. به عنوان مثال چنین آدمی باید بدونه که یه ساختار شکست خوب چیه و چطوری تهیه می‌شه و به چه کاری میاد، نه این‌که بدونه ساختار شکست کار مناسب برای فلان نوع یا بهمان نوع پروژه چیه.
بعد از این‌که تمام اطلاعاتی که لازم داشتین رو استخراج کردین، می‌تونین برای بهبودشون از تجربه‌ها و الگوهای پذیرفته شده شرکت‌های مشابه هم …
خیلی وقت‌ها می‌بینیم که تو اداره یه شرکت مشکلای زیادی وجود داره و شروع می‌کنیم به ایراد گرفتن و بعضا مسخره کردن. این کار برای خیلی‌ها جزئی از فرهنگ روزمره‌شونه، یعنی سر کار که می‌رن باید چنتا نامه جواب بدن، روی کارای دوتا پروژه کار کنن، حداقل بیست دقیقه هم مدیریت شرکت رو مسخره کنن.
ماجرا اینه که:
ممکنه یه شرکت هزارتا کار خیلی اشتباه انجام بده، ولی به ازای اون ده هزارتا کار درست و حساب شده هم داره انجام می‌ده و برای همینه که هنوز سرپا مونده؛ البته مشخصا دارم در مورد شرکت‌های خصوصی صحبت می‌کنم که نوعی انتخاب طبیعی در موردشون صادقه. این‌که فقط بخوایم اشتباه‌ها رو مبنای قضاوت قرار بدیم و به کارهای درست و سنجیده توجه نکنیم خیلی بی‌انصافیه.
مدیریت یه کار یکپارچه‌س. خیلی راحته که آدم یه مورد کوچیک رو پیدا کنه که خوب پیش نمی‌ره و به روش‌های بهتری برای اجراش فکر کنه و بعد هم بگه که ببین این‌ها چقدر نادون هستن که روشی به این سادگی و موثری رو اجرا نمی‌کنن. ولی واقعا اینطوره؟ اون روش هرچی که باشه باید با بدنه کلی مدیریتی یکپارچه بشه و این ماجرا معمولا به این سادگی نیست. بعضی وقت‌ها برای یکپارچه کردن یه تغییر کوچیک باید کلی چیزها رو عوض کنیم. پس هر چیزی که به نظر ساده میاد الزاما ساده نیست.
در نهایت این‌که از حرف تا عمل راه خیلی زیاده. شاید یه روش به نظر خیلی بهتر بیاد، ولی وقتی جانشین روش …
امروز یکی از خواننده‌ها از من سوالی در مورد انگیزه تجاری (Business Case) کرد و من تازه متوجه شدم که ممکنه تو کتاب‌هام به اندازه کافی توضیح نداده باشمش. سوال این بود که این منطقیه که مدیر پروژه پیمانکار انگیزه تجاری رو خیلی واقع‌بینانه برای کارفرما به‌روزرسانی کنه، در حالی که اگه مشخص بشه پروژه توجیه‌پذیر نیست ممکنه به قیمت از دست دادن پروژه تموم بشه یا نه.
اول این‌که مبنا باید شفافیت باشه؛ اگه پیمانکار متوجه می‌شه که پروژه برای کارفرماش توجیه‌پذیر نیست باید بهش اطلاع بده و در این صورت بهتره که پروژه لغو بشه. گذشته از این‌که این‌کار اعتبار پیمانکار و رضایت کارفرما رو افزایش می‌ده و تو بلند مدت به نفع پیمانکار تموم می‌شه، جلوی بعضی مشکلات رو هم تو کوتاه مدت می‌گیره: پروژه‌ای که توجیه‌پذیر نباشه احتمال زیادی داره که پیش از اتمام به مشکلات مالی بخوره و در این صورت پیمانکار هم ممکنه نتونه مطالباتش رو به راحتی بگیره. خیلی از کارفرماهای بزرگ خودشون تامین‌کننده‌های مالی دیگه‌ای دارن (مثل سازمان‌های بالادست) که به هر حال اون‌ها دیر یا زود متوجه ماجرا می‌شن و تامین نقدینگی رو ممکنه متوقف کنن.
ولی از این‌ها که بگذریم، این نکته مهم رو باید در نظر داشته باشین که تو همه استانداردها وقتی از انگیزه تجاری صحبت می‌کنیم منظورمون صرفا انگیزه تجاری‌ایه که برای شرکت خودمون وجود داره، نه برای کارفرما یا …
من همیشه از انعام دادن خوشم میاد. این ماجرا ممکنه تو این تجربه خیلی محدود من شکل گرفته باشه که وقتی خیلی کم سن بودم چند ماه بدون این‌که خانوادم بدونن یه جایی فروشندگی کردم. انعام‌هایی که مردم می‌دادن در آخر پول خوبی می‌شد و واقعا بهم مزه می‌داد! از طرف دیگه، این‌که احساس می‌کنم با انعام دادن من یه نفر خوشحال می‌شه (هرچند کوچیک) خودش خیلی ارزش داره.
بگذریم. ماجرایی که امروز به ذهنم رسید شیوه انعام دادن بود. اکثر آدم‌ها وقتی سرویس رو کامل دریافت می‌کنن انعام می‌دن. این کار مثل این می‌مونه که آدم صبر کنه، سرویس رو ارزیابی کنه و بعد به ازای اون پولی اضافه بده. یادمه دایی من از قدیم جور دیگه‌ای برخورد می‌کرد: انعام رو اول می‌داد، تا سرویس بهتری دریافت کنه. من هم یه مدتیه که دارم از این روش استفاده می‌کنم و واقعا ازش راضی‌ام.
احتمالا می‌دونین که من همیشه گفتم اگه لازم باشه PMBOK رو تو یه جمله خلاصه کنیم، می‌شه «انفعالی برخورد نکن». مثال: شما مدیر پروژه‌ای و متوجه شدی که نتیجه طراحی یکی از مهندس‌ها مشکل داره. اولین کاری که باید کرد چیه؟
تقریبا همه می‌گن که به نوعی اون ایراد رو برطرف کنیم. این می‌شه «راه حل اصلاحی»، در حالی که قراره اولویت با «راه حل پیش‌گیرانه» باشه. اولین کاری که می‌کنیم اینه که ببینیم دلیل ریشه‌ای این مشکل چی بوده. مثلا اطلاعات درست به اون طراح نرسیده؟ با همکارانش مشکل …