Work Intake: RITM vs Idea

[yournamehere]

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]

Hey Rob.

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.

Sean

[Sean Witt · 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

[Uncle Rob]

Great knowledge dump here.

[yournamehere]

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.

[Sean Witt]

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.

Sean