منگل کی سہ پہر ہے اور پروجیکٹ مینیجر ایک میٹنگ میں مصروف ہے جس میں کمپلائنس لیڈ (تعمیل کے ذمہ دار)، پروڈکٹ اونر، اور ہسپتال نیٹ ورک کے لیے مریضوں کا پورٹل تیار کرنے والی وینڈر ٹیم شامل ہے۔ کمپلائنس ٹیم کو آڈٹ کی مقررہ تاریخ تک کنٹرولز (ضوابط) کے ایک سیٹ پر باضابطہ منظوری درکار ہے۔ پروڈکٹ اونر طبی عملے (کلینیشنز) کی طرف سے آج صبح موصول ہونے والی تبدیلیوں کا ایک نیا سیٹ دکھاتا ہے؛ یہ محض الفاظ کی معمولی تبدیلیاں نہیں بلکہ اہم اور بنیادی نوعیت کی تبدیلیاں ہیں۔ وینڈر تقاضا کرتا ہے کہ ضروریات (requirements) کی حتمی اور مستحکم دستاویز فراہم کی جائے تاکہ وہ تیاری اور ٹیسٹنگ کا کام مکمل کر سکیں۔ ہر فریق کا مطالبہ معقول ہے، لیکن یہ سب بیک وقت درست ثابت نہیں ہو سکتے۔ ہر ہفتے ٹیم منظوری کے حصول کے لیے ضروریات کو حتمی شکل (لاک) دیتی ہے، اور پھر حقیقی صارفین کے تاثرات پر عمل کرنے کے لیے انہیں دوبارہ کھول دیتی ہے۔ اس عمل میں دوبارہ کام (rework) کا بوجھ بڑھتا جاتا ہے، ٹیسٹنگ کے لیے وقت کم پڑ جاتا ہے، اور آڈٹ ٹریل (ریکارڈ) بے ترتیب ہو جاتا ہے کیونکہ فیصلوں پر نظر ثانی تو کی جاتی ہے لیکن منظوری کا کوئی واضح ریکارڈ موجود نہیں ہوتا۔
کسی ڈیلیوری کے طریقہ کار کا نام لینے سے پہلے، یہ اندازہ لگائیں کہ اگر آپ نے کچھ نہ کیا تو یہ منصوبہ سب سے پہلے کس مقام پر ناکام ہوگا۔
ایک عام غلط فہمی یہ سوچنا ہے کہ ٹیم کو یا تو تیز رفتاری کا انتخاب کرنا ہے یا پھر ضوابط کی پابندی (compliance) کا۔ اصل مسئلہ یہ ہے کہ اس پروجیکٹ میں دو مختلف قسم کے کام آپس میں ملے ہوئے ہیں۔ ایک حصے کے لیے ‘ٹریسیبلٹی’ (traceability) یا کام کے ہر مرحلے کا سراغ لگانے کی صلاحیت درکار ہوتی ہے؛ یعنی ہم یہ دکھا سکیں کہ کس طرح ایک ضرورت (requirement) پہلے ڈیزائن، پھر تعمیر (build)، پھر ٹیسٹ اور آخر میں منظوری کے مراحل سے گزری۔ دوسرے حصے کے لیے ‘تیز رفتار سیکھنے کے عمل’ (rapid learning) کی ضرورت ہوتی ہے، جس کا مطلب ہے کہ صارفین سے ملنے والی معلومات کی بنیاد پر ہم اپنی تیار کردہ چیز میں ترامیم کرنے کی توقع رکھتے ہیں۔ جب آپ تیز رفتار سیکھنے کے عمل کو منظوری کے طویل اور پیچیدہ طریقہ کار میں زبردستی شامل کرتے ہیں، تو کام میں رکاوٹیں (bottlenecks) پیدا ہوتی ہیں۔ اسی طرح، جب آپ واضح کنٹرولز کے بغیر تیز رفتار سائیکل میں ٹریسیبلٹی کو شامل کرنے کی کوشش کرتے ہیں، تو آڈٹ کے دوران مسائل یا اعتراضات (audit findings) سامنے آتے ہیں۔ نئے مینیجرز کا فطری رجحان یہ ہوتا ہے کہ وہ سب کو ایک نکتے پر متفق ہونے اور پروجیکٹ کے دائرہ کار (scope) کو حتمی شکل دے کر منجمد (freeze) کرنے کا کہتے ہیں۔ یہ عمل قیادت کی علامت محسوس ہوتا ہے کیونکہ اس سے وقتی طور پر انتشار یا شور و غل کم ہو جاتا ہے، لیکن جب حقیقت سامنے آتی ہے تو اکثر ‘تبدیلی کی درخواستوں’ (change requests) کا سیلاب آ جاتا ہے۔
پروجیکٹ مینجمنٹ کی حقیقت ضوابط کے تحت ہونے والے کاموں میں، آپ آڈٹ کی تاریخ پر کوئی سودے بازی نہیں کرتے۔ آپ اس بات پر بات چیت کرتے ہیں کہ اس تاریخ تک کون سا کام دائرہ کار میں شامل ہوگا اور تبدیلیاں منظوری کے مراحل سے کیسے گزریں گی۔
جب لوگ ‘ایجائل’ (Agile) یا ‘واٹر فال’ (Waterfall) کا ذکر کرتے ہیں، تو ان کی مراد اکثر فیصلوں کا ایک مجموعہ ہوتا ہے۔ اس کورس کے لیے، ہم اس مجموعے کو تین ایسے عملی عوامل (levers) میں تقسیم کریں گے جنہیں آپ شعوری طور پر ترتیب دے سکتے ہیں۔
پہلا عنصر فیڈ بیک لوپ (feedback loop) ہے، یعنی آپ کتنی بار صارفین یا اسٹیک ہولڈرز سے حقیقی آراء حاصل کرتے ہیں اور اسے اپنی تیار کردہ مصنوعات میں تبدیلیوں کا حصہ بناتے ہیں۔ مختصر لوپس آپ کو تیزی سے سیکھنے میں مدد دیتے ہیں، لیکن ان کے نتیجے میں تبدیلیوں کا دباؤ بھی بڑھ جاتا ہے جسے سنبھالنا ضروری ہوتا ہے۔
دوسرا عنصر منصوبہ بندی کا افق (planning horizon) ہے، یعنی تعمیر اور ٹیسٹ کے مرحلے کا آغاز کرنے سے پہلے آپ کتنی دور کی منصوبہ بندی تفصیل کے ساتھ کرتے ہیں۔ طویل مدتی منصوبہ بندی پیش گوئی کی صلاحیت کو بڑھا سکتی ہے، لیکن اس کے لیے ضروری ہے کہ ضروریات (requirements) مستحکم رہیں۔ مختصر مدتی منصوبہ بندی غیر یقینی صورتحال کو تسلیم کرتی ہے، لیکن اس کے لیے اسٹیک ہولڈرز کا مسلسل شامل رہنا ضروری ہے تاکہ ٹیم کو اندازوں پر انحصار نہ کرنا پڑے۔
تیسرا عنصر کنٹرول پوائنٹس (control points) ہیں، یعنی وہ مراحل جہاں کام کو آگے بڑھانے کے لیے اسے طے شدہ معیارات پر پورا اترنا لازمی ہوتا ہے۔ کنٹرول پوائنٹ کوئی باضابطہ منظوری، سیکیورٹی کا جائزہ، یا ٹیسٹنگ کے مرحلے میں داخلے کا گیٹ ہو سکتا ہے۔ کنٹرول پوائنٹس خطرات کو کم کرتے ہیں، لیکن ان کی وجہ سے انتظامی بوجھ اور انتظار کا وقت بڑھ جاتا ہے۔
ان تینوں عناصر کا پروجیکٹ کے نتائج سے موازنہ کریں اور ان کے درمیان ہونے والے سمجھوتوں (trade-offs) پر غور کریں۔