همانند منابع پروژه که محدودند، توان اندیشیدنمان هم محدود است. همان‌گونه که کوشش می‌کنیم از منابع پروژه بهینه استفاده کنیم، باید مراقب استفاده از توان اندیشیدنمان هم باشیم. در نقش مدیر پروژه باید به اعضای تیم پروژه نیز کمک کنید تا از توان ذهنی خود بهینه استفاده کنند.
اگر خود را درگیر ریزه‌کاری‌های پروژه و جنبه‌های فنی کنید، بخشی از توان اندیشیدنتان صرف خواهد شد و توان کمتری برای وظایف واقعیتان باقی می‌ماند. البته به جز آن دشواری‌های دیگری هم ایجاد می‌شود که پیش از این بررسیشان کردیم. فرض کنید توان اندیشیدنتان مبلغ محدودیست و برآنید که آن را در بهترین حوزه‌ها سرمایه‌گذاری کنید.
آیا قاعده ۸۰/۲۰ را می‌شناسید؟ بر پایه این قاعده، حدود ۸۰ درصد منافع بسیاری از دامنه‌ها با حدود ۲۰ درصد عناصرش به وجود می‌آیند. به آنچه شخصا در پروژه‌ها انجام می‌دهید بیندیشید: احتمالا حدود ۸۰ درصد نتایج مناسبی که می‌گیرید با ۲۰ درصد از کارهایی که کرده‌اید به دست آمده‌اند. بنا بر این، شاید بتوانید در فعالیت‌های خود بازبینی کنید و با حذف برخی از آن‌ها که نتیجه چندانی در بر ندارند، عناصر پربار را تقویت کنید.
قاعده ۸۰/۲۰ یکی از راهنماهای تدوین متدولوژی P3.express هم بوده است. به‌جای هدف قرار دادن ۱۰۰ درصد منافع مدیریت پروژه ساخت‌یافته با ۱۰۰ درصد کوشش، سیستمی ساخته شده است که با کمک آن بتوانید ۸۰ درصد منافع را با …
اگر هر بار که قرار است کاری انجام دهید روند آن را دوباره کشف و تدوین کنید، انرژی فراوانی لازم خواهد بود و احتمال اشتباه نیز بالا می‌رود. به جای آن بهتر است که جنبه‌های مشترک کارها را با عناصر تکرارپذیر مستند کرده، به‌تدریج بهبود دهید.
نمونه خوبی برای عناصر تکرارپذیر، چک‌لیست است. برای نمونه، اگر قرار است اسناد مهندسی فراوانی در شرکت ارزیابی شوند، هرآنچه باید چک شود را در چک‌لیستی مستند کنید و هر بار که فرآیند تکرار می‌شود به‌جای اندیشیدن به الزامات کنترلی، از آن لیست کمک بگیرید. در زمان به کارگیری لیست، چه‌بسا موارد بهبودی نیز به ذهنتان برسد که می‌توانید در چک‌لیست اعمال کرده، هم برای مورد در دست اقدام و هم برای موارد آینده به کار ببرید.
نمونه دیگر وجود چرخه‌های تکرارپذیر در متدولوژی‌هایی مانند P3.express است. فعالیت‌هایی که هر ماه یا هر هفته با روند ویژه‌ای تکرار می‌شوند به‌تدریج تبدیل به عادت می‌شوند و توان ذهنی کمتری نیاز خواهند داشت. توانی که اینگونه صرفه‌جویی کرده‌اید را می‌توانید صرف حل مسایل دیگر کنید.
ایمیلی برای تایید به آدرسی که ثبت کردید ارسال شد. بعد از تایید ایمیل، در خبرنامه سایت مشترک خواهید شد.
توجه داشته باشید که ممکن است ایمیل در پوشه اسپم قرار گرفته باشد. در این صورت علاوه بر تایید ایمیل، آن را از حالت اسپم نیز خارج کنید تا بتوانید در آینده خبرنامه را بدون مشکل دریافت کنید.
هرگاه تفاوت اجرا و برنامه انحرافی در متغیرهای پروژه مانند زمان و هزینه ایجاد کند، یا باید متغیرها را بازبینی کرد یا انحراف‌ها را از بین برد. هر متدولوژی روند ویژه‌ای برای این کار دارد. معمولا هنگامی که اثر انحراف از حدی کمتر باشد، اعضای تیم یا رهبران تیم‌ها برای انحراف تصمیم می‌گیرند، اگر اثر از حد آن‌ها بالاتر باشد مدیر پروژه، وگرنه حامی پروژه و افراد دیگر در لایه‌های بالاتر سازمان.
بسیاری از متدولوژی‌ها حدود تصمیم‌گیری دارند، ولی بسیاری برداشت اشتباهی درباره آن‌ها دارند. برای نمونه، حدود تصمیم‌گیری در پرینس۲ تلورانس نامیده می‌شوند، و بسیاری گمان می‌کنند که این تلورانس‌ها مانند تلورانس‌های مهندسی هستند و مشخص می‌کنند که چه مواردی نیاز به تصمیم‌گیری دارند و اگر اثر موردی کمتر از تلورانس باشد نیاز به اصلاح نخواهد داشت. چنین برداشتی درست نیست: هر انحرافی نیاز به اصلاح دارد و تلورانس‌ها فقط مشخص می‌کنند که چه کسی باید تصمیم‌گیری کند.
همیشه بهتر است انحراف‌ها در زودترین زمان اصلاح شوند، زیرا هرچه بیشتر روی هم انباشته شوند اصلاح کردنشان دشوارتر خواهد شد.
وقتی انحرافی وجود دارد، باید برایش اقدامی اصلاحی طراحی کنید. افزون بر آن، لازم است که اقدامی پیشگیرانه نیز طراحی کنید که احتمال بروز مشکل‌های همانندش را در آینده کم کند. متاسفانه بسیاری فقط به اقدام‌های اصلاحی توجه می‌کنند و نه پیشگیرانه.
اگر به هر دلیلی لازم باشد که میان اقدام اصلاحی و اقدام پیشگیرانه تنها یکی را انتخاب کنید، انتخاب درست، اقدام پیشگیرانه خواهد بود. اگر غیر از این عمل کنید، همیشه با انبوهی از دشواری روبرو خواهید بود و هیچ زمانی برای کارهای زیربنایی نخواهید داشت.
روند مناسب در رویارویی با هر انحرافی این‌چنین است:
دلیل ریشه‌ای بروز این انحراف چیست؟ چگونه می‌توانم از بروز مشکل‌های همانند آن در آینده جلوگیری کنم؟
چگونه می‌توانم انحراف کنونی را اصلاح کنم؟
نگاهی به متدولوژی خود بیندازید و ببینید که این دو مسئله چگونه پوشش داده شده‌اند. اگر گمان می‌کنید ممکن است طراحی اقدام‌های پیشگیرانه را فراموش کنید و این موضوع در متدولوژی به‌اندازه کافی روشن نیست، آن جنبه را تقویت کنید تا از قلم نیفتد.
در بخش پیش نخستین چالش کلان که پذیرش تیم بود را بررسی کردیم. چالش دیگری هم وجود دارد: شاید فردی فنی باشید که به دلیل علاقه به مدیریت پروژه چنین سمتی را پذیرفته است. با توجه به ریسک‌هایی که مدیریت پروژه برای افراد فنی دارد و پیش‌ازاین بررسی‌اش کردیم، چه باید بکنید؟
در چنین حالتی باید کاملا درباره دوگانگی مسایل فنی و مدیریتی خودآگاه باشید. هر زمان که قرار است سخنی بگویید، کاری انجام دهید، یا تصمیمی بگیرید، از خود بپرسید که موضوع فنیست یا مدیریتی، و اگر مدیریتی نبود، آن را بر دوش فرد مسئولش بگذارید. این مسئله با تمرین درونی می‌شود و پس از مدتی ناخودآگاه درست عمل خواهید کرد.
یکی از مدیر پروژه‌های خبره‌ای که می‌شناختم معمار بود. در یکی از پروژه‌ها که جنبه‌های معمارانه حساسی داشت مدیر پروژه بود. در یکی از جلسه‌ها، دو شرکت مشاور مسئول در پروژه درگیر بحثی طولانی درباره یکی از جنبه‌های معماری پروژه شده بودند. به‌یکباره یکی از افراد جلسه از مدیر پروژه پرسید «آقای دکتر، دیدگاه شما چیست؟ هرچه باشد شما هم معمار هستید!» و او در پاسخ گفت «من اینجا به‌عنوان مدیر پروژه در کنار شما هستم و نه به‌عنوان معمار. در نقش مدیر پروژه می‌توانم به شما بگویم که بهتر است در این باره جلسه جداگانه‌ای برگزار کنید و با سنجش همه موارد به رای نهایی برسید. نکات مثبت و منفی تصمیم را هم مکتوب کرده، برایم بفرستید. اگر …
در حال اجرای پروژه با انواع اقلام قابل‌پیگیری (follow-up item) روبرو خواهید شد که باید آن‌ها را ثبت و مدیریت کنید. منظور از اقلام قابل‌پیگیری، عناصر زیر است:
ریسک‌ها: ریسک به پیشامدهایی که ممکن است در آینده روی دهند و اثری مثبت یا منفی بر پروژه بگذارند گفته می‌شود. در زمان اجرای پروژه، به دلیل نزدیکی بیشتر به کار، امکان بیشتری برای شناسایی ریسک‌ها خواهید داشت. بسیاری از سیستم‌های چابک جلسه‌هایی روزانه دارند که همه اعضای تیم گرد هم می‌آیند و در مدت ۱۵ تا ۲۰ دقیقه، هرکدام از اعضای تیم پاسخ سه پرسش را می‌دهد: از دیروز تا امروز چه کرده‌ام؟ از امروز تا فردا چه خواهم کرد؟ برای انجام کارهایم با چه دشواری‌هایی ممکن است روبرو شوم؟ چنین جلسه‌هایی فرصت خوبی برای شناسایی ریسک‌هاییست که در آینده نزدیک وجود خواهد داشت و با کمی کوشش بیشتر شاید بتوانید آن را به ریسک‌های دورتر هم تسری دهید. چنین جلسه‌ای برای پروژه‌های بسیار کوچک مناسب است، ولی در سایر پروژه‌ها هم می‌توان شکل‌های اختصاصی‌سازی‌شده‌ای از آن را به وجود آورد.
مسایل: به طور کلی، هرچه خلاف برنامه‌ها پیش رفته باشد «مسئله» نامیده می‌شود. مشکل‌هایی که در هنگام کار روی می‌دهند و ریسک‌هایی که عینیت پیدا می‌کنند نمونه‌هایی از مسایل هستند.
برنامه‌های بهبود: بهتر است رضایت ذی‌نفعان را دوره‌ای ارزیابی کرده، بر پایه آن برنامه‌هایی برای بهبود کار …
روش مناسب برای ساخت هر محصول فقط بستگی به نوع محصول دارد و نه مسایل دیگری مانند ترجیح تیم، مدیر پروژه، سازمان، یا کارفرما.
آیا می‌توانید محصولی که پاسخگوی نیازها و خواسته‌ها باشد را پیش‌بینی کنید یا با خواسته‌هایی پیش‌بینی‌ناپذیر سروکار دارید و لازم است که آن‌ها را به‌تدریج و با نمایش دادن نسخه‌هایی قابل استفاده از محصول (increment) کشف کنید؟ آیا اصلا امکان ساخت نسخه‌های قابل استفاده محصول برای ارزیابی خواسته‌های بازار وجود دارد؟
در روش تطبیقی باید بتوانیم نسخه‌های متعددی از محصول بسازیم، به‌گونه‌ای که هر نسخه قابلیت‌های بیشتری داشته باشد و همواره قابل استفاده باشد زیرا فقط اینگونه می‌توان بازخورد مناسب از محیط دریافت کرد. با بهره‌مندی از بازخورد هر نسخه، حدس میزنیم که بهترین کاری که در نسخه بعد می‌توان انجام داد چیست و بر آن پایه جلو می‌رویم. فراموش نکنید که هدف اصلی از گردآوری بازخورد در سیستم‌های متعین کشف مسیر مناسب برای آینده است و نه اصلاح گذشته. اصلاح گذشته بر پایه بازخورد در همه پروژه‌ها وجود دارد و به معنی تطبیقی بودن نیست.
برای این‌که بتوان به ترتیب گفته شده جلو رفت، باید در هر نسخه بر زیرمجموعه‌ای از ویژگی‌های تازه تمرکز کنیم و آن اجزا را جدا از سایر اجزا تعریف، طراحی، و تولید کرده، با خروجی‌های پیشین ترکیب کنیم. اگر فرآیندهای توسعه (تعریف، طراحی، …) را نتوانیم از …
اندیشه انتقادی حوزه‌ای درباره تصمیم‌گیری و ایده‌پردازی سنجیده و به‌دور از فریب‌های ذهنیست. اگر قرار باشد این کتاب فقط یک اثر بر شما داشته باشد، امیدوارم این اثر علاقه‌مند کردنتان به مطالعه درباره اندیشه انتقادی باشد! این مهارت کمک‌های فراوانی به پروژه‌هایتان خواهد کرد و افزون بر آن در زندگی شخصی‌تان هم کارآمد خواهد بود.
اندیشه انتقادی یکی از جنبه‌های اندیشه سیستمی است؛ دست‌کم، پم‌باک آن را اینگونه مدل می‌کند.
عنوان نخستین این اصل اندیشه سیستمی بود، ولی برای یکسان‌سازی عنوان‌ها و تبدیل آن‌ها از حالت اسمی به امری، به جمله بلندی که هم‌اکنون وجود دارد تبدیل شد. از آن گذشته، موضوع این اصل همچنان اندیشه سیستمیست.
اندیشه سیستمی درباره اندیشه‌ورزی همه‌جانبه درباره پیچیدگی‌هاست. بررسی همه‌جانبه مفهوم پیچیده «ارزش» در بخش‌های پیشین نمونه‌ای از اندیشه سیستمیست.
اندیشه سیستمی حوزه‌ای گسترده و کمابیش پیچیده است. مهم‌ترین مسایل در اندیشه سیستمی در مدیریت پروژه از این قرارند:
برنامه‌ریزی باید گستره، زمان، هزینه، کیفیت، منابع، ریسک و سایر حوزه‌ها را پوشش دهد. با این‌همه، زمان‌بندی یکی از عناصر مهم و مرکزی در برنامه‌ریزیست و معمولا موردی که چالش‌های ویژه خود را دارد و از این‌رو بیشتر از دیگر حوزه‌ها به آن پرداخته شده است.
زمان‌بندی به معنی تخصیص زمان آغاز و پایان یا ترتیب اجرا به فعالیت‌های پروژه است.
دو نوع زمان‌بندی می‌توان داشت:
وابستگی محور
اولویت محور
فعالیت‌های بسیاری از پروژه‌ها وابستگی‌هایی ذاتی و گریزناپذیر به همدیگر دارند. برای نمونه، تا وقتی دیواری ساخته نشده باشد نمی‌توانید آن را رنگ کنید. چنین پروژه‌هایی را باید به شیوه وابستگی محور برنامه‌ریزی کرد. برای این کار شبکه‌ای از روابط میان فعالیت‌ها ساخته می‌شود و اطلاعاتی دیگر مانند مدت‌زمان آن‌ها نیز درج می‌شود. پس از آن با روش مسیر بحرانی (critical path method) و همانند آن تاریخ‌های آغاز و پایان به دست می‌آیند. نرم‌افزارهایی مانند پریماورا و مایکروسافت پراجکت نمونه‌هایی از ابزارهای رایج در این نوع برنامه‌ریزی‌اند.
فعالیت‌های برخی پروژه‌ها را می‌توان به شکلی ساخت که به هم وابسته نباشند. در این حالت می‌توانید آن‌ها را با روشی اولویت محور زمان‌بندی کنید. در این روش، اولویت هر فعالیت بر پایه مجموعه‌ای از پارامترها مانند ارزش و ریسک تعیین می‌شود و سپس فهرست فعالیت‌ها بر آن پایه مرتب می‌شود. …
اگر ذی‌نفعان پرشمار باشند، بد نیست آن‌ها را بر پایه توجیه‌پذیری برنامه‌ای که برای مشارکت‌دادنشان دارید، حدود اثرگذاری، و موارد مشابه آن اولویت‌بندی کنید تا اگر زمانی در میان اجرای پروژه توان کافی برای اجرای همه برنامه‌ها نبود، دست‌کم روی مهم‌ترین موارد تمرکز کنید.
به یاد داشته باشید که توجیه‌پذیری‌ها دایما تغییر می‌کنند و از این رو باید اولویت‌بندی‌ها را نیز اصلاح کنید.
فرض کنید منبع‌هایی که دارید تنها برای انجام یکی از دو پروژه زیر بسنده می‌کند:
پروژه ۱ – با به پایان رساندن پروژه معادل یک میلیون پیتزا پول به دست خواهید آورد.
پروژه ۲ – پس از به پایان رساندن پروژه، به مدت بیست سال، هر سال معادل سیصد هزار پیتزا به دست خواهید آورد.
کدام پروژه را انتخاب می‌کنید؟
اگر پیش از این تنها روی پروژه‌های بلندمدت سرمایه‌گذاری کرده باشید نیاز به درآمد کوتاه‌مدت خواهید داشت و از این رو شاید گزینه نخست بهتر باشد. اگر شرکت دچار چالش مالی و در شرف ورشکستگی باشد، بی‌گمان گزینه نخست بهتر خواهد بود. اگر چالشی در درآمدهای کوتاه‌مدت وجود نداشته باشد، شاید گزینه دوم را ترجیح دهید.
این نمونه دیگری از مواردیست که ارزیابی ارزش پروژه بستگی به وضعیت کلان سازمان پیدا می‌کند و بنابراین نیاز است که ارزیابی در آن سطح انجام شود.
کسانی که در چنین تصمیم‌گیری‌هایی مشارکت می‌کنند هم باید با دقت انتخاب شوند. مشکلی رایج در برخی سازمان‌های بزرگ این است که فردی مشهور را به طور کوتاه‌مدت به‌عنوان مدیرعامل انتخاب می‌کنند. او که می‌داند بیش از چند سال مدیرعامل نخواهد بود، تنها هدفش ایجاد سابقه بهتر برای خودش خواهد بود و درنتیجه به جای این‌که ترکیبی از بهترین پروژه‌ها را انتخاب کند، فقط روی پروژه‌هایی با بازگشت کوتاه‌مدت تمرکز می‌کند. برخی از آن‌ها حتی آینده بلندمدت سازمان را …
بیشتر افراد در پاسخ به نیازها یا مشکل‌ها بی‌درنگ نخستین راهکار «بدیهی» را انتخاب می‌کنند. اگر زمان بیشتری صرف درک مشکل و نیاز کنیم و راهکارهای گوناگون را بسنجیم، معمولا می‌توانیم گزینه‌های بهتری بیابیم. برای همین چنین روندی در همه متدولوژی‌ها وجود دارد:
الزامات ← تحویل‌شدنی‌ها ← فعالیت‌ها
گام نخست، شناسایی الزامات است؛ هم الزامات واضح و هم پنهان. بسیاری از الزامات از سوی کارفرما هستند، ولی معمولا آنچه به شما می‌گویند واقعا الزام پروژه نیست، بلکه راهکاری «بدیهی» است برای الزامی که در ذهن داشته‌اند. از این رو، باید با آن‌ها گفتگو کنید تا بتوانید الزامات واقعی را استخراج کنید. از سوی دیگر، معمولا بیش از یک نماینده از سوی کارفرما وجود دارد و الزاماتی که در اختیارتان می‌گذارند شاید با یکدیگر هماهنگ نباشند که در این حالت هم باید به شکل‌های گوناگون رفع اختلاف کنید و به مجموعه‌ای سازگار از الزامات برسید. بسته به نوع محصول پروژه و محدوده مسئولیت‌هایتان، شاید بهتر باشد به آنچه از نمایندگان کارفرما می‌شنوید نیز کاملا اعتماد نکنید و با شماری از کاربران نهایی که در آینده از محصول استفاده خواهند کرد هم گفتگو کنید.
افزون بر کارفرما، سازمان خودتان هم چه‌بسا الزاماتی برای همه پروژه‌ها داشته باشد که باید در نظرشان بگیرید. شاید آیین‌نامه‌های مختلفی هم برای نوع پروژه‌تان وجود داشته باشند که الزاماتی …
همه پروژه‌ها نیاز به برنامه‌ریزی دارند. برخی گمان می‌کنند پروژه‌های چابک نیاز به برنامه‌ریزی ندارند، ولی این‌چنین نیست؛ فقط برنامه‌ریزی آن‌ها با پروژه‌های متعین متفاوت است:
پروژه‌های متعین برنامه‌های تفصیلی یا کلان نخستین دارند. اگر برنامه نخستین تفصیلی نباشد، معمولا دوره‌ای (برای نمونه، ماهانه) تفصیلی می‌شود.
پروژه‌های تطبیقی با برنامه‌ای کلان آغاز می‌شوند. شاید برنامه هر دوره کمی تفصیلی‌تر شود، ولی فقط پیش از اجرای هر جز است که برنامه‌اش کامل تفصیلی خواهد شد.
همه کارهایمان باید هدفمند باشند. برنامه‌ریزی با دو هدف کلی انجام می‌شود:
هدایت پروژه
ارزیابی وضعیت پروژه
چگونگی هدایت پروژه به شیوه ساخت محصول بستگی دارد و ارزیابی وضعیت پروژه به متدولوژی مدیریت پروژه. برنامه‌ریزی مفهومی مستقل نیست و نمی‌توان درباره کیفیت برنامه مستقل از شیوه ساخت محصول و متدولوژی مدیریت پروژه قضاوت کرد. شاید برنامه‌ای برای یک بستر مناسب و برای بستری دیگر نامناسب باشد.