دانلود مقاله آماده سازی سازمان های پروژه ای برای تغییر

چکیده: تحقیق و تمرین مکرراً اثبات می کند که سازمانهای پروژه ای باید برای محیطهای ابداعی که تغییر یک لزوم ثابتی است، آماده شوند.

این سازمانها باید انعطاف پذیر بوده و قابلیت تطبیق پروسه ها و ساختارهایشان با محتوای ظاهر شده را داشته باشند.

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

سرعت و اثر بخشی و مواظب بودن وقایع ایجاد کننده تغییر و آماده شدن برای اجرای تغییر را نشان می دهد.

ما نیز اصول تغییر ساختار بندی شده را برای سازمانهای پروژه ای که تغییر را از بعد عملی تکمیل می کنند پیشنهاد می کنیم.

ما نیز اصول تغییر ساختار بندی شده را برای سازمانهای پروژه ای که تغییر را از بعد عملی تکمیل می کنند.

پیشنهاد می کنیم.

اصول ما نتیجه ترکیبی تجارب خود ما دانش حالت هنر در این زمینه و آزمایش اصول تغییر از طریق یک مورد تحقیق- عمل می باشد.

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

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

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

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

وقتی پروسه های مدیریت پروژه در حال بلوغ فزاینده را درونی می کنیم.

بسیاری از آنها اینکه سازمانهای پروژه ای شوند را پایان می دهند.

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

PBO ها برای محیطهای ناپایدار مناسب تر هستند.

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

همزمان، PBO ها باید پیکربندی مجدد دینامیکی و استنتاج به محیط متغیر سازمانی پاسخ بدهند.

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

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

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

در این پروسه تغییر، مزایای زیادی انتظار می رود مثل افزایش بلوغ پروسه های مدیریت پروژه اش و افزایش سرمایه انسانی و سرمایه سازمانی این مقاله به یک وضعیت مورد واقعی در یک شرکت نیمه رسانا رجوع میث کند که وقایع ایجاد کننده تغییر و اصول تغییر پیشنهادی را یا مثال نشان می دهد.

2-مرور مطالب مدیریت تغییر، بدنه دانش روی رفتارهای تغییر سازمان و چگونگی اجرای موثر تغییرات سازمانی مناسب می باشد.

PBO ها باید چند عامل را تطبیق داده و پروسه ها جدید را وادار به مدیریت پروژه ها بنمانید.

این سازمانها می توانند پارادایم های تغییر زیادی و مدلهای تغییر متعددی را همانطوریکه مولفان شرح داده اند اتخاذ کنند.

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

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

یک PBO معمولاً بر استانداردهای مدیریت پروژه قابل قبول بین المللی که مفاهیم، پروسه ها و برخی از ابزارها، تکنیکها و الگوها را توضیح می دهد، تکیه می نماید.

کاربردی، ترین استانداردهای مدیریت پروژه PMBOK و PRINCE2 هستند که اخیراً برای تکمیل استانداردهای جدید برای مدیریت برنامه و مدیریت پورستفولیو (سهام)، با پیروی از گرایش سازمانهای چند چروژه ای ارتقاء یافته کند.

استانداردهای مذکور عموماً برای انواع صنایع، پروژه ها و انواع سایزهای پروژه و کاربردی هستند برای تسهیل ارزیابی بلوغ پروسه هایشان، این استانداردها، مدلهای دارای قابلیت بلوغ OPM3، P3M3 را خلق کردند که به PBO اجازه درک سریع شکافها را از چه هست تا چه باید باشد را می دهد.

بهرحال این استانداردها یک اصول تغییر برای اجرای چنین پروسه هایی را تشریح نمی کنند.

نهایتاً، یک PBO به پروسه های با کیفیت انعطاف پذیر، اجرا شده با حمایت سیستم ها را اطلاعاتی نیاز دارد.

سازمانها بدون بطور فزاینده ای به IS وابسته هستند.

3-اصول تحقیق همانطور که مدیران پروژه وضعیتهای رایج و درحال بروز را از طریق ترکیبی از حقایق مشاهدات و ارتباطات سخن با سهامداران و عناصر منتخب گروه پروژه درک می کنند، اصولی مثل Action Research در رویکردهای سازنده گرایی یا رویکردهای عمل گرایی برای تئوری سازی ظاهراً کافی به نظر می رسد.

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

بعلاوه طبق الهامات Creswell و Plano Clark این مقاله رویکردی را بر اساس شش روش، یعنی بر کلیه کیفی- روایتی اتخاذ می کنند.

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

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

4-یک مورد از مدیریت تغییر ما برای انعکاسی چگونگی مدیریت تغییر.

از یک تغییر کوچک به یک تغییر بزرگ در سازمانهای پروژه ای یک مورد تغییر واقعی را توسعه دادیم.

این مورد به شرکت IP (املاک هوشمندانه نیمه رسانا) تأسیس شده در 1997 بر می گردد و لیدر جهانی توسعه دهنده IP سیگنال آنالوگ و ترکیبی شده این شرکت دو حق مالکیت را بوسیله شرکتهای عمومی در 2007 و 2009 بدست آورد.

این شرکت، رسماً بخشی از شرکت عمومی است که در IP نیمه رسانا و EDA (اتوماسیون طراحی الکترونیکی) با بیش از هشت هزار کارمند در جهان، لیدروپیشرو است.

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

در روزهای اول، هر سیستم طراحی تکنیکهای مدیریت پروژه تجربی خودش را اتخاذ می کرد و شروع به اتخاذ پروسه های مدیریت استاندارد در اوایل 2005 می کرد.

بعداً در 2006؛ شروع به کشف استفاده ممکن از سیستم های اطلاعات مدیریت پروژه مثل Orcle EPM، Microsft Project server نمود چرا که رشد اضافی بیش از 200 پروژه در سال را داشت .

در طی اولین مالکیت، شرکت پروسه موجودش و مکانیزمهای گسترش را حفظ کرد و با فرهنگ شرکت کسب کنند.

یکسان سازی خوبی انجام نداد.

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

لذا از پایان 2009، برخی از مدیران پروژه شروع به تحکیم دیدگاه سازمان پروژه ای کردند که قادر به گرداندن تعداد بیشتری پروژه و برنامه هایی بود که شرکت باید شرکتهای IP دیگری که تحت تملک واقع می شوند.

مدیریت می کرد.

برای حمایت این دیدگاه پیش الگوی IS کوچکی توسعه یافت تا یکی از سیستم های مهندسی را تشکیل دهد.

این دیدگاه بعداً توسط مدیران ارشد زیادی ارائه و بحث شد.

تنها در آغاز 2011 CIO رسماً برنامه ای را برای اجرای یک سیستم مدیریت پروژه و برای تعیین مسیر کار اجرا شده در پروژه های توسعه محصول و کسب درآمد بر اساس درصد تکمیل کار برای اجرا شدن در 15 ماه بعدی آغاز نمود.

یک سیستم تغییر نیز تشکیل شد که در آن محقق یک همکاری فعال بود.

سیستم مدیریت پروژه جدید با حوزه عملی دیدگاه تعریف شده اجرا شد.

پروسه اجرا رئوس وظایف اصلی را پیروی نمود.

آماده سازی برنامه: تیم IS برای ارتباط با اهداف سیستم جدید و شناسایی سهامداران مهم که تعریف لیست مفصل نیازمندیها همکاری دارند با تیم های مهندسی زیادی تماس گرفت.

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

پیرو استنباط پروسه های جدید و عملکردهایی را که باید تحت حمایت سیستم های اطلاعاتی جدید واقع شوند، تعریف کرد.

طراحی پیش الگوی سازی و تست گیری: تعریف برنامه اجرایی اساساً یک فعالیت IS است که برای استفاده از نرم افزار COTS تصمیم گرفته شده اند.

دلیل اصلی چنین تصمیمی، سرعت اجرا، مشخصات حمایت شده و توانایی تکمیل IS مالی موجود بود.

ارزیابی کاربر: سهامداران کلیدی برای تست سیستم جدید و تست کاربری آن، شرکت کردند.

در طی این مرحله، جلسات زیادی برای انعکاس روی پروسه های تعریف شده و باز تعریف برخی از پروسه ها تعریف شده در مرحله برنامه کاری وجود داشت و بیشتر یا باز تعریف اندکی از وظیفه ضروری در سیکل اول توسعه همراه بود.

آموزش و گسترده سازی: آماده سازی و تجدید نظر موضوعات آموزشی برای کمک به ارتباط با پروسه های جدید و سیستم اطلاعاتی نوین: سیستم عامل تغییر باید به تعریف ترتیب اتخاذ انجام شده تیم های مهندسی بوسیله سیستم اطلاعاتی جدید بپردازد.

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

5-اصول تغییر PBO بعنوان نقطه شروع PBO که می خواهد تغییر را اجرا کند، تغییر باید برای هماهنگ کردن تلاشهای تغییر، یک سیستم عامل تغییر را بوجود آورد، اصول و روشها شناسی شامل 4 مرحله است (شکل 1) و بر اساس و TOGAF و EAP می باشد.

آن با تعریف دیدگاه معماری و مدیران برنامه تغییر آغاز می شود.

لذا جزء بندی زیر- قلمروهای معماری انجام می گردد سوماً تغییرات تعیین محدوده و برنامه ریزی می شوند.

نهایتاً اجرای طرحهای تغییر، مدیریت و ارزیابی می گردند.

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

5-1-مرحله دیدگاه تغییر سیستم عامل تغییر باید یک دیدگاه شروع کننده ساده ای را خلق کند مثل یک دانه ای عمل می کند که برای افزایش نفوذ در سازمان تغییر را رشد داده و بوجود می آورد.

آن باید یک دیدگاه سطح عالی از ساختار PBO باشد، پروسه های کلیدی که باید در مکان خاص خود تعبیه شوند و بر سازمان اثر می گذارند.

اهداف و دیدگاه های محکم تر و جاه طلبانه می توانند در زمانیکه مدیریت ارشد، برنامه تغییر را رواج می دهد و منابع افزایش می یابند.

ایجاد می شوند دیدگاه سطح بالای معماری PBO، پروسه های مدیریت پروژه کاربردی را تحکیم می بخشد.

پروسه های شناسایی شده باید بصورت بلوکهای ساختمانی پروسه گروه بندی شوند مثلاً: مدیریت هزینه پروژه یا تکمیل مدیریت برنامه، و سپس به مراحل زیر تقسیم شوند.

هر پروسه ای که به پروسه های موجود در سازمان متصل است نیز باید شناسایی شود مثلاً پروسه توسعه محصول، HR یا پروسه های مالی، برای اجرای ارزیابی پروسه، PBO می تواند قابلیتهای مدیریت پروژه اش را ارزیابی کند و حتی الامکان از یکی از ابزارهای خود ارزیابی بلوغ مدیریت پروژه مثل P3M3، OPM3 استفاده کند تا ارزیابی سریعی از وضعیت فعل داشته باشد.

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

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

5-2-1-معماری شغلی تجاری معماری شغلی تجاری شامل تمام مشخصات پروسه می باشد.

سازمان می تواند از مدلهای پروسه موجود مثل RetModPM استفاده کند که پروسه های PMBOK را تعیین می کند یا ایستگاه پروسه های مدیریت پروژه خودشان را توسعه می دهد.

کار حد سازی پروسه می تواند توسط دیاگرامهای BPMW (نشانگذاری و مدل پروسه شغلی) انجام شود.

توسعه و یاگرامهای پروسه BPMW یک رویکرد بالا به پایین است که برای هر بلوک ساختمانی پروسه بکار می رود.

5-2-2-معماری داده های سیستم های اطلاعاتی (IS): معماری داده ها، نهادهای دخیل در پروسه های معرفی شده بعنوان بخشی از معماری تجاری شغلی مثل پروژه، جدول زمانبندی، وظیفه کاری را نشان می دهد.

یک راه خوب شناسایی این نهادها، جستجوی هر پروسه و توسعه نموی یک دیاگرام کلاس UML حاوی نهادهای معرفی شده می باشد.

برای هر نهاد جدید، یک کلاس UML خلق می شود که حاوی نام نهاد منحصر به فرد صفات و روابط (انبوه سازی ها و پیوسته سازی ها) می باشد.

یک رویکرد مدلسازی مهم، تضمین نرمال دیتابیس هاست.

داشتن یک طراح دیتابیس با تجربه برای تکمیل و تجدید نظر ورژن نهایی دیاگرام های کلاس می تواند مفید باشد.

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

در این صورت، نیازمندهای انتقال به سیستم اطلاعاتی جدید باید اضافه شود.

این شامل کار آماده سازی روی داده های موجود است یعنی تبدیل، و جین سازی و تنظیم برای آنکه آنها را با فرصت- معماری جدید، با تضمین کیفیت داده ها، قابل تطبیق و سازگار نماید.

5-2-3-معماری کاربرد (اپلیکیشن) سیستم های اطلاعات (IS) معماری کاربرد شامل شناسایی کاربردهای لازم برای حمایت از پروسه ها و نهادهای معرفی شده قبلی است.

برای کمک به شناسایی این کاربردهای مرتبط یک ماتریس عملکرد تجاری شغلی-نهاد داده ها باید خلق گردد.

این روش، روابطی بین نهادهای داده ها و پروسه هایی که کمی از آنها استفاده کرده و یا آنها را دستکاری می نماید، بوجود می آورد.

در هر یک از این روابط ما باید نوع عملیات داده های اصلی لازم برای حمایت شدن را شناسایی کنیم: خلق کنیم بخوانیم، ارتقاء دهیم و پاک کنیم.

وقتی تمام روابط بین نهادها و پروسه ها شناسایی شدند، شناسایی کاربردهای مربوطه با گروه بندی مجموعه روابط معنادار ممکن می شود.

اگر کاربرد فعلی برخی از پروسه ها را حمایت کند.

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

انجام گردد.

هر یک از این روابط، نهادهای داده هایی را نشان می دهد که هر کاربرد ذخیره می کند و پروسه هایی را نشان می دهد که آن را حمایت می کند.

ترتیب بندی نهادهای داده ها و پروسه های شغلی تجاری باید به گونه ای باشند که کاربردها با یکدیگر وجه اشتراکی نداشته باشند.

از انیرو از مضاعف سازی داده ها و وظیفه مندیها اجتناب می گردد.

بوسیله ماتریس عملکرد شغلی- نهاد داده، شناسایی نهادهایی که هرگز خلق نشده اند حتی اگر بوسیله پروسه های مختلف استفاده شوند، ممکن می شود، همچنین یافتن نهادهایی که خلق می شوند ولی هرگز ارتقاء نمی یابند و یا بوسیله هر یک از عملکردهای پروسه خوانده نمی شوند نیز ممکن می شود.

آن می تواند به شناسایی عملکردهای پروسه ای که هنوز بوسیله هیچیک از کاربردهای تعریف شده حمایت نشده اند، کمک کند.

ماتریس عملکرد شغل –نهاد داده جدول I اجازه تعریف حوزه توسعه کاربرد بوسیله شناسایی موارد زیررا می دهد: نیازمندیهای عملکردی، نهادهایی که خلق می کند و اطلاعاتی که باید بین کاربردها مبادله شوند.

5-3-مرحله پلان تغییر 5-3-1-استراتژی توسعه وقتی معماری PBO جدیدی تعریف می شود.

یک استراتژی اجرایی باید برای هر سیستم اطلاعاتی یا یک توسعه مرسوم (سنتی) یا استفاده از یک بسته COTS نیز تعریف شود.

راه حلهای COTS بسیار خوبی برای PBO ها وجود دارد که از پروسه ها حمایت می کنند مثل زمانبندی پروژه مدیریت منابع مدیریت پورتغلیو، راه حل COTS، زمان اجرای IS را ذخیره می کند ولی به یکپارچه سازی و مرسوم سازی بیشتر نیاز دارد.

برای درک کامل قابلیتهای انجام شده توسط COTS، صرف تلاش قابل ملاحظه ای لازم است که ممکن است برای به تعویق انداختن سیکل اجرایی بعدی، مقتضی و مصلحت باشد.

یک توسعه مرسوم (سنتی) می تواند برای یک اجرای سریع و هدف یابی روابط مهم یا منافع گروگذاران خاص بخوبی سایزبندی شود (متناسب سازی شود).

لذا ممکن است به تولید حرکت و جنبش آنها در سازمان و همچنین طی کردن مسیر برای تکمیل بعدی یک راه حل COTS نیز کمک کند.

5-3-2-پلان برنامه سیستم های اطلاعاتی و پروسه های شناسایی شده باید به مراحل اجرایی تغییر مختلفی گروه بندی شوند.

رویکرد نحوی معمولاً با کاربردهای نرمال، سازگارتر است و می تواند به حداقل کردن قطعی ها، کمک کند.

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

وقتی پلان مرحله ای شده کامل شد باید توسط مدیریت ارشد و گروگذاران مربوطه (سهامداران) تجدید نظر و بحث شود.

آنها همگی باید منابع لازم را حداقل برای مراحل اجرایی اولیه تصویب نماید.

5-3-3-خلق آمادگی برای تغییر قبل از شروع، اجرا، زمان درست برقراری ارتباط با حضار و شنوندگان بیشتر است.

حفظ ارتباط مداوم از آنچه که انجام شده و آنچه که انتظار روی دادن می رود، مهم است.

لذا تیم عامل تغییر باید پلان ارتباطی را تعریف کند که خط زمانی وقایع ارتباط و حاضرین لازم در کل مراحل مختلف اجرایی را تعریف و معین می کند.

5-4-مرحله اجرای تغییر اجرای سیستم های اطلاعاتی، کاری است که به مدیر پروژه IS واگذار شده است.

سیستم عامل تغییر، اهداف پروژه را از لحاظ زمانبندی و وسعت تعریف می کند و جزئیات اجرا و اختیارات تکنولوژی نهایی را تجدید نظر می نماید.

ارزیابی سریع پیش الگو می تواند به پالایش نیازمندیهای IS و تسهیل همکاری بین سهامداران کمک کند.

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

هر داده برای انتقال نیازمند آمادگی برای تطبیق با ساختارهای دیتابیس فیزیکی جدید است و تنطیف داده های موجود از ثبتهای داده ای نسخه ای یا غلط نیز لازم است.

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

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

این مقاله با یک اصول اصلی همراه است که یک رویکرد سیستماتیک را برای کمک به تغییر یک PBO ارائه می کند.

اصول پیشنهادی هر دو بعد تغییر را ترکیب می نماید: سخت (پروسه ها، روندها، سیستم های اطلاعاتی) و نرم (انگیزه کارمندان، ارتباط و رهبری) بطوریکه PBO ها می توانند یک سازمان آینده را بخوبی تغییر دهند.

اصول پیشنهادی از یک PBO در کل زنجیره تغییرش با توانمندسازی سازمان در پساخدهی پویا به ایجاد کنندگان تغییر، حمایت می کند.

چون نتایج ارائه شده این مقاله بر اساس مطالعه موردی یک سایمان واقعی بوده است.

ممکن است اعتبار کافی برای اتخاذ اصول تغییر در دیگر سازمانها انداشته باشد.

شاید این مطالعه بتواند به تعریف اصول دیگر تغییر که نیازهای خاص یک PBO را نشان دهد، کمک کند.

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