Just back from the Integrated Program Management Workshop in Bethesda MD these week, where the topic of Agile and Earned Value Management occupied 1/3 of the conference speaks and training - I was one speaking and training. I'm current working two Agile+EVM programs in the Federal Governance and started in this path back in 2003 and 2003. Today the maturity of both Agile and EVM is much greater than the early 2000's Tools, processes, and practices have improved. Now we have SAFE and Scrum of Scrums as he basis of our program controls work. 5 guys in the same room as their customer around the same table is extremely rare where I work. The threshold for EVM is $20M and full validation of the EVMS is now $100M, so small teams are simply not the paradigm. But Agile is still a powerful tool in the INTEL, Software Intensive Systems, Systems of Systems, and rapidly emerging enterprise IT projects in our domain. All driven by the NDAA section 804
In this paradigm, programs are awarded through a formal contracting process guided by the Federal Acquisition Regulations starting with FAR 15 - competitive procurement. A period of performance and a Dollar amount in some form, Not To Exceed, Firm Fixed Price, or Cost Plus, still has a dollar amount. On all these programs, requirements emerge over the course of the work. The notion that requirements are defined upfront is a Red Herring, by those not working in this domain. Capabilities Based Planning is used in most cases, for larger programs. Increasing maturity of the end item deliverables is guided by the Integrated Master Plan / Integrated Master Schedule process in he DOD and other agencies as well as applied to large commercial programs we work.
In all cases decisions must be made in the presence of uncertainties about the future. This is the basis of all risk informed decision making, guided by Risk and Opportunity Acquisition Guide.
Much of this experience is applicable outside of major program development. Based in 5 Immutable Principles of project success
- What does Done look like in units of measure meaningful to the decision maker?
- What's the Plan to get to Done with the needed Capabilities, at the needed Time, for the needed Budget to starting returning the needed value or fulfilling the mission?
- What resources are needed to deliver the needed Capabilities, at the needed Time, for the needed Budget?
- What impediments will be encountered along the way to Done, and what activities are needed to removed these impediments?
- How is progress being measured to inform the decision makers of the probability of success of the program?
These 5 principles are applicable to all project work no matter the domain, process, procedures, or tools.
I came across the briefing below while researching materials of a client. The decision making processes here at deterministic. In practice these are probabilistic branches. Each branch of the decision tree has a probability of occurrence. So making decisions require making estimates of not only the probability of occurrence, but also the probabilistic outcome of that decisions.
Making decisions in the presence of uncertainty between the multiple choices and the impacts of those choices requires making estimates of probabilistic outcomes. To suggest otherwise willfully ignores the Microeconomics of decision making and the Managerial Finance processes that funds those decisions.
