استحکام یک زنجیر تنها بهاندازه استحکام ضعیفترین حلقه آن است
حوزههای مختلفی در پروژه وجود دارد که همگی آنها باید موردتوجه قرار گیرند، ما باید چشمانداز جامعی از پروژه داشته باشیم. توجه به حوزههایی که در نگاه اول مهم بنظر میرسند (مثل زمان) بهتنهایی کافی نیست چون تمامی حوزهها باهم در تعامل هستند و تا زمانی که به همه آنها به میزان کافی توجه و رسیدگی نشود بهدرستی کار نخواهند کرد.
مثال: همهچیز با ضربالاجل مرتبط است
فرض کنید که شما در حال ساختِ مکانی برای مسابقات المپیک هستید این کار دارای یک ضربالاجل بسیار جدیِ زمانی است که اهمیت مدیریت زمان را دوچندان میکند. آیا موافقید؟
اگر کیفیت آنقدر کم باشد که پس از مدتی نیاز به دوبارهکاری باشد چه؟ پس کیفیت میتواند روی زمان تاثیرگذار باشد. ممکن است در پروژه شما یک باغ فانتزی نیز تعریف شده باشد اما ذکر شده باشد که در صورت کمبود وقت میتوان از آن چشمپوشی کرده و صرفاً آن زمین را چمنکاری کرد؛ بنابراین مدیریت محدوده کار (Scope Management) نیز مهم است. پس تا اینجا حوزههای زمان و کیفیت و Scope در کانون توجه ما قرار گرفت.
احتمالاً این داستان معروف را شنیدهاید: زمانی که رئیسجمهور آمریکا، آقای کِنِدی از یکی از نگهبانهای ناسا پرسید چهکار میکنی؟ او در پاسخ گفت “من اینجا برای فرستان انسان به کره ماه به دیگران کمک میکنم” آیا داشتن اینگونه افراد در پروژه، به تحویل بهموقع آن کمک نخواهد کرد؟
هر چه بیشتر پیش میروید متوجه خواهید شد که هر یک از این حوزهها در مدیریت زمان مشارکت دارند و تازمانیکه شما به همه حوزهها توجه نکنید نمیتوانید ضربالاجلها را در سطح قابل قبولی از قطعیت برآورده کنید.
مثال: رفتار گزینشی
وقتیکه افراد با متدهای متنوع مدیریت روبرو میشوند گاهی گزینشی رفتار کرده و هر آنچه از متدهای مختلف برایشان جذاب است را باهم ترکیب میکنند. این کار معمولاً بینتیجه است زیرا اجزا بهتنهایی کار نمیکنند، اجزایی که در کنار هم آورده میشود باید با یکدیگر سازگار باشند. هرگونه حذف، اضافه یا تغییر در یک سیستم باید با نگاهی جامع صورت پذیرد.
دلیل آنکه گاهی وقتها اجزا ضد و نقیضی در متدهای مختلف میبینیم نیز همین است مثلا میبینیم که یک کار در یک متد خاص نتیجه میدهد و متضاد آن در متد دیگر. هر جزء، بهخودیخود صحیح یا غلط نیست.
ایمنترین رویکرد آن است که یک متدولوژی برای پروژه انتخاب کنید، آن را سفارشیسازی (Tailoring) کنید و پیوسته با در نظر گرفتن سازگاری آن با کل سیستم، اجزا دیگری به آن اضافه کنید.
مثال: رویکرد ضد فرآیند
یکی از بهترین مطالبی که در متدولوژی Agile آورده شده این است که توجهها را به عوامل انسانی جلب کرده است. Agile Manifesto ارزش بیشتری برای اشخاص و تعاملاتشان در مقایسه با فرآیندها و ابزارها قائل است. اگرچه ممکن است که این مقایسه منصفانهای نباشد. تقریباً تمام متدها به اهمیت عوامل انسانی اشاره میکنند و تفاوت واقعی آنها با متد Agile آن است که عوامل انسانی بهجای یک پیشنهاد ساده بخش مجزایی از فرآیندهای آن است. بحث پیرامون رقابت بین عوامل انسانی و فرآیندها نیست بلکه راجع به نحوه نگرش سیستمها به عوامل انسانی است.
شکی نیست که برخی از افراد سعی میکنند فرآیندهای پیشرفتهتر را جایگزین عوامل انسانی کنند اما این تنها نوعی سوءِ رفتار است. حتی بهطور مشابه افراد مخالف این ایده نیز وجود دارد و برخی در تلاشاند تا فرآیندها را با عوامل انسانی جایگزین کنند که این هم نتیجه خوبی نخواهد داشت.
مثال: تمام حوزههایی که نیاز دارید اینجاست
وقتی به حوزهها فکر میکنید باید مراقب باشید که هیچکدام از آنها را از قلم نیندازید. این حوزهها کدماند؟ اگر کتب مرجع را بررسی کنید جوابهای متفاوتی خواهید یافت ، تا به امروز هیچیک از آنها کل حقیقت را بیان نکرده است.
تمهای PRINCE2® همان حوزهها هستند اما این تنها دامنههایی است که نقش کلیدی در متدولوژی ایفا میکنند مابقی حوزهها صرفاً بهطور ضمنی اشارهشده.
PMBOK® Guide یک متدلوژی نیست و میتوان آن را با 10 حوزه دانش (Knowledge Area) بهطور مناسبتری فرموله کرد بااینحال، این حوزههای دانش تفسیری از تمام حوزههای پروژه مبتنی بر چشمانداز PMBOK® است . بهعنوانمثال PMBOK® به عوامل انسانی توجه چندانی نمیکند.
ICB منبع مناسبی برای دریافت اطلاعات پیرامون حوزههاست. اگرچه ICB راجع به حوزهها نیست اما راجع به صلاحیتهای موردنیاز در پروژه بوده و رابطه یکبهیکی با حوزهها ندارد اما برای شناسایی آنها کمک شایانی میکند.
NUPP شامل لیست حوزهها نمیشود در درجه اول به این دلیل که اینیک متا سیستم است نه سیستم، ثانیاً به این دلیل که دستهبندی حوزهها، به نوع پروژه و محیط آن وابسته است. بهعنوانمثال یک پروژه ساختوساز معمول ممکن است نسبت به یک پروژه تحقیقاتی ابتکاری چشمانداز متفاوتی نیاز داشته باشد.
مترجم: مهرزاد منصورزاده