وقتی سامانهٔ جدید آماده می‌شود، وسوسه داریم تغییر را تمام‌شده بدانیم. اما زندگی واقعی سامانه از فردی شروع می‌شود که باید میان کارهای روزمره، راه تازه را یاد بگیرد و به آن اعتماد کند. اگر او هنوز برای تصمیم به فایل قدیمی برمی‌گردد، مسئله صرفاً «مقاومت» نیست. شاید اطلاعات، اختیار یا فرصتی که برای انجام درست کار لازم دارد، هنوز در مسیر جدید فراهم نشده است.
مقاومت را قبل از نام‌گذاری بشنویم
در یک مثال فرضی، تیم خدمات باید درخواست‌ها را در ابزار تازه ثبت کند، اما مدیر همچنان گزارش قبلی را می‌خواهد. کارمند حالا دو بار اطلاعات وارد می‌کند. از دور، استفاده‌نکردن از ابزار تنبلی به نظر می‌رسد؛ از نزدیک، تلاش برای انجام دو انتظار متناقض است. نخستین گفت‌وگو بهتر است دربارهٔ کار واقعی باشد: چه چیزی سخت‌تر شده و چه مسئولیتی هنوز روشن نیست؟
مدل ADKAR متعلق به Prosci، آگاهی، تمایل، دانش، توانایی و تقویت را از هم تفکیک می‌کند. این مدل نسخهٔ تضمینی موفقیت نیست؛ برای این نوشته، یادآوری مفیدی است که دانستن دلیل تغییر با توان انجام آن یکسان نیست و یک جلسهٔ معرفی نمی‌تواند همهٔ این نیازها را پوشش دهد. Prosci؛ مدل ADKAR
افراد درگیر را به تصمیم وصل کنیم
کارشناس اجرا چیزی دربارهٔ استثناهای روزانه می‌داند که در نمودار فرایند دیده نمی‌شود. پشتیبانی پیامد یک خطا را می‌بیند؛ فناوری محدودیت اتصال را می‌شناسد؛ مدیر دربارهٔ اولویت و منابع تصمیم می‌گیرد. اگر این نگاه‌ها فقط در پایان به هم برسند، هر اصلاح کوچک می‌تواند دوباره به مذاکره‌ای طولانی تبدیل شود. همکاری باید بخشی از طراحی کار باشد، نه مراسم تأیید نهایی.
استاندارد تیم چندرشته‌ای GOV.UK، حضور مهارت‌های متنوع و مشارکت افراد تصمیم‌گیر را برای ایجاد و ادارهٔ خدمت مطرح می‌کند. برداشت پیشنهادی ما، تیم بزرگ‌تر به هر قیمت نیست؛ ترکیبی است که مسئلهٔ مشخص را بفهمد و بتواند درباره‌اش اقدام کند. دسترسی به نظر متخصص نیز مهم است، حتی اگر او عضو تمام‌وقت تیم نباشد. GOV.UK؛ تیم چندرشته‌ای
آموزش را به تمرین واقعی تبدیل کنیم
آموزشِ ابزار با نشان‌دادن همهٔ دکمه‌ها تمام نمی‌شود. در مثال خدمات، تمرین باید ثبت درخواست ناقص، انتقال مسئولیت و اصلاح اشتباه را هم پوشش دهد. فرد باید بداند در موقعیت مبهم از چه کسی کمک بگیرد. بهتر است بخش کوچکی از کار را با پشتیبانی نزدیک آغاز کنیم و سؤال‌های تکراری را به اصلاح راهنما یا خود فرایند تبدیل کنیم.
زمان یادگیری نیز باید واقعی باشد. اگر انتظار خروجی روزانه تغییر نمی‌کند ولی کار تازه اضافه می‌شود، بار تغییر بی‌صدا روی افراد می‌افتد. پیش از اجرا، دربارهٔ زمان تمرین، روش موقت کار و زمان کنارگذاشتن مسیر قبلی توافق کنیم. مسیر موازی شاید برای گذار لازم باشد، اما بدون تاریخ تصمیم و مسئول روشن، می‌تواند برای همیشه باقی بماند.
اختیار و بازخورد را مشخص نگه داریم
راهبری چابک در راهنمای GOV.UK، مرز اختیار تیم و مسیر تصمیم‌هایی را که بیرون آن مرز قرار دارند روشن می‌کند. در عمل، پیشنهاد اینجا یک توافق کوتاه است: چه کسی مشکل را ثبت می‌کند، چه کسی می‌تواند اصلاح کوچک را تأیید کند و کدام موضوع باید به تصمیم بالاتر برسد. مسئولیت مشترک نباید به بی‌مسئولیتی تبدیل شود. GOV.UK؛ اختیار تصمیم و راهبری چابک
پس از شروع، فقط تعداد ورودها را نگاه نکنیم. ببینیم کارها کجا متوقف می‌شوند، چه استثناهایی بیرون سامانه حل می‌شوند و چه کسی دوباره به روش قبلی برگشته است. این مشاهده برای سرزنش افراد نیست؛ نشانه‌ای برای اصلاح شرایط کار است. تغییر زمانی ماندگارتر می‌شود که تیم بتواند دربارهٔ دشواری حرف بزند و اثر این حرف‌زدن را در تصمیم بعدی ببیند.