The Three Maps Before the Big Project

Big projects often look healthiest right before they become expensive. The kickoff is energetic, the roadmap has names on it, the early diagrams look reasonable, and everyone has enough context to feel aligned.

Then the work starts and the project discovers its real shape. A dependency was not a dependency in the planning system. A decision owner was present in the kickoff but not actually available. A migration step looked technical but was really a support problem. A risk everyone mentioned casually becomes the thing that controls the schedule.

It failed because the plan hardened before the group understood the terrain.

The thesis

Before a big project gets real commitments, a principal engineer should make three maps: a system map, a people map, and a risk map.

The important claim is not that maps are useful. The important claim is that one map is misleading. A system diagram without decision owners creates false confidence. A stakeholder list without technical dependencies creates political comfort. A risk register without sequencing becomes anxiety in table form.

Large technical work moves through code, people, and uncertainty at the same time. Planning should expose all three before scope calcifies.

The production pattern

The recurring pattern is a project that begins with a target architecture and a date. The architecture shows services, data flows, interfaces, and rollout stages. The date comes from a business window, a leadership promise, or a coordination need with another group.

Everyone knows the project is cross-functional, but the plan treats "cross-functional" as a staffing detail instead of a design constraint. The implementation depends on teams with different priorities. The rollout depends on operators who were not in the architecture review. The data migration depends on old semantics that are understood by only a few people. The product behavior depends on a decision that nobody wants to own until the tradeoff is unavoidable.

In the first few weeks, the project still looks busy. Engineers write code, documents get updated, and meetings increase. The stall arrives later, when a seemingly small open question blocks a large downstream sequence.

That is the cost of missing maps. The work was visible. The terrain was not.

The trap

The obvious response is to ask for a better plan. More milestones, more tickets, more named phases, more diagrams, and more status updates.

Those can help, but they often make the wrong thing precise. A plan can be detailed and still hide a dependency with no accountable owner. A diagram can be accurate and still hide rollback work no one has designed. A roadmap can be sequenced and still hide the riskiest unknown until the last responsible moment has passed.

The deeper trap is treating planning as prediction. Big-project planning should be a way to force choices while choices are still cheap. The question is not "Can we describe the work?" The question is "Can we see what will constrain the work?"

The model

I use three maps before I trust a large project plan.

System map: the technical shape of the work. This is not only a component diagram. It includes data ownership, integration points, operational boundaries, compatibility requirements, migration paths, rollback paths, and the parts of the current system that must keep behaving while the new work lands.

For the system map, I look for:

Dependencies: what must change, stay stable, or be available.
Interfaces: where contracts cross service, team, or user boundaries.
State: what data can be recomputed, migrated, repaired, or lost.
Runtime behavior: what fails under latency, retries, overload, or partial rollout.
Sequencing: what must happen before other work becomes safe.

People map: the decision and ownership shape of the work. Big projects do not move only through tickets. They move through people who can say yes, no, not yet, or not my problem. A people map names those paths before the project needs them urgently.

For the people map, I look for:

Decision owners: who can resolve product, technical, operational, and migration tradeoffs.
Implementing owners: who is actually funded to do the work.
Operating owners: who inherits alerts, support load, data repair, and user pain.
Consulted experts: who has historical context but should not become a hidden blocker.
Missing rooms: which groups will be affected but are not yet in the conversation.

Risk map: the uncertainty shape of the work. This is not a generic list of things that could go wrong. It is a ranked view of what can invalidate the sequence.

For the risk map, I look for:

Risk hotspots: the few areas where being wrong is expensive.
Unknowns: questions that need evidence rather than opinion.
Irreversible choices: decisions that create long compatibility or migration tails.
Adoption risks: places where the system can ship but not become used.
Recovery paths: what we will do if the chosen path fails.

The useful artifact is not three polished documents. It is a shared view of dependencies, decision owners, risk hotspots, sequencing, and unknowns. If the maps do not change the plan, the mapping probably did not go deep enough.

Where this model breaks

Mapping can become procrastination. Some engineers are most comfortable when the work is still conceptual, and maps can become a socially acceptable way to delay commitment.

The test is whether the maps produce choices. A useful system map changes sequence. A useful people map changes who is in the room or who owns a decision. A useful risk map changes what evidence is gathered first. If none of that happens, the project is decorating uncertainty.

The model also breaks for genuinely exploratory work. If the goal is to discover whether a product direction, algorithm, or user behavior is real, a full map may create false precision. In that case, the right map may be deliberately small: what are we testing, what will we not build yet, and what signal ends the exploration?

There is also a timing cost. Mapping too early can preserve assumptions that should be challenged by prototypes. Mapping too late turns into damage control. The right moment is usually when the organization is close to making commitments but still able to change sequence, scope, or ownership.

What I do now

I ask for the three maps before I bless a big project plan. I do not need them to be beautiful. I need them to be decision-grade.

For the system map, I ask someone to draw the current and target flow on the same page. If the current system is missing, the team is designing against an idealized past. I want to see what remains during rollout, where compatibility matters, and what cannot be rolled back easily.

For the people map, I ask who can decide each uncomfortable tradeoff. If the answer is "leadership" or "the platform team," I ask for names and decision scope. Vague ownership is how big projects acquire invisible queues.

For the risk map, I ask what we should learn in the first two weeks that would change the plan. This question is useful because it forces the group to admit which assumptions are load-bearing.

I also watch for disagreement between the maps. If the system map says the hardest risk is migration but the people map has no migration owner, the plan is not ready. If the people map depends on a group whose roadmap is already full, the schedule is fiction. If the risk map says adoption is the biggest risk but every milestone is internal delivery, the project is measuring the wrong thing.

The principal-engineer lens is sequencing. The job is not to make every risk disappear. It is to decide which risks must be reduced before the organization spends heavily, and which risks can be carried consciously.

Closing takeaway

Before a big project hardens, make the system map, people map, and risk map agree. If they tell different stories, fix the sequence before adding more scope.