Use cases

How different program teams use Kharazm

Programs look different across organizations, but the delivery problem repeats: many owners, fixed dates, visible risks, and stakeholders who need a reliable account of progress. These six scenarios show where Kharazm fits and which parts of the product do the work.

These are capability narratives, not customer stories. Kharazm is a new product and has no customers yet, so nothing here is attributed to a real organization and no results are claimed.

01 Cross-functional launches

Coordinating owners, milestones, risks and decisions around one visible outcome.

02 Learning & development

Running cohorts, curricula and required learning as one program use case.

03 Grant-funded programs

Reporting to a funder with a record you can stand behind.

04 Community & volunteer programs

Coordinating contributors, sites and recurring delivery with limited capacity.

05 Multi-site rollout

The same initiative across many locations, at different speeds.

06 System migration

Managing the people, decisions and cutover around a platform change.

Scenario 01

Cross-functional launches

A visible outcome has one date, but the work crosses operations, communications, policy, technology and leadership — teams with different priorities and no single shared view.

The situation

A launch is more than its release date. Policy needs approval, communications needs final language, operations needs a readiness check, technical work needs validation, and an executive sponsor needs a concise status. Miss one handoff and the public date can stay green while the work underneath is already slipping.

How Kharazm is used

The launch is a program with an owner, objective and target date. Decision points and the public release become milestones. Work becomes tasks with an assignee, due date and labels for each workstream, so the board shows handoffs without flattening the whole launch into one checklist.

The timeline places task due dates, estimated status bars and milestone diamonds against a month grid and today marker. Work waiting on another team carries the blocked flag and can be explained in task comments; reports count overdue, blocked or unassigned work alongside the program status.

What it makes easier

The launch meeting starts with one current picture instead of five departmental reports. A published update then preserves the version the team chose to publish inside the workspace, even as the live board continues to change.

Scenario 02

Learning and development programs

An onboarding cohort, leadership academy, curriculum rebuild or required-learning cycle has content work, delivery dates, approvals and stakeholders beyond the learning team.

The situation

Learning delivery is only the visible event. Before it, subject-matter experts review content, communications reach the audience, facilitators and locations are confirmed, accessibility is checked, and sponsors decide what success means. A learning platform may track learners and completions; it does not necessarily manage the cross-functional program around them.

How Kharazm is used

The initiative becomes a program with milestones for design approval, pilot, launch and review. Preparation work — content review, accessibility checks, facilitator readiness and communications — moves through To do → In progress → Review → Done.

Known problems go in the risks and issues register: a subject-matter expert may be unavailable, a policy change may invalidate content, or a delivery site may not be ready. Each entry has a type, owner, due date and resolution field.

The program manager records program health and reviews it against visible evidence such as overdue work, blocked approvals and missed milestones before publishing a stakeholder update.

What it makes easier

The learning team can manage delivery and stakeholder accountability without asking an LMS to become a program-management tool. Each published update is preserved with its evidence, so the status shared before a cohort or launch remains available after the live plan moves on.

Scenario 03

Grant-funded program reporting

A program funded by a grant, with deliverables, a period of performance, and a funder who expects a report on a schedule agreed before the work started.

The situation

Grant-funded work carries an obligation that ordinary internal work does not: you have to be able to describe, in writing and on time, what was delivered in the reporting period. The report is usually assembled at the last minute by one person, from a mixture of memory, spreadsheets and whatever the team can recall in a meeting. Anything that was true three weeks ago and has since changed quietly becomes an inaccuracy in a document with your organization's name on it.

How Kharazm is used

Each award becomes a portfolio, and the programs it funds sit inside it — so the roll-up matches the funding rather than the org chart. Deliverables are milestones with the dates from the agreement. The written objective on each program is the place to restate the funded outcome in the funder's own language, so nobody has to go back to the award document to remember the wording.

Reporting periods are handled by the weekly stakeholder update: a draft you edit as the period runs, then publish. Publishing writes a fixed, read-only snapshot with the evidence behind it, so the state of the work at that moment is preserved. The reports view supplies the underlying picture — status mix across the portfolio's programs, work completed per week, and the open items still needing attention.

What it makes easier

The report becomes an act of editing rather than an act of archaeology. Because published snapshots cannot be altered afterwards, the workspace keeps a defensible record of the status versions prepared for each period. Kharazm stores those versions; it does not send a funder report or prove that an external recipient received one.

Scenario 04

Community and volunteer programs

Delivering a recurring service with contributors who may be distributed, part-time, seasonal or shared with other initiatives.

The situation

Community programs often run on limited capacity. A seasonal intake, site launch, event cycle or outreach campaign may depend on volunteers, partner organizations and staff who each have other responsibilities. The public commitment remains fixed even when contributors and local conditions change.

How Kharazm is used

The service cycle is a program; each intake wave, event or site opening is a milestone. Preparation tasks carry labels for the site or season and a clear assignee. The list view puts due dates in one place, while the board makes handoffs visible.

The team page records who reports to whom and shows each person's current open-task count. Reports count overdue, blocked and unassigned work so a manager can review the common failure mode of distributed work: responsibility changed, but the task did not.

What it makes easier

Continuity. When a coordinator changes, the plan, open risks, task discussion and past published updates stay in the workspace instead of leaving with one inbox. A replacement can join with an assigned access level through an invitation.

Scenario 05

Multi-site rollouts

One initiative, many locations — regional offices, branches, schools, clinics or field sites — each moving at its own pace with local constraints.

The situation

The central plan may be finished; the hard part is delivery across sites that are not identical. One region lacks an owner. Another cannot make the change during its busy season. A third finished early and is waiting on a shared approval. Leadership asks for one answer to "how is the rollout going," and the honest answer has many local parts.

How Kharazm is used

The rollout is one program with per-site tasks, or a portfolio of site programs when each location needs its own dates and owner. Site labels remain visible on each task, although board filtering is not available yet. Shared dates — readiness review complete, materials delivered, all sites live — are milestones on the timeline.

The workflow view earns its place here: live counts at each stage show where the rollout is jamming. A large queue in Review usually means one central reviewer has become the bottleneck for fifteen sites, and each stage links straight into the board so the person looking at it can act rather than just observe.

Local problems go into the risks and issues register with a named owner, which keeps "the north region has no implementation lead" from being raised in every meeting and resolved in none.

What it makes easier

A single view where sites are visibly at different stages, instead of a status spreadsheet that is out of date the moment it is circulated. And when a director asks which sites are behind, the reports view answers from the work itself.

Scenario 06

System migration and platform change

Moving data, processes and teams from one system to another while normal operations continue and the old contract moves toward its end date.

The situation

A platform migration crosses the business area that owns the process, IT, procurement, security, vendors and the people who will use the new system. Historical data may be inconsistent, dependencies sit outside the core team, and the cutover date is often fixed because the old contract ends.

How Kharazm is used

The migration is its own program, separate from the operational programs that continue during it. Phases become milestones: inventory complete, pilot migrated, records validated, cutover, old system decommissioned. Work to assess, map, test, migrate or retire records becomes tasks on the board, with labels for the business area or data group involved.

Dependencies on people outside the team are where migrations fail, so they are made explicit: tasks waiting on the vendor or on IT carry the blocked flag, are counted in reports, and are visible to everyone rather than living in one person's follow-up list. Assumptions that turn out to be wrong — "historical completion dates will transfer intact" is the classic — belong in the risks and issues register from the start.

Because the cutover date affects far more people than the project team, a weekly published update keeps a fixed in-workspace record of what moved, what is at risk, and what the team needs from other departments. Kharazm does not send or publicly share that update; the team chooses how to distribute it.

What it makes easier

An honest, current view of a long project with many external dependencies — and a written trail of what was flagged and when, which is worth a great deal in the review that follows a difficult migration.

Who it is for

Roles around the work, and the access that fits them

Kharazm has four access levels, enforced on the server rather than only hidden in the interface. Most program teams map onto them like this.

Admin

Workspace owners and program directors

The person accountable for the portfolio. Admin is the level that can create and delete programs, delete portfolios, add and remove people, set everyone else's access, invite by email, and read the organization's audit log. Keep the number of admins small — this is the level that can remove things.

Manager

Program leads, senior coordinators

The people running delivery day to day. Managers create and delete tasks, edit and archive programs, manage milestones and portfolios, and write and publish the weekly stakeholder update. Most of the work of running a program happens at this level.

Member

Coordinators, specialists and contributors

The people doing the work. Members edit tasks, change status, comment, and raise or resolve risks and issues. They cannot create or delete tasks or programs, so the plan stays under the program lead's control while the work stays in the hands of the people doing it.

Viewer

Executive sponsors, oversight staff, partner departments

People who need visibility, not edit rights. Viewers see programs, tasks, the timeline, reports and publication history, and can use search — while server-side rules prevent them from changing the record.

Access levels are cumulative and checked on the server for every write, with the actor taken from the signed-in session. A full breakdown of who can do what is in the permission table on the features page.

Kharazm is likely a good fit if

You run several visible, multi-step programs at once
Your deadlines come from outside your team — commitments, grants, contracts, launches or oversight cycles
Someone above you expects a regular written update
Work depends on people in other departments who do not report to you
You need a record of what was reported and when
Your staff are not project-management specialists and will not learn a complex tool

Kharazm is not the right tool for

Delivering courses or tracking learner completions — that is an LMS, and Kharazm is not one
Budget, invoicing or grant drawdown tracking — there is no financial surface at all
HR records or performance management
Automated syncing with other systems — no integrations exist
Task dependencies, time tracking, custom workflows or capacity forecasting — those are not in the current product

We would rather tell you this now than after you have moved your team.

Does one of these look like your work?

Kharazm is early and has no customers yet. If your team is accountable for complex programs and recurring stakeholder updates, tell us how you actually work — it shapes what gets built next.

Request access Explore the features