هنگامی که همه جنبههای فنی بر دوش متخصصان فنی پروژه گذاشته شود، چه کاری برای مدیر پروژه باقی میماند؟ هماهنگی، حل اختلاف، مذاکره و تسهیلگری برخی از موارد نسبتا بدیهی هستند، ولی مسئولیت مدیر پروژه به این موارد محدود نمیشود.
یکی دیگر از مسئولیتهای مدیر پروژه این است که فضای مناسبی برای رشد حرفهای اعضای تیم فراهم کند. بله، مدیر پروژه در این باره مسئول است. این یکی از جنبههای اخلاق و رفتار حرفهایست. برای اطلاعات بیشتر میتوانید به این منابع مراجعه کنید:
خلاصه اینکه از اعضای تیم پروژه و منابعی که در اختیار پروژه گذاشته شده است مراقبت کنید. امانتدار و قابلاعتماد باشید و الزامات و قوانین را تا جایی که خلاف اخلاق نباشند پاس دارید.
نکته پایانی این است که برای انجام همه این موارد باید شنونده خوبی باشید. برای پاسخ دادن گوش نکنید، بلکه برای فهمیدن گوش کنید. منتظر نمانید که برای گفتگو به شما رجوع کنند، بلکه برایش پیشقدم شوید تا هر دشواری یا کمبودی را در زودترین زمان و پیش از آنکه پیچیدهتر شود حل کنید.
کیفیت محصول و شیوه ساخت آن را بهکوتاهی بررسی کردیم. عنصر دیگری که باید در مدیریت کیفیت مد نظر باشد، کیفیت سیستم مدیریت پروژه است. بله، این مسئله حتی دربرگیرنده کیفیت سیستم مدیریت کیفیت هم میشود!
نمونه خوبی از مدیریت کیفیت مدیریت پروژه در P3.express همتاداوری (peer review) دورهایست. در آغاز هر ماه، پس از اینکه برنامههای کلان بازبینی و برنامه تفصیلی ماه پیش رو آماده شود، مدیر پروژه باید از یکی دیگر از مدیر پروژههایی که در سازمان وجود دارد درخواست همتاداوری کند. مدیر پروژه دوم زمانی را صرف میکند و همراه هم کارهای انجام شده را بررسی میکنند تا اگر مشکلی وجود داشت کشف شود. پیشنهاد P3.express این است که در صورت امکان هر ماه از فرد تازهای برای همتاداوری دعوت کنید.
یکی از امتیازهای همتاداوری کشف زودهنگام مشکلهای احتمالیست، ولی افزون بر آن، در طی این فرآیند هر دو فرد از یکدیگر نکتههای جالبی میآموزند. این فرصت طلایی را به هیچ وجه نباید از دست بدهید. پیشنهاد میکنم که به هر متدولوژیای که دارید همتاداوری هم بیفزایید.
یکی از دو موضوع مدیریت کیفیت، محصول و شیوه ساخت آن است که موضوعی فنیست وابسته به نوع محصول؛ برای نمونه:
پروژههای نرمافزاری آزمایشهای خودکار و دستی فراوانی دارند که مطمئن شوند نرمافزاری که در اختیار کاربر قرار میگیرد کارکرد درستی خواهد داشت. در کنار آن میتوان از روشی مانند pair programming نیز برای بهبود کیفیت بهره برد. در این روش هرروز اعضای تیم به گروههای دونفره تقسیم میشوند. هر گروه روی قابلیتی کار میکند؛ یکی از آن دو نفر برنامهنویسی میکند و نفر دیگر نظارهگر است و در هنگام کار پیشنهادهایی میدهد. هر نیم ساعت تا یک ساعت این دو نفر جایشان را با یکدیگر عوض میکنند.
در پروژههای ساختی که بتنی باشند روشهای آزمایش مخرب و نامخرب گوناگونی برای بتن وجود دارد، ولی افزون بر آن آییننامهها و استانداردهایی هم درباره نوع شن و آب، نگهداری سیمان، شیوه مخلوط کردن مواد، شیوه نگهداری از بتن پس از بتنریزی و همانند آن وجود دارد که رعایتشان احتمال رخداد مشکل را کمتر میکند.
به عنوان مدیر پروژهای که الزاما فنی هم نیست چگونه میتوانید از این جنبههای فنی اطلاع داشته باشید؟
مانند همیشه، نیازی نیست که شخصا همه این موارد را بشناسید، بلکه باید از تیم متخصصی که در کنار خود دارید کمک بگیرید. آنچه برای شما لازم است این است که مطمئن باشید روند مدیریت کیفیت فنی بهخوبی شناسایی، مستند، و اجرا …
همانگونه که گفته شد، بهتر است روندی برای تیم پروژه وجود داشته باشد که بهجای کار روی انبوهی از تحویلشدنیها، روی شمار اندکی کار کرده، آنها را به سرانجام برساند. بهتر است مدیر پروژه کارهای پایان یافته را بررسی و تایید نیز بکند.
تایید تحویلشدنیها بر پایه گستره و کیفیت آنهاست. باید پیش از آغاز به کار روی تحویلشدنیها از نیروهای فنی پروژه کمک بگیرید و گستره و کیفیت تحویلشدنیها را بر پایه الزامات و نیازهای ذینفعان تعیین کنید. پس از اینکه کار به پایان رسد، بر پایه همان تعریف نخستینی که به کمک اعضای تیم شده بود کارشان را بررسی خواهید کرد. این بررسی به مفهوم نظارتی از بالا به پایین و با هدف خردهگیری نیست، بلکه کمکی دوستانه است از سوی فردی که شاید حتی فنی هم نباشد تا با نگاهی تازه، کمی دورتر از کار به آن بنگرد و تفاوت احتمالی آن را با آنچه افراد فنی در نظر داشتهاند بسنجد و کمبودهای احتمالی را مشخص کند.
جلوگیری از بروز دشواریهای بنیادین در زمان تحویل نهایی، افزایش بهرهوری کار با محدود کردن کارهای موازی، و بسیاری دیگر از عناصر مفید پروژه مستلزم تعیین گستره و کیفیت تحویلشدنیها پیش از ساخت است. پرینس۲ برای این کار سندی به نام شرح محصول دارد («محصول» در اینجا به معنی تحویلشدنی است) و P3.express این مشخصات را به شکل یادداشت در نقشه تحویلشدنیها لحاظ میکند. متدولوژی خود را بررسی …
پس از ارزیابی وضعیت پروژه، باید نتیجه را به برخی از ذینفعان گزارش کنید. اعضای تیم باید از وضعیت پروژه آگاه باشند تا بتوانند کار خود را بر آن پایه اصلاح کنند. برخی لایههای مدیریتی سازمان هم باید از وضعیت پروژه باخبر باشند. اگر کارفرمایی بیرون سازمان داشته باشید هم بیگمان از شما انتظار گزارش خواهد داشت.
در بیشتر مواقع نمیتوان با فقط یک نوع گزارش با همه ذینفعان ارتباط مناسب برقرار کرد. برخی نیاز به اطلاعات فنی و برخی مدیریتی دارند. برخی نیاز به اطلاعات تفصیلی دارند و برخی کلان. چند نوع گزارش که برای پاسخگویی به همه نیازها کافی باشد طراحی کنید و در فهرست ذینفعان هم مشخص کنید که هر فرد قرار است چه نوع گزارشی دریافت کند. پس از فرستادن گزارش، با ذینفعان گفتگو کرده، کارآمدی گزارش را ارزیابی کنید. باید دایما به دنبال یافتن راههایی برای بهبود گزارشهای خود باشید.
ذینفعان به درجههای مختلفی گرفتار هستند و بسیاری از آنها صبر و حوصله ندارند. از این رو، گزارشهای خلاصه و سرراست کارآمدتر هستند. برخی از ذینفعانتان پافشاری خواهند کرد که گزارشهای تفصیلی برایشان بفرستید، ولی حتی در آن حالت هم گزارشی تکصفحهای به آن پیوست کنید، زیرا هنگامی که گزارش تفصیلی درخواست میکنند بیشتر از این روست که مطمئن باشند زیرساخت و توانایی کافی را برای ارزیابی پروژه دارید، ولی طولانی بودن گزارش باعث میشود …
تمرکز اصلی PMI بر برگزاری کنفرانسهایی بود که دستاندرکاران را گرد هم میآورد. این سنت همچنان ادامه دارد و در هر شهر یا کشوری که شعبهای از PMI وجود داشته باشد معمولا یک کنفرانس بزرگ سالانه و چند کنفرانس کوچک محلی برگزار میشود.
مدتی پس از بنیانگذاری PMI، ایده راهاندازی گواهیای برای مدیریت پروژه شکل گرفت. این گواهی، با نام Project Management Professional (حرفهای در مدیریت پروژه)، که کوتاهشده PMP نامیده میشود، در ۱۹۸۴ شکل گرفت. گواهی بهسرعت محبوبیت فراوانی پیدا کرد و همچنان یکی از مطرحترین گواهیهای مدیریت پروژه جهان به شمار میرود.