- My View
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?
I think the docs pretty much explains the reason for both demand and RITM within ServiceNow and as a whole.
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?
ServiceNow Witch Doctor and MVP
For all my blog posts: http://bit.ly/2fCzj1g
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?
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)
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?
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.
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:
2. Demands where the Category field is identified as "Operational" can become:
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.
"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
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.
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?
My take would be that ServiceNow Out of Box (OOB) makes a distinction between Product Management versus Project Management. There is some overlap between the two areas, and SN has always pitched the offering as capable of managing hybrid projects (meaning stories and other components of Agile Development contained inside of a traditional project plan). So you can live in both worlds...
But the OOB Demand Management solution is in some ways better targeted to the Project Management tools, because if you are going to spend the time to gather business requirements, survey portfolio stakeholders, score the demand, etc. you typically are making that investment for the big stuff (i.e. projects) versus smaller chunks of work.
Typical OOB flow would be Idea Submission > Idea Review (Accept or Defer decision) > Accepted Ideas become draft Demands > Multi-step Demand review process flow > Approved/promoted Demands can become a Project, Enhancement, Change Request or Defect record.
This flow gives your reviewers/fulfillers multiple stage gates to accept or defer an idea, same for a demand. So that covers the evaluation/governance piece that you referenced.
The tracking the work/progress piece is normally handled in three ways:
1. Custom email notifications (note that there are minimal OOB notifications for Ideation & Demand Management) for things like notifying a submitter when an idea is accepted or deferred, demand gets promoted to a project, etc. While this is a customization to create these, it is not a lot of work; you will probably spend more time writing up the wording for the notification than it will take you to build and test it.
2. Displaying the source record and a link to it on the next record in the process flow...meaning on the demand form, I display a field system populated with the source idea number. This allows my users to hover and view details about the source idea, or click to drill back into that source record. Same deal for a project created from a demand...
3. System pass/populate some information forward when an idea or demand is promoted forward in the process. For example, business case information or resource plans tied to a demand can be passed forward to the project that is created from the demand. At the point in which you accept an idea, you are done working it and begin dealing with the demand record. Same thing when the demand becomes a project or enhancement. So you push forward the pieces of information that are still relevant for the next step in the process flow...
The approach is to inform the appropriate stakeholders (submitter, fulfiller, whoever) as an idea moves forward or backward in the process flow, and provide the link (i.e. PRJ001001) so that they can check status, with those forms also offering pointers back to their source idea/demand records.
Sorry, this message is getting long...I'll send a separate one on the Product Management piece, which I see as being a little bit different for most implementations.
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.
Wow, thank you so much for your insight. It is all starting to come together for me now. It seems to me, based on your response, that we are attempting to force-feed the Product Management approach down the throat of the SN Demand Management - routing all development requests to a Demand and then adding customization to bring us back into Release Management. It is due to this approach that I have attempted to compare an Idea to a RITM...Not realizing that moving from a Demand to a FETR was customization that we would be adding just contributed to by confusion.
This sure feels like a lot of administrative work for small requests. If this is our desired process moving forward, I'm thinking we would have to disable the ability to move from a RITM > FETR, otherwise, folks would take the easy route and always bypass the Demand evaluation...Just one of the many concerns I have with our approach.
We are in early discussions of moving toward this approach now, which is why I have so many questions. Thanks again for your input.
Yeah, when we demo Demand Management from start to finish, and show an idea getting reviewed and accepted, then moving through all of the stages of demand, after about the 20th click light bulbs start going off around the room. It is a great process for the items worthy of that degree of thorough, comprehensive review, but I don't think any organization would want to push all of their "idea" type traffic through the full gauntlet.
Good luck with your internal discussions, usually the hardest part is figuring out when a fast lane/bypass around the process is acceptable so that your demand managers only have to focus on the important stuff. And it may help to read up on record producers on the docs site...the idea of the record producers being that you can expose a form on the portal or Service Catalog to gather data, and then push it on submission to whatever the appropriate record type is (idea, demand, defect, enhancement, etc.). So maybe there are only 2-3 questions that you ask someone to submit what becomes an idea, but you ask more questions for enhancement requests to gather more specifics.
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.
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.