Requirements Gathering for Catalog Items?

jesusemelendezm
Mega Guru

I need to design several catalog items, however the clients don't have a clear definition of the workflow and variables. Whats the best way you have found to capture the requirements from the clients?

 

I am looking for best practice advise on this (templates, methods, and tips).

 

Thank you!

1 ACCEPTED SOLUTION

jemers
Kilo Expert

Hi Jesus,



I generally start out with a basic questionnaire for the client. I work for a healthcare organization, that is broken up into a variety of departments so no two requests are alike.   At some point, I am going to create a catalog item for such requests as a starting point. In the meantime, I schedule a meeting with my clients, provide examples of my past work and go from there. Because I used to work on a help-desk, I have a better insight (in most cases) of what the end-user needs to see in terms of layout, my suggestion to my clients is to keep it simple as possible. That goes for naming the catalog item and placing it on the ESS portal in an easy to find place.  


I make it a point to know who the audience is that the catalog request is going to be submitted by. The form needs to have a certain "flow" at all times.


I get the client's "wish list" and make no guarantees. Although you aim to please the client, best practice still needs to be followed. I try not to get in over my head with complicated process, sometimes it can't be avoided. It's more beneficial to you, the client and the end-user in the long run. Below is an example of the most common questions I ask a client that wants a catalog item created. I use it as a visual aide to begin visualizing the workflow.



1.           List of questions that the user will need to fill out. — an attachment you mentioned will suffice in the format you wish to use.


2.           Decide among the questions which ones are required before submission (mandatory).


3.           Does there need to be a separate section dedicated to other departments that are involved in the process? What type of information do they need to enter on the form?


4.           Discuss your process with all parties involved to ensure that it is exactly how you and other departments involved want it to be.


·                 Initial routing: Who (individual analyst or assignment group) receives the request first, second, third etc..


·                 Email notifications: Does a specific analyst or members of a department need to be notified about this type of request? If so, when? What will the email notification subject line and body contain?



·                 Will the requestor need to be sent a specific notification at a certain point in the process after it has been submitted? If so, when? What will the email notification subject line and body contain?


5.           Is there an approval required? If so, it is for certain individuals or to a certain group? When does the approval need to be requested?


6.           Will users be able to open requests on behalf of others? Does that option need to be made available on the form?


7.           How is your routing determined? Is it straight forward after submission?


8.           Will you need any type of training documentation to disperse to users or team members before the request is posted into Production?



If you are going to use templates, they work for me in the workflow on the catalog tasks. They come in handy when the same department wants a different request but have some of the same assignment groups involved in the process.


Templates will also work to your benefit if you will be using record producers. I am also a huge fan of the order guide.



Sorry for the lengthy reply, I'm just happy to finally be able to contribute something to the community that may help you.


View solution in original post

13 REPLIES 13

Slava Savitsky
Giga Sage

We have certain internal rules and best practices for Service Catalog forms and workflows. They help us ensure that we do not reinvent the wheel with every new catalog item but rather reuse existing pieces. So when a new request comes in, we usually give the requestor a few options to choose from. Otherwise, if they start designing forms and workflows themselves, we will end up with a large number of unique forms/workflows and the Catalog will become completely inconsistent and unmanageable.


I'll also take your input. I agreed with you on that to have a standard. For example, all my catalog items start with requested.for and location. So, I suggested this as mandatory. For the workflow, approvals, and notifications, I am more opened to the requirement since this will always depend on



Thanks again.


KingSukh
Tera Expert

I have developed a feature in ServiceNow that will allow you to document Workflow requirements. If anyone is interested in it($$) please let me know.


Umang5
Kilo Contributor

Hi, do you still have the template?

 

JohnJasinski
Tera Expert

A few ideas ..


  1. Don't talk workflows and variables - talk about what they do
  2. to be an effective BA you must speak their language and translate
  3. Get their supervisor to tell you what his or her team does.   Or,
  4. Get the supervisor to work with their team to document what the team does. Or,
  5. give them a simple workflow to start and build over time gradually.
  6. give them a report / gauge / homepage to view counts and durations
  7. Escalate issue. Or,
  8. Get some post-it notes and a white board. Play the role of Business Analyst (BA).   Or,
  9. get get a copy of BABOK - learn the activities of a BA - requirements elicitation.
  10. get a BA assigned or ask one for support
  11. have the team define their OLA.
  12. Find the one or two most knowledgable people on the team, they can tell you.
  13. find a team which can define their work - work with them first - show by example - come back to the others later.
  14. find a Service Manager who knows ITIL, ISO, BABOK, PMBOK and COBIT - work together for ideas.
  15. if they can't define what they do skip for now - tell them to work on it and contact you when they do.
  16. but you know all this
  17. thanks for letting me share