اپنے پارٹنر نیٹ ورک کے لیے میچورٹی ماڈل کیسے بنائیں

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

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

میچورٹی ماڈل کیا ہے، اور یہ تصور کہاں سے آیا

نومبر 1986 میں، Carnegie Mellon University کے Software Engineering Institute نے ایک درخواست کے جواب میں پراسیس میچورٹی کا فریم ورک تیار کرنا شروع کیا۔ مقصد امریکی وفاقی حکومت کو ایسا طریقہ فراہم کرنا تھا جس سے وہ اپنے سافٹ ویئر کنٹریکٹرز کی صلاحیت کا جائزہ لے سکے۔ 1993 تک یہ Capability Maturity Model for Software بن چکا تھا، جس کی پانچ میچورٹی سطحیں، SEI کے اپنے الفاظ میں، ”ایک ترتیبی پیمانہ متعین کرتی ہیں“ [1]۔

اس کی بنیادی ساخت برقرار رہی ہے: سطحوں کا ایک سلسلہ، جو ترقی کے متوقع، مطلوبہ یا عام راستے کو الگ الگ مراحل میں بیان کرتا ہے [2]۔ ہر سطح بتاتی ہے کہ وہاں پہنچنے کے لیے کیا درست ہونا ضروری ہے، اس لیے جائزے سے تنظیم کا اس راستے پر مقام معلوم ہوتا ہے اور اگلا قدم سامنے آتا ہے۔ 2005 تک IT خدمات سے لے کر نالج مینجمنٹ تک کے شعبوں میں 150 سے زیادہ میچورٹی ماڈل موجود تھے [3]، لیکن جب Becker، Knackstedt اور Pöppelbuß نے ان میں سے 51 کا جائزہ لیا تو صرف نو میں ڈیزائن کا عمل تفصیل سے درج تھا [2]۔ آگے اسی تحقیق کا طریقہ پروگرام ٹیموں کے لیے ڈھال کر پیش کیا گیا ہے۔

آٹھ مراحل میں میچورٹی ماڈل کیسے بنائیں

یہ مراحل کسی بھی میچورٹی ماڈل کی تیاری کے لیے de Bruin، Rosemann، Freeze اور Kulkarni کے تجویز کردہ مراحل کے مطابق ہیں: دائرۂ کار، ڈیزائن، مواد کی تیاری، جانچ، نفاذ اور دیکھ بھال [3]۔ ہر فیصلہ اگلے مرحلے کو محدود کرتا ہے، اور پائلٹ کے بعد آپ کو کم از کم ایک بار وضاحتیں دوبارہ لکھنی پڑیں گی۔

1. طے کریں کہ ماڈل کس مقصد کے لیے ہے

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

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

2. جہتیں منتخب کریں

جہتیں وہ موضوعات ہیں جن کا ماڈل احاطہ کرتا ہے: گورننس، مالیات، ڈیجیٹل مہارتیں، تحفظ، نوجوانوں کی شرکت۔ پیچیدگی محدود رکھنے اور انہیں ایک دوسرے سے الگ رکھنے کے لیے جہتیں کم رکھیں (de Bruin اور ان کے ساتھیوں کے دو ماڈلز میں چھ اور چار بنیادی اجزا تھے)، اور اس بات کو یقینی بنائیں کہ وہ باہم غیر متداخل اور مجموعی طور پر مکمل ہوں [3]: کسی بھی ثبوت کو دو بار شمار نہیں ہونا چاہیے، اور مقصد کے لیے ضروری کوئی چیز چھوٹنی نہیں چاہیے۔ میری کوشش ہوتی ہے کہ چار سے سات جہتیں رکھی جائیں، اور وسیع موضوعات کو دو یا تین ذیلی جہتوں میں تقسیم کیا جائے۔

اپنا ماڈل لکھنے سے پہلے دیکھیں کہ پہلے سے کیا موجود ہے: نیا ماڈل بنانے کے لیے موجودہ ماڈلز سے موازنہ کرنا Becker اور ان کے ساتھیوں کی پہلی شرط ہے [2]۔ صلاحیت کو مضبوط بنانے کے لیے، Venture Philanthropy Partners کے لیے McKinsey کی 2001 کی گرڈ کے سات عناصر ایک مضبوط نقطۂ آغاز ہیں [5]، اور ہماری پارٹنر کی صلاحیت کے جائزے کی رہنما میں دیے گئے چھ شعبے بھی۔

3. چار یا پانچ سطحیں منتخب کریں

CMM میں پانچ سطحیں ہیں [1]؛ McKinsey کی گرڈ میں چار [5]۔ تعداد سے زیادہ اہم وہ شرط ہے جو de Bruin اور ان کے ساتھیوں نے بیان کی ہے: مراحل الگ اور واضح طور پر متعین ہوں، ان کی ترتیب منطقی ہو، اور ہر مرحلے کا مختصر نام اس کا مقصد ظاہر کرے [3]۔

میرا اصول آپریشنز ریسرچ کے تجربے سے آیا ہے: کسی سطح کو صرف اسی صورت جگہ ملنی چاہیے جب آپ اسے شواہد سے بیان کر سکیں اور اس کے پڑوس کی سطحوں سے الگ ثابت کر سکیں۔ اپنے نیٹ ورک میں حقیقتاً دیکھی جا سکنے والی حالتوں کو گنیں، پھر وہیں رک جائیں۔ تعداد بڑھ بھی سکتی ہے: Becker اور ان کے ساتھیوں نے IT کارکردگی کا ماڈل چار مراحل سے شروع کیا، پھر IT مینیجرز کے انٹرویوز کے بعد اسے چھ مراحل تک بڑھایا، ”غیر موجود“ سے ”بہترین حالت میں“ تک، تاکہ کمزور صورتوں میں فرق واضح ہو [2]۔ اور نچلی سطح کو فیصلے کے بجائے نقطۂ آغاز کے طور پر لکھیں: ”کھوج“ گفتگو کا آغاز کرتا ہے؛ ”ناقص“ اسے ختم کر دیتا ہے۔

4. ہر سطح کو ایک قابلِ مشاہدہ حالت کے طور پر لکھیں

زیادہ تر ماڈل اسی مرحلے پر ناکام ہوتے ہیں۔ وضاحت سے مراد گرڈ کے ایک خانے میں درج متن ہے۔ Pöppelbuß اور Röglinger ایک مفید میچورٹی ماڈل کے ڈیزائن اصولوں میں ایسے معیارات کو شامل کرتے ہیں جن کی مختلف افراد آزادانہ طور پر تصدیق کر سکیں: وضاحتیں اتنی درست اور واضح ہوں کہ ایک سطح کو دوسری سے الگ کیا جا سکے [4]۔ سادہ الفاظ میں، ایک ہی پارٹنر کو دیکھنے والے دو افراد کو ایک ہی خانہ منتخب کرنا چاہیے۔

تین عادتیں مددگار ہیں:

• ایسی چیز کا نام لیں جسے دیکھا یا ہاتھ میں لیا جا سکے: کوئی دستاویز، معمول، عہدہ یا عدد۔ ”اچھا“، ”مضبوط“، ”مناسب“ اور ”مؤثر“ جیسے الفاظ سے گریز کریں۔
• ہر مرحلے میں ایک چیز تبدیل کریں۔ اگر سطح 3 میں ایک ساتھ بجٹ، ذمہ دار فرد اور سالانہ جائزہ شامل ہوں تو جس پارٹنر کے پاس ان میں سے دو چیزیں ہوں، اس کے لیے کوئی مناسب خانہ نہیں ہوگا۔
• سطحوں کو تدریجی بنائیں۔ ہر مرحلے میں اس سے نچلے مراحل کی شرائط بھی شامل ہونی چاہئیں [3]۔ میرے آپریشنز ریسرچ کے دور کا ایک امتحان: ایسے پارٹنر کا تصور کریں جس کے لیے سطح 3 درست ہو، مگر سطح 2 نہ ہو۔ اگر ایسا ممکن ہو تو ترتیب غلط ہے، یا یہ خانہ کسی اور جہت سے تعلق رکھتا ہے۔

5. ہر سطح کے شواہد متعین کریں

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

6. پارٹنرز کے ساتھ ماڈل کی توثیق کریں

مسودہ ان لوگوں کو دکھائیں جنہیں اس کے ساتھ کام کرنا ہوگا۔ de Bruin اور ان کے ساتھیوں نے اپنے ماڈلز بنانے اور جانچنے کے لیے Delphi تکنیک اور فوکس گروپس استعمال کیے [3]؛ McKinsey نے اپنی گرڈ کو تقریباً ایک درجن غیر منافع بخش اداروں کے ایگزیکٹو ڈائریکٹرز کے ساتھ آزمایا [5]؛ اور CMM کا ورژن 1.1، ورژن 1.0 پر ہونے والی ورکشاپ کے تاثرات کے نتیجے میں سامنے آیا، جس میں تقریباً 200 سافٹ ویئر پیشہ ور افراد نے شرکت کی تھی [1]۔ پارٹنر نیٹ ورک کے لیے آٹھ سے دس مختلف پارٹنرز کے ساتھ دو گھنٹے کی ورکشاپ سے آغاز کریں۔ پوچھیں: کیا آپ اس میں خود کو پہچانتے ہیں؟ کیا یہ آپ کی زبان ہے؟ کیا کچھ غائب ہے؟ کیا کوئی بات توہین آمیز ہے؟

7. پائلٹ کریں اور پیمانے کی درستی کریں

تین سے پانچ پارٹنرز کے ساتھ ماڈل کو حقیقت میں آزمائیں۔ de Bruin اور ان کے ساتھی اس بات پر زور دیتے ہیں کہ آلے کی صداقت اور قابلِ اعتماد ہونے کی جانچ ضروری ہے، تاکہ نتائج درست اور دہرائے جا سکیں [3]۔ عملی طور پر اس کا مطلب ہے کہ دو افراد ایک ہی پارٹنر کا الگ الگ جائزہ لیں، اور ہر اختلاف کی بنیاد بننے والی وضاحت کو دوبارہ لکھا جائے۔ اگر ہر پائلٹ پارٹنر سطح 2 پر ہو تو آپ کی سطحیں فرق واضح نہیں کر رہیں؛ اگر کوئی سطح 4 تک پہنچنے کا تصور بھی نہ کر سکے تو یہ محض خواہشات کی فہرست ہے۔ جو پیمانہ سب کو ایک ہی خانے میں رکھے، وہ کوئی معلومات فراہم نہیں کرتا۔

8. تبدیلیوں کی نگرانی کریں اور دوبارہ جائزہ لیں

Becker اور ان کے ساتھی نوٹ کرتے ہیں کہ حالات، ٹیکنالوجی اور علم میں تبدیلی کے ساتھ ہر میچورٹی ماڈل پرانا ہو جاتا ہے، اور ضروری تبدیلیاں ماڈل کے نئے ورژن میں شامل ہونی چاہئیں [2]۔ اپنے ماڈل کو ایک معیار کی طرح سنبھالیں: ورژن نمبر رکھیں، ہر سال تبدیلی کے لیے ایک مقررہ مدت رکھیں، کیا اور کیوں بدلا اس کا ریکارڈ رکھیں، اور جائزے کے دور کے درمیان ترمیم نہ کریں۔ جب ورژن 1.1 میں کوئی خانہ بدلے تو بتائیں کہ ورژن 1.0 کے تحت درج پوزیشنز کو نئے ورژن میں کیسے منتقل کیا جائے گا، تاکہ جملہ دوبارہ لکھنے کی وجہ سے کسی پارٹنر کی سطح نہ گرے۔ پھر ہر 6 سے 12 ماہ بعد دوبارہ جائزہ لیں۔ ان جائزوں کو کیسے چلائیں، اور سطحوں کا اوسط لے کر ایک مجموعی اسکور کیوں نہیں بنانا چاہیے، یہ ہماری پارٹنر کی صلاحیت کے جائزے کی رہنما میں پڑھیں۔

پارٹنر میچورٹی ماڈل کا ٹیمپلیٹ (مفت ڈاؤن لوڈ)

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

میچورٹی ماڈل بلڈر ٹیمپلیٹ ڈاؤن لوڈ کریں (PDF، 4 صفحات)۔ اسے ڈیزائن ورکشاپ کے لیے پرنٹ کریں، یا اس کے حصے نقل کریں۔

مثال: ایک فیڈریشن کا ممبر ڈیجیٹل میچورٹی کا راستہ

یہاں ٹیمپلیٹ Meridian Youth Federation کے لیے پُر کیا گیا ہے، جو 26 قومی رکن تنظیموں پر مشتمل ایک فرضی فیڈریشن ہے۔

مکمل کی گئی مثال ڈاؤن لوڈ کریں (PDF، 4 صفحات)۔ چار فیصلے قابلِ تقلید ہیں:

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

میچورٹی ماڈل بناتے وقت عام غلطیاں

1. مقصد طے کرنے سے پہلے سطحیں لکھنا۔ رہنمائی کے لیے کوئی فیصلہ نہ ہو تو ماڈل درجہ بندی بن جاتا ہے، اور پارٹنرز بھی اسے اسی نظر سے دیکھتے ہیں۔
2. سوالنامے کو ماڈل سمجھ لینا۔ SEI نے 1987 میں اپنا میچورٹی سوالنامہ جاری کیا، مگر لوگوں نے اکثر اسے خود ماڈل سمجھ لیا [1]۔ ماڈل ترقی کا راستہ ہے؛ سوالنامہ اسے ناپنے کا ایک طریقہ ہے۔
3. قابلِ مشاہدہ حالتوں کے بجائے صفات استعمال کرنا۔ ”مناسب“ کا مطلب ہر جائزہ لینے والے کے لیے مختلف ہوتا ہے۔
4. بہت زیادہ جہتیں رکھنا۔ چالیس اشاریوں والا ماڈل کوئی مکمل نہیں کرتا۔
5. پارٹنرز کے لیے ڈیزائن کرنا، ان کے ساتھ نہیں۔ اگر سطح 1 کو ناکامیوں کی فہرست کے طور پر لکھا جائے تو پارٹنرز باتیں چھپانا سیکھتے ہیں۔
6. جائزے کے دور کے درمیان تبدیلی کرنا۔ وضاحت میں ایک ترمیم بھی اس دور کو پچھلے دور سے ناقابلِ موازنہ بنا دیتی ہے۔

Advancer.World میں اپنا میچورٹی ماڈل بنائیں

Advancer.World کا آغاز UNICEF اور Airbus جیسی تنظیموں کے پروگراموں کی ڈیجیٹل تبدیلی کے تجربے سے ہوا، اور اس میں ایک پروگرام کی ساخت میچورٹی ماڈل جیسی ہے: مراحل آپ کی سطحیں، موضوعات اور ذیلی موضوعات آپ کی جہتیں، اور ہر خانے میں ایک وضاحت ہوتی ہے۔

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

اکثر پوچھے جانے والے سوالات

میچورٹی ماڈل میں کتنے درجے ہونے چاہییں؟

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

میچورٹی ماڈل بنانے میں کتنا وقت لگتا ہے؟

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

کیا ہم نیا ماڈل بنانے کے بجائے پہلے سے موجود میچورٹی ماڈل کو اپنا سکتے ہیں؟

اکثر ایسا ممکن ہے، اور سب سے پہلے آپ کو یہی دیکھنا چاہیے [2]۔ لائسنس چیک کریں، اگر اس کی ساخت آپ کے مقصد کے لیے موزوں ہو تو اسے برقرار رکھیں، اور وضاحتی تفصیلات اپنے نیٹ ورک کی زبان میں دوبارہ لکھیں۔

کیا ایک پارٹنر مختلف جہتوں میں مختلف درجوں پر ہو سکتا ہے؟

جی ہاں، اور عموماً ایسا ہی ہوتا ہے؛ ماڈل کا سب سے مفید نتیجہ یہی پروفائل ہوتا ہے۔ البتہ ایک ہی جہت میں پارٹنر کو درجات چھوڑ کر آگے نہیں بڑھنا چاہیے—یہی نکتہ CMM کے مصنفین نے اپنے ماڈل کے درجات کے حوالے سے بیان کیا تھا [1]۔

درجات سے نہیں، مقصد سے آغاز کریں

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

حوالہ جات

1. Mark C. Paulk, Bill Curtis, Mary Beth Chrissis and Charles V. Weber، Software Engineering Institute, Carnegie Mellon University، "Capability Maturity Model for Software, Version 1.1" (CMU/SEI-93-TR-024)، فروری 1993، https://www.sei.cmu.edu/library/capability-maturity-model-for-software-version-11/ (اکتوبر 2026 میں دیکھا گیا)۔
2. Jörg Becker, Ralf Knackstedt and Jens Pöppelbuß، "Developing Maturity Models for IT Management: A Procedure Model and its Application"، Business & Information Systems Engineering، 1(3)، 2009، صفحات 213-222، https://doi.org/10.1007/s12599-009-0044-5 (اکتوبر 2026 میں دیکھا گیا)۔
3. Tonia de Bruin, Michael Rosemann, Ronald Freeze and Uday Kulkarni، "Understanding the Main Phases of Developing a Maturity Assessment Model"، 16th Australasian Conference on Information Systems (ACIS)، سڈنی، 2005، https://aisel.aisnet.org/acis2005/109 (اکتوبر 2026 میں دیکھا گیا)۔
4. Jens Pöppelbuß and Maximilian Röglinger، "What Makes a Useful Maturity Model? A Framework of General Design Principles for Maturity Models and its Demonstration in Business Process Management"، Proceedings of the 19th European Conference on Information Systems (ECIS 2011)، جون 2011، https://aisel.aisnet.org/ecis2011/28/ (اکتوبر 2026 میں دیکھا گیا)۔
5. McKinsey & Company for Venture Philanthropy Partners، "Effective Capacity Building in Nonprofit Organizations"، 2001، https://www.bridgespan.org/getmedia/ef1ff943-173b-48ec-843a-b5ce85c6c807/effective-capacity-building-VPP.pdf (اکتوبر 2026 میں دیکھا گیا)۔

© 2026 Mourinho Solutions۔ جملہ حقوق محفوظ ہیں۔