7. Development positions and decisions

7.1 Positions describe the work, not percent complete

This management approach uses conceptual, FEED (front-end engineering design), 30%, 60%, 90% and delivery positions. These engineering-derived names describe what has become sufficiently established for the next kind of work. An undertaking can use other names while preserving the questions that matter.

They are not percentages of code, effort, cost or tasks completed. Different parts of a project can occupy different positions. A late finding can reopen one interface without returning the entire project to its beginning.

A small undertaking can combine positions. A substantial or regulated project may require formal decisions at particular boundaries. This manual neither creates those gates automatically nor cancels adopted gates.

The question at each position is what the next work will rely on. Prepare evidence for that question rather than satisfying a percentage label through document production.

7.2 Conceptual and FEED positions

Conceptual work establishes the intended outcome, affected users, governing constraints and plausible approaches. It examines alternatives before treating one as a commitment.

FEED develops the basis into coherent scope, contribution boundaries and principal interfaces. It should make major assumptions visible and identify the consequential choices that determine later work.

An accepted basis can contain open matters. Acceptance identifies what was decided and what remains conditional. It does not transform every source statement into a universal instruction.

Before expanding production, establish whether the contribution boundaries preserve the intended whole. A decomposition with every row populated can still divide a coupled responsibility badly.

7.3 Execution definition around 30 percent

Execution definition makes production contracts, inputs, examination methods and responsibility usable. Participants should understand what they can produce and what their consumers require.

Dependency analysis helps identify the production order and unresolved coupling. A project may adopt an initial DAG as a baseline, but the meaningful result is an intelligible course of work. The diagram is a representation of that result.

The project can preserve a baseline when planning or external commitments need one. Finer implementation relationships can remain in design material or local declarations until a query or consumer needs more structure.

7.4 Detailed development around 60 percent

The 60% position concerns whether consequential design and integration premises are established well enough to expand dependent production. It does not require that all uncertainty disappear or every relationship fit an acyclic diagram.

Examine developed interfaces, closely coupled groups, remaining technical conditions and the proposed order of work. Identify matters that could change the deliverable set or invalidate work already produced. State how each such matter will be resolved, contained or presented for a qualified decision.

Grouping co-designed work can make progress possible without changing its deliverable identities. The group needs a coherent integration responsibility and an examined path through its difficult interfaces. Grouping alone does not establish that every input is already supplied.

A warning sign is repeated analysis that finds more coupling while no product advances. Another is narrowing designs merely to close graph cycles. Ask which experiment or real integration would answer the consequential question more directly.

Where the project has an adopted human gate, present a short assessment with its actual evidence and qualifications. The person decides the gate. Your check does not substitute for that decision.

7.5 Produced work around 90 percent

At this position, intended contributions are integrated and ready for the remaining concentrated examination in use. Establish scope coverage, relationship coverage and applicable evaluation coverage.

Do not postpone all testing until this point. Earlier checks establish local behavior and consequential premises. The later examination addresses the assembled result and any claims not yet established.

An incomplete product may still be useful under an authorized reduced scope. State that scope and its limitations. Do not relabel missing required work as uncertainty merely to claim completion.

7.6 Delivery and continuing responsibility

Delivery transfers an identified result to its intended recipient with the information and continuing responsibilities needed for use. Acceptance is an authorized act concerning an identified subject, scope and purpose. Release authorizes an identified result to be made available for a stated use or audience. Establish the decisions required for the particular delivery; an internal review candidate and a released product have different conditions. The recipient needs usable instructions, limitations and recovery information where relevant.

The amount of ceremony follows the actual delivery obligations. A routine internal change and a professional reliance product do not have identical requirements. Neither should inherit the other's process by analogy alone.

Source integration, such as a Git merge, brings a change into a selected source revision. Integration of the work brings related contributions into a usable result and examines their relationships. A merge can contribute to that result without establishing it. State which operation or outcome occurred and which acceptance or release decisions apply.