AIPM: Adaptive Intelligence for Portfolio, Program, and Project Management
A framework for accelerating learning and measurable outcomes
| Jeff Mitchell Geissler | Scale with Jeff | Working version 1.0 | October 16, 2026 |
Executive statement
Adaptive Intelligence for Portfolio, Program, and Project Management (AIPM) is an adaptive portfolio management framework that combines Agile and Lean principles with AI-assisted evidence synthesis, risk insight, and disciplined experimentation. It helps teams connect strategy to measurable outcomes, make cross-functional decisions, and adjust delivery as evidence changes. Leaders establish intent and boundaries; teams act within them; AI assists with information and analysis; people own commitments and consequences.
Use Adaptive Intelligence for Portfolio, Program, and Project Management as a proposed expansion of AIPM. The name describes intelligence in the delivery system as well as the use of AI. It is a working name, not a claim of trademark exclusivity or industry certification.
The central proposition
Treat a plan as the current hypothesis about how to achieve an outcome. Maintain explicit commitments, resource limits, acceptance criteria, and accountability. Change the route when evidence warrants it, and reconsider the outcome itself when customer needs or strategic assumptions change.
Traditional portfolio or program management already addresses uncertainty. AIPM makes frequent evidence review and applied learning central to delivery, with AI assistance where it improves the total workflow. The software-to-AI analogy is a teaching device: predictable rules and probabilistic outputs call for different evaluation practices, but neither software nor organizational delivery is universally predictable.
Success means better outcomes with acceptable quality, risk, total cost, and human effort. Faster task completion alone does not establish success. Faster failure is useful only when it limits exposure and informs a better next decision.
Where to apply AIPM
Apply the framework where related work crosses teams, suppliers, tools, or functions and the route to an outcome contains material uncertainty. Suitable starting points include a recurring dependency problem, slow cross-functional decisions, fragmented risk reporting, or a small AI-assisted workflow improvement.
Use conventional repeatable procedures for well-understood work. Use bounded experiments for uncertain approaches. Use explicit reviews for consequential commitments. AIPM combines these practices rather than requiring every delivery task to become an experiment. Keep customer and product judgment close to the work.
Leadership foundations
Trust. State what is known, uncertain, and corrected. Invite challenge from the people closest to the work. Treat adverse findings as information and protect sustainable work.
Clarity. Make the outcome, strategic choices, evidence, decision authority, and next action understandable. Distinguish meaningful uncertainty from avoidable confusion.
Accountability. Assign people responsibility for outcomes, decisions, and actions. Delegation includes boundaries and escalation routes. AI cannot accept responsibility on behalf of a person.
These foundations come from the author’s leadership writing. Financial fluency and calm, proportionate response turn them into daily behavior.
Framework structure
AIPM has six operating disciplines. These are ongoing capabilities, not six sequential gates. A recurring learning cycle connects them.
| Discipline | Leadership question | Minimum useful record |
|---|---|---|
| Strategic intent and value | What should improve, for whom, and why now? | Outcome agreement |
| Evidence and shared understanding | What do we know, how current is it, and what conflicts? | Evidence record |
| Risk and dependency readiness | What threatens the outcome, and when must we respond? | Exposure and dependency record |
| Adaptive delivery and learning | What is the next useful increment or experiment? | Delivery or experiment card |
| Decisions and economic judgment | Who must choose, by when, with what tradeoffs? | Decision brief |
| Leadership and learning continuity | How does today’s learning change tomorrow’s work? | Applied lesson linked to a decision |
Start with one shared document if that is sufficient. These records are logical information requirements, not a requirement to introduce six tools or templates.
Discipline one Strategic intent and value
Define the beneficiary, desired change, strategic purpose, measure, baseline, target, observation window, and outcome owner. Include quality and harm boundaries, capacity and financial constraints, exclusions, and what will be deferred. Make explicit how priorities resolve conflicts.
Differentiate a delivered capability, its adoption, and its effect. A deployed tool is an output. People using it is an adoption signal. Reduced resolution time with maintained quality may be an outcome. Durable customer or financial value requires its own evidence.
Use forecasts appropriate to the information available. Show assumptions and ranges where uncertainty matters; preserve contractual and external commitments as constraints to manage explicitly. Adaptation does not erase obligations.
Completion test: The team can explain the intended change and how it will judge progress without describing only tasks or dates.
Discipline two Evidence and shared understanding
Bring together the minimum evidence required for the pending question. Relevant sources may include work trackers, financial records, dependency plans, supplier updates, quality observations, and customer feedback. Preserve access permissions and source context when combining them.
For each material finding retain a reference, source owner, observation date, scope, and limitations. Identify stale, inaccessible, missing, and contradictory information. Avoid collapsing disagreement into a single reassuring summary.
Use interactive inquiry to move beyond a static report. Useful questions include: What changed? Which assumption is weakening? Which dependency is not ready? What is the consequence of waiting? What evidence would change our recommendation? Answers should connect evidence to impact, uncertainty, and an owner or decision.
Begin with uploads or a bounded export. Add read-only integrations when access, maintenance effort, and repeated use justify them. Define freshness needs by decision: a procurement choice may require a current quote; a strategy review may use a longer observation window. A fresh record can still be incorrect.
Completion test: A reviewer can trace and challenge the basis of a material conclusion.
Discipline three Risk and dependency readiness
Distinguish risks that may occur, issues already occurring, and blockers preventing progress. Record the affected outcome, cause or condition, plausible consequence, urgency, response, owner, and review date. Assess likelihood where evidence supports it; otherwise record uncertainty rather than inventing precision.
For dependencies record provider and consumer, required deliverable, acceptance criteria, needed date, readiness evidence, owner, and fallback. A date in a plan is not proof of readiness. Investigate combinations of dependencies when they may create wider exposure.
Set response triggers in advance where practical. Triggers may include a deadline for an expiring option, a breached spending limit, a quality failure, or an unresolved prerequisite. Separate management estimates from measured facts. Avoid combining subjective scores into an apparently precise overall health number.
Completion test: Each material exposure has a response path and a person able to act before options disappear.
Discipline four Adaptive delivery and learning
Use the following recurring cycle:
- Define the outcome. Establish the change, measure, baseline or baseline gap, owner, and observation window.
- Expose assumptions. State why the proposed approach should work, what remains uncertain, and what would weaken that belief.
- Deliver a bounded increment or test. Choose the smallest useful action. Define scope, acceptance criteria, time and resource limits, permissions, and review. For experiments specify comparison, guardrails, and decision thresholds before results arrive.
- Evaluate evidence. Compare observations with expectations. Include defects, correction effort, adoption, cost, missing observations, and plausible alternative explanations.
- Capture and apply learning. Preserve the original expectation. Explain what changed, how far the lesson transfers, and what practice should change next.
- Continue pivot or stop. Recommend the next action with an owner, rationale, limits, and review date. Separate continuation within tested scope from a broader rollout decision.
Treat inconclusive evidence explicitly. Propose a capped extension, a better test, or a pause. Never extend the experiment silently or rewrite the original target to manufacture success.
Use existing delivery events to run this cycle. In Scrum, outcome and experiment planning can inform planning, evidence can inform review, and applied learning can inform retrospection. Team members retain their established accountabilities. Do not add a parallel approval ceremony to every Sprint.
Completion test: Each completed test informs a real decision; each lesson changes a proposed or accepted next action.
Discipline five Decisions and economic judgment
Give each material choice one accountable decision owner, a required date, alternatives including waiting or doing nothing, evidence, tradeoffs, and conditions that would change the recommendation. Distinguish reversible choices from difficult-to-reverse commitments. Record consequences of delay with the basis for any estimate.
Examine full costs: implementation, integration, fixed commitments, usage, human evaluation, correction, maintenance, support, and transition. Review base and downside cases when material. Do not confuse capacity released with cash savings, or avoided future costs with realized budget reductions. Do not add overlapping benefits. Use Finance or the appropriate benefit owner to confirm consequential assumptions and results.
Record decided, deferred, or escalated status. For deferral, identify the missing evidence and next date. Do not escalate every uncertainty: delegate within agreed limits and reserve higher-level review for conflicts or exposure beyond those limits.
Completion test: The decision record enables action and a later review of whether the reasoning held.
Discipline six Leadership and learning continuity
Maintain a steady operating rhythm and make early disclosure safe. Leaders should ask what in the system produced a result before assigning blame. Accountability remains explicit, including corrective action for repeated failures of agreed responsibilities.
Retain lessons with context, evidence, and limits. Before starting related work, examine relevant prior experiments and decisions. Attach accepted changes to working guidance, acceptance criteria, or the next experiment. Review learning when conditions change; old lessons can become stale assumptions.
Build skills by pairing AI assistance with human reasoning rather than outsourcing judgment. Give experts the authority to challenge summaries, recommend alternatives, and pause unreliable work. Evaluate team usefulness and workload alongside delivery measures.
Completion test: A team can show where prior learning changed current delivery, and people understand their authority and responsibilities.
AI contribution and human authority
| Work | AI assistance | Human responsibility |
|---|---|---|
| Intent | Draft outcome measures and challenge ambiguous goals | Choose priorities and authorize commitments |
| Evidence | Summarize permitted sources and flag discrepancies | Validate material interpretations and resolve disputes |
| Exposure | Suggest dependency links and questions | Confirm impact, timing, responses, and risk acceptance |
| Experiment | Draft hypotheses, designs, and comparisons | Approve exposure and determine acceptable evidence |
| Evaluation | Assist calculations and compare records | Check methods and judge practical implications |
| Learning | Retrieve related lessons and draft updates | Accept changes and own follow-through |
AI can assist the management of any appropriate program; a program need not deliver an AI product. When it does deliver AI capabilities, include evaluation across representative cases, data changes, model changes, monitoring, fallback, and incident ownership as part of acceptance and lifecycle management.
Keep the current companion skill advisory. AIPM as a framework can accommodate later authorized automation, but moving from advice to action requires a separate decision about permissions, bounded authority, monitoring, failure response, and recovery. A skill’s instructions do not create connector access or execution rights.
Proportionate application
Team experiment: Use an outcome and experiment card, a few evidence references, an owner, and a review date for a small reversible change. No new committee is needed.
Cross-team delivery: Add shared dependency readiness, a decision queue, material exposure review, and economic assumptions. Reuse the existing review cadence.
Consequential program: Add specialist review, explicit funding authority, lifecycle controls, recovery readiness, and independent evaluation where the consequence warrants it. Select controls for the actual exposure rather than automatically requiring every function to attend.
These are tailoring choices, not maturity rankings. The minimum rigor must follow consequences; a small team can still face consequential risk.
Roles and operating rhythm
The sponsor or outcome owner sets strategic intent and owns benefit realization. The program leader coordinates the whole system and decision flow. Team and product leaders own delivery and product choices within delegated authority. Decision owners authorize specific choices. Evidence owners maintain and clarify their records. Experiment owners run approved tests and report results. Relevant specialists review their domain when necessary.
One person may hold several roles in a small team; keep the different responsibilities visible. Do not impose a second product owner or override existing Scrum accountabilities.
Use team-level flow reviews to surface impediments. Use a short cross-team review for decisions and dependencies at the pace the work requires. Use periodic outcome and funding reviews to reconsider intent and investment. Trigger immediate review for material guardrail breaches. Replace redundant reporting meetings where possible and measure the total coordination effort.
Balanced measures
Choose a small set with clear definitions, owners, sources, and thresholds. Use trend and context instead of a league table of individuals.
| Dimension | Example measure | Interpretation |
|---|---|---|
| Outcome | Beneficiary result against baseline over an agreed window | The primary test of value; activity is insufficient |
| Flow | Request-to-decision elapsed time plus age of open decisions | Segment by consequence and complexity |
| Readiness | Accepted critical dependencies divided by critical dependencies due | Preserve original dates and disclose revised scope |
| Quality | Material errors or rework divided by cases reviewed | Report denominator and review coverage |
| Learning | Time from evidence to an accepted adaptation; linked examples | Do not reward experiment counts or forced pivots |
| Economics | Total workflow cost and separately verified benefits | Include AI, evaluation, support, and recurring effort |
| Human capacity | Review backlog and team feedback on effort/usefulness | Reduce output when evaluation cannot keep pace |
Do not claim causal proof from a small before-and-after comparison. Compare similar work, preserve unfavorable results, and record confounders. Use stronger evaluation designs when stakes and feasibility justify them.
Original illustrative scenario
All numbers in this example are synthetic. A fictional services team wants to reduce time preparing internal delivery summaries while maintaining factual accuracy. Twenty manual summaries take 600 minutes including checking; one contains a material omission. The team proposes an AI-assisted trial on twenty comparable summaries, targeting at most 24 minutes per summary and no more than one material omission. A human reviews every summary before use.
The synthetic trial takes 340 minutes drafting, 130 checking, and 50 correcting: 520 minutes total, or 26 minutes per summary. Three summaries need material correction. Total effort falls by 80 minutes, or 13.3%, but the 20% effort target and quality criterion are both missed. Faster drafting is not sufficient evidence for rollout. Released minutes are capacity, not demonstrated cash savings; tool costs also belong in the economic review.
The owner stops the trial as designed and reviews the errors. A possible next test narrows AI assistance to extracting cited facts rather than generating whole summaries. It requires new criteria and authorization. The learning concerns the tested workflow, not a universal conclusion about AI. Baseline comparability and correction definitions remain limitations.
Reusable minimum record
Outcome and beneficiary:
Measure baseline source target and observation window:
Accountable outcome owner:
Assumption and disconfirming evidence:
Next delivery increment or bounded experiment:
Evidence references dates and limitations:
Risk issue blocker and dependency readiness:
Time effort cost and quality boundaries:
Decision owner options required date and recommendation:
Observed result and total effort:
Continue pivot stop or explicitly inconclusive:
Applied lesson action owner and review date:
Adoption over the first thirty days
Week one: Choose a recognized delivery problem. Agree an outcome, roles, constraints, and a small balanced baseline. Map existing decisions and records. Identify what reporting the pilot will replace.
Week two: Operate the minimum records and learning cycle on one bounded stream. Verify that ownership and evidence are sufficient without relying on AI to repair missing management agreements.
Week three: Compare reviewed AI assistance with the existing workflow on comparable approved inputs. Keep access narrow. Include checking and correction in effort measures. Observe both usefulness and failures.
Week four: Review results against criteria agreed before the trial. Continue, change, or stop. Record what should transfer, what remains untested, and the next decision owner. Expand scope only when the evidence and economics justify it.
This sequence is a proposed pilot pattern. Tailor timing to observation windows; do not force claims about benefits that require longer to materialize.
Distinctive contribution and relationship to other practices
AIPM’s proposed contribution is the practical connection among strategic outcomes, inspectable evidence across tools, risk and dependency readiness, decision ownership, economic judgment, and applied learning. Its identity comes from this combination and the author’s articulation and implementation of it, not from claiming exclusive ownership of experiments, adaptive planning, or AI-assisted synthesis.
Agile principles provide a foundation for adaptation and collaboration [1]. Scrum explicitly incorporates empiricism and inspection/adaptation [2]. Lean provides a foundation for experimentation and improvement [3]. NIST provides public references for AI risk management [4]. Related public work already explores AI within PDCA [5]. AIPM should acknowledge that overlap and demonstrate its usefulness through transparent examples and field evaluation.
This framework is developed from the author’s own leadership writing. Its examples are fictional, and it does not describe any organization’s internal implementation, data, or results.
Development priorities
Validate with a real bounded pilot before presenting effectiveness claims. Refine the outcome and decision templates from observed use. Align the existing companion skill with this framework and evaluate behavior on contradictory evidence, missing baselines, and unsuccessful experiments. Develop a white paper explaining the rationale and a presentation showing a single complete learning cycle. Keep the framework as the conceptual foundation, the skill as an implementation aid, and the Substack series as an accessible explanation.
References and provenance
[1] Manifesto for Agile Software Development and principles, 2001. https://agilemanifesto.org/ and https://agilemanifesto.org/principles.html
[2] Schwaber and Sutherland. The Scrum Guide, November 2020. https://scrumguides.org/scrum-guide.html
[3] Lean Enterprise Institute. Getting Started with Lean Thinking and Practice. https://www.lean.org/the-lean-post/articles/getting-started-with-lean/
[4] NIST. AI Risk Management Framework Core and Generative AI Profile. https://airc.nist.gov/airmf-resources/airmf/5-sec-core/ and https://doi.org/10.6028/NIST.AI.600-1
[5] Lean Enterprise Institute. Prompt Do Check Act The New PDCA. https://www.lean.org/the-lean-post/articles/prompt-do-check-act-the-new-pdca/
Key themes draw on the author’s writing, including An Essential Guide to Leadership, Strategic Thinking for Business and Technology, Financial Fluency for Program Leaders, Tactics Every Program Manager Should Master, Strategy in Motion, Metrics That Matter, The Hidden Cost of Misalignment, Leadership Without Drama, and essays on AI governance and operating leadership.
No field validation of AIPM is claimed yet.