عوامل موفقیت و شکست پروژه های IT در سازمانها

عوامل موفقیت و شکست پروژه های IT در سازمانها
کلید واژه ها:
فن آوری اطلاعات، سیستم های اطلاعاتی، موفقیت پروژه، مدیریت پروژه
مقدمه:
امروزه گسترش فعالیتهای بازرگانی، جهانی شدن و تغییرات وسیع تکنولوژیک در محیط سازمانها باعث گردیده که آنها برای حفظ بقاء و مزایای رقابتی خود از انعطاف پذیری لازم برخوردار باشند لازمه انعطاف پذیری تغییرات سریع است و تغییرات سریع بدون داشتن اطلاعات امکان پذیر نیست، در نتیجه اطلاعات که به عنوان یک منبع بسیار پر ارزش در کنار سایر عوامل موثر در هر سازمان مطرح است. وجود سیستم های اطلاعاتی یکپارچه از ضروریات حرکت به سمت کسب و کار الکترونیک و رقابت بوده و استفاده از فن آوری اطلاعات (IT) و سیستم های اطلاعاتی (IS) برای کلید سازمانها و شرکتها ضرورتی اجتناب ناپذیر می باشد. بسیاری از سازمانها به اهمیت فن آوری اطلاعات و تاثیر آن بر سرعت و دقت گردش کارها، رضایت بیشتر مشتریان یا سیستم های پشتیبانی، تصمیم گیری مدیران و به ویژه کارآیی آن واقف شده اند و این امر باعث گردیده که به سرعت به سمت استفاده از آن روی آورند. هر شرکت یا سازمانی شامل 3 هسته اصلی یعنی فرایند تصمیم گیری، جریان اطلاعات و جریان مواد است، که فن آوری اطلاعات روی هر 3 هسته فوق می تواند تاثیر بگذارد. کاربرد فناوری اطلاعات، شرکت ها را قادر می سازد امتیازات مهمی از قبیل موارد زیر کسب کنند:
1- صرفه جویی در هزینه و بهبود بخشیدن جهت تبادل اطلاعات .
2- اجتناب از خطاهای انسانی هنگامی که وظایف، تکراری یا بسیار پیچیده است.
3- صرفه جویی مالی بدلیل کاهش خطاها و زمان انجام وظایف.
4- ادغام و هماهنگی چندین وظیفه در یک وظیفه.
5- بهبود بخشیدن کارایی و اثربخشی سازمانی.
6- بهبود مدیریت میانی و کاهش فرآیندهای زائد از طریق اطلاعات مفیدتر.
ولی اجرای پروژه های (IT) در آنها بدون مشکل نبوده و اجرای غیر صحیح، ناقص یا بدون برنامه ریزی مناسب باعث شکست یا توقف آنها با تحصیل هزینه های هنگفت می گردد. علی رغم وابستگی زیاد سازمانها به (IT)، باوراین که هنوز کل پروژه های IT، به نوعی با شکست مواجه می شوند مشکل است. مطالعات نشان می دهد که بالغ بر 50 درصد پروژه های فن آوری اطلاعات شکست می خورند، 83 درصد از آنها اهداف تحویل و قیمت را محقق نمی کنند و بیش از 30 درصد آنها قبل از تحویل به طور کامل منحل می شوند. و این در حالی است که شکست یا موفقیت پروژه (IT) توان تاثیر روی تمام افراد درگیر در پروژه، از تیم پروژه گرفته تا کل سازمان و نهایتا مدیریت عالی را دارا است. پروژه های (IT) موفق منابع قابل سنجشی را برای سازمان داشته و پیشرفت شغلی افرادی را که در این نوع پروژه ها کار می کنند، بهبود می بخشند، در صورتیکه پروژه های ناموفق از لحاظ راهبردی به دلیل شکست در ایجاد تغییر و به لحاظ عملیاتی به دلیل شکست در ارائه راه حلهای قابل اجرا که خواسته های سازمان را برآورده می سازند در سازمان عدم اطمینان بوجود می آورند.
به منظور برنامه ریزی جهت رسیدن به موفقیت بایستی دلایل و عوامل شکست پروژه های (IT) را شناخت و درک کرده، با مشخص شدن راهبرد دفاعی ما در برابر شکست و تعیین عوامل موفقیت می توان با استفاده از مناسبترین روشها به ایجاد موثر پروژه های (IT) مبادرت ورزید. این مقاله تلاشی است در جهت تبیین عوامل شکست و در نتیجه عوامل موفقیت در اجرای پروژه های (IT) در سازمانها و شرکتها.
تقسیم بندی انواع پروژه های (IT):
از مواردی که در موفقیت یا شکست پروژه های (IT) موثر است خود پروژه می باشد. پروژه ها را می توان از نظر اندازه، سطح تکنولوژی و ماهیت تقسیم بندی نمود. از نظر اندازه پروژه ها به سه دسته کوچک، متوسط و بزرگ تقسیم می شوند.
از نظر سطح تکنولوژی پروژه ها به 4 گروه پروژه های بر اساس تکنولوژی تکامل یافته، نسبتا تکامل یافته، پیشرفته و بسیار پیشرفته تقسیم می شوند. از نظر ماهیت می توان آنها را به 4 دسته پروژه های ساده، فازی یا مبهم، قطعی و اضطراری تقسیم کرد. بدیهی است که پروژه های کوچکتر از پروژه های بزرگتر و پروژه هایی با تکنولوژی تکامل یافته نسبت به پروژه های بسیار پیشرفته از ریسک کمتر و در نتیجه احتمال شکست پائین تری برخوردار هستند.
1- پروژه های ساده:
این نوع پروژه ها دارای مشخصات زیر می باشد:
1- طرح و برنامه مفصلی برای کل پروژه وجود دارد.
2- تمام منابع لازم برای تکمیل پروژه در دسترس است.
3- بر عملیات کاری موجود تاثیر کمی دارد.
4- برای اجرای آن، یک راه حل واحد و واضح وجود دارد.
پروژه های ساده، معمولا به گام های طویل امکان سنجی و تحقیق که برای پروژه های پیچیده تر ضروری هستند، نیاز ندارند، ولی با این حال، باید بازنگری ها و کنترل های منظمی بر پروژه انجام گیرد تا از متمرکز ماندن پروژه بر برآورده ساختن اهداف کاری و بالاتر از همه اجرای آن اهداف اطمینان حاصل شود. در این نوع پروژه احتمال شکست کم است و از اطمینان بالا و ریسک پائینی برخوردار است.
2- پروژه های فازی یا مبهم:
پروژه های فازی از آن دسته پروژه هایی هستند که در آنها جزئیات آنچه که بایستی اجرا شود و هم چنین نحوه انجام کار مشخص نیست، بنابراین صفت مشخصه پروژه های فازی، نیاز به اجرا و تکرار گامهای امکان سنجی و تحقیق، تا زمانی که بتوان شناخت کافی از وضعیت بدست آورد باشد. بدیهی است که این نوع پروژه دارای ریسک بالا بوده و احتمال شکست زیاد است.

3- پروژه های قطعی:
این نوع پروژه ها، وقتی بوجود می آیند که سازمان ملزم شود خواسته مشخصی را برآورد سازد، ماهیت این خواسته ها چنان است که تا وقتی برآورد نگردد بعید است سازمان یا شرکت بتواند بکار خود ادامه دهد، ریسک در این پروژه ها بالا و احتمال شکست زیاد است.
4- پروژه های اضطراری:
مواردی پیش می آید که بایستی مجوز پروژه ها را سریعاً صادر و هر چه زودتر آنها را آغاز کرد. پروژههای اضطراری ریسک بالایی دارند ولی در صورتی که به خوبی سازماندهی و مدیریت شوند احتمال شکست پائین است.
انواع شکست پروژه های (IS):
شکست پروژه های (IS) می تواند از طریق یک یا چند مورد از رویدادهای زیر شناخته شود:
1- کاهش توان کاری موجود
2- کاهش مزیت رقابتی
3- افزایش هزینه های عملیاتی
4- شکست در برآورده ساختن خواسته های اصلی کاری
5- سطوح پائین رضایت کاربر
6- عدم کنترل بر مدیریت خواسته ها
7- عدم کنترل بر برنامه ریزی
محیط و دامنه شکست پروژه های (IS):
محیطی که در آن پروژه انجام می شود در بردارنده راه حل چگونگی افزایش احتمال موفقیت پروژه است.
که به سه دسته تقسیم می شود، محیطی که از پروژه پشتیبانی می کند. محیط موسسه و محیط تجارت پروژه های (IS) صرفا در نتیجه مدیریت نامناسب پروژه با شکست مواجه نمی شوند. پروژه های (IS) موفق متکی به هم راستایی و هم افزایی اجزا بسیار متفاوتی از محیطهای مذکور است که بعضی از آنها نظیر راهبرد (IT) و رفتار طرفهای ذی نفع درون سازمان مربوط به داخل سازمان بوده و بقیه عوامل خارجی است نظیر سیاستها <– مجموعه قوانین صنایع و رفتار تامین کنندگان. آنچه که واضح است، این است که بسیاری از عواملی که بر موفقیت پروژه تاثیر می گذارند، خارج از حوزه مدیریت پروژه قرار دارند.
هر چند تمام طرفهای ذی نفع درون پروژه دارای اهمیت هستند، ولی در نهایت مشتری است که نقش رهبری را در سرتاسر چرخه عمر پروژه ایفا می کند. در واقع مشتری به مانند یک ذی نفع خارجی است.
ولی پروژه های بسیاری نیز وجود دارد که در آنها مشتری یک ذی نفع داخلی است. همانند پروژه هایی که در یک بخش از سازمان برای کمک به بخش دیگر انجام می گیرد.
برخی علل اصلی شکست پروژه های :(IS)
متاسفانه علی رغم منافعی که می توان به واسطه استفاده موثر از (IT) در سازمان بدست آورد، تعدادی از مدیران سازمان، نقش (IT) را بصورت زیر می بینند.
1- یک بلای اجباری که برای خودکار کردن وظایف بزرگ تکراری و عادی مورد نیاز است.
2- تلف کردن مقادیر قابل توجهی پول.
3- نداشتن منافعی برای سازمان.
4- غیر منعطف و مانع تغییرات سازمانی.
5- بی توجه نسبت به روشهای اصلی و کنترل مالی.
این دیدگاهها باعث می شود که وظیفه (IT) در بسیاری از سازمانها با سایر وظایف بیگانه شده و علل اصلی شکست پروژه های (IS) از این جا سرچشمه می گیرد که عبارتند از:
1- فقدان رابطه روشن بین راهبرد سازمان و راهبرد (IT).
2- شکست برنامه ریزی سیستم های اطلاعاتی در اینکه جزو فرایند برنامه ریزی سازمان شود.
3- فقدان ارتباط و مشارکت بین (IT) و سازمان که به کاهش بیشتر تعهد و حس از خود دانستن پروژه (IT) می شود.
4- شکست در پی گیری منافع و خواسته ها.
بنابراین، بدیهی است که برای موثر بودن راهبرد (IT) بایستی با راهبرد سازمان همسو شود تا مدیران شرکت و سازمان تشویق شوندو برای اطلاعات به عنوان یکی از منابع سازمان ارزش قائل شود و طی اجرای راهبرد (IT) موارد زیر را اجرا کند:
1- آگاه کردن افراد کلیدی از روش اطلاعات.
2- نشان دادن اینکه چگونه (IT) می تواند به ارزش افزوده عملیات کاری اضافه کند.
3- فراهم کردن مبنایی برای اصلاح و بهبود فرایند کاری.
عوامل شکست پروژه های (IT):
با بررسی اخیری که توسط شرکت خدماتی و مشاوره KPMG انجام شده، 6 عامل اصلی شکست پروژه های (IS) مشخص شده:
1- برنامه ریزی ضعیف پروژه 2- طرح توجیهی ضعیف 3- عدم درگیری و پشتیبانی مدیریت ارشد 4- عدم درگیری کاربر 5- تازه بودن تکنولوژی برای سازمان 6- عدم از خود دانستن پروژه
هر یک از عوامل ممکن است موفقیت پروژه را به شیوه های گوناگون به خطر بیاندازد، منتهی 1 یا چند مورد از این عوامل می تواند در نهایت آنقدر ریسک پروژه را افزایش دهد تا از آن پس آنرا بی فایده سازد، در صورت بروز چنین وضعیتی خاتمه ی زود هنگام پروژه تنها راه حلی است که برای سازمان باقی می ماند.
با بررسی دقیق تر می توان عوامل اصلی شکست پروژه های (IS) را که برای سازمان، عوامل داخلی محسوب می شوند در دو حوزه شکست پروژه و شکست مدیریت پروژه، تقسیم بندی نمود.
هر یک از این عوامل می تواند ناشی از شکست انسانی، فنی و یا فرایند باشد.
1- عوامل شکست پروژه:
1- مالکیت ضعیف پروژه (شکست انسانی)
2- تکنولوژی تکامل نیافته یا تثبیت نشده (شکست فنی)
3- عدم درگیری کاربر (شکست انسانی)
4- طرح توجیهی ضعیف (شکست انسانی)
5- ارتباطات ضعیف (شکست انسانی)
6- شکست در بررسی فرایندها و اهداف سازمان قبل از بکارگیری تکنولوژی
2- عوامل شکست مدیریت پروژه:
1- مدیریت پروژه بی تجربه (شکست انسانی)
2- برنامه ریزی ضعیف پروژه (شکست فرایند)
3- مدیریت ضعیف خواسته ها (شکست فرایند)
4- وابستگی به ابزارهای مدیریت پروژه (شکست فنی)
5- عدم وجود تاریخ پایان کار (شکست فرایند)
6- رهبری ضعیف (شکست انسانی)
7- آزمایش ناکافی (شکست فرایند)
1- عوامل شکست پروژه ها:
1-1- مالکیت ضعیف:
هر پروژه ای باید با میزان مشخصی از پاسخگویی و مسئولیت از جانب کسانی که درصدد کسب منافعی از پروژه هستند، همراه باشد. در این ارتباط به ویژه مالک / حامی مالی پروژه (IS)، نقش مهمی دارد که دست کم باید نیاز به پروژه را درک کرده و توجیه کند، ریسکهای آنرا ارزیابی و مدیریت نماید و از لحاظ مالی آنرا تامین کند.
با وجود نقش مالکیت در پروژه در اکثر موارد ضعیف بوده و بدتر از همه اینکه گاهی اصلا وجود ندارد.
مدیران ارشد اجرایی، از لحاظ پیگیری پیشرفت پروژه و هزینه های آن در سازمان، از جایگاه خوبی برخوردارند، ولی اغلب در انجام اینکار شکست می خورند، یا اینکه آنرا خیلی دیر انجام می دهند.
1-2- تکنولوژی تکامل نیافته یا تثبیت نشده:
همانطور که قبلا اشاره شد، پروژه های IS را می توان از نظر فن آوری به 4 گروه تقسیم کرد.
1- تکنولوژی تکامل یافته
2- تکنولوژی تقریبا تکامل یافته
3- تکنولوژی پیشرفته
4- تکنولوژی بسیار پیشرفته
تکنولوژیهای پیشرفته و بسیار پیشرفته در لبه پیشرفته توسعه قرار دارد، و معمولا تکامل یافته هستند، هر چند تکنولوژی، با سرعت شگفت انگیزی پیشرفت کرده، ولی سرعت تغییرات، اثر منفی بر روی پروژه های IT گذاشته است. آرزوی بدست آوردن رهبری، نقطه ضعف سازمانهای بسیاری است که تصور می کنند آخرین چیز، بهترین چیز است. در سال 1980 تکنولوژی MACH-HYPED CLIENT SERVER به گونه ای تاثیرگذار موجب شکست پروژه های IS بسیاری در سازمانهای بزرگ شد. در آن زمان، غالبا بدون توجه به مخاطرات استفاده از تکنولوژی تکامل نیافته، رایانه های بزرگ بسیار قدرتمند و مطمئن جایگزین شد. در طی چند هفته و در بعضی موارد در طی چند روز بسیاری از سازمانها دریافتند که به دلیل شکست سیستم های جدید در فائق آمدن بر بار کاری روزانه سازمان، ادامه کار غیر ممکن است.
1-3- عدم درگیری کاربر:
پروژه های IS، به منظور برآورده ساختن اهداف سازمان آغاز می شوند. این پروژه ها در ابتدا ممکن است بر اهداف راهبردی متمرکز شوند، ولی در نهایت، پروژه بایستی اهداف را در یک سطح عملیاتی برآورده سازد، و این به معنای درک نقشها، مسئولیتها و خواسته های کاربران است، پروژه تکنولوژی مدار بر خلاف پروژه ی کارآمد نمی تواند در برآورده شدن اهداف سازمان امیدوار باشد. پروژه های تکنولوژی مدار، اغلب تکنولوژی را توسعه می دهد که اهداف (IT) را برآورده می سازند. پیامد اصلی این پروژه های تکنولوژی مدار، عدم درگیری زیاد کاربر در سرتاسر پروژه است. هر چند تکمیل قسمت پیچیده کد برنامه ممکن است به خوبی موجب به حرکت درآوردن گروه اصلی بشود، ولی این نیازهای کاری است که باید در ابتدا برآورده شود و با افرادی که باید از آن استفاده کنند آغاز شده و به پایان برسد. در واقع آزار و اذیتی که کاربران درون سازمان از یک سیستم جدید متحمل می شوند، یکی از دلایل اصلی شکست پروژه های IS در تحقق منافع بالقوه شان است.
1-4- طرح توجیهی ضعیف:
یک طرح توجیهی قوی یا منافع قابل سنجش برای توجیه سرمایه ای که باید برای اجرای آن صرف شود، لازمه موفقیت آمیز بودن پروژه است. طرح توجیهی باید به وضوح از راهبردهای تجاری و IT سازمان پشتیبانی کند. در طرح پیشنهادی، باید در مورد نحوه پشتیبانی بی واسطه پروژه از اهداف راهبردی سازمان، توضیحات روشنی وجود داشته باشد، در عمل بسیاری از سازمانها یا از راهبرد تجاری مشخص استفاده نمی کنند یا در هیئت مدیره آنها، یک مدیر اجرائی IT وجود ندارد.
1-5- ارتباطات ضعیف:
یک سازمان موفق، به داشتن شبکه های ارتباط موثر بین کارکنان، سرپرستان و مدیریت ارشد وابسته است. این مطلب در مورد یک پروژه IS نیز صادق است، ارتباطات، شاهرگ حیاتی پروژه محسوب می شود، و بدون آن، قابلیت تصمیم گیری موثر به شدت به مخاطره می افتد. شکست در آزمایش فرایندها و اهداف کاری موجود قبل از استفاده از اهرم تکنولوژی دریک سازمان، جدایی از روشهای کاری موجود نمی تواند موفقیت پروژه را تضمین کند. استفاده از IT در یک سازمان نیز فقط در صورتی می تواند فایده ای در برداشته باشد که از فرایندها و روشهای کاری موجود یا جدید پشتیبانی کند. و همینطور در صورتیکه این فرایندها و روشها در سازمان به طور موثر و کارآمد عمل کنند می توانند مفید واقع شوند. بنابراین تجزیه و تحلیل فرایندها و روشهای کاری، قبل از توسعه سیستمهای (IT) در جهت خودکار کردن آنها از اهمیت خاصی برخورداراست. اگر پیش از توسعه IT، در روشهای کاری مشکل وجود داشته باشد نظیر گلوگاه های فرایند، وارد نمودن سیستم IS به سازمان، احتمالا ارزش چندانی در برنخواهد داشت، و موجب بروز اشتباهاتی خواهد شد.
2- عوامل اصلی شکست مدیریت پروژه:
1-2- مدیران پروژه بی تجربه:
مدیریت ضعیف باعث کاهش کارآیی و افزایش قیمت پروژه IS می شوند و تایید آن از هر عامل دیگری بیشتر است.
مهم ترین عامل موفقیت پروژه IS استعداد و توانایی مدیر پروژه است، زیرا مسائل مهم امروز مسائل فنی نیست بلکه مسائل مدیریتی است.
مدیران پروژه بی تجربه، فاقد قدرت ارتباطی، راهبری و مدیریت قوی هستند، متاسفانه معیار انتخاب مدیر پروژه در بسیاری از سازمانها صرفا بر اساس صلاحیت فنی است و مسلما چنین سازمانهایی، برنامه نویس یا تحلیل گری بسیار ماهر را بدون توجه به شرایط مدیریت پروژه، به این سمت منصوب می کنند.
2-2- برنامه ریزی ضعیف پروژه:
عدم برنامه ریزی صحیح پروژه، علت اصلی بسیاری از پروژه ها می باشد، در واقع مدیریت نامناسب، ریسک و طرح ضعیف پروژه، از علل عمده ی برنامه ریزی ضعیف پروژه است. عوامل مشخص کننده برنامه ریزی ضعیف عبارتند از:
1- عدم تعریف دقیق اهداف پروژه
2- عدم در نظر گرفتن منابع مورد نیاز
3- عدم همگرایی در برنامه پروژه
3-2- مدیریت ضعیف خواسته ها:
پروژه های IT در موارد مختلفی همچون اهداف فنی، مالی و تجاری مورد استفاده قرار می گیرند. لذا خواسته ها در سطوح مختلف از پروژه ها قرار دارند. در محیط پروژه های IT خواسته ها ممکن است به دلیل نوع پروژه تغییر کند ولی آنها را می توان به 4 گروه خواسته های عملیاتی، خواسته های فنی، خواسته های تجاری و خواسته های فرایندی تقسیم کرد، پایه و اساس استقرار سیستم IT مدیریت خواسته هاست. هدف مدیریت خواسته ها، تضمین تطابق توانایی های حاصل از پروژه های IS با انتظارات کاربران بر طبق محدودیت های امکان سنجی راهبرد سازمان، استاندارهای قانونی و دیگر عوامل محدود کننده است. در مرحله گردآوری خواسته ها تعداد بسیار زیادی خواسته بوجود خواهد آمد که باید آنها را اولویت بندی کرد. بسیاری از پروژه های IS بدین خاطر شکست می خوردند که دامنه آنها بسیار وسیع است ولی با گذشت چندین سال هیچ ارزشی ایجاد نمی گردد. بهتر است از روش MDSCOW استفاده کنیم.
( Must have, should have, can have, won't have)
به عبارت دیگر افزایش قلمرو، نتیجه کوشش ضعیف برای تمرین خواسته هاست.
مشکل، زمانی شروع می شود که اختلاف بین نیازها و خواسته ها نادیده گرفته شود، وقتی خواسته ها مدون و به گونه ای ارائه شوند که تمام طرفهای درگیر در پروژه بتوانند آنها را درک کنند می توان امکان پذیری آنها را ارزیابی نمود. این ارزیابی باید شامل موارد زیر باشد:
1- امکان پذیری فنی (آیا این خواسته را می توان با تکنولوژی فعلی برآورده ساخت؟)
2- امکان پذیری عملیاتی (آیا سیستم می تواند بدون تاثیر بر عملیات فعلی، در محیط کاری پیاده گردد؟)
3- امکان پذیری اقتصادی (آیا خواسته ها را می توان با هزینه هایی که مورد قبول مشتری است، برآورده ساخت؟)
هزینه دوباره کاری بطور قابل ملاحظه ای در چرخه فرایند توسعه ی نرم افزار افزایش می یابد و اگر هزینه های احتمالی توسعه، از منابع حاصل از توسعه سیستم بیشتر گردد، بدون شک پروژه با شکست مواجه خواهد شد، عامل اصلی شکست مدیریت خواسته ها، فرهنگ سازمانی است. سازمانی که فرهنگ آن به تغییرات به عنوان تهدیدی برای وضع کنونی می نگرد اغلب در برابر گردآوری خواسته ها ذی نفع آن مقاومت می کند. تغییرات همه جانبه، باعث تغییرات اساسی در فعالیت های یک سازمان می شوند و این تغییرات نشان دهنده ی ترک آشکار شیوه های موجود در کار هستند.
تعریف خواسته ها در هر پروژه، اغلب مرحله ای است که در آن اشتباهات بسیار ساده و قابل اجتناب رخ می دهد. خطاهایی که در طی مرحله تعریف خواسته ها رخ می دهد، اغلب شناسایی نمی شود. مگر با گذشت زمان که درآن موقع برای اصلاح آنها جدا از تاثیر برنامه های زمانی و بودجه پروژه، بسیار دیر است. برخی از خطاهایی که در این مرحله رخ می دهند. عبارتند از: عدم تسلط کافی بر خواسته ها، کثرت فهرست خواسته ها، تغییر خواسته ها.
4-2- وابستگی به ابزار مدیریت پروژه:
در بعضی از سازمانها، تنها شرط احراز برتری و لیاقت یک مدیر پروژه، توانایی او در استفاده از ابزار مدیریت پروژه است، مهارتهایی همچون ارتباطات، رهبری و فن مذاکره برای تبحر یافتن در استفاده از ابزار مدیریت پروژه، در وجه دوم اهمیت قرار دارد. جذابیت کار با ابزارهای نرم افزاری به قدری افزایش پیدا کرده که اغلب آنها مهمترین جنبه ی مدیریت پروژه به نظر می رسند.
یک مدیر پروژه ضعیف با استفاده از ابزار نرم افزاری اشتباهات بیشتری خواهد داشت، در صورتیکه یک مدیر پروژه خوب با استفاده از چنین ابزاری کنترل بیشتری بر روی پروژه خواهد داشت.
5-2- عدم وجود تاریخ پایان کار:
اگر پروژه تاریخ شروع و پایان مشخصی نداشته باشد، مشخص می شود که هنوز درک کافی از برنامه کلی پروژه صورت نگرفته، در صورتیکه پروژه تاریخ خاتمه نداشته باشد، این ریسک وجود دارد که پروژه برای مدت زمانی نامشخص ادامه پیدا می کند. در مواقعی که افراد هنوز باید در پروژه ای که سالها پیش باید تکمیل می شده کار می کنند، معمولا اولین چیزی که از بین خواهد رفت روحیه و انگیزه آنهاست و سرانجام آنچه به عنوان خط مشی خوب آغاز شده به یک کابوس تبدیل می شود.
6-2- رهبری ضعیف:
رهبرانی که در مبحث سازمانها مورد توجه قرار می گیرند عبارتند از: رهبران فرهمند، رهبران خلاق و تیمهای مدیریت ارشد.
پروژه ای که در آن فقط مدیریت صورت می گیرد پروژه موثری نخواهد بود، پروژه های موفق به جای مدیریت افراطی نتیجه رهبری قوی هستند.
7-2-آزمایش کافی:
انجام آزمایش برای موفقیت هر پروژه تکنولوژیکی مورد نیاز است. علی رغم بهترین طراحی ها و برنامه ریزی های فنی کاستی ها، خطاها و مشکلاتی ممکن است بروز کند. یک فرایند تست برنامه ریزی شده می تواند باعث جلوگیری و رفع خطاها و مشکلات شود، انجام برنامه تست باعث تحقق موارد زیر می شود:
1- اطمینان از تطابق عملکردها با طراحی ها.
2- اطمینان از تحقق خواسته های کاربران.
3- حذف مسائل اشتباهات و کاستی ها.
در صورتیکه فعالیتهای برنامه ریزی و توسعه نرم افزار از برهه های زمانی تعیین شده، بیشتر طول بکشد این امر اغلب به زیان برنامه زمانی آزمایش تمام خواهد شد. چون وقتی تکمیل فعالیتهای توسعه چندین ماه طول بکشد، به احتمال زیاد، آزمایشها ظرف چند روز به طور ناقص انجام خواهند شد، تا موعدهای تحویل رعایت گردند.
آزمایش فعالیت بسیار با اهمیتی است و مسئولیت آن به جای کاربران به عهده گروه توسعه ی نرم افزار گذاشته شده است ولی این یک اشتباه بزرگ است. چون توسعه گران نرم افزار سطح تخصصی کار مربوطه را ندارند.
عوامل موفقیت پروژه های IT:
عوامل موفقیت وابستگی کامل به عوامل شکست دارد، همانطور که از مطالب قبلی مشخص شد عوامل موثر شامل مدیریت خواسته ها، برنامه ریزی پروژه، فرایندها، مدیریت منافع، افراد و تست می باشد، در ادامه پیشنهاداتی در مورد این عوامل جهت کسب موفقیت آورده شده است:
1- مدیریت خواسته ها:
1-1- تهیه لیست خواسته ها: خواسته های عملیاتی بایستی توسط کاربران نهایی یا مشتریان، خواسته ها فنی توسط کارمندان فنی، خواسته های تجاری توسط کاربران نهایی و مدیریت، و خواسته های فرایندی بایستی توسط کارمندان IT و پروژه تهیه شود.
2-1- اولویت بندی خواسته ها بر اساس میزان ضرورت آنها.
3-1- استفاده از هر نوع ابزار برای حصول اطمینان از درک خواسته ها توسط مشتری و تامین کننده.
4-1- عدم انجام فعالیتهای اصلی قبل از مشخص شدن مشخصات خواسته ها.
5-1- تامین اعتبار آنها.
2- برنامه ریزی پروژه:
1-2- حصول اطمینان از وجود یک طرح توجیهی درست.
2-2- بررسی ماهیت پروژه با توجه به محدودیت های زمانی.
3-2- کسب پشتیبانی مدیر اجرایی برای پروژه.
4-2- تشکیل تیم پروژه با افراد مناسب.
5-2- تهیه یک برنامه اجرایی مناسب.
6-2- تعیین شرایط موفقیت برای پروژه.
7-2- درگیر کردن افراد ذی نفع در کار.
8-2- تعیین مکانیزم های کنترل برای پیگیری
9-2- حصول اطمینان از شناسایی و پیگیری مسائل و ریسکها
10-2- در نظر گرفتن زمان کافی برای بازنگری و تجدید نظر در برنامه
11-2- جلوگیری از تاخیر در پروژه بخاطر مخاطرات ناشی از تغییرات تکنولوژیک
12-2- انعطاف پذیر کردن برنامه های پروژه به قدر کافی برای استفاده از تغییرات تکنولوژیک
3- فرایندها.
4- مدیریت منافع:
1- تعریف موفقیت در ابتدای پروژه 2- شناسایی و به کمیت در آوردن منافع 3- طراحی پروژه 4- در نظر گرفتن زمان پروژه 5- ارزیابی دائمی منافع 6- محسوس نمودن منافع 7- ارزیابی تاثیر IT در حوزه های کاری سازمان 8- آماده سازی روحی و جسمی سازمان. 9- مبنا قرار دادن بودجه پس از توافق و پیش بینی هزینه ها.
5- افراد:
1- هر پروژه بایستی از حامی پروژه برخوردار باشد که بتواند از آن در کل سازمان و هم در بخش IT و همچنین کاربران نهایی حمایت کند.
2- تقویت مدیریت پروژه برای پذیرش ریسکها و تصمیم گیری ها 3- تقویت مدیر پروژه برای نه گفتن به وسیله تغییر فرهنگ سازمانی 4- عدم استفاده از پیشینه رابط ضعیف بین سازمان و جوامع IT برای بهانه ای برای شکست 5- استخدام افراد مناسب در تیم پروژه 6- ایجاد فرهنگ عدم سرزنش در پروژه
6- آزمایش :
1- تعریف خواسته های آزمایش
2- تعیین اهداف و مقاصد
3- انتخاب روشهای تست
4- تهیه برنامه تست و اخذ تاییدیه در صورت لزوم
5- تهیه مشخصات تست و اخذ تایید در صورت لزوم
6- ایجاد محیط تست و تهیه لوازم مورد نیاز
7- تهیه گواهینامه های تست و تهیه تاییدیه ها در صورت نیاز
8- زمانبدی تست و تهیه تاییدیه های مورد نیاز
9- توجیه همه کاربران
10- نظارت بر برنامه تست و ثبت نتایج
11- تحلیل نتایج و کاربرد آنها در رفع اشکال و نواقص
مطالعات موردی:
مطالعات موردی نشان میدهد که چطور پروژه های IT حتی وقتی که تعداد معدودی از عوامل اصلی موفقیت رعایت نگردد به سادگی با شکست مواجه می گردند. مطالعات موردی، پروژه شکست خورده یا موفق دولتی یا خصوصی را مورد تجزیه و تحلیل قرار می دهند. هر چند به خاطر محدودیت های قانونی، احکام قضایی و شرایط حقوقی بدست آوردن اطلاعات در مورد پروژه های IT در بخش دولتی یا خصوصی علی الخصوص درایران دشوار است. مواردی نیز که افشاء شده است از ذکر نام و منابع درون آنها به دلایل تجاری و قانونی خودداری شده است. تلاش برای جبران قانونی شکست پروژه های IT و نیز بی میلی نسبت به افشای اطلاعاتی که ممکن است از حساسیت قانونی یا تجاری برخوردار باشند، به نوبه خود مشکلات افراد بسیاری که در جستجوی راهکارهایی برای تعدیل سطح شکست پروژه ها هستند را روشن تر می کند. با این وجود یک نمونه از پروژه های شکست خورده که عوامل بیشتری در شکست آن نقش داشته اند، و به عنوان نمونه در زیر آورده شده است.
سیستم رایانه ای ارسال آمبولانس لندن:
(London Ambulance Service)
این مطالعه موردی، خطرات اجرای راه حل هایی با تکنولوژی بالا را بدون داشتن اطمینان فنی کافی ، سازمان مدیریت و بدون توجه به افراد سازمان نشان می دهد . شکست تماشایی ، ولی تاسف آور سیستم LAS ( سیستم خدمات آمبولانس لندن) ، پیام واضحی به مدیران و حامیان تغییر راهبردی می دهد و آن، این است که پروژه هایی که بدون حمایت و تعهد کامل کاربران پیاده شود. احتمال شکست بالایی دارند. سیستم LAS ، در 1930 پایه گذاری شد که بزرگترین بخش خدمات آمبولانس دنیاست. این سیستم با پوشش دادن مساحتی بالغ بر 600 مایل مربع، به جمعیتی بیش از هفت میلیون نفر خدمات ارائه می کند. در طی یک روز کاری، سیستم LAS بین 2000 تا 2500 پیام تلفنی دریافت می کندکه از این تعداد، بین 1300 تا 1600 پیام از پیام های اورژانسی "999" هستند. این سیستم یک زیرساخت ترابری برای 80 بیمارستان و مرکز اجتماعی فراهم آورده است.که در سال به بیش از 500000 مورد تصادفی و اورژانسی و 3/1 میلیون مورد غیر اورژانسی رسیدگی می کنند.
منطق یک سیستم جدید
استانداردهای ملی ای که توسط ORCON (مشاور پژوهش عملیاتی ) برای اجرای خدمات آمبولانس وضع شده، بیان می دارد که از دریافت یک پیام اورژانس تا مخابره دستور به یک ایستگاه آمبولانس، نباید بیش از 3 دقیقه زمان صرف شود. آمبولانس باید پس از ارسال، ظرف 14دقیقه به محل مورد نظر برسد. LAS ، با سیستم دستی ارسال آمبولانس نتوانست این استانداردها را رعایت کند. خلاصه ای از نحوه عملکرد سیستم دستی می تواند برخی از دلایل عمده آن را نشان دهد.
1. وقتی یک پیام اورژانسی 999 یا پیامی از مرکز کنترل دریافت می شود، منشی کنترل، جزئیات پیام را بر روی یک فرم چرک نویس یادداشت می کند. محل حادثه ونیز مختصات جغرافیایی آن از روی نقشه (اطلس جغرافیایی ) تعیین می شود. این فرم، همراه با دیگر فرم های مشابه بر روی یک نوار نقاله گذاشته شده که آنها را به بایگانی مرکز کنترل حمل می کند.
2. فرم ها گردآوری شده و توسط کارمند دیگری که تصمیم می گیرد کدام تخصیص دهنده منبع باید با توجه به 3 حوزه مختلف لندن (شمال شرق، شمال غرب و جنوب) به آنها رسیدگی کند، بررسی می شوند. در اینجا پیام های بالقوه تکراری نیز شناسایی می شوند.
3. تخصیص دهنده منبع (تخصیص دهنده آمبولانس و ….. )، از روی وضع فعلی و محل هر یک از آمبولانس های درون بخش خود ( با استفاده از اطلاعات ارائه شده توسط اپراتور رادیو و فرم فعالیت هر وسیله نقلیه ) باید تصمیم بگیرد کدام منبع (پزشک اورژانس، آمبولانس، هلیکوپتر و غیره) حرکت کند. سپس اطلاعات ارسالی، بر روی فرم حادثه ثبت و به ارسال کننده داده می شود.
4. پس از آن ارسال کننده با ایستگاه مربوطه تماس گرفته (اگر در آن منبع وجود داشته باشد و یا اگر آمبولانس در حرکت باشد)، دستور حرکت را به اپراتور رادیو می دهد.
با توجه به فشارهای عملیاتی (کاری) و نیز وضعیتی که در آن نمی شد پیام های ورودی را کنترل نمود، LAS از نواقص سیستم موجود به خوبی آگاه گشت که این نواقص عبارتند از :
* مدت زمان شناسایی محل دقیق حادثه از روی جزئیات ناقص یا غیر دقیقی که تماس گیرنده می داد. طولانی بود؛
* پردازش ها و رسیدگی های کاغذی لازم، بسیار زیاد بود؛
* برای شناسایی پیام های تکراری و حوادث خاص ( که به واحد واکنش سریع (RRU )(1 ) یا هلیکوپتر نیاز داشتند) به قضاوت انسانی نیاز بود؛ 1
* وظیفه حفظ جزئیات وضعیت وسایل نقلیه و اطلاعات محل آنها با کمک شهود اپراتور و اطلاعاتی، که از روی فرم های فعالیت، فراهم شود. اغلب غیر ممکن بود.
مقاصد و اهداف سیستم جدید
هدف اصلی پروژه، استقرار یک سیستم تقریبا خودکار جامع بود. با ورود این سیستم، نقش جدید اپراتورهای بخش مرکزی کنترل آمبولانس، دریافت پیام های ورودی و ثبت جزئیات آنها در سیستم می شد. تنها در پیچیده ترین حالتها برای تخصیص بهترین منبع ، به مداخله انسان نیاز می شد، بنابراین سیستم ارسال رایانه ای، فرامین و کنترل های زیر را به طور خودکار انجام می داد:
* ردیابی خودکار وسایل نقلیه؛
* شناسایی و تخصیص خودکار منابع؛
* شناسایی خودکار تلفن های تکراری؛
* مدیریت منابع، عمدتاً موقعیت یابی وسایل نقلیه برای به حداقل رساندن زمان پاسخگویی؛
* نگاشت رایانه ای (موقعیت ) با شناسایی باجه تلفن عمومی.

راه اندازی پروژه
یافتن یک تامین کننده برای توسعه این سیستم، دشوار نبود. پس از علاقه اولیه ای که 35 شرکت نشان دادند، گزینش که از مدیر آمبولانس ها (که چند سال گذشته را مسئول سیستم های LAS بوده ) و یک تحلیل گر قرار داد تشکیل می شد، 17 طرح پیشنهادی دریافت نمود. مدیر اجرایی ارشد LAS بیان کرده بود که نقش مدیر سیستم ها، به مدیر سیستم هایی که به درستی تعیین صلاحیت شده، واگذار می شود- که بدین ترتیب، مدیر فعلی برکنار می شد.
معیارهای مورد استفاده برای ارزیابی پیشنهادهای مناقصه، به صورت زیر اولویت بندی شده بودند :
* توانایی انجام وظایف لازم.
* توانایی به کار بردن توان عملیاتی لازم و رعایت زمان های پاسخگویی.
* سادگی استفاده توسط کاربر .
* قابلیت برگشت به حالت اصلی (برگشت سریع از حالت خرابی به حالت اولیه ) .
* انعطاف پذیری .
* توانایی رعایت جدول زمانی.
* هزینه ها .
* ویژگی های اضافی.
در آگهی مناقصه به تاریخ 7 فوریه 1991 اظهار شده بود که سیستم باید تا ژانویه 1992 به طور کامل پیاده سازی شود در مورد این تاریخ، جای هیچگونه مذاکره ای نبود، چند تامین کننده این تاریخ را زیر سوال برده و همچنین اظهار داشتند که فکر می کنند این تاریخ دست نیافتنی باشد و روشی مرحله ای را برای تحویل، پیشنهاد نمودند، معلوم نیست که آیا این نظرات به دست مدیریت ارشد LAS رسیده است یا خیر.
علی رغم دریافت چند پیشنهاد خوب از تامین کنندگانی شناخته شده، تیم گزینش پیشنهاد کنسرسیوم آپریکات را پذیرفت که متشکل از یک تامین کننده شناخته شده سخت افزار و یک تامین کننده نسبتاً کوچک نرم افزار با نام System Options (SO ) بود. پیشنهاد مناقصه آنها به مقدار قابل ملاحظه ای پایین تر از دیگر پیشنهادها بود: قیمت پایین ترین پیشنهاد بعدی، 05/1 میلیون دلار ( 700000 پوند ) بالاتر بود. چون سیاست LAS ، پذیرفتن پایین ترین پیشنهاد بود، تیم گزینش، چاره دیگری جز پذیرفتن آن نداشت، به رغم اینکه عملاً هزینه ها در انتهای معیارهای پذیرش قرار گرفته بود، هزینه ها به وضوح بسیار بالاتر از مقداری بود که LAS خود را برای قبول آن آماده کرده بود. پیش از ارائه پیشنهاد مناقصه به هیئت مدیرهLAS جهت تصویب آن، تیم گزینش ابتدا آن را برای تصویب، به بخش خدمات آمبولانس دیگری ارائه داد. هر چند ارزیابی فنی پروژه به طورمناسبی انجام گرفته بود، ولی هیچکس در این تیم وجود نداشت که تجربه خاصی در مدیریت پروژه یا مدیریت قراردادها داشته باشد.
سرانجام هیات مدیره پیشنهاد مناقصه را پذیرفت و تصویب نمود، ولی هیچ نشانی از گفتگو درباره فرایند انتخاب تامین کننده، شایستگی تامین کننده و مقایسه این هزینه به غایت پایین، با قیمتهای پیشنهادی، وجود نداشت.
وقتی پروژه راه اندازی شد، گروه پروژه تغییر پیدا کرده و نقش های زیر را شامل گردید :
* مدیر خدمات پشتیبانی.
* تحلیل گر قراردادهای LAS .
* مدیر خدمات اتاق کنترل .
* مدیر عملیات .
* مدیر آموزش.
* مدیر روابط عمومی.
* نماینده شرکت خدمات فنی و ارتباطی (ارتباطات ).
* پشتیبانی اداری.
* نمایندگان تامین کننده.
در حالیکه به نظر می رسد بسیاری از بخش های LAS ، در این گروه حضور دارند، هیچ نماینده ای از طرف کاربران (خدمه آمبولانس ) در گروه وجود ندارد. همچنین با توجه به حجم کاری که توسط تامین کننده صورت می گیرد، تعجب آور است که در این گروه هیچ نقشی از مدیر قراردادها به چشم نمی خورد.
مدیریت پروژه
تصور شرکت SO به عنوان پیمانکار رهبر، این بود که نقش مدیریت پروژه با اوست چون در قرارداد هیچ اشاره خاصی به این موضوع نشده بود. ولی وقتی اجرای پروژه آغاز شد، این نقش به نقشی مبهم تبدیل گشت : SO در صدد برآمد تا ورودی های خود به پروژه را به گونه ای مدیریت نماید تا LAS را وادار به پذیرفتن مسئولیت مدیریت پروژه گرداند. تامین کنندگان تصریح می کنند که در واقع مدیریت پروژه با LAS است، چون مدیر خدمات پشتیبانی و تحلیل گر قرار دادها، آمادگی انجام آن را داشتند. هر چند مدیر خدمات پشتیبانی، نهایت سعی خود را می نمود، ولی بدیهی است که یک مدیر پروژه حرفه ای خیلی زودتر می تواند ریسکهای بزرگ مرتبط با راه حل پیشنهادی، انتخاب تامین کننده و محدودیت ها و بازه های زمانی را شناسایی کند.
LAS قصد داشت از روش مدیریت پروژه PRINCE استفاده کند، ولی هیچکس در LAS تجربه به کارگیری این روش را نداشت. از این رو برای رفع این مشکل، یک دوره آموزشی کوتاه مدت PRINCE برای گروه پروژه گذاشته شد. با توجه به حجم کار، این عمل متاسفانه نامناسب به نظر رسید وبرای پروژه زیان بار تشخیص داده شد.
در جلسه گروه پروژه در 17 ژوئن 1991، چند موضوع بالقوه نگران کننده مطرح شد و مورد بررسی قرار گرفت. این موضوعات، اثر قابل ملاحظه ای بر موفقیت پروژه می گذاشتند.
* از طرف LAS هیچ فردی به طور تمام وقت در پروژه کار نمی کند.
* نبود توضیح رسمی در رابطه با نحوه اعمال روش PRINCE .
* نبود برنامه ای رسمی برای جلسات گروه پروژه و سایر جلسات.
* نگرانی در مورد انتخاب متهورانه بازه های زمانی برای پروژه؛ شش ماه، در مقایسه با متوسط صنعت (18 ماه ) برای این نوع پروژه بسیار کوتاه بود.
* در برنامه تامین کننده، هیچ زمانی برای بازنگری و تجدید نظر گنجانده نشده بود. هر چند این موضوعات در مراحل اولیه پروژه مطرح گردیده بود، ولی هیچ مدرکی وجود ندارد که آنها پیگیری شده یا به اطلاع مدیریت ارشد رسانده شده باشند.
عجیب آنکه در حالی که هنوز شناخت کمی نسبت به نحوه اعمال روش های PRINCE در پروژه وجود داشته، استفاده از PIR (ثبت مسایل پروژه ) واقعا صورت پذیرفته است. آنچه شگفت آور است، این است که کنترل و مدیریت مسایل موثر بر پروژه به عهده SO ، تامین کننده پیشتاز نرم افزار گذاشته شده بود. ولی بنا به پیشنهاد مدیر جدید سیستم های LAS (که البته برای این پروژه منصوب نشده بود) سیستم PIR نهایتا تحت کنترل گروه پروژه LAS قرار گرفت. علی رغم استفاده از سیستم ها PIR ، 1513 مشکل ثبت شده تنها بخشی از مسایل پروژه بود.
توسعه سیستم
تعیین مشخصات خواسته های سیستم ( SRS )، در 1990 انجام گرفت و طرحی مبتنی بر پنج مولفه کلیدی ارائه شد :
* سیستم ارسال رایانه ای (CAD )
* سیستم نمایش نگاشت رایانه ای
* سیستم موقعیت یابی خودکار وسایل نقلیه (AVLS )
* پایانه های متحرک نمایش داده ها (MDT )
* سیستم رابط رادیویی (RIFS )
دو مورد از این مولفه ها (MDT,RIFS ) قبلا در نتیجه تلاش بی فرجام برای خودکار نمودن عملیات LAS راه اندازی شده بود. کارکرد طرح پیشنهادی، به غایت بالا و پیچیده بود. با این طرح نه تنها برتری بیشتری نسبت به تلاش شکست خورده قبلی برای خودکار سازی تشخیص منابع داشت. بلکه پیشرفته تر از دیگر سیستم های قابل مقایسه در انگلستان بود.
SRS ، خود ماهیتی به غایت تجویزی (دستوری ) داشت که منعکس کننده فرهنگ سازمان و امکان محدودی را برای دیگر ایده های تامین کنندگان احتمالی فراهم می کرد. هیچ مدرکی مبنی بر تصویب رسمی SRS وجود نداشت. سخت افزار رایانه ای که باید از سیستم CAD پشتیبانی می نمود، بر اساس ایستگاه های کاری آپریکات کار می کرد. که متشکل بودند از پردازنده های 486 با سرعت Mhz 25 (که در آن موقع بسیار قدرتمند بودند ). رابط کاربر با سیستم CAD ، متکی بر ویندوز 0/3 بود که رابط گرافیکی جالبی برای کاربران فراهم می کرد و استفاده هم زمان از چند برنامه را نیز امکان پذیر می ساخت. صفحه نمایش های مورد استفاده در سیستم CAD ، با ویژوال بیسیک نوشته شده بودند که یک ابزار توسعه نرم افزار است که به جای تولید سیستم های سریع کارآمد، برای ارائه سریع نمونه های آزمایشی برنامه های کاربردی، مورد استفاده قرار می گیرد. همانطور که گروه پروژه پی برد، ترکیب بی مورد ویندوز 0/3 با ویژوال بیسیک، مخاطره ای در برداشت که انتظار وقوع آن می رفت.

فرهنگ سازمانی و تغییر سازمانی
روابط صنعتی مابین مدیریت و کارکنان LAS خوب نبود. بی تردید در 1990، در پایان یک مشاجره صنعتی بسیار زیان بار بر سر حقوق، LAS به لزوم ایجاد تغییراتی اساسی پی برد. نگرش مدیریت و خدمه آمبولانس آنقدر متفاوت بود که غالباً در کشمش بودند، خدمه آمبولانس ها احساس می کردند که مدیریت می خواهد حتی به قیمت از بین رفتن عوامل حرفه ای نظیر سرعت پاسخگویی و مراقبت از بیمار که باعث افتخار آنها بود، ضرب الاجل های پروژه را رعایت نماید. در نتیجه، آنها ترغیب نمی شدند که به چالش این ضرب الاجل های سخت و غیر قابل انعطاف تحمیلی بپردازند، چون از "برکناری" یا از وجهه "منفی" پیدا کردن هراس داشتند. طرح کلی سیستم CAD تا حد امکان، فرآیندهای دستی موجود در رابطه با تخصیص منابع اورژانسی را خودکار می کرد. طرح سیستم جدید مبتنی بر فرآیند عملیاتی زیر بود :
1- پیام توسط منشی کنترل ( CA) در یافت و در سیستم CAD وارد می شود.
2- محل پیام توسط دستگاه نگاشت و دستگاه شناسایی باجه تلفن عمومی، شناسایی می شود.
3- سیستم CAD با استفاده از اطلاعات بدست آمده از این پیام، منشی کنترل را از دقت و ضرورت این پیام (1-10 ) و تخصیص ها و منابع مورد نیاز (مثلا هلیکوپتر/ RRU و غیره) آگاه می سازد.
4- با استفاده از اطلاعات مربوط به وضعیت و محل هر وسیله نقلیه، یک الگوریتم قانونمند، مناسبترین وسیله نقلیه را تعیین می کند.
5- منشیان بخش کنترل، منابع (آمبولانس، پزشک و … ) مورد نظر را تخصیص داده و سیستم CAD، اعلان حرکت و جزئیات حادثه را ارسال می نماید.
6- خدمه آمبولانس، به محض کنترل حادثه با فشار کلیدهای مختلف بر روی سیستم MDT (پایانه نمایش داده ها ) خود، سیستم را از وضعیت خود آگاه می سازند. این اطلاعات به همراه اطلاعات AVLS، برای بهنگام نگه داشتن سیستم CAD، مورد استفاده قرار می گیرد تا سیستم از محل و وضعیت دقیق تمام منابع، در هر لحظه مطلع باشد.
آزمایش سیستم و به کارگیری آن
وقتی سیستم اجرا می شد، حداقل دو نوع آزمایش کلیدی وجود داشت که باید انجام می گرفت.
* آزمایش کارکرد، برای حصول اطمینان از اینکه سیستم آنچه مورد انتظار بوده را انجام میدهد.
* آزمایش بار، برای آزمایش توانایی کار سیستم تحت حداکثر بارکاری.
با توجه به ماهیت بحرانی سیستم، از این لحاظ که خرابی های آن می تواند پیامدهای مرگ و زندگی به همراه داشته باشد. کیفیت و کامل بودن آزمایش های انجام شده در پروژه، به خاطر تحویل و پیاده سازی تدریجی و مشروط تجهیزات، مورد تردید بود. هیچ مدرکی مبنی بر انجام آزمایش کامل بر روی سیستم، قبل از اجرای آن در اکتبر 1992 وجود ندارد.
هر چند آزمایش، همیشه به خاطر ماهیت "لحظه ای" عیب ها و نواقص، کار پیچیده ای است، ولی هرگز نباید اجازه داد چنین مرحله مهمی در توسعه سیستم ها نادیده گرفته شود. با توجه به این حقیقت که در آن موقع ابزارهای آزمایش خودکار متعددی وجود داشته که می توانستند به آزمایش چنین سیستم پیچیده ای کمک کنند، عجیب است که هیچ مدرکی دال بر این که چنین کاری انجام شده، وجود ندارد.
به ویژه آزمایش هماهنگی بین زیر سیستم ارسال و زیر سیستم ارتباطات (AVSL,MDT) هرگز به طور کامل انجام نشده بود. در یادداشتی که از طرف معاون عملیات، قبل از تاریخ اجرای اصلی یعنی 8 ژانویه 1992، به تیم حوادث و اورژانس فرستاده شد، آمده بود : پس از آغاز دوره کار سیستم CAD، بازنگری کامل توان شبکه انجام خواهد گرفت. بدین مفهوم که آزمایش، بخشی از پیاده سازی خواهد بود.
پیاده سازی
علی رغم اینکه برنامه ریزی شده بوده که پیاده سازی سیستم در یک مرحله (با شیوه ای مرحله ای که توسط چند تامین کننده رد صلاحیت شده، پیشنهاد شده بود) انجام گیرد، ناتوانی تامین کنندگان در رعایت ضرب الاجل های توافق شده، اتخاذ شیوه مرحله ای جدید را ایجاب نمود :
* مرحله 1. روال های پیام گیری تکمیل شوند، ولی سیستم دستی موجود برای تخصیص و ارسال، مورد استفاده قرار گیرد. نگاشت موقعیت نیز برای کمک به منشیان بخش کد برای شناسایی دقیق تر محل حوادث مورد استفاده قرار گرفت.
* مرحله 2. همانند مرحله 1، ولی با شروع ردگیری وسایل نقلیه با استفاده از AVSL وMDT . ارسال صوتی در این مرحله حذف می گردد.
* مرحله 3. پیاده سازی کامل، یا پیام گیرها به طور خودکار منابع را تخصیص دهند تا امکان رسیدن منابع (آمبولانس و غیره ) در عرض 11 دقیقه میسر شود. در غیر اینصورت، تخصیص دهنده ها شناسایی و تخصیص منابع را به طور دستی انجام دهند. این مرحله، این گونه طراحی شود که کار، بدون استفاده از کاغذ و به جای سه بخش کردن لندن، تمام لندن را پوشش دهد. کارکنان مرکز کنترل نیز بسته به نقشهایشان، در قسمتهای مختلف اتاق گروه بندی شوند.
مرحله 1. بسیار موفقیت آمیز انجام شد، ولی چاپگرهای مورد استفاده، دارای مشخصات تعیین شده نبودند و موجب بروز چند خرابی در سیستم شدند، مثل قفل شدن صفحات نمایش و خرابی های گهگاهی کامپیوتر سرور. این امر، موجب کاهش اعتماد کاربران به یکپارچگی و بی عیبی سیستم شد. این امر به طور منطقی، پیامد اجتناب ناپذیر لزوم برجسته نمودن موفقیتی کوچک ولی قابل توجه در تحویل پروژه مطابق تاریخ اجرای اعلام شده، بود.
مراحل 1و 2 بین ژانویه و اکتبر 1992، به شیوه ای تدریجی در ایستگاههای مختلف آمبولانس لندن انجام گرفت. فهرست زیر برخی از خطاهای عمده ای که در طی این دوره به وقوع پیوست را نشان می دهد.
* گزارش دهی نادرست یا ناقص و ضعیف وسیله نقلیه توسط خدمه آمبولانس؛ به خاطر آموزش ناکافی، خرابی های ارتباطی و اشتباه در استفاده از دستگاه ردیابی.
* خرابی سیستم AVLS شناسایی هر 53 وسیله نقلیه.
* تعیین اشتباه محل آمبولانس؛ مشکلاتی با MDT .
* اضافه بار کانال های ارتباطی.
* ناتوانی سیستم در مواجهه با خدمه هایی که آمبولانس متفاوتی نسبت به آمبولانس تخصیصی دریافت می کردند.
* خطاهای نرم افزاری در نرم افزار پیشنهاد منبع که موجب اشکال در شناسایی نزدیک ترین منبع موجود می شد.
در طی این ماه ها، به دلیل تغییرات و بهبودهایی که در سیستم انجام می گرفت، سیستم هرگز ثبات نداشت. علی رغم فقدان واضح هر گونه کنترل رسمی بر تغییرات و عدم انجام آزمایش کامل سیستم، تصمیم گرفته شد که اجرای کامل سیستم، در 26 اکتبر 1992 انجام شود. در زمان اجرا، هنوز دو PIR وجود داشت که افت خدمات سرور را نشان می داد و سیستم تا زمان رفع این دو PIR ، نمی توانست درست کار کند. باور کردنی نیست که 44، PIR عمده نیز وجود داشت که منجر به سطح ضعیف خدمات به بیماران میشد.
پیاده سازی کامل سیستم
سیستم CAD در 7 صبح دوشنبه 26 اکتبر 1992، نه ماه پس از تاریخ برنامه ریزی شده، راه اندازی شد. مشکلات اولیه وقتی بار کاری سیستم در نوبت کاری صبح افزایش پیدا کرد، بروز نمود. به زودی نیز مشخص شد که به علت وقوع مشکلاتی در دستگاه های فرعی ارتباطی، شناسایی وضعیت وسایل نقلیه و دستگاه های نگاشت، سیستم به تدریج مکان و وضعیت وسایل نقلیه را کمتر و کمتر شناسایی می کند. به علاوه، این سیستم، پیام ها را از دست می داد که منجر به مضاعف شدن تلفن های افراد نگران می شد. همان طور که حجم تلفن ها افزایش می یافت، سیستم به سرعت بی استفاده تر می شد و تلفن کنندگان با یک زمان انتظار 30 دقیقه ای پشت خط نگهداشته می شدند. چون ارتباطات صوتی-رادیویی به صورت محدود پیاده سازی شده بود، مانع از بازخورد به موقع اطلاعات حادثه می شد. به علت تغییرات فیزیکی به وجود آمده در اتاق کنترل نیز توانایی مداخله ستاد اتاق کنترل شدیداً کاهش یافته بود.
چون میزان پیام های استثنائی در طول روز، به علت خطاهای رفع نشده ای که موحب استثناهای جدید می شد، افزایش می یافت تراکم در این سیستم به قدری زیاد شد که لازم بود پیاده سازی کامل به تعویق افتاده و به سیستم نیمه دستی مراجعه شود.
این سیستم تا ساعات اولیه 4 نوامبر 1992 به خوبی کار کرد تا وقتی که به طور قابل ملاحظه ای کند شد و به طور کامل متوقف گشت. تمام تلاش ها برای راه اندازی مجدد آن با شکست مواجه شد و به توصیه مدیریت ارشد بخش مرکزی کنترل آمبولانس به سیستم کاملا دستی و کاغذی، و استفاده از بی سیم و تلفن، روی آورد.
علل شکست پروژه LAS
فشار زمان بندی
در زمان اجرای پروژه، LAS هنوز از پیشینه روابط صنعتی ضعیف، روحیه ضعیف کارکنان و عدم اطمینان در مدیریت رنج می برد. اجرای جسورانه این سیستم که تغییرات سازمانی گسترده ای را بر کاربرانش تحمیل می کرد، بدون درگیری و مشاهده مناسب کاربر، با توجه به ماهیت بحرانی "خدمات آمبولانس" مسلّماً ریسک بزرگی در برداشت. ولی مدیریت LAS تحت فشار زیادی بود تا عملکرد عملیاتی خود را بهبود بخشیده و استانداردهای ORCON را رعایت نماید که بدون شک گروه پروژه را تحت فشار قرار می داد تا راه حلی را هرچه سریعتر اجرا کنند. همیشه زمان کافی برای پیاده سازی سیستم جدید وجود ندارد، ولی سیستم های بسیار زیادی در بدترین زمان یعنی زمانی که سیستم موجود تحت فشار بار کاری زیاد قرار داشته و زمان کافی برای طراحی سیستم جایگزین وجود ندارد، برنامه ریزی شده و پیاده سازی می شوند. پروژه LAS نیز در این دسته قرار گرفت. پیاده سازی مرحله ای که آغاز شد با برنامه ریزی انجام نگرفت، اما بدلیل ناچاری اجرای این مرحله صورت پذیرفت.
سودای رهبری
با توجه به مسایل سازمانی که بر LAS تاثیر می گذاشت و همچنین با توجه به پیشینه ضعیف رابط صنعتی در آن بدیهی بود که مدیران اجرایی LAS این سیستم جدید را به صورت یک "گلوله نقره ای" می دیدند. سیستم جدید نوآورانه و برای LAS تازه و "اولین" محسوب می شد.
هیات اجرایی LAS به عنوان بزرگترین بخش خدمات آمبولانس دنیا در لندن یعنی یکی از مهمترین و با نفوذترین پایتخت های جهان، ابداع سیستم IT جدیدی را می دید که وسیله ای بود برای :
* کاهش هزینه های عملیاتی؛
* کاهش میزان کارکنان؛
* دستیابی به نوآوری فنی؛
* بهبود روابط صنعتی؛
تصور این که استقرار یک سیستم رایانه ای جدید، به تنهایی رفتار کنونی کارکنان را تغییر خواهد داد، از طرف مدیریت LAS یا از روی سادگی بوده یا از روی سوء تفاهم یا خطا. این طرح در نوع خود برای LAS، جهشی در تکنولوژی محسوب می شد، چون نه تنها بسیار فراتر از دامنه پروژه بی نتیجه قبلی بود، بلکه از دیگر سیستم های موجود ارسال اورژانس نیز پیشرفته تر بود. LAS، برنامه ریزی کرد تا در یک مرحله، از عملیات کاملاً دستی، به سمت عملیات کاملاً خودکار حرکت نماید. محور شکست پروژه، طرح سیستمی بود که به تغذیه کامل و بی وقفه داده ها برای کارکردن نیازمند بود؛ افراد همیشه آنچه می گویند را انجام نمی دهند.
(یقیناً در طی پیاده سازی، عنصر خرابکاری وجود داشته)؛ تکنولوژی قابل اعتماد نیست؛ و (کیفیت) اطلاعات ورودی سیستم، بی دقت یا ناقص است.
مدیریت ریسک نامناسب
از اولین روزهای پروژه، بدون انجام فرآیند صحیح مدیریت ریسک، تصمیماتی بحرانی اما بالقوه مخاطره آمیز گرفته شد. انتخاب تامین کننده، بایستی در همان اوایل، زنگ هشدار را برای مدیریت به صدا در می آورد، نه تنها به خاطر حجم کار بلکه به خاطر پیشنهاد قیمت پایین و باور نکردنی تامین کننده در مقایسه با دیگر قیمت های دریافتی. همین طور، فقدان یک مدیر پروژه با تجربه یا مدیر قراردادهای IT در پروژه، بایستی به عنوان ریسکی بزرگ برای چنین پروژه عظیمی شناخته می شد. مدیریت ریسک، به معنای بی رحمی است. مدیریت LAS باید چند سوال صریح از خود می پرسید که یکی از آنها عبارت است از در صورتیکه سیستم به شیوه مورد انتظار کار نکند چه اتفاقی می افتد؟
در اینجا جواب باید اینگونه می بود از دست رفتن بالقوه زندگی (مرگ بیماران)
تضمین کیفیت نا مناسب
در طی توسعه و اجرای پروژه، واضح بود که کارکنان SO رویه ها و تغییرات اجرا شده در سیستم را دور می زنند از این مهمتر، با توجه به اتّخاذ شیوه"بیگ بنگ"، این که سیستم هرگز به طور کامل یعنی از دریافت یک تلفن اورژانسی تا انتقال موفقیت آمیز بیمار به بیمارستان، آزمایش نشده، باور کردنی نیست.
مدیریت پروژه نامناسب
به تعهد تیم پروژه و در حقیقت تعهد مدیریت LAS و تامین کننده پیشتاز نمی توان شک کرد. چون همه آنها در شرایط دشوار، نهایت سعی خود را کردند- ولی عدم مدیریت صحیح پروژه و نبود تجربه در گروه، عامل اصلی شکست در شناسایی و تشخیص اهمیت مشکلات بسیاری بود که درنهایت، چنین اثر تاسف آوری را بر نتیجه پروژه می گذاشت. طبعاً LAS، تصور می کرد که تامین کننده نقش مدیر پروژه را بر عهده خواهد گرفت. ولی این امر اتفاق نیفتاد و یکی از مهمترین فرآیندهای کنترلی در پروژه، بر پایه شانس گذاشته شد.

منابع مورد استفاده :
1- نواده فراهانی. محمدرضا و مصطفی پرخوان رازلیقی، نقش فن آوری اطلاعات در فرآیند مهندسی مجدد کسب و کار، ص 48، تدبیر، شماره 133.
2- How to build a Business For information Technology. Http://gloBal.mci/de/resources/articles/35/keenqa.xml
3- Speak Sizing Guidelines, www.IT toolkit. com
4- Corre latiug Success with the Classitication.
www.ITtoolkit.com
5- yardely,David, Successful IT projects Delivery, Addison- weseley, 2002.
6- wysoki, Roberk.,Building Effective project Teams, John wiley & Sons, INC., 2002.
7- kPMG,what went wrong. Unsuccessful information Technology prjects, 1997,www.kpmg.com
8. why do projects fail,www,etpint.com/whyFail.htm
9. A procecc For projects Requirement, www.IT toolkit.com
10- دفت، ریچارد ال. تئوری سازمان و طراحی ساختار، ترجمه علی پارسائیان، سید محمد اعرابی، موسسه مطالعات و پژوهش های بازرگانی.
11- From project to production : The IT Testing Process, www.IT toolkit, com

1 Rapid Response unit
—————

————————————————————

—————

————————————————————

2