বিষয় 5.1 — প্রকল্প-চালিত কাজ

এক বাক্যে: প্রকল্প-চালিত কাজ সঠিক সরঞ্জাম যখন কাজটির একটি সংজ্ঞায়িত পরিধি, একটি সসীম জীবন এবং একটি স্পষ্ট শেষ অবস্থা আছে, একটি অস্থায়ী, নিয়ন্ত্রিত প্রচেষ্টা যা সম্মত সময়, খরচ ও মানে সরবরাহ করা হয়, তারপর বন্ধ করা হয়।

স্বাস্থ্য ও পরিচর্যায় কেন এটি গুরুত্বপূর্ণ#

সবকিছু জীবন্ত সেবা নয়। স্বাস্থ্য ও পরিচর্যার কিছু সবচেয়ে গুরুত্বপূর্ণ কাজ সত্যিই সসীম: একটি ইলেকট্রনিক পেশেন্ট রেকর্ড থেকে অন্যটিতে স্থানান্তর, একটি হাসপাতাল এস্টেট জুড়ে Wi-Fi রোলআউট, জীবন-শেষ সার্ভার প্রতিস্থাপন, একটি সরবরাহকারী চুক্তি শেষ হওয়ার আগে একটি লিগ্যাসি সিস্টেম ডিকমিশন, বা একটি নতুন হাসপাতাল ভবনের ডিজিটাল অংশ সরবরাহ। এই কাজের একটি শুরু, একটি মধ্যভাগ এবং একটি নির্দিষ্ট শেষ আছে। এটিকে একটি অন্তহীন পণ্য হিসেবে পরিচালনা অর্থ নষ্ট ও জবাবদিহিতা ঝাপসা করবে; এর একটি প্রকল্পের শৃঙ্খলা দরকার।

প্রকল্প ব্যবস্থাপনা এখানে ঠিক তার মূল্য দেয় কারণ ঝুঁকি উঁচু এবং সীমাবদ্ধতা কঠিন। একটি ডেটা-স্থানান্তর কাটওভারের একটি নির্দিষ্ট গো-লাইভ সপ্তাহান্ত আছে, রেকর্ড হারালে বা বিকৃত হলে একটি রোগী-নিরাপত্তা ঝুঁকি আছে, এবং পুরোনো সিস্টেম বন্ধ হলে একটি চুক্তিগত খাড়া ধার আছে। সরকারি অর্থ একটি ব্যবসায়িক কেসের বিপরীতে প্রতিশ্রুত, এবং সংসদ, নিরীক্ষক ও বোর্ড জিজ্ঞাসা করবে তা অনুমোদিত মতো ব্যয় হয়েছে কি না। প্রকল্প-চালিত কাজ সেই গভর্ন্যান্স জোগায়, একটি ব্যবসায়িক কেস, স্টেজ গেট এবং একটি নিয়ন্ত্রিত সমাপ্তি, যা একটি বোর্ডকে আত্মবিশ্বাসে মূলধন প্রতিশ্রুত করতে এবং যুক্তি ফুরালে কাজ পরিচ্ছন্নভাবে থামাতে দেয়।

বিপদ হলো ভুল কাজের জন্য এই সরঞ্জাম ব্যবহার। একটি বিবর্তনশীল ডিজিটাল সেবায় প্রয়োগ করা প্রকল্প-চালিত গভর্ন্যান্স বিষয় 5.0 — পণ্য-চালিত কাজে বর্ণিত "গড়ে-ছেড়ে-দাও" ব্যাধি তৈরি করে। এই বিষয় ব্যাখ্যা করে প্রকল্প-চালিত কাজ কোথায় সঠিক যন্ত্র এবং কোথায় এর সীমা শুরু। এটি বিষয় 5.2 — কর্মসূচি-চালিত কাজের পাশে বসে, যা একাধিক প্রকল্প সমন্বয় করে, এবং বিষয় 5.3 — এন্টারপ্রাইজ পোর্টফোলিও ও প্রকল্প ব্যবস্থাপনা (EPPM), যা এই সরঞ্জামগুলোর মধ্যে বাছাই করে।

মূল ধারণা#

প্রকল্প। সময়, খরচ ও মানের সীমাবদ্ধতার মধ্যে একটি সম্মত বিনির্দেশ অনুযায়ী এক বা একাধিক সংজ্ঞায়িত আউটপুট সরবরাহ করতে তৈরি একটি অস্থায়ী সংগঠন। সংজ্ঞায়ক বৈশিষ্ট্য হলো এটি অস্থায়ী, এটি একটি সংজ্ঞায়িত শেষে পৌঁছাতে এবং তারপর ভেঙে যেতে অস্তিত্বশীল।

লৌহ ত্রিভুজ (পরিধি, সময়, খরচ)। ক্লাসিক সীমাবদ্ধতা মডেল: পরিধি, সময়সূচি ও বাজেট পরস্পর নির্ভরশীল, এবং মান নির্ভর করে সেগুলোর ভারসাম্যের ওপর। একটি বদলালে অন্যগুলো বদলায়; প্রকল্প নিয়ন্ত্রণ মূলত এই বিনিময় স্বচ্ছভাবে পরিচালনার শৃঙ্খলা।

PRINCE2 (PRojects IN Controlled Environments)। যুক্তরাজ্য সরকারের কাঠামোবদ্ধ প্রকল্প পদ্ধতি, NHS ও সরকারি খাত জুড়ে ব্যাপকভাবে ব্যবহৃত। এটি নীতির ওপর গড়া (অবিরাম ব্যবসায়িক ন্যায্যতা, সংজ্ঞায়িত ভূমিকা, ধাপে ধাপে পরিচালনা, ব্যতিক্রম দ্বারা পরিচালনা, পণ্যে মনোযোগ, অভিজ্ঞতা থেকে শেখা, পরিবেশ অনুযায়ী মানানসই) এবং কাজকে নিয়ন্ত্রিত ধাপে সংগঠিত করে যেখানে একটি প্রকল্প বোর্ড দিকনির্দেশ দেয়।

PMI / PMBOK। Project Management Institute-এর Guide to the Project Management Body of Knowledge প্রভাবশালী আন্তর্জাতিক সমতুল্য, একটি নির্ধারিত ধাপবদ্ধ প্রক্রিয়ার বদলে কর্মক্ষমতা ডোমেইন ও নীতির চারপাশে প্রকল্প কাজ সাজায়। PRINCE2 ও PMBOK একই শৃঙ্খলার পরিপূরক লেন্স।

ব্যবসায়িক কেস। যে নথি প্রকল্প ন্যায্য করে: সমস্যা, মূল্যায়িত বিকল্প, প্রত্যাশিত সুবিধা, খরচ ও ঝুঁকি। PRINCE2-এ ব্যবসায়িক কেস জীবন্ত, প্রতিটি ধাপ সীমানায় যাচাই করা হয়, এবং অবিরাম ন্যায্যতা মিলিয়ে গেলে সঠিক সিদ্ধান্ত হলো থামা। যুক্তরাজ্যের সরকারি সংস্থায় এটি সাধারণত HM Treasury-র Five Case Model (কৌশলগত, অর্থনৈতিক, বাণিজ্যিক, আর্থিক, ব্যবস্থাপনা) হিসেবে কাঠামোবদ্ধ।

স্টেজ গেট। একটি PRINCE2 প্রকল্প সিদ্ধান্ত গেটে বিচ্ছিন্ন ব্যবস্থাপনা ধাপে ভাগ করা। প্রতিটি সীমানায় প্রকল্প বোর্ড একটি সুচিন্তিত থামা/এগোনো সিদ্ধান্ত নেয়: অগ্রগতি ও ব্যবসায়িক কেস পর্যালোচনা করে, পরবর্তী ধাপের পরিকল্পনা অনুমোদন করে, এবং কেবল সেই ধাপের জন্য সম্পদ প্রতিশ্রুত করে। এভাবেই একটি বোর্ড নিয়ন্ত্রণ রাখে এবং খারাপ অর্থের পেছনে ভালো অর্থ ছোড়া এড়ায়।

RAID লগ। ঝুঁকি (Risks), অনুমান (Assumptions), সমস্যা (Issues) ও নির্ভরতা (Dependencies)-র একটি একক রেজিস্টার, প্রকল্প ব্যবস্থাপকের মূল নিয়ন্ত্রণ নিদর্শন। RAID অনিশ্চয়তা দৃশ্যমান ও পরিচালনাযোগ্য করে: ঝুঁকি যা ঘটতে পারে, সমস্যা যা ঘটেছে, অনুমান যার ওপর পরিকল্পনা নির্ভর করে, এবং নির্ভরতা যা পরিকল্পনা অন্যত্র থেকে চায়।

শ্রেষ্ঠ চর্চা#

1. একটি সৎ ব্যবসায়িক কেস দিয়ে শুরু করুন এবং তা জীবন্ত রাখুন। একটি একক পূর্বনির্ধারিত উত্তর নয়, প্রকৃত বিকল্প মূল্যায়নে একটি স্বীকৃত কাঠামো (যুক্তরাজ্যের সরকারি সংস্থায় Five Case Model) ব্যবহার করুন। তারপর ব্যবসায়িক কেসকে প্রতিটি স্টেজ গেটে পর্যালোচিত একটি জীবন্ত নথি হিসেবে দেখুন, অবিরাম ব্যবসায়িক ন্যায্যতা প্রথম PRINCE2 নীতি, এবং এটি হারানো থামার একটি বৈধ কারণ।

2. পরিধি নির্ভুলভাবে সংজ্ঞায়িত করুন এবং এর পরিবর্তন নিয়ন্ত্রণ করুন। একটি প্রকল্পের মূল্য হলো "সম্পন্ন"-র একটি স্পষ্ট, সীমাবদ্ধ সংজ্ঞা। পরিধি সম্মত হন, বেসলাইন করুন, এবং প্রতিটি প্রস্তাবিত পরিবর্তন একটি পরিবর্তন-নিয়ন্ত্রণ প্রক্রিয়ার মধ্য দিয়ে চালান যাতে পরিধি ক্রীপ নীরবে বাজেট ও সময়রেখা খেয়ে না ফেলে।

3. প্রকৃত সিদ্ধান্ত গেটসহ ধাপে ধাপে পরিচালনা করুন। কাজকে ব্যবস্থাপনা ধাপে ভাঙুন এবং প্রতিটি সীমানায় একটি প্রকৃত থামা/এগোনো পর্যালোচনা রাখুন। যে গেট সবসময় "এগোন" বলে তা নাট্য; শৃঙ্খলা কেবল তখনই কাজ করে যখন থামা বা পুনঃপরিকল্পনা একটি প্রকৃত বিকল্প যা বোর্ড প্রয়োগ করবে।

4. একটি লাইভ RAID লগ চালান এবং ব্যতিক্রম দ্বারা ঊর্ধ্বতনে পাঠান। ঝুঁকি, অনুমান, সমস্যা ও নির্ভরতা এক জায়গায় রাখুন, নিয়মিত পর্যালোচনা করুন, এবং PRINCE2-এর "ব্যতিক্রম দ্বারা পরিচালনা" ব্যবহার করুন: প্রকল্প ব্যবস্থাপক সম্মত সহনশীলতার মধ্যে চালান এবং কেবল একটি সহনশীলতা হুমকিতে পড়লে বোর্ডে ঊর্ধ্বতনে পাঠান। এটি জ্যেষ্ঠ সময়কে প্রকৃত সিদ্ধান্তে কেন্দ্রীভূত রাখে।

5. স্পষ্ট, একক-বিন্দু জবাবদিহিতা দিন। PRINCE2 সংজ্ঞায়িত ভূমিকার ওপর জোর দেয়: ব্যবসায়িক কেসের মালিক একজন জ্যেষ্ঠ দায়িত্বপ্রাপ্ত মালিক/নির্বাহীসহ একটি প্রকল্প বোর্ড, আউটপুট যাঁরা ব্যবহার করবেন তাঁদের প্রতিনিধিত্বকারী একজন জ্যেষ্ঠ ব্যবহারকারী, এবং একজন জ্যেষ্ঠ সরবরাহকারী। অস্পষ্ট জবাবদিহিতা সরণের সবচেয়ে সাধারণ কারণ।

6. শুরুর আগেই লাইভ সেবায় রূপান্তরের পরিকল্পনা করুন। একটি প্রকল্প একটি আউটপুট সরবরাহ করে; পরে কাউকে তা পরিচালনা করতে হবে। প্রকল্পের অংশ হিসেবে গ্রহণকারী দল, সহায়তা মডেল এবং ক্লিনিক্যাল-নিরাপত্তা হস্তান্তর (মোতায়েনের জন্য DCB0160) সম্মত হন, যাতে গো-লাইভ একটি মালিকানা শূন্যতায় খাড়া ধার না হয়।

7. ক্লিনিক্যাল নিরাপত্তা, তথ্য গভর্ন্যান্স ও পরীক্ষা গেঁথে নিন। রোগীর ডেটা স্পর্শকারী যেকোনো সিস্টেমের জন্য, ক্লিনিক্যাল নিরাপত্তা কেস, DPIA এবং কাটওভার/রোলব্যাক পরীক্ষা ঐচ্ছিক অতিরিক্ত নয়, তারা গেট-করা সরবরাহযোগ্য। একটি পরীক্ষিত রোলব্যাক পরিকল্পনা ছাড়া স্থানান্তর গো-লাইভের জন্য প্রস্তুত নয়।

8. প্রকল্প সুচিন্তিতভাবে বন্ধ করুন এবং শিক্ষা ধরুন। একটি সংজ্ঞায়িত শেষের অর্থ একটি সংজ্ঞায়িত সমাপ্তি: আউটপুট গৃহীত নিশ্চিত করুন, পরিচালনায় হস্তান্তর করুন, দল মুক্ত করুন, এবং শিক্ষা রেকর্ড করুন (PRINCE2-এর শিক্ষা লগ)। একটি অ-বন্ধ প্রকল্প অনির্দিষ্টকাল সম্পদ ও জবাবদিহিতা ক্ষরণ করে।

দলের সঙ্গে আলোচনার প্রশ্ন#

1. আমাদের সামনের কাজটি কি সত্যিই একটি সংজ্ঞায়িত শেষ অবস্থাসহ সসীম, নাকি আমরা প্রকল্প গভর্ন্যান্সের দিকে হাত বাড়াচ্ছি কারণ এটি আমাদের চেনা অর্থায়ন পথ? এটি সেই নির্ণায়ক প্রশ্ন যার ওপর বিষয়টি ঘোরে, কারণ প্রকল্প-চালিত শৃঙ্খলা সঠিক যন্ত্র কেবল তখনই যখন কাজটির সত্যিই একটি শুরু, একটি মধ্যভাগ ও একটি নির্দিষ্ট শেষ আছে। একটি স্বাস্থ্য ও পরিচর্যা প্রতিষ্ঠানে প্রকল্প আকারের দিকে টান প্রবল, মূলধন বাজেটিং, ব্যবসায়িক-কেস যন্ত্রব্যবস্থা ও বোর্ড প্রতিবেদন সবই এর জন্য গড়া, তাই একটি বিবর্তনশীল ডিজিটাল সেবাকে কেবল অর্থ মুক্ত করার উপায় বলে একটি প্রকল্প সাজানো যেতে পারে, যা তারপর গড়ে-ছেড়ে-দাও ব্যাধি তৈরি করে। বিতর্ক প্রতিটি প্রার্থী সৎভাবে পরীক্ষা করবে: একজন সরবরাহকারী সমর্থন প্রত্যাহারের আগে একটি প্যাথলজি সিস্টেম প্রতিস্থাপনের একটি কঠিন চুক্তিগত খাড়া ধার আছে এবং তা নিঃসন্দেহে সসীম, অথচ "রোগী অ্যাপ উন্নত করুন"-র কোনো শেষ অবস্থা নেই এবং এটি বিষয় 5.0-এর। বিবেচনা করুন একটি প্রকৃত গো-লাইভ আছে কি যার পরে দলের ভেঙে যাওয়া উচিত, নাকি কাউকে অনির্দিষ্টকাল জিনিসটি উন্নত করতে হবে। একটি ভালো উত্তর প্রকল্প গভর্ন্যান্সকে অভ্যাস হিসেবে ব্যবহার প্রতিরোধ করে, মূর্ত শেষ অবস্থা ও "সম্পন্ন" সংজ্ঞায়িত করা ঘটনার নাম বলে, এবং বলতে ইচ্ছুক যে আমরা বর্তমানে যা প্রকল্প হিসেবে চালাই তার কিছু কখনো প্রকল্প হওয়া উচিত ছিল না।

2. আমাদের স্টেজ গেটে, এই বোর্ড কি সত্যিই এমন একটি প্রকল্প থামাত বা পুনঃপরিকল্পনা করত যা তার ন্যায্যতা হারিয়েছে, এবং আমরা কি এমন একবারের কথা নির্দেশ করতে পারি যখন করেছি? স্টেজ গেট কেবল তখনই নিয়ন্ত্রণ যখন থামা একটি প্রকৃত বিকল্প যা বোর্ড প্রয়োগ করবে; যে গেট সবসময় "এগোন" বলে তা নাট্য, এবং অবিরাম ব্যবসায়িক ন্যায্যতা প্রথম PRINCE2 নীতি ঠিক কারণেই যে এটি হারানো কাজ শেষ করা উচিত। স্বাস্থ্য ও পরিচর্যায় টানাপোড়েন তীব্র: একটি অর্ধ-গড়া EPR স্থানান্তর বা একটি পরীক্ষাগার-সিস্টেম কাটওভার থামানো ব্যর্থতা স্বীকার, নিমজ্জিত খরচ নষ্ট করা এবং ইতোমধ্যে নিজেদের পরিকল্পনা বদলানো চিকিৎসকদের ব্যাহত করার মতো মনে হয়, তাই ব্যবসায়িক কেস নীরবে বাষ্প হয়ে গেলেও বোর্ড এগিয়ে যাওয়ার যুক্তি দেখায়। আলোচনায় একটি প্রকৃত উদাহরণ আনুন, এমন একটি প্রকল্প যেখানে পরীক্ষা প্রকাশ করেছিল ডেটা-ম্যাপিং ঝুঁকি ধরার চেয়ে খারাপ, বা যেখানে সুবিধা পিছলে গিয়েছিল, এবং জিজ্ঞাসা করুন গেট নকশা অনুযায়ী ব্যবহৃত হয়েছিল নাকি রাবার-স্ট্যাম্প করা। বিবেচনা করুন কোন সহনশীলতা ঊর্ধ্বতন-প্রেরণ ট্রিগার করে, বোর্ডে কার থামার ডাক দেওয়ার মর্যাদা আছে, এবং নিমজ্জিত-খরচ যুক্তি ঘরে নাম দেওয়া ও চ্যালেঞ্জ করা হয় কি না। একটি সৎ উত্তর স্বীকার করে গেট কোথায় আনুষ্ঠানিকতা ছিল, যে শর্তে বোর্ড সত্যিই থামাত বা পরিধি বদলাত তা বর্ণনা করে, এবং জনসমক্ষে অবলোপনের আগে থামার কর্তৃত্বকে হুমকির বদলে শৃঙ্খলার প্রকৃত মূল্য হিসেবে দেখে।

3. প্রতিটি প্রকল্পের আউটপুট একটি লাইভ সেবা হিসেবে কে গ্রহণ করে, এবং আমরা কীভাবে ক্লিনিক্যাল-নিরাপত্তা হস্তান্তর ও চলমান মালিকানাকে একটি খাড়া ধারের বদলে গেট-করা সরবরাহযোগ্য করি? একটি প্রকল্প একটি আউটপুট সরবরাহ করে; সসীম কিছু শেষ হয়, কিন্তু যা এটি তৈরি করেছে তা দল ভেঙে যাওয়ার অনেক পরেও পরিচালিত, উন্নত ও নিরাপদ রাখতে হবে, এবং সবচেয়ে সাধারণ নীরব ব্যর্থতা হলো ওপারে কেউ এর মালিক নয়। রোগীর ডেটা স্পর্শকারী সিস্টেমে এটি প্রশাসনিক পরিচ্ছন্নতা নয়: DCB0160 মোতায়েন নিরাপত্তা কেস, DPIA, একটি পরীক্ষিত রোলব্যাক এবং একটি নামধারী গ্রহণকারী দলই একটি নিয়ন্ত্রিত গো-লাইভ ও একটি মালিকানা শূন্যতার মধ্যে দাঁড়ায় যেখানে নিরাপত্তা ঝুঁকি অব্যবস্থাপিত জমে। বিতর্ক গো-লাইভ সপ্তাহান্তে নয়, প্রকল্প শুরুর আগে স্থানান্তর সম্পর্কে স্পষ্টতা বাধ্য করবে: কোন পরিচালনগত দল এটি নেয়, সহায়তা মডেল কী, এবং সেই দলের এটি উন্নত করতে থাকার সামর্থ্য ও কাজের ধরন (বিষয় 5.0 অনুযায়ী পণ্য-চালিত) আছে কি না। মূর্ত সাম্প্রতিক গো-লাইভ এবং হস্তান্তর পরিকল্পিত ছিল নাকি উদ্ভাবিত, এবং "প্রকল্প সম্পন্ন"-কে "এবং এখন এটি কারও কাজ নয়" বোঝাতে দেওয়া হয়েছিল কি না বিবেচনা করুন। একটি ভালো উত্তর শুরুতেই গ্রহণকারী দল ও সহায়তা মডেলের নাম বলে, নিরাপত্তা হস্তান্তরকে এমন একটি গেট হিসেবে দেখে যা ছাড়া প্রকল্প পাস করতে পারে না, এবং লাইভ সেবার চলমান উন্নতি সরণে ছেড়ে দেওয়ার বদলে স্পষ্টভাবে সঠিক কাজের ধরনে অর্পণ করে।

4. যখন লৌহ ত্রিভুজ কামড়ায় এবং পরিধি, সময় ও খরচ সংঘর্ষ করে, আমরা কোন সীমাবদ্ধতা নমনীয় করি, এবং রোগী নিরাপত্তা কি কখনো সেই চলক হতে পারে যা ছাড় দেয়? প্রতিটি প্রকৃত প্রকল্প শেষ পর্যন্ত সেই মুহূর্তের মুখোমুখি হয় যখন সময়সূচি, বাজেট ও প্রতিশ্রুত পরিধি সবকিছু ধরে রাখা যায় না, এবং দল সেই চাপ কীভাবে মীমাংসা করে তা প্রকাশ করে এটি আসলে কী মূল্য দেয়। স্বাস্থ্য ও পরিচর্যায় ফাঁদ স্বতন্ত্র: কারণ শেষ তারিখ প্রায়ই একটি কঠিন চুক্তিগত খাড়া ধার, একজন সরবরাহকারী সমর্থন প্রত্যাহার, একটি ইজারা শেষ, একটি ডেটা-সেন্টার বন্ধ, সময় প্রায়ই নড়তে পারে না, তাই চাপ নীরবে মানের ওপর পড়ে, যার ক্লিনিক্যাল সিস্টেমে অর্থ পরীক্ষা কাটা, যাচাইকরণ সংকুচিত করা, বা জানা ডেটা-ম্যাপিং ত্রুটিসহ পাঠানো। আলোচনা আগেই নাম বলবে প্রতিষ্ঠান ত্রিভুজের কোন কোণ রক্ষা করবে ও কোনটি উৎসর্গ করবে, এবং স্পষ্ট করবে যে বাকি সবকিছু স্থির থাকলেও ক্লিনিক্যাল নিরাপত্তা ও তথ্য গভর্ন্যান্স মুক্তির ভাল্ব নয়। একটি সাম্প্রতিক কাটওভার দেখুন এবং জিজ্ঞাসা করুন তারিখ ধরা থাকলে নীরবে কী ছাড় দিয়েছিল: রোলব্যাক মহড়া, ক্লিনিক্যাল-যাচাইকরণ জানালা, প্রশিক্ষণ? বিবেচনা করুন নিরাপত্তা মার্জিন ক্ষয় করার বদলে গো-লাইভ তারিখ সরানোর কর্তৃত্ব কার আছে, এবং সেই কথোপকথন বোর্ডে খোলাখুলি ঘটে নাকি মাঠে ডিফল্টে। একটি সৎ উত্তর সংকটের আগে অগ্রাধিকার ক্রম বলে, একটি পিছলে-যাওয়া তারিখ বা একটি পুনঃপরিকল্পিত ধাপকে বৈধ ফলাফল হিসেবে দেখে, এবং অনুক্ত সময়সূচি চাপকে অলগ-করা ক্লিনিক্যাল ঝুঁকিতে রূপান্তরিত হতে দিতে অস্বীকার করে।

5. আমাদের RAID লগ কি আমরা যা করি তা বদলে দেওয়া একটি লাইভ যন্ত্র, নাকি শাসিত দেখাতে রক্ষণাবেক্ষণ করা একটি নথি, এবং এটি কি সেই ঝুঁকি সামনে আনত যা আসলে প্রকল্প ডোবায়? একটি RAID লগ তার জায়গা অর্জন করে কেবল যদি এটি পর্যালোচনা সিদ্ধান্ত বদলায়; সাধারণ ব্যাধি হলো একটি রেজিস্টার কিক-অফে লেখা, বোর্ডে উপস্থাপিত এবং কখনো প্রকৃতপক্ষে ব্যবস্থা-না-নেওয়া যখন গুরুত্বপূর্ণ ঝুঁকি অদেখা পরিপক্ব হয়। একটি স্থানান্তর বা কাটওভারে নির্ণায়ক ঝুঁকি প্রায়ই নির্দিষ্ট ও জানার যোগ্য, ঐতিহাসিক ফলাফল যা নতুন রেফারেন্স পরিসীমায় পরিষ্কারভাবে ম্যাপ হবে না, অন্য দলের ফায়ারওয়াল পরিবর্তনের ওপর একটি নির্ভরতা, একটি অনুমান যে ক্লিনিক্যাল যাচাইকরণ সম্পদ দরকারের সময় বিনামূল্যে থাকবে, এবং প্রশ্ন হলো লগ সেগুলো মূর্তভাবে নাম বলে নাকি "সম্পদ সীমাবদ্ধতা"-র মতো সাধারণ এন্ট্রির পেছনে লুকায়। বিতর্ক পরীক্ষা করবে ব্যতিক্রম দ্বারা ঊর্ধ্বতন-প্রেরণ প্রকৃত কি না: প্রকল্প ব্যবস্থাপক সম্মত সহনশীলতার মধ্যে চালান এবং কেবল একটি হুমকিতে পড়লে বোর্ডের মনোযোগ ডাকেন, নাকি সবকিছু হয় নীরব থাকে বা সংকট হয়? বিবেচনা করুন কাছাকাছি-ভুল ও বাস্তবায়িত সমস্যা পরবর্তী ধাপ কীভাবে পরিকল্পিত হয় তাতে ফিরে খায়, নাকি কেবল লগ হয়ে ভুলে যায়। একটি ভালো উত্তর এমন একটি সিদ্ধান্তের দিকে নির্দেশ করতে পারে যা RAID লগ আসলে বদলেছে, দীর্ঘ লেজের ছোটগুলো থেকে সত্যিই প্রকল্প থামাতে পারে এমন দুটি বা তিনটি ঝুঁকি আলাদা করে, এবং লগকে আশ্বাসের জন্য তৈরি নিদর্শনের বদলে একটি কর্মরত নিয়ন্ত্রণ হিসেবে দেখে।

6. আমরা বন্ধ করে ভেঙে দেওয়ার পরে, ব্যবসায়িক কেসের সুবিধা আসলে অর্জিত হয়েছে কি না কেউ কি যাচাই করে, এবং না হলে আমরা কি জানতাম? ব্যবসায়িক কেস ব্যয় ন্যায্য করতে সুবিধার প্রতিশ্রুতি দেয়, কিন্তু প্রকল্প-চালিত কাজ স্বাভাবিকভাবে গো-লাইভ ও দল মুক্তিতে শেষ হয়, তাই সত্যের মুহূর্ত, স্থানান্তর আসলে ঝুঁকি কমিয়েছে, খরচ কেটেছে বা পরিচর্যা উন্নত করেছে কি না, সাধারণত সবাই এগিয়ে যাওয়ার পরে পড়ে এবং নিশ্চিত করার জন্য কেউ জবাবদিহিকারী নয়। এটি জনস্বাস্থ্য ও পরিচর্যায় তীব্রভাবে গুরুত্বপূর্ণ, যেখানে অর্থ একটি Five Case ব্যবসায়িক কেসের বিপরীতে প্রতিশ্রুত যা সংসদ, নিরীক্ষক ও বোর্ডকে বলা হয়েছিল নির্দিষ্ট ফলাফল দেবে, তবু সুবিধা অর্জন সেই ধাপ যা সবচেয়ে প্রায়ই এড়ানো হয় কারণ যে প্রকল্প এর মালিক হতো তা আর নেই। আলোচনা ঠিক করবে প্রকল্প বন্ধ হলে সুবিধা ট্র্যাকিং কে উত্তরাধিকারসূত্রে পায়, কত সময়ের জন্য, এবং কোন বেসলাইন পরিমাপের বিপরীতে, যা গো-লাইভের আগে ধরতে হবে নয়তো হারাবে। একটি সাম্প্রতিক সম্পূর্ণ প্রকল্প বিবেচনা করুন এবং সরলভাবে জিজ্ঞাসা করুন তারপর থেকে কেউ এর প্রতিশ্রুত সুবিধা যাচাই করেছে কি না, এবং একটি ঘাটতি কখনো এটি অনুমোদনকারী বোর্ডে পৌঁছাত কি না। একটি সৎ উত্তর সমাপ্তি-পরবর্তী সুবিধা মালিকানা ভেঙে-যাওয়া দলের বদলে একটি স্থায়ী ফাংশনকে দেয়, প্রকল্প এখনো লাইভ থাকতে বেসলাইন ধরে, এবং রেকর্ড করতে ইচ্ছুক যে একটি প্রকল্প সময়মতো ও বাজেটে তার আউটপুট দিয়েছে অথচ যে মূল্য একে ন্যায্য করেছিল তা দেয়নি।

বাস্তবে: স্বাস্থ্য ও পরিচর্যার একটি উদাহরণ#

একটি অ্যাকিউট ট্রাস্টকে বর্তমান সরবরাহকারী সমর্থন প্রত্যাহারের ১৪ মাসের মধ্যে তার বার্ধক্যগ্রস্ত প্যাথলজি পরীক্ষাগার তথ্য ব্যবস্থাপনা সিস্টেম প্রতিস্থাপন করতে হবে। এটি পাঠ্যবইয়ের প্রকল্প-চালিত কাজ: নির্দিষ্ট শেষ তারিখ, সংজ্ঞায়িত পরিধি, একটি কঠিন চুক্তিগত খাড়া ধার, এবং স্থানান্তরে ফলাফল হারালে তীব্র রোগী-নিরাপত্তা ঝুঁকি।

ট্রাস্ট তিনটি বিকল্প (জায়গায় আপগ্রেড, একটি নতুন সিস্টেম ক্রয়, একটি আঞ্চলিক ইনস্ট্যান্স ভাগ) মূল্যায়ন করে একটি Five Case ব্যবসায়িক কেস লেখে, ক্রয় বেছে নেয়, এবং একটি স্পষ্ট বোর্ডসহ একটি PRINCE2 প্রকল্প দাঁড় করায়: ব্যবসায়িক কেসের মালিক একজন নির্বাহী, একজন জ্যেষ্ঠ ব্যবহারকারী (প্রধান বায়োমেডিক্যাল বিজ্ঞানী), এবং জ্যেষ্ঠ সরবরাহকারী। কাজ ব্যবস্থাপনা ধাপে ভাগ করা হয়, ক্রয়, নির্মাণ ও কনফিগারেশন, ডেটা স্থানান্তর, পরীক্ষা ও গো-লাইভ, প্রতিটি একটি সিদ্ধান্ত গেটে শেষ।

প্রকল্প ব্যবস্থাপক একটি RAID লগ চালান। একটি মূল ঝুঁকি হলো ঐতিহাসিক ফলাফল নতুন সিস্টেমের রেফারেন্স পরিসীমায় পরিষ্কারভাবে ম্যাপ নাও হতে পারে; একটি নির্ভরতা নেটওয়ার্ক দলের ফায়ারওয়াল পরিবর্তন; একটি অনুমান হলো পরীক্ষার জন্য ক্লিনিক্যাল যাচাইকরণ সম্পদ পাওয়া যাবে। স্থানান্তর স্টেজ গেটে, পরীক্ষা প্রকাশ করে ডেটা-ম্যাপিং ঝুঁকি ধরার চেয়ে খারাপ, তাই বোর্ড গেটটি নকশা অনুযায়ী ব্যবহার করে: এটি অন্ধভাবে এগোয় না, বরং একটি বর্ধিত যাচাইকরণ জানালা ও একটি পরীক্ষিত রোলব্যাক পরিকল্পনাসহ একটি পুনঃপরিকল্পিত ধাপ অনুমোদন করে, মূল সময়সূচির ওপরে রোগী নিরাপত্তা রক্ষা করে।

গো-লাইভ ঘটে একটি নিয়ন্ত্রিত সপ্তাহান্তে, রোলব্যাক পরিকল্পনা স্ট্যান্ডবাইতে এবং একটি DCB0160 ক্লিনিক্যাল-নিরাপত্তা অনুমোদনসহ। সিস্টেমটি গৃহীত হয়, যে পরিচালনা দল এটি চালাবে তাদের হস্তান্তর করা হয়, শিক্ষা লগ করা হয়, এবং প্রকল্প আনুষ্ঠানিকভাবে বন্ধ হয়। দল ভেঙে যায়, ঠিকভাবেই, কারণ কাজ সত্যিই সম্পন্ন। যা আসে (লাইভ সেবার অবিরাম উন্নতি) তা কাজের একটি ভিন্ন ধরন, এবং ট্রাস্ট সতর্ক যে এটি করতে একটি পূর্ণ প্রকল্প দলকে চিরকাল চালু রাখবে না।

খাতভিত্তিক দৃষ্টিকোণ#

স্টার্ট-আপ#

একটি ছোট ডিজিটাল-স্বাস্থ্য কোম্পানি কদাচিৎ আনুষ্ঠানিক PRINCE2 প্রকল্প চালায়, কিন্তু সত্যিকারের সসীম কাজ তবু দেখা দেয়, একটি নতুন ক্লাউড প্ল্যাটফর্মে একবারের ডেটা স্থানান্তর, একটি Cyber Essentials বা DTAC সনদের ঠেলা, একটি বড় NHS চুক্তির আগে পেন-টেস্ট প্রতিকার। স্টার্ট-আপ এগুলো একজন নামধারী মালিক ও "সম্পন্ন"-র স্পষ্ট সংজ্ঞাসহ হালকা, সময়-সীমিত প্রচেষ্টা হিসেবে সামলায়, আনুষ্ঠানিকতা ছাড়াই শৃঙ্খলা (স্থির পরিধি, একটি শেষ তারিখ, একটি যাও/না-যাও) ধার করে, কোনো আনুষ্ঠানিক প্রকল্প বোর্ড নেই, পাঁচ-ধাপ গেটিং নেই। অর্থায়ন আসলে প্রতিষ্ঠাতার মনোযোগ ও রানওয়ে, তাই ঝুঁকি হলো সসীম কাজ পণ্য স্প্রিন্টের মাঝে চাপা পড়ে এবং কখনো প্রকৃতপক্ষে বন্ধ হয় না। প্রতিকার একজন একক মালিক ও একটি কঠিন সময়সীমার নাম দেওয়া, এবং সনদ বা স্থানান্তরকে চিরকাল "চলমান" না রেখে সম্পন্ন-ও-চূড়ান্ত হিসেবে দেখা।

ক্ষুদ্র ব্যবসা#

একটি প্রতিষ্ঠিত ছোট প্রদানকারী, একটি জিপি প্র্যাকটিস, কমিউনিটি ফার্মেসি, কেয়ার হোম বা একক-স্থানের ক্লিনিক, প্রকল্প-চালিত কাজের মুখোমুখি হয় মাঝে মাঝের কিন্তু অনিবার্য ঘটনা হিসেবে: ক্লিনিক্যাল সিস্টেম সরবরাহকারী বদলানো, একটি নতুন প্র্যাকটিস-ব্যবস্থাপনা প্ল্যাটফর্মে স্থানান্তর, বা সমর্থন শেষ হওয়ার আগে জীবন-শেষ ডিভাইস প্রতিস্থাপন। প্রতিষ্ঠানের প্রকৃত রোগী ও চলমান পরিচালনা আছে কিন্তু কোনো নিবেদিত প্রকল্প বা IT ফাংশন নেই, তাই "প্রকল্প দল" সাধারণত প্র্যাকটিস ম্যানেজার বা একজন রেজিস্টার্ড ম্যানেজার যিনি এটি দৈনন্দিন কাজের পাশে করেন, প্রায়ই স্থানান্তর চালাতে আগত সরবরাহকারীর ওপর ভর করে। এই বাস্তবতার সংস্পর্শে টিকে থাকা শৃঙ্খলা হলো হালকা মূল: একটি স্পষ্ট শেষ অবস্থা, একটি বেসলাইন-করা পরিধি যাতে সরবরাহকারী নীরবে তা না বাড়ায়, একজন নামধারী জবাবদিহিকারী ব্যক্তি, এবং রোগীর রেকর্ড স্পর্শকারী যেকোনো কাটওভারের আগে একটি পরীক্ষিত রোলব্যাক। ফাঁদ হলো কেবল কাজ নয়, বিচারও আউটসোর্স করা, স্বাধীন যাচাই ছাড়া সরবরাহকারীর গো-লাইভ তারিখ ও ডেটা-ম্যাপিং আশ্বাস মেনে নেওয়া, কারণ একই ক্লিনিক্যাল-নিরাপত্তা ও তথ্য-গভর্ন্যান্স দায়িত্ব (DCB0160, একটি DPIA) প্রতিষ্ঠান যত ছোটই হোক প্রযোজ্য। প্রতিকার হলো যাও/না-যাও সিদ্ধান্ত ও গ্রহণযোগ্যতা মানদণ্ডের মালিকানা ঘরোয়া রাখা, এমনকি অন্য প্রতিটি জোড়া হাত বিক্রেতার হলেও।

বৃহৎ প্রতিষ্ঠান#

একটি বড় NHS ট্রাস্ট বা ইন্টিগ্রেটেড কেয়ার সিস্টেম (ICS) সেই জায়গা যেখানে প্রকল্প-চালিত কাজ সবচেয়ে স্বচ্ছন্দ: EPR প্রতিস্থাপন, এস্টেট-জুড়ে Wi-Fi, ডেটা-সেন্টার প্রস্থান ও কাটওভার সবই কঠিন চুক্তিগত ও রোগী-নিরাপত্তা খাড়া ধার বহন করে। এখানে পূর্ণ যন্ত্রব্যবস্থা ন্যায্য, একটি Five Case ব্যবসায়িক কেস, একজন নামধারী নির্বাহী/SRO, জ্যেষ্ঠ ব্যবহারকারী ও জ্যেষ্ঠ সরবরাহকারীসহ একটি PRINCE2 বোর্ড, প্রকৃত গেটসহ ব্যবস্থাপনা ধাপ, এবং একটি লাইভ RAID লগ, কারণ অঙ্ক বড়, নিরাপত্তা ঝুঁকি তীব্র, এবং অভ্যন্তরীণ নিরীক্ষা ও বোর্ড ব্যয় যাচাই করবে। এই মাপে বৈশিষ্ট্যসূচক ব্যর্থতা হলো একই গভর্ন্যান্স জীবন্ত সেবা (বিষয় 5.0 — পণ্য-চালিত কাজ) ও সসীম কাজ উভয়ে নির্বিচারে প্রয়োগ, তাই একটি পোর্টফোলিও দৃষ্টিভঙ্গি (বিষয় 5.3 — এন্টারপ্রাইজ পোর্টফোলিও ও প্রকল্প ব্যবস্থাপনা) যা প্রতিটি কাজকে সঠিক ধরনে পাঠায় তা গুরুত্বপূর্ণ। ক্লিনিক্যাল নিরাপত্তা (DCB0160) ও একটি পরীক্ষিত রোলব্যাক গেট-করা সরবরাহযোগ্য, ঐচ্ছিক অতিরিক্ত নয়।

সরকার#

জাতীয় বা প্রধান-প্রকল্প স্কেলে, প্রকল্প-চালিত কাজ সরকারের আশ্বাস ব্যবস্থার ভেতরে বসে: Infrastructure and Projects Authority গেটওয়ে পর্যালোচনা চালায়, HM Treasury-র Green Book ও Five Case Model ব্যবসায়িক কেস শাসন করে, এবং সবচেয়ে বড় প্রকল্প সংসদ ও National Audit Office-এর কাছে প্রকাশিত জবাবদিহিতাসহ Government Major Projects Portfolio-তে প্রবেশ করে। জবাবদিহিতা তীব্রভাবে জনসমক্ষে, জ্যেষ্ঠ দায়িত্বপ্রাপ্ত মালিক ব্যক্তিগতভাবে জবাবদিহিকারী এবং একটি সিলেক্ট কমিটির সামনে ডাকা হতে পারে, তাই স্টেজ গেট ও বিকল্প মূল্যায়ন বিধিবদ্ধ-মানের নিয়ন্ত্রণ, নাট্য নয়। অনুমোদিত ব্যবসায়িক কেসের বিপরীতে কিস্তি-কিস্তি অর্থায়ন মুক্ত হয় এবং ঝুঁকি ক্ষুধা কম, কারণ ব্যর্থতা প্রথম পাতার খবর। এখানে শৃঙ্খলার প্রকৃত মূল্য হলো একটি ব্যর্থ প্রকল্প জন অবলোপনে পরিণত হওয়ার আগে থামানো বা পরিধি বদলানোর কর্তৃত্ব।

ব্যর্থতার সাধারণ ধরন#

• একটি বিবর্তনশীল সেবাকে প্রকল্প-পরিচালনা। একটি জীবন্ত ডিজিটাল পণ্যে স্থির-পরিধি, শেষে-ভেঙে-যাওয়া গভর্ন্যান্স প্রয়োগ পরিত্যাগের ব্যাধি তৈরি করে। সমাধান: যেখানে সেবা চলমান সেখানে পণ্য-চালিত কাজ (বিষয় 5.0) ব্যবহার করুন।
• অর্থায়নের একবারের টিকিট হিসেবে ব্যবসায়িক কেস। অর্থ খুলতে একবার লেখা, তারপর কখনো পুনর্বিবেচিত নয়। সমাধান: প্রতিটি স্টেজ গেটে পর্যালোচনা করুন; থামতে ইচ্ছুক থাকুন।
• রাবার-স্ট্যাম্প স্টেজ গেট। যে গেট কখনো "থামুন" বলে না তা কোনো নিয়ন্ত্রণ দেয় না। সমাধান: থামা বা পুনঃপরিকল্পনা একটি প্রকৃত বোর্ড বিকল্প করুন এবং তা ব্যবহার করুন।
• পরিবর্তন নিয়ন্ত্রণ ছাড়া পরিধি ক্রীপ। অনিয়ন্ত্রিত সংযোজন সময় ও খরচ ফাটায়। সমাধান: পরিধি বেসলাইন করুন এবং প্রতিটি পরিবর্তন পরিবর্তন নিয়ন্ত্রণের মধ্য দিয়ে পাঠান।
• সেবায় রূপান্তরের পরিকল্পনা নেই। প্রকল্প শেষ হয় এবং আউটপুটের মালিক কেউ নেই। সমাধান: গো-লাইভের আগে গ্রহণকারী দল ও সহায়তা মডেল সম্মত হন।
• ফাইলিং ক্যাবিনেট হিসেবে RAID। একটি লগ যা লেখা হয় এবং কখনো ব্যবস্থা নেওয়া হয় না। সমাধান: নিয়মিত RAID পর্যালোচনা করুন এবং ব্যতিক্রম দ্বারা ঊর্ধ্বতনে পাঠান।
• কখনো আসলে বন্ধ না করা। জম্বি প্রকল্প যা শেষ ছাড়া সম্পদ খরচ করে। সমাধান: গ্রহণযোগ্যতা, হস্তান্তর ও ধরা শিক্ষাসহ একটি সুচিন্তিত সমাপ্তি।

পরিপক্বতা মডেল#

চেকলিস্ট#

• কাজটি কি সত্যিই একটি সংজ্ঞায়িত পরিধি ও শেষ অবস্থাসহ সসীম (চলমান সেবা নয়)?
• প্রতিটি স্টেজ গেটে পর্যালোচিত একটি জীবন্ত ব্যবসায়িক কেস (Five Case Model) আছে কি?
• পরিধি কি বেসলাইন-করা, একটি কার্যকর পরিবর্তন-নিয়ন্ত্রণ প্রক্রিয়াসহ?
• কাজের ধাপ কি সংজ্ঞায়িত, প্রতিটি একটি প্রকৃত থামা/এগোনো সিদ্ধান্ত গেটে শেষ?
• প্রকল্প বোর্ড ভূমিকা কি স্পষ্ট, নির্বাহী/SRO, জ্যেষ্ঠ ব্যবহারকারী, জ্যেষ্ঠ সরবরাহকারী?
• ব্যতিক্রম দ্বারা ঊর্ধ্বতন-প্রেরণসহ একটি লাইভ RAID লগ রক্ষণাবেক্ষণ করা হয় কি?
• ক্লিনিক্যাল নিরাপত্তা (DCB0160), DPIA এবং কাটওভার/রোলব্যাক পরীক্ষা কি গেট-করা সরবরাহযোগ্য?
• গো-লাইভের আগে গ্রহণকারী পরিচালনা দল ও সহায়তা মডেল কি সম্মত?
• একটি সুচিন্তিত সমাপ্তি আছে কি: গ্রহণযোগ্যতা, হস্তান্তর, দল মুক্তি, শিক্ষা লগ করা?
• লাইভ সেবার চলমান উন্নতি কি সঠিক কাজের ধরনে অর্পিত হয়েছে?

মূল উৎস#

• AXELOS / PeopleCert — Managing Successful Projects with PRINCE2 (৭ম সংস্করণ) এবং PRINCE2 নীতি, থিম ও প্রক্রিয়া।
• Project Management Institute (PMI) — A Guide to the Project Management Body of Knowledge (PMBOK Guide) এবং The Standard for Project Management।
• HM Treasury — Guide to Developing the Project Business Case (Five Case Model / Green Book)।
• Infrastructure and Projects Authority (IPA), Cabinet Office — প্রধান প্রকল্পের জন্য আশ্বাস ও গেটওয়ে পর্যালোচনা নির্দেশিকা।
• NHS Digital Clinical Safety মান DCB0160 (স্বাস্থ্য IT সিস্টেমের মোতায়েন)।
• NHS England — NHS Service Manual এবং Digital Service Standard (সেবা-রূপান্তর ও ব্যবহারকারী-প্রয়োজন প্রেক্ষাপটের জন্য)।

তথ্যসূত্র#

1. Project management — Wikipedia — https://en.wikipedia.org/wiki/Project_management
2. PRINCE2 — Wikipedia — https://en.wikipedia.org/wiki/PRINCE2
3. Project management triangle (iron triangle) — Wikipedia — https://en.wikipedia.org/wiki/Project_management_triangle
4. Project Management Institute — Wikipedia — https://en.wikipedia.org/wiki/Project_Management_Institute
5. Project Management Body of Knowledge — Wikipedia — https://en.wikipedia.org/wiki/Project_Management_Body_of_Knowledge
6. Business case — Wikipedia — https://en.wikipedia.org/wiki/Business_case
7. Phase-gate process (stage gates) — Wikipedia — https://en.wikipedia.org/wiki/Phase-gate_process
8. Scope creep — Wikipedia — https://en.wikipedia.org/wiki/Scope_creep
9. Data migration — Wikipedia — https://en.wikipedia.org/wiki/Data_migration
10. Electronic health record — Wikipedia — https://en.wikipedia.org/wiki/Electronic_health_record
11. HM Treasury — Wikipedia — https://en.wikipedia.org/wiki/HM_Treasury
12. Managing Successful Projects with PRINCE2 (7th edition) — AXELOS / PeopleCert — https://www.peoplecert.org/browse-certifications/project-programme-and-portfolio-management/PRINCE-2-1005
13. A Guide to the Project Management Body of Knowledge (PMBOK Guide) — Project Management Institute — https://www.pmi.org/
14. The Green Book and Guide to Developing the Project Business Case (Five Case Model) — HM Treasury — https://www.gov.uk/government/publications/the-green-book-appraisal-and-evaluation-in-central-governent
15. Assurance and gateway review guidance for major projects — Infrastructure and Projects Authority, Cabinet Office — https://www.gov.uk/government/organisations/infrastructure-and-projects-authority
16. Clinical risk management standard DCB0160 — NHS England — https://digital.nhs.uk/services/clinical-safety