PMPlus

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

تغییر باید مورد نیاز باشد: شاید شما هم با افراد یا سازمانهایی برخورد داشته اید که ناخواسته به این شعار پایبند هستند. ” من تغییر می دهم، پس من هستم”. تغییر خوب، خوب است اما باید توجه داشت که تغییر باید مورد نیاز باشد. قبل از پیاده سازی تغییر، باید دلیل و توجیه آن برای تمام ذینفعان آن شفاف و مشخص شود. به این نکته توجه داشته باشید که هر چند همه موافقیم که سازمانها باید آینده نگر باشند، اما اگر همه چیز در سازمان شما آرام است، دلیلی ندارد قسمت عمده از سازمان خود را درگیر تغییری کنید که قرار است ۱۰ سال بعد جواب بدهد. خودتان بهتر می دانید که افراد نسبت به این اهداف بسیار طولانی مدت توجیه نخواهند شد و آن را مفید نمی دانند. برای اینگونه تغییرات بهتر است افراد کمی که می توانند با هدف گذاری بلند مدت کنار بیایند را درگیر نمایید

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

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

تغییر باید گام به گام باشد: “ما می خواهیم در سازمان فرایند  تحلیل را با استاندارد  ^®BABOK پیاده کنیم. همه تحلیلگران باید از هفته آینده بر اساس این استاندارد کار کنند.” حالا تا دیروز هیچ کس از اینکه ^®BABOK هم وجود دارد خبر نداشت. تا دیروز کسی از وجود تکنیکهای متعدد جمع آوری اطلاعات و نقاط ضعف و قوت هر یک از آنها مطلع نبود. تا دیروز هر زمان که باید تحلیلی صورت می گرفت، بدون توجه به اینکه تحلیل  باید برنامه ریزی شود، مستند سازی شود، ممیزی شود و … تحلیل صورت می گرفت. خب چگونه باید از هفته بعد این استاندارد را در سازمان پیاده سازی کرد؟ من که فکر می کنم عمر این استاندارد بسیار خوب در این سازمان یک ماه است و در طول این یک ماه، همان کیفیت تحلیلی که از قبل وجود داشت، از بین خواهد رفت.

بهتر است در گام اول تا شش ماه فقط روی مستند سازی کار کرد، در این مدت افراد را با تکنیکها جمع آوری اطلاعات آشنا کرد، در شش ماه دوم روی برنامه ریزی تحلیل و استراتژی های جمع آوری اطلاعات کار کرد و … به نظر من این روش تضمین شده تر است؟

خب نظر شما در مورد این روشها چیست؟ روشهای پیشنهادی شما برای فرهنگی کردن تغییرات کدام است؟

در توییتر و فیس بوک من را دنبال کنید.

از طریق صفحه تماس با من در ارتباط باشید.

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

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

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

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

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

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

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

از طریق صفحه تماس با من در ارتباط باشید.