Economics is a social science concerned chiefly with description and analysis of the production, distribution, and consumption of goods and services. Economics is the study of how people make decisions in resource-limited situations. Economics has two basis branches:
- Macroeconomics is the study of how people make decisions in resource-limited situations on a national or global scale. Macroeconomics deals with the effects of decisions that national leaders make on such issues as tax rates, interest rates, foreign and trade policy.
- Microeconomics is a branch of economics that studies the behavior of individuals and firms in making decisions regarding the allocation of scarce resources (time, money, facilities, and talent) and the interactions between individuals (inside and outside the firm) and firms themselves.
Microeconomics is applicable to the development is software systems. Macroeconomics is not.
If we look at the discipline of software engineering, we see that the microeconomics branch of economics deals more with the types of decisions we need to make as software engineers or managers.
Throughout the software life cycle, there are many decision situations involving limited resources in which software engineering economics techniques provide useful assistance.
Economic principles underlie the overall structure of the software lifecycle, and its primary refinements of prototyping, incremental development, and advancemanship.
The primary economic driver of the life-cycle structure is the significantly increasing cost of making a software change or fixing a software problem, as a function of the phase in which the change or fix is made.- Boehm, Barry W. "Software engineering economics." IEEE Transactions of Software Engineering, 1 (1984): 4-21.
By the way, the pure conjecture that agile enables late changing requirements to not have a significant impact on the cost and schedule of the development project is completely lacking any testable evidence outside of personal anecdotes of agile advocates. Take for example the deployment of an ERP system, the installation, and startup of a process control system, the release of a suite of embedded software controllers for a car, aircraft, petrochemical plant. Making changes late in the development cycle has significant impacts on the verification and validation of the system no matter the software development method.
When we hear about software development disasters and then hear that estimates are to blame, and NOT Estimating will somehow reduce or prevent these disasters, think again. A recent survey of 600 firms indicated that 35% of them had at least one "runaway' software project. Research clearly shows the root causes of most software projects cost and schedule overruns and technical shortfalls comes from poor risk management.
Most post-mortems of these software disaster projects have shown that their problems would have been avoided or strongly reduced if there had been an explicit early concern with identifying and resolving their high-risk elements. Frequently, these projects were swept along by a tide of optimistic enthusiasm during their early phases, which caused them to miss some clear signals of high-risk issues which proved to be the project's downfall later.
Enthusiasm for new software capabilities is a good thing. But it needs to be tempered with a concern for early identification and resolution of a project's high-risk elements, so that people can get these resolved early and then focus their enthusiasm and energy on the positive aspects of their software product.
Now To Risk Management
Cost and schedule growth for software development programs is created by unrealistic technical performance expectations, unrealistic cost and schedule estimates, inadequate risk assessments, unanticipated technical issues, and poorly performed and ineffective risk management, all contributing to program technical and programmatic shortfalls.
Risk is the effect of uncertainty of objectives. Uncertainty is a state or condition that involves a deficiency of information and leads to inadequate or incomplete knowledge of understanding. In the context of risk management, uncertainty exists whenever the knowledge or understanding of an event, consequence, or likelihood is inadequate or incomplete.
‒ ISO 31000:2009, ISO 17666:2016, and ISO 11231:2010
Risk is Uncertainty that Matters
Risk can be the potential consequence of a specific outcome that affects the system’s ability to meet cost, schedule, and/or technical objectives. Risk has three primary components:
- Probability of the activity or event occurring or not occurring, described by a Probability Distribution Function.
- Consequence or effect resulting from the activity or event occurring or not occurring, described by a Probability Distribution Function.
- Root Cause (condition and activity) of a future outcome, which when reduced or eliminated, will prevent the occurrence, non‒occurrence, or recurrence of the cause of the risk.
For the project manager, there are three risk categories that must be identified and handled. Each of the categories operates in the presence of uncertainty and requires that estimates be made about the probability, conseqeunce of the resutling risk. Amd of course, the Root Cause determined before any corrective or preventive action can be taken:
- Technical ‒ risks that may prevent the end item from performing as intended or not meeting performance expectations. Measures of Effectiveness, Measures of Performance, Technical Performance Measures, and Key Performance Parameters describe the measures of these expectations.
- Programmatic ‒ risks that affect the cost and schedule measures of the program. The programmatic risks are within the control or influence of the Program Management or Program Executive Office, through managerial actions applied to the work activities contained in the Integrated Master Schedule.
- Business ‒ risks that originate outside the program office or are not within the control or influence of the Program Manager or Program Executive Office.
All risk comes from Uncertainty. As stated numerous times before, Uncertainty comes in two forms. Ontological uncertanty is the thrid form, but not applicable here.
- Epistemic uncertainty ‒ from the Greek επιστηµη (episteme), meaning knowledge of uncertainty due to a lack of knowledge of quantities or processes of the system or the environment. Epistemic uncertainty is represented by the ranges of values for parameters, a range of workable models, the level of model detail, multiple expert interpretations, and statistical confidence. Epistemic uncertainty derives from a lack of knowledge about the appropriate value to use for a quantity that is assumed to have a fixed value in the context of a particular analysis. The accumulation of information and implementation of actions reduce epistemic uncertainty to eliminate or reduce the likelihood and/or impact of risk. This uncertainty is modeled as a subjective assessment of the probability of our knowledge and the probability of occurrence of an undesirable event.
- Aleatory uncertainty ‒ from the Latin alea (a single die in Latin) is the inherent variation associated with a physical system or the environment. Aleatory uncertainty arises from an inherent randomness, natural stochasticity, environmental or structural variation across space and time in the properties or behavior of the system under study. The accumulation of more data or additional information cannot reduce aleatory uncertainty. This uncertainty is modeled as a stochastic process of an inherently random physical model. The projected impact of the risk produced by Aleatory uncertainty can be managed through cost, schedule, and/or technical margin.
Separating the types of uncertainty serves to increase the clarity of risk communication, making it clear which type of uncertainty can be reduced and which types cannot be reduced. For the latter (irreducible risk), only margin can be used to protect the program from the uncertainty.
Risk Management is How Adults Manage Projects - Tim Lister
Uncertainty, creates risk. The management of risk means good project management. Managing in the presence of uncertainty requires we make estimates and act accordingly to the results of these estimates.
If we're going to manage as adults, we're going to have to Estimate. It's as simple as that.
Some Resources for Learning How to Manage Software Development in the Presence of Uncertainty
So no more excuses for not understanding how uncertainty creates risk, how risk management mandates estimating, and how no credible decision can be made on non-trivial projects without managing the risk created by those decisions, and the estimating processes needed to support those decisions.
Here's a list of Risk Management resources updated frequently