این یک واقعیت شناخته شده است که دولتها اغلب در تحقق اهداف خود شکست میخورند. طرحها، برنامهها و پروژههای جدید اغلب با تأخیر یا هزینههای بیشتر از حد انتظار اجرا میشوند یا به سادگی به وعدههای اولیه خود عمل نمیکنند.
به عنوان مدیران یک شرکت مشاوره تخصصی دولتی به نام PUBLIC، ما این کاستیها را از نزدیک مشاهده کردهایم. PUBLIC با دولتهای بریتانیا و اروپا همکاری میکند تا پروژههای بزرگ و پیچیده دیجیتال، داده و فناوری را اجرا کند. از تجربهی ما میدانیم که همه چیز همیشه به آسانی پیشبینی نمیشود. سوال اصلی این است: چرا؟
در این مقاله، به بررسی برخی از شکستهای رایج در پروژههای دولتی از دیدگاه رفتاری میپردازیم. ما معتقدیم که تعصبات شناختی، عادات و روشهای اکتشافی اغلب ریشه مشکل هستند و با آگاهی بیشتر از آنها، دولتها میتوانند در تحقق وعدههای خود بهتر عمل کنند. ما هفت نمونه از تعصبات پروژه را بررسی خواهیم کرد و استراتژیهایی برای غلبه بر آنها ارائه خواهیم داد، با الهام از “روشهای بهداشتی تصمیمگیری” توصیه شده توسط کانمن برای کنترل تعصبات.
به عنوان متخصصان دیجیتال، ما عمدتاً بر روی پروژههای دیجیتال و فناوری تمرکز خواهیم کرد، اما معتقدیم اصول ما برای هر نوع پروژهای، از جمله زیرساخت، مسکن، مراقبتهای بهداشتی یا هر چیزی که نیاز به برنامهریزی دقیق و اجرای دقیقتر دارد، صادق است.
ما تمایل داریم فکر کنیم پروژههای ما منحصر به فردتر از آنچه هستند، هستند.
حتی برای معمولیترین پروژهها، ما معمولاً فکر میکنیم که مورد ما به نوعی متفاوت یا خاصتر از دیگران است. ما این را همیشه میبینیم، مخصوصاً وقتی صحبت از نرمافزار میشود. اکثر سیستمهای دیجیتالی که دولتها میسازند، اساساً شبیه به بقیه هستند، همه به یک پایگاه داده واحد یا یک صفحه وب ساده خلاصه میشوند. اما حتی وقتی چیزی هزاران بار قبلاً انجام شده است، هنوز هم وسوسهانگیز است که فکر کنیم: به دلیل چیدمان ما، به چیزی کمی متفاوت نیاز داریم، یا ممکن است نیاز به تغییر رابط کاربری داشته باشیم، یا این کاملاً با نحوه انجام کارهای ما مطابقت ندارد.
شواهد قوی اخیر از بنت فلیوبرگ، جغرافیدان اقتصادی دانمارکی، و دیگران نشان میدهد که تعصب منحصر به فرد بودن - تصور اینکه پروژههای ما متفاوت هستند در حالی که به سادگی متفاوت نیستند - بزرگترین پیشبینیکننده شکست پروژههای بزرگ است. منحصر به فرد بودن درک شده میتواند به چند دلیل مشکلساز باشد. اول، میتواند باعث ناکارآمدی شود: تیمها سعی میکنند چرخ را از نو اختراع کنند (یا در این مورد، فرآیندهای تثبیت شده) یا سعی میکنند مشکلاتی را حل کنند که در حال حاضر راه حلهای قابل اعتمادی برای آنها وجود دارد. دوم، این میتواند به معنای آن باشد که تیمها از درس گرفتن از پروژههای دیگر که شکست خوردهاند، غافل میشوند، که همانطور که مطالعه فلیوبرگ میگوید، "منجر به دیدگاه تحریف شدهای از واقعیت میشود که خطر را دست کم میگیرد و فرصت را بیش از حد ارزیابی میکند."
به جای فرض منحصر به فرد بودن از همان ابتدا، تیمها باید از این فرض شروع کنند که پروژه آنها قبلاً انجام شده است و بنابراین، باید سعی کنند هر گونه بینشی را که میتوانند از کار قبلی که قبل از آنها انجام شده است، جمعآوری کنند. بیرون آوردن همه اینها قبل از شروع یک پروژه میتواند به تیم کمک کند تا به یک درک مهم برسد: پروژه آنها احتمالاً منحصر به فرد نیست و قبلاً یک طرح اولیه دارد که میتوانند آن را دنبال کنند و برای نیازهای خود اصلاح کنند.
ما در برنامهریزی پروژهها بیش از حد خوشبین هستیم
تعصب خوشبینی به تمایل ما به بیش از حد خوشبین بودن هنگام برنامهریزی یا حسابداری برای نتایج آینده اشاره دارد. این اثر با نگاه بیشتر به آینده، که همیشه برای پروژههای پیچیده دولتی مورد نیاز است، شدیدتر میشود. ساخت یک بزرگراه جدید، اجرای یک طرح مراقبتهای بهداشتی جدید برای میلیونها نفر یا توسعه یک قطعه نرمافزاری کاملاً جدید همه زمانبر هستند و همه نیاز به پیشبینی سالها دارند.
در دولت بریتانیا، ما در واقع یک فرآیند استاندارد برای اعمال تخفیف خوشبینی به پیشبینیهای مالی داریم. این بدان معناست که هنگام برنامهریزی پروژهها، از تیمها خواسته میشود که هنگام تخمین هزینه یک پروژه، هزینههای اضافی را به پیشبینیهای مالی آینده خود اضافه کنند. معمولاً این مقدار اضافی 10 تا 20 درصد از کل هزینه است، بسته به پروژه.
اما تعصب خوشبینی چیزی نیست که فقط در ابتدای کار هنگام انجام پیشبینیهای مالی بزرگ باید از آن آگاه باشیم. این چیزی است که میتواند در هر لحظه بر تصمیمگیری تأثیر بگذارد. هنگامی که تیمها برای برنامهریزی وظایف خود برای روز، هفته یا ماه گرد هم میآیند، آنها به طور منظم پیچیدگی این وظایف یا مدت زمانی که طول میکشد را دست کم میگیرند.
یک فرآیند بهداشتی خوب هنگام برنامهریزی یا تقسیم وظایف، بررسی خود برای تعصب خوشبینی بالقوه است. منطقی است که از همان ابتدا فرض کنیم ممکن است انجام کارها بیشتر از آنچه در ابتدا برنامهریزی کردهاید، طول بکشد. یک قانون ساده ممکن است افزایش زمان تخمینی به میزان 20 تا 25 درصد هنگام پیشبینی مدت زمانی باشد که ممکن است چیزی طول بکشد.
یک استراتژی مفید دیگر برای بررسی تعصب خوشبینی شما، همکاری با همکاران خود برای انجام یک پیشمرگ پروژه است که شامل در نظر گرفتن تمام چیزهایی است که ممکن است قبل از شروع کار اشتباه شود، نه بعد از آن. این میتواند به کاهش خوشبینی شما کمک کند، زیرا شما را مجبور میکند با چیزهایی که ممکن است طبق انتظار پیش نروند، روبرو شوید.
ما برای مدت زمان و هزینه پروژهها، لنگرهای ضعیفی داریم
پروژهها معمولاً با کمی دامنهبندی سست شروع میشوند. در بخش فناوری، گاهی اوقات این را "اندازه T-shirt" مینامیم - یا، به عنوان یک ترجمه، ما به طور گسترده اندازه و شکل پروژه را مشخص میکنیم، قبل از عرق کردن روی جزئیات. اما متأسفانه، این فرآیند بسیار مستعد خطرات تعصب لنگر است.
تعصب لنگر یک اثر شناختی است که باعث میشود ما هنگام قضاوت یا تصمیمگیری، اولویت را به اطلاعات اخیر یا برجسته (“لنگر”) بدهیم. لنگرها میتوانند بر درک ما از هم هزینه و زمان مرتبط با یک پروژه تأثیر بگذارند. هنگام تهیه بودجه، ساخت مدل مالی یا تخمین جدول زمانی پروژه، تیمها میتوانند توسط طیف وسیعی از اطلاعات مختلف لنگر شوند. شاید این یک قیمت نقل شدهای باشد که کسی چند هفته پیش در یک جلسه گفته است. یا هزینهای که آخرین بار برای تکمیل پروژه پرداخت شده است. یا چند هفتهای که مدیر انتظار دارد طول بکشد. گاهی اوقات، لنگر حتی میتواند از منابع خارجی مانند مبلغی که یک فروشنده یا مشاور به شما گفته است، بیاید.
همه این لنگرها میتوانند در راه برنامهریزی هدفمند پروژه از ابتدا قرار بگیرند. تیمها اغلب متوجه نمیشوند که وقتی در حال برنامهریزی یا هزینه کردن یک پروژه جدید هستند، اغلب از لنگر اصلی به عنوان نقطه شروع استفاده میکنند. این بدان معناست که آنها برنامهها یا بودجههای خود را بر اساس جزئیات خاص یک پروژه نمیسازند، بلکه بر اساس اعدادی که ممکن است به آنها گفته شده باشد، دستور داده شده باشد یا از آسمان گرفته شده باشد، عمل میکنند.
بهترین راه برای کاهش این خطر، قرار دادن تمام لنگرهای تیم شما در ابتدای پروژه و ارزیابی میزان عینی بودن آنها و همچنین مقدار وزنی است که باید واقعاً به آنها بدهید.
ما اولویت را به خوب به نظر رسیدن میدهیم تا خوب عمل کردن
ما یک تمایل ذاتی داریم که به دستاوردهایی که برای دیگران بیشتر قابل مشاهده هستند، اولویت دهیم، نه مهمترین کاری که باید انجام شود. جای تعجب نیست که وقتی در یک تیم کار میکنیم، با رهبران ارشدی که کار ما را بررسی میکنند، میخواهیم جلوی همکارانمان خوب به نظر برسیم.
در زمینه نرمافزار، یک فرآیند خستهکننده اما مهم تست خودکار نمونهای عالی از این است. تست خودکار زمانی است که ما از ابزارهایی برای آزمایش باگها، خطاها یا نقصها در نرمافزار استفاده میکنیم. این کار بسیار پشت پرده در نظر گرفته میشود: خارج از تیم فنی که این آزمایشها را انجام میدهد، هیچ کس حتی نمیداند که این اتفاق در حال رخ دادن است. این مطمئناً برای مدیریت یا مشتریان قابل مشاهده نیست. اغلب، زمانی که زمان محدود است، تیمها این پارامترهای کیفیت را به نفع انجام کارهایی که مردم میتوانند ببینند، مانند ساخت ویژگیهای جدید، بهبود تجربه کاربری یا رسیدگی به درخواستهای رهبری ارشد، کماهمیت میکنند.
این موردی است که در آن اولویتبندی خوب به نظر رسیدن بر مهمترین (اما اغلب نامرئی) کار انجام میشود. یک تیم پروژه آگاه احتمالاً ویژگیها و ارتقاءهای جدید را قربانی میکند یا حتی بودجه پروژه را افزایش میدهد تا اطمینان حاصل شود که این کار پنهان اما ضروری انجام میشود. اما در بیشتر شرایط، تیمها ممکن است این اولویتها را جابجا کنند.
برای مقابله با این خطر، مهم است که تیمهای پروژه به طور فعال دستاوردهای کمتر قابل مشاهده پروژه را به همان اندازه دستاوردهای قابل مشاهده جشن بگیرند و تشویق کنند. این بدان معناست که رهبری ارشد را برای قسمتهای “خستهکنندهتر” اما حیاتی یک پروژه هیجانزده کنید، یا حتی این کارهای پشت صحنه را به مشتریان بالقوه نشان دهید.
ما امیدها، ترسها و انگیزههای خود را در پروژهها نمیفهمیم - یا انگیزههای همتیمیهایمان را
برنامهریزی پروژه اغلب آنچه را که میخواهیم به دست آوریم، و اگر به خوبی انجام شود، چگونه میخواهیم به آن دست یابیم، مشخص میکند. برنامهها شامل اعداد، هزینهها، منابع، تاریخها و نقاط عطف است - اما معمولاً در حساب کردن صحیح افراد درگیر شکست میخورند.
به طور خاص، ما چیزهایی مانند: چرا این پروژه برای من مهم است؟ چرا وقت خود را برای این کار صرف میکنم؟ چه ترسها یا اضطرابهایی ممکن است مرا سوق دهد؟ وقتی به پروژه فکر میکنم چه حسی دارم؟ را در نظر نمیگیریم. و اگر اغلب نمیتوانیم به این سوالات درباره خودمان پاسخ دهیم، جای تعجب نیست که معمولاً انگیزههای اعضای تیم خود را هم درک نمیکنیم.
متأسفانه، قابل درک است که چرا به این سوالات به عنوان اولویت در کنار حقایق سرد و سخت یک پروژه رسیدگی نمیشود. وقتی کارهایی برای انجام دادن و مهلتهایی برای رعایت کردن وجود دارد، طبیعی است که مستقیماً به اعداد و صفحات گسترده بپریم. اما محرکهای انسانی پروژهها نیز واقعاً مهم هستند.
اگر وقت بگذاریم تا انگیزههای تیم خود را در ابتدای پروژه درک کنیم، میتوانیم بهتر نقش احساسات خود را در شکل دادن به تصمیمات پروژه خود - و همچنین تصمیمات همکارانمان - درک کنیم. برای مثال، ممکن است راحتتر تشخیص دهیم که چه زمانی اعضای تیم تصمیماتی را بر اساس ترس، گناه یا غرور میگیرند. یک زمینه ادبیات تثبیت شده وجود دارد که بر این موضوع تمرکز میکند که چگونه احساسات میتوانند بر تحمل ریسک ما در شرایط مختلف تأثیر بگذارند (اقتصاددان رفتاری جورج لوونشتاین این را به عنوان نظریه ریسک به عنوان احساسات توصیف کرد).
این همه میتواند به ویژه زمانی مفید باشد که در پروژههای خود با مشکلاتی مواجه میشویم (که تقریباً اجتنابناپذیر است). اینها همان نوع لحظات پر استرس هستند که تصمیمگیری احساسی میتواند بر آنها غلبه کند. تیمی که امیدها، ترسها و انگیزههای یکدیگر را درک کند، در موقعیت بهتری برای هدایت این شرایط دشوار و بهبود تصمیمگیری جمعی خود قرار خواهد گرفت - و در نتیجه، نتایج پروژههای بعدی.
ما در تراز کردن انگیزهها، بهویژه با شرکا و پیمانکاران، شکست میخوریم
بسیاری از پروژهها ساختارهای انگیزشی کلی مناسبی برای تسهیل موفقیت ندارند. به عبارت دیگر، موفقیت کلی پروژه همیشه با موفقیت همه اعضای تیم پروژه درگیر کاملاً همسو نیست. این امر به ویژه در مورد پروژههایی که شامل شرکای خارجی، پیمانکاران، فروشندگان یا مشاوران هستند، صادق است که ممکن است حتی اگر نتایج مثبت نباشد، پاداش بگیرند.
یک مثال رایج از این پدیده در توسعه نرمافزار نهفته است. هنگام نوشتن کد، اکثر توسعهدهندگان معمولاً برای اطمینان از اینکه کد آنها آسان برای استفاده، پیمایش یا بهروزرسانی در آینده است، انگیزه ندارند. در عوض، آنها معمولاً برای تولید سریعترین خروجی ممکن، حتی اگر به معنای میانبر یا کوتاه کردن کیفیت باشد، انگیزه دارند. این به این دلیل است که معمولاً کسی که کد را مینویسد همان کسی نیست که آن را در چند سال آینده نگهداری یا بهروزرسانی میکند.
این امر به ویژه در صورتی صادق است که یک فروشنده یا پیمانکار خارجی در حال نوشتن کد باشد، که در پروژههای دولتی بسیار رایج است. در اکثر موارد، شرکای خارجی نه تنها برای سادهتر کردن کارها برای آینده انگیزه دارند، بلکه ممکن است در واقع برای سختتر کردن کارها برای آینده انگیزه داشته باشند تا مشتریان آنها را نگه دارند.
خوشبختانه، اگر انگیزهها از ابتدا همسو باشند، نیازی به این نیست. نکته مهم در اینجا این است که اطمینان حاصل شود که شرکا با موفقیت خود پروژه انگیزه دارند. تا حد امکان، اعضای پروژه - چه داخلی باشند چه خارجی - باید با نتایج انگیزه داده شوند، که به ویژه شامل سادهسازی کار برای کسی برای ادامه کار از جایی که رها کردهاند، میشود.
ما منابع بیشتری را صرف پروژههای اشتباه میکنیم
سرانجام، مشکل کلاسیک مدیریت پروژه. دولتها همچنان به صرف زمان و منابع برای چیزهای اشتباه ادامه میدهند، حتی زمانی که تصمیم بهتری خواهد بود که در حالی که عقب هستند متوقف شوند. این پدیده به عنوان خطای هزینههای از دست رفته شناخته میشود: تمایل ما به ادامه کاری که قبلاً در آن سرمایهگذاری زیادی کردهایم (چه زمان، پول، تلاش یا انرژی عاطفی)، صرفنظر از نشانههای واضحی که نشان میدهد تسلیم شدن ایده بهتری است.
در توسعه نرمافزار، ما این را همیشه میبینیم. نمونههای زیادی از نهادهای عمومی در بریتانیا وجود دارد که میلیونها دلار را صرف پروژههای فناوری کردهاند که میدانند کار نمیکنند. آنها این کار را عمدتاً به این دلیل انجام میدهند که زمان زیادی را صرف آنها کردهاند یا پول زیادی را هدر دادهاند، به طوری که برای سازمان غیرممکن است که به خود اعتراف کند که کار نکرده است. حتی بدتر از آن، این بسیار رایج است که یک بخش دولتی در حال خرج کردن پول برای دو سیستم یکسان است: یکی که کار میکند و دیگری که کار نمیکند، زیرا نمیتوانند خود را مجبور کنند یکی از آنها را تعطیل کنند.
ما فکر میکنیم پاسخ اینجا به ارزیابیهای منظمتر و صادقانهتر از پروژههای ما برمیگردد. اگر اجازه دهیم کارها سالها بدون بررسی ادامه پیدا کند، ممکن است متوجه شویم که در حال صرف پول برای چیزهایی هستیم که میدانیم ارزشش را ندارد. یک گام مهم دیگر برای کاهش هزینههای از دست رفته، بازسازی تصمیمات برای لغو پروژههای فعلی به عنوان "صرفه جوییهای آینده" است. به عنوان مثال، اگر یک سرویس فناوری زنده را لغو کنیم، ممکن است 2 میلیون دلار هزینه توسعه آن شده باشد، اما بیش از 10 میلیون دلار در هزینههای عمر آینده صرفهجویی کردهایم.
بررسی نقاط کور رفتاری در پروژهها
اینها تنها برخی از عوامل رفتاری پنهانی هستند که میتوانند مانع از انجام صحیح پروژههای دولتی شوند. بسیاری از اینها نقاط کوری هستند که ممکن است از قبل از آنها آگاه باشیم اما در شیوههای کاری روزمره خود به اندازه کافی به آنها توجه نکنیم. مراحل بهداشت تصمیمگیری که ما ترسیم کردهایم، چکهای سریعی هستند که میتوانند قبل از یک پروژه و همچنین در طول اجرای آن انجام شوند. برخی از این اقدامات کوچک میتوانند در دراز مدت تفاوت بزرگی ایجاد کنند.
به یاد داشته باشید که اهمیت انجام درست این کار بسیار زیاد است: این نوع اشتباهات میتوانند به معنای واقعی کلمه صدها میلیون دلار هزینه داشته باشند و مانع از انجام کارهای مهم شوند. اما با شروع شناخت این تعصبات، میتوانیم شکستهای پروژه را به موفقیت پایدار تبدیل کنیم.
خلاصه نکات کلیدی:
- نقاط کور رفتاری: عواملی مانند تعصب لنگر، اولویت دادن به ظاهر بر عملکرد، عدم درک انگیزههای فردی و تیمی، عدم ترازبندی انگیزهها، و ادامه پروژههای شکستخورده (هزینههای از دست رفته) میتوانند منجر به شکست پروژه شوند.
- اهمیت بهداشت تصمیمگیری: انجام چکهای منظم برای شناسایی و مدیریت این تعصبات میتواند به بهبود نتایج پروژه کمک کند.
- هزینههای بالای اشتباه: شکست پروژهها میتواند هزینههای مالی و فرصتهای از دست رفته زیادی داشته باشد.
- تبدیل شکست به موفقیت: با شناخت و مدیریت تعصبات رفتاری میتوان از شکست پروژهها جلوگیری کرد و به موفقیت پایدار دست یافت.
اقدامات پیشنهادی:
- شناسایی نقاط کور: قبل از شروع هر پروژه، تیم باید به طور فعال نقاط کور احتمالی را شناسایی کند و راهکارهایی برای مدیریت آنها بیابد.
- ترازبندی انگیزهها: اطمینان حاصل کنید که انگیزههای همه اعضای تیم با اهداف کلی پروژه همسو باشد.
- ارزیابی منظم پروژهها: به طور منظم پیشرفت پروژه را ارزیابی کنید و در صورت لزوم اصلاحات لازم را انجام دهید.
- مدیریت هزینههای از دست رفته: از ادامه پروژههایی که احتمال موفقیت کمی دارند خودداری کنید.
- ترویج فرهنگ یادگیری: ایجاد یک فرهنگ سازمانی که در آن اشتباهات به عنوان فرصتهای یادگیری تلقی شوند، میتواند به بهبود نتایج پروژهها کمک کند.
با پیروی از این راهکارها، سازمانها میتوانند احتمال موفقیت پروژههای خود را به میزان قابل توجهی افزایش دهند.
دیدگاه خود را بنویسید