ITTO শৃঙ্খল — একটি বাস্তব প্রজেক্টের মধ্য দিয়ে একটি সুতো
অ্যাপে: Project → follow the thread: Charter → WBS → Registers → Gantt → Variance
Reference. ITTO ব্যাখ্যা-র সহযোগী। সেখানে আপনি শেখেন একটি ITTO কী আর সব 40 process ঘুরে দেখেন; এখানে আপনি দেখেন dependency graph একটি বাস্তব প্রজেক্টের একটিমাত্র সুতোয় কীভাবে কাজ করে।
সঙ্গে রাখার মতো পুনর্বিবেচনা: ITTO চল্লিশটি তালিকা নয় — এটি একটি dependency graph, যেখানে একটি process-এর output পরেরটির input। এই পৃষ্ঠা তা প্রমাণ করে Coral Ridge Resort নির্মাণে — একটি $48,000,000 সৈকতঘেঁষা হোটেল, যার schedule baseline শেষ হয় 31 August 2028-এ।
শৃঙ্খল — Coral Ridge-এর মধ্য দিয়ে একটি সুতো
একটিমাত্র সুতো অনুসরণ করুন: আমরা কি frame গড়া শুরু করতে পারি? দেখুন কীভাবে প্রতিটি output পরের input হয়ে ওঠে।
1 · Initiate Project
Coral Ridge শুরু হয় একটি অভিপ্রায় হিসেবে, প্রজেক্ট হিসেবে নয়। Initiate Project একে প্রজেক্টে রূপান্তরিত করে।
- Inputs: business case, sponsor-এর mandate
- Tool: expert judgement, আর "done" মানে কী তা নিয়ে একটি আলোচনা
- Output: project charter — যা $48M budget-এর সীমা নির্দিষ্ট করে আর যে opening season নির্মাণকে ছুঁতে হবে তা নাম ধরে বলে
charter হলো প্রথম বাস্তব artefact। নিচের দিকের সবকিছু একে উদ্ধৃত করে।
2 · Define Scope
- Input: charter (ধাপ ১-এর একটি output)
- Tool: decomposition
- Output: WBS — বাস্তব work package, যার মধ্যে আছে
1.2.4 Coastal & environmental clearance,1.3.2 Piling on coastal soil,1.4.1 RCC frame — floors 1–5
handoff-টা লক্ষ করুন। charter থাকার আগে আপনি scope-কে decompose করতে পারতেন না, কারণ কীসের বিপরীতে decompose করবেন তা-ই থাকত না।
3 · Identify Risks
- Input: WBS (ধাপ ২-এর output) আর site survey-গুলো
- Tool: expert judgement, site investigation
- Outputs: register entry। Coral Ridge থেকে তিনটি বাস্তব উদাহরণ:
| Entry | Type | Status |
|---|---|---|
| Coastal water table is high; piling reaches competent strata by −22 m | Assumption | Confirmed |
| ECA clearance granted before superstructure | Constraint | Pending |
| Monsoon (Jun–Sep) halts external works ~10 weeks/yr | Assumption | Confirmed |
তৃতীয়টি নজরে রাখুন। যে monsoon বছরে দশ সপ্তাহ বাইরের কাজ থামিয়ে দেয়, সেটি এমন কোনো risk নয় যার আপনি প্রতিক্রিয়া দেন — এটি এমন একটি constraint যা ঘিরে আপনি schedule সাজান। সেই পার্থক্যটা এখুনি গুরুত্বপূর্ণ হতে চলেছে।
4 · Develop Schedule
এখানেই শৃঙ্খলটা ফল দেয়। দেখুন কী কী আগে থেকে থাকতে হবে:
- Inputs: WBS (ধাপ ২), duration estimate-গুলো, আর ধাপ ৩-এর register entry-গুলো — monsoon window আর ECA dependency
- Tools: critical path method; আর
1.3.2 Piling-এর জন্য PERT, কারণ coastal strata-য় ভিত্তির গভীরতা সত্যিই অনিশ্চিত - Output: schedule baseline — শেষ হয় 31 August 2028-এ
শুধু piling-এ কেন PERT? কারণ সেটাই সেই একমাত্র duration যা কেউ আত্মবিশ্বাসের সাথে বলতে পারে না। tool-টা অনিশ্চয়তার সাথে মানিয়ে বেছে নেওয়া হয়, সমানভাবে প্রয়োগ করা হয় না। "tools and techniques" বাস্তবে এটাই মানে — একটি menu যা থেকে আপনি বেছে নেন, অনুসরণ করার procedure নয়।
আর ECA constraint-ই কারণ কেন superstructure শুধু আগেভাগে schedule করা যায় না। clearance হলো এমন
একটি permitting process-এর output যা এখনও pending। সেটা না থাকা পর্যন্ত 1.4.1 RCC frame-এর
এমন একটি input আছে যা সে পায় না।
তাহলে: আমরা কি frame গড়া শুরু করতে পারি? না — আর ITTO আপনাকে ঠিক বলে দেয় কেন, কাউকে ব্যাখ্যা করতে না হয়েই।
5 · Monitor Schedule
- Input: schedule baseline (ধাপ ৪-এর output) আর প্রকৃত অগ্রগতি
- Tool: variance analysis, earned value
- Outputs: variance, forecast, আর change requests
আর একটি change request হলো Assess Changes-এর একটি input, যার output হতে পারে একটি re-baseline — যা আবার Monitor Schedule-এর নতুন input হয়ে ওঠে।
শৃঙ্খলটা একটি loop-এ বন্ধ হয়ে যায়। এটাই সেই অংশ যা grid আপনাকে দেখাতে পারে না।
এটি আপনার পড়াশোনার জন্য কী বোঝায়
উপরের শৃঙ্খলটি পাঁচটি process ছুঁয়ে গেছে। কেউ কিছু মুখস্থ করেনি, তবুও input-গুলো সব আন্দাজযোগ্য ছিল — কারণ একটি input আসলে এমন একটি output যা অন্য কেউ ইতিমধ্যেই তৈরি করেছে।
তিনটি নিয়ম যা সাধারণভাবে খাটে:
Output হলো বিশেষ্য; tool হলো ক্রিয়া। baseline, register, charter, plan — এগুলো output। decomposition, estimation, analysis, judgement — এগুলো tool। একটি term যদি কোনো document-কে নাম দেয়, তবে সেটা প্রায় কখনোই tool নয়।
Plan হলো planning process-এর output আর অন্য সবকিছুর input। "Plan Schedule" output দেয় schedule management plan — নিয়মগুলো। "Develop Schedule" সেই নিয়ম গ্রহণ করে আর output দেয় baseline — তারিখগুলো। দুটো আলাদা process, দুটো আলাদা output, আর candidate-রা এগুলো অনবরত গুলিয়ে ফেলে।
একটি process যদি কিছু তৈরি করে, নিচের দিকের কিছু-একটা সেটা ব্যবহার করে। consumer নেই এমন একটি output সাধারণত বোঝায় আপনি process-টা ভুল পড়েছেন — অথবা আপনি এমন documentation বানাচ্ছেন যা কেউ ব্যবহার করে না, যা নিজেই একটি সমস্যা।
VanillaPM-এ এটা কোথায় দেখবেন
শৃঙ্খলটা কোনো শেখানোর কৌশল নয় — এটাই হলো app কীভাবে তৈরি, আর আপনি এটায় ক্লিক করতে পারেন।
Coral Ridge sample খুলুন (python manage.py seed_tutorial) আর একই সুতো অনুসরণ করুন: Charter
tab-এ আছে ধাপ ১-এর output; WBS-এ ধাপ ২-এর; Risk and Assumption register-এ ধাপ ৩-এর;
Gantt এগুলো সব গ্রহণ করে baseline তৈরি করে; আর Variance view হলো ধাপ ৫, যা change request
আবার governance-এ ফেরত পাঠায়।
উপরের শৃঙ্খলের প্রতিটি তীর একটি বাস্তব database-এ একটি বাস্তব foreign key। ITTO যে সত্যিকারের কিছু বর্ণনা করে তার সবচেয়ে বিশ্বাসযোগ্য যুক্তি এটাই: আপনি একটি কার্যকর project tool বানাতে পারবেন না এটা ছাড়া, আপনি একে ITTO বলুন বা না বলুন।
ধারণা আর সব 40 process-এ ফিরে যান: ITTO ব্যাখ্যা। lookup দরকার? ITTO cheat sheet। walked task-এর জন্য প্রস্তুত? শুরু করুন P1 · Develop a common vision-এ।