پروفایل برنامه‌ریزی و کنترل پروژه
نادر خرمی راد

ساختار تیم

ساختار تیم DSDM بسیار جالب، ولی پیچیده است:

  • سطح پروژه: نقش‌هایی که بر جنبه‌های کلان پروژه و یکپارچگی آن متمرکز هستند در این سطح قرار دارند.
    • حامی کسب و کار: این فرد مدیری ارشد است که مسئولیت‌هایی مانند اطمینان داشتن از توجیه‌پذیری پروژه و فراهم کردن منابع مالی را بر دوش دارد.
    • ایده‌پرداز کسب و کار: این فرد نیازهای کسب و کار را برای سطح پروژه تفسیر می‌کند.
    • مدیر پروژه: این فرد مسئول مدیریت روزمره پروژه است.
    • هماهنگ‌کننده مسایل فنی: این فرد با تیم‌ها در تماس است و به آن‌ها کمک می‌کند که معماری‌ سازگار و کارآمدی داشته باشند.
  • سطح تیم: در این سطح چندین تیم اجرایی وجود دارد که ساخت محصول را بر دوش دارند.
    • رهبر تیم: این فرد رهبری و هماهنگی‌های تیم را بر دوش دارد و با مدیر پروژه در تماس است.
    • سفیر کسب و کار: این فرد جنبه‌های کسب و کار محصول را برای اعضای تیم تفسیر می‌کند و با ایده‌پرداز کسب و کار در تماس است.
    • توسعه‌دهندگان: این افراد محصول پروژه را می‌سازند.
    • آزمایش‌کننده محصول: این افراد مسئولیت آزمایش محصول و کنترل کیفیت آن را بر دوش دارند.
  • سطح پشتیبانی: در این سطح نقش‌هایی وجود دارند که به همه تیم‌ها خدمات می‌دهند.
    • مشاور فنی: این افراد درباره مسایل فنی ویژه (برای نمونه، امنیت نرم‌افزار) به تیم‌ها مشاوره می‌دهند.
    • مشاور کسب و کار: این افراد درباره مسایل ویژه در کسب و کار (برای نمونه، …

سلسله‌مراتب تحویل‌شدنی‌ها

تحویل‌شدنی‌های بسیاری از پروژه‌ها به اندازه‌ای پرشمارند که اگر در فهرستی ساده و تک‌سطحی قرار داده شوند فهرست آنقدر بلند می‌شود که قابل استفاده نخواهد بود. راهکار معمول در چنین مواقعی، دسته‌بندی کردن آیتم‌های فهرست است و برای تحویل‌شدنی‌ها نیز می‌توان چنین کاری کرد. به‌جای یک سطح دسته‌بندی هم می‌توانید چندین سطح داشت که اصلاحا سلسله‌مراتبی نامیده می‌شود.

بسیاری از متدولوژی‌های مدیریت پروژه استفاده از دسته‌بندی‌های سلسله مراتبی را پیشنهاد می‌کنند. در چنین دسته‌بندی‌هایی محصول اصلی پروژه به چند تحویل‌شدنی کلان تقسیم می‌شود، هرکدام از آن‌ها به چند تحویل‌شدنی کوچک‌تر و روند به همین ترتیب ادامه پیدا می‌کند تا به جزئی‌ترین تحویل‌شدنی‌ها برسیم.

این دسته‌بندی‌های سلسله‌مراتبی نام‌های مختلفی دارند:

  • بیشتر منابع: ساختار شکست کار (work breakdown structure)
  • پرینس۲: ساختار شکست محصول (product breakdown structure)
  • P3.express: نقشه تحویل‌شدنی‌ها (deliverables map)

به‌کارگیری چنین ساختارهایی بسیار کارآمد است، ولی بازهم باید توجه داشته باشید که لیست‌های تک سطحی برای پروژه‌های بسیار کوچک کافی و مناسب‌تر هستند. از این رو، در متدولوژی micro.P3.express، که نسخه ویژه‌ای از P3.express برای پروژه‌های بسیار کوچک است، وجود نقشه تحویل‌شدنی‌ها الزامی نیست.

شمار تحویل‌شدنی‌های نیمه‌کاره

در هر زمان شماری تحویل‌شدنی نیمه‌کاره در پروژه وجود دارد. برخی پروژه‌ها حساسیتی به خرج نمی‌دهند و تحویل‌شدنی‌های پرشماری را به‌موازت هم پیش می‌برند که باعث افت بهره‌وری کلی پروژه می‌شود.

محدود کردن کار نیمه‌کاره یکی از اصل‌های زیربنایی در تولید Lean است، که تاثیر بزرگی هم در پروژه‌های چابک گذاشته است. با این‌همه، کاربرد آن محدود به پروژه‌های چابک نیست و در همه پروژه‌ها باید به آن توجه داشت.

یکی از مسایل اصلی درباره افزایش بیش از اندازه شمار کارهای موازی این است که وقتی چنین فرهنگی در پروژه وجود داشته باشد، هرگاه اعضای تیم در ساخت تحویل‌شدنی‌ای به دشواری بر بخورند به‌جای گره‌گشایی به سراغ انجام تحویل‌شدنی دیگری می‌روند که خروجی کارشان به ظاهر بالاتر باشد. هرچه بیشتر از زمان بروز دشواری بگذرد، حلش سخت‌تر می‌شود و از این رو چنین روندی مناسب نیست. همیشه به یاد داشته باشید که هدف زودتر آغاز کردن کارها نیست، بلکه زودتر به پایان رساندن آن‌هاست.

برخی از متدولوژی‌ها عناصری دارند که تیم پروژه را تشویق می‌کند که تحویل‌شدنی‌های نیمه‌کاره را به سرانجام برسانند و پس از آن دست به کار تحویل‌شدنی‌های تازه بشوند. چنین عنصری را می‌توان به روندی ضمنی برای دریافت تایید نیز متصل کرد که خود مانع بروز بسیاری از دشواری‌های زمان تحویل نهایی می‌شود و در بخش گذشته بررسی شد. اگر متدولوژیتان چنین جنبه‌ای را …

شناسایی

گاهی شناسایی ذی‌نفعان کار ساده‌ای نیست. نمونه‌اش پناهگاه کوهستانیست که پیش از این طرح شده بود.

باید در آغاز کار زمان کافی صرف شناسایی ذی‌نفعان کلیدی کرد، زیرا برخی از ذی‌نفعان، مانند قانون‌گذاران، چنان تاثیرهای کلانی بر پروژه می‌گذارند که ممکن است توجیه‌پذیری آن را از بین ببرند. اگر این ذی‌نفعان در آغاز کار شناسایی شوند، شاید متوجه شوید که بهتر است زمان و هزینه‌ای صرف پروژه نشده، لغو شود.

گذشته از شناسایی نخستین، باید دایما در هنگام اجرای پروژه نیز به فکر شناسایی ذی‌نفعان تازه باشید، زیرا

  • شاید برخی از ذی‌نفعان را از قلم انداخته باشید، و
  • شاید تغییرهایی در محیط پروژه به وجود آمده، ذی‌نفعان تازه‌ای به وجود آورده باشد.

مانند بسیاری دیگر از حوزه‌های مدیریت پروژه، بهتر است به اسناد پروژه‌های همانند که در گذشته اجرا کرده‌اید نیز مراجعه کنید تا ببینید چه کسانی بر آن اثر گذاشته‌اند. اینگونه می‌توانید ذی‌نفعان بیشتری شناسایی کنید که شاید بدون آن از قلم بیفتند. این مسئله یکی از دلایل فراوانیست که بر لزوم مستندسازی و بایگانی مناسب اسناد پروژه‌ها پافشاری می‌کنیم.

متدولوژی خود را بررسی کنید تا ببینید که روندی که برای شناسایی ذی‌نفعان دارد برای شرایط پروژه‌تان مناسب است یا نه، و اگر لازم است، فعالیت‌های ساخت‌یافته‌تری برای این منظور به آن بیفزایید.

شناسایی ریسک‌ها

نخستین گام مدیریت ریسک، شناسایی ریسک‌هاست. باید در آغاز پروژه کارگاه‌هایی برگزار کرد و با کمک اعضای تیم پروژه به عدم‌قطعیت‌ها اندیشید. با این همه، هرچه هم که در آغاز کار زمان صرف شناسایی ریسک‌ها کنیم، باز هم مواردی شناسایی نشده باقی می‌مانند و فقط هنگامی که به آن‌ها نزدیک‌تر شویم از آن‌ها آگاه می‌شویم. گاهی هم ریسک‌های تازه‌ای به دلیل تغییر شرایط محیطی به وجود می‌آیند. از این رو، لازم است که روند شناسایی ریسک‌ها دایما تکرار شود.

یک راه خوب این است که بخش کوچکی برای شناسایی ریسک‌های تازه به انتهای بیشتر جلسه‌ها و کارگاه‌ها بیفزایید.

فرآیند

در P3.express مجموعه فعالیت‌هایی برای آغازش پروژه و پایان پروژه وجود دارد. در میان این دو، چرخه‌هایی ماهانه برای انجام کار پروژه وجود دارد، با گروه فعالیت‌هایی برای آغازش ماهانه و پایان ماهانه. درون چرخه‌های ماهانه نیز فعالیت‌هایی برای مدیریت هفتگی و مدیریت روزانه وجود دارد. پس از پایان پروژه شماری فعالیت مدیریت پساپروژه برای ارزیابی منافع پروژه و طراحی اقدام‌های تازه وجود دارد.

برای آغازش پروژه باید اعضای کلیدی تیم منصوب و به کمک آن‌ها برنامه‌ای کلان آماده شود. برنامه برای حامی پروژه فرستاده می‌شود تا درباره اجرا کردن یا نکردن پروژه تصمیم بگیرد.

ترجیح بر این است که برنامه نخستین کلان باشد و سپس در هر آغازش ماهانه بازبینی شده، برای ماه پیش رو تفصیلی شود. اطلاعات بازبینی و تفصیلی شده در پایان آغازش ماهانه برای حامی پروژه فرستاده می‌شوند تا درباره ادامه دادن یا متوقف کردن پروژه تصمیم بگیرد.

در طول ماه بر روی محصول پروژه کار می‌کنیم و هر هفته پیشرفت آن را ارزیابی کرده، به انحراف‌ها واکنش نشان می‌دهیم. فعالیت‌هایی روزانه نیز برای تایید تحویل‌شدنی‌های کامل شده و پیگیری اقلام قابل‌پیگیری (ریسک‌ها، مسایل، درخواست‌های تغییر، برنامه‌های بهبود، و درس آموخته‌ها) وجود دارد.

در زمان پایان ماهانه، رضایت ذی‌نفعان را ارزیابی کرده، بر آن پایه برنامه‌هایی برای بهبود پروژه در ماه بعد طراحی می‌کنیم. …

فرآیند

وقتی ایده پروژه‌ای شکل می‌گیرد و به نظر جالب می‌رسد و پیش از آن‌که تصمیم نهایی درباره آن گرفته شود، فرآیند راه‌اندازی پروژه اجرا می‌شود. در این فرآیند برخی اعضای کلیدی تیم منصوب می‌شوند و همراه هم اطلاعاتی کلان گردآوری می‌کنند که در پایان در سندی با نام خلاصه پروژه (project brief) ذخیره خواهند شد. این سند اطلاعاتی تقریبی درباره توجیه‌پذیری پروژه و شیوه اجرای مناسب آن دارد.

مدیر ارشد و سایر افراد تصمیم‌گیرنده بر پایه اطلاعات گردآوری شده تصمیم می‌گیرند که پروژه ارزش بررسی دقیق‌تر دارد یا خیر. اگر داشته باشد، فرآیند آغازش پروژه اجرا می‌شود.

در آغازش پروژه برنامه کلان آماده می‌شود و بر آن پایه می‌توان توجیه‌پذیری پروژه را با اطمینان بیشتر برآورد کرد. این اطلاعات در سندی با نام سند آغازش پروژه (project initiation documentation) ذخیره می‌شود. این سند نیز در اختیار مدیر ارشد و سایر تصمیم‌گیرندگان گذاشته می‌شود که تصمیم نهایی را برای آغاز کردن یا نکردن کار اجرایی پروژه بگیرند.

همان‌گونه که می‌بینید، پروژه در دو مرحله ارزیابی می‌شود. در مرحله نخست به‌سرعت و با صرف توان محدود آن را بررسی می‌کنیم تا پروژه‌هایی که اصلا توجیه‌پذیر نیستند حذف شوند. در مرحله دوم، با صرف زمان و انرژی بیشتر، پروژه را به دقت بررسی می‌کنیم و بر آن پایه تصمیم نهایی را می‌گیریم.

پروژه‌ها در پرینس۲ مرحله به مرحله انجام …