Together, or in turn

The same two purchases, and the sign of the answer changes

Programme A is line-end production capture. Programme B replaces the planning and order-booking system. They share no data, no supplier and no hardware. Nothing about A is an input to B. On any dependency map they are two unconnected boxes, which is exactly why the steering group saw no reason not to run them at once.

They share one thing: 96 of A's hours and 150 of B's hours are Retno's, and she is one person.

Wanagiri costed both ways, over the window Sundari uses for everything: three years, or 156 weeks from the decision. She does not discount. Course 20.6 owns why a discount rate and a comparator move a machine answer more than the machine does, and her view is that inside three years the argument costs more than it settles. What follows is her convention, not a rule.

In turn, A first. Her usable rate on a single topic is 5.2 hours a week, so A takes 18.5 weeks of her and goes live at week 22.5 after a four-week tail. B follows and goes live at week 51.3.

• A: USD 60,774.67
• B: USD 47,598.88
• Together: USD 108,373.55

Side by side, she splits the week between them. Two topics, so 1.6 hours a week disappear into re-entry and each programme gets 2.2 usable hours. A goes live at week 47.6. B goes live at week 72.2.

• A: USD 41,603.08
• B: minus USD 57,829.78
• Together: minus USD 16,226.70

The same two purchases, from the same two suppliers, at the same prices, delivering the same benefits. The pair is worth USD 124,600.25 more done in turn than done at once. Nothing in that swing is a difference in what was bought.

Why B goes negative and A does not

Delay alone does not flip a sign. A is delayed by 25 weeks and still returns USD 41,603.08. What happens to B is a second thing, and it is the part a schedule slip never shows.

A specification is a sequence of decisions, and B has 84 of them. What does a booked minute mean? Is a line's capacity attended time or on-standard time? How is a split delivery represented? What happens to a partly-cut order when a date moves? Retno's diary from the two earlier programmes gives the rate at which those decisions came back, reversed or amended after the supplier had built to them:

• decisions taken in a single unbroken session: 9.0% came back
• decisions taken in a fragmented week: 31.0% came back

Across 84 decisions that is 7.56 revisits against 26.04. That is 18.48 extra, at a measured USD 1,455 each in supplier rework and re-testing, so USD 26,888.40. Not one hour of it is visible in a project plan, because every one of those decisions was made on time.

The larger half is what happens when a revisit is not caught before go-live. B's capacity model was the decision Retno signed in the shortest week of the programme. It books attended minutes where the factory plans in on-standard minutes, a distinction course 5.4 spends a lesson on and everybody blurs in conversation. The supplier built exactly what the signed document said. The system was live and wrong for 17 weeks before anybody could prove it: three orders recovered by air at USD 8,940, 214 line-hours idle from mis-sequencing at USD 96 a line-hour, and USD 2,800 of overtime. USD 32,284.

Sequencing and order are two different questions

Having decided to run them in turn, which goes first? Sundari's meeting spent three sessions on it. Here is the answer.

A first, by USD 1,730.77. That is a real answer and it is a small one. Set beside the sequencing decision it is very small indeed:

• deciding to run them in turn rather than at once: USD 124,600.25
• deciding which of the two goes first: USD 1,730.77
• the first decision is worth 72.0 times the second

The steering group argued for three meetings about the question worth USD 1,730.77 and never held a meeting about the one worth USD 124,600.25. The second question looks like a decision and the first looks like an assumption. That gap is the most transferable thing in this lesson: the expensive choices in a portfolio are usually the ones nobody framed as choices.

The rule that produced the answer, and why you can trust it

A first is not a judgement call. Divide each programme's benefit by the hours it takes from the constraint:

• A: USD 900.00 a week of benefit for 96 hours, so 9.38 per hour
• B: USD 1,375.00 a week for 150 hours, so 9.17 per hour

The higher ratio goes first. This is the standard result for cutting the total waiting cost of a queue, and it holds whenever the items are independent. Weigh the benefit you are waiting for against the constraint time it occupies. Never against its capital cost, and never against its headline benefit. B is worth 52.8% more a year than A and still goes second, because it occupies the constraint 56.3% longer.

Two cautions before you apply it. It assumes the programmes are genuinely independent, and lesson 3 is about what to do when they are not. And it says nothing about how many to run at once. That answer is already fixed at one, by the arithmetic above.

Act as an industrial engineer who has costed a parallel implementation after the fact. Two programmes are about to start here. For each: [NAME, CAPITAL, ANNUAL RUNNING COST, EXPECTED ANNUAL BENEFIT ONCE LIVE, AND THE HOURS IT NEEDS FROM EACH NAMED SPECIFIER]. The horizon my owner counts over is [NUMBER] years and we do not discount inside it. The people they share: [NAME AND HOURS A WEEK EACH CAN PROTECT]. Do the following. First, work out each programme's delivery week under three arrangements — A then B, B then A, and both at once — using usable hours rather than diary hours, and subtracting a re-entry cost per topic per week of [HOURS, OR ASK ME TO MEASURE IT]. Second, compute the three-year net of each arrangement: benefit from go-live to the end of the horizon, minus running cost over the same period, minus capital, minus the internal cost of the specification hours. Show your working line by line so I can check it. Third, separate two questions and price them apart: what is it worth to run them in turn rather than together, and what is it worth to put one first rather than the other. Tell me the ratio between those two numbers. Fourth, add the degradation term the schedule does not show: ask me how many specification decisions each programme contains and what share of decisions have historically come back after the supplier built to them, in an unbroken week and in a fragmented one. If I do not know, tell me how to find it from my own change logs rather than inventing a rate. Fifth, give me the ranking rule in one line, which is benefit rate divided by hours of the constraint, and say plainly where it stops being valid. Do not recommend running both to keep momentum.

What to take away

1. Two independent programmes are not independent if they need the same specifier. Wanagiri's pair was worth USD 108,373.55 in turn and minus USD 16,226.70 at once.
2. Running in parallel does two things: it stretches the calendar and it degrades the specification. Only the first shows up in a project plan.
3. A fragmented week raised Wanagiri's rate of decisions coming back from 9.0% to 31.0%, at USD 1,455 a time.
4. Sequencing and ordering are different questions. Here the first was worth 72.0 times the second, and only the second was ever discussed.
5. Order independent programmes by benefit rate divided by hours of the constraint. Wanagiri's larger benefit went second.
6. The expensive decisions in a portfolio are the ones nobody framed as decisions.