Work Intake: RITM vs Idea

yournamehere
Kilo Contributor

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?

1 ACCEPTED SOLUTION

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

21 REPLIES 21

User394596
Mega Contributor

This has been a great conversation.  I'm curious how partners have gotten customers to embrace the differentiation between requests (RITM) and ideas. From how we've approached it, a request is either a process that can be automated via the Service Catalog or something that fits into a catch-all catalog item since it's not possible to automate every operational request type (i.e. build a report for me or grant my team member access to an application).  An idea by contrast requires an assessment to confirm the ask aligns with organizational objectives (i.e. I want a new application or I'd like to see enhancements to an existing application). Has anyone developed a customer-accepted governance model that gives clear examples of the differences between requests and ideas?

F_Fairley
Tera Contributor

@yournamehere @User394596 did either of you (or anyone else on this thread) set up a process for converting service requests to demands (or ideas) for those cases where the user inadvertently submitted a service request when an idea/demand should have been submitted?