بخشی از مقاله
بررسی مدل های بالندگی در مدیریت پروژه و شناسایی خطوط راهنما جهت انتخاب
چکیده
در سال های اخیر گرایش به سوی مدل های بالندگی مدیریت پروژه افزایش روز افزونی یافته است. از سال ۱۹۸۶، که CMM منتشر شد، تاکنون بیش از ۴۰ مدل و استاندارد با رویکردها و دامنه های کاربرد مختلف منتشر شده اند. تعدادی از این مدل ها در قالب پروژه های تحقیقاتی کوتاه مدت بوده و برخی نیز توسط شرکت ها و سازمان های معتبر در زمینه مدیریت پروژه انتشار یافته اند. در این میان تعدادی از این مدل ها وجود دارند که دارای محبوبیت و مقبولیت بیشتری نزد جامعه مدیریت پروژه می باشند. تعاریف مختلف از بالندگی سازمانی و پروژه موفق موجب شده است که سازمان هایی که قصد دارند از مدل های بالندگی مدیریت پروژه در راستای تعالی خود استفاده نمایند، در انتخاب مدل مطلوبی که بتواند بیشترین سازگاری را با ساختار سازمان داشته و اثربخشی مورد انتظار را فراهم نماید، دچار چالش گردند. در نظر گرفتن ویژگی های مشترک مدل های بالندگی، امکان طبقه بندی آنها را در شاخه های مختلف فراهم می آورد و تاحدودی خطوط اولیه را جهت انتخاب مدل مطلوب سازمان ترسیم می کند. در این مقاله سعی شده است تا با بیان مفاهیم بنیادین مدل های بالندگی و بررسی اجمالی ویژگی های آنها، با طبقه بندی انواع مدل های بالندگی از یک سو و بررسی نقاط قوت و ضعف تعدادی از معتبرترین آنها، خطوط اولیه راهنما را برای سازمان ها و شرکت هایی که می خواهند از مدل های بالندگی مدیریت پروژه در راستای ایجاد! بهبود تعالی سازمانی خود استفاده نماید، ترسیم گردد.
اگر مقهوم بالندگی (بلوغ) برای یک سازمان به کار برده شود در حقیقت به حالتی اشاره می کند که سازمان در یک شرایط کامل برای دستیابی به اهدافش است. بنابرین بلوغ در مدیریت پروژه به این معنی است که سازمان به طور کامل شرایط اجرای پروژه هایش را دارد. از آنجا که در دنیای واقعی هیچ سازمانی یافت نمی شود که به طور کامل به بلوغ دست یابد، ضروری است تا از ابزارهایی برای اندازه گیری میزان دستیابی یک سازمان به بلوغ و درجه اطمینان آن استفاده گردد. مدل های بالندگی این ابزار را در اختیار سازمان ها قرار می دهند. یک مدل بلوغ، چارچوبی مفهومی با اجزای سازنده آن است که بلوغ را در ناحیه مورد نظر که در این جا، مدیریت پروژه سازمانی است، تعریف می کند. در برخی از موارد، یک مدل بلوغ ممکن است فرآیندی را نیز توصیف کند که به وسیله آن سازمان می تواند چیزهای مطلوبی نیز نظیر مجموعه ای از توانمندی ها یا راهکارها را ایجاد کرده یا به دست آورد. این فرایند می تواند به یک وضعیت سازمانی تکامل یافته تر منجر شود، به عبارت دیگر، یک سازمان بالغ تر، تقریبا همه مدل های بلوغ از یک نردبان پیشرفت استفاده می کنند. نردبان پیشرفت این منطق را دنبال می کند که بلوغ در زمان ایجاد می شود و می توان آن را از طریق موقعیت ها و مراحل اصلی تشخیص داد.
نکته: با توجه به اینکه در متون مختلف ترجمه های متفاوتی از واژه Mature به فارسی انجام شده، در این مقاله از هر دو برگردان متداول آن یعنی بالندگی و بلوغ استفاده شده است. لذا در کل متن می توان آنها را به جای یکدیگر به کار برد و هر دو ترجمه شده واژه Mature می باشند.
بلوغ در مديريت پروژه
فیلد مدیریت پروژه، تمرکزش را از مطالعه بر روی یک پروژه به راهی که یک شرکت یا سازمان از پروژه ها برای به دست آوردن اهدافش استفاده می کند، گسترش داده است. گاریس خیلی وقت پیش، مفهوم سازمان پروژه محور را اختراع نمود. آینده مخصوص اینچنین سازمانی است که مدیریت فردی پروژه ها، مدیریت شبکه داخلی و خارجی پروژه ها و روابط بین سازمان و پروژه های فردی را مورد توجه قرار می دهد. پروژه های امروزی خیلی فراتر از حل مشکلات تکنیکی به نظر می رسند. همچنین آنها سرآغازی هستند برای تسلط بر کسب و کار و تغییرات. عبارت بلوغ پروژه می تواند به عنوان یک شاخص برای سنجش توانمندی یک سازمان در استفاده از پروژه ها برای اهداف مختلف باشد. در فرهنگ های لغت آکسفورد و وبستر واژه بلوغ به معنای رسیدن یا دستیابی به حالت تکامل طبیعی و یا حداکثر توسعه آمده است. مفهوم فرایند بلوغ در حرکت مدیریت کیفیت فراگیر متولد شد. جایی که کاربرد تکنیک های کنترل فرآیند آماری نشان داد که بهبود بلوغ هر فرآیند تکنیکی به دو چیز منجر خواهد شد: یکی کاهش در تغییر پذیری ذاتی فرآیند و دیگری بهبود در میانگین کارایی فرآیند. گسترش این مفهوم به اندازه گیری سازمانی فرایند بلوغ خواهد انجامید. اگر مفهوم بلوغ برای یک سازمان به کار برده شود در حقیقت به حالتی اشاره می کند که سازمان در یک شرایط کامل برای دستیابی به اهدافش است. بنابرین بلوغ در مدیریت پروژه به این معنی است که سازمان به طور کامل شرایط اجرای پروژه هایش را دارد. از آنجا که در دنیای واقعی هیچ سازمانی یافت نمی شود که به طور کامل به بلوغ دست یابد، ضروری است تا از ابزارهایی برای اندازه گیری میزان دستیابی یک سازمان به بلوغ و درجه اطمینان ان استفاده گردد.
ویژگی های کلی مدل های بالندگی
علی رغم تفاوت های آشکار مدل های بالندگی، ویژگی های مشترکی در همه آنها وجود دارد که می تواند در دو بخش بیان گردند:
الف- استفاده از مدل های بالندگی مزایای زیر را در پی خواهد داشت
• مدیریت موثر کلیه پروژه هایی که سازمان متقبل شده است
بهبود مستمر کارایی کلیه پروژه هایی که سازمان متقبل شده است
• بهبود گفتمان میان جامعه مدیریت پروژه و مدیریت ارشد سازمان
• تعیین فرایندهای مدیریت پروژه به صورت استاندارد
• تعیین دقیق و روشن نقش ها و مسوولیت ها در قبال فعالیت های پروژه
• استفاده از درس های آموخته قبلی و امکان بازبینی در کارایی پروژه
• پیشبرد اهداف استراتژیک سازمان از طریق به کارگیری ابزارهای و شیوه های مدیریت پروژه
ب- در استفاده از مدل های بالندگی چالش های زیر می بایست مدنظر قرار گیرد:
• یک تعریف توافقی عمومی از اینکه یک سازمان بالغ پروژه محور چگونه است، وجود ندارد. مدل های بلوغ مختلف نشانگر تفاوت های مفهومی و همچنین تفاوت های سلیقه ای در سیر بلوغ هستند.
• کل زمینه مطالعات بلوغ، همانند یک میدان مین معنایی می باشد و واژگان اصلی ان دارای معانی تکنیکی مخصوصی می باشند که تفاوت انها با فضای نرمال گفتار عمومی، بسیار زیاد می باشد.
• مفهوم پروژه موفق، پیچیده تر می باشد و اگرچه در اینجا برخی توافقات عمومی در خصوص آن وجود دارد ولی در سایر مشخصه های آن، یک عدم توافق گسترده به چشم می خورد.
• هم شاخص ها و هم مدل های بلوغ بر روی یک تئوری تلویحی از پروژه بنا بنهاد شده اند که ممکن است در همه جا قابل به کارگیری نباشد. با توجه به موارد مذکور، انتخاب مدل بالندگی مطلوب در مدیریت پروژه، نیازمند خطوط راهنمایی می باشد که هر سازمان بتواند با استفاده از آنها، سیستم ارزیابی بالندگی سازمانی خود را انتخاب نماید. پیش از ان بهتر است به معرفی ۵ مدل معروف از مدل های بالندگی مدیریت پروژه پرداخته شود.
مدل CMM
. اولین مدل بلوغ در مدیریت پروژه، مدل CMM می باشد و بسیاری از مدل های بلوغ آتی بر اساس اصول CMM پایه ریزی شده اند. CMM یا مدل تکامل قابلیت ها برای نرمافزار، اصول و برنامه هایی را توصیف می کند که زیربنای تکامل و توسعه نرمافزارهاست. این مدل روش های کنترل فرآیندها برای توسعه و نگهداری و همچنین بهبود فرهنگ مهندسی نرمافزار و مدیریت را فراهم می کند.
در نوامبر ۱۹۸۶ مؤسسه مهندسی نرم افزار (SEI) وابسته به دانشگاه کارنگی ملون با کمک شرکت مایتر توسعه چارچوب تکامل فرآیندها را آغاز کردند. این اقدام در پاسخ به درخواست دولت فدرال برای تعیین میزان تکامل فرآیندهای نرمافزاری، آغاز شد. در سپتامبر ۱۹۸۷ مؤسسه SEI خلاصهای از چارچوب تکامل فرآیندها را منتشر کرد و بعد از چهار سال استفاده آزمایشی از چارچوب تکامل فرآیندهای نرمافزاری و نسخه اولیه پرسشنامه تکامل، در سال ۱۹۹۱ SET مدل تکامل قابلیت برای نرمافزار (CMM) را تدوین نمود. 1.0 CMMV در سالهای ۱۹۹۱ و ۱۹۹۲ مورد استفاده و بازبینی قرار گرفت.
هدف از طراحی CMM تعیین میزان تکامل فرآیندهای موجود و مشخص کردن نکات اساسی کیفیت نرمافزار و بهبود فرآیندها برای سازمان های تولید کننده نرمافزار بود تا آنها را برای انتخاب راهبردهای بهبود فرآیندها یاری کند. ساختار مرحله بندی شده CMM متکی بر اصول کیفیت محصولات است که از ۶۰ سال قبل مورد استفاده بوده است. در حال حاضر اخرین نسخه منتشر شده از این سری
CMMI for Acquisition v1.2 . CMMI for Services v1.2.
می باشد که در سال 2007 منتشر شده اند .
الف - مراحل یا سطوح بالندگی در
CMM بهبود مستمر فرآیندها بهتر است به جای آنکه بر ابتکارات دگرگون ساز متکی باشد بر اقدامات کوچک و تدریجی بنا شود. CMM چارچوبی ارائه می دهد که این اقدامات تدریجی را به پنج سطح تکامل تقسیم می کند و این سطوح زیربنای بهبود مستمر فرآیندها خواهند بود. یک سطح تکامل، یک فاز تدریجی تعریف شده می باشد که برای دستیابی به تکامل فرآیند نرم افزاری طراحی شده است.
هر سطح به عنوان پایه ای برای رسیدن به سطح بالاتر می باشد. سازماندهی CMM به پنج سطح مطابق شکل ۱ اقدامات مورد نیاز برای افزایش تکامل فرایند نرمافزار را اولویتبندی می کند.
شکل ۱- سازمان دهی CMM برای افزایش تکامل فرآیند نرم افزار
سطح ابتدایی (سطح اول): در این سطح سازمان عموما محیط باثباتی برای توسعه و نگهداری نرمافزارها نیست. چنانچه مواقع بحرانی روندهای برنامهریزی شده کنار گذاشته می شوند و به مرحله برنامه نویسی و آزمون اکتفا میگردد در هر حال موفقیت پروژه تماماً به یک مدیریت استثنایی و یک تیم طراحی نرم افزار کارآمد و مؤثر بستگی دارد. حتی یک فرآیند قوی مهندسی و طراحی هم نمی تواند بر ناپایداری ناشی از مدیریت ضعیف، غلبه کند. تکامل فرآیند تولید نرمافزار در سازمانهای سطح ۱ غیرقابل پیش بینی است زیرا به تدریج که کار پیشرفت میکند، فرایند دائماً تغییر می کند یا اصلاح می شود. عملکرد، بستگی به ویژگیهای فردی مجریان پروژه دارد و با مهارتهای ذاتی، دانش و انگیزه آنها تغییر می کند.
سطح تکرار پذیر (سطح دوم): در این سطح خط مشی مدیریت پروژههای نرم افزاری و فرآیندهای اجرای این خط مشی ها مشخص شدهاند وبرنامه ریزی و مدیریت پروژههای جدید بر تجربیات حاصل .از پروژههای مشابه متکی می باشد. هدف از دستیابی به این سطح، رسمیت بخشیدن به فرآیندهای مدیریتی مؤثر برای پروژههای قبلی است (هرچند که فرایندهای استفاده قرار میگیرد. تکامل فرآیندهای نرم افزاری سازمان های سطح ۲ را می توان به طور خلاصه «ضابطه مند» نامید. زیرا طراحی و پیگیری پروژه نرمافزاری پایدار است و امکان تکرار موفقیت های قبلی وجود دارد.
• سطح تعریف شده (سطح سوم): در این سطح، فرآیند استاندارد توسعه و نگهداری نرم افزار، مشتمل بر فرآیندهای مهندسی و فرآیندهای مدیریتی، مستند می شوند و به صورت یک مجموعه هماهنگ در می آیند. فرآیندهای سطح ۳ به مدیران و کارکنان فنی کمک می کنند که کار خود را به صورت اثربخش تری اجرا کنند. در سازمان سطح ۳ گروهی (گروه فرآیندهای مهندسی نرمافزار) وجود دارد که مسئول فرایندهای نرمافزاری آن است. در این راستا برای حصول اطمینان از اینکه مدیران و کارکنان، دانش و مهارتهای لازم برای انجام وظایف خود را دارا باشند، یک برنامه آموزشی جامع در کل سازمان اجرا می شود. برای هر پروژه، استاندارد سازمان به گونهای اصلاح می شود که ویژگی های منحصر به فرد ان پروژه را شامل شود. در CMM به این فرآیند، فرآیند نرم افزاری تعریف شده برای پروژه میگویند. یک فرآیند نرم افزاری معین شامل مجموعه ای هماهنگ و یکپارچه از فرآیندهای مهندسی و مدیریتی، میباشد. تکامل فرآیند نرمافزاری در سازمان های سطح ۳ را می توان در رده استاندارد و هماهنگ قرار داد زیرا فعالیت های مهندسی و مدیریتی، پایدار و تکرار پذیر هستند. این قابلیت بر اساس فهم مشترک سازمانی از فعالیتها، وظایف و مسئولیتها در یک فرایند معین نرمافزاری بنا شده است.
• سطح مدیریت شده (سطح چهارم): در سطح مدیریت شده، سازمان اهداف کنی را برای فرایندها و محصولات نرم افزاری در نظر میگیرد. به عنوان بخشی از برنامه سنجش سازمانی، بهرهوری و کیفیت فرآیندهای مهم در تمام پروژهها اندازهگیری می شوند. در این سطح، فرآیندهای نرمافزاری با معیارهای هماهنگ و متناسب سنجیده می شوند. این اندازهگیری ها زیربنایی کمّی برای ارزیابی فرآیندها و محصولات پروژه فراهم می کند قابلیت فرآیندهای نرمافزاری برای سازمان های سطح ۴ را می توان به طور خلاصه، قابل پیشبینی نامید، زیرا فرایندها با معیارهای قابل اندازه گیری سنجیده می شوند. چنانچه اندازهگیریها تخطی از حدود مجاز را نشان دهد برای تصحیح عملکرد اقدام میشود.
• سطح بهینه سازی (سطح پنجم) در این سطح کل سازمان بر بهبود مستمر فعالیت ها متمرکز میشود. سازمان با هدف جلوگیری از وقوع نقص و اشکال در کارها امکان شناسایی و پیش بینی قوت و ضعف فرآیندها را دارد. از دادههای بدست آمده درباره اثربخشی فرایندهای نرم افزاری برای تحلیل هزینه - فایده فناوری های جدید و تغییرات احتمالی فرآیندها استفاده می شود. تیمهای انجام دهنده پروژهها در سازمانهای سطح ۵ نقائص را تحلیل می کنند تا علل آن را مشخص کنند. برای جلوگیری از تکرار نقائص شناخته شده، فرآیندها مورد ارزیابی قرار گرفته و درسهای آموخته شده در مورد سایر پروژه ها نیز به کار گرفته می شود.
ب - نحوه ارزیابی در CMM مدل CMM برای ارزیابی سازمان، هر سطح تکامل را به اجزاء تشکیل دهنده آن تقسیم کرده است. هر سطح تکامل از چند حوزه فرایند کلیدی تشکیل می شود. هر حوزه فرایند کلیدی به پنج بخش که ویژگی های عمومی نام دارند تقسیم می شود. ویژگی های عمومی، اقدامات کلیدی را که برای رسیدن به اهداف حوزه فرآیند کلیدی لازم است، مشخص می کند. سلسله مراتب این ساختار در شکل ۲ نشان
داده شده است. ارزیابی در CMM اساس چار چوب های تعیین ܚܶܝܠܬ توسط مدل صورت پذیرد. در واقع تشخیصں پوشش یک سطح بالندگی در سازمان توسط تیم ممیزی و بر اساس شاخص های کیفی تعیین شده توسط مدل صورت می پذیرد.
در جدول ۱، نحوه ارایه نتایج ارزیابی برای هر حوزه فرآیندی مشخص شده است.
سطح قابلیت فرایند
جدول ۱- نحوه ارایه نتایج ارزیابی برای هر حوزه فرآیندی
ب- نقاط قوت و ضعف
CMM به طور کلی نقاط قوت CMMI عبارتند از:
- دارای سطوح بلوغ مشخص و مسیر بلوغ
- بررسی وجود روش ها و رویکردهای ارزیابی توانمندی های کارکنان
- ساختار جامع و گسترده
- امکان ارزیابی مستمر
- ارایه راهکار برای بهبود
و شامل نقاط ضعف زیر نیز می گردد:
- عدم امکان استفاده برای کلیه حرفه ها (فقط پروژه های نرم افزاری)
- عدم ارتباط مستقیم با استانداردهای EFQM ISO و یا PMBOK که در ایران شناخته شده ترند.
- عدم امکان ارزیابی سازمان در هر یک از سطوح بلوغ به صورت مجزا
- عدم امکان بررسی همزمان توامندی ها و قابلیت ها و همچنین نقاط ضعف سازمان در سطوح مختلف
- عدم ارزیابی فرآیندهای مدیریت پورتفولیو
- دشوار بودن فرآیند ارزیابی و نیاز به تربیت کارشناسان ارزیابی بسیار ماهر و فرآیند آموزشی طولانی مدل
- عدم ارایه نتایج ارزیابی ها و میزان دستیابی به سطوح بلوغ به صورت کمی
مدل PMMM
مدل PMMM در سال ۲۰۰۱ و توسط شرکت OGC ارایه شد. این مدل بر مبنای ساختار مدل CMM ارایه شده است با این تفاوت که به نوعی استاندارد PMBOK را به عنوان بستر دانش خود در نظر گرفته است و در عین حال قابلیت کاربرد برای سایر حوزه های مدیریت پروژه را نیز دارا می باشد. همچنین در مدل PMMM برای ارزیابی هر یک از سطوح بلوغ یک پرسشنامه ارزیابی بلوغ و نیز جدول راهنمای مرتبط با آن نیز ارایه شده است که خود امکان ارزیابی کمی بلوغ در سازمان را امکان پذیر می سازد. مدل PMMM با تاکید ویژه بر مدیریت استراتژیک پروژه تدوین شده است و به نوعی می توان آن را پایه گذار برقراری ارتباط میان مفاهیم بلوغ مدیریت پروژه و مدیریت استراتژیک نامید که خود ناشی از اضافه شدن مفاهیم مدیریت پور تفولیو در این مدل می باشد. همچنین این مدل ارتباط بسیار نزدیکی با ساختار بلوغ مدیریت پروژه ارایه شده توسط هرولد کرزنر دارد. در حال حاضر آخرین نسخه ارایه شده از این مدل PMMMV5.0 می باشد که در سال ۲۰۰۲ ارایه شده است.
الف - مراحل یا سطوح بلوغ PMMM
• سطح اول (زبان مشترک): در این سطح، سازمان اهمیت مدیریت پروژه و نیاز به داشتن درکی خوب از دانش پایه در مدیریت پروژه و زبان / لغات فنی آن را در می یابد.
• سطح دوم (فرآیندهای مشترکا): در این سطح سازمان در می یابد که برای تکرار موفقیت های یک پروژه، در پروژه ای دیگر، نیازمند تعریف و توسعه فرآیندهای مشترک می باشد. از دیگر موارد موجود در این سطح، درک کاربرد و نیز حمایت اصول مدیریت پروژه سایر شیوه های به کار رفته توسط سازمان است.
سطح سوم (شیوه اجرایی واحد): در این سطح سازمان اثر ترکیب همه شیوه های بنگاه تبدیل آن ها به یک شیوه اجرایی واحد را تعیین می کند که در مرکز آن، مدیریت پروژه قرار دارد. اثرات هم افزایی، همچنین کنترل فرآیند را با وجود یک شیوه آسان تر می کند تا با وجود چند شیوه.
• سطح چهارم (سنجش): این سطح شامل درک ضرورت بهبود فرایند برای حفظ مزیت رقابتی است. سنجش باید به طور پیوسته انجام گیرد. سازمان باید تصمیم بگیرد که چه چیزی را و با چه کسی مقایسه نماید.
• سطح پنجم (بهبود مستمر: در این سطح سازمان اطلاعات به دست آمده از راه سنجش را ارزیابی کرده و سپس باید تصمیم بگیرد که آیا این اطلاعات شیوه اجرایی واحد را بهبود خواهد داد یا نه؟
