فرآیند مدیریت ریسک PMBOK از تئوری تا عمل

مقدمه

مدیریت ریسک PMBOK یکی از عبارت‌هایی است که وقتی به گوشم می‌رسد یاد و خاطره 2 سال زحمت و تلاش در ذهنم تداعی می‌کند که فکر می‌کنم حاصل آن، فقط شب‌بیداری و زحمت و … بوده است که اگر نگویم هیچ، ولی حداقل آن انتظاری که من از خودم داشتم رو برآورده نکرد.

روز اولی که با هزار امید و آرزو، پروپوزال پایان‌نامه خود را به تصویب رساندم، هرچند که هدف اولم تهیه پایان‌نامه بود ولی هر جا سخن از پایان‌نامه می‌آمد می‌گفتم باید پایان‌نامه‌ای ارائه بدم که کاربردی باشه و نه اینکه بیافته گوشه کتابخانه و خاک بخوره!!!

غافل از اینکه بعدازاین همه تلاش و کوشش درنهایت همین اتفاق افتاد. پایان‌نامه‌ای ارائه دادم که به نظر خودم یکی از پایان‌نامه‌های عالی در سطح خودش بود ولی عاقبت دچار همان سناریوی از پیش تعیین‌شده هزاران پایان‌نامه‌هایی شد که قبلاً به آن دچار شده بودند.

هدف من از طرح موضوع فوق این نیست که خوانندگان وب‌سایت مدیر پروژه را ناراحت کنم؛ یا در مورد فرآیندهای مدیریت ریسک PMBOK توضیحی داده؛ یا در مورد مدلی که برای توسعه مدل ریسک PMBOK در این پایان‌نامه استفاده کردم و یا تکنیک‌های جدیدی که در SharePoint استفاده کردم، توضیح دهم؛ بلکه هدف من آن است که تجربه‌ای که از این دو سال گرفتم را با دیگر دوستان به اشتراک بگذارم تا دیگران راه اشتباه رفته من را تکرار نکنند و حداقل خودم را راضی کنم که این پایان‌نامه فوق‌لیسانس ما، خاصیت دیگری هم داشته است؟!

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

ارتباط موضوعی با پروژه

اولین سؤالی که ممکن است در ذهن مخاطبان قرار گیرد این است که ارتباط موضوعی این بحث با مباحث پروژه چیست؟

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

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

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

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

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

البته خیلی از موارد موجود در فرآیندهای مدیریت پروژه PMBOK که مدنظر من بود می‌توان در اینجا عنوان نمود ولی یکی از مهم‌ترین فرآیندهایی که از چشم من مخفی مانده بود، خود فرآیند مدیریت ریسک PMBOK بود. من ریسک‌های موجود در این پروژه را نه شناسایی کردم و نه برنامه‌ای برای مقابله با آن داشتم!

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

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

جدیت بر روی هدف خوب است ولی آیا آن هدف ماست

همان‌طور که عنوان شد هدف من تکمیل پایان‌نامه و ارائه آن بود؛ اما به نظر می‌رسد خیلی آرام و بی‌سروصدا هدف من تغییر پیدا کرد و از این هدف به تهیه برنامه‌ای که قابلیت پیاده شدن در سازمان‌های نفتی را داشته باشد تغییر پیدا کرد.

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

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

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

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

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

برآورد اشتباه مدت‌زمان

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

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

• اگر در سطح سازمان بحث می‌شود نیاز به واگذاری کار به نفراتی است که باید مطمئن بود برای انجام این‌چنین کاری وقت کافی داشته باشند و یا توانایی مدیریت زمانی را برای انجام آن داشته باشند.
• اگر به‌صورت فردی بحث می‌شود باید دقت نمود هر انسان در هرلحظه فقط می‌تواند یک کار ارادی را انجام دهد و درصورتی‌که قبلاً زمان خالی نداشته آیا توانایی انجام کار جدید و به‌عبارت‌دیگر خالی کردن زمان برای انجام آن کار را دارد یا خیر؟

تجربه ثابت کرده سازمان‌ها و افراد در تخمین زمان انجام کارها کاملاً خوش‌بین هستند و اگر کارفرما به مسئله زمان حساسیت خاص داشته باشد، می‌تواند انجام پروژه را با مخاطره روبرو کند.

البته فکر می‌کنم بحث تخمین برآورد زمانی برای افراد در کارهایی که برای اولین بار صورت می‌گیرد و یا حتی کارهایی که برای چندمین انجام می‌گیرد، برمی‌گردد به شخصیت افراد، که در تخصص من نیست؛ ولی اگر کاری برای اولین بار است که صورت می‌پذیرد، در برآورد زمانی باید بسیار محتاط بود. یک توصیه اکید این است که برآورد را به‌صورت فردی ارائه نداده و برای تخمین زمان، از دوستان متخصصی که شخصیت متفاوتی با ما دارند، نیز نظرسنجی شود.

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

چرا فکر می‌کنیم که این روش ما بهترین روش است؟

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

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

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

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

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

وقتی‌که از این موضوع آگاه شدم یک هفته از انجام کار می‌گذشت و چون حجم اطلاعات خیلی زیاد بود، با دو نفر نیروی مستقیم، فقط حدود سی درصد از کل کار انجام شده بود! درصورتی‌که با ارائه یک روش نسبتاً آسان در اکسل و با یک برنامه‌نویسی ساده حدود یک روز به اتمام رسید!

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

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

ایده آل گرایی به چه قیمت

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

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

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

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

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

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

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

جالب اینجاست بدون رعایت پارامترهای قبل، وقتی موضوع به مدیران ارشد سازمان انتقال می‌یابد، توقع داریم که آن‌ها از خروجی کار خوششان بیاید و از آن حمایت کنند!

ارتباط قوی با ذینفعان کلیدی پروژه

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

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

یکی از مهم‌ترین ضعف‌های این مورد نداشتن جلسات مشترک و منظم و اطلاع‌رسانی مدیران ارشد در خصوص نحوه انجام کار و عدم دخالت آن‌ها در فرآیند تکمیل کار است. اگر در همان ابتدای کار که در حال شکل‌گیری بستر کار است، مسیر را اصلاح ننماییم، تصحیح آن بعد از اتمام کار هزینه و زمان بسیار زیادی را می‌برد. تمثال این حرف همان ضرب‌المثل مشهور است که می‌گوید: خشت اول گر نهد معمار کج …

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

چرخ را دوباره اختراع نکنیم

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

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

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

چون تمرکزم بر روی راه‌حل بود برای حل مشکلاتم در انجام کار مجبور شدم انواع و اقسام روش‌ها، تکنولوژی‌ها و ابزارها شامل (WCS, BDCS, InfoPath, SharePoint Designer, jQuery, Visual C#) را مطالعه و درنهایت استفاده کنم. اگر من به‌جای تمرکز بر روی راه‌حل (که ناشی از برآورد اشتباهم در ابتدای کار بود) بر روی خود مشکل تمرکز می‌کردم، هزینه به‌مراتب کمتری پرداخت می‌کردم.

نتیجه‌گیری

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

مهم‌تر از همه موارد فوق اینکه در چند سازمان توانستم این برنامه را حتی به‌رایگان پیاده‌سازی کنم؟ فکر کنم جواب را خودتان می‌توانید حدس بزنید.