طراحی پروژه تعالی منابع انسانی با مدل انجمن

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

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

برای طراحی پروژه مبتنی بر مدل انجمن، ابتدا باید روشن کنیم چه کاری مجاز شده، چه نتیجه‌ای انتظار می‌رود، چه چیزی تحویل می‌شود و مسئولیت پس از تحویل با چه کسی است.

«استقرار مدل» در پروژه شما دقیقاً به چه معناست؟

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

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

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

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

تعریفمنشور پروژه (Project Charter) مبنای توافق درباره چرایی پروژه، هدف‌های اصلی، دامنه کلی و اختیار اجرای آن است. برنامه پروژه، جزئیات بیشتری درباره چگونگی انجام کار ارائه می‌کند. یک منشور کوتاه و روشن، از سند مفصلی که تصمیم‌های اصلی در آن مبهم‌اند مفیدتر است.

منشور پروژه تعالی چه اطلاعاتی داشته باشد؟

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

1. چرایی پروژه: چه نیاز یا مسئله‌ای انجام این کار را توجیه می‌کند؟
2. هدف مرحله نخست: پس از پایان این مرحله چه شناخت، تصمیم یا تغییری انتظار داریم؟
3. دامنه: کدام بخش‌ها، گروه‌ها و موضوعات در بررسی قرار می‌گیرند؟
4. خارج از دامنه: چه انتظارهایی فعلاً تعهد پروژه نیستند؟
5. مرجع: کدام ویرایش مدل و کدام اسناد مرتبط مبنای کارند؟
6. حامی و مدیر پروژه: چه کسی اختیار شروع، هماهنگی و رفع موانع را دارد؟
7. خروجی‌های اصلی: چه چیزهایی باید تحویل شوند؟
8. معیار موفقیت: از کجا می‌فهمیم پروژه به هدف خود نزدیک شده است؟
9. محدودیت‌ها و فرض‌ها: زمان، ظرفیت، دسترسی و وابستگی‌های مهم چیست؟
10. تصمیم‌های نیازمند ارجاع: کدام تغییرها یا اختلاف‌ها باید به حامی پروژه برسند؟

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

دامنه بررسی را از دامنه بهبود جدا کنید

دامنه پروژه (Project Scope) باید حد و مرز تعهد را روشن کند. در پروژه تعالی، دست‌کم دو مرز متفاوت وجود دارد: چه چیزی بررسی می‌شود و چه چیزی در همین پروژه تغییر می‌کند.

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

در تعیین دامنه، این موارد را مشخص کنید:

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

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

خروجی را با فعالیت اشتباه نگیرید

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

خروجی قابل تحویل (Deliverable) باید به اندازه‌ای مشخص باشد که بتوان درباره کامل‌بودن آن گفت‌وگو کرد. در مقابل، عبارت‌هایی مانند «بهبود منابع انسانی» یا «ارتقای فرهنگ» بدون تعریف بیشتر، معیار مناسبی برای تحویل نیستند.

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

نقش‌ها و اختیار تصمیم‌گیری را چگونه روشن کنیم؟

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

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

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

پروژه را با چه ترتیبی پیش ببریم؟

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

مرحله اول: توافق بر هدف و امکان اجرا

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

مرحله دوم: آماده‌سازی تیم و برنامه شواهد

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

مرحله سوم: بررسی و جمع‌بندی وضعیت

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

مرحله چهارم: انتخاب و طراحی بهبود

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

مرحله پنجم: اجرا و بررسی استفاده

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

مرحله ششم: تحویل مسئولیت و پیگیری

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

زمان و منابع را بر چه مبنایی برآورد کنیم؟

تعداد معیارها به‌تنهایی زمان موردنیاز را تعیین نمی‌کند. گستردگی سازمان، پراکندگی اطلاعات، تعداد واحدهای درگیر، دسترس‌پذیری مدیران و دامنه اقدام‌های بهبود بر حجم کار اثر می‌گذارند.

برآورد را بر اساس کار واقعی انجام دهید:

• چه مقدار اطلاعات باید دریافت، پاک‌سازی و تفسیر شود؟
• برای شناخت اجرا، با چه گروه‌هایی باید گفت‌وگو شود؟
• چه خروجی‌هایی به بازبینی و تأیید چند واحد نیاز دارند؟
• کدام فعالیت به تکمیل فعالیت دیگری وابسته است؟
• اعضای تیم چه تعهدهای جاری دیگری دارند؟

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

تغییر دامنه و ریسک‌ها را چگونه مدیریت کنیم؟

در جریان ارزیابی، مسائل تازه‌ای آشکار می‌شوند. این اتفاق طبیعی است، اما به معنای پذیرفتن خودکار همه آن‌ها در تعهد جاری نیست. گسترش کنترل‌نشده دامنه (Scope Creep) زمانی رخ می‌دهد که کار اضافه شود، اما درباره اثر آن بر زمان، منابع و خروجی توافق تازه‌ای شکل نگیرد.

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

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

چه زمانی خروجی واقعاً آماده تحویل است؟

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

در تحویل نهایی، دست‌کم این موضوعات روشن باشد:

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

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

نگاه مشاوره‌ای خانه منابع انسانی

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

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

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