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

Steven G_ · ‎01-02-2018

Hi Rob,

From reading you responces I would suggest you go back to your buiness executives and explain the value of process documentation. If you are creating functionality that is not rolling up to a documented process then you will get to a point where your platform will not roll up to its future state. Servicenow Platfrom is in transition right now to a service management methodology (IT4IT), If you are the platform Admin/Developer this is where you get to bring value back to the business in helping them uinderstand where the platform is going and how they should invest in the growth of the platfrom. I hope this helps you a little bit.

lentzjay · ‎01-10-2018

This is a great and "reality" driven conversation, love it! One question though. What is the intended design/proper use in ServiceNow to flow between the multiple record types and multiple modules under each business process domain? Meaning the architecture, configurations and inter-relationships with modules (tables) within a suite, for example this discussion is focusing on ITBM and specifics with Ideation, Demand, PPM, RITM, etc.... One thing I have never seen is a business process management view which could be a reference architecture or a business process enterprise flow view of how ServiceNow "Designed" and "Intended" to use the various modules and record types together from end to end. Everyone company has different needs and I totally agree with KISS when it comes to record producers and too much "Operational Cluter" to get work done. But I would love to see visually how the product management teams, SAs and developers actually envisioned an organization to operationalize something like what this thread is talking about? Does anyone have any end to end process diagrams to share that are built with how ServiceNow designed without customization? What is the underlying model/framework? I think with a LEAN mind and also with the end user both customer and technical experiences. So I'm always asking can we simplify to create a better experience and actually deliver the IT promises of easier, faster, efficient, automated, intelligent and value that you want more of.

nits2 · ‎10-04-2018

Hi,

This is a really great discussion. As more and more IT teams are becoming agile and want to use the capabilities offered by demand management. We are also running into similar kind of issues, where IT teams want to migrate their current intake within catalog requests into IDEA->Demand->Project modules.

But this means that IDEA table is growing exponentially with columns for all sort of questions. I was wondering if the ideal way is to still continue to use catalog but generate an IDEA or Demand from it?

If you can share which module you ended up choosing eventually and why, that would help me understand this a better.

Thanks

Inactive_Us1852 · ‎11-18-2020

Don't really have an answer but given that this question was submitted before the Idea Portal was added to the ITBM product, I think it is worth revisiting.

I am interested in your view of having 2 portals: i.e. the "Service Portal" plus the "Idea Portal". Seems to me that if the function to collect and assess changes to your existing application is not already part of your Service Catalog, it would make sense to start with the Idea Portal. However, isn't it better to have just 1 portal and offer all your services from it?

Inactive_Us1852 · ‎05-07-2021

Great discussion and so relevant to what we are facing currently. Any input from more current experiences would be valuable.