Course 07 — Defining an Engineering Project

A project basis makes the undertaking understandable to people who were absent from its first discussions. It connects purpose, requirements, scope, constraints, and decisions.

Good definition leaves room for design while making commitments and unresolved matters clear. It supports a division of work that can produce a coherent result.

This course develops a project basis and an initial work allocation. Detailed planning and technical integration follow in Courses 08 and 09.

Series · Northbank case · Glossary · References

Prerequisites and outcomes

Complete Courses 01 to 06. Bring your source index, interpretation, decision memorandum, and meeting record.

After this course, you can:

• Connect an intended result to its users and benefits.
• Distinguish outcomes, constraints, design choices, and proposals.
• Prepare a project basis with accountable unresolved matters.
• Define deliverables and their examination.
• Allocate scope while preserving interfaces and combined responsibility.

Use Northbank Packets A and B. Identify any new classroom decision separately from the supplied records.

Lesson 1 — Establish purpose before selecting the solution

A requested component can conceal the need it serves. Ask what activity the intended result supports and who will use it.

Distinguish the product from the project. The product may be an installation or design package. The project organizes its development and delivery.

The product may remain in use after the project ends. Consider operating and maintenance responsibilities when defining the undertaking.

Describe the intended benefit without inventing evidence. If a benefit remains a sponsor expectation, identify it as such.

Ask these questions:

1. What problem or opportunity motivates the work?
2. Who uses or is affected by the result?
3. Which outcome would address the need?
4. Which conditions constrain an acceptable solution?
5. What evidence will show that the outcome has been achieved?

Investigate alternatives before locking in an unexamined means. Compare them against the same purpose, requirements, operating conditions, and resource constraints.

Alternatives can include modification, replacement, staged work, or a different operating arrangement. Their technical and legal acceptability must be established.

Where the sponsor has already adopted a solution boundary, preserve it. Propose a change through the applicable decision process if evidence justifies reconsideration.

Record reasons for consequential choices. A later participant needs to understand why an attractive alternative was rejected under the original conditions.

Lesson 2 — Assemble the project basis

The project basis identifies the purpose, requirements, scope, constraints, and decisions used to develop and execute the project.

An organization may carry this information in several controlled documents. Their relationships must remain clear to the people who use them.

Include enough information to govern the next work. Extra detail has little value when no decision or activity uses it.

Organize the basis around these subjects:

• Intended result, users, and operating activity.
• Applicable requirements and identified governing sources.
• Included scope and assignment boundaries.
• Existing assets and interfaces to preserve or modify.
• Budget, delivery target, and other constraints.
• Acceptance responsibilities and proposed examination.
• Unresolved inputs and their treatment.

Identify the revision and status of each governing source. Explain whether a newer record supplements, replaces, or merely proposes to change the basis.

Distinguish existing obligations, proposed interpretations, and proposed new project constraints. A supported interpretation can explain an obligation that already governs. The obligation does not await sponsor adoption. A new project constraint requires the appropriate decision.

Reconcile conflicting sources at the relevant subject. Do not solve a discrepancy by deleting the record that exposes it.

Before requesting acceptance, read the basis as a whole. Check for incompatible assumptions, missing boundaries, unclear terms, and unsupported commitments.

Identify exactly which document revision the decision concerns. Record any conditions on proceeding and the work they affect.

Lesson 3 — Make requirements and examination usable

A requirement states a needed result or constraint. It must preserve the conditions that give the statement meaning.

Specify the subject, required result, relevant conditions, source, and status. Separate independently allocatable obligations where that improves responsibility.

For example, one statement can define a transfer-flow outcome. Another can define standby behavior. Their shared operating conditions remain connected.

Avoid turning an unresolved input into a convenient design value. Assign work to establish it before the dependent decision.

Develop the examination alongside the requirement. Ask what observation, analysis, inspection, or test could establish its satisfaction.

Use this relationship:

Requirement → contribution → examination → evidence → authorized decision

The examination must address the full claim. A normal-flow observation would leave required changeover behavior unexamined.

A requirement can be approved while its detailed examination remains in development. Identify who will complete the method before its point of need.

Use this compact requirement record:

Do not fabricate test tolerances, code clauses, or acceptance thresholds. Missing definitions require competent development and the appropriate decision.

Lesson 4 — Divide work without dividing away responsibility

Decomposition divides the undertaking into manageable contributions. Its purpose is complete responsibility and usable exchanges between contributors.

Choose boundaries around related work that someone can understand and carry through. Compare the cost of coordination across alternative boundaries.

Preserve discipline responsibility where it applies. Identify the person who coordinates the combined technical result across those discipline contributions.

Give each obligation one accountable home. Several people may contribute to it. Their inputs and interfaces must remain explicit.

That home coordinates fulfillment. It does not erase the duties of contributors, reviewers, or other appointed authorities.

Do not allocate the same whole obligation to two groups without explaining their distinct contributions. This can conceal both duplication and gaps.

For each deliverable, state:

1. Its purpose and required result.
2. Its governing requirements and inputs.
3. Its receiving participants and interfaces.
4. Its producer and required review.
5. Its examination and evidence.

A deliverable title alone gives insufficient direction. “Electrical package” does not identify what it must establish for procurement or installation.

Read the division in both directions. Follow each requirement to its contributions. Follow each contribution back to its source obligation or justified project need.

Then examine the boundaries. Determine who supplies shared inputs, who resolves differences, and who assembles the whole.

Separate work allocation from work satisfaction. An assigned deliverable remains to be produced and examined.

Lesson 5 — Establish readiness and the treatment of open matters

Projects often begin development with unresolved conditions. The basis must show which work can proceed and which work depends on resolution.

Give each open matter an owner, required resolution, affected decision, and point of need. Record its current evidence and any authorized interim assumption.

An assumed value can support a bounded study if its status and limits are explicit. It cannot silently become a procurement requirement.

State readiness for a specific activity. “Ready for investigation” differs from “ready for equipment order release”.

Check readiness with these questions:

1. Which result or act is being authorized?
2. Which conditions does it require?
3. What evidence establishes those conditions?
4. Which unresolved matters can remain under stated limits?
5. Who has authority to decide?

A pending external requirement may limit several technical choices. Other authorized information gathering can continue.

An exclusion also needs careful treatment. If another party supplies a required act, identify that party and the interface the project still needs.

Do not remove an obligation by placing it outside one contributor's scope. Determine where responsibility for it continues.

After acceptance, communicate the basis to its users. Follow later changes through the requirements, assignments, interfaces, and examination they affect.

Worked example — Define Northbank's purchase preparation

A02 Rev 1 establishes 18 litres per second, two pump units, tank reuse, and associated work. It also identifies unresolved hydraulic conditions.

A01 distinguishes sponsor scope authority from project and discipline engineering responsibilities. B02 shows that procurement still needs an authorized purchase package.

The project engineer prepares a definition for purchase preparation. Its purpose is to establish a technically reviewed, identified equipment requirement before order release.

The mechanical contribution must establish the operating envelope and selected equipment basis. It needs operating information and relevant electrical motor conditions.

The electrical contribution must assess the existing supply and the selected motor arrangement. A04 supplies one checked observation while leaving important checks open.

The controls contribution needs the changeover definition and alarm response. The civil contribution needs equipment loads, base dimensions, and access requirements.

The project engineer gives coordination of these exchanges an explicit home. Each discipline retains responsibility for its contribution.

The supplier submission requires correction and additional evidence before it can support technical acceptance. No corrected pump or motor is invented in the definition.

A05 remains a proposed scope change. Its impact assessment receives a separate assignment and returns to the sponsor for the scope decision.

The definition records A06's unresolved external requirements. It identifies dependent technical choices instead of asserting legal applicability.

The proposed division allows source retrieval, operating clarification, commercial inquiry, and technical assessment to proceed. Order release remains dependent on its required conditions.

Transfer example — A data acquisition upgrade

A plant wants better fault diagnosis. A team proposes new sensors but has not defined the events operators need to recognize.

The project basis must establish those intended uses and operating conditions. Sensor selection and acceptance then have a common purpose and examination basis.

Practice — Repair a weak assignment

Treat this sentence as an exercise draft:

Supply pumps quickly. Electrical will make them work. Operations can add the future flow requirement later.

Use A01 to A06 and B01 to B03. Identify the missing purpose, requirements, conditions, responsibilities, interfaces, and examination.

Replace the sentence with a bounded assignment for preparing the equipment requirement. Keep detailed technical inputs unresolved where the case leaves them unresolved.

Prepare an interface table with suppliers, consumers, required contributions, owners, and points of need. Label proposed ownership assignments as proposals.

Knowledge check

1. How do the product and project differ?
2. Which subjects must a usable project basis establish?
3. Why must a requirement retain its qualifying operating conditions?
4. How can several contributors fulfill an obligation with one accountable home?
5. What distinguishes work allocation from work satisfaction?
6. What must be stated before unresolved information can remain open during dependent work?

Portfolio continuation and references

Keep the repaired assignment, project basis, requirement table, and scope allocation. Link them to your earlier sources and decisions.

Carry these records into Course 08 for planning. Use their interfaces and readiness conditions in Course 09.

Source adaptation: Field Book §§3–4 and Consolidated v8 §§2.1–2.7 and 3.1–3.7. These sections address basis, scope, outputs, and examination.

Use the shared references for systems engineering fundamentals and project governance. External readings are optional for the supplied assignment.

Assessed assignment — Prepare a coherent project definition

Prepare a proposed Northbank project basis using Packets A and B. Preserve all approved A02 commitments and their identified limits.

Include a requirement table, deliverable allocation, interface table, and open-matter treatment. Explain one alternative division of work and its coordination consequences.

Include A05's impact assessment as proposed-change work. State the route for its scope decision without treating the proposal as adopted.

Present the definition to a peer or mentor. Check coverage in both directions and repair identified gaps.

The instructor assesses these five observable criteria:

1. The basis preserves source identities, approved scope, constraints, and proposed-change status.
2. Requirements retain their conditions and identify suitable examination or its missing definition.
3. The work allocation gives each obligation an accountable home and covers the complete accepted scope.
4. Interfaces identify contributions, proposed owners, points of need, and coordination responsibility.
5. Open matters identify resolution, authority, and the specific work they limit without invented technical or legal conclusions.