حرفۀ مدیریت پروژه تحلیلگران زیادی دارند؛ پس چرا بیشتر تحلیل نکنیم؟

متناقض نیست؟! کارشناسان PMO ِزیادی هستند که در عنوان شغلی‌شان «تحلیلگر» دارند اما عجیب است که کمتر خودشان را وقف تحلیل‌ها می‌کنند. ما در عصری هستیم که می‌توانیم داده‌های زیادی دربارۀ سازمان‌ها، پروژه‌ها، کارپردازان، بازاریابان و افراد جمع کنیم. این داده‌ها در سامانه‌های CRM، ابزار PPM، پایگاه‌داده‌های HRIS و سامانه‌های مدیریت اسناد موجود هستند. این منابع را می‌توان برای تصمیمات داده‌محور دربارۀ نحوۀ تحویل پروژه‌ها و دریافت ارزش از آن‌ها به‌کار گرفت.

علی‌رغم گزینه‌های واضح بسیار، دفترهای مدیریت پروژۀ کمتری توانسته‌اند به این خزانۀ داده‌ها دست بیابند؛ به سه علت اصلی:

شناخت ناکافی تفکر تحلیلی در دفترهای مدیریت پروژه اولین علت است. بسیاری از افراد که در فضای PMO کار می‌کنند در گذشته مدیر پروژه بوده‌اند و طرزتفکر مدیریت پروژه دارند. تمرکز بر «حال» است، بر تحویل پروژۀ فعلی و رسیدن به نقطۀ رویداد (مایلستون) بعدی.

ناکافی بودن مهارت‌ها یا نداشتن مجموعه‌مهارت‌های مربوطه دلیل دیگر است. در روش‌ها  و فنون مدیریت پروژه تمرکز بیش‌ازحدی بر آموزش تحلیلگران PMO وجود دارد. معمولاً تحلیلگران را به گرفتن مدارک PMP یا PRINCE2 ترغیب می‌کنند، به‌جای اینکه برای توسعۀ دانش داده‌ها، کلان‌داده‌ها [۱] و روش‌های آماری تشویق کنند.

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

اگر PMOها داده‌ها را ندانند و نشناسند نمی‌توانند «یگانه ‌منبع واقعیت» باشند، چیزی که ادعایش را می‌کنند. تیم‌های مالی و تیم‌های BAU که داده‌ها را از مدیران پروژه بهتر می‌فهمند این اعتبار را کسب می‌کنند.

خوشبختانه برخلاف آنچه که شاید کارپردازان و مشاوران به شما بگویند، PMOها برای اینکه کار با تحلیل را شروع کنند نیاز به سرمایه‌های کلان ندارند؛ صفحه‌گسترده‌ها [۲] کفایت می‌کنند. درواقع از مزایای صفحه‌گسترده‌ها آموزش نادشوار آن‌هاست. صفحه‌گسترده‌ها انعطاف‌پذیرند؛ می‌توانید فوراً داده‌ها را از سیستم‌ها  و منابع مختلف باهم ترکیب کنید. البته بهترین مزیتش این است که می‌توانید به‌محض اینکه تحلیلگران PMO نرم‌افزار را بر لپ‌تاپشان نصب کردند دست‌به‌کار شوید.

شروع فوری اهمیت دارد، زیرا کندی کار غالب می‌شود. چند بار شده که بنشوید «تا سیستم Clarity یا Oracle یا SAP یا Salesforce را نصب کردیم، می‌توانستیم تحلیل داده‌ها را شروع کنیم»؟ درعمل وقتی سیستم‌ها نصب می‌شوند برای همه بسیار پیچیده است و بررسی آن به کارشناسان خبره و آموزش‌دیدۀ تجاری نیاز دارد.

PMOها برای بهره بردن از کلان‌داده‌ها چه می‌توانند بکنند؟

 اول اینکه لازم است PMOها طرزتفکر تحلیلی را تقویت کنند. باید بتوانند داده‌ها را جمع کنند، تحلیل کنند و از آن‌ها نتیجه‌گیری کنند و نتایج را برای اتخاذ تصمیمات، هوشمندانه، ارائه بدهند. آیا دِین فنی [۳] شتاب تحویل را کند نمی‌کند؟ آیا برخی بخش‌های کسب‌وکار برای تحویل ارزش پروژه از دیگر بخش‌ها بهتر نیستند؟ چرا؟ آیا کسب‌وکار باید در آزمون خودکار و چندواریانسی سرمایه‌گذاری کند یا در آموزش؟ در یک دورۀ سه‌ساله به چه مجموعه‌مهارت‌هایی برای پروژه‌مان نیاز داریم؟ معنا کردن سؤال یا مجموعۀ سؤال‌ها اولین قدم است. وقتی که سؤال معنی شد، قدم بعدی ساخت یک مدل تحلیلی است، اول با شناختن علت‌ها و سپس شناسایی داده‌ها یا منابع داده‌های موردنیاز.

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

مشکل بعدی مهارت‌ها و توانمندی‌هاست. بیشتر PMOها کارکنانی ندارند که در بسته‌های نرم‌افزاری آماری و تحلیلگری مانند R و JMP تخصص داشته باشند. سرمایه‌گذاری در آموزش راه دیگر است؛ همچنین PMOها می‌توانند استخدام منابعی را که پیشینۀ کاری آماری دارند درنظر داشته باشند یا به دانشگاه‌های محلی سری بزنند و دانشجویانی را که در جست‌وجوی راهی برای انجام پروژه و کارآموزی هستند بیابند.

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

در خط دید 

 دربارۀ گزارش‌های تحلیلی بخوانید.

تحلیل «تجویزی» داده‌ها را با تحلیل «توصیفی» داده‌ها مقایسه کنید.

آیا هوش مصنوعی شغل تحلیلگر داده‌ها را ازبین می‌برد؟

[۱] Big data

[۲] spreadsheet

[۳]  دِین فنی یا Technical Debt مفهومی در توسعۀ نرم‌افزار است که بیانگر هزینۀ احتمالیِ دوباره‌کاری اضافی است که به دلیل انتخاب یک راهکار آسان‌تر درعوض راهکار بهتری که زمان بیبشتری می‌گرفت ایجاد می‌شود. اگر دِین فنی پرداخته نشود، «بهره» پیدا می‌کند و بعداً پرداخت آن دشوارتر می‌شود. بی‌توجه ماندن به دین فنی می‌تواند موجب «درگاشت (آنتروپی) نرم‌افزار» شود. دِین فنی الزاماً بد نیست بلکه گاهی در اثبات مفهوم (proof of concept) برای پیشبرد اولیۀ پروژه لازم است. بااین‌حال برخی از کارشناسان معتقدند که استعارۀ «دین فنی» تأثیر آن را کم جلوه می‌دهد و نتیجه، جهتگیری ناکافی برای تصحیح آن است.