Submit Request
Work enters through a shared intake path instead of side-channel emails, chats, or hallway asks.
Shows how IT work enters ODOE, how it is prioritized, and how different audiences stay informed.
The operating discipline is straightforward: work should enter through a clear intake path, be classified and prioritized consistently, and move through delivery and reporting with visibility.
This is the simplest version of the process. Every request should move through these same core steps.
Work enters through a shared intake path instead of side-channel emails, chats, or hallway asks.
IT identifies whether the work is an incident, standard support request, access/security request, or project/enhancement item.
Priority is based on mission impact, time sensitivity, risk, dependencies, and available capacity.
Some items move immediately, some are scheduled into the queue, and some require leadership tradeoff or sponsor input.
An owner is assigned, the work moves forward, and blocked items are surfaced quickly instead of silently stalling.
IT confirms the fix or delivery worked, explains status in plain language, and shares timing changes early.
Work is closed cleanly, recurring issues feed runbooks or problem review, and leadership reporting stays current.
This keeps prioritization from feeling arbitrary. These are the factors leadership and stakeholders should expect IT to use.
Does this affect core agency operations, public reporting, leadership decisions, or staff productivity in a meaningful way?
Is there a real deadline, outage, audit timing issue, or external commitment driving when this must be done?
Does delaying the work create security, access, continuity, or governance risk for the agency?
Can IT complete this quickly, or does it depend on vendors, approvals, other teams, or prerequisite work?
If this moves up, what work moves down? The queue should show that tradeoff clearly.
Not every item follows the same speed. Some work needs immediate action, while some work belongs in the planned queue.
Examples: outage, service degradation, security issue, executive-critical operational blocker.
Behavior: immediate triage, rapid assignment, frequent communication, then post-incident review if needed.
Examples: enhancement request, reporting improvement, collaboration cleanup, dashboard refinement.
Behavior: scored for priority, sequenced with other work, scheduled into the backlog, and reported through regular cadence.
Blocked does not mean ignored. It means IT cannot move the item forward until something external or unresolved is addressed.
Different audiences need different visibility from the same process.
Needs queue detail, ownership, blocked items, incident status, workload, and change readiness so work can actually move.
Need service health, top risks, priority alignment, decisions needed, and whether IT is operating predictably.
Need plain-language status, expected timing, maintenance notices, and a clear understanding of how to engage IT correctly.
Simple rhythm matters. It keeps the process alive and visible instead of becoming a one-time diagram.
| Cadence | Purpose | Audience |
|---|---|---|
| Daily / near-daily triage | Review new intake, incidents, and blocked items | IT team |
| Weekly prioritization review | Confirm queue order, tradeoffs, and capacity shifts | IT manager + key stakeholders |
| Monthly executive review | Report health, risks, progress, and decisions needed | Leadership |