A friend asked me "what table should I put my team's work in? Defect? Incident?". That started a conversation about Demand Management outputs.

"What task table do I put the ServiceNow work into" is the wrong question. Work should be in whatever tables quantify that work. Sometimes that will be a range of tables... *EVEN FOR THE SAME PIECE OF WORK!!*. Consider: Customer raises an incident because of an error. We're an agile(ish) team, we know we need dev work to cure the malfunction. We don't know how much effort it is or when/if we'll do it. We create a Demand to assess / approve. That Demand outputs a Defect, & that Defect generates three stories, which go into 1 sprint, which go into 1 release. Count the records. "Only 1 task per thing" isn't a paradigm that will work, especially with complex pieces of work.

If you have a category of Strategic, that opens up types of Project & Enhancements. Things needing significant effort involving multiple parties with control over cost, scope, & schedule should wind up as a Project. Paraphrasing: "we need something new that's also big". Few people have problems understanding this.

If you have a category of Operational, that opens up Types of Change & Defects. This covers types of demands that are known standards for work & thus only need a Change Control. Best example I can think of is opening a firewall, or deploying a new virtual server, or turning on/off some could based compute/storage. They may intake through demand, but they output into something controlled and known: a change.

If you have category of Strategic, you can pick a type of Enhancement. If category is Operational, you can pick a type of Defect. Why do these strange artifacts exist? Defect & Enhancement predate much of ITBM, going back to "Release v1". Since then, agile concepts made significant headway in the market. I'm a HUGE fan of these tables, but only used in conjunction with Demand.

Reason #1: They don't necessitate agile adoption.

Reality check! Not everyone is hip to agile yet. By the time they are, maybe a new work framework will emerge. They still want to distinguish "things we have to repair" from "things we have to build new". In a non-agile shop, Enhancements and Defects can be used in place of Stories.

Reason #2: They're great staging grounds for agile shops?

If you DO operate in an agile-ish framework, Enhancement & Defect records are still useful. Demand is the process of sizing & shaping level of effort & determining appropriate work output. Allowing Enhancement & Defect is a *GREAT* way to hand off to Agile Product Owners / Scrum Masters without making judgments on stories. Enhancements may even get converted to Epics to further flesh out Stories. Eventually, Stories track the work, but who knows if a given Enhancement is 1 story, or 5? Same goes for Defects. Who says what it takes to work a defect to closure? Maybe you need to repair 3 things... each separately expressible as a story.

SPONSORED CONTENT: WHAT'S UP WITH PROJECT STATUS REPORTS?

If you're an ITBM customer you've noticed Status Reports are impossible to configure. They're also difficult to distribute to needed stakeholders, because you first need the project_user role to view them. With VividCharts, we've solved both those problems.

OTHER DEMAND OUTPUT CONSIDERATIONS:

Spend some time adding UI actions so multiple task types can generate a Demand. "I don't know how big an effort this is" = converted to a demand. This includes Incidents, Ideas, "generic" Catalog Items, & custom task types when appropriate.
* "But Robert, shouldn't we work Incidents to closure"? Not on a Dev team. Need to time work with other necessary work? Need to fully understand scope & cost? Convert it to a Demand! It should output as a Defect to create Stories to timebox, sprint, then release.
* "But Robert, shouldn't we work Requests to closure"? Why? What makes someone's generic request more important than a Demand someone else put in? If you need to manage the work in an agile sense, put the request into the Demand table. It could come out as ANY of the 4 outputs
This is one area that's worth spending significant time configuring. ServiceNow's design is definitively biased towards "one task for an interaction"... except for Demand, which assumes a thing may traverse multiple task types. Spend some time thinking about how to notify stakeholders if their tasks "transition" to other types, and how / if those other records close. Also give thought to what records face customers, especially if using Enhancements / Defects. Seen a lot of necessary customization to do things like "close the Enhancement / Defect after all its related stories are closed + email customer along the way".

If you use Closure Codes in ServiceNow, give some thought into what to do if a task type simply changes. A user submits an Incident. We know the Incident is due to underlying code. We need to assess the level of effort via a demand. Create a Demand from the Incident. What happens to the Incident? It MAY be fair to close it so long as you communicate with the customer. But do you close the Incident? Leave it open until teh Demand is done? Leave it open until the Demand and its OUTPUT are done? For my money, I'm for closing the incident and linking the customer's interest to a new record type while informing them. I've gone so far as adding new Incident Closure codes such as "Created Demand"

This gets political fast. The PMO is the usual champion & stakeholder of ITBM deployments. They typically feel Demand is "theirs". If there's one table definitively NOT exclusive to the PMO, its Demand. Project is 1/4 of possible Demand output. Fight tooth & nail to preserve the "this is for everyone" paradigm in Demand. It is NOT easy. Maybe I'll do a post on this some day. Let me know if you'd like that.

DO NOT MESS WITH DEMAND CATEGORY AND TYPE

. This is one of the most common requests I get. It is also one of the easiest ones to reconcile the customer to reality. The 4 outputs of Demand cover almost exactly which outputs make sense. Understand that the Category & Type are more about determining output than any reporting concern. If you need to categories the Demand in new ways, then use a custom field that does not impede Category + Type = Output.

"Yeah but we know what we're do-" SHHHHH!!!! No you do not. You don't know what you're doing, and you're going to collide with a future ServiceNow update. Don't alter these fields.

- Take My Content Survey- Reply to this email with questions & objections! I do my best to reply to every message.

- Make a small donation. I do this all on my own time. Only donate if my work has truly blessed you.