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