Conducted on a common discussion group of the PMI’s RiskSIG and INCOSE’s Risk Mgmt Working Group

Thoughts about an Ideal Project Law (IPL)Subtitle: “What happens when really smart folks have too much time on their hands” • Conducted on a common discussion group of the PMI’s RiskSIG and INCOSE’s Risk Mgmt Working Group • Edited by Ron Kohl and David Hall

David Hall Ron Kohl Alan Webb Bob Jones David Hillson Roger Graves Suman Rao Arjen Veltheer David Whitmoyer John Cloward Key Contributors

A brief historical summary • A visual aid is offered up to help to communicate the affects on project risk if cost or schedule is changed • The ‘push in on a ballon and watch it stick out there’ analogy was subsequently offered up • It was suggested that some ‘closed form’ equation could represent this balloon surface/situation! • An analogy to the Ideal Gas Law was ‘postulated’ • All hell broke loose!! It was the ‘hydraulic engineers’ against the ‘theoretical fluid physicists’ ;-) • Some wish to pursue some ‘basic underlying scientific principles’ while other want to pursue a practical tool

Assumptions • We will restrict ourselves to development projects (and ignore operations projects for now) • Because development projects have fixed F, C and S, while Ops projects can be open ended • A given project, P, is a set of activities and artifacts that are intended to produce a set of Functionality, F, for a given cost, C, on a given schedule, S.

And now for details (the early days) • David Hall shared a visual aid that he uses that attempts to depict changes in risk due to changes in certain project parameters (cost, schedule, performance). See next two slides • It was noted that changing of project parms was analogous to poking in a ballon and watching it poke out somewhere else • This analogy was further extend by replacing the balloon with an abitrary 3-d mathematical surface and noting that such a figure is typically the graph of some appropriate function! • It was suggested that perhaps there is some ‘closed form’ of some mathematical expression that could describe this surface (i.e. an equation that described these relationships)

Risk Trade Space Indication Increasing Risk Less risk if allowed to move cost and schedule

Increasing Risk Schedule Schedule Cost Performance Increasing Risk Performance Changing Performance Requirements with no change allowed in cost or schedule Cost

The middle years • There was much turmoil as a debate ensued about if the 3 project parameters are sufficient (F=Functionality, C=Cost, S=Schedule) • Some postulated that more ‘dimensions’ of a project were necessary (Quality, Cust Sat, etc) • Others claimed that any parm beyond F, C and S could be derived from these 3 basic ones • There was a concern that we had lost sight of the original intent to explain changes in risk based on other project parameter changes

The Alchemists are heard from • Ron Kohl introduced the Ideal Gas Law (which says: (P*V)/T = K) as an example of a ‘closed form’ scientific equation which may have analogies to our Project Risk situation • Ron Kohl then postulated the IPL which says: F/(C*S) = K, where F = Functionality of system, C = Cost and S = Schedule • The purpose of the IPL was to capture ‘direct’ and ‘inverse’ relationships between the 3 factors

What are the ‘open’ issues? • Definition of an ‘ideal project’ that is analogous to an ‘ideal gas’ • Concern that the 3 factors (F, C, S) are not adequate to be ‘useful’ (should be more factors) • Concern ‘risk’ has not been addressed and may not easily be inserted into the IPL • Concern that S (in the IPL) is not fully in a ‘direct relationship’ with F. • Concern about how the IPL relates to the lifecycle • Concern that this IPL will be of any value at all • Relationship between the IPL and various project types (a new killer app project, a weapons systems project, etc)

Let’s look at the Open Issues

Definition of an ‘ideal project’ • Project: a set of activities and artifacts that is intended to produce a system with a set of functionality (F), for a given cost (C) over a given schedule (S). • This is a limited definition but is necessary to bound the scope of the IPL • It is observed that projects exhibit certain behaviours • holding S fixed, if C is increased, then F is increased • holding C fixed, if S is decreased, then F is decreased • holding F fixed, if C is increased, then S is decreased • An ‘ideal project’ is one which obeys these behaviours, as the parameters go to zero and infinity (i.e. obeys the IPL)

More about Ideal Projects • We can conclude the following: • If F is fixed, then given enough money, we can produce F in as short a time as desired • If F is fixed, then if we allow long enough time for completion, then the cost can be made arbitrarily small • In a fixed amount of time, we can produce any functionality, given enough money • For a fixed cost, we can produce any functionality if allow sufficiently long enough time

The 3 factors (F, C, S) are not adequate (should be more factors) • Some say Q (quality) is needed: • Others say that Q is simply a function of F • If any Fi in F is not fully implemented, then there is a lack of Q • Some say Customer Sat is needed: • Others say that CS is a function of C, S • If the PM can reduce C or S, then CS increases • But if there is no explicit ‘rqmt’ for CS (e.g. award fee, etc), then CS is not likely to be a high priority

Concern that ‘risk’ has not been addressed • It has been suggested that by introducing U (uncertainty) into the IPL is a start • U is an attribute of any project factor, including the 3 factors in the IPL • We could introduce U(F), U(C) and U(S) • We could introduce a ‘range of risk values’ for F, C and S • We could introduce R (risk) as either a ‘weight’ or as function of F, C and S

Let’s look at IGL vs IPL re/risk • There were pressurized gas systems long before the IGL • Prior to the IGL, there was engineering savvy that provided guidance on how to construct such systems and what risks to worry about • After the IGL, there was a better understanding of the underlying principles of physics so that the engineering of such systems could be improved • In the early days, risk was addressed by providing ‘engineering limits’ so that things didn’t go boom! • These engineering limits arose thru trial and error • After the IGL, it became possible to compute the ‘system state’ to see if a ‘risk limit’ was being appraoched

Let’s look at IGL vs IPL re/risk • What is the analogy to the IPL vs real projects, as relates to risk? • We don’t have any underlying scientific principles, but we do have ‘engineering’ guidance for project management • We know that projects ‘go boom’ and most times we know why • Yet we seem to lack a good ability to quantitatively watch a project undergo changes and then watch as risks rise and fall • The IPL could become a useful tool in our Risk Mgmt toolkit to help address this problem

Concern that S is not fully in a ‘direct relationship’ with F. • It seems odd to suggest that given a fixed C, that if we increase S, then we get more F • It doesn’t seem so odd to suggest that given a fixed C, that if we decrease S, then we get less F • This suggest that perhaps there is not a ‘geometric’ relationship between F and S • Perhaps using some ‘damping’ function would help • Sqrt or Log or ….? • IPL becomes F = K*C*Log(S)? • It may require data to pick any such ‘damping’ function

Concern about how the IPL relates to the lifecycle • When do instances of an IPL surface in a system’s lifecycle? • Acquisition Concept Development • In a proposal to a bid • In a contract for a project • When do instances of an IPL change during a project? • Major project milestones • Technology upheavals • F, C and/or S changes

The IPL will not be of practical value • Skepticism is running rampant! • This is a very good thing!!! • Postulated ‘ideal’ laws of science must be challenged • Holes must be found in these Laws • Some would like a practical ‘tool’ right away • Others recognize that the pursuit of ‘basic scientific principles’ takes time (to succeed or to fail) • Given that practitioners are involved on both sides, there is hope

More about ‘practicality’ • The best we are likely to achieve is some ‘relativeness’, not ‘absoluteness’ • Many existing tools that are predictive and comparative in nature (COCOMO, SW Error Predictions, Reliability, etc) are not guaranteed for accuracy! • So, just what is a reasonable expectation of ‘practicality’? • Recall where we started: Visually showing how changes in one factor influenced a change in risk!

How’s this for an expectation? • Establish a comparison capability: • Between projects • Between two changed states within a given project • To be able to predict relative riskyness of a project, as compared to a baselined state

Where are we now? • An IPL has been postulated • Valid issues have been raised • Alternative ideas are being considered • The link between ‘ideal’ and ‘reality’ is weak • A separate ‘venue’ has been formed to focus on just this topic, perhaps with reduced but focused participants

Where do we go next? • Further analysis of the IPL • Possible ways to introduce Risk • How to make the IPL ‘practical/useful’ • Conduct experiments/analysis, with real project data, to validate (or invalidate) the IPL • Report out the results as appropriate (or maybe periodically?) • Derive ‘units’ for F, C, S and K that make sense

Conducted on a common discussion group of the PMI’s RiskSIG and INCOSE’s Risk Mgmt Working Group