اگر آپ کا سافٹ ویئر پروجیکٹ ناکام ہوجاتا ہے تو کیا ہوگا؟ قانونی اختیارات اور روک تھام

ایک سافٹ ویئر پروجیکٹ جو رک جاتا ہے دونوں فریقوں کے لیے ایک سنگین دھچکا ہے۔ کلائنٹ نے ایک ایسے نظام میں سرمایہ کاری کی جس کا مقصد اپنے کاموں کو بہتر بنانا ہے اور کام کے نتائج کے بغیر ڈیڈ لائن گزرتے دیکھنا ہے۔ فراہم کنندہ اکثر ایک مختلف تصویر دیکھتا ہے: ایک کلائنٹ جو نئی خواہشات پیش کرتا رہتا ہے، فیصلے ملتوی کرتا ہے یا بہت کم معلومات فراہم کرتا ہے۔

تو نقصان کون اٹھاتا ہے؟ شروع میں چار نکات:

• ایک ناکام سافٹ ویئر پروجیکٹ سپلائر کی طرف سے انجام دینے میں خود بخود ناکامی نہیں ہے۔
• مؤکل کا تعاون بھی قانونی طور پر متعلقہ ہو سکتا ہے۔
• پراجیکٹ کے اچھے ریکارڈ اور معاہدے کے انتظامات قانونی چارہ جوئی کے خطرے کو محدود کرتے ہیں۔
• تکنیکی تشخیص کے لیے ماہرانہ تفتیش فیصلہ کن ثابت ہو سکتی ہے۔

ذیل میں ہم عام وجوہات، قانونی تشخیص، مؤکل کا تعاون کرنے کا فرض، ماہرانہ تفتیش، کارروائی کے ممکنہ نتائج، کون سی عملی مثالیں ظاہر کرتے ہیں، اور کون سے اقدامات تنازعہ کو روک سکتے ہیں ان کا ذکر کرتے ہیں۔

عام وجوہات

عملی طور پر مٹھی بھر وجوہات کی تکرار ہوتی ہے۔

• دائرہ کار، تفویض کی بتدریج توسیع. نظام کی ضروریات منصوبہ بندی اور بجٹ کے نتائج کو حل کرنے کے لیے باقاعدہ تبدیلی کے طریقہ کار کے بغیر بڑھتی رہتی ہیں۔
• غیر واضح یا نامکمل فنکشنل تصریحات۔ اگر یہ پہلے سے قائم نہیں کیا جاتا ہے کہ سسٹم کو کیا کرنا چاہیے، تو اس بارے میں تنازعہ پیدا ہو گا کہ آیا ڈیلیور کردہ نتیجہ کی تعمیل ہوتی ہے۔
• ناقص سسٹم ڈیزائن۔ فن تعمیر اصل بوجھ، دوسرے سسٹمز کے ساتھ انٹرفیس، یا مستقبل میں توسیع کے لیے نہیں بنایا گیا ہے۔
• پیچیدگی اور لیڈ ٹائم کو کم سمجھنا، خاص طور پر ان پروجیکٹس پر جہاں کئی موجودہ سسٹمز کو منسلک ہونا ضروری ہے۔
• مؤکل کی طرف سے دیر سے یا محدود تعاون۔

یہ اسباب شاذ و نادر ہی اکیلے کھڑے ہوتے ہیں۔ وہ اکثر ایک دوسرے کو تقویت دیتے ہیں۔ ایک پروجیکٹ جو ابتدائی طور پر صرف دیر سے چلتا ہے اس کے نتیجے میں مکمل طور پر ناکام ہوسکتا ہے۔

قانونی تشخیص: انجام دینے میں ناکامی اور معاون غلطی

پہلا قانونی سوال یہ ہے کہ آیا فراہم کنندہ منسوب خلاف ورزی میں ہے۔ ڈچ سول کوڈ کا آرٹیکل 6:74 قرض دہندہ کو اس نقصان کی تلافی کرنے کا پابند کرتا ہے جو قرض دہندہ کو انجام دینے میں ناکامی کی وجہ سے ہوتا ہے، جب تک کہ اس ناکامی کو اس سے منسوب نہ کیا جائے۔

اس لیے ایک کامیاب دعوی کے لیے یہ قائم کرنے کی ضرورت ہوتی ہے کہ فراہم کنندہ نے وہ ڈیلیور نہیں کیا جس پر اتفاق کیا گیا تھا، مثال کے طور پر کیونکہ سافٹ ویئر ریکارڈ شدہ فنکشنل تصریحات کو پورا نہیں کرتا ہے۔ اور ناکامی اس سے منسوب ہونی چاہیے، یعنی کوئی زبردستی میجر نہیں ہے۔

عملی طور پر، ذمہ داری اکثر مشترکہ ہے. کلائنٹ نے کچھ تقاضوں پر دیر سے وضاحت فراہم کی، منصوبہ بندی اور لاگت کے نتائج کو قبول کیے بغیر پروجیکٹ کے دوران اپنی خواہشات کو تبدیل کیا، یا کوئی قابل استعمال ٹیسٹ ماحول دستیاب نہیں کرایا۔

ایسی صورت میں عدالت ڈچ سول کوڈ کے آرٹیکل 6:101 کے تحت فراہم کنندہ کی معاوضہ کی ذمہ داری کو کم کر سکتی ہے، اس حد کے تناسب سے جس حد تک مؤکل سے منسوب حالات نے نقصان میں حصہ ڈالا۔ شراکتی غلطی کا یہ نظریہ ایوارڈ کو کافی حد تک کم کر سکتا ہے، اور غیر معمولی معاملات میں اسے مکمل طور پر برخاست کر دیا جاتا ہے۔

دونوں فریقوں کے لیے عملی مشورہ: پورے پروجیکٹ میں دستاویز جو کون سے فیصلے لیتا ہے، کون سی تبدیلیاں کی جاتی ہیں، اور کون سی معلومات کب فراہم کی جاتی ہیں۔ کارروائی میں، وہ ریکارڈ اکثر مکمل ذمہ داری اور بھاری معتدل نتائج کے درمیان فرق کرتا ہے۔

تعاون کرنا مؤکل کا فرض ہے۔

سافٹ ویئر کا نفاذ ایک مشترکہ کوشش ہے۔ سپلائر بناتا اور ترتیب دیتا ہے، لیکن مسلسل کلائنٹ پر انحصار کرتا ہے: بروقت اور مکمل وضاحتیں، قابل استعمال ٹیسٹ ڈیٹا، کھلے سوالات پر فوری فیصلے، اور فراہم کردہ اجزاء کی بروقت قبولیت۔

جہاں یہ تعاون موجود نہیں ہے، سپلائر اپنا کام نہیں کر سکتا۔ قانون اس کے نتائج کو منسلک کرتا ہے۔ آرٹیکل 6:58 اور ترتیب۔ ڈچ سول کوڈ قرض دہندہ کے ڈیفالٹ کو کنٹرول کرتا ہے، جو اس وقت پیدا ہوتا ہے جب قرض دہندہ کی کارکردگی کو روکا جاتا ہے کیونکہ قرض دہندہ سے مطلوبہ تعاون آنے والا نہیں ہے۔

عملی طور پر ترجمہ: اگر سپلائی کرنے میں تاخیر ہوتی ہے کیونکہ کلائنٹ وقت پر ضرورت کے مطابق سپلائی نہیں کرتا، تو سپلائر ڈیفالٹ میں نہیں آتا اور اس تاخیر کا ذمہ دار نہیں ہوتا۔ یہ کلائنٹ ہے جو خود ڈیفالٹ میں ہوسکتا ہے۔ چونکہ سافٹ ویئر پراجیکٹس عام طور پر تکراری ہوتے ہیں، ہر مرحلے میں پچھلے ایک سے فیڈ بیک اور منظوری کے ساتھ، غیر حاضر ان پٹ کو باقاعدگی سے کیس لا میں استعمال کیا جاتا ہے تاکہ تاخیر کو مکمل یا جزوی طور پر مؤکل سے منسوب کیا جا سکے۔

کلائنٹس کے لیے یہ نوٹ کرنے کی بات ہے: جہاں آپ کی اپنی فیصلہ سازی سست ہوتی ہے وہاں پیشرفت پر تنقید کا وزن کم ہوتا ہے۔ سپلائرز کے لیے الٹا لاگو ہوتا ہے: فلیگ میں تاخیر کلائنٹ سے فوری طور پر اور تحریری طور پر، مثال کے طور پر واضح انتباہ یا ڈیفالٹ کے نوٹس کے ساتھ جیسے ہی ضروری ان پٹ مکمل ہونے میں ناکام ہو جاتا ہے۔ اگر ایسا نہیں ہوتا ہے، تو اس کے بعد تعمیر نو کرنا اکثر ناممکن ہوتا ہے کہ کس نے تاخیر کی۔

ماہر تحقیقات

سافٹ ویئر کے منصوبے تکنیکی نوعیت کے ہوتے ہیں۔ کیا فراہم کردہ سافٹ ویئر وضاحتوں پر پورا اترتا ہے؟ کیا تاخیر سپلائر یا کلائنٹ کے ساتھ ہوئی؟ کیا اضافی کام کی رسید جائز تھی؟ آرکیٹیکچر، سورس کوڈ، ترقی کے عمل کے ذریعے ضروریات کا پتہ لگانے اور ٹیسٹ رپورٹس کے مواد کے بارے میں سوالات تکنیکی علم کا مطالبہ کرتے ہیں جس کی جج سے توقع نہیں کی جا سکتی۔

اسی وجہ سے ڈچ کوڈ آف سول پروسیجر کے آرٹیکل 194 سے 207 کے تحت اکثر ان تنازعات میں عدالت کے حکم سے ماہر کی رپورٹ تیار کی جاتی ہے۔ اس کے بعد ایک آزاد ماہر اس بات کا جائزہ لیتا ہے کہ آیا سافٹ ویئر نے متفقہ شرائط کو پورا کیا، جہاں تاخیر ہوئی، اور کیا اس پر اٹھنے والے اخراجات مناسب تھے۔ عملی طور پر عدالت کے فیصلے میں نتائج کا بہت زیادہ وزن ہوتا ہے۔

ایک ماہر کو عام طور پر درج ذیل دستاویزات کی ضرورت ہوگی۔

• معاہدہ اور اس کے ملحقہ؛
• فنکشنل اور تکنیکی وضاحتیں؛
• تبدیلی کی درخواستیں؛
• منصوبے کی منصوبہ بندی اور پیش رفت کی رپورٹ؛
• ٹیسٹ رپورٹس؛
• تاخیر اور قبولیت کے بارے میں خط و کتابت؛
• ماخذ کوڈ اور دستاویزات۔

اگر اس کا کچھ حصہ غائب ہے، تو ماہر اکثر سوال کا جواب نہیں دے سکتا۔ یہ ان حقائق پر انحصار کرتے ہوئے پارٹی کی واضح پوزیشن میں کام کرتا ہے۔ اس لیے یہ اس فائل کو پروجیکٹ کے دوران ترتیب میں رکھنے کی ادائیگی کرتا ہے، نہ صرف ایک بار تنازعہ پیدا ہونے پر۔

کارروائی کے ممکنہ نتائج

جہاں معاہدے کا صرف ایک حصہ غلط ہوا ہے، مثال کے طور پر کیونکہ ایک ماڈیول کام نہیں کرتا جبکہ باقی قابل استعمال ہے، عدالت ڈچ سول کوڈ کے آرٹیکل 6:270 کے ساتھ آرٹیکل 6:265 کے تحت جزوی تنسیخ کا حکم دے سکتی ہے۔ کامیاب حصہ پھر اپنی جگہ پر رہتا ہے۔

آرٹیکل 6:74 کے تحت ہرجانہ بھی دیا جا سکتا ہے، جسے آرٹیکل 6:101 کے تحت شراکتی غلطی کے لیے کم کیا جا سکتا ہے۔ آخر میں، عدالت آرٹیکل 6:109 کے تحت نقصانات کو معتدل کر سکتی ہے، مثال کے طور پر جہاں دعوی کی گئی رقم کا معاہدہ کی اصل قیمت سے کوئی تعلق نہیں ہے۔ عدالتیں اعتدال کی اس طاقت کو تھوڑا سا لاگو کرتی ہیں۔

عملی طور پر ایک ناکام سافٹ ویئر پروجیکٹ اکثر دوسرے سپلائر پر دوبارہ شروع ہونے کے ساتھ ختم ہوتا ہے۔ وہ بھی شاذ و نادر ہی بغیر بحث کے آگے بڑھتا ہے۔ سورس کوڈ کس کو ملتا ہے؟ بنائے گئے نظام میں املاک دانش کے حقوق کس کے پاس ہیں؟ کیا کوئی ایسکرو انتظام ہے، جس کے تحت ماخذ کوڈ کسی آزاد فریق ثالث کے پاس جمع کیا جاتا ہے؟ جس نے بھی شروع میں اس میں سے کچھ بھی طے نہیں کیا وہ اس وقت اسے ٹھیک سے نوٹس کرتا ہے۔

کیا عملی مثالیں ظاہر کرتی ہیں۔

عام عدالتوں کے ساتھ ساتھ، فاؤنڈیشن فار دی سیٹلمنٹ آف آٹومیشن ڈسپیوٹ (SGOA) آئی ٹی کے شعبے میں اہم کردار ادا کرتی ہے۔ تنازعات کا یہ آزاد ادارہ 1989 سے موجود ہے اور ثالثی، ثالثی، ثالثی کے خلاصے کی کارروائی، پابند مشورہ، ماہرانہ رپورٹس اور تنازعات سے بچاؤ کی پیشکش کرتا ہے۔ اس کے ثالث صنعت کے ماہرین ہیں، جو اس بات کی وضاحت کرتے ہیں کہ آئی ٹی کے بہت سے تنازعات عدالتوں میں کارروائی کے بجائے یہ راستہ کیوں اختیار کرتے ہیں۔

شائع شدہ SGOA فیصلے چند بار بار آنے والے اسباق کو ظاہر کرتے ہیں جو باہر کی کارروائی کے لیے بھی مفید ہیں:

• ذمہ داری شاذ و نادر ہی مکمل طور پر کسی ایک فریق پر ڈالی جاتی ہے۔ مختص ان میں سے ہر ایک نے اصل میں کیا اور کرنے میں ناکامی کے بعد کیا ہے۔
• تصریحات جو پروجیکٹ کی پیشرفت کے ساتھ تبدیل ہوتی ہیں تنازعہ کے سب سے عام نکات میں سے ہیں، اور رسمی تبدیلی کے طریقہ کار کی عدم موجودگی عام طور پر اصل معاہدے پر انحصار کرنے والے فریق کے خلاف شمار ہوتی ہے۔
• پروجیکٹ کے ریکارڈ کا معیار اکثر فیصلہ کن ہوتا ہے، کیونکہ یہ طے کرتا ہے کہ کون سے حقائق اب بھی قائم کیے جا سکتے ہیں۔

معاہدے کا مسودہ تیار کرنے والے ہر فرد کے لیے یہ مفید اشارے ہیں: یہ بالکل ایسے مضامین ہیں جو پہلے سے طے کیے جاتے ہیں۔

احتیاطی اقدامات

بہت سے تنازعات کو ٹھیک ٹھیک ٹھیک سیٹ اپ سے روکا جا سکتا ہے۔

• مرحلہ وار معاہدوں کے ساتھ کام کریں۔ پروجیکٹ کو ریلیز یا سنگ میل میں تقسیم کریں، ہر ایک کے اپنے قبولیت کے معیار کے ساتھ۔ یہ مہینوں کے بعد ہی پورے کا اندازہ لگانے سے گریز کرتا ہے۔
• رسید دینے سے پہلے رسمی قبولیت کے ٹیسٹ سے اتفاق کریں۔ اس کے بعد یہ طے کیا جاتا ہے کہ ادائیگی کی وجہ سے گرنے سے پہلے ڈیلیور شدہ جزو کو کیا پورا کرنا چاہیے۔
• تبدیلی کی درخواست کون کر سکتا ہے، کون فیصلہ کرتا ہے، اور منصوبہ بندی اور قیمت کے نتائج پر کیسے عمل ہوتا ہے، تبدیلی کا طریقہ کار ریکارڈ کریں۔
• ایک توسیعی سیڑھی سے اتفاق کریں: پہلے پروجیکٹ گروپ کے اندر بحث، پھر اعلیٰ سطح پر اسٹیئرنگ کمیٹی، پھر ثالث، اور اس کے بعد ہی عدالتوں میں کارروائی۔
• SGOA کے ذریعے تنازعات کے حل پر غور کریں۔ ایک عملی نکتہ پر دھیان دیں: ثالث صرف اس معاملے کی سماعت کر سکتے ہیں جہاں فریقین نے پہلے سے فاؤنڈیشن کو دائرہ اختیار دے دیا ہو، لہذا یہ شق معاہدہ میں ہونی چاہیے۔ SGOA اس کے لیے ماڈل شقیں دستیاب کراتی ہے۔

بڑھتی ہوئی سیڑھی اس بات کو یقینی بناتی ہے کہ تنازعات پر ابتدائی مرحلے اور صحیح سطح پر بات کی جائے، بجائے اس کے کہ صرف ایک بار تعلقات ٹوٹ جائیں۔ ایسے حالات میں جہاں ایک پروجیکٹ ایک نازک موڑ پر رک جاتا ہے اور ایک فریق تعاون نہیں کرے گا، SGOA کی ثالثی خلاصہ کارروائی تیزی سے ریلیف فراہم کرتی ہے۔

بند ہونے میں

ایک ناکام سافٹ ویئر پروجیکٹ شاذ و نادر ہی کسی ایک غلطی کا نتیجہ ہوتا ہے۔ یہ عام طور پر غیر واضح تصریحات، خواہشات کو بدلنے، تکنیکی کمی اور ناقص تعاون کے امتزاج سے پیدا ہوتا ہے۔ ڈچ قانون اس بات کا تعین کرنے کے لیے ایک باریک فریم ورک پیش کرتا ہے کہ نقصان کون برداشت کرتا ہے، انجام دینے میں ناکامی، شراکت دار کی غلطی اور قرض دہندہ کی ڈیفالٹ، لیکن اسے لاگو کرنے کے لیے قانون اور ٹیکنالوجی دونوں کے علم کی ضرورت ہوتی ہے۔

کیا آپ کا سافٹ ویئر پروجیکٹ رک رہا ہے؟ Law & More ذمہ داری، پروجیکٹ کے ریکارڈ، معاہدہ کی روک تھام اور تنازعات کے حل کے بارے میں گاہکوں اور سپلائرز کو مشورہ دیتا ہے۔ اپنے معاہدے اور اپنی پروجیکٹ فائل کی جانچ کے لیے ہم سے رابطہ کریں۔

اکثر پوچھے گئے سوالات

ذیل میں ہم ان سوالات کے جوابات دیتے ہیں جو ہم سے اکثر اس موضوع پر پوچھے جاتے ہیں۔

اگر سافٹ ویئر پروجیکٹ ناکام ہوجاتا ہے تو کیا میرا سپلائر ذمہ دار ہے؟

خود بخود نہیں۔ یہ ثابت ہونا چاہیے کہ اس نے وہ نہیں پہنچایا جس پر اتفاق کیا گیا تھا اور یہ اس سے منسوب ہے۔ عملی طور پر، ذمہ داری اکثر دونوں فریقوں کے درمیان مشترک ہوتی ہے۔

کیا ہوگا اگر، بطور مؤکل، میں نے خود تاخیر میں حصہ ڈالا؟

عدالت اس کے بعد ڈچ سول کوڈ کے آرٹیکل 6:101 کے تحت معاوضہ دینے کے لیے سپلائر کی ذمہ داری کو کم کر سکتی ہے، اس تناسب سے کہ آپ کے اپنے طرز عمل نے نقصان میں کتنا حصہ ڈالا۔ یہ ایوارڈ کو کافی حد تک کم کر سکتا ہے اور، غیر معمولی معاملات میں، اس کی برخاستگی کا باعث بن سکتا ہے۔

تعاون کرنے کے فرائض میں کیا شامل ہے؟

کلائنٹ کے طور پر آپ کو تصریحات، ٹیسٹ ڈیٹا، فیصلے اور قبولیت کو اچھے وقت میں فراہم کرنا چاہیے۔ اگر ایسا نہیں ہوتا ہے اور اس کے نتیجے میں فراہم کنندہ کارکردگی نہیں دکھا سکتا، تو یہ ڈیفالٹ میں نہیں آتا اور آپ خود قرض دہندہ کے ڈیفالٹ میں مبتلا ہو سکتے ہیں (ڈچ سول کوڈ کا آرٹیکل 6:58 اور ترتیب)۔

ایک ماہر کو اکثر کیوں مقرر کیا جاتا ہے؟

کیونکہ فن تعمیر، سورس کوڈ اور ٹیسٹ رپورٹس کے بارے میں سوالات کے لیے تکنیکی علم کی ضرورت ہوتی ہے جس کی جج سے توقع نہیں کی جا سکتی۔ ڈچ کوڈ آف سول پروسیجر کے آرٹیکلز 194 سے 207 کے تحت عدالت کے حکم سے ماہر رپورٹ تیار کی جا سکتی ہے، اور اس کے نتائج کا وزن بہت زیادہ ہے۔

مجھے کون سے پراجیکٹ دستاویزات رکھنا چاہئے؟

اس کے ملحقات کے ساتھ معاہدہ، فنکشنل اور تکنیکی وضاحتیں، تبدیلی کی درخواستیں، پروجیکٹ کی منصوبہ بندی اور پیش رفت کی رپورٹس، ٹیسٹ رپورٹس، تاخیر اور قبولیت کے بارے میں خط و کتابت، اور دستاویزات کے ساتھ سورس کوڈ۔ ان دستاویزات کے بغیر ایک ماہر اکثر سوال کا جواب نہیں دے سکتا۔

تبدیلی کا طریقہ کار اتنا اہم کیوں ہے؟

کسی رسمی طریقہ کار کے بغیر اسائنمنٹ پر کسی کا دھیان نہیں جاتا ہے جبکہ منصوبہ بندی اور بجٹ ایک جیسا رہتا ہے۔ ایک تنازعہ میں یہ قائم کرنا ناممکن ہے کہ دائرہ کار کب اور کیوں تبدیل ہوا۔ ریکارڈ کریں کہ کون تبدیلی کی درخواست کر سکتا ہے، کون فیصلہ کرتا ہے، اور منصوبہ بندی اور قیمت کے نتائج پر کیسے عمل ہوتا ہے۔

قبولیت کا معیار کیا ہے؟

وہ معروضی طور پر اس وقت قائم کرتے ہیں جب ڈیلیور شدہ جزو کی تعمیل ہوتی ہے۔ یہ واضح کرتا ہے کہ ادائیگی کب ہوتی ہے اور بڑی حد تک بعد میں اس بحث کو روکتا ہے کہ آیا ترسیل درست تھی۔ ترجیحی طور پر انہیں رسمی قبولیت ٹیسٹ کے ساتھ ریلیز یا سنگ میل سے جوڑیں۔

دوسرے سپلائر کے ساتھ دوبارہ شروع کرنے پر سورس کوڈ کا کیا ہوتا ہے؟

یہ آپ کے معاہدے پر منحصر ہے۔ ماخذ کوڈ کے اجراء کے انتظامات کے بغیر، بنائے گئے نظام میں دانشورانہ املاک کے حقوق پر، اور کسی بھی ایسکرو انتظامات پر، دوبارہ شروع کرنے میں کافی تاخیر ہو سکتی ہے۔ معاہدہ کرتے وقت اسے طے کریں، بعد میں نہیں۔

کارروائی کے کیا نتائج ہو سکتے ہیں؟

جزوی تنسیخ جہاں صرف ایک حصہ غلط ہوا ہے (ڈچ سول کوڈ کے آرٹیکل 6:265 کو 6:270 کے ساتھ پڑھا گیا ہے)، آرٹیکل 6:74 کے تحت نقصانات، آرٹیکل 6:101 کے تحت شراکتی غلطی میں کمی، اور آرٹیکل 6:109 کے تحت اعتدال۔ عدالتیں اس اعتدال کو تھوڑا سا لاگو کرتی ہیں۔

کیا میں عدالتوں کے باہر تنازعہ حل کر سکتا ہوں؟

جی ہاں SGOA ثالثی، ثالثی، ثالثی کے خلاصے کی کارروائی، پابند مشورہ اور ماہرانہ رپورٹیں پیش کرتا ہے، جس میں صنعت کے ماہرین فیصلہ ساز کے طور پر شامل ہوتے ہیں۔ ثالث صرف اس کیس کی سماعت کر سکتے ہیں جہاں فریقین نے پہلے سے فاؤنڈیشن کو دائرہ اختیار دیا ہو، اس لیے معاہدے میں اس شق کو شامل کریں۔

میں طویل عرصے سے جاری تنازعہ سے کیسے بچ سکتا ہوں؟

مرحلہ وار معاہدوں اور فی ریلیز قبولیت کے معیار کے ساتھ کام کریں، انوائسنگ سے پہلے رسمی قبولیت کے ٹیسٹ سے اتفاق کریں، تبدیلی کے طریقہ کار کو ریکارڈ کریں، اور پراجیکٹ گروپ سے اسٹیئرنگ کمیٹی، ثالث کی طرف بڑھنے والی سیڑھی پر اتفاق کریں اور اس کے بعد ہی عدالتوں میں کارروائی ہوگی۔

کیا آپ کا کسی IT سپلائر کے ساتھ تنازعہ ہے، یا آپ چاہتے ہیں کہ IT معاہدہ کا جائزہ لیا جائے؟ ہمارے آئی ٹی وکلاء مدد کرنے میں خوش ہیں۔

کس طرح Law & More اس کے ساتھ آپ کی مدد کر سکتے ہیں ہماری پر وضاحت کی گئی ہے آئی ٹی وکیل صفحہ.