Service-now.com Project Management Observations

General Add comments
by:

This subject might be a bit ‘of topic’ as I do not have a focus on the SNC application itself.
I will not go into any technical details nor describe how to configure Service.now.com.

Still interested?

I am working as a Project Manager and I’m managing and have managed multiple projects, delivering the SNC solution for large companies.
In this topic I like to share a number of observations related to managing SNC projects.

Before going into detailed observations I like to make a statement first.

“In principle a SNC project does not differ from any other project. As with every project you have to manage items like: scope, timelines, resources, risks and quality”.

Having said this there are a number of observations I like to share that are challenging or at least different when you need to manage a SNC project.

1. SaaS

Software-as-a- Service is a beautiful concept and I like it. However, when managing projects I always seem to end up in discussions about technical details of the solution in the SNC datacenter.
Common questions are:

  • How is the SNC datacenter setup?
  • Is SNC using firewall(s)? If so, what are the settings?
  • What type of database is being used?
  • Is there a Data Recovery plan?
  • Etc, etc….

If you follow the SaaS-concept these kinds of questions should not be relevant, however most customers do demand the information. And in some cases the information is needed to assess compliancy. A simple “we do not have this information” does not work and can endanger the buy-in of your project.
Referring the customer to the SNC Wiki documentation pages is a better solution and – if needed – SNC can help you with publicly available documentation.

2. Communicating with Service-now.com

In general there are no SNC contacts persons readily available where you can discuss project-related items. Communications are directed to the service portal by logging requests, cases or questions. As a project manager I am used to having escalation-points, formal supplier contacts, because these are useful in case of real emergencies. At this moment there is no solution for the lack of contacts, so my motto is: Live with it!

That’s the way SNC works. If you find a way to adapt to this way of working you can actually benefit from it! The only thing you need is to make sure your project members have the proper access to the SNC service portal, priority 1 request do have the attention of Service-now.com

3. Flexibility

SNC’s flexibility is a great feature. It is easily adaptable and configuration changes are simple. Staying in control as a project manager on the other hand is not easy due to this flexibility. It is very easy to make changes to the tool without any registration or approval of the correct stakeholders. To me there are 2 ways to handle this and these really depend on the approach and the customer environment.

  1. In case your customer is an informal organization, you can apply a Rapid Application Development method by doing workshops, adapt the tool, show the results, configure further adaptations. Repeat this cycle until the module is ready. Document the changes and go live. (this is a simple way of looking at the world)
  2. In case the organization or environment is more formal, like an organization which needs to comply with many quality requirements or regulations, you may have to use a more traditional development method. Sign-offs is a most commonly used term. Below I have written down a number of rules you might need to apply in these formal environments. They are simple and straightforward but are in many cases overlooked. In other words: start with the obvious!

Rules of thumb:

  • Stay as close as possible to the Out-of-the-box configuration;
  • Make sure all stakeholders are aware of the previous point;
  • If changes in the configuration are required, document and register them beforehand; that is before building them;
  • Make all changes traceable by defining requirements, specifications, tool changes, test scenarios and test cases. We are using a requirements module for this. (If you are curious about managing requirements in a SNC projector environment, please refer to the Wiki pages or wait for my next blog);
  • Have a process in place agreed by all stakeholders for requirements management, including proper approvals.

In general:

  • Plan an describe your changes
  • Build your change
  • Proof they are working

To conclude my blog: I have written down a number of items related to SNC Project Management, including a number of high level suggestions. I have no doubt there are lots of other topics relevant to a SNC project and that is why I am very interested to hear about other experiences related to Project Management within a SNC project. Please do not hesitate to share your thoughts by commenting on this topic or contacting via email on jaco.van.der.niet@2e2.nl.

Leave a Reply