Eleven files, three days before I leave for two weeks. I'd rather walk you through what each one is and where it fits, so you don't have to reverse-engineer it while I'm offline. The goal of this page is simple: by the bottom of it, you should know what we do today, what's broken about it, and what good would actually look like.
If you only have an hour, this is the path I'd take. Each step builds on the last.
I told you on the call I think this is the central problem, and I meant it. Here's how I use these terms. The PMO uses some of them differently. Aligning on this is part of the pilot's value.
Why this matters for the pilot Right now we treat every change as a project, because that's the only governance shape we have. That's how we end up with PMs trying to attach demand records to spreadsheet rows. If Iteright can give us a place where ideas, demands, projects, and product features each have an appropriate home, that alone is a huge win. It's the unifying intake problem you and I were circling on the call.
These are the artifacts that actually get looked at by leadership. They are also the artifacts the pilot needs to either replace or render obsolete.
This is a Power BI report exported to PDF. It pulls from a mix of the project records in ServiceNow and the spreadsheets the PMs are maintaining by hand. 71 projects, $140M in budget, traffic-light status across scope, schedule, cost, quality. It's the closest thing ITSD has right now to a single view of work.
The page count is misleading. The first page is the all-up view, then there are slicer-driven division views (AppDev, RCSD, Cyber, DSIO, External), a project-detail drill-down page, and a current-and-proposed-work backlog. This is what Jay's peers see in the weekly review.
It's better than what came before it, which was loose PowerPoint slides. It's still not what we want. The data is one Tuesday old by the time anyone sees it, and the underlying spreadsheets it pulls from are maintained inconsistently division-by-division.
This is the predecessor format. PowerPoint, hand-assembled, loosely templated. Each group lead used to do their own. I did one for five months and stopped because I couldn't tell anyone was reading them. The new comms person inherited this mess and is the reason the Power BI version exists at all.
Worth opening to feel the texture of what they're moving away from. The PowerPoint is what every IT division did before; the PDF above is where they are now. The next step is supposed to be Planner Premium plus ServiceNow as the source. See the Teams screenshot included with this bundle.
Screenshot of a Teams message from Amy Garcia, one of our PMs. The summary: the legacy Power BI report still pulls from Excel. A new report on the ITSD PMO Report tab pulls from Planner Premium and ServiceNow. Once all the PMs have updated their projects in the new place, the legacy report retires.
Read this as: the PMO is in motion, mid-migration, and Iteright is arriving at exactly the moment they're rethinking where project status lives. That's a feature, not a bug. We just have to be deliberate about not stepping on the migration in flight.
This is the application-and-project roadmap workbook for AppDev specifically. Application name, group, retire-replace-modernize-new, customer, funding source, project, PEMP and Lab Agenda alignment, Balendra Pillars, start, end. About 200 rows.
Mention this to Jay and watch his face. This is the kind of artifact that exists in three slightly different versions because everybody made their own copy. It is, however, a real working source of truth for what AppDev is doing across applications, even if it doesn't reconcile cleanly with what's in ServiceNow.
For the pilot, this matters because it's the closest thing to a portfolio plan in flat-file form. If Iteright can ingest this and produce the same shape Jay is drawing here, manually, we're in business.
The Demand is supposed to be the heart of the intake-to-project flow. It is also the most misunderstood object in the system. These four files together tell the story.
A blank one. Look at the field list. Number, Category, Project Tier, Project Tracking, Group Leader, Title. Then the long-text block: Problem Statement, Customers Serviced, Recommended Solution, Benefits, Labor and Materials cost, Cost Estimate Notes, Project Schedule, Alternatives, Analysis Methodology, Risks. Plus a state pipeline across the top: Draft, Submitted, Qualified, Approved, Completed, Rejected.
This is a lot. Too much, in fact, for anything that hasn't already been thought through. Which is why most ideas never make it past Draft, and why people skip the form altogether for smaller work.
Real example, completed and approved. EMT Web Application, $20,691.90 in labor, primary designer Herb Himes, period of performance April through August. State Completed. Linked to project PRJ0011048. Activity log showing every state transition over a couple of days at the end of April.
I'm including this so you can see what the form looks like when it's actually used as designed. Most demands don't look like this. Most demands look like the next file.
This is the raw export from the demand table. Two hundred and twenty columns, 675 rows. Of those, 413 are Completed, 158 are Draft, 81 are Submitted, 22 Rejected, exactly one Qualified. That ratio alone tells you something about how the workflow is being used.
Categories break down as 474 Operational, 139 Strategic, 62 uncategorized. Most of the columns are sparsely populated. The interesting fields for ingestion are roughly: number, title, short_description, state, category, opened_at, opened_by, demand_manager, assignment_group, approved_start_date, approved_end_date, business_capabilities, business_applications, plus the long-text fields like problem_statement, recommended_solution, benefits, risks.
If you want to start with something concrete, this CSV is the most concrete thing in the bundle. It is also a good calibration set for what the data quality looks like in the wild.
This is a Demand record from the out-of-the-box ServiceNow Strategic Planning Workspace, on a fresh instance. Different field set, different language, different cardinality. Portfolio, Program, Department, Product, Strategic Program, Primary Goal, MoSCoW prioritization, T-Shirt size, Score, Risk, Value, Investment Class, Investment Type, Expense Type. Goal-Target relationships as a related list.
Compare this to our actual blank form above. Ours is heavier on cost-estimate detail and lighter on portfolio-level structure. This is on purpose, but it's also part of why our instance feels Frankensteined. Every customization moves us further from what the SPM module assumes.
"From my perspective, a demand is a record of a business need. The way we treat it, it's a project that hasn't been approved yet. Those are different things, and that gap is most of the problem."
If the Demand form is the heavy machinery, the Idea form is the front door. The BRMs have been redesigning it. This is the most active piece of work in this bundle, and probably the most useful place for Iteright to plug in.
This is the redesigned ServiceNow front-door form for ideas. Author, Requesting Directorate, Requestor or Sponsor, Directorate Funding Project, Request Name, Request Details, Investment Type, Category Alignment, Capability Alignment, Requested Date of Delivery, Estimated Cost, Associated BRM, Associated IT Division. Attachments at the bottom.
Light enough that someone can fill it out in five minutes. Structured enough that we can route it.
The first page lists the fields the form ingests from the SharePoint version: author, directorate, request name, key objectives, data classification, completion date, funding, lab agenda item, BRM, risk-benefit score.
The second page is more interesting. It's the discovery-and-design checklist. Eighteen tasks the form needs to track per request, each with status (Not Started, In Progress, Blocked, Completed, Cancelled) and an assignee. Tasks like Request for Quote, Capital Determination, Build vs. Buy, Initial Solution Design, Requirements Gathering, TIME Evaluation, Architectural Forum Review, Resource Identification, OCM Assessment, RACI, Risk Assessment, MOU, Proof of Concept, RFI/RFP, Budget Estimates, High-Level Timeline, Architectural Evaluation, Cyber Evaluation, ITSD Recommendation. Plus an open comments box that needs to accept new entries each time the form is opened, and attachments.
This is the workflow the BRMs want behind every accepted idea. ServiceNow can technically support it. Whether ServiceNow is the right place to run it, or whether Iteright is, is a real question. The deck is essentially their requirements document for whoever ends up owning the intake-through-discovery flow.
The cleanest pilot integration An idea is captured in Iteright. It's evaluated, scored, debated. If it earns promotion, Iteright pushes a Demand into ServiceNow with the right fields populated, including the BRM, capability alignment, and category. The Demand then runs the existing ServiceNow workflow toward Project. This gives us governed intake without ripping out anything ServiceNow already does well, and it answers the question Tyler asked on the call about where to plug in first.
Seven pages. The Application Development Division Portfolio Plan, viewed in the ServiceNow Strategic Planning Workspace. Prioritization grid (MoSCoW, value vs. effort, primary goal alignment), a roadmap timeline grouped by Knowledge / Management / Operational portfolios, a Kanban view by planning state, and two hierarchy views grouped by Application Model and by Portfolio.
This is what I built in a developer instance to show Andrew and Jay what's possible. It pulls from the same demand and project tables you'd expect, but it adds the planning layer (goals, prioritization, capacity, financials). Andrew got excited about the Ideas module specifically. The roadmap view is the one that makes everyone realize spreadsheets are the wrong tool.
I'm half-skeptical because I've seen what happens when our instance touches a new module. It gets configured halfway, and then the configuration drifts because nobody owns the platform end-to-end. That said, this is the closest thing to a target state we have inside ServiceNow today. If Iteright can either feed this view or replace it cleanly, we're in good shape either way.
Take the demand CSV and try to ingest it. Not because it's clean, but because it isn't. The shape of the mess will tell you more about ITSD in an afternoon than I could on another call. Map what you can. Flag what you can't. When I'm back, we walk through what didn't fit and decide whether the gap is in our data, our model, or yours.
The intake form requirements deck is the second thing. That's the workflow you'll most plausibly own a piece of. If you sketch what it looks like in Iteright, even loosely, we'll have something concrete to put in front of Jay when I'm back.
Everything else is context. Read it as you have time.