MSE 100: Introduction to Management Engineering

Sources and References

Primary textbook — Peter Ostafichuk & Carol Jaeger, Introduction to Engineering: A Guide to Professional Practice in Canada (Oxford University Press). Supplementary texts — Clive Dym, Patrick Little, Elizabeth Orwin Engineering Design: A Project-Based Introduction; Frederick Hillier & Gerald Lieberman Introduction to Operations Research; Peter Senge The Fifth Discipline; Don Norman The Design of Everyday Things; Stephen P. Robbins & Timothy A. Judge Organizational Behavior. Online resources — MIT OCW 2.009 “Product Engineering Processes”; Professional Engineers Ontario practice guidelines.

Chapter 1 — What Is Management Engineering?

Management engineering is the discipline that applies engineering methods — modelling, measurement, optimization, and the scientific method — to the design and operation of human organizations, processes, and socio-technical systems. Where a mechanical engineer designs a gearbox and an electrical engineer designs a circuit, a management engineer designs the system that coordinates people, machines, information, and money so that the whole delivers value efficiently and effectively. The field descends from industrial engineering and operations research but sits closer to decision science, information systems, and organizational behaviour than to the classical hardware disciplines.

Two words capture the value proposition. Efficiency asks whether a system consumes the minimum feasible inputs per unit of output — cost per claim processed, kilowatt-hours per tonne of steel, minutes of nurse time per patient encounter. Effectiveness asks whether the system produces the outputs that actually matter: cured patients rather than completed forms, satisfied customers rather than shipped boxes. A system can be highly efficient at producing the wrong thing, so the two criteria must be reasoned about together. Ostafichuk and Jaeger frame the engineer’s job as “making decisions under constraints,” and the management engineer’s constraints are typically human, economic, and organizational rather than purely physical.

The practice rests on a small set of recurring activities: framing an ambiguous situation as a well-posed problem, modelling the cause-and-effect structure behind it, gathering and interpreting data, generating alternatives, choosing among them against explicit criteria, and implementing the chosen solution through other people. Each of these activities is the subject of a later chapter. Throughout, the management engineer plays three overlapping roles — analyst (builds the model), designer (creates the intervention), and change agent (persuades the organization to adopt it). None of the three is optional. A brilliant analysis that no one implements has produced zero improvement, which is the only unit of output the field ultimately cares about.

Chapter 2 — The Engineering Design Process

Engineering design is the activity of producing a plan or specification that, if executed, will cause a desired change in the world. Dym, Little, and Orwin define it as “a systematic, intelligent process in which designers generate, evaluate, and specify concepts for devices, systems, or processes whose form and function achieve clients’ objectives or users’ needs while satisfying a specified set of constraints.” The key ingredients are client objectives, user needs, functions, constraints, and form. Management engineers apply the same logic to process and organizational design, replacing “device” with “workflow” or “policy.”

A typical design process passes through five stages. Problem definition clarifies what is actually being asked for, surfaces stakeholders, and converts vague wishes into measurable objectives. Conceptual design generates many candidate approaches before committing to one, often through brainstorming, analogical search, and morphological charts. Preliminary design develops the most promising concept to the point where its feasibility and rough performance can be estimated. Detailed design fixes every parameter needed to build or deploy the solution. Design communication delivers the drawings, specifications, code, or standard operating procedures that allow others to implement the result. MIT 2.009’s “Product Engineering Processes” adds explicit milestones — sketch model, mock-up, assembly review, final review — that force teams to converge on tangible artifacts at each stage.

Design is iterative, not linear. Discoveries in any stage routinely send the team back to revise earlier decisions, and Dym warns that treating the five-stage diagram as a one-pass recipe is the single most common student mistake. Two habits reduce the cost of iteration. First, delay commitment: hold multiple concepts alive as long as possible so that killing one does not collapse the design space. Second, prototype early and cheaply; a cardboard mock-up or a paper process map exposes flaws before they are locked into detailed drawings. The designer’s job is not to be right the first time but to discover wrongness as quickly and cheaply as the schedule permits.

Chapter 3 — Problem Analysis and Framing

A well-framed problem is half-solved; a poorly framed one cannot be solved at all, because effort is wasted on the wrong target. Ostafichuk and Jaeger distinguish the problem statement (the symptom the client notices) from the design problem (the underlying need the engineer must address). A hospital complaining that “the emergency department is too slow” has stated a symptom. The design problem might be reducing door-to-doctor time, reducing length of stay, or redesigning triage — three very different projects.

Problem framing begins with stakeholder identification. Every system has users, owners, operators, regulators, and bystanders, and each group values different outcomes. A good framing lists them explicitly and records what each wants, what each fears, and what each controls. The engineer then converts these inputs into objectives (things to maximize or minimize), constraints (hard lines that must not be crossed), and functions (what the system must do). A pair-wise comparison or an objectives tree can impose structure on an initially messy list.

Two traps are common. The first is solution-driven framing, where the client has already chosen an answer (“build us an app”) and asks the engineer only to execute it; the engineer’s duty is to step back and ask what problem the proposed solution is supposed to solve, then check whether better alternatives exist. The second is narrow framing, where the problem boundary is drawn so tightly that the real cause lies outside it. A Toyota Production System maxim, “ask why five times,” pushes the boundary outward until the root cause appears. A useful final test is to write a one-sentence need statement of the form “design a [system] that [function] for [user] subject to [constraints].” If the sentence is not yet writable, the framing is not yet done.

Chapter 4 — Cause-and-Effect Analysis and the Ishikawa Diagram

Once a problem is framed, the next question is why it is happening. Cause-and-effect analysis is the disciplined search for the upstream factors that produce an observed effect. Without it, interventions target symptoms and fail to stick. Ishikawa Kaoru introduced the fishbone diagram at Kawasaki Steel in the 1960s as a visual aid for this search. The effect — the problem — is written at the head of the fish; the spine runs back from it, and major cause categories branch off as bones.

The classical categories for manufacturing are the 6 Ms: Man, Machine, Method, Material, Measurement, and Milieu (environment). Service and management settings often use the 4 Ps: People, Policies, Procedures, and Plant. Within each branch, sub-bones capture finer causes, and the exercise continues until the team can propose concrete tests or interventions. A warehouse with high picking errors might list “insufficient training” under People, “ambiguous bin labels” under Plant, “two-step verification removed last year” under Policies, and “fatigue on night shift” under People again. Repetition across branches is useful information — it signals an interaction effect.

Fishbone analysis pairs naturally with the 5 Whys technique popularized by Taiichi Ohno. Each candidate cause is interrogated by asking “why does that happen?” until the chain reaches something actionable. The discipline is important: stopping too early yields shallow fixes (“tell workers to be more careful”) while pushing too far yields philosophical non-causes. A good stopping rule is that the answer names something the organization can actually change within its authority and budget. The deliverable of a fishbone session is not the drawing itself but a short list of hypotheses, each testable with data, that the team will investigate next.

Chapter 5 — Risk Analysis

Risk is the combination of the likelihood that an undesired event occurs and the severity of its consequences if it does. Every engineering decision implies a risk posture, whether or not it is made explicit, and the professional obligation to “hold paramount the safety, health, and welfare of the public” requires engineers to reason about risk openly. Ostafichuk and Jaeger present risk management as a four-step loop: identify hazards, estimate likelihood and consequence, evaluate against tolerance thresholds, and control.

The workhorse tool is the risk matrix, a grid whose axes are likelihood (rare to almost certain) and consequence (negligible to catastrophic). Each identified hazard is plotted as a cell, and cells are colour-coded green, yellow, or red by policy. Red cells demand controls before the project proceeds; yellow cells require mitigation and monitoring; green cells are accepted. The matrix is crude — likelihoods and severities are usually estimates — but its value is forcing the conversation into the open and producing a ranked list.

More sophisticated methods include Failure Modes and Effects Analysis (FMEA), which for each component or step lists how it could fail, what the effect would be, how likely the failure is, how severe, and how detectable, then multiplies the three ratings into a risk priority number; and fault-tree analysis, which decomposes a top event into AND/OR combinations of underlying failures and lets the analyst compute probabilities from component data. The control hierarchy is also standard: eliminate the hazard if possible, substitute a safer alternative, engineer a physical barrier, add administrative controls (procedures, training), and only as a last resort rely on personal protective equipment. The hierarchy reflects that controls nearer the top are more reliable because they remove human vigilance from the loop.

Chapter 6 — Process Analysis and Flow Diagrams

A process is a sequence of steps that transforms inputs into outputs for a customer. Management engineering cares about processes because most organizational waste is not in any single step but in how the steps fit together. Process analysis makes the sequence visible so that rework, waiting, duplication, and handoff errors can be found and removed. The first tool is the flow diagram: boxes for activities, diamonds for decisions, arrows for flow, and swim lanes for the actors responsible. A good diagram is a shared map that lets the team argue about the territory rather than their memories of it.

Once the diagram exists, quantitative analysis follows. Cycle time is the average time for one unit to traverse the process. Throughput is the number of units completed per unit of time. Work-in-process (WIP) is the number of units inside the system at any moment. These three are linked by Little’s Law, WIP = Throughput × Cycle time, which holds for any stable system regardless of internal structure and is the most-used equation in operations analysis. The bottleneck is the resource with the lowest capacity; it alone determines system throughput, so improvements elsewhere produce no benefit until the bottleneck moves.

Lean thinking supplies a vocabulary for what to look for. The seven wastes — overproduction, waiting, transport, over-processing, inventory, motion, and defects — name the patterns that add cost without adding value for the customer. Value-stream mapping overlays the flow diagram with timing data, separating value-added time (the customer would pay for it) from non-value-added time (everything else). A typical office process has under five percent value-added time; the remaining ninety-five percent is opportunity. The deliverable of process analysis is a revised “to-be” map together with an implementation plan that gets the organization from the current state to the improved one.

Chapter 7 — Human-Computer Interaction and Prototyping

Most modern management systems reach their users through a screen, and the screen is where well-designed logic goes to die if the interface fights the user. Don Norman’s Design of Everyday Things supplies the core vocabulary. Affordances are properties that suggest how an object can be used (a flat plate affords pushing). Signifiers are perceivable cues that communicate affordances (an arrow, a label). Mappings are correspondences between controls and effects (the left stove knob should control the left burner). Feedback tells the user what the system is doing in response to an action. Constraints prevent impossible or dangerous actions before they happen. A good interface makes the right action obvious and the wrong action hard; a bad one blames the user for failing to read a manual.

Norman’s seven stages of action — goal, plan, specify, perform, perceive, interpret, compare — give designers a framework for asking where the user could get stuck. Each stage is a potential breakdown point: an unclear goal, a plan the system does not support, a button the user cannot find, a result the user cannot interpret. Usability testing traces real users through the stages to find the breakdowns before launch.

Prototyping is how interface ideas are tested cheaply. Low-fidelity prototypes — paper sketches, wireframes, clickable mock-ups in Figma — reveal structural problems (wrong information architecture, missing steps) at a stage when changes are free. High-fidelity prototypes add visual design and real data and expose subtler issues of typography, colour, and micro-interaction. The rule of thumb is to raise fidelity only when lower-fidelity testing has stopped yielding new findings. Five users typically uncover about 85 percent of usability problems, so small tests run often beat large tests run rarely. Generative AI tools now accelerate the earliest stages by producing first-draft wireframes and copy from a short brief, but the designer’s judgement about what to test, and on whom, remains the scarce input.

Chapter 8 — Economics for Engineers

Engineering decisions spend money, and money has both a price and a time dimension. The economics chapter of any introductory engineering text therefore begins with the time value of money: a dollar today is worth more than a dollar next year because today’s dollar can earn interest. The present value of an amount F received n years from now at interest rate i is P = F / (1+i)^n. Comparing alternatives that generate cash flows at different times requires discounting them all to a common date, usually the present, and summing. The result, net present value (NPV), is positive for projects worth undertaking and negative for projects that destroy value at the chosen cost of capital.

Microeconomics contributes the laws of supply and demand. Demand curves slope downward because buyers purchase less at higher prices; supply curves slope upward because sellers produce more. The intersection is the market-clearing price and quantity. Shifts in either curve — a new technology lowers supply cost, a tax shifts demand — move the equilibrium, and the engineer’s job is often to predict the direction and rough magnitude of such shifts. Elasticity measures the percentage change in quantity for a one-percent change in price; inelastic goods (insulin, electricity) tolerate price changes with little volume response, while elastic ones (restaurant meals) do not.

The concept most often abused is opportunity cost: the value of the next-best alternative forgone by choosing a particular option. Dollars already spent are sunk costs and should not influence future choices, although humans reliably let them. A project that will lose a further $100k to finish but generate $150k in remaining revenue should be completed even if $500k has already been spent, because the relevant question is only whether future benefits exceed future costs. Engineers are expected to perform this analysis cleanly even when the organization around them cannot.

Chapter 9 — Organizational Behaviour

People are the medium through which engineering solutions are implemented, and a solution the organization rejects is indistinguishable from no solution at all. Robbins and Judge organize organizational behaviour around three levels: the individual, the group, and the organization. At the individual level, motivation theories matter most. Herzberg separates hygiene factors (pay, supervision, conditions) whose absence produces dissatisfaction from motivators (achievement, recognition, growth) whose presence produces satisfaction; fixing hygiene without adding motivators yields neutral employees, not engaged ones. Self-determination theory identifies autonomy, competence, and relatedness as the psychological nutrients of sustained motivation, which is why top-down process redesigns that strip workers of autonomy typically under-deliver.

At the group level, Tuckman’s forming-storming-norming-performing model describes how teams develop, and Belbin and others have shown that balanced role coverage (coordinator, implementer, completer-finisher, plant, monitor-evaluator, resource-investigator) outperforms homogeneous brilliance. Groupthink, identified by Irving Janis, is the tendency of cohesive groups to suppress dissent and converge on bad decisions; counter-measures include explicit devil’s advocates, anonymous input, and decision rules that require surfacing alternatives before choosing.

At the organizational level, structure and culture shape what behaviour is rewarded and what is punished. A functional structure optimizes depth of expertise but slows cross-functional flow; a matrix structure speeds flow but creates two-boss ambiguity; a network structure outsources non-core work at the cost of coordination. Culture — “the way we do things around here” — is shaped by what leaders notice, reward, and punish, and changes slowly even when structures change overnight. For the management engineer, the lesson is that technical recommendations must be accompanied by a change-management plan that addresses incentives, communication, and the psychological safety workers need to adopt a new way of working.

Chapter 10 — Sustainability, Life-Cycle, and Systems Thinking

Sustainability is the constraint that a system’s operation must not compromise the ability of future generations to meet their needs. For engineers, this translates into decisions about energy, materials, emissions, and social impact across the whole life of a product or service, not just the slice for which they hold direct responsibility. Life-cycle assessment (LCA) is the standard method. It inventories inputs (materials, energy, water) and outputs (emissions, waste, heat) at every stage — raw-material extraction, manufacturing, distribution, use, end-of-life — and converts them into impact categories such as global-warming potential, acidification, or resource depletion. The method’s value is in preventing burden-shifting, where a change that looks green at one stage quietly increases impact at another.

Systems thinking, as developed by Peter Senge in The Fifth Discipline, supplies the mental model for understanding why sustainability problems resist point fixes. A system is a set of variables linked by feedback loops; the reinforcing loops amplify change (a growing market attracts more entrants which grows the market further), while balancing loops counteract it (high prices suppress demand which lowers prices). Delays in these loops create oscillation, and stocks that accumulate over time — carbon in the atmosphere, deferred maintenance in a factory — hide current imbalances until they become crises. Senge’s archetypes (shifting the burden, tragedy of the commons, limits to growth) are patterns that recur across industries and let the engineer recognize a familiar structure in a new domain.

The practical implication is leverage points. Donella Meadows listed twelve, ranked from weakest (adjusting parameters) to strongest (changing the goals and paradigm that generate the system). Most engineering interventions operate near the weak end, tuning flows and delays; the most durable improvements come from reframing what the system is for. A sustainable redesign therefore starts from goals and purposes, not from efficiency metrics, and asks whether the right things are being measured at all.

Chapter 11 — Simulation and the Beer Game

Some systems are too complex for closed-form analysis. Simulation builds a computational model of the system, runs it many times under controlled conditions, and observes emergent behaviour. Discrete-event simulation advances a clock from one event to the next — arrival, service, departure — and is the dominant tool for queueing, logistics, and service operations. Monte Carlo simulation samples random variables many times to estimate distributions of outcomes and is used for risk analysis and financial modelling. Agent-based simulation models individual actors with local rules and lets macro-behaviour emerge, as in traffic models or pedestrian flows.

The pedagogical classic is the Beer Distribution Game, developed at MIT in the 1960s and popularized by Senge. Four roles — retailer, wholesaler, distributor, factory — each face a simple task of ordering beer from the next stage upstream to meet customer demand. Shipping delays and ordering delays separate cause from effect by several weeks. A modest, one-time step up in end-customer demand reliably causes catastrophic oscillations upstream: distributors over-order, factories build inventory, and weeks later everyone is drowning in stock they cannot sell. Players consistently blame “the other stages” when the cause is the structure of the system itself — delays plus local optimization plus lack of information sharing.

The dice game, used in lean teaching, makes a complementary point: variability and dependence between stations jointly limit throughput. Four stations each with average capacity equal to demand will still under-produce because stochastic shortfalls cascade downstream while stochastic surpluses cannot. These simulations teach in hours what abstract theory conveys poorly — that local efficiency is not global efficiency, that delays destabilize control, and that information sharing and buffer design matter more than worker effort. A management engineer who has felt the Beer Game fail under their own hands rarely forgets the lesson.

Chapter 12 — Optimization and Operations Research

Operations research is the application of mathematical models to find the best decisions, and optimization is its central activity. Hillier and Lieberman present the canonical problem in the form: choose decision variables x to maximize (or minimize) an objective function f(x) subject to constraints g(x) \leq b. When f and g are linear and x is continuous, the problem is a linear program (LP), solvable at very large scale by the simplex method or interior-point algorithms. When some variables must be integer — how many trucks to buy, which facilities to open — the problem becomes a mixed-integer program, harder but still tractable for many industrial instances.

Classic applications recur across industries. The transportation problem ships goods from sources to destinations at minimum cost. The assignment problem matches workers to jobs one-to-one. The knapsack problem selects a subset of projects under a budget. The travelling-salesman problem finds the shortest tour visiting a set of cities. Each has a standard formulation and a standard solver; the engineering skill is recognizing which template applies to a real situation and translating messy reality into the template’s variables and constraints. Sensitivity analysis then asks how the optimal solution changes when inputs shift, which matters because inputs are estimates.

Beyond deterministic optimization, OR includes stochastic methods for systems with uncertainty (Markov decision processes, queueing theory), heuristics for problems too large for exact methods (genetic algorithms, simulated annealing, tabu search), and game theory for decisions against strategic opponents. The common thread is that the discipline insists on writing the problem down. A model that is wrong in known ways is usually more useful than an intuition whose errors are unexamined, because the model’s wrongness can be probed, the intuition’s cannot. Management engineers build the model, argue about its assumptions, solve it, and then ask what the solution teaches about the real problem.

Chapter 13 — Excel, VBA, and Spreadsheets for Engineers

Excel is the lingua franca of business analysis because it combines storage, calculation, and presentation in one file that any collaborator can open. For the management engineer, fluency is assumed. The building blocks are formulas (arithmetic, logical, lookup), named ranges that make formulas readable, and pivot tables that summarize long tabular data by dimensions without writing code. A well-built model separates inputs, calculations, and outputs onto different sheets, uses colour or cell styles to mark user-editable cells, and documents assumptions in-sheet so that a reviewer a year later can still reconstruct the logic.

Data analysis functions cover most introductory needs. SUMIFS, COUNTIFS, and AVERAGEIFS aggregate conditionally. VLOOKUP and the newer XLOOKUP join tables. INDEX/MATCH handles lookups VLOOKUP cannot. Statistical functions provide means, standard deviations, correlations, and percentiles. For relationships between variables, linear regression via LINEST or the Analysis ToolPak produces coefficients, R-squared, and standard errors; charting the residuals is the cheapest way to detect model misfit. The Solver add-in handles small optimization models directly in the workbook — a convenient on-ramp before moving to dedicated OR software.

VBA (Visual Basic for Applications) is Excel’s embedded programming language. It automates repetitive tasks — importing daily data files, reformatting reports, sending emails — and lets engineers build macros triggered by buttons, events, or keyboard shortcuts. Modern alternatives (Office Scripts, Python in Excel, Power Query) are replacing VBA for new work, but a large installed base means the language will outlive its obituaries. The deeper lesson is not any specific tool but a habit of mind: if a task is performed more than a handful of times, automating it pays back many times over and, more importantly, removes a class of human error from the process.

Chapter 14 — Engineering Ethics, Safety, and Legal Liability

An engineer is a licensed professional, and with the title come duties that ordinary technical competence does not discharge. The Canadian professional bodies — PEO in Ontario, APEGA in Alberta, and their counterparts — share a code of ethics whose first obligation is to “hold paramount the safety, health, and welfare of the public and the protection of the environment.” Other duties include acting as a faithful agent for clients and employers, disclosing conflicts of interest, maintaining competence, not signing work one has not reviewed, and reporting situations that endanger the public.

Ostafichuk and Jaeger classify ethical frameworks that engineers can use to reason through hard cases. Consequentialism evaluates choices by their outcomes — greatest good for the greatest number — and underlies cost-benefit analysis. Deontology evaluates by duties and rules regardless of consequences — tell the truth, keep promises, respect persons — and underlies professional codes. Virtue ethics asks what a person of good character would do. No single framework handles every dilemma; practical ethics uses all three as cross-checks. The Seven-Step Guide of Harris, Pritchard, and Rabins walks the engineer through stating the problem, checking the facts, identifying relevant ethical considerations, listing options, testing each against the frameworks, making a choice, and reflecting on what the case teaches.

Safety and legal liability are the enforceable layer on top of ethics. Negligence — failure to meet the standard of care — exposes engineers and their firms to civil liability; gross departures from the standard can trigger discipline, loss of licence, or criminal charges. Product liability extends the exposure to the design of consumer goods. The Professional Engineers Ontario guideline on human rights adds explicit obligations regarding discrimination, harassment, and accessibility in professional practice. The practical message for the student is that signing a drawing is a legal act, not a formality, and the signature means the signer accepts responsibility for the work and for any foreseeable harm it enables.

Chapter 15 — Communication and Professional Practice

The best analysis is useless if it cannot be communicated to the people who must act on it. Mike Markel’s Technical Communication frames every document or presentation around four questions: who is the audience, what do they need to know, what do they need to do with the information, and what is the medium that best delivers it. The discipline of answering these questions before writing prevents the most common failure — a technically correct report that buries the recommendation, assumes the wrong background, or targets the wrong decision.

Technical writing is genre-driven. A memo conveys a recommendation and its reasoning in one to two pages; the recommendation goes first, the reasoning second, the detail in an appendix. A formal report adds an executive summary, structured sections, and references, and is indexed for readers who will sample rather than read linearly. A proposal must persuade, not just inform, and foregrounds need, approach, qualifications, and cost. A slide deck supports a spoken presentation rather than replacing it; slides heavy with text are used poorly. A good rule is that every slide should survive the removal of the speaker — if no one would understand it without narration, it needs redesign.

Professional practice extends beyond documents. Engineers must manage their time, commit honestly to deadlines, handle disagreement without personalising it, and accept feedback as data rather than threat. Co-op placements and capstone projects are rehearsals for the workplace behaviours that distinguish competent juniors from brilliant but unmanageable ones: showing up prepared, asking clarifying questions early, acknowledging ignorance instead of faking expertise, and closing loops on commitments. Time management — calendar discipline, batching, and the Eisenhower urgent-versus-important grid — is the scaffolding on which the rest depends. The management engineer’s job is to improve how other people work; the first system to be improved is always one’s own.