Scott RugglesIT Project Manager| Maricopa County Department of TransportationPhoenix, Az, United States
So everyone wants this new technology, though the questions we need to ask and all of the Data sources/approvals/management that goes with it.
For example: Costs in relation to 'tokens', an analysis of the different available 'models', ramp up speed, increased testing and learning... all the things that a standard project charter (pre AI) doesn't cover.
How have your project charters evolved to ensure you're covering project success?
Consultant| Canarys Automation LtdBangalore, Karnataka, India
I don't think AI projects necessarily need a completely different Project Charter, but I do believe the traditional charter needs to evolve. Along with the usual objectives, scope, stakeholders, budget, risks, assumptions, and success criteria, AI initiatives introduce additional considerations: data sources and ownership, data quality, privacy and security, model selection, token/API and infrastructure costs, expected accuracy, testing and evaluation criteria, human oversight, and governance around AI-generated outcomes. Another important difference is predictability. With conventional software, we can often define expected behaviour relatively clearly. With AI, some experimentation may be necessary before we know whether the proposed approach can achieve the required quality. I would therefore include explicit assumptions, evaluation thresholds, experimentation boundaries, and go/no-go criteria in the charter. So, for me, it is less about creating an "AI Project Charter" and more about extending the existing charter so that approval reflects the realities and uncertainties of AI delivery. The charter should still answer the fundamental question: What exactly are we authorizing, and how will we know whether it has succeeded? Saving Changes...
Hellen charlessseo expert| Digital MarketingHouston, United States
I think AI projects require a slightly different approach to the traditional project charter. The usual scope, timeline, budget and risks are still important, but there are several additional areas that need to be defined upfront. For example, I would include the AI model being considered, data sources and ownership, privacy and security approvals, expected token and API costs, testing requirements, human oversight and how success will actually be measured. I would also leave room for experimentation because the first model or approach is not always going to be the best one. I would probably treat the charter as a living document as well. AI tools and models change so quickly that assumptions made at kickoff can become outdated during the project. Clear decision points and review checkpoints can help keep the project aligned with the original business goal rather than simply adopting AI for the sake of using it.
...
1 reply by ZIAUDDIN KHAWAJA
Aug 18, 2026 3:57 PM
ZIAUDDIN KHAWAJA
...
I agree with the core point here—AI projects definitely demand a shift toward treating the charter as a living document with iterative review gates. Coming from a telecommunications and network delivery background, the biggest difference I see with AI/ML initiatives compared to traditional infrastructure deployment is the uncertainty around data quality and cost scaling. A standard charter assumes deterministic outcomes, whereas AI projects require explicit definitions around:
Data Governance & Security: Validating ownership, privacy approvals, and training data cleanliness before scope baseline.
Operational Cost Thresholds: Setting hard guardrails on API/token costs and compute infrastructure to prevent budget overruns during discovery.
Go/No-Go Decision Gates: Defining clear accuracy and testing thresholds so the project can pivot or ramp down if the model fails to deliver measurable business value.
Focusing on these upfront boundaries keeps the team aligned on business outcomes rather than adopting technology just for the sake of it.
Saving Changes...
Luis BrancoCEO| Business Insight, Consultores de Gestão, LdªCarcavelos, Lisboa, Portugal
A very relevant question. I would be cautious, however, about assuming that AI-driven projects necessarily require a different Project Charter. A well-designed Charter should already establish purpose, expected value, high-level scope, assumptions, constraints, risks, authority and success criteria. The question is what AI changes materially enough to require explicit treatment.
For AI-enabled initiatives, that may include data access, use, quality and governance, model and vendor assumptions, autonomy boundaries, validation criteria, human intervention, cost uncertainty and evidence requirements. It may also require clarity about which changes in models, data, configuration or use are material enough to trigger reassessment or reauthorization.
I would also distinguish what belongs in the Charter from what should sit in the SOW, contracts or more detailed governance mechanisms. Trying to place every AI-specific consideration in the Charter could make the document less useful rather than more complete.
Perhaps the evolution needed is therefore not an "AI Charter" by default, but fit-for-purpose governance and authorization mechanisms that make AI-specific assumptions, boundaries and responsibilities explicit while keeping each mechanism focused on the purpose it is intended to serve.
...
1 reply by Scott Ruggles
Aug 18, 2026 12:08 PM
Scott Ruggles
...
Luis,
Thanks for the input. Maybe the approach would be to revise the SOW as well, and load that with additional discovery questions.
Thanks!
Saving Changes...
Scott RugglesIT Project Manager| Maricopa County Department of TransportationPhoenix, Az, United States
Aug 18, 2026 2:50 AM
Replying to Luis Branco
...
A very relevant question. I would be cautious, however, about assuming that AI-driven projects necessarily require a different Project Charter. A well-designed Charter should already establish purpose, expected value, high-level scope, assumptions, constraints, risks, authority and success criteria. The question is what AI changes materially enough to require explicit treatment.
For AI-enabled initiatives, that may include data access, use, quality and governance, model and vendor assumptions, autonomy boundaries, validation criteria, human intervention, cost uncertainty and evidence requirements. It may also require clarity about which changes in models, data, configuration or use are material enough to trigger reassessment or reauthorization.
I would also distinguish what belongs in the Charter from what should sit in the SOW, contracts or more detailed governance mechanisms. Trying to place every AI-specific consideration in the Charter could make the document less useful rather than more complete.
Perhaps the evolution needed is therefore not an "AI Charter" by default, but fit-for-purpose governance and authorization mechanisms that make AI-specific assumptions, boundaries and responsibilities explicit while keeping each mechanism focused on the purpose it is intended to serve.
Luis,
Thanks for the input. Maybe the approach would be to revise the SOW as well, and load that with additional discovery questions.
Thanks!
...
1 reply by Luis Branco
Aug 18, 2026 2:30 PM
Luis Branco
...
Yes, I think that could be a very useful part of the approach.
I would use the additional discovery questions to identify what AI changes materially and then determine where each resulting requirement should be governed. Some may belong in the Charter, others in the SOW, contracts, risk controls or ongoing AI governance mechanisms.
That distinction matters because the objective is not simply to add more AI-related questions or documentation. It is to ensure that what discovery reveals leads to appropriate requirements, clear ownership and decision rights, proportionate controls, and defined triggers for reassessment as models, data, configuration or use evolve.
So I would see the SOW as an important part of the solution, but as one element of a broader governance approach in which each mechanism serves a clear and distinct purpose.
Thanks for extending the discussion, Scott.
Saving Changes...
Luis BrancoCEO| Business Insight, Consultores de Gestão, LdªCarcavelos, Lisboa, Portugal
Aug 18, 2026 12:08 PM
Replying to Scott Ruggles
...
Luis,
Thanks for the input. Maybe the approach would be to revise the SOW as well, and load that with additional discovery questions.
Thanks!
Yes, I think that could be a very useful part of the approach.
I would use the additional discovery questions to identify what AI changes materially and then determine where each resulting requirement should be governed. Some may belong in the Charter, others in the SOW, contracts, risk controls or ongoing AI governance mechanisms.
That distinction matters because the objective is not simply to add more AI-related questions or documentation. It is to ensure that what discovery reveals leads to appropriate requirements, clear ownership and decision rights, proportionate controls, and defined triggers for reassessment as models, data, configuration or use evolve.
So I would see the SOW as an important part of the solution, but as one element of a broader governance approach in which each mechanism serves a clear and distinct purpose.
Thanks for extending the discussion, Scott. Saving Changes...
I think AI projects require a slightly different approach to the traditional project charter. The usual scope, timeline, budget and risks are still important, but there are several additional areas that need to be defined upfront. For example, I would include the AI model being considered, data sources and ownership, privacy and security approvals, expected token and API costs, testing requirements, human oversight and how success will actually be measured. I would also leave room for experimentation because the first model or approach is not always going to be the best one. I would probably treat the charter as a living document as well. AI tools and models change so quickly that assumptions made at kickoff can become outdated during the project. Clear decision points and review checkpoints can help keep the project aligned with the original business goal rather than simply adopting AI for the sake of using it.
I agree with the core point here—AI projects definitely demand a shift toward treating the charter as a living document with iterative review gates. Coming from a telecommunications and network delivery background, the biggest difference I see with AI/ML initiatives compared to traditional infrastructure deployment is the uncertainty around data quality and cost scaling. A standard charter assumes deterministic outcomes, whereas AI projects require explicit definitions around:
Data Governance & Security: Validating ownership, privacy approvals, and training data cleanliness before scope baseline.
Operational Cost Thresholds: Setting hard guardrails on API/token costs and compute infrastructure to prevent budget overruns during discovery.
Go/No-Go Decision Gates: Defining clear accuracy and testing thresholds so the project can pivot or ramp down if the model fails to deliver measurable business value.
Focusing on these upfront boundaries keeps the team aligned on business outcomes rather than adopting technology just for the sake of it.
Consultant| Timely Nexus Project LLPGreater NOIDA, Uttar Pradesh, India
Not necessarily. A separate project charter is not automatically required just because AI is being introduced. If AI is an enhancement to an existing project and remains within the approved objectives, scope, governance, and budget, the existing charter can be updated with an AI-specific section or amendment. However, a separate charter may be appropriate when AI introduces substantially different objectives, significant new risks, separate funding, new stakeholders, data governance requirements, or a different delivery approach. A practical approach is: amend the existing charter for an AI enhancement; create a separate charter when AI becomes a distinct project or workstream with its own objectives and governance. Saving Changes...
Community Champion
