As you build and grow your Foundry Program team, we recommend following the strategic planning and governance checkpoints as described below. These planning, review, and development stages are critical in ensuring your team is prepared for the various responsibilties and activity required for successful maintainance, usage, and deployment of the Foundry platform within your organization.
Steering committee (SteerCo) meetings are regular meetings that are central to the high-level direction of the Foundry Program. The primary purpose of a SteerCo meeting should be to evaluate the strategic direction, scope, and cost of the Foundry platform as a whole. It is common for specific high-priority projects to be discussed during a SteerCo, but they should not be the sole focus of the meeting.
A sample agenda for a SteerCo meeting might include:
Development and roadmap reviews are meant to review the past month's progress and align on deliverables for the coming month and longer-term roadmap. This session is a forum for reviewing the progress of ongoing development initiatives, discussing opportunities for enhancements to existing use cases, and identifying and prioritizing opportunities for new use cases.
A sample agenda for each session might include:
Standup is a short (<30 min) daily call during which each member of a use case team provides a progress update.
Standup updates are typically limited to:
During sprint planning meetings, attendees review what was and was not completed from the previous sprint and decide what will be worked on in the upcoming sprint.
An example agenda includes:
New projects are suggested by users across the organization by submitting a creation request through the Project Creation Request Portal. Those requests are then reviewed and either approved or denied from the Project Approval Inbox.
If a request is approved, the requested project is created, controlling for role assignment and group access in accordance to the details of the request. Project creation permissions for each Foundry space should be restricted to the central Platform Governance team; the roles that fill this team will evolve over time as platform governance grows more specific throughout the phases of development.
Project roles should be controlled such that only designated groups hold specific roles on projects. We recommend ensuring that groups are tied directly to the organization's identity provider (IdP) groups.
Access requests are reviewed and either approved or denied the request from the Project Approval Inbox. Upon request approval, the requestor's account is added to the group(s) with the appropriate role on the Project.
Depending on where groups are managed, this will require either adding the requestor's network account to the IdP group, or adding their Foundry account to the Foundry-specific group. We recommend that individual users are not granted roles directly on a Project.
Data permission administration in Foundry takes several forms, from controlling blanket access to datasets or entire pipelines, to controlling visibility of records within a dataset.
Data permission administration requirements for a particular use case should be scoped out as a part of the Project Creation Review process. Documenting and applying the appropriate data permissions takes place during Project development.
We recommend the creation of an internal support structure to assist with user issue triage, investigation, and resolution. This structure can be significantly impactful in retaining autonomy within your organization and in ensuring any issues that require Palantir involvement will have the required level of detail provided before escalation.
**Phase 1/2: **Support may be handled by the Foundry Program team Phase 2+: We recommend establishing a dedicated internal Foundry Support team
Palantir offers centralized training resources, but we recommend that Foundry Program teams also develop an internal training curriculum specific to each of the organization's use cases.
This includes developing and maintaining the documentation for each use case's data lineage and ontology components, as well as tutorials for how users should engage with core applications. Training mediums can include in-platform and external documentation (for example, interface tutorials and documentation), as well as recorded and in-person training/tutorials.