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

Goran WitchDoc · ‎12-22-2017

Hi Rob,

I think the docs pretty much explains the reason for both demand and RITM within ServiceNow and as a whole.

Demand :

The Demand Management application consists of tools for capturing, centralizing, and assessing strategic and operational demands. It also provides a single location for managing all the demand information.

The ideation module, integrated with Demand Management, provides an easy way for users to submit ideas and for demand managers to assess before promoting them to demands. Ideation also helps track the progress of an idea as it moves through the demand life cycle (idea to a demand, to a project, enhancement, change, or defect).

Couldn't quick find a good doc page for RITMs. but basically those are for Request fulfillment. Meaning they are connected to the Service Catalog. I would more say that I don't think that you been using RITM for what they are supposed to be used for earlier.

I wouldn't say there is a connecting between RITM and demand at all. When we look at the catalog, you might have a item there for submitting ideas, but that would be a record producer and not generating a RITM.

Does that make sense?

yournamehere · ‎01-02-2018

Thanks for your quick response. Many of our IT departments are dreading the idea of yet another entry point for "requests" from the end user in the form of Ideas, giving them another queue to monitor and manage. After reading your explanation I'm learning that not only have we been using the RITM incorrectly, but I'm also getting the sinking feeling that the root of our issues may go back to the setup of our Service Catalog...To this point we have been driving all customer requests through the Request Item > Feature > Release (or Incident > Defect > Release). With the Demand Intake process, if I'm understanding you correctly, it sounds like we should be replacing our process for RITMs with Ideas: Idea > Demand > Feature > Release? Is there still a place for RITMs after implementation of the Demand Intake process — if so, how do you prevent users from creating RITMs only to require the manual creation of a Demand in order to fulfill the request?

Uncle Rob · ‎01-02-2018

Its one of the best questions in the ServiceNow space in my opinion, but not for the reason you think.

The real problem is at the crossroads of the following facts:
- Catalogs tend to sprawl. Dozens, hundreds, even thousands of things to order.

- Consumers don't give 1 meager low fiber $#!% what record type you prefer to work from

- Consumers don't *want* to be on the portal. They're there begrudgingly... to get something they need to work optimally.

At the intersection is "even if we have a perfect record progression, would people even use it".

Not to say figuring out where to start isn't important. But I think pragmatically its better to focus on ways to *convert* records with feedback to customers. Something like "Thank you for submitting this incident, we've converted it to IDEA00123 and it is now being evaluated for potential release".

Is there room for RITMs after you implement Idea? Unquestionably. In my mind the RITM is there to represent *known workflows*. An idea is an unknown. "Wouldn't it be cool if AppXYZ had its own mobile app" (idea)
"Can I get access to AppXYZ?" (known workflow / RITM)

yournamehere · ‎01-02-2018

Great advice, Robert. I appreciate your response and perspective from the consumer - and I couldn't agree more. With the implementation of another work intake method, one of my main objectives is to impact the customer as minimally as possible while still meeting our executive's overall requirement to see impacts to the IT workforce. The underlying message here is suck it up IT, you're getting another work intake queue to manage.

From an IT process viewpoint, with the implementation of the Demand Intake process, converting RITMs to Features seems to have become obsolete (as it bypasses the entire Demand process). For those of you using the Demand Intake process, if a consumer enhancement request sneaks through the Catalog via a RITM, are you creating an Idea or Demand and then pushing it to a Feature > Release?