Two weeks ago I sat in a room at the Ministry of PANRB for launch-planning discussions on INA Digital, Indonesia's government digital-services initiative. Quantum's part is one contribution among many, and I am not going to describe the program from the inside. What I can write about is what a room like that does to your understanding of scope.
Scope is not a list of features
At national scale, the feature list is the least interesting document on the table. Everybody agrees that citizens should be able to do the thing. The hard questions are about authority:
- Who decides what "the thing" is when two agencies describe it differently?
- Who accepts that it works, and against which scenario?
- Who can say stop?
If those three questions have no names attached, the feature list is fiction. Work will proceed, demos will happen, and nothing will be released, because nobody is allowed to say yes.
I had learned a version of this on smaller projects. Seeing it at this scale made it a rule: before any build starts, name the decision owner, the acceptance authority, and the person who can halt the work. Three names, written down, agreed by both sides.
The smallest end-to-end outcome
The second lesson is about size. When the ambition is national, the temptation is to plan for the whole thing at once, because anything smaller looks unambitious in a room full of ministries.
The opposite is true. The credible plan is the smallest outcome that runs end to end for one real user: one service, one citizen, one complete journey, on real infrastructure, accepted by a named person. Everything that follows is a repetition of a pattern that already works. Everything planned before that first slice exists is a hope.
This is not a small-company bias. It is how any system that has to survive contact with the public gets built. You find the narrowest path that proves the whole chain, you walk it, and then you widen it.
What I carry back to client work
Three practices came home with me from that room, and they now apply to every engagement, including the ones for companies of fifty people.
- Decision rights before design. A workshop that ends without named owners for decisions and acceptance has not ended. Schedule the next one.
- One slice that touches everything. The first deliverable should cross every boundary the final system will cross: the user, the data, the permission, the integration, the report. Thin, but complete.
- Separate what was decided from what was discussed. Meeting notes are not decisions. A decision has an owner, a date, a reason, and the document it changed.
If you are sponsoring a large program
Ask, in the first planning meeting, who can accept the first release and who can stop it. If the answer is a committee, ask which member signs. If nobody can say, you have found the real first deliverable of the program, and it is not software.
The boring documents are the real ones
What I took away had nothing to do with architecture diagrams. On any platform with many stakeholders, the documents that decide the outcome are the list of who can decide what, the scenario a first release will be judged against, and a dated record of the decisions already made. Those are dull to write and easy to skip when everyone is enthusiastic. They are also the only things that survive a change of personnel, a change of minister, or a change of vendor. On a program that will outlive every individual contributor, they are the product, and the software is an implementation of them.
Name who decides, who accepts, and who can stop, then build the thinnest slice that touches everything.