ترجمه تخصصی دستیابی به موفقیت در پروژه - مدیریت پروژه

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

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

مقالات ترجمه شده جدید مدیریت پروژه
 

 

هدف این مقاله، تحلیل پیش آیندهای «موفقیت مدیریت پروژه هزینه ای و زمانی» (CTPMS) توسعه سیستم های اطلاعات، با ملاحظه همزمانی این متغیرها در چندین سطح تحلیل (شبکه پورتفوی، پروژه، مدیر برنامه و سطح تیم)، می باشد. هدف، شناسایی شیوه های مدیریت پروژه است که بوسیله آنها یک سازمان می تواند شایستگی خود برای دستیابی به موفقیت پروژه های توسعه سیستم اطلاعات را بهبود بخشد. همچنین این مطالعه با بکار گیری داده های ثانویه به این رشته می افزاید و بنابراین کمبودهای بالقوه گرفتن نتیجه (نتیجه گیری) از داده های ادراکی را رفع می کند.

 

مقالات ترجمه شده جدید مدیریت پروژه
 

این پژوهش از داده هایی از یک ارائه دهنده خدمات مالی پیشرو که سالانه بیش از 3000 پروژه IS را توسعه می دهد، استفاده کرد. «صنعت خدمات مالی» (FSI) مسئول 13% (351 میلیارد دلار) سرمایه گذاری کلی جهان در زمینه IT می باشد. در برزیل، کشوری که از آن داده ها را گردآوری کردیم، این درصد حتی بیشتر است زیرا FSI مسئول 14% (6 میلیارد دلار) ازسرمایه گذاری کلی کشور در زمینه IT می باشد (دیلوئیت، 2017). فنآوری، به عنوان یکی از مولفه های عمده عملکرد این صنعت محسوب می شود که توجه بسزایی از جانب ارگان هایی که بر FSI نظارت دارند، می طلبد. برای مثال، «بانک مرکزی برزیل» ، بکار گیری شیوه های مدیریت پروژه خاص برای اطمینان یافتن از رفع ریسک موفق و محقق سازی مزیت های پروژه های IT را ملزم کرده است (ISACA، 2013؛ ترلیزی و همکاران، 2017).

باقی این مقاله به این صورت بخش بندی شده است. این مقاله ابتدا ادبیات مرتبط را در بخش 2 توصیف می کند. سپس روش ها را در بخش 3 توضیح می دهد. نتایج در بخش 4 ارائه شده اند و بعد از آن در بخش 5 بحث می آید. در آخر، یافته های خود در بخش 6 را با مشارکت های نظری، دلالت های عملی و محدودیت ها، نتیجه گیری می کنیم.

 

2.مروری بر مقالات

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

بخاطر اینکه دستیابی به موفقیت پروژه به عوامل بسیاری بستگی دارد، موفقیت یک پروژه را می توان با استفاده از شکل های مختلف ارزیابی نمود؛ هیچ بهترین روش اندازه گیری وجود ندارد (توماس و فرناندز، 2008). در واقع، این موضوع از دهه 1970 بحث گسترده ای بوجود آورده است که این بخاطر ابعاد و تفسیرهای مختلف آن است (ایکا، 2009). در این زمینه، تحلیل در زمینه مقالات انجام شده برای شفاف سازی تعدادی از تفاوت های بین موفقیت پروژه (PS) و موفقیت مدیریت پروژه (PMS) و شفاف سازی عوامل و جنبه های مختلف دخیل در IS PMS، لازم است.

 

2.1.

موفقیت پروژه و موفقیت مدیریت پروژه

حداقل یک اتفاق نظر در ادبیات در مورد PS، وجود دارد، و آن این است که موفقیت کلی را باید حول دو جنبه مختلف در نظر گرفت. از یک سو، PMS، مسئولیت مدیر پروژه در نظر گرفته می شود و به معنای تحویل بموقع خروجی های پروژه، در محدوده بودجه و ویژگی ها و کارکردهای لازمه، می باشد. در نتیجه، معمولاً براساس مثلث آهنی (زمان، بودجه و حیطه/کیفیت)، سنجش می شود. از سوی دیگر، PS را می توان به صورت مسئولیت مالک پروژه با پیش بینی مزیت های پروژه (برای مثال، مالی، کیفیتی، انعطاف پذیری و نوآوری) در نظر گرفت (بادوی، 2016؛ چیه و زویکائل، 2015؛ کوپر و ادجت، 1997؛ دوهرتی و همکاران، 2012؛ ترلیزی و همکاران، 2016؛ تشچ و همکاران، 2019؛ ترنر و مولر، 2005).

جالب اینکه، از جنبه ادبیات پروژه های IS، مفهوم PS به میزان هنگفتی به عنوان مترادف PMS بکار گرفته می شود، زیرا مثلث آهنی در تقریباً دو سوم از 26 مقاله مربوط به PS تحلیل شده از 1997 تا 2009، استفاده شده است (دی باکر و همکاران، 2010). به همین صورت، «گروه Standish» نیز بر موفقیت پروژه IT در سراسر جهان از سال 1994 با استفاده از مثلث آهنی به عنوان نشانه ای از موفقیت، نظارت کرده است؛  تنها در سال 2015، این مفهوم بهبود یافته است تا ابعاد دیگر موفقیت را مورد ملاحظه قرار دهد (هستی و ووجوودا، 2015).

برای شفاف سازی نحوه رفع این مسئله در ادبیات فعلی، یک مرور ادبی نظام مند از دو مجله مدیریت پروژه برتر از سال 2006 تا 2016 انجام دادیم تا مطالعه دی باکر و همکاران را تکمیل کنیم. این مرور ادبی، 31 مقاله را شناسایی کرد که یافته های اصلی آنها در جدول 1 ارائه شده است.

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

نیاز به مذاکره مداوم در مورد تغییرات اندک در حیطه حتی یک پدیده IT در زمینه شیوه های PM، یعنی رویکرد چابک برای پروژه ها، بوجود آورده است (سرادور و پینتو، 2015). این رویکرد را می توان به صورت یک روند جهت بهبود ارتباطات و تسهیل این تنظیمات اندک در حیطه، زمان و هزینه، در نظر گرفت (ماستروگیاکومو و همکاران، 2014).

علیرغم این دینامیک ها، ارزیابی PMS، از زمان معرفی مثلث آهنی، تقریباً یکسان و بدون تغییر باقی مانده است (لچ، 2013)، یعنی، بنظر می رسد که مولفه های حیطه، زمان و هزینه مستقل بوده اند. هنگام پرداختن به پروژه های سیستم های اطلاعات، بسیار ارزشمند خواهد بود اگر معیارهای جدید PMS برای ترکیب بهتر هزینه و زمان با توجه به یک موافقت در مورد حیطه، پیشنهاد شود (لچ، 2013).

جنبه دیگر این است که اگرچه بنظر می رسد موفقیت پروژه به چندین جنبه به هم مرتبط بستگی دارد، اما تنها تعداد اندکی از مطالعات از رویکرد چند سطحی برای تحلیل پیش آمدها در موفقیت پروژه، استفاده کرده اند. 20 مقاله یا 65% از مقاله های انتخاب شده، تنها یک سطح پیش آیند را تحلیل کرده اند. دریافته ایم که تعداد قابل توجهی مطالعه (14 مقاله -45%) به پیشآیند مدیر پروژه پرداخته اند و در رتبه های بعدی، جنبه پروژه (9 مقاله- 30%) و جنبه پروژه تیمی (7 مقاله- 22%) قرار دارند.

 

 

 

 

دریافتیم که این محدودیت، خلاء اساسی در ادبیات بوجود می آورد زیرا هیچ مقاله ای اثرات موفقیت را از جنبه ترکیب چندسطحی عوامل، تحلیل نکرده بود.

دوم اینکه، اکثریت داده های استفاده شده در این پژوهش تاکنون، فهمیده شده که براساس پرسشنامه (20 مقاله، 65%)، متغیر از 25 تا 1387 پاسخگر، گردآوری شده اند. روش های گردآوری دیگر عبارت بودند از مصاحبه (6 مقاله، 20%)، متغیر از 4 تا 108 مصاحبه شونده، مرور ادبی (3 مقاله، 10%) و در نهایت مستندسازی (2 مقاله، 5%) بوده اند. علاوه بر آن، از نظر پروفایل و مشخصات پاسخگران، این مطالعات اساساً ادراکات مدیران پروژه را مطالعه پیمایشی کرده بودند. هیچکدام از مطالعات از رکوردهای داده ثانویه واقعی استفاده نکرده بودند که این خلاء عمده دیگری در ادبیات است زیرا پاسخ های ادراکی ممکن است بطور بالقوه با خود سوگیری پاسخگر را داشته باشند. اگرچه همه منابع داده ها ممکن است مقداری جنبه مثبت در مطالعه نشان دهند، اما رکوردهای داده ای دقیقتر در نظر گرفته می شوند و در نتیجه تحلیل غیرادراکی را ممکن می سازند (این، 2013).

علاوه بر آن، نظریه پردازان مدیریت پروژه، اهمیت تجمیع مطالعات از صنایع مختلف سراسر جهان برای گسترش زمینه پژوهش را تشخیص می دهند (ترنر و لدویث، 2016). در دوره تحلیل شده، تنوع مطالعات ادبی از تعدادی منطقه جهان و بخش های مختلف را مشاهده کردیم، اما تنها چهار مطالعه مخصوصاً بر FSI تمرکز کرده بودند. این مشخص است که FSI بیشتر از هر بخش دیگر بر فنآوری سرمایه گذاری می کند و بنابراین انتظار می رود بر فنون مدیریت IS عالی، مسلط و مهارت داشته باشند (برگ اوت و همکاران، 2011؛ دی لوئیته، 2017). بنابراین، افزایش تمرکز بر این صنعت، مهم است.

 

2.2.موفقیت مدیریت پروژه- جنبه چند سطحی

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

مقالات ترجمه شده جدید مدیریت پروژه
 

از جنبه فنآوری اطلاعات، رویکرد چند سطحی، یک رویکرد جایگزین برای بررسی پدیده ها حاصل می کند که این با در نظر گرفتن همزمان ماهیت پدیده ای است که از طریق آن، مطالعه ما تعامل بین فنآوری ها و بازیگران انسانی را مورد بررسی قرار می دهد (آوبرت و همکاران، 2008). اما، مطالعاتی که پدیده IS را از جنبه چندسطحی ارزیابی کرده باشند، هنوز معدود و نادر باقی مانده اند (بلانجر و همکاران، 2014).

در پنج دهه گذشته، ادبیات مدیریت پروژه تلاش کرده است شرایطی که باعث رسیدن به یک پروژه موفق از یک جنبه چندسطحی را ترسیم می کنند، را سعی کرده است (بندولی و همکاران، 2010؛ شنهار و لوی، 1997؛ تاتیکوندا و روزنتال، 2000)؛ با اینحال، تعداد اندکی مطالعه، رویکرد همزمان را به عنوان یک تحلیل مناسب برای PMS در نظر گرفته اند. برای مثال، وسعت استفاده از شیوه های مدیریت ریسک، مانند شناسایی ریسک، تحلیل ریسک احتمالالتی، برنامه ریزی عدم قطعیت، تحلیل تعادل (بده بستان) و رابطه آنها با ابعاد موفقیت پروژه مختلف، توسط راز و همکاران (2002) بررسی شده است. این مطالعه براساس داده های گردآوری شده براساس 100 پروژه انجام شده در اسرائیل بود و نشان داد که مدیریت ریسک، هنگام استفاده می تواند در موفقیت پروژه مشارکت داشته باشد و اثرش عمدتاً بر برآورده کردن بهتر اهداف زمانی و بودجه ای است نه موفقیت عملکردی و مشخصاتی محصول. به صورتی دیگر، تاتیکوندا و روزنتال (2000)، رابطه بین مشخصات پروژه توسعه محصول (فنآوری، نوآوری و پیامدهای پروژه) را با این فرض بررسی کردند که مشخصات نوآور بودن پروژه و پچیدگی پروژه در عدم قطعیت انجام پروژه مشارکت دارند و در نتیجه پیامدهای اجرای پروژه را تعریف می کنند. نتایج آشکار کردند که سطوح پروژه بالاتر پیچیدگی پروژه یا نوآوری فنی به شکست کلی پروژه ارتباط ندارند.

برعکس، در مقاله بندولی و همکاران (2010)، داده های گردآروی شده برای چندین سطوح تحلیل به درک به هم وابستگی های چندسطحی در محیط مدیریت پروژه از جنبه عوامل اجتماعی، کمک کرده است. نویسندگان نقش رفتار فرد در هدایت دینامیک ها و عملکرد پروژه را تحلیل کردند و دیدگاه های بسیار مهم در مورد تصمیمات گرفته شده توسط هر دوی اعضای تیم پروژه و مدیران پروژه، فراهم کردند. در همین راستا، لوفرانی-فدیدا و میسونیر (2015) ایده مدیر پروژه «ایده آل» را مطرح می کنند و بر شایستگی های اساسی (کارکردی و تجمیعی) مبتنی بر سطوح فردی، جمعی و سازمانی، تمرکز می کنند.

علیرغم تلاش های محیط های آکادمیک و اجرایی، نرخ موفقیت در پروژه ها، پایین باقی مانده است. اگرچه عوامل عمومی مرتبط با شکست پروژه قبلاً شناسایی شده اند (PMI، 2017)، اما بندرت با همدیگر و مرتبط با هم، مورد مطالعه قرار گرفته اند. در این مطالعه، عناصر موثر بر PMS در سازمان ها را به چهار سطح تقسیم بندی می کنیم: اولی، اثرات سطح شبکه پورتفوی، شامل نزدیکی شبکه پروژه و بردار ویژه شبکه پروژه. دومی، شامل «اثرات سطح پروژه»، مانند اندازه پروژه، مدت پروژه، تعویق اندازی پروژه و سطح برونسپاری پروژه است. سومین سطح مرتبط است با «اثرات سطح مدیر پروژه» و شامل قدرت رسمی مدیر پروژه و تنوع مدیر پروژه است. سطح چهارم شامل «اثرات پروژه-سطح تیم» با استفاده از اندازه تیم، تنوع سلسله مراتبی گروه و پراکندگی تخصیص تیم، می باشد. مطالعات قبلی، این سطوح به هم وابسته ترکیبی را عمیقاً مورد بررسی قرار نداده بودند و کمبود مطالعات تجربی که نشان می دهند این سطوح چهار عاملی چگونه می توانند با هم کار کنند، حس می شود.

در مدل پژوهشی زیر (شکل 1)، ادبیات IS و PM را مرور می کنیم و به تفصیل، منطق نهفته در هر فرضیه در مورد اثر بالقوه هر عامل بر موفقیت مدیریت هزینه ای و زمانی پروژه (CTPMS) را توضیح می دهیم. در انجام چنین کاری، بر این باور هستیم که می توانیم پیامدهای هر سطح از عوامل را به صورت جامع تر تحلیل کنیم.

 

2.3.اثرات سطح شبکه پورتفوی

مطالعات مدیریت پورتفوی از مقالات آکادمیک بدوی منتشر شده توسط گیر (Gear) و همکاران (1971)، نشات گرفته اند. اما، مدیریت پورتفوی فنآوری اطلاعات، توجه بیشتری به واسطه مک فارلان (1981) به خود جلب کرده است، کسی که مفاهیم توسعه یافته توسط مارکوویتز (1952) را توسعه داد. در دهه 1990، با توسعه طرح های تجاری که چهارچوبی برای طبقه بندی پروژه ها فراهم می کند، افزایش حجم ادبیات مرتبط با تحلیل و برنامه ریزی پورتفوی ها، حاصل شد (ویلرایت و کلارک، 1992)، علاوه بر توسعه مدل های انتخاب و مدیریت پورتفوی پروژه (آرکر و قاسم زاده، 1999). مدیریت پورتفوی پروژه، فرآیندی است که هدفش اطمینان حاصل کردن از این است که پروژه صحیح برای دستیابی به اهداف مطلوب سازمان، انجام خواهد شد (ترنر، 2014).

مدیریت پورتفوی پروژه، توجه متخصصان و مجریان را به عنوان ابزاری برای قادر سازی سازمان ها در همسوسازی پروژه های لازم با استراتژی سازمانی و اطمینان حاصل نمودن از منابع انسانی کافی برای پروژه ها در زمان مناسب، را به خود جلب کرد (کیلن و هانت، 2014). هزینه منابع انسانی، بخاطر اهمیت ویژه اش، غالباً بخوبی کنترل می شود (آکونا و همکاران، 2006) و تخصیص و انتساب افراد مناسب، کیفیت و بهره وری یک پروژه را تعیین می کند (چان و همکاران، 2008). بنابراین، فرآیند تخصیص و تقسیم بندی اعضای تیم براساس بهترین ترکیب هزینه و مهارت، برای موفقیت مدیریت پروژه، بسیار حیاتی است (والتر و زیمرمن، 2016). ما دو مشخصه مرتبط با اثر متقابل بین اعضای تیم در پورتفوی پروژه های درون سازمان را مورد توجه قرار می دهیم: نزدیکی شبکه پروژه و بردار ویژه شبکه پروژه.

 

2.3.1.نزدیکی شبکه پروژه و بردار ویژه شبکه پروژه

هدف یک رویکرد شبکه اجتماعی، توصیف الگوهای اثر متقابل بین افراد با استفاده از یک نمودار اتصالات است که در آن افراد درون یک شبکه، گره نامیده می شوند و روابط بین بازیگران، پیوندها یا مناسبات نامیده می شوند (نیومن، 2002). گره ها و پیوندها، ساختار یک شبکه را تشکیل می دهند و نظریه شبکه اجتماعی، ساختار شبکه را با توجه به منابع برای اقدام اجتماعی، توصیف می کند (بیکر، 1990). نظریه های شبکه اجتماعی می توانند خاطر نشان کنند که چگونه قرار گیری در معرض انواع گسترده اطلاعات بوسیله شبکه، بر یادگیری و بهره وری تاثیر می گذارد (ریگانز و زاکرمن، 2001).

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

مقالات ترجمه شده جدید مدیریت پروژه
 

پروژه های IS از چندین عضو تیم تشکیل شده اند و هر عضو تیم می تواند در چندین پروژه مشارکت کند. بخاطر اینکه اعضای تیم می توانند ایده ها را مبادله کنند (زیکا-ویکتورسون و همکاران، 2006) و دانش در مورد فنون توسعه نرم افزار را بین چندین تیم پروژه، در میان بگذارند (اوزر و ووگل، 2015)، شبکه پروژه ها، به عنوان یک کانال یا مسیر برای جریان دانش و تخصص در میان پروژه های IS متصل و همبند، عمل می کند (شو و همکاران، 2006). روابطی که با آنها اعضا و پروژه ها به هم متصل شده اند، می توانند باعث بهبود پیامدها و عملکرد شوند (برت، 2009)، و در نتیجه بر موفقیت پروژه ها بخاطر کاهش هزینه هماهنگی بین اعضا تاثیر بگذارند (پنگ و همکاران، 2013).

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

بنابراین، افزایش تعداد پیوندهای عام و ژنریک می تواند به نحو نادرست اضافه بار اطلاعات بوجود بیاورد و هزینه مدیریت را افزایش دهد و در نتیجه پیامد و عملکرد را کاهش دهد (اولیری و همکاران، 2011). بنابراین، موارد زیر را مطرح می نماییم:

 

فرضیه 1. نزدیکی بیشتر در شبکه پروژه، اثر مضر بر «موفقیت مدیریت هزینه ای و زمانی پروژه» (CTPMS) در پروژه های توسعه IS دارد.

 

برعکس، ایجاد اتصالات و پیوندها با افرادی که می توانند اطلاعات مفید را مبادله کنند به اعضای تیم، رسیدن به دیگران با سطح یکسان مهارت ها را ممکن می سازد (اوزر و ووگل، 2015). فرار بودن شرایط و الزامات نرم افزاری و نوآوری فنآوری، استفاده همزمان از چندین چارچوب توسعه نرم افزار در یک پروژه خاص را، که نیاز به اطلاعات تخصصی دارد را افزایش می دهد (راماسوبو و همکاران، 2015). علاوه بر آن، مدیران می توانند در استفاده از کنترل های مدیریتی، همکاری داشته باشند (کوروهونن و همکاران، 2014)، که این می تواند پروژه های IS تحت مدیریتشان را بهبود بخشد.

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

 

فرضیه 2. یک بردار ویژه شبکه پروژه بالاتر، اثر مثبتی بر موفقیت مدیریت زمانی و هزینه ای پروژه (CTPMS) در پروژه های توسعه IS دارد.

 

2.4.اثرات سطح پروژه

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

 

2.4.1.اندازه و مدت پروژه

این ادبیات، فرض های مختلف در مورد اثر اندازه و مدت پروژه بر pMS را ارائه می دهد. به عقیده والاس و همکاران (2004)، پروژه های درازمدت تر معمولاً ریسک های بیشتری در این ابعاد دارند: تیم، محیط سازمانی، الزامات، برنامه ریزی و کنترل، کاربر و پیچیدگی پروژه. در حالت برابر، همانگونه که توسط مارتین و همکاران (2007) ذکر شده، پروژه های IS بزرگتر با مدت طولانی تر، مشکلات بیشتری در رعایت بودجه ها و کیفیت پروژه دارند که این بخاطر هزینه فنآوری، افزایش تعداد پرسنل، تعداد بیشتر وندروهای بکار گرفته شده و پیچیدگی بیشتر در هماهنگی و کنترل است.

به طور مشابه، تیلور و همکاران (2012) اذعان می کنند که معمولاً پروژه های بزرگ، پیچیده تر و ریسکی تر هستند؛ چنین پروژه هایی نیاز به تیم های بزرگتر و ارتباطات بهتر داند و در نتیجه باعث پیچیدگی سازمانی بیشتر و کاهش احتمال موفقیت می شوند. بنابراین، تفکیک پروژه های طولانی به ریزپروژه های کوتاه تر می تواند پیچیدگی را کاهش دهد، خطرات را رفع کند و شانس موفقیت را بیشتر کند.

برعکس، پروژه های طولانی تر، معمولاً پروژه هایی که بیش از یک سال طول می کشند، اثر مثبتی بر توسعه مهارت های تیم دارند و تاثیر مثبت بعدی بر PMS از خود نشان می دهند. مدیران، زمان مناسب برای سرمایه گذاری در شیوه های توسعه تیم دارند که این می تواند تاثیر مثبتی بر موفقیت پروژه بگذارد؛ برای مثال، «پرداخت و پاداش»، در کاهش انحراف از برنامه مشارکت دارد، درحالی که «هماهنگی» تاثیر عمده ای بر بهبود رضایت مشتری دارد (زیوکواول و اونگر-آوریام، 2010). در همین راستا، لیو و همکاران (2016) نتیچجه گیری گیرکده که در پروژه های «جمع سپاری» ، ریسک پیچیدگی مرتبط با پروژه های بزرگتر را می توان براحتی رفع کرد، زیرا «جمع سپاری» می تواند گروهی از افراد آموزش دیده برای انجام وظایف پروژه را استخدام کند.

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

بنابراین، همراستا با این استدلال، فرضیه زیر را بیان می کنیم:

مقالات ترجمه شده جدید مدیریت پروژه
 

 

فرضیه 3. افزایش اندازه پروژه، CTPMS در پروژه های توسعه IS را افزایش می دهد.

 

فرضیه 4. افزایش مدت پروژه CTPMS در پروژه های توسعه IS را بهبود می بخشد.

 

2.4.2.تعویق در پروژه

تعویق در پروژه به معنای انعطاف پذیری در تعویق شروع اجرای یک پروژه و قسمتی از تعهد منابع آن می باشد. این تصمیم می تواند براساس لزومیت اطلاع یافتن در مورد ماهیت نتایج و بهبودهای (payoff های) غیرقطعی باشد و می تواند باعث تغییرات در اولویت بندی گردد (بنراوچ و همکاران، 2007). گرفتن این تصمیم در ابتدای یک پروژه IS می تواند نیاز به سرمایه گذاری بیشتر را برطرف کند و حتی زیان های گردش ملای را کمتر کند. مثالهای آن شامل تاخیر تا اینکه یک فنآوری جدید و کم هزینه تر مهیا شود و میسر بودن اثبات شده یا منتظر ماندن برای اصلاح مناسب در مقررات که می تواند باتعریف هنگرفت حیطه پروژه را توجیه دهند، باشند (بناروچ و کافمن، 2000).

تعویق پروژه، یکی از تصمیمات مدیریت پوترفوی پروژه متشکر از تصمیمات برای شروع، توقف یا شتاب دادن پروژه ها می باشد (کوپر و ادجت، 1997*). از سوی دیگر، تصمیم برای تعویق یک پروژه IS می تواند مزایای پروژه را کاهش دهد، بخصوص هنگامی که پروژه شامل انتشار و عرضه یک فنآوری نوین است که مزیت رقابتی را برای تنها اولی ها بوجود می آورد. از سوی دیگر، سازمان ها باید همچنین ریسک زیان های بالقوه ناشی از عدم قطعیت را ارزیابی کنند و یک دیدگاه دفاعی از تعویق اندازی شروع پروژه اتخاذ کنند (فیشمن و همکاران، 2005). به بیان دیگر، اگرچه گزینه تعویق باید هزینه تصممیم نگرفتن را جبران کند (لیوئیس و همکاران، 2004)، اما تاخیر شروع پروژه می تواند ارزشمند شود اگر انتظار برود اطلاعات آتی ، ریسک های اجرا را کاهش دهند (بناروچ و همکاران، 2007).

براساس این عناصر و با ملاحظه اینکه ارگان هایی که صنعت خدمات مالی در برزیل را نظارت و قانونگذاری می کنند، اتخاذ کنترل های مدیریت پروژه برای اجتناب از ریسک های ذاتی پروژه های IS را ملزم کرده اند (ترلیزی و بیانکولینو، 2014؛ ترلیزی و همکاران، 2016)، استدلالها در مورد تاثیرات مثبت را قبول می کنیم و فرضیه زیر را بیان می کنیم:

 

فرضیه 5. هرچه تعویق پروژه طولانی تر باشد، CTPMS پروژه های توسعه IS بیشتر می شود.

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

 

فرضیه 6. مدت پروژه اثر ممستقیم تعویق پروژه بر CTPMS پروژه های توسعه IS را متعادل و کاهش می دهد.

 

2.4.3.میزان برونسپاری پروژه

برونسپاری کارکردهای IS در ادبیات در سالهای اخیر بطور گسترده مورد بحث قرار گرفته است (لاسیتی و همکاران، 2010؛ لیانگ و همکاران، 2016) و کاهش هزینه به صورت یکی از عوامل اصلی پدیدار شده است که باعث می شود یک شرکت برونسپاری را مدنظر قرار دهد (شوارز، 2014). شرکت ها، انگیزه های بسیاری برای برونسپاری فعالیت های IS خود فهرست می کنند، مانند عرضه سریع محصولات جدید، نیاز به تمرکز بر کسب و کارهای اصلی خود، افزایش بهره وروی، دسترسی بهتر به تخصص فنی و کمبود منابع داخلی لازمه (گورلا و سومرز، 2014).

مخصوصاً، از جنبه پروژه IS، برونسپاری، یک تصمیم اساسی در نظر گرفته می شود که این بخاطر اثراتش بر هزینه ها و زمن پروژه است (گورلا و سامرز، 2014). چندین مطالعه به یک رابطه مثبت بین برونسپاری پروژه IS و PMS اشاره می کنند. برای مثال، مائو و همکاران (2008) در مطالعه خود در مورد اعتماد و کنترل در برونسپاری iS، اشاره می کنند که کنترل مشتری بر وندور، تاثیر بسزایی بر کنترل هزینه دارد و به وندور در جلوگیری از اضافه هزینه، کمک می کند. تیوانا و کیل (2009) در مطالعه خود با 57 پروژه iT برونسپاری شده و 79 پروژه داخلی، نتیجه گیری کرند که بخاطر اینکه مکانیزم های کنترل در پروژه های داخلی موثر هستند اما در پروژه های برونسپاری شده موثر نیستند، مدیران باید کنترل را هنگام برونسپاری پروژه ها کاهش دهند. سریوواستاوا و تئو (2012) اعلام می کنند که هنگامی که فعالیت های iS بوسیله یک تامین کننده انجام می شوند نه به صورت داخلی، حاکمیت مشتری را می توان بهتر انجام داد، هزینه های هماهنگی کاهش می یابند و کیفیت قابل بهبود است. هان و همکاران (2013) در مطالعه خود با 267 مدیر پروژه، دریافتند که قابلیت های مکمل همدیگر برای وندور و مشتری عوامل قابل توجه موفقیت پروژه IS هستند. لیو و وانگ (2014) استدلال می کنند که پرونسپاری یک پروژه بهترین گزینه برای سازمان هایی است که واحدهای IT آنها تخصص و دانش فنی کافی ندارند و گفن و همکاران (2016) ذکر می کنند که برای اجتناب از مسائل در اجرای پروژه، مدیریت ریسک معمولاً برونسپاری را مدنظر قرار می دهد تا از موفقیت پروژه اطمنان حاصل کند. در خلاصه، فرضیه زیر را پیشنهاد می کنیم:

 

فرضیه 7. هرچه سطح پرونسپاری بیشستر باشد، CTPMS پروژه های توسعه IS، بیشتر می شود.

 

2.5.اثرات سطح مدیر پروژه

یک مدیر پروژه (pM) مسئول نظارت بر پروژه و تیم پروژه است (دوبویس و همکاران، 2015). PM همچنین باید نگران منافع تجاری باشد (مارتینسو و لهتونن، 2007) باشد تا PMS را تضمین کند. میلهولان و کارست-بران (2016) فهرستی از مهارت های نرم و سخت لازم برای یک PM برای انجام قاطعانه فعالیت هایش را ذکر کرده اند: مهارت های مدیریت پروژه، کسب و کار، مدیریت، دانش از اصول فنی پروژه،  بین فردی، مدیریت اسپانسر پروژه، آگاهی وضعیت و تلفیق مهارت ها و دانش قبلی. این ادبیات، عوامل بسیار مرتبط با مشخصات مدیر پروژه که می توانند بر PMS تاثیر بگذارند را شامل می شود؛ بنابراین، دو مشخصه مرتبط با سازمان را به عنوان عوامل PM در نظر گرفتیم: قدرت رسمی PM و تنوع مدیریت PM.

 

2.5.1.قدرت رسمی PM

رهبران پروژه، برای اینکه قادر به تشویق و الهام بخشیدن به کارکنان باشند، باید قادر به تاثیر گذاری بر دیگران برای رسیدن به اهداف پروژه باشند. اما، در رهبری، نه تنها دستیابی به نتایج تجاری خوب مهم است بلکه همچنین ایجاد فرهنگی که در آن کارکنان توانمند می شوند و بوسیله یک هدف مشترک ترغیب می شوند، مهم است (دوبویس و همکاران، 2015). اما، برای دستییابی به موفقفیت مدریریت پروژه، مدیر پروژه نه تنها لازم است مهارت های نرم برای ترغیب مشارکت اعضای تیم داشته باشد بلکه همچنین دسترسی به مهارت های سخت (ابزار و فنون) لازم برای نظارت و کنترل فعالیت های پروژه دارد (سینگ و ران، 2010). علاوه بر آن، PM باید اختیار برای واگذاری، کنترل و نظارت بر فعالیت های اعضای تیم داشته باشد (PMI، 2013) و باید رسماً توانمند باشد تا فعالیت انعطاف پذیر در شرایط پیش بینی نشده داشته باشد (جوگدف و مولر، 2005).

کنترل رسمی برای رفع ریسک ها (ترلیزی و بیانکولینو، 2015؛ تیوانا و کیل، 2007) و بهبود عملکرد پروژه های IT داخلی (کیل و همکاران، 2013؛ لیو و وانگ 2016) و همچنین برونسپاری شده (لیو و همکاران، 2017)، حیاتی است. در تعدادی از سازمان ها، قدرت رسمی، از اسپانسر به مدیر پروژه به روشی محدود، منتقل می شود. چنین انتقالی یک مسئله واقعی برای مدیران پروژه مجرب نیست، زیرا آنها می توانند وظایف را انجام دهند و نیاز به توان و قدرت رسمی را به حداقل برسانند، اما مدیران کمتر مجرب، مدیریت یک پروژه در سناریویی با قدرت رسمی کم، دشوار می بینند. این عدم تعادل اختیار بین سازمان و مدیر پروژه می تواند بر PMS تاثیر بگذارد (ایوز، 2005).

پترو و گاردینر (2015) مشخص کرده اند که میزان تاثیر مدیر پروژه در سازمان، تبدیل و تعبیر شده به قدرت رسمی، تاثیر مثبتی نه تنها بر pMS دارد بلکه همچنین بر موفقیت پورتفوی، رضایت مشتری و همراستایی استراتژیک، دارد. براساس این اظهارات، فرضیه زیر را پیشنهاد می کنیم:

 

مقالات مدیریت پروژه و ساخت

 

 

فرضیه 8. هرچه قدرت رسمی PM بیشتر باشد، CTPMS پروژه های توسعه IS، بیشتر می شود.

مقالات ترجمه شده جدید مدیریت پروژه
 

 

2.5.2.تنوع مدیریت PM

مدیریت پروژه ها با اندازه های مختلف نیاز به رویکردهای متنوع، سبک های رهبری و مهارت های مختلف دارند (مولر و ترنر، 2010). در یک طرف مقیاس، مدیریت پروژه های کوچک و متوسط نیاز به تمرکز بر اولویت بندی تخصیص منابع در چندین پروژه دارد، درحالی که در پروژه های بزرگ، تاکید بر هماهنگی یک دنباله پیچیده از فعالیت ها، متعادل سازی منابع در بین فعالیت ها و اما تمرکز بر ممکن سازی فعالیت های اساسی، می باشد (پینه و ترنر، 1999). بطور کلی، دانش و مهارت مدیر پروژه، راهکار حل موثر بحران پروژه و بیشینه سازی احتمال موفقیت پروژه، می باشند (السبعا، 2001). برای مثال، تخصص در حل مسئله، مهارت در ارتباطات و رهبری، توانایی برای شناسایی صحیح شرایط زمینه و تخصص در برنامه ریزی و نظارت بر حیطه، خطوط زمانی و بودجه ها، از اهمیت اساسی برخوردار می باشند (مولر و ترنر، 2010).

یکی از رویکردها برای بدست آوردن دانش و توسعه تجربه و مهارت های لازم، گنجاندن در پروژه های با اندازه متنوع دخیل داده شوند، که در آنها چندین وضعیت PM را ملزم به اعمال چندین توانایی می کنند، می باشند. اختصاص داده شدن برای مدیریت پروژه های کوچک، می تواند به عنوان یک زمینه آموزشی برای مدیران پروژه های بزرگ بعدی، عمل کند (پینه و ترنر، 1999). شرکت ها از این رویکرد استفاده می کنند تا بطور موثرتر از منابع خود بهره بگیرند و انتقال دانش را ارتقاء بخشند و در نتیجه بهره وری و یادگیری را بهبود بخشند (میلگروم و رابرتز، 1992). براساس موارد گفته شده در بالا، فرضیه زیر را تدوین می کنیم:

 

فرضیه 9. سطوح بالاتر تنوع مدیریت PM با سطوح بالاتر CTPMS پروژه های توسعه IS ارتباط دارند.

 

2.6.اثرات سطح تیم

یک تیم شامل دو یا چند فرد است که تعامل اجتماعی دارند هنگامی که هدفشان انجام امور سازمانی می باشد. مشخصات این افراد از این قرارند: (1) اهداف مشترک؛ (2) به هم وابستگی مرتبط با فعالیت ها، گردش کار، اهداف و پیامدها (3) نقش ها و مسئولیت های مختلف؛ و (4) گنجانده شدن در یک سیستم سازمانی. کار تیمی را می توان با سیکل های مکرر اثر متقابل دو به دو به هم وابسته، نشان داد. در حال حاضر، سازمان های بسیاری از نوعی کار تیم محور برای بدست آوردن بازده بهتر، استفاده می کنند (کوزلوفسکی و بل، 2003). اما، پروژه های تامین نیرو، چالش برانگیز است (والتر و زیمرمن، 2016) زیرا تیم های پروژه شامل اعضایی با مهارت ها و رشته های مختلف و کسانی که کنار هم قرار دادنشان دشوار است، می باشند (زویکائل و اونگر-آویرام، 2010). ما اندازه، پراکندگی تخصیص و پراکندگی سلسله مراتبی را به عنوان عوامل تیم در نظر گرفتیم.

 

2.6.1.اندازه تیم

با ملاحظه زمینه خاص توسعه سیستم های منبع باز (OSS)، افزایش تعداد توسعه دهندگان لزوماً یک مسئله برای بودجه پروژه نیست، زیرا افراد براساس تابعیت و فرعی بودن (affiliation) داوطلبانه، برای کار پذیرفته می شوند. مطالعات در مورد دینامیک های OSS و بهره وری تیمی نشان داده اند که اندازه گروه بزرگتر، تاثیر مثبتی بر پیامدهای پروژه دارد که این بخاطر مشغول شدن و درگیر شدن توسعه گر است. برای پرداختن به انگیزه های دیگر، توسعه گران OSS می توانند فرصت هایی در پروژه های اصلی برای یادگیری، شناختن افراد و بهبود نیکنامی پیدا کنند، اگر بتوان آنها را با عملکرد خوب ارتباط داد (چنگالور-اسمیت و همکاران، 2010؛ قاپانچی و آوروم، 2012).

اما، این ادبیات عمومی، این فرض مقدم را تایید می کند که اندازه بزرگ تیم پروژه، ممکن است تلاش هماهنگی بیشتر را ملزم کند و می تواند انگیزه اعضای تیم را کاهش دهد. برای مثال، یک تیم بزرگ می تواند تاثیر مضری بر بودجه بگذارد (مارتین و همکاران، 2007) و باعث افت بهره وری (اینگهام و همکاران، 1974؛ والتر و زیمرمن، 2016) شوند. در همین راستا، این شواهد تجربی وجود دارد که با افزایش اندازه تیم، بهره وری برای هر نفر بخاطر اثر اتلاف وقت اجتماعی، کاهش می یابد، درحالی که اعضای تیم به کمتر از ظرفیت و پتانسیل خود دست می یابند (چیدامبارام و تانگ، 2005). تیلور و همکاران (2012) نیز اذعان کردند که تیم های بزرگتر نیاز به سطوح ارتباطات بیشتر دارند و باعث پیچیدگی سازمانی شوند، درحالی که بالیت (2010) استدلال می کند که یک تیم کوچک، ارتباطات را هم درون تیم و هم با ذینفعان پروژه تسهیل می بخشد و در نتیجه انسجام و همکاری را بهبود می بخشد. براساس این گفته ها، فرضیه زیر را پیشنهاد می کنیم:

 

فرضیه 10. هرچه اندازه تیم پروژه بزرگتر باشد، CTPMS پروژه های توسعه IS کاهش می یابد.

 

2.6.2.پراکندگی تخصیص تیم

تخصیص تیم در پروژه های IS براساس ترکیبی از الزامات پروژه فنی و تخصص ها و توانایی های توسعه دهنده، می باشد. در حال حاضر، تخصص های لازمه بیش از پیش بوسیله یک سناریوی تکامل فنآوری سریع تعریف شده اند که در آن دانش در مورد فنآوری های متعدد و استفاده همزمان از چندین چارچوب های فرآیند توسعه نرم افزار، یک واقعیت در یک پروژه است (راماسوبو و همکاران، 2015).

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

در نتیجه، تیم ها را می تواند به نحوی توصیف کرد که افراد گروه دارای توانایی ها و دانش مکمل به صورت استراتژیک، تعریف گردند. همکاری، با افزوده شدن به این کار تفصیلی، نیز لازم است و متناسب شدن با ارزش های متناظر اعضای تیم، یکی از راهکارها برای تقویت اتصالات و ارتباطات لازم می باشد. اما، بکارگیری استراتژی همکاری اعضای تیم نیز پیچیده است (نارایانسوامی و همکاران، 2013).

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

 

فرضیه 11. هرچه پراکندگی تخصیص تیم بیشتر باشد، CTPMS پروژه های توسعه IS، کمتر است.

 

2.6.3.تنوع سلسله مراتبی تیم

ادبیات در مورد تنوع گروهی، نکته هایی در مورد اثرات و عوارض جانبی که تنوع کارکردی می تواند بر سازمان و عملکرد پروژه داشته باشد، ارائه می دهد. یکی از دلایل مرتبط با مشکلات در نهادینه کردن روح کار تیمی در همه اعضا است. معمولاً اعضای تیم، انسجام گروهی و رضایت شغلی کمتر و میل به ترک شرکت و استرسزاهای شغلی بیشتری نسبت به گروه های همگن دارند (آنکونا و کالدول، 1992).

تنوع عملکردی در تیم پروژه، اثر مستقیم بر کیفیت فنی ندارد، بلکه تاثیری قوی و منفی بر عملکرد بودجه ای دارد، و اثر مستقیمی بر رسیدن به برنامه ریزی زمانی ندارد (کلر، 2001).

 

 

 

بر این اساس، مانیکس و نیل (2005) ادعا می کنند که تیم های همگن از دانش موجود، سود و منفعت بهتری می کنند. اما، با در نظر گرفتن انواع دیگر تنوع، استدلال شده است که گروه های دارای تخصص، تجربه و پیشینه آموزشی مختلف، از خلاقیت و حل مسئله در سیستم های پیچیده، منفعت می برند (پیج، 2010). همراستا با دیدگاه قبلی، موارد زیر را پیشنهاد می کنیم:

 

فرضیه 12. سطوح بالاتر تنوع سلسله مراتبی تیم پروژه با سطوح کمتر CTPMS پروژه های توسعه IS ارتباط دارند.

 

3.روش ها

3.1.نمونه آماری و گردآوری داده ها

سازمان مدنظر، یک شرکت برزیلی در صنعت خدمات مالی می باشد. این سازمان 15 کشور وجود دارد و یکی از بزرگترین سازمان های جهان در زمینه کاری خاص خود است و بیش از 400 میلیون دلار دارایی و بیش از 80000 کارمند دارد. در فهرست 50 برند بانکداری ارزشمند جهان مربوط به سال 2015 شامل شده است (Brand Finance، 2015). بخش IT تقریباً 5000 پرسنل دارد و ظرفیت همکاران و مشارکت کنندگان بیرونی، براساس تقاضا، انعطاف پذیر است، درحالی که «دفتر مدیریت پروژه» (PMO)، 50 پرسنل دارد. پورتفوی پروژه به بیش از 3000 پروژه IS شروع شده در هر سال می رسد که اینها با یک «سیستم اطلاعات مدیریت پروژه» (PMIS)، کنترل می شوند. این پروژه ها می توانند یکی از وضعیت های زیر را داشته باشند: (1) پیش نویس- هنوز پروژه تایید نشده است (مشخصات فنی و برآوردها، در حال انجام)؛ (2) در حال اجرا- پروژه توسط تیم IT درحال توسعه می باشد؛ (3) نتیجه گیری شده- حیطه کلی توسط کاربر تحویل داده شده و پذیرش شده؛ یا (4) کنسل شده (لغو شده)- پروژه بطور غیرمنتظره قبل از تکمیل، تایید داده نشده یا خاتمه داده نشده، که این معمولاً بخاطر پورتفوی پروژه یا تغییر سناریوی سیاستی/اقتصادی می باشد.

یک مجموعه داده اولیه 3778 پروژه IS از PMIS در فوریه 2016، استخراج شد. چکیده شامل پروژه های IS اجرا شده در دوره دسامبر 2013 تا دسامبر 2014 بود و در دوره ژانویه 2014 تا دسامبر 2015، نتیجه گیری شد. مدیر مسئول PMO توضیح داد که پروژه های کنسل شده را نمی توان شکست یا عدم موفقیت در نظر گرفت، زیرا هیچ رکوردی وجود نداشت که دلیل لغو را توجیه می کردند یا توضیح می دادند آیا تحویل جزئی از نظر حیطه وجود داشته است یا خیر. در زمان استخراج داده ها، فرآیند ملغی سازی پروژه های IT تحت بازبینی آن سازمان بود؛ بنابراین انتخاب آن پروژه ها در مطالعه امکان پذیر نبود.

2636 پروژه IS که زمان توسعه کمتر از 501 ساعت داشتند، کنار گذاشته شدند و بنابراین مجموعه داده به 1142 پروژه، کاهش یافت. این کاهش لازم بود، زیرا این پروژه ها طبق «روش کار مدیریت پروژه» (PMM) تهیه شده توسط سازمان، کوچک در نظر گرفته شدند. پروژه های IS کوچک توسط تیم ها و بودجه های جداگانه با استفاده از یک PMM ساده، براساس ترتیب FIFO (ورودی اول، خروجی اول)، انجام می شوند. بنابراین، با توجه ماهیت بسیار گسترده فرآیندهای مدیریت پروژه، تصمیم گیری شد که پروژه های IS کوچک در یک مطالعه جداگانه ارزیابی شوند.

سپس، مواردی که یک مورد فوق العاده موفقیت در نظر گرفته شده بودند، و آنها را غیرمحتمل دیدیم، کنار گذاشتیم. برای مثال، مواردی که از نظر زمانی با استفاده از کمتر از 33% از زمان خط مبنا موفقیت آمیز بودند یا مواردی که از نظر هزینه با هزینه یابی کمتر از 33% هزینه خط مبنا، موفقیت آمیز بودند، تفکیک شدند (segregated). آن مواردی که احتمال داده شد فرآیند اولیه دارای خطا دارند یا دربرگیرنده تغییر حیطه عمده هستند، در خط مبنا، شامل نشدند. برای بکار گیری این ضابطه، شاخص های اولیه برای «موفقیت هزینه ای مدیریت پروژه» (CPMS) و «موفقیت زمانی مدیریت پروژه (TPMS) را توسعه دادیم که براساس درصد واریانس هزینه تحمیل شده از هزینه خط مبنا و درصد انحراف زمانی تحمیل شده از زمان خط مبنا، به ترتیب، محاسبه شده بود. با این حال، پروژه های ناموفق از نظر هزینه ای یا زمانی، در هر میزان درصد انحراف، شامل شدند. براساس این ضابطه، 243 پروژه از مجموعه داده ها، کنار گذاشته شدند و در نتیجه 899 حیطه معتبر از پروژه های IS موفق، بدست آمد؛ بنابراین، محاسبه شاخص «موفقیت حیطه ای مدیریت پروژه»، لازم نبود.

در سازمان مطالعه شده، پروژه های IT به سه دسته مختلف، طبقه بندی و دسته بندی می شوند: پروژه های IT شرکتی (معمولاً پروژه های زیرساختی با سرمایه گذاری زیاد)، پروژه های تجاری (ایجاد محصولات یا خدمات جدید یا بهبود محصولات و خدمات موجود) و پشتیبانی (تعمیر و نگهداری سیستم های میراثی، ریسک عملکردی و مسائل نظارتی و قانونگذاری). جدول 2، مشخصات تعدادی از پروژه های IT انتخاب شده در نمونه را نشان می دهد.

 

3.2.سنجه ها

همه متغیرها را به صورت زیر تقسیم بندی می کنیم:

 

3.2.1.متغیر وابسته

برعکس معیارهای سنتی PMS دیده شده در ادبیات، یک جنبه افزایشی-حاشیه ای برای شاخص CTPMS را پیشنهاد می کنیم. فرض این رویکرد این است که افزایش جزئی مقادیر نسبت به خط مبنای هر بعد (هزینه یا زمان) دو به دو به هم وابسته هستند. این جنبه، یکی از ملاحظات مهم است، زیرا ادبیات موفقیت مدیریت پروژه عمدتاً بر معیارهای تجمعی (aggregate) ( و معمولاً ادراکی) تمرکز می کند، به نحوی که گویا یک بعد می تواند بدون ملاحظه اثرات ابعاد دیگر، برآورده شود. در نتیجه، CTPMS را به صورت رابطه هزینه خط مبنا تا هزینه واقعی که یک پروژه از نظر حیطه ای و هزینه موفق  متحمل می شود، ضربدر رابطه زمان خط مبنا نسبت به زمان واقعی صرف شده برای پروژه های موفق حیطه ای و زمانی، بیان می شود. این روش کار با منطق فلسفی کلاسیک که یک صفت وجودی را هنگام برآورده کردن شرایط لازم و کافی برای قرار دادن آن  در یک طبقه خاص، همخوانی دارد (مک کنزی و همکاران، 2011). در مورد CTPMS، سنجه های موفقیت هزینه ای و زمانی هر دو برای مشخص کردن صفت مرکزی (focal) لازم و کافی می باشند و عملکرد ریاضیاتی محصول متناظر با شرایط همزمانی می باشد (گوئرتز، 2005).

این جنبه، ملاحظه همزمان انحراف اندک از هزینه و زمان برنامه ریزی شده را اجازه می دهد و در عین حال، حیطه را کنترل می کند. دلیلی که برای مدل سازی سنجش به این  صورت بیان می کنیم این است که، همانگونه که در مرور ادبی بحث شد، برای مدیران پروژه، بررسی (negotiate) و تنظیم پویای الزامات پروژه بین تیم های توسعه و تجاری/مشتری،  معمول است. در نتیجه، ضرب کردن هر دو امتیاز (score) باعث بدست آمدن یک سنجه کارآمد CTPMS ترکیبی، با ملاحظه موفقیت حیطه ای، هزینه و زمانی می شود. برای مثال، یک مدیر پروژه می تواند هزینه پروژه را با بکار گیری تعداد کمتری از توسعه گران کاهش می یابد و این باعث مزیت جزئی از کاهش هزینه نسبت به بودجه شد. اما با اقدام به این صورت، به احتمال زیادی، اتمام پروژه طولانی تر می شود که این باعث عدم مزیت زمانی می گردد. چنین بررسی تفصیلی منابع در طی توسعه، بسیار معمول است، زیرا می تواند به نحو انعطاف پذیر، مدیریت پورتفوی و تخصیص تیم لازم را حاصل کند. در نتیجه، اگر تنظیمات بطور متناسب در طی پروژه رخ دهند، بدان معنا که تغییرات تناسبی زمان، تغییرات هزینه را جبران کنند و اگر پروژه کلی توسط مشتری از نظر حیطه، هزینه و زمان، موفق قلمداد شود، نتایج چنین تنظیماتی بر نمره شاخص، باید سطح یکسان موفقیت داشته باشد به گونه ای که گویا پروژه هر دوی خط مبنای هزینه ای و زمانی را برآورده کرده است. بخاطر داشته باشید که همه پروژه های نمونه از نظر حیطه، زمان و هزینه، موفق در نظر گرفته شده اند. بنابراین، این شاخص، تغییرات PMS ترکیبی، که برای آنها، مقدم ها یا پیش آیندها را مطالعه می کنیم، سنجش می کند.

همراستا با گزاره ها و پیشنهادهای ما، انحراف هزینه ای یا زمانی (یا هر دو) از خط مبنا باعث بدست آمدن نمره ای می شود که می تواند از حداکثر طلایی «1» فاصله بگیرد. همچنین این ارزیابی، تصمیمات مدیریتی که ممکن است بطور متناسب استفاده از منابع را با هم ترکیب کند، جبران می کند. برای مثال، تیم مدیریتی ممکن است تصمیم به کاهش به اندازه 10% ، و افزایش هزینه به اندازه 10% بگیرد و بیشینه و حداکثر نمره بدست آید. معادله (1)، فرمول PMS هزینه-زمان می باشد:

1. 1. 1. 1. 1.                   

 

3.2.2.متغیرهای مستقل و کنترلی

3.2.2.1.اندازه پروژه

اندازه پروژه را بوسیله تعداد کل واحدهای کار لازم برای تکمیل پروژه (چالیشیر و گوموسوی، 2005؛ PMI، 2013)، بیان شده برحسب ساعت، بیان می کنیم.

 

 

 

3.2.2.2.مدت پروژه

مدت پروژه، زمان مورد نیاز برای تکمیل پروژه است (چالیشیر و گوموسوی، 2005؛ PMI، 2013)، که برحسب روز بیان می شود و بوسیله تفاضل بین تاریخ اتمام واقعی و تاریخ شروع واقعی پروژه، محاسبه می شود.

 

3.2.2.3.شاخص برونسپاری

شاخص برونسپاری، رابطه بین تعداد کل ساعات برونسپاری شده و مقدار کل کار (ساعات کار)، می باشد.

 

3.2.2.4.تعویق در پروژه

تعویق در پروژه را با تفاضل روزهای بین تاریخ شروع برنامه ریزی شده که در خط مبنای پروژه مشخص شده و تاریخ واقعی شروع پروژه، تعریف می کنیم. یک عدد مثبت نشان دهنده دیر شروع شدن پروژه است و ممکن است متحمل هزینه های بیشتری شده باشد (اولانیران و همکاران، 2015).

 

3.2.2.5.اندازه تیم

اندازه تیم به صورت یک مجموعه افرادی که مدیر پروژه را در انجام پروژه برای دسترسی به اهداف پشتیبانی می کنند، تعریف می شود (چالیشیر و گوموسوی، 2005؛ PMI، 2013) و توسط رئیس پروژه اجرایی می شود. منابع برونسپاری شده و کارکنان بخش های تجاری، تایم شیت های PMIS را ثبت نمی کنند؛ بنابراین، متغیر اندازه تیم، تنها کارکنانی را در نظر می گیرد که در بخش IT کار می کنند.

 

3.2.2.6.پراکندگی تخصیص و تقسیم بندی تیم

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

 

 

 

3.2.2.7.تنوع سلسله مراتبی تیم

تنوع سلسله مراتبی تیم را به صورت یک سنجه از پراکندگی سمت یا جایگاه در سلسله مراتب (H) مربوط به عضو تیم (m) درون هر پروژه (i) طبق موقعیت و سمتش در سازمان، بدست می آوریم.

1. 1. 1. 1. 2.             

 

3.2.2.8.نزدیکی شبکه پروژه (اعضای شبکه به هم)

نزدیکی شبکه پروژه را با تحلیل شبکه ای با استفاده از تخصیص اعضای تیم به عنوان معیارهای یال، بدست می آوریم. در نتیجه، گره ها به عنوان پروژه ها در نظر گرفته شدند و در این حالت، نزدیکی شبکه ای، معیاری از این است که یک پروژه با ملاحظه همه پروژه های دیگر درون پورتفوی شبکه ای را بخاطر چندین تخصیص توسعه گران، مورد ملاحظه قرار می دهد (بیوچامپ، 1965). استفاده از نظریه شبکه اجتماعی، زمینه پژوهشی مدیریت پروژه است و اخیراً در مطالعات پروژه های منبع باز استفاده شده است (پنگ و همکاران، 2013).

 

3.2.2.9.مرکزیت بردار ویژه شبکه پروژه

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

 

3.2.2.10.قدرت رسمی مدیر پروژه.

این متغیر به صورت سنجه ای از اختیار رسمی داده شده به مدیر پروژه برای بکار گیری منابع سازمانی برای فعالیت های پروژه، تعریف شده است (لی و همکاران، 2000؛ PMI، 2013). این متغیر براساس نقش مدیر پروژه (1= تحلیلگر ارشد سیستم، 2= تحلیلگر سیستم میانه یا متوسط، 3= تحلیلگر سیستم ارشد، 4= هماهنگ کننده و 5= مدیر) با استفاده از یک متغیر ساختگی برابر با صفر، اگر نقش مدیر 1 تا 3 باشد، و برابر با 1 اگر نقش مدیر 4 تا 5 باشد، بدست می آید (ساندیو و همکاران، 1996).

 

 

 

3.2.2.11.تنوع مدیریت PM

این متغیر بیانگر یک مدیر پروژه است که پروژه هایی با اندازه های مختلف را هماهنگ می کند (مولر و ترنر، 2010). تنوع مدیریت PM را به صورت یک سنجه از پراکندگی اندازه پروژه مدیریت شده (Ps) مدیر پروژه (PM) در هر پروژه مدیریت شده (i)، بدست می آوریم. این فرمول، واریانس پروژه افزایشی یک توزیع دوجمله ای را به صورت زیر محاسبه می کند:

1. 1. 1. 1. 3.                     

 

3.3.رویه های تحلیلی

برای آزمون کردن اثرات همزمانی پیش بینی کننده های چندسطحی بر CTPMS، یک تحلیل رگرسیون سلسله مراتبی ، که یک روش افراز واریانس افزایش است، انجام دادیم. این روش کافی و مناسب می باشد وقتی که ماهیت متغیر وابسته، پیوسته باشد و مطالعه جهت تحلیل چند متغیر با کنار گذاشتن اثرات قبلاً بحث شده در مدل، در نظر گرفته شده است (کوهن و همکاران، 2003). این روش برای دستیابی به یک قدرت توجیه کنندگی زیاد استفاده نمی شود بلکه برای ارزیابی اهمیت نسبی تعدادی متغیرهای افزوده شده به متغیرهای موجود در مدل در نظر گرفته شده، و در نتیجه به پژوهشگر امکان می دهد هرگونه اثرات پیش بینی کننده ها بر متغیر وابسته را درک کند (پدهازور و شملکین، 1991).

ابتدا، به دلایل نظری، با افزودن متغیرهای قبلاً اشاره شده در ادبیات به مدل 1 (جدول 4)، به صورت نشان دهنده اثرات PMS، کار را شروع کردیم: اندازه پروژه، اندازه تیم و قدرت رسمی PM. سپس این متغیرها برای ایجاد مدل صفر، که از آن به دنبال تغییرات معنادار برحسب R²  هستیم، که در مدل های بعدی ارائه می شود و بوسیله افزودن بلوک های متغیرهای دیگر برقرار می شود، استفاده شدند (کوهن و همکاران، 2003). طبق هدف پژوهش ما، برای بررسی اثرات سطوح مختلف تحلیل، بلوک های اضافه استفاده شده برای ایجاد مدل های رگرسیون بعدی از پایین ترین سطح به بالاترین سطح، با ملاحظه پروژه به عنوان یک نقطه آغازین، به سطوح تحلیل ارتباط دارند. بنابراین، پروژه (مدل 2) به عنوان پایین ترین سطح در نظر گرفته شد و سپس به ترتیب، سطوح تیم، پورتفوی و PM تحلیل شدند. علاوه بر آن، اثر متقابل هایی که حمایت نظری داشتند نیز در مدل 6 تست شدند.

ما همه متغیرها را میانگین گیری مرکزی کردیم تا از هرگونه همخطی چندگانه اجتناب کنید و علی الخصوص، تهدید همخطی چندگانه را با محاسبه ضریب تورم واریانس (VIF) برای هر پیش بینی کننده (کوهن و همکاران، 2003) در مدل کامل، بررسی کردیم.

 

4.نتایج

4.1.آماره های توصیفی

جدول 3، آماره های توصیفی و همبستگی های تاو پیرسون و کندال متغیرهایمان را نشان می دهد. آماره های توصیفی نشان می دهند که «اندازه پروژه» نمونه گیری شده، میانگین 2931 ساعت، را همراه با یک انحراف معیار گسترده، برآورده کرده است. بطور میانگین، اندازه یک تیم 71/9 نفر بود و مدت یک پروژه بطور میانگین 261.7 روز بود. بطور میانگین، برونسپاری 2/27% از اندازه پروژه ها را تشکیل می داد، درحالی که مدیران پروژه مسئول مدیریت پروژه هایی بود که بطور میانگین 17.1% از نظر اندازه متفاوت بودند. معیار «موفقیت مدیریت هزینه ای و زمانی پروژه» همبستگی مثبت و معناداری با مدت پروژه، تعویق اندازی پروژه و تنوع مدیریت PM دارد، اما همبستگی منفی با برونسپاری و تنوع سلسله مراتبی تیم داشت. عوامل تورم واریانس (VIF ها) و یک آزمون وابستگی خطی برای تست همخطی استفاده شد. تعدادی همبستگی معنادار بین پیش بینی کننده ها مشاهده شد، اما هیچکدام از آماره های همخطی چندگانه برآورد شده همراه با مدل های رگرسیون ما، به نقطه ای نرسید که در آن همخطی چندگانه به نگرانی تبدیل شود. همه ضرایب VIF، در هر مرحله رگرسیون به صورت تک تک برآورد شدند و باعث بدست آمدن مقدار کمتر از 5 شد که بخوبی کمتر از آستانه 10 است و نشان دهنده آن است که همخطی چندگانه یک تهدید محتمل برای برآورد پارامتر نیست (کوهن و همکاران، 2003). علاوه بر آن، «شاخص شرایط» (CI) بیشینه را برای هر بلوک از پیش بینی کننده ها تحلیل کردیم و نتیجه، بالاترین مقدار 5.2، یعنی کمتر از مقدار تهدید 15 را نشان می دهند (بلسلی و همکاران، 2004). این نتایج نشان می دهند که همخطی چندگانه برای مدل ما باعث نگرانی نمی شود.

 

مقاله مدیریت پروژه های نرم افزاری

 

 

4.2.نتایج تحلیل رگرسیون: عوامل پیشآیند یا مقدم بر PMS

H1 بیان کرد که نزدیکی شبکه ای پروژه بیشتر، اثر منفی بر CTPMS پروژه های توسعه IS دارد. نتایج آشکار می کنند که نزدیکی شبکه پروژه یک اثر منفی و اندک بر CTPMS داشته است [B=-0.074, t886=-2.160, p<0.05 ]. بنابراین H1  تایید می شود.

H2  بیان کرد که یک بردار ویژه شبکه پروژه بزرگتر، تاثیری مثبت بر CTPMS پروژه های توسعه IS دارد. نتایج آشکار کردند که بردارویژه شبکه پروژه، اثر مثبت اندکی بر CTPMS دارد [B=0.066, t886=1.83, p<0.10 ]. بنابراین H2  تایید می شود.

H3  بیان کرد که افزایش اندازه پروژه، CTPMS پروژه های توسعه iS را افزایش می دهد. نتایج آشکار کردند که اندازه پروژه، اثری قوی و مثبت بر CTPMS دارد [B=0.261, t261=3.48, p<0.001 ]. بنابراین H3  تایید می شود.

H4  بیان کرد که افزایش مدت پروژه، CTPMS پروژه های توسعه IS را افزایش می دهد. نتایج آشکار کردند که مدت پروژه اثری قوی و مثبت بر CTPMS دارد [B=0.362, t886=10.791, p<0.001 ]. بنابراین H4  تایید می شود.

H5  بیان کرد که تعویق طولانی تر پروژه، اثر مثبت قوی بر CTPMS پروژه های توسعه IS دارد. نتایج آشکار کردند که تعویق پروژه یک تاثیر مثبت قوی بر CTPMS دارد [B=0.142, t886=5.08, p<0.001 ]. بنابراین H5  تایید می شود.

H6  ادعا کرد که مدت پروژه، تعدیل کننده و کاهش دهنده اثر مستقیم تعویق پروژه بر CTPMS پروژه های توسعه IS دارد. نتایج آشکار می کنند که این اثر متقابل، معنادار است و یک اثر منفی و اندک را نشان می دهد [B=-0.074,  t886=-2.160, p<0.05 ]، بنابراین H6  تایید می شود.

H7  بیان کرد که هرچه سطح برونسپاری پروژه بیشتر باشد، CTPMS پروژه های توسعه iS بیشتر است. نتایج آشکار کردند که برونسپاری پروژه یک اثر غیرمعنادار منفی حاشیه ای بر CTPMS دارد [B=-0.024, t886=-0.683, ns ]. بنابراین H7  تایید نمی شود.

H8  بیان کرد که هرچه قدرت رسمی PM بالاتر باشد، CTPMS پروژه های توسعه IS بیشتر است. نتایج آشکار کردند که قدرت رسمی PM اثر معناداری بر CTPMS ندارد [B=0.001,t886=-0.032, ns ]. بنابراین H8  تایید نمی شود.

H9  بیان کرد که سطوح بالاتر تنوع مدیریت PM با سطوح بالاتر CTPMS پروژه توسعه IS ارتباط دارد. نتایج آشکار کردند که تنوع مدیریت PM یک تاثیر اندک و مثبت بر CTPMS دارد [B=0.080, t886=2.581, p<0.05 ]. بنابراین H9  تایید می شود.

H10  بیان کرد که هرچه اندازه تیم پروژه بیشتر باشد، CTPMS پروژه های توسعه IS کمتر است. نتایج آشکار می کنند که اندازه تیم پروژه تاثیری قوی و منفی بر CTPMS دارد [B=-0.198, t886=-3.729, p<0.001 ]. بنابراین H10  تایید می شود.

H11  بیان کرد که هرچه پراکندگی تخصیص تیم بیشتر باشد، CTPMS پروژه های توسعه IS کمتر است. نتایج آشکار کردند که پراکندگی تخصیص تیم اثری منفی و قوی بر CTPMS دارد [B=-0.274, t886=-4.188, p<0.001 ]. بنابراین H11  تایید می شود.

در آخر، H12  بیان کرد که سطوح بالاتر تنوع سلسله مراتبی تیم پروژه با سطوح کمتر CTPMS ارتباط دارد. نتایج آشکار می کنند که تنوع سلسله مراتبی تاثیر منفی غیرمعناداری بر CTPMS دارد [B=-0.049, t886=-1.17, ns ]. بنابراین، H12  تایید نمی شود.

جدول 4، نتایج تحلیل رگرسیون اثرات ثابت برای پیش بینی موفقیت مدیریت هزینه ای-تیمی پروژه را نشان می دهد.

همچنین، مقاوم بودن (استواری) داده ها در مقابل امکان سوگیری متغیر قلم افتاده را تحلیل کردیم. در مطالعه ما، «تخصیص زمانی تیم» و «شاخص برونسپاری» احتمالاً نماینده هایی برای عوامل سازمانی سنجش نشده مانند روش های توسعه نرم افزار باشند. سیاست های «اداره مدیریت پروژه» یا حتی سیاست های سازمانی مربوط به توسعه آیین نامه های حساس مثر بخش مالی؛ سیستم های اطلاعاتی از ارزش استراتژیک برخوردارند. ما از آزمون RESET رامسی (Ramsey) برای متغیرهای قلم افتاده، یک سری معیار استواری برای بدست آوردن براوردها، استفاده کردیم. نتایج این فرضیه صفر را تایید کردند که سوگیری متغیر قلم افتاده در این مطالعه یک نگرانی جدی نیست [F3883=2.017,ns ].

 

5.بحث و بررسی

با گسترش پژوهش های  قبلی  که بر نقش تنها تعدادی سطوح برای ملاحظه عوامل پیشآیند بر موفقیت مدیریت پروژه تاکید کرده اند، عوامل گسترده و پراکنده شده در چهار سطح مختلف تحلیل را تشخیص دادیم (سطح شبکه پورتفوی، سطح پروژه، سطح مدیر پروژه و سطح تیم). ما از پروژه های مربوط به ادبیات IS استفاده کردیم تا مطالعه کنیم عوامل چندسطحی مرتبط چه تاثیری بر موفقیت مدیریت پروژه دارد. علاوه بر مونتاژ کردن و سرهم بندی چند سطح و تبدیل آن به یک قطعه پژوهشی، رویکرد تحلیل شبکه ای را افزودیم تا عواملی را بدست آوریم که شدیداً در سازمان هایی که به پورتفوی های نرم افزار بزرگ می پردازند و در آنها چندین تیم بین چندین پروژه تقسیم بندی شده اند، وجود دارند. جدول 5، بطور خلاصه نتایج آزمون فرضیه را بین می کند.

 

5.1.اثرات سطح پروژه

با ملاحظه اینکه تعداد زیادی پروژه IS در حال حاضر در سازمان مطالعه شده اجرا می شوند، تعجب آور نیست که پروژه های بزرگتر با مدت طولانی تاثیر مثبت بر PMS و به این ترتیب بر موفقیت پروژه، دارند. آن اثر به این علت رخ می دهد، که در بانک ها پروژه های بزرگتر معمولاً استراتژیک هستند و توسط  یک کمیته اجرایی اولویت بندی می شوند. علاوه بر آن، یک پروژه که نیاز به سرمایه گذاری منابع زیاد دارد، یک یا چند مدیر ارشد به عنوان اسپانسر دارد و مزایای موفقیت آمیز تحقق چنین پروژه ای، مستقیماً به اهداف اسپانسر ارتباط دارند. در نتیجه، یک ساختار کنترل مقاوم تر سازمان دهی می شود تا از PMS یک پروژه بزرگ و حیاتی اطمینان حاصل شود. برای مثال، با اینکه پروژه توسط دفتر مدیریت پروژه مورد نظارت قرار می گیرد و بهترین اعضای تیم برای آن پروژه گماشته می شوند، اما تکامل پروژه بطور مداوم به کمیته اجرایی ارائه و گزارش داده می شود. این یافته ها، مطالعات قبلی (چو و همکاران، 2009؛ گفن و همکاران، 2016؛ کیگان و همکاران، 2012؛ لیو و وانگ، 2016؛ ترلیزی و همکاران، 2017؛ زویکائل و اونگر-آویرام، 2010)، را تقویت و تایید می کنند.

تعویق انداختن شروع یک پروژه ارتباط تنگاتنگی با مدیریت ریسک پروژه دارد. همانگونه که توسط بناروچ و کافمن (2000) ذکر شده، گرفتن این تصمیم در شروع یک پروژه IS نیاز به سرمایه گذاری بیشتر را برطرف می کند و حتی جریان نقدی را کمتر می کند. مطالعه تجربی ما نشان داد که تعویق انداختن شروع یک پروژه اثر مثبتی بر PMS دارد. در یک سازمان مالی بزرگ که تعداد زیادی پروژه IS بطور همزمان در حال اجرا هستند، داشتن یک صف منظم و سازمان یافته از پروژه های اولویت بنده شده برای بیشینه سازی منابع IT، لازم است. به بیان دیگر، ابتدا یک پروژه معمولاً وابستگی شدیدی به اتمام پروژه های دیگر که منابع لازم را آزاد می کنند، دارند. با این حال، در چنین وضعیتی، مرسوم است که تاخیر در پروژه قبلی بر پروژه بعدی تاثیر بگذارد. بنابراین، یک شیوه کاری شناخته شده مورد استفاده توسط مدیران پروژه، به تاخیر انداختن شروع پروژه است تا اکثریت منابع آزاد شوند و در نتیجه تحویل پروژه به موقع، مطابق با بودجه تضمین داده شود و در نتیجه انتظارات ذینفعان دخیل برآورده شود. این شیوه می تواند تحویل برنامه ریزی شده پروژه را به تاخیر بیاندازد و بر تاریخ اولیه استخراج مزیت های پروژه، تاثیر بگذارد (فیشمن و همکاران، 2005)؛ اما، ریسک برآورده نکردن برنامه زمانی خط مبنا یا فراتر رفتن از بودجه پروژه را به حداقل می رساند. این یافته ها، مطالعات قبلی را تایید می کنند (بناروچ و همکاران، 2007؛ فیشمن و همکاران، 2005؛ لیویس و همکاران، 2004).

با اینکه تعدادی از مطالعات قبلی تایید کردند که برونسپاری پروژه های IS تاثیر مثبتی بر هزینه و زمان پروژه دارد (گفن و هماکران، 2016؛ گورلا و سامرز، 2014؛ شوارز، 2014؛ سرویستاوا و تئو، 2012)، مطالعه ما همین نتیجه را نشان نداد. فرضیه ما اینکه سطح بالاتر برونسپاری پروژه تاثیر مثبتی بر PMS دارد، تایید نشد. شاید این اثر رخ نمی دهد زیرا تعدادی از انگیزشگرهای مهم برای برونسپاری فعالیت های IS، مانند کمبود منابع داخلی لازم، تمرکز بر کسب و کاری اصلی خود (گورلا و سامرز، 2014) یا تخصص و دانش فنی ناکافی (لیو و وانگ، 2014) برای یک سازمان مالی بزرگ، معتبر نیستند. در یک بانگ بزرگ با یک بخش IT بزرگ بالغ بر 5000 پرسنل، فعالیت های IS باید فعالیت های اصلی باشند، زیرا شرکت شدیداً به فنآوری وابسته است و منابع IT داخلی، نسبت به منابع بیرونی، مجرب تر و آموزش دیده تر هستند. بنابراین، برونسپاری یک پروژه در این سناریو به معنای بهبود عملکرد پروژه نیست؛ اما، پژوهش های بیشتری برای اعتباریابی گفته مان، لازم است.

 

5.2.اثرات سطح مدیر پروژه

با اینکه یک مدیر پروژه مجرب تر با قدرت رسمی، انعطاف پذیری برای پرداختن به شرایط پیش بینی نشده دارد و تاثیر مثبتی بر PMS و رضایت مشتری دارد (ایوز، 2005؛ جوگدف و مولر، 2005؛ پترو و گاردینر، 2015؛ PMI، 2013)، اما مطالعه ما نمی تواند در مورد این جنبه، قاطع باشد. این فرضیه ما که قدرت رسمی PM اثر مثبتی بر PMS دارد، تایید نشد. ممکن است علت رخداد این نتیجه این باشد که قدرت و اختیار رسمی داده شده به مدیر پروژه براساس نقشش، دیگر بخاطر تیم های چابک توانمند شده تر و آشنایی آنها با فنآوریها، محصولات و روش های چابک جدید، بر اعضای تیم تاثیر ندارد (سرادور و پینتو، 2015). بر این باوریم که پژوهش های بیشتری برای درک این پدیده لازم است.

مطالعه ما نشان می دهد که سطوح بالای تنوع مدیر پروژه، تاثیر مثبتی بر PMS دارد. تخصصی سازی، یک مفهوم اقتصادی مهم است که بر عملکرد یک پرسنل تاثیر دارد؛ اما، این مفهوم برای یک مدیر پروژه IT معتبر نیست. یک مدیر پروژه که می تواند برای پروژه هایی با اندازه و انواع مختلف در حین خدمت خود، آماده و مهیا باشد، بهتر توانایی و آمادگی رفع مسائل پیش بینی نشده که تاثیر احتمالی بر PMS دارند، را دارا می باشد. این استنباط، ادبیات (یعنی پژوهش های) قبلی (السعبا؛ مولر و ترنر، 2010؛ پاینه و ترنر، 1999) را تایید می کند.

 

5.3.اثرات سطح شبکه ای تیم و پورتفوی

همچنین نتایج نشان می دهند که تقسیم بندی گروهی، یک مسئله PM اساسی است، زیرا اندازه تیم، پراکندگی تخصیص زمانی تیم و نزدیکی شبکه پروژه، همگی موفقیت مدیریت هزینه ای-زمانی پروژه را کاهش می دهند. در نتیجه، تیم های کوچکتر، دارای تمرکز بیشتر و کمتر پراکنده، می توانند نتایج بهتری نسبت به چندین تیم بزرگتر و پراکنده که تعداد کثیری از پروژه ها می پردازند، حاصل کنند. این استنباط، در ادبیات اخیر در مورد توسعه IS چابک مشارکت دارد که بیان می کند این سطح از مدیریت، PMS را بهبود می بخشد (لی و شیا، 2010).

با گسترش پژوهش های IS قبلی، تخصیص تیم در پورتفوی را تحلیل کردیم. دو نوع شبکه پدیدار می شوند که باعث اثرات متقابل و متضاد می شوند. داشتن پرسنلی که در اصل در پروژه های مرکزی تخصیص داده شده اند و ساعاتی را با چندین پروژه می گذرانند، PMS را کاهش می دهد، درحالی که داشتن افرادی که ساعاتش را با پروژه های مرکزی دیگر صرف می کند، PMS را افزایش می دهد. همانگونه که در بالا ذکر کردیم، پروژه های مرکزی معمولاً پروژه های استراتژیک هستند که بهتر کنترل می شوند و تیم های فنی بهتری دارند. بنابراین، اعضای تیم طبیعتاً نگرانی بیشتری در مورد نتایج پروژه هنگام کار بر پروژه های مرکزی نسبت به کار بر پروژه های جانبی دارند. این مشاهده با مطالعات قبلی (کولازو، 2010؛ اولیری و همکاران، 2011؛ پنگ و همکاران، 2013)، همسویی دارد.

 

6.نتیجه گیری

6.1.جنبه نوآوری و مشارکت در ادبیات

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

علاوه بر آن، نظریه پردازان مدیریت پروژه تشخیص داده اند که نسخه های مختلف مدیریت پروژه در شرایط مختلف، طبق کشور، بخش صنعت و اندازه سازمان، لازم می باشند. برای گسترش این زمینه پژوهشی، تجمیع مطالعات از صنایع مختلف سراسر جهان، مهم است (لاو و همکاران، 2005؛ ترنر و لدویت، 2016). تعداد زیادی عوامل می توانند بر موفقیت پروژه های IT تاثیر بگذارند و احتمال شکست آنها را کاهش دهند. پژوهشگران بسیاری شخصاً مطالعه کردند که چگونه شیوه های مرتبط با انتخاب و اولویت بندی پورتفوری، فنون نظارت و کنترل پروژه، مهارت های سخت و نرم مدیر پروژه و حتی انگیزه تیم را بهبود بخشند. اما، تعداد جدید گردآوری شده در سطح جهان، توسط تعدادی موسسات مدیریت پروژه، همچنان نشان می دهند که 52% از پروژه های IT چالش برانگیز بوده اند (خزش حیطه و بودجه از دست رفته) و 19% با شکست مواجه شده اند (شکست های در نظر گرفته شده) (PMI، 2017؛ استندیش، 2015). بنابراین، نیاز به شروع بررسی روابط بین این سطوح بسیار عوامل برای توسعه نظریه های مقاوم تر و کمک به متخصصان برای دستیابی به بهترین سطوح عملکرد پروژه، حس می شود.

نظریه مدیریت پروژه در زمینه کنترل زمان، هزینه و حیطه پروژه ها، توسعه یافته اند. اما، نظریه باید به فراتر از این حیطه و زمینه گسترش یابد و در نظر بگیرد که ارزش پروژه باید اثبات شود، بخصوص در سازمان های مالی که استفاده شدیدی از IT در عملیات های خود می کنند و موفقیت پروژه های IT، یک مسئله استراتژیک است.

 

6.2.دلالت های عملی

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

این مطالعه، وجود شیوه های مدیریت پروژه بسیاری را نشان داده است، اما فقط بکار گیری این شیوه ها به صورت منفرد برای تضمین موفقیت مدیریت پروژه های IS، کافی نیست. تضمین دادن استفاده ترکیبی از این شیوه ها برای بیشینه سازی PMS، فوق العاده مهم است.

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

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

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

 

 

مقالات ترجمه شده جدید مدیریت پروژه

 

 

6.3.محدودیت ها و توصیه هایی برای پژوهش های بعدی

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