Project planning — WBS, Gantt chart, CPM আর PERT

১ · Project আর operations — পরিকল্পনা কেন আলাদা বিদ্যা

একটি কাল্পনিক জেলা শহরের স্কুল ঠিক করল, এবার থেকে পরীক্ষার ফলাফল কাগজের খাতায় নয়, একটি অ্যাপে প্রকাশ হবে — শিক্ষক নম্বর তুলবেন, অ্যাপ নিজেই grade বের করবে, অভিভাবক মোবাইলে ফল দেখবেন। প্রধান শিক্ষক জানতে চাইলেন তিনটি প্রশ্নের উত্তর: কবে হবে? কত খরচ? দেরি হলে আগে থেকে বুঝব কীভাবে? এই পর্বের পুরোটা জুড়ে আমরা এই “স্কুল ফলাফল অ্যাপ” (কাল্পনিক) project-টি পরিকল্পনা করব।

প্রথমে একটি পার্থক্য। একটি project-এর নির্দিষ্ট শুরু আর শেষ আছে, আর এটি একটি অনন্য ফল তৈরি করে — এই অ্যাপটি আগে কখনো এই স্কুলের জন্য বানানো হয়নি। অন্যদিকে operations হলো নিয়মিত, পুনরাবৃত্ত কাজ: অ্যাপ চালু হওয়ার পর প্রতি পরীক্ষায় নম্বর তোলা, server চালু রাখা, ছোট bug সারানো। Operations-এ অতীতের অভিজ্ঞতা প্রায় হুবহু খাটে; project-এ প্রতিবার কিছু না কিছু নতুন, তাই অনিশ্চয়তা বেশি। এ কারণেই project-এর জন্য আলাদা পরিকল্পনার পদ্ধতি দরকার।

Triple constraint — scope, সময়, খরচ আর মাঝখানে quality

Project management-এর সবচেয়ে পরিচিত ছবি একটি ত্রিভুজ: তিন কোণে scope (কী কী বানাতে হবে), সময় আর খরচ, আর মাঝখানে quality. একে triple constraint বা iron triangle বলে। ধারণাটি সাধারণত Martin Barnes-এর নামে উদ্ধৃত হয় (১৯৬৯ সালের দিকে একটি প্রশিক্ষণ কোর্সে) — তবে উৎস নিয়ে বিভিন্ন বর্ণনা আছে। মূল কথা: তিনটির একটি বদলালে অন্তত আরেকটি বদলাতে হবে, নইলে চাপটা নিঃশব্দে quality-র ওপর পড়ে।

• প্রধান শিক্ষক যদি বলেন “SMS-এ ফল পাঠানোর feature-ও চাই” (scope বাড়ল), তাহলে হয় সময় বাড়বে, নয় খরচ (আরও লোক), নয়তো test কম হবে — অর্থাৎ quality কমবে।
• “ফল প্রকাশের তারিখ দুই সপ্তাহ এগিয়ে আনুন” (সময় কমল) — তাহলে scope কাটতে হবে বা খরচ বাড়াতে হবে (অংশ ৬-এর crashing).

পর্ব ২৪-এ (requirement management) আপনি scope creep দেখেছেন — প্রভাব না মেপে scope বাড়তে থাকা। Triple constraint সেই সমস্যারই হিসাবের দিক: প্রতিটি নতুন চাহিদার সাথে প্রশ্ন, “এর বদলে কোনটি ছাড়ব?”

২ · Work breakdown structure — বড় কাজকে ভাঙার নিয়ম

“স্কুল ফলাফল অ্যাপ বানানো” — এই এক লাইনের কাজের সময় অনুমান করা অসম্ভব। কিন্তু “শিক্ষকের নম্বর তোলার screen” বা “grade হিসাবের module” — এগুলোর অনুমান সম্ভব। Work breakdown structure (WBS) হলো পুরো project-কে ধাপে ধাপে ছোট অংশে ভাঙা একটি গাছ। ওপরে project, তার নিচে বড় বড় deliverable (হস্তান্তরযোগ্য ফল), তার নিচে আরও ছোট অংশ, আর সবচেয়ে নিচের পাতাগুলো work package.

ভালো WBS-এর কয়েকটি প্রচলিত নিয়ম:

• Deliverable-কেন্দ্রিক: শাখাগুলো “কী তৈরি হবে” দিয়ে সাজানো, “কে করবে” বা “কোন মাসে” দিয়ে নয়। এতে কাজ বাদ পড়লে সহজে চোখে পড়ে।
• ১০০% নিয়ম (100% rule): প্রতিটি স্তরের অংশগুলোর যোগফল ঠিক তার ওপরের অংশের সমান — scope-এর বাইরের কিছু নয়, আবার scope-এর কিছু বাদও নয়। PMI-এর WBS-বিষয়ক practice standard এই নিয়মকে কেন্দ্রে রাখে। খেয়াল করুন, “Project management” শাখাটি না রাখলে ১০০% পূর্ণ হতো না — মিটিং আর রিপোর্টেও সময় যায়।
• একই কাজ দুই জায়গায় নয়: শাখাগুলো পরস্পর-বিচ্ছিন্ন হতে হবে, নইলে খরচ দুবার গোনা হয়।
• Work package কত ছোট? এমন ছোট যে একজন দায়িত্বপ্রাপ্ত মানুষ, নির্ভরযোগ্য অনুমান আর মাপা যায় এমন অগ্রগতি থাকে। একটি প্রচলিত হাতের হিসাব হলো 8/80 heuristic: work package মোটামুটি ৮ থেকে ৮০ ঘণ্টার কাজ। এটি কোনো মানদণ্ডের বাধ্যতামূলক নিয়ম নয় — দল, project আর রিপোর্টিং-এর সময়সীমা অনুযায়ী বদলায়।

WBS-এর প্রতিটি অংশের বিস্তারিত বিবরণ রাখা হয় একটি সঙ্গী দলিলে — WBS dictionary. যেমন ১.৩.৩ Grading module-এর ঘরে লেখা থাকে: কাজের বর্ণনা (নম্বর থেকে GPA, স্কুলের নিয়ম অনুযায়ী), কে দায়িত্বে, অনুমিত সময় ও খরচ, নির্ভরতা (database নকশা আগে), আর শেষের শর্ত (“২০টি নমুনা শিক্ষার্থীর হাতে-হিসাব করা ফলের সাথে মিলেছে”)।

৩ · Activity, dependency আর network diagram

Work package থেকে আমরা activity বের করি — সময় নেয় এমন নির্দিষ্ট কাজ। আমাদের অ্যাপের জন্য নয়টি activity, প্রতিটির সময় (দিনে) আর পূর্বসূরি (যে কাজ আগে শেষ হতে হবে):

চার ধরনের dependency আর lag-lead

উপরের টেবিলের সব নির্ভরতা একই ধরনের: আগেরটি শেষ হলে পরেরটি শুরু — finish-to-start (FS). বাস্তবে আরও তিনটি ধরন আছে:

নির্ভরতার সাথে সময় যোগ করা যায় — lag আর lead. “FS + ২ দিন” (lag) মানে আগেরটি শেষ হওয়ার ২ দিন পর পরেরটি শুরু — যেমন SRS পাঠানোর পর অনুমোদনের জন্য ২ দিন অপেক্ষা। “FS − ২ দিন” (lead) মানে আগেরটি শেষ হওয়ার ২ দিন আগেই পরেরটি শুরু — অংশ ৬-এর fast-tracking আসলে এটাই।

AON আর AOA — দুই রকম network diagram

Activity-on-node (AON) রীতিতে প্রতিটি activity একটি বাক্স, আর তীর শুধু নির্ভরতা। চারটি dependency ধরন আর lag এখানে সহজে দেখানো যায়; আধুনিক tool প্রায় সবই AON ব্যবহার করে (একে precedence diagramming method-ও বলে)। অংশ ৪-এর ছবিটি AON.

পুরোনো activity-on-arrow (AOA) রীতিতে উল্টো: activity হলো তীর, আর বৃত্ত (node) হলো ঘটনা — “এই মুহূর্তে আগের কাজগুলো শেষ”। মূল CPM আর PERT এই রীতিতেই আঁকা হতো, আর পরীক্ষায় এখনো আসে। এর একটি বিশেষ জিনিস হলো dummy activity: শূন্য সময়ের ড্যাশ-দেওয়া তীর, যার কাজ দুটি —

1. নির্ভরতা ঠিক রাখা: ধরুন G-এর জন্য D, E, F তিনটিই লাগে, কিন্তু অন্য একটি কাজ (ধরুন “user manual”) লাগে শুধু F-এর পরে। শুধু ঘটনা-বৃত্ত দিয়ে এটি আঁকলে ভুল নির্ভরতা তৈরি হয়; তাই F-এর শেষ-ঘটনা থেকে একটি dummy তীর G-এর শুরু-ঘটনায় যায়।
2. প্রতিটি activity আলাদা চেনানো: AOA-তে activity-কে তার শুরু ও শেষ ঘটনার জোড়া (i, j) দিয়ে চেনা হয়। D আর F দুটোই ঘটনা ৩ থেকে শুরু; দুটো একই শেষ-ঘটনায় গেলে দুটোই হতো (৩, ৫) — তাই একটির শেষে আলাদা ঘটনা আর একটি dummy লাগে।

একটি network-এ কোনো চক্র থাকতে পারে না — “A-র আগে B, B-র আগে A” অসম্ভব। অর্থাৎ network হলো একটি DAG (directed acyclic graph) — Git-এর commit graph-এর মতোই। আর DAG-এর node-গুলোকে নির্ভরতার ক্রমে সাজানোর অ্যালগরিদম হলো topological sort; DSA কোর্সে এর প্রমাণ আর Kahn-এর পদ্ধতি আছে (Topological sort আর DAG, পটভূমির জন্য গ্রাফের পরিভাষা)।

৪ · CPM — forward pass, backward pass আর float

Critical path method (CPM) দুটি প্রশ্নের উত্তর দেয়: পুরো project কমপক্ষে কত দিনে শেষ হবে, আর কোন কাজ কতটা দেরি সইতে পারবে। প্রতিটি activity-র জন্য চারটি সংখ্যা বের করা হয়:

ES/EF বের করা হয় শুরু থেকে শেষের দিকে — forward pass; LS/LF বের করা হয় শেষ থেকে শুরুর দিকে — backward pass. মনে রাখার কৌশল: সামনে যেতে বড়টি নিন (সব পূর্বসূরি শেষ না হলে শুরু করা যায় না), পেছনে যেতে ছোটটি নিন (যে উত্তরসূরি সবচেয়ে আগে শুরু হতে হবে, সে-ই সীমা ঠিক করে)। এখানে “দিন ০ থেকে শুরু” রীতি নেওয়া হয়েছে: ES = ০, সময় ২ হলে EF = ২। কিছু বই “দিন ১ থেকে শুরু” রীতি নেয় (তখন ES = ১, EF = ২); উত্তর একই থাকে, শুধু লেখা আলাদা — পরীক্ষায় যে রীতি নেবেন, শুরুতেই লিখে দিন।

প্রথমে একটি ছোট network-এ হাতে-কলমে দেখি — একটি login feature-এর ছয়টি কাজ (কাল্পনিক)। প্রতিটি বাক্সে ওপরে ES ও EF, নিচে LS, float (F) ও LF. “পরে” চেপে এগোন; কমলা দাগ দেখাবে কোন বাক্সের হিসাব চলছে।

এবার আমাদের নয়টি activity-র পুরো network. একই নিয়মে হিসাব করলে ছবির সংখ্যাগুলো পাওয়া যায়:

Total float বনাম free float — সূক্ষ্ম কিন্তু পরীক্ষার প্রিয়

C-এর total float ১ দিন: C এক দিন দেরি করলে project-এর শেষ তারিখ বদলায় না। কিন্তু C-এর free float শূন্য — কারণ C-এর EF ৯ আর তার উত্তরসূরি E-র ES-ও ৯। C এক দিন দেরি করলে E-কেও এক দিন পিছাতে হয়, আর তখন E-র নিজের float খেয়ে ফেলা হয়। অর্থাৎ C আর E একটি float ভাগ করে নিচ্ছে: পথ A → C → E → G-তে মোট বাড়তি সময় মাত্র ১ দিন। E-র ক্ষেত্রে total float আর free float দুটোই ১, কারণ E-র পরে G-এর ES ১৩ আর E-র EF ১২। F-এর দুটোই ২।

A → C → E → G → H → I পথটির দৈর্ঘ্য ২১ দিন — critical path-এর চেয়ে মাত্র ১ দিন কম। একে বলে near-critical path. এখানে একটু দেরিতেই পথটি নতুন critical path হয়ে যাবে। তাই ভালো পরিকল্পনাকারী শুধু critical path নয়, কম float-এর পথগুলোও ঝুঁকির তালিকায় রাখেন — পর্ব ৬২-এর (risk আর quality management) risk register-এ এর জায়গা।

এবার পুরো হিসাবটি কোডে। নিচের প্রোগ্রাম Kahn-এর অ্যালগরিদমে topological order বানায়, সেই ক্রমে forward pass, উল্টো ক্রমে backward pass করে, তারপর float-এর টেবিল আর সব critical path ছাপে:

// CPM on a 9-activity AON network (fictional school result app), in days.
// activity: [duration, predecessors]
const acts = {
  A: [4, []], B: [3, ["A"]], C: [5, ["A"]], D: [6, ["B"]], E: [3, ["C"]],
  F: [4, ["B"]], G: [3, ["D", "E", "F"]], H: [4, ["G"]], I: [2, ["H"]] };
const ids = Object.keys(acts), succ = {}, indeg = {};
for (const k of ids) { succ[k] = []; indeg[k] = acts[k][1].length; }
for (const k of ids) for (const p of acts[k][1]) succ[p].push(k);
// Kahn's algorithm: take an activity once all its predecessors are placed
const order = [], ready = ids.filter(k => indeg[k] === 0);
while (ready.length) { const k = ready.shift(); order.push(k);
  for (const s of succ[k]) if (--indeg[s] === 0) ready.push(s); }
console.log("topological order:", order.join(" "));
const ES = {}, EF = {}, LS = {}, LF = {};
for (const k of order) {                         // forward pass
  ES[k] = Math.max(0, ...acts[k][1].map(p => EF[p])); EF[k] = ES[k] + acts[k][0]; }
const T = Math.max(...ids.map(k => EF[k]));
for (const k of [...order].reverse()) {          // backward pass
  LF[k] = Math.min(T, ...succ[k].map(s => LS[s])); LS[k] = LF[k] - acts[k][0]; }
console.log("act dur  ES  EF  LS  LF  TF  FF");
for (const k of order) {
  const ff = Math.min(T, ...succ[k].map(s => ES[s])) - EF[k];   // free float
  console.log([k, acts[k][0], ES[k], EF[k], LS[k], LF[k], LS[k] - ES[k], ff]
    .map((v, i) => String(v).padStart(i ? 4 : 3)).join(""));
}
// critical path(s): chains of zero-float activities that touch end to end
const crit = k => LS[k] === ES[k];
const walk = (k, path) => succ[k].length === 0 ? [path] : succ[k]
  .filter(s => crit(s) && ES[s] === EF[k]).flatMap(s => walk(s, [...path, s]));
const starts = ids.filter(k => acts[k][1].length === 0 && crit(k));
console.log("project duration:", T, "days");
console.log("critical path(s):", starts.flatMap(s => walk(s, [s])).map(p => p.join("-")).join(", "));

topological order: A B C D F E G H I
act dur  ES  EF  LS  LF  TF  FF
  A   4   0   4   0   4   0   0
  B   3   4   7   4   7   0   0
  C   5   4   9   5  10   1   0
  D   6   7  13   7  13   0   0
  F   4   7  11   9  13   2   2
  E   3   9  12  10  13   1   1
  G   3  13  16  13  16   0   0
  H   4  16  20  16  20   0   0
  I   2  20  22  20  22   0   0
project duration: 22 days
critical path(s): A-B-D-G-H-I

৫ · PERT — তিনটি অনুমান থেকে সম্ভাবনা

CPM ধরে নেয় প্রতিটি কাজের সময় নিশ্চিত। Software-এ তা প্রায় কখনো সত্য নয় — testing-এ কত bug বেরোবে, কেউ আগে জানেন না। PERT প্রতিটি activity-র জন্য একটি সংখ্যার বদলে তিনটি নেয় — একটি three-point estimate:

• a — optimistic: সব ঠিকঠাক চললে সবচেয়ে কম সময়
• m — most likely: সবচেয়ে সম্ভাব্য সময়
• b — pessimistic: অনেক কিছু খারাপ হলে (কিন্তু অসম্ভব বিপর্যয় নয়) সবচেয়ে বেশি সময়

পর্ব ৬০-এ (software estimation) প্রতিটি task-এর three-point অনুমান কীভাবে নেওয়া হয়, তা দেখবেন। এখানে আমাদের কাজ তার পরের ধাপ — task-গুলোর অনুমান জুড়ে পুরো schedule-এর সম্ভাবনা বের করা। সূত্রগুলো:

এরপর critical path ধরে: project-এর প্রত্যাশিত সময় μ = পথের t_e-গুলোর যোগফল, variance = পথের σ²-গুলোর যোগফল (activity-গুলো পরস্পর-নিরপেক্ষ ধরে), আর standard deviation σ = √Σσ². Central limit theorem-এর যুক্তিতে মোট সময়কে মোটামুটি normal বণ্টন ধরা হয়। তাহলে T দিনের মধ্যে শেষ হওয়ার সম্ভাবনা:

এখানে Φ হলো standard normal-এর cumulative distribution — পরীক্ষায় normal table থেকে পড়া হয়, কোডে math.erf দিয়ে: Φ(z) = ½(১ + erf(z/√২))। Z-score বলে T গড় থেকে কত σ দূরে। কয়েকটি মান মুখস্থ রাখলে কাজে লাগে: Φ(০) = ০.৫, Φ(১) ≈ ০.৮৪১৩, Φ(১.৬৪৫) ≈ ০.৯৫, Φ(২) ≈ ০.৯৭৭২, আর Φ(−z) = ১ − Φ(z).

আমাদের অ্যাপের প্রতিটি activity-র (a, m, b) এমনভাবে নেওয়া হয়েছে যে t_e ঠিক অংশ ৪-এর সময়গুলোর সমান — তাই critical path একই থাকে। খেয়াল করুন H (Testing)-এর অনুমান (২, ৩, ১০) — ডান দিকে লম্বা লেজ, কারণ testing-এ বড় bug বেরোলে অনেক দিন লাগতে পারে। প্রশ্ন: project ২৪ দিনের মধ্যে শেষ হওয়ার সম্ভাবনা কত?

এবার একই হিসাব Python-এ, কয়েকটি T-এর জন্য, আর ৯৫%-এর তারিখ একটি সরল খোঁজ দিয়ে। শেষ অংশে একটি Monte Carlo simulation: প্রতিটি activity-র সময় একটি beta-PERT বণ্টন থেকে এলোমেলোভাবে নিয়ে (নির্দিষ্ট seed-এ) ৫০,০০০ বার পুরো network চালানো হয় — এখানে শুধু critical path নয়, সব পথ প্রতিযোগিতা করে।

import math, random
# activity: (optimistic a, most likely m, pessimistic b, predecessors), in days
acts = {"A": (2, 4, 6, ""), "B": (2, 3, 4, "A"), "C": (3, 5, 7, "A"), "D": (3, 6, 9, "B"),
        "E": (1, 3, 5, "C"), "F": (2, 4, 6, "B"), "G": (2, 3, 4, "DEF"),
        "H": (2, 3, 10, "G"), "I": (1, 2, 3, "H")}
te = {k: (a + 4 * m + b) / 6 for k, (a, m, b, _) in acts.items()}
var = {k: ((b - a) / 6) ** 2 for k, (a, m, b, _) in acts.items()}
print("  ".join(f"{k}:{te[k]:.0f}/{var[k]:.3f}" for k in acts))
crit = "ABDGHI"                        # critical path found by the CPM pass
mu = sum(te[k] for k in crit)
sigma = math.sqrt(sum(var[k] for k in crit))
Phi = lambda z: 0.5 * (1 + math.erf(z / math.sqrt(2)))    # standard normal CDF
print(f"critical path {crit}: mu={mu:.2f} days, var={sigma**2:.3f}, sigma={sigma:.3f}")
for T in (20, 22, 23, 24, 25):
    z = (T - mu) / sigma
    print(f"  P(finish <= {T}) : z={z:+.3f}  p={Phi(z):.4f}")
T = mu                                 # inverse search: smallest T (0.01 steps), p >= 0.95
while Phi((T - mu) / sigma) < 0.95:
    T += 0.01
print(f"95% sure by about {T:.2f} days")
# merge bias: simulate beta-PERT durations so that ALL paths compete
random.seed(61)
N, hit, total = 50000, 0, 0.0
def draw(a, m, b):
    return a + (b - a) * random.betavariate(1 + 4 * (m - a) / (b - a), 1 + 4 * (b - m) / (b - a))
for _ in range(N):
    fin = {}
    for k, (a, m, b, pre) in acts.items():      # dict order is a topological order here
        fin[k] = max((fin[p] for p in pre), default=0) + draw(a, m, b)
    hit += fin["I"] <= 24
    total += fin["I"]
print(f"simulated: mean={total / N:.2f} days, P(finish <= 24)={hit / N:.3f}")

A:4/0.444  B:3/0.111  C:5/0.444  D:6/1.000  E:3/0.444  F:4/0.444  G:3/0.111  H:4/1.778  I:2/0.111
critical path ABDGHI: mu=22.00 days, var=3.556, sigma=1.886
  P(finish <= 20) : z=-1.061  p=0.1444
  P(finish <= 22) : z=+0.000  p=0.5000
  P(finish <= 23) : z=+0.530  p=0.7021
  P(finish <= 24) : z=+1.061  p=0.8556
  P(finish <= 25) : z=+1.591  p=0.9442
95% sure by about 25.11 days
simulated: mean=22.28 days, P(finish <= 24)=0.821

PERT-এর সীমা — merge bias আর অন্যান্য ধারণা

আমাদের near-critical পথ A-C-E-G-H-I-এর গড় ২১, σ ≈ ১.৮২৬; একা এটি ২৪ দিনে শেষ হওয়ার সম্ভাবনা প্রায় ৯৫%. Project শেষ হয় তখনই, যখন সব পথ শেষ। কোনো দিন critical path তাড়াতাড়ি শেষ হলো কিন্তু UI-এর পথ দেরি করল — তখনো project দেরি। একে বলে merge bias: যে বিন্দুতে কয়েকটি পথ মেলে (এখানে G), সেখানে প্রকৃত সময় সবচেয়ে লম্বা গড়-পথের চেয়ে বেশি হওয়ার প্রবণতা থাকে। ১৯৬০-এর দশকেই গবেষকেরা (যেমন MacCrimmon ও Ryavec, ১৯৬৪ সালের দিকে) PERT-এর ধারণাগুলোর এই দুর্বলতা বিশ্লেষণ করেন। অন্য সীমাগুলো:

• স্বাধীনতার ধারণা: variance যোগ করা যায় শুধু activity-গুলো পরস্পর-নিরপেক্ষ হলে। বাস্তবে একই কারণ (একজন অভিজ্ঞ developer অসুস্থ, requirement অস্পষ্ট) অনেক কাজকে একসাথে দেরি করায়।
• (b − a)/6 একটি অনুমান: beta বণ্টনের জন্য একটি সুবিধাজনক সরলীকরণ; আর a, b নিজেই মানুষের অনুমান, প্রায়ই খুব সরু।

তাই আধুনিক চর্চায় Monte Carlo schedule simulation বেশি ব্যবহৃত হয়। তবু PERT-এর সূত্র পরীক্ষায় সবচেয়ে বেশি আসে, আর এর মূল শিক্ষাটি মূল্যবান: একটি তারিখ নয়, সম্ভাবনাসহ তারিখ বলুন।

৬ · Schedule ছোট করা — crashing আর fast-tracking

প্রধান শিক্ষক জানালেন, শিক্ষা অফিসের পরিদর্শন এগিয়ে এসেছে — অ্যাপ ২২ নয়, ১৯ দিনে চাই। Scope কাটা যাবে না। দুটি প্রচলিত কৌশল আছে।

Crashing মানে টাকা দিয়ে সময় কেনা: বাড়তি developer, overtime, দ্রুত server ভাড়া। প্রতিটি activity-র একটি normal সময় ও খরচ আর একটি crash সময় ও খরচ থাকে — যার কমে আর নামানো যায় না। এক দিন কমানোর খরচের হার হলো cost slope:

যেমন D (Backend): normal ৬ দিনে ৯০ হাজার টাকা, crash ৪ দিনে ১১৪ হাজার — slope = (১১৪ − ৯০) ÷ (৬ − ৪) = ১২ হাজার টাকা প্রতি দিন। আমাদের project-এর slope-গুলো (হাজার টাকা প্রতি দিন; বন্ধনীতে normal → crash সময়): A ৩০ (৪→৩), B ১০ (৩→২), C ৮ (৫→৪), D ১২ (৬→৪), E ৬ (৩→২), F ৫ (৪→৩), G ২৫ (৩→২), H ১৫ (৪→৩), I কমানো যায় না (২)। Normal খরচের মোট ৩৯০ হাজার টাকা।

নিয়ম তিনটি: (১) শুধু critical activity কমালে project ছোট হয় — F-এর slope সবচেয়ে কম (৫), কিন্তু F critical নয়, তাই F কমানো টাকা নষ্ট। (২) Critical activity-গুলোর মধ্যে সবচেয়ে কম slope-এরটি এক দিন কমান। (৩) প্রতিবার critical path নতুন করে দেখুন — একটি কমাতেই আরেকটি পথ critical হয়ে যেতে পারে, তখন সব critical পথ একসাথে কমাতে হয়।

দুটি পথ critical হলে “সব critical পথ কাটে এমন সবচেয়ে সস্তা activity-সেট” খুঁজতে হয়। ছোট network-এ সব সম্ভাব্য সেট পরীক্ষা করে দেখাই যথেষ্ট — নিচের প্রোগ্রাম তাই করে:

// Crashing: shorten the project 1 day at a time for the least extra money.
// activity: [normal days, crash days, cost slope in thousand taka per day]
const A = { A: [4, 3, 30], B: [3, 2, 10], C: [5, 4, 8], D: [6, 4, 12], E: [3, 2, 6],
            F: [4, 3, 5], G: [3, 2, 25], H: [4, 3, 15], I: [2, 2, 0] };
const paths = ["ABDGHI", "ACEGHI", "ABFGHI"];      // every start-to-end path
const dur = {}; for (const k in A) dur[k] = A[k][0];
const len = p => [...p].reduce((s, k) => s + dur[k], 0);
const INDIRECT = 19, TARGET = 18;                  // overhead per day, goal in days
let direct = 390;                                  // sum of normal (direct) costs
function report() {
  const T = Math.max(...paths.map(len));
  console.log(`T=${T}  direct=${direct}  indirect=${INDIRECT * T}  total=${direct + INDIRECT * T}`);
  return T;
}
let T = report();
while (T > TARGET) {
  const crit = paths.filter(p => len(p) === T);
  const can = Object.keys(A).filter(k => dur[k] > A[k][1]);   // still crashable
  let best = null;              // cheapest set that shortens EVERY critical path
  for (let mask = 1; mask < 1 << can.length; mask++) {
    const set = can.filter((_, i) => (mask >> i) & 1);
    if (!crit.every(p => set.some(k => p.includes(k)))) continue;
    const cost = set.reduce((s, k) => s + A[k][2], 0);
    if (!best || cost < best.cost || (cost === best.cost && set.length < best.set.length))
      best = { set, cost };
  }
  if (!best) { console.log("no way to crash further"); break; }
  console.log(`  critical: ${crit.join(", ")} -> crash ${best.set.join("+")} by 1 day (+${best.cost})`);
  best.set.forEach(k => dur[k]--); direct += best.cost;
  T = report();
}

T=22  direct=390  indirect=418  total=808
  critical: ABDGHI -> crash B by 1 day (+10)
T=21  direct=400  indirect=399  total=799
  critical: ABDGHI, ACEGHI -> crash H by 1 day (+15)
T=20  direct=415  indirect=380  total=795
  critical: ABDGHI, ACEGHI -> crash D+E by 1 day (+18)
T=19  direct=433  indirect=361  total=794
  critical: ABDGHI, ACEGHI -> crash C+D by 1 day (+20)
T=18  direct=453  indirect=342  total=795

Fast-tracking দ্বিতীয় কৌশল: ক্রমানুসারে হওয়ার কথা এমন কাজ আংশিক একসাথে চালানো — যেমন UI নকশা পুরো অনুমোদনের আগেই frontend-এর কোড শুরু (FS-এর বদলে SS বা lead). টাকা প্রায় লাগে না, কিন্তু rework-এর ঝুঁকি বাড়ে: নকশা বদলালে লেখা কোড ফেলে দিতে হয়। আর software-এ crashing-এর একটি বিশেষ ফাঁদ আছে — দেরি হওয়া project-এ নতুন মানুষ যোগ করলে শেখানো আর যোগাযোগের খরচে কাজ আরও পিছিয়ে যেতে পারে (Brooks-এর সূত্র, The Mythical Man-Month, ১৯৭৫)।

৭ · Resource levelling আর Gantt chart

CPM ধরে নেয় যত লোক দরকার, তত পাওয়া যাবে। বাস্তবে দলে নির্দিষ্ট সংখ্যক developer. অংশ ৪-এর ছোট network-এ ধরা যাক প্রতিটি কাজে developer লাগে: P ১, Q ২, R ১, S ১, T ২, U ১। সবাই ES-এ শুরু করলে প্রতিদিন কতজন লাগবে, তার resource histogram:

দিন ২–৩-এ চারজন লাগছে (Q-র দুজন, R আর S-এর একজন করে), অথচ বাকি দিনে দুই-তিনজন। S-এর float ৪ দিন — তাই S-কে তিন দিন পিছিয়ে, দিন ৫-এ শুরু করলে (তখনো ১ দিন float বাকি) চূড়া ৪ থেকে ৩-এ নামে, আর project-এর সময় ৯ দিনই থাকে। মোট কাজ দুই সারিতেই ২০ developer-দিন — শুধু সাজানো বদলেছে। একে বলে resource levelling (float-এর ভেতরে থাকলে অনেকে বলেন resource smoothing). কিন্তু দলে যদি মাত্র ২ জন থাকেন, float দিয়ে আর হবে না: ২০ developer-দিনের কাজে কমপক্ষে ১০ দিন লাগবে — অর্থাৎ সম্পদের সীমা নিজেই project লম্বা করবে, আর critical path তখন শুধু নির্ভরতা দিয়ে নয়, মানুষ দিয়েও ঠিক হয়।

Gantt chart — schedule-এর ছবি

Network diagram নির্ভরতা দেখাতে ভালো, কিন্তু “আজ কী চলার কথা?” প্রশ্নের উত্তর দেয় Gantt chart: আড়াআড়ি সময়ের অক্ষ, প্রতিটি activity একটি দণ্ড। সাথে থাকে milestone (শূন্য সময়ের গুরুত্বপূর্ণ বিন্দু, সাধারণত ◆ চিহ্নে), নির্ভরতার তীর, আর দিন ১২-র অবস্থায় প্রকৃত অগ্রগতি:

এখানে দুটি স্তর আছে। মোটা দণ্ডগুলো schedule baseline — অনুমোদিত মূল পরিকল্পনার স্থির কপি; পর্ব ২৪-এর requirement baseline-এর মতোই, এটি শুধু আনুষ্ঠানিক অনুমোদনে বদলায়। সরু সবুজ দণ্ড প্রকৃত অবস্থা। ছবি থেকেই বোঝা যায়: D এক দিন দেরিতে শুরু, আর D critical — তাই কিছু না করলে release ২২ নয়, ২৩ দিনে। F-ও এক দিন দেরিতে শুরু, কিন্তু তার float ২ দিন, তাই বিপদ নেই।

৮ · Earned value — পরিকল্পনা বনাম বাস্তব, টাকার ভাষায়

দিন ১২-তে হিসাবরক্ষক বললেন, “বাজেটের ২৪৩ হাজার খরচ হয়েছে, পরিকল্পনায় এই সময়ে ২৭৫ হাজার খরচ হওয়ার কথা — তাহলে আমরা টাকা বাঁচাচ্ছি!” কথাটি বিপজ্জনকভাবে ভুল হতে পারে, কারণ এতে বলা নেই কতটা কাজ হয়েছে। Earned value management (EVM) তিনটি সংখ্যা মিলিয়ে এই ফাঁক বন্ধ করে:

সূত্রগুলো PMI-এর বই আর বিভিন্ন মানদণ্ডে (যেমন যুক্তরাষ্ট্রের ANSI/EIA-748) প্রায় একইভাবে লেখা, তবে EAC-র কয়েকটি রূপ আছে, আর কোনটি নেবেন তা নির্ভর করে খরচের বাড়তি কেন হলো তার ওপর। নিচের প্রোগ্রাম আমাদের অ্যাপের দিন ১২-র অবস্থা থেকে সবগুলো হিসাব করে। ধরে নেওয়া হয়েছে, প্রতিটি activity-র বাজেট তার পরিকল্পিত দণ্ড জুড়ে সমানভাবে খরচ হওয়ার কথা:

# Earned value at the end of day 12 (fictional school result app, thousand taka).
# activity: (planned start, planned finish, budget, % complete, actual cost so far)
acts = {"A": (0, 4, 40, 100, 42), "B": (4, 7, 30, 100, 33), "C": (4, 9, 50, 100, 55),
        "D": (7, 13, 90, 50, 50), "E": (9, 12, 40, 50, 25), "F": (7, 11, 40, 100, 38),
        "G": (13, 16, 30, 0, 0), "H": (16, 20, 50, 0, 0), "I": (20, 22, 20, 0, 0)}
DAY, PLANNED_DAYS = 12, 22

def planned_share(start, finish, day):     # budget assumed spread evenly over the bar
    return min(max((day - start) / (finish - start), 0), 1)

BAC = sum(b for _, _, b, _, _ in acts.values())
PV = sum(b * planned_share(s, f, DAY) for s, f, b, _, _ in acts.values())
EV = sum(b * pc / 100 for _, _, b, pc, _ in acts.values())
AC = sum(ac for *_, ac in acts.values())
SV, CV, SPI, CPI = EV - PV, EV - AC, EV / PV, EV / AC
print(f"BAC={BAC}  PV={PV:.1f}  EV={EV:.1f}  AC={AC:.1f}")
print(f"SV={SV:+.1f}  CV={CV:+.1f}  SPI={SPI:.3f}  CPI={CPI:.3f}")
variants = [("BAC/CPI          (cost rate so far continues)", BAC / CPI),
            ("AC+(BAC-EV)      (overrun was a one-off)", AC + (BAC - EV)),
            ("AC+(BAC-EV)/(CPI*SPI) (late AND over budget)", AC + (BAC - EV) / (CPI * SPI))]
for name, eac in variants:
    print(f"EAC = {name}: {eac:.1f}   VAC = {BAC - eac:+.1f}")
print(f"ETC with BAC/CPI = {BAC / CPI - AC:.1f}")
print(f"rough finish = {PLANNED_DAYS} / SPI = {PLANNED_DAYS / SPI:.1f} days (crude, see text)")

BAC=390  PV=275.0  EV=225.0  AC=243.0
SV=-50.0  CV=-18.0  SPI=0.818  CPI=0.926
EAC = BAC/CPI          (cost rate so far continues): 421.2   VAC = -31.2
EAC = AC+(BAC-EV)      (overrun was a one-off): 408.0   VAC = -18.0
EAC = AC+(BAC-EV)/(CPI*SPI) (late AND over budget): 460.8   VAC = -70.8
ETC with BAC/CPI = 178.2
rough finish = 22 / SPI = 26.9 days (crude, see text)

৯ · Agile planning-এর সাথে তুলনা — কখন কোনটি

পর্ব ৫-এ (Agile আর Scrum) আপনি sprint planning, velocity আর burndown দেখেছেন। প্রশ্ন ওঠে: Agile দলের কি CPM, Gantt chart লাগে? উত্তর: পরিকল্পনা লাগে, কিন্তু অন্য আকারে আর অন্য স্তরে।

Release planning-এ দল velocity দিয়ে মোটা হিসাব করে: backlog-এ ধরুন ১২০ story point, velocity sprint-প্রতি গড়ে ২০ (সাম্প্রতিক কয়েকটির পরিসর ১৬ থেকে ২৪), তাহলে প্রায় ৫ থেকে ৮টি sprint — একটি পরিসর, একটি তারিখ নয়। Roadmap আরও উঁচু স্তরের: “এই প্রান্তিকে অভিভাবকের app, পরের প্রান্তিকে SMS” — লক্ষ্যের ক্রম, তারিখের প্রতিশ্রুতি নয়। দুই জগতের মাঝে সেতু হলো rolling wave planning: কাছের কাজ বিস্তারিত, দূরের কাজ মোটা দাগে, তথ্য এলে ধাপে ধাপে বিস্তারিত।

বাস্তবে অনেক project দুটোই মেশায়: ফল প্রকাশের নির্দিষ্ট তারিখ, server কেনা আর শিক্ষক প্রশিক্ষণের মতো বাইরের নির্ভরতার জন্য উঁচু স্তরের network আর milestone; screen-এর ভেতরের feature-গুলো sprint-এ, অগ্রাধিকার অনুযায়ী। পর্ব ৪-এর (process model) waterfall বনাম iterative-এর সিদ্ধান্তটাই এখানে পরিকল্পনার ভাষায় ফিরে এসেছে।

১০ · AI-এর যুগে — schedule-এর হিসাব যাচাই

AI এখন এক লাইনের বর্ণনা থেকে WBS, Gantt chart আর ঝুঁকির তালিকা বানিয়ে দেয়। শুরু করার জন্য এটি কাজের, কিন্তু project planning-এ AI-এর কিছু চেনা ভুল আছে:

AI-এর দেওয়া schedule হাতে পেলে — চেকলিস্ট

• অন্তত একটি পথের দৈর্ঘ্য আর দুটি activity-র float আমি নিজে হাতে বা কোডে মিলিয়েছি
• Merge point-এ ES সর্বোচ্চ দিয়ে, আর backward pass-এ LF সর্বনিম্ন দিয়ে হয়েছে — যাচাই করেছি
• PERT-এ variance যোগ হয়েছে, standard deviation নয়; Z আর normal table-এর মান মিলিয়েছি
• Crashing-এর প্রতিটি ধাপে কমানো activity তখন critical ছিল, আর critical path নতুন করে দেখা হয়েছে
• WBS-এ project management, testing, deployment আর প্রশিক্ষণ আছে — 100% নিয়ম মেনেছে
• প্রতিটি বই, মানদণ্ড আর সালের উল্লেখ নিজে যাচাই করেছি; আর AI-কে দেওয়া তথ্যে গোপন কিছু ছিল না