Projects are composed of three fundamental elements. Cost, Schedule, and Technical outcomes. The *Technical Outcomes* go far beyond the PMI-style *scope* terms. In this paradigm, the technical outcomes are at the end of a chain. Here's examples of that chain - Capabilities, Measures of Effectiveness, Measures of Performance, Key Performance Parameters (there are 5 in our domain), and Technical Performance Measures. At the TPM level is where things like quality live, traceable to the KPPs.

These three elements are *coupled* in dynamic ways. Their connections are *springy*, in that changes in one has an impact on the other two, But rarely is this impact linear and ridgid. The *Iron Triangle* notion is really a *Three Body *problem, in which all three element impact each other and at the same time respond to that impact.

All projects have these three elements, coupled in this way. Changes in one impact the other two. Changes in two impact each other and the third. Without knowing the dynamics of cost, schedule, and technical performance, we can't have any credible understanding of these variables.

**Three Body Problem**

The three body problem determines the possible motions of three point masses *m*_{1}, *m*_{2}, and *m*_{3}, which attract each other according to Newton's law of inverse squares. It started with the perturbative studies of Newton himself on the inequalities of the lunar motion. In the 1740s there was a search for solutions (or at least approximate solutions) of a system of ordinary differential equations by the works of Euler, Clairaut and d'Alembert (with an explanation by Clairaut of the motion of the lunar apogee).

Developed further by Lagrange, Laplace, and their followers, the mathematical theory entered a new era at the end of the 19^{th} century with the works of Poincaré and since the 1950s with the development of computers. While the two-body problem is integrable and its solutions completely understood, solutions of the three-body problem (Java 7 in 64 bit Browser needed) may be of an arbitrary complexity and are very far from being completely understood.

The forces between the bodies can be *self attractive* or they can be a central force - the restrictive three body problem. Or a combination of the two. This is the basis of complex systems, where multiple forces are applied to objects, which in turn change the forces. As an aside, the double pendulum and the three body problem are used as examples of complex systems. Without acknowledging that the underlying mathematics is *deterministic* since the Java example above draws the lines from an algorithm.

This is a common mistake by those unable to *do the math, *or who want to suggest the problems of the day are beyond solution.

**Three Body Problem and Three Elements of Project Management**

The three body problem uses gravity as the force between the masses. There is a simpler example of three masses connected with three springs. This model is found in chemistry and biology, at the molecular level. Gravity is not in effect of course, but electromagnetic force.

Consider a simplified model for the vibrations of an ozone molecule consisting of three equal oxygen atoms. The atoms are represented by three equal point masses in equilibrium positions at the vertices of an equilateral triangle. They are connected by equal springs of constant *k* that lie along the arcs of the circle circumscribing the triangle. Mass points and springs are constrained to move on the circle, so that, e.g., the potential energy of a spring is determined by the arc length covered.

These class of problems are called *soft body dynamics*. The visible outcome is the rendering of graphical objects that are flexible in movies and games - like three dimensional garments.

**Now to Projects**

If we assume for the moment that cost, schedule, and technical performance are dynamic variables, with *forces* between them described by their functional equations. In our functional equations for the force between them ar not constant, but are relationships like this:

is a function of**Cost**- Time is money in this case.**schedule**is a function of**Schedule**- We can buy time, shorten schedule, but at what cost?**cost**is a function of**Cost**- Want to got fast? How much will that cost?**technical performance**is a function of**Cost**- This is not a 1:1 exchange for the schedule question.**schedule**as a function of**Technical performance**- What can we afford to do?**cost**as a function of**Technical performance**- When can we have fast?**schedule**

The interaction between the three core elements (cost, schedule, technical) is a two way interaction, so the spring analogy is not quite correct, since the spring force doesn't know which end it is pushing or pulling.

**The Point**

It's not the *Iron Triangle,* it's a springy triangle. The connections are non-linear and most importantly they are probabilistically driven by the underlying statistical processes of the project. Let's start with the picture below.

All project processes are *probabilistic*. They have behaviours that are not fixed. The notion that you can *slice* work into same sized *chunks* and execute these chunks with the same effort would violate the basic *aleatory* uncertainties of all work processes. With an understanding of the statistical processes, driven by either *aleatory* or *epsitemic* uncertainties, is followed by asking probabilistic questions. *What's the probability that we'll complete on or before a date* or *what's the probability we'll compete at or below a cost.*

With a probability and statistics foundation, we can now put together a credible plan, driven by the underlying stochastic. All work is connected in dependent ways. The work effort, it's duration, and outcomes is also statistically driven. This picture is typical of such a project.

**In The End**

- We need to know all three properties.
- We need to know the underlying statistical behaviours. If not go find out or pick a
*reference class*. - We need to speak about confidence intervals, not deterministic value (single point values).
- We need to know something about cost. If you don't you can't know value or ROI. It's that simple. It's basic financial management.

So we can:

- Learn to estimate.
- Understand that those with the money need to know how much money and when to release that money.
- Those waiting for the
*value*need to know when they will receive that value. - Those consuming other peoples money, to produce that value, need to have some notion of how time, money, and production of value take place outside their narrow world of
*it's all about me*.