Management plans and sub-plans
This page is under construction ...
See also Project Execution, Project Development, Project Definition, Project Life Cycle and Phase Models, Project Delivery Methods.
See also Program Management in Civil Engineering, Civil Engineering Projects, Project Management ...
Article Overview
It is important to note that the purpose of this article is **not** to render a current and fully accurate characterization of the regulatory framework for any particular Federal agency. The purpose of this article is to serve as a source of information on good practices and as a resource to engineering professionals.
Readers should be aware that agency practices evolve over time; the information presented here represents a “snapshot in time” for a particular agency and possibly a specific program.
Again, please note our site terms of use. Even though this site may characterize and analyze government-agency policy and practices in conformance with our guidelines, users are reminded that RiskWiki is **not** an official government site.
- If you are in need of engineering advice, seek individual engineer advice and DO NOT rely on RiskWiki. RiskWiki IS NOT YOUR ENGINEER.
- Similarly, if you are in need of legal advice, seek individual attorney advice and DO NOT rely on RiskWiki. RiskWiki IS NOT YOUR LAWYER.
Basic considerations
Process, as documented in management plans, plays a pivotal role in both ASCE’s and PMI’s Bodies of Knowledge, and in civil-engineering practice.
Semantic, Epistemic and Logical frameworks
(Under Construction)
The semantic, epistemic and logical frameworks for the concept of **process** in civil-engineering projects have several dimensions. Problems often arise from interchangeable usages or lack of definition. Examples include:
- lack of clear distinction between “artifact” and “model”,
- interchangeable use of function / process / workflow / procedure / routine,
- lack of definition around process diagrams, maps and models, layers / levels.
Semantic framework
The most important semantic issue is the definition of **process** itself – particularly:
- process vs system vs model, and
- process vs procedure.
- Process
Process is often defined as having **inputs, outputs**, and the **energy** required to transform or “work” those inputs into outputs. The concept of work implies a passage of time, so a process takes real time to perform its associated action. The process also requires space for input/output objects and transforming objects to exist; therefore it requires real space.
Other authors describe a process as a set of structured tasks that result in specific services or products to meet certain goals for a particular set of actors.
The traditional view is the IPO (input–process–output) approach. Process-modelling languages are often grouped into categories such as:
- transformational
- conversational
- role-oriented
- constraint-based
- system-dynamics–oriented
Civil-engineering processes are typically executed in an organizational context. A critical factor in discussing process is the **state** of the process:
- the current state (a descriptive or “as-is” model), and
- a prescriptive or predictive future state.
- Process vs System
A **system** differs from a process in that systems provide the **context** in which every process can be described and analysed.
From this follow several important properties for processes in civil-engineering projects:
Process set membership
Process set membership refers to the ability to control participation in process activities and, ultimately, changes of state for individual variables. There must be at least one potential process element that is effectively excluded by process documentation throughout the process-execution life cycle.
- As project complexity increases, the process’s ability to control its set membership is “loaded and deforms” (in a structural-analogy sense).
- Inability to control set membership for **control processes** can lead to failure under such loading.
- This has serious implications for any project-control strategy and solution.
Projects as unique process sets
Both PMI and ISO identify projects in terms of processes. In a civil-engineering context this can be interpreted as a second network (parallel to the schedule time network with critical paths).
- In the simplest case, a project may be represented by a single process.
- As complexity increases, additional processes are added.
This raises questions such as:
- How do process elements achieve “end-to-end” hookups?
- Can we implicitly assume that all process outputs always match all required successor inputs?
- What about periods where one activity has a break before execution of the successor (schedule “float”)?
In the simplest case, there is a one-to-one mapping between any arbitrary project activity and its associated process. As complexity increases, the relationship tends towards a many-to-many architecture.
- This likewise has serious implications for any project-control strategy and solution.
Process interfaces
Process interfaces require **input and output acceptance criteria**. Matching up output states (“as-executed”) to input requirements (“as-is”) requires verification – itself a process.
Process constants and variables
- **Process constants** are process elements, properties or characteristics that do not vary over process execution.
- Any process element that does vary over execution is a **process variable**.
Any process variance or non-variance associated with a project material state should be identified, documented and communicated at appropriate times.
Process state
State plays a critical role in the concept of civil-engineering process:
- ordinary usage treats the concept of process as if it had a single “state”,
- but the concept may cover many variables, each with its own state.
The process may change all variables within a framework of variables and constants. In civil-engineering processes, models (formalized concepts) use several project variables (scope, cost, etc.).
- Outputs, outcomes, products, deliverables
Output states are fundamental end-points of any arbitrary process. In transitioning from “as-is” to “as-executed”:
- project variables change state (time, cost, resources, etc.),
- complete knowledge of all variable state changes is impossible and inherently uncertain.
We can distinguish:
- **Outcomes** – a subset of all output states that can be identified, documented and verified using civil-engineering knowledge.
- **Products** – a subset of outcomes that, regardless of execution context, can be formally described and communicated using civil-engineering knowledge.
- **Deliverables** – a subset of products produced in a specialized execution context and formally described and communicated using contracting techniques and civil-engineering knowledge. Deliverables often function as contractual or chartered milestones representing specific types and amounts of work to be “delivered”.
Deliverables are also important communications with clients. They create spaces in which teams and clients can negotiate, adjust, and mediate their diverse perspectives and understandings, and are often “the space in which consulting actually takes place”.
- Deliverables play a key role in the learning and collaborating processes at the heart of project work itself.
Process equilibrium, stability and instability
A process can be said to be in **equilibrium** when a condition of balance exists between opposing work efforts. For a generalized notion of process, any concept of equilibrium is meaningful only within a framework of constraints and over time.
- A fully “equilibrious” process (completely recoverable state, no residual effects) is a theoretical ideal and does not exist in real projects.
- In practice, process constituents may be disturbed and then either able or unable to recover their predecessor state.
- Stability** refers to a process’s ability to recover, at least partially, to a predecessor state after disturbance.
- Stable processes resemble structural elements undergoing elastic bending: when loading is removed, the system recovers sufficiently to be considered serviceable.
- Instability corresponds to exceeding elastic limits – plastic deformation of processes that propagates or cascades through other processes.
- Process stability (and the avoidance of cascading failures) is a key element of civil-engineering knowledge and has serious implications for any project-control strategy and solution.
Process control
Stable processes are a subset of all processes. Civil-engineering practice requires:
- understanding process stability, and
- increasing reliability in handling disturbances, detecting material variations, intervening later in execution, and recovering more of the predecessor state with fewer resources.
This leads to a further partitioning into **control processes** – those that can be documented and deliver reliably and predictably.
- A core skill is the ability to identify material variable states and plan process-variable state changes that occur reliably and predictably.
- In this sense, “process variables” are congruent with “core” project variables (scope, cost, schedule, risk).
The ideal civil-engineering process:
- tightly controls its set membership,
- executes repeatedly with core-variable state changes that are detectable and within predicted ranges,
- localizes changes to selected variables with minimal cascading into dependent processes.
This is the conceptual basis for **process** as a fundamental element of **management controls**.
Process models
A **process model** is a semantically closed abstraction of a process – a model of how the process behaves, under what assumptions, and with what inputs/outputs.
Key properties:
- Multiple, semantically equivalent views (different disciplinary perspectives) that remain consistent and compatible.
- Decomposition into successive sub-model layers that remain logically and functionally equivalent in aggregate.
- Documentation of state changes, resource consumption, assumptions and dependencies.
- Restricted application domain – good engineering models tightly constrain their interpretation to avoid ambiguous or non-functional outcomes.
Process architecture, artifacts, patterns, and documentation
- **Process architecture** – a set of critical decisions about the structure, components, relationships and properties of the process model. These decisions constrain how processes aggregate into larger systems and decompose into sub-processes.
- **Artifacts** – any information created, produced, changed or used as part of project execution; the most important artifact is often the process model itself.
- **Patterns** – reusable generic components or configurations in process architectures, capturing previous solutions to common problems.
- **Process documentation** – explicit and implicit documentation (formal and informal) providing organizational memory and reference baselines.
- Process formality** ranges from fully formal (“white-box”) to fully informal (“black-box”), with many “grey-box” states in between.
Process meta-knowledge and layers
- Process meta-knowledge** – knowledge about processes (rather than within a process) – allows statements about:
- how processes aggregate and decompose,
- how they form chains and networks, and
- how components align and function.
Civil engineers rely on professionally validated meta-knowledge to assume that processes can be decomposed and aggregated in ways that remain meaningful and controllable.
- Layers** are patterns where components are grouped at similar levels of generality and stability. In civil engineering, the analogue of layer is often **level**.
Examples:
- Upper layers: discipline knowledge (ASCE BOK), practice documentation, artifact libraries.
- Intermediate layers: project-level processes, geographic / functional layers, contract layers.
- Lower layers: work-package level processes, down to the smallest units of execution.
- Layers are not the same thing as increments or iterations.
- Workflow** in software engineering is often treated as the “executed” instance of a documented process. PMI barely uses the term; ASCE BOK almost not at all. For RiskWiki, workflow can be thought of as a realized execution path through a defined process.
Epistemic framework
No epistemic issues are analysed in detail in this article; rather, the focus is on definitions and logical structure.
Logical framework
The logical framework for civil-engineering processes has several key concepts:
- Projects are sets of processes. ISO and PMI each define process families.
- Project management is the application of knowledge to project activities using processes adapted for creating deliverables.
- Organisations must identify the external and internal factors (positive and negative) that are relevant to their context and that can affect their ability to achieve the intended outcomes of their management systems.
- The overall objective of the civil-engineering approach to project processes is to develop solutions that support delivering projects reliably and predictably.
Practice frameworks in Processes
Policy Framework
A number of U.S. Federal agencies require a **Project Management Plan (PMP)** for their major capital projects, including:
- Federal Transit Administration (FTA)
- Federal Railroad Administration (FRA)
- U.S. Army Corps of Engineers (USACE)
- U.S. Department of Energy (DOE), etc.
This section discusses selected agencies and their approach to project management using PMPs. Again, agency practices evolve over time and information here represents a snapshot in time.
Examples:
- Federal Transit Administration – New Starts Program
- FRA’s Intercity Passenger Rail Service authorizations under Public Law 110–432 (see FRA / PRIIA references)
Further Guidance
(Under construction.)
Beneficial Outcomes
(Under construction.)
Working definition of the term
(Under construction.)
Limitations of the definition
(Under construction.)
See also
Related Wikipedia articles:
Notes
(Under construction.)
References
- Introduction to Business Process Management, Alan McSweeney, 2010. Based on the Association of Business Process Management Professionals (ABPMP) BPM Common Body of Knowledge.
- Krogstie, John. "Perspectives to process modeling." in Business Process Management, Springer, 2013.
- Carlsen, Steinar. "Action port model: A mixed paradigm conceptual workflow modeling language." Cooperative Information Systems, 3rd IFCIS Int’l Conference, 1998.
- De, Robert. Linguistic Theory: The Discourse of Fundamental Works. Routledge, 2014. (Discussion of systems and context.)
- Rogers, Priscilla, Lisa Pawlik, and Barbara Shwom. "The Role of Deliverables in Project Work." Ross School of Business Paper 1267 (2015).
- OED Online, entries for “equilibrium”, “work”, “stability”, Oxford University Press, 2016.
- Tarski, Alfred – work on semantic closure.
- Medić, S., Karlović, B., & Cindrić, Z. "New Standard ISO 9001:2015 and its effect on organisations." Interdisciplinary Description of Complex Systems, 14(2), 2016.
- Public Law 110–432 (PRIIA), 16 Oct 2008, 122 Stat. 4935.