Seven cases, and the diary nobody read

Seven proposals, one table, and a number that was never the problem

Wanagiri Garmindo cuts and sews woven bottoms and light workwear. It has twelve lines in Kertajala and four buyers: Quilloway, Meriden Row, Tolvanden and Culverwood. In January its owner, Sundari Prawoto, put seven digital proposals on one table. She asked the obvious question: which of these can we afford?

Capital, all seven: USD 228,600. Claimed benefit, all seven: USD 224,400 a year. Sundari had already agreed a ceiling of USD 240,000. So the answer to the question she asked was all of them, and that is how the meeting ended.

Eleven days later Retno Hardjanto, the industrial engineering manager, asked the question that decided the year. It was not about money at all: who writes down what each of these must do, and who says whether the delivered thing does it?

The resource that appears on no business case

Every one of the seven needs a particular kind of hour. Not a programmer's hour and not a consultant's hour. It needs an hour from somebody who meets three conditions at once:

1. They know how this factory really works, including the parts nobody has written down.
2. They can turn that into a requirement a supplier can build against.
3. They can look at what was delivered and say, with authority, whether it is right.

At Wanagiri three people meet all three: Retno; Bayu Salamun, the one IT person; and Lestari Wibisono, who runs planning. The building holds 810 people. Nobody else can sign an acceptance, because nobody else can be wrong about it in a way that matters.

Their diaries are the constraint. Their diaries were in none of the seven cases.

A consultant can draft, document, map data and chase a supplier. That is 34.0% of the work. The rest is deciding and accepting, and neither can be bought, because both mean being answerable for the answer.

Now the capacity. Wanagiri has 46 working weeks once holidays and buyer visits are taken out. The three of them can protect this much of a week for work that is not their day job: Retno 6.0 hours, Bayu 11.0, Lestari 4.5. That is 989.0 hours a year.

993 hours of demand against 989 hours of supply. The portfolio is over-subscribed by 0.4%. That sounds like a rounding error. Reading it that way is the single most expensive mistake in this course.

The total is where a constraint hides

Split the same 993 hours by the person who has to spend them.

The portfolio is not 0.4% over. It is 118.8% over on the only person who matters. The total hid that, because Bayu is more than half idle on this work and cannot do Retno's part of it. Hours are not one currency. They are three separate currencies with no exchange rate between them. Adding them gave a number that was correct and told the meeting the opposite of the truth.

Every case was true. The set was false.

This is worth being exact about, because it is why nobody was at fault. The heaviest single demand on Retno is programme B, at 150 hours against her 276. Every one of the seven is comfortably possible on its own. Not one case overstated its need, invented a benefit or hid a cost.

What each case did was assume the specification work would be absorbed. Taken on its own, that assumption was correct. Seven correct assumptions were written in different months by different sponsors, and none of those sponsors saw the others. Together they say something about Retno's diary that no author ever wrote and every reader believed.

What "in flight" costs, before anything goes wrong

Wanagiri could measure this instead of arguing about it. It had run two programmes side by side in the previous two years, an attendance system and a stock module, and Retno kept a diary throughout. A session on a topic she had not touched since last week cost 0.8 hours before it produced anything: finding the file, re-reading the last decision, remembering why it was made.

That is a fixed cost per topic per week, so it multiplies with the number of programmes in flight.

At four programmes at once, the seven take 4.1 years. At seven, the arithmetic leaves her 0.4 usable hours a week and the model stops meaning anything, which is itself the answer. "Start everything" is not an aggressive plan. It is a plan whose finish date cannot be worked out.

Act as an operations director who has cancelled digital programmes for want of specification capacity, not money. Do not recommend any product. My situation: [NUMBER] sewing lines, [NUMBER] total headcount, [NUMBER] working weeks a year after holidays and buyer visits. Here is every digital proposal alive in my building, including ones that are only a conversation: [LIST EACH ONE WITH ITS CAPITAL COST, ITS CLAIMED ANNUAL BENEFIT AND WHO RAISED IT]. Here are the people who could write a requirement for one of these AND sign that the delivered thing is right, with the hours a week each can genuinely protect for work that is not their day job: [NAME, ROLE, HOURS A WEEK]. Do the following. First, for each proposal, estimate its specification hours and split them into hours that could be bought in from outside (drafting, documenting, data mapping, chasing) and hours that could not (deciding and accepting). Say why for each split. Second, assign every non-delegable hour to ONE named person from my list, and show the loading per person as hours demanded over hours available. Show the pooled figure too, and tell me plainly whether the pooled figure is hiding anybody. Third, check whether each proposal is individually feasible against its heaviest person; a set can be impossible while every member is possible on its own, so say which case I am in. Fourth, ask me how many hours are lost re-entering a topic that has not been touched since last week; if I have not measured it, tell me how to measure it in a fortnight rather than assuming a figure. Then show how many programmes can run at once before my most loaded person's usable hours fall below a week's useful work. Fifth, write the one-page constraint register I should keep from now on: one row per person, hours available, hours already promised, and the programme each promise belongs to. Do not tell me which programme to buy.

What to take away

1. A digital portfolio is limited by the diaries of the few people who can specify and accept work, not by capital. Wanagiri's ceiling was never reached.
2. Count that resource per person. Wanagiri's pooled loading was 100.4% and its real loading was 218.8%, on one person.
3. Roughly a third of specification work can be bought in. Deciding and accepting cannot, because both mean being answerable.
4. Every one of the seven cases was true and possible on its own. The set was impossible, and no author was wrong.
5. A business case cannot see a portfolio. Keep the register the cases cannot contain.
6. Running programmes in parallel costs a fixed re-entry charge per topic per week, so "start everything" has no finish date you can work out.