Pooyan: Restored from 2017 RiskWiki archive (Wayback).

2025-11-29T23:04:55Z

Restored from 2017 RiskWiki archive (Wayback).

New page

'''This page is under construction…'''

''See also: [[Performance_Management_Systems_(PMSs)]], [[Project_Execution]], [[Management_plans_and_sub-plans]].''

== Basic considerations ==

There is increasing recognition that '''management control''' and '''management control systems (MCS)''' need more coherent theoretical foundations if we want a systemic, non-piecemeal understanding of how control actually works in real organizations.<ref name="FerreiraOtley2009" />

Ferreira and Otley argue that our understanding of management control and MCSs will remain fragmented as long as we ignore the inter-dependencies between different control mechanisms operating simultaneously in the same organization. Their answer is a more holistic view in the form of a '''performance management and control (PMC) framework''', which integrates measurement, control, and learning rather than treating “controls” as just accounting artefacts.<ref name="FerreiraOtley2009" />

In a civil-engineering / project context, that distinction really matters: if you only see “control” as budget variances, you miss design controls, configuration controls, quality controls, procurement controls, and all the other technical control systems that actually govern whether a project can be delivered within constraints.

== Logical Framework ==

From an engineering perspective, you can think of management control as:

* A subset of the project organization’s overall '''Performance Management System (PMS)''' – the big umbrella of measurement, feedback, incentives, and learning; and
* A collection of more specific '''control systems''' (design, cost, schedule, quality, configuration, procurement, etc.) which together shape behaviour and outcomes.

A minimal logical framing:

# The organization (or project) has '''objectives''' – usually multiple, sometimes conflicting.
# There are '''activities and processes''' intended to achieve those objectives.
# There is some mechanism for '''measurement''' (of outputs, outcomes, and sometimes inputs).
# There are '''feedback and decision mechanisms''' that compare measured performance with objectives.
# There are '''interventions''' (changes in behaviour, resources, or structure) intended to reduce the gap.

In theory, that sounds clean. In practice, each step is politicized, fragmented, and distributed across different professional silos — and that’s exactly why the naive “thermostat” metaphor for control often fails.

== Research frameworks in Academic media ==

Measurement of '''performance''' has long been a concern across several disciplines. For risk engineering and civil engineering, two strands are particularly relevant:

* '''Management accounting / management control research'''
* '''Project management / project governance research'''

Most of the heavy theoretical lifting on “management control systems” comes from the first.

=== Management accounting research ===

Traditional management accounting research focused on '''financial performance''', typically using micro-economic or agency-theoretic models.<ref name="Otley1999" />

This did two problematic things:

* It gave relatively little guidance to '''designers''' of control systems (engineers, project managers, systems designers), and
* It implicitly equated “management control” with “management accounting”, at the very moment when classic cost accounting was being widely criticized as obsolete.

The result: a lot of sophisticated work on accounting techniques, but much less on the '''overall control architecture''' of organizations.

More recent work shifts from:

* “How do we '''measure''' performance?”
**to**
* “How do we '''manage''' performance?” – acknowledging performance is multi-dimensional, ambiguous, and context-dependent.

==== Cybernetic Model for Management Controls ====

A huge amount of control theory in management is built on a cybernetic model: negative feedback loops.

Hofstede characterises a standard cybernetic control process as consisting of five steps:<ref name="Hofstede1978" />

# Set goals or standards.
# Measure actual accomplishment (output or work performed).
# Compare measured performance to goals.
# Identify and analyse '''variances'''.
# Feed variance information back into the process and intervene to correct the deviations.

The thermostat metaphor: a simple, closed control loop.

Hofstede points out that this model rests on a set of strong assumptions:

* There is a '''defined and documented process''' with identifiable boundaries that corresponds to effective and efficient accomplishment of objectives.
* Actual accomplishment can be '''measured''' and compared to those objectives.
* Variances can be detected and analysed in a meaningful way.
* Variance information can be communicated in a timely, intelligible way across specialist boundaries.
* Actors are sufficiently '''trained and motivated''' to act on that information to change the process.

He questions whether these assumptions hold in real organizations, as opposed to electrical circuits — which is exactly why engineers need to be careful when importing cybernetic metaphors.

From an engineering governance perspective, Hofstede makes two important observations (adapted into a project context):

* Control processes are usually tied to '''functional specialisation''':
** Senior management (or sponsors) set high-level objectives and standards.
** Technical and support staff measure and compare performance.
** Different levels of management intervene – minor interventions at lower levels; major changes in core project variables (scope, time, cost) at higher levels.
* This separation means that the cybernetic loop is not a single device, but a chain of different professions, tools, and routines – all of which can fail in different ways.

He also notes:

* Cybernetic control works best in '''structured environments''' where processes and outputs are adequately determined.
* Completely determined processes make control trivial (and sometimes redundant), while completely undetermined environments make formal control “infeasible”.<ref name="Sutherland1975" />

==== Homeostatic Model for Management Controls ====

Hofstede contrasts the thermostat (cybernetic) with a '''homeostatic''' model: the living cell.

* In the homeostatic view, measurement, analysis, communication, and intervention are carried out within the '''same professional group''' (where feasible).
* Standards may still be set “outside”, but the self-regulating capacity resides in the unit.

He writes that a homeostatic system:

> “is equipped with internal processes capable of maintaining an equilibrium (self-regulating) in a changing environment, provided that the environmental conditions stay within certain norms.”<ref name="Hofstede1978" />

The downside: homeostatic systems are more vulnerable than simple cybernetic devices – they have to grow, adapt, and can deteriorate; they can’t just be “swapped out like a thermostat”.

For civil engineering, the analogy is intuitive:

* Some control systems are engineered gadgets (e.g. numerical acceptance criteria in a design code).
* Others are living practices – a design review culture, a safety culture, a project-controls team.

=== Control Frameworks ===

Control '''frameworks''' help:

* Structure theory-building,
* Integrate disparate findings,
* Provide a language for practitioners to describe their systems.

Otley (1999) proposes a now-classic performance-management framework built around five questions:<ref name="Otley1999" />

# What are the key organizational objectives?
# What strategies and plans are adopted to achieve them?
# How is performance measured and evaluated?
# What rewards and incentives are attached to performance?
# What information flows provide feedback and enable learning?

Ferreira & Otley (2009) extend this into a broader '''Performance Management and Control (PMC) framework''' – explicitly designed as a research and diagnostic tool for describing MCS design and use.<ref name="FerreiraOtley2009" />

=== Control System Environments ===

Hofstede, citing Sutherland (1975), points out that many organizational environments are too stochastic or politically fluid to support a textbook cybernetic control system.<ref name="Sutherland1975" />

Three common modes of failure:

# **Objectives** are missing, unclear, or change in an uncontrolled way.
# **Work/accomplishment** is not measurable in a meaningful sense (or only via weak surrogates).
# **Feedback and intervention** fail – information is late, unintelligible, politically toxic, or actors are unwilling/unable to act.

Ferreira & Otley’s case study on the Portuguese Post Office (PPO) illustrates this in practice: targets are partly negotiated, partly imposed; lower-level managers have little influence on target-setting; and what is “controlled” is often as much a product of internal coalitions as of rational design.<ref name="FerreiraOtley2009" />

=== Types of Control Systems ===

Simons’ distinction (as used by Ferreira & Otley) between two system types is useful:<ref name="FerreiraOtley2009" />

* '''Diagnostic control systems (DCS)''' – used to monitor and correct performance against pre-set targets.
* '''Interactive control systems (ICS)''' – used by senior managers to focus organizational attention on strategic uncertainties, to foster learning, and to generate new strategies.

In practice, real performance-management architectures mix both:

* Budgets, KPIs, and variance reports used diagnostically;
* Strategic reviews, benchmarking exercises, and repeated dialogue used interactively.

=== Positive and Negative aspects of Management Controls ===

Controls are double-edged:

* Positively, they:
** Provide clarity about objectives,
** Reduce opportunism,
** Enable coordination across complex projects.
* Negatively, they:
** Can distort behaviour (gaming metrics, “hitting the target but missing the point”),
** Can suppress learning and dissent,
** Can hard-code bad assumptions if objectives are wrong.

A civil-engineering MCS has to be designed with both sides in mind.

== Regulatory Framework ==

The management-control literature intersects with regulatory frameworks where:

* Law or regulation impose minimum control architectures (e.g. internal control over financial reporting, safety management systems).
* Public-sector project sponsors (DOE, FTA, USACE, etc.) require documented management-control and performance-management systems as part of project governance.

RiskWiki’s purpose here is not to provide a current snapshot of any one agency’s policy, but to map “good practice” concepts that engineers can use as a reference point. Readers must always verify the latest versions of laws, regulations, and manuals directly from the issuing agencies.

== Practice Framework (Under construction) ==

''Work in progress – to be aligned with the PMIBoK materials on “project controls” and with agency guidance (DOE, FTA, FRA, USACE, etc.).''

The PMBOK® Guide uses “management control” language in many places (contingency reserve, control accounts, management reserve, performance-measurement baseline), but does not define “performance” or “management control” as such. In civil-engineering practice, project controls usually blend:

* Engineering control systems (design, quality, configuration),
* Project-controls systems (cost, schedule, risk),
* Governance and internal-control structures.

A genuine MCS has to integrate these, not treat them as siloed.

== Further Guidance ==

In an engineering context, the primary benefit of designing an explicit MCS is:

* To increase the likelihood that the project actually delivers the required outcomes,
* And to make explicit which mix of controls (technical, financial, organizational, cultural) is being relied upon.

Engineering controls are not just accounting controls; they share some DNA but operate on different objects (design artefacts, physical work, safety margins, risk registers).

== Beneficial Outcomes ==

A well-designed management-control system for civil-engineering projects should enable:

* Better alignment between sponsor objectives and project-team behaviour.
* Earlier detection of deviations in core variables (scope, time, cost, quality, risk).
* More disciplined learning and adaptation over the project’s life cycle.
* Greater transparency for regulators, sponsors, and the public.

Ferreira & Otley’s PMC framework is one way of structuring these issues; the aim is to move beyond ad-hoc collections of tools towards coherent control architecture.

== Working definition of the term ==

; Management control
: ''Management control'' is a subset of the project organization’s [[Performance_Management_Systems_(PMSs)|performance management system]]. It consists of the evolving formal and informal processes for:
:* conveying material objectives and goals,
:* assisting strategic, operational, and ongoing management through analysis, planning, measurement, and control,
:* and supporting and facilitating organizational learning and change.<ref name="FerreiraOtley2009" /><ref name="Otley1999" />

; Management Control Systems (MCS)
: A ''Management Control System (MCS)'' is the collection or package of management controls and control systems in use. Individual systems may be:
:* Engineering-specific (e.g. [[Design controls]], configuration management, quality control, procurement control),
:* Accounting-based (budgets, financial measures),
:* Administrative (organization structure, governance),
:* Social/cultural (values, norms, informal practices).

: Project organizations usually have many such controls. They are used, to varying degrees, to align the activities of individuals and teams with project goals, objectives, and constraints.<ref name="MalmiBrown2008" />

== Limitations of the definition ==

This working definition:

* Emphasizes design and integration, rather than just accounting techniques.
* Is still high-level; specific project-type and regulatory context will require tailoring.
* Assumes objectives can be articulated and measured with at least some clarity — which is often contested in public works and politically sensitive projects.

== See also ==

* [[Performance_Management_Systems_(PMSs)]]
* [[Management_plans_and_sub-plans]]
* [[Project_Execution]]
* [[Program_Management_in_Civil_Engineering]]
* Wikipedia: [https://en.wikipedia.org/wiki/Control_(management) Control (management)], [https://en.wikipedia.org/wiki/Management_control_system Management control system]
* Wikipedia: [https://en.wikipedia.org/wiki/Template:Systems_engineering Systems engineering elements] (template)

== Notes ==

''(This section can be used later if you wish to separate “Notes” from “References” using the <code><nowiki><references group="Note"/></nowiki></code> mechanism.)''

== References ==

* Ferreira, A., and D. Otley. “The design and use of performance management systems: An extended framework for analysis.” ''Management Accounting Research'' 20(4), 2009, pp. 263–282.
* Otley, D. “Performance management: a framework for management control systems research.” ''Management Accounting Research'' 10, 1999, pp. 363–382.
* Hofstede, G. “The poverty of management control philosophy.” ''Academy of Management Review'' 3(3), 1978, pp. 450–461.
* Sutherland, J. W. “System theoretic limits on the cybernetic paradigm.” ''Behavioral Science'' 20, 1975, pp. 191–200.
* Malmi, T., and D. A. Brown. “Management control systems as a package—opportunities, challenges and research directions.” ''Management Accounting Research'' 19, 2008, pp. 287–300.

<references />

Management control - Revision history

Pooyan: Restored from 2017 RiskWiki archive (Wayback).