Work Intake: RITM vs Idea

yournamehere · ‎12-21-2017

Our IT organization is introducing Demand management to our ServiceNow work intake process. Until recently, our IT Service teams have used the RITM and Incidents as our method of work intake. From a RITM we would create FETR if development/configuration was required (Incident -> DFCT) and on to the Release and Change Management.

With the introduction of Ideas as a method of work intake, how do our teams move away from RITMs and management of multiple queues? I see a continued need for Incidents, but the RITM seems to have lost its value. Is there a place for RITMs within the DEMAND management module of SN? If so, where does a RITM fit in the overall flow of work?

Sean Witt · ‎01-02-2018

And on the Product Management side, things are different...

Assuming traditionally that projects are defined as something with a defined beginning and end, product management is inherently different, because products are continually refined via enhancements and defect remediation. So I would see a typical product management in ServiceNow leveraging some or all of these record types:

1. Product (like "Our Customer Service Application")

2. Work performed on this product is organized into Release records

3. The Release record can be further broken down into Sprints (i.e. iterations of work); so a Release called FY2018 Q1 might contain 3 one month sprints

4. Stories are used to capture requirements, and are associated to a product and a specific release, sprint, etc.

You can see and read about these relationships in more detail here > Agile Development tables . There's a diagram that shows how all of the pieces tie together, including where defects and enhancements fit in.

So for teams that are focused on product management, they can manage their work in ServiceNow without touching Idea, Demand, or Project. "Stuff" that comes in to be worked as an enhancement or defect can be related to the appropriate product, release, etc. A lot of companies do this using the story record. Within a product grouping, stories can easily be ranked, assigned to a specific release and/or sprint, Visual Task Boards can also be leveraged to allow for intuitive visual movement of story cards.

Or if your business environment calls for more formal structure and overhead around your product work, stories can be associated to a project plan as part of an agile project phase. So you can have a traditional project plan, with a WBS, Gantt Chart Views, etc. to build some structure over the top of your iterative development work. OOB demand records can be promoted into enhancements or defects...and you could also create idea-like record producers on your portal to feed into stories, defects, enhancements, whatever record types make sense for your environment.

So ServiceNow will let you do hybrid projects, where traditional components of agile product management like stories are contained inside of a project plan. Or you can manage your products without an overarching project plan, using product, release, sprint, etc.

Hope this helps...the platform is flexible, so you can customize it to match your process, but a better starting point may be to first look at the OOB offering to try to leverage it to reduce your initial and ongoing maintenance effort. I don't hear many people in ServiceNow saying they wish they had started out more custom, but we do see a lot of companies working to get back closer to OOB.

Sean

View solution in original post

Uncle Rob · ‎01-02-2018

The whole reason the Demand record exists is to help with the sizing / prioritizing and therefore go/no-go of a proposal. It tracks the work involved in determining if a larger set of work will be done.

"SUCK IT UP I.T."

Kinda. A lot can be done to ease the pain by building mechanisms for records to convert, as I mentioned above. The key would be ensuring the customer has an easy / fruitful experience as much as the supplier side does.

But your struggle isn't new. This is probably one of the toughest nuts to crack given ServiceNow's architecture. The product tends to think of its individual offerings in a vacuum. "Ideation is easy! Just have people use the ideation form"... forgetting that there's probably 5 or 6 places already facilitating that kind of interaction. I don't think they've put enough thought into "how does ServiceNow work for the consumers if everyone is using everything". This is evident from both the UX and the way Workflows are managed.

Sean Witt · ‎01-02-2018

Hey Rob.

The assumed Out of Box (OOB) path for ServiceNow demands is to be promoted into one of four record types:

1. Demands where the Category field is identified as "Strategic" can become:

i. Project

ii. Enhancement

2. Demands where the Category field is identified as "Operational" can become:

i. Change

ii. Defect

So OOB you will NOT see a mechanism to push these ideas and demands into a Feature or Release record. Meaning if you want to stick with that process/approach, you would be doing some customizations from OOB.

I agree with the points from Robert Fedoruk, customers want to submit their ask and receive it without worrying about how the fulfillers categorize the work behind the scenes, but the Service Catalog is designed to accommodate this. Record producers like "Submit Idea" can co-exist in the Service Catalog and portal alongside of things like "Create Incident", along with true catalog items for things like ordering a laptop, onboarding a new employee, replacing a lost name badge. That way the users just have to search for what they are looking for, and then your ServiceNow development team has the appropriate logic and workflow behind the record producer or catalog item to make the fulfillment process efficient.

Most of the companies that I have worked with want to leverage Ideation and Demand Management as a screening process for review and scoring/prioritization of potential projects and enhancements. I have seen less people pursue the "Operational" demands, largely because the overhead involved in gathering business cases, reviewing, scoring, etc. might not be justified for smaller work items like an individual defect. But the OOB offering includes the ability to generate a Change Request or Defect record from an operational demand if that is valuable for your company.

Sean

Uncle Rob · ‎01-02-2018

"I agree with the points from Robert Fedoruk, customers want to submit their ask and receive it without worrying about how the fulfillers categorize the work behind the scenes, but the Service Catalog is designed to accommodate this. Record producers like "Submit Idea" can co-exist in the Service Catalog and portal alongside of things like "Create Incident", along with true catalog items for things like ordering a laptop, onboarding a new employee, replacing a lost name badge. That way the users just have to search for what they are looking for, and then your ServiceNow development team has the appropriate logic and workflow behind the record producer or catalog item to make the fulfillment process efficient."

If that's what the catalog was designed for, its not how catalog consumers are engaging with it in the wild.

Users will always try to find the fastest way to submit. This is why catalogs that have highly visible "report issue" buttons will generate a huge amount of Incidents for stuff that's already available in the Catalog.

That "Submit Idea" record producer co exists besides dozens... hundreds... even THOUSANDS of other options. A needle in a gigantic stack of needles. Waiting to be found by someone who has not one #$%&ing clue that their work type is an Idea vs a Request.

Its the most common ServiceNow problem that (I'll argue) has *absolutely no accommodating design* to remediate. Initial deployment success brings more stakeholders to the catalog. More stakeholders means way more options. Options create taxonomies. Once you hit taxonomies the customer feedback on portal experience nose-dives. Stakeholders respond by demanding their own cordoned off categories that exist at top level

yournamehere · ‎01-02-2018

Interesting...After reading your response, I did confirm that this automated step (Demand > Feature) was being customized for us specifically. Did ServiceNow intend the Demand Process to be completely independent of the Release Management process? I'm having a very hard time wrapping my head around this, as I expected there to be a natural flow or progression:

Request > Evaluation (Governance/Demand) > Work > Release

For those using Demand Management today, how are you progressing to implementation (tracking the work) once the Demand is approved? How do you link back to the Demand from the work being done?

I truly appreciate all of the thoughtful responses on this thread.

Steven G_ · ‎01-02-2018

Hi Rob,

we are using the demand record for sizing of potential projects. our lifecyle follwos the OOB lifecycle: Idea> Demand> Project. Demand can become other records if you make it behave that way (OOB I believe you can make enhancements also to feed your release management app or to feed your agile app). This all goes back to my earlier comment of what is the business asking for and what functionality exist in your licensing model. have you been with your current company since your instance go-live? did you inherit the instance in the current state? what is the Business Requirements you are being asked to fullfil?