There was a recent suggestion to "melt down our iron triangle" in pursuit of agile project management. Although I'd probably concur there are some systemic problems with defining the triangle in the absence of a context, I've started using three other veritice points for the triangle
- Cost
- Schedule
- Technical Performance Measures
Technical performance could be seen as machine or software performance, but is better seen as product performance. Technical Performance is a parametric view of a product like weight, temperature, stiffness, projectile impact resistance, transaction throughput, or continuous running time. The trade off in the triangle is the measure of the technical performance against Cost and Schedule.
If we're seeking a target weight (lower the weight the better) as an independent variable, with Cost and Schedule as the dependent variables, then the question to be answered is "when do we stop spending time and money?"
If we can get to 80% of the target with 80% of the cost and schedule, then we're performing "on plan." But then how much does it cost to get the last 20%. This makes EXPLICIT the old 80/20 rule and addressed the common disease of managing software development projects where we get to 80% done and become stuck there for another 100% of the schedule duration.
If we measure the TPM as a function of cost and schedule - a dynamic Triangle - then we can see how progress (maturity toward the goal) is being made over time. With this measurement a projection of the future can be made as well.
This is a very quick overview of TPMs and their connection to Cost and Schedule. The link to TPM is a starting point, but I'll provide some more details soon.
