25 common challenges in ServiceNow projects

<< following article was published and shared by Zalan Heil, a ServiceNow expert with over a decade of experience with consultancy practice management, business development, project management, business analysis, solution architecture, and technology development. He has worked in multinational teams from the EU and the USA. >>

The pointers he has shared, are very useful and following his recommendation can help many to achieve success by avoiding the pit-falls.

x-------------------x--------------------x--------------------x--------------------x-------------------x

ServiceNow projects have several challenges, just like any other projects, and if these challenges are not dealt with, it usually means that the projects will fail to deliver some of the expected results. My objective is to help customers, as well as members of the ServiceNow consultancy community, identify and overcome such typical challenges.

This post addresses the following 25 challenges, their symptoms, and recommendations on ways to deal with them:

1. Project goal setting and scoping;

2. Senior ServiceNow expert involvement;

3. Big-bang vs phased approach;

4. Configuration versus custom development;

5. Implementation accelerator;

6. Geographically dispersed team;

7. Silo thinking;

8. Service provider selection;

9. Resource estimate;

10. Project scheduling;

11. Project budget and cost management;

12. Solution design and development;

13. Project integration and dependencies;

14. Project support tools and techniques;

15. Resistance to change;

16. Stakeholder identification and involvement;

17. Project responsibility and team member skill;

18. User acceptance testing (UAT);

19. Documentation and training;

20. Project communication;

21. Project change management;

22. Project quality management;

23. Project risk management;

24. Early life support;

25. Transition to support.

Let us look at some relevant statistics, whilst keeping in mind the famous quote: ‘There are three kinds of lies: lies, damned lies, and statistics’. Despite this quote, I am confident that most members of the ServiceNow community will agree that various challenges in our projects, mostly regarding stakeholders, processes, and technology, are common.

So, what does statistics say about projects in general?

• Only 2.5% of companies successfully complete 100% of their projects.
• Around 50% of projects fail to achieve all the original objectives or fail completely. This percentage varies based on the source of information, but around 50% seems to be a good estimate.
• The average project budget overrun is around 27%.

(source of statistics: PwC and KPMG)

Those numbers are very likely to be not fully accurate or not completely in line with one’s experience, because they can depend on a number of factors, but the angle of those statistics is clear.

Why are those statistics important in ServiceNow projects, and what do they tell us?

• Even though we can see an increasing number of customer success stories on social media, if we assume that the aforementioned statistics are correct and are not afraid to use our common sense, whilst being skeptical about excessive marketing communication, we will observe that the vast majority of service providers, including those who publish their customer success stories, will fail partly or sometimes completely in a number of their ServiceNow projects no matter what their communication suggests. For instance, a normal ‘textbook’ project execution rarely occurs, and in today’s CSAT score-oriented service provider culture, it is very difficult to tell in advance whether a service provider’s service quality meets expectations.
• On an average, projects seem to be nearly one-third more expensive than the originally planned budget.

As a result of these factors, I thought that it would be useful to review the typical challenges in ServiceNow projects as well as the best ways to deal with them. However, this article does not focus on service provider quality, marketing, and communication practices. These topics are probably worth a separate blog post, especially because I think that it would be beneficial for everyone if, from time to time, service providers also published the way they failed with their projects and the lessons they learnt from those failures, instead of focussing solely on communicating their polished success stories.

Here are a few common challenges I have observed from my experience in ServiceNow projects and some practical advice on the ways in which one can deal with them:

1. Project goal setting and scoping challenges

Symptoms

• Such challenges arise when the list of project goals, along with related deliverables and tasks, is missing. This is an issue for not only larger ServiceNow projects but also smaller ones that can fail to deliver if the goals are not set transparently. This could happen since there can be unexpected dependencies, constraints, or other issues affecting the project, for example, another project with overlapping goals and features.
• When the project scope is incomplete, its impact on the stakeholders, processes, ServiceNow applications and third-party applications is not completely clear. For instance, the project is supposed to implement a CMDB in ServiceNow, but change management is missing from the project’s scope meaning, such that the CMDB – unless the configuration items are automatically populated– will likely be up to date only for a very short period after production deployment, owing to untracked changes in the CMDB after deployment.
• When out-of-scope items are not defined, some stakeholders can misunderstand what is included and what is not. For example, when only SLA definitions are within the project’s scope, but some stakeholders expect a performance analytics’ historical SLA trend dashboard as well, it is best to define in advance that the dashboard is excluded from the project’s scope in order to manage stakeholder expectations.
• When a project has no goals, scope, deadlines, or resource plan, it is most likely to not be a project at all but a bit more like business as usual or support-type work.

Recommendations

• ServiceNow project goals are recommended to be defined and agreed. Moreover, they are required to not only be specific, measurable, action-oriented, realistic, and time-bound (SMART) but also frequently discussed, ambitious, specific, and transparent (FAST).
• A clearly defined project scope serves as a critical success factor of every ServiceNow project. The list of expected deliverables as well as the ServiceNow applications and plugins to be deployed or customised should be defined, in addition to the impacted stakeholders, processes, third-party tools, assumptions, and out-of-scope items.

2. Senior ServiceNow expert involvement challenges

Symptoms

• These challenges arise when no senior ServiceNow experts (e.g., solution architects, champions, or senior consultants) are involved in the project’s preparation, planning, and execution phases or their involvement is insufficient. This lack of senior expert involvement can cause a large number of issues, ranging from unrealistic resource and time estimates to inefficient solutions and so on.

Recommendations

• In every ServiceNow project, a senior ServiceNow expert (usually with over four years and over 10 ServiceNow projects experience) should be involved, who can at least review the project goals and deliverables, coupled with the solution design, and can be consulted during the project. In addition, if possible, it is best if such senior ServiceNow experts can actively participate in the project by being responsible for developing the solution design, managing project deliverables, and bridging information and knowledge gaps between stakeholders. Furthermore, they should manage expectations at all levels of the project stakeholders in order to ensure that the project objectives are realistic and the project’s execution is smooth.

3. Big-bang vs phased approach challenge

Symptoms

• In ServiceNow projects, a dilemma often arises about how much of the features should be put in the first release and how much should be scheduled to be included in future releases. When the project’s scope includes tasks performed for over a few hundred man-days spread across a couple of months, such a project is usually said to have a big-bang approach, which means that the solution contains a significant amount of new or changed features. Usually, the larger the project, the higher the risk concerning the project’s scope, resource, cost, and time management.

Recommendations

• Prioritise project objectives and divide the project into multiple phases and releases as much as possible. If there is no other way but to adopt the big-bang approach, even then set up multiple project streams and reasonable milestones, for example, still try to split the project into multiple parts in order to manage them more efficiently.
• Even a project’s planning and execution phases can be delivered separately to minimise execution budget risk by allocating only a solution design budget at first.

4. Configuration versus custom development challenges

Symptoms

• It is common for less experienced project stakeholders to be in the ‘out-of-the-box mirage’ for some time. This is most likely a consequence of related marketing communication and, in general, an admirable goal, as I can recall that around ten years ago, ServiceNow extensively used studies in their marketing activities promoting the SaaS model, demonstrating that IT services were becoming more and more like utility services. After ten years, we clearly got closer but are not there yet in terms of enterprise service management. So, there are probably one or more decades to go in this regard. Until then, the reality is that even custom development is usually difficult to avoid, but some configuration – other than what is included in the guided setup – is almost always necessary in ServiceNow projects.

Recommendations

• Keep in mind that out-of-the-box usage is not realistic in most cases. Thus, instances are nearly always configured with some customer-specific process logic, and the out-of-the-box functionality is often extended further with custom development, e.g., scripting.

5. Implementation accelerator challenges

Symptoms

• When the time required to market is a high priority, a complete ServiceNow environment or a single application needs to be rolled out quickly.
• When there is a strong budget constraint, the implementation project needs to be short and is required to deliver reliable results with a proven and tested rollout approach.
• When it is acceptable to have a solution built on industry best practices and service provider experience, there is no need for extensive customisations.

Recommendations

• Review the offered ServiceNow implementation accelerator’s features. Moreover, ask the service provider to provide a comparison list between the features included in their implementation accelerator and the out-of-the-box ServiceNow features in order to understand the offered solution’s added value.
• Check the offered implementation accelerator’s features in practice, not just in terms of marketing materials. In addition, ask for a demo environment from the service provider and have your process managers test the processes in that environment. Subsequently, compare the offered features with your requirements to analyse whether it is worth investing in the purchase of the ServiceNow implementation accelerator or if your requirements are completely different compared to the features and facilities offered by the implementation accelerator package.

6. Geographically dispersed team challenges

Symptoms

• These challenges arise when the members of the ServiceNow project team work from different locations or from home most of the time.

Recommendations

• Conduct frequent project status meetings with stakeholders, with communication updates, as well as regular, if possible daily, stand-up meetings with developers.
• Maintain a central project task and issue repository that is easily accessible for all project stakeholders in order to support transparency.
• Provide multicultural awareness coaching, which comes handy if the project is executed in a multicultural team setup.

7. Silo thinking challenges

Symptoms

• Such challenges arise when ServiceNow project stakeholders, especially process owners and managers, request unique and custom solutions that are often related to their area of responsibility only or they come from legacy toolsets.
• In these cases, it is difficult to convince the project team to move in the same direction, because the stakeholders think about their own areas of concern rather than the bigger picture.

Recommendations

• Place strong emphasis on the ServiceNow solution architect role to ensure that standard solutions are implemented across impacted functional areas and processes.
• Provide extensive training and coaching to project stakeholders in order to show them opportunities regarding the ways in which the automation of their own areas can be improved and made more efficient with the help of ServiceNow solutions.
• Make stakeholders from different service lines communicate with one another to discuss their challenges and agree on potential solutions together. It might come as a huge surprise but colleagues from different fields can in fact learn a lot from one another.

8. Service provider selection challenges

Symptoms

• In such challenges, there are frequent issues with the current service providers. The projects are late either due to deadline breaches or ‘mutually agreed’ reschedules over the budget. Moreover, the service quality is below expectations, or a reactive approach is adopted towards problem solving with frequent firefighting, and so on.
• Service providers are usually focussed on sales and marketing and tend to treat their customers with higher priority in the beginning, by allocating senior experts on projects, which can easily change later or even immediately following the preparation and presales phase. This means that less experienced consultants can be included in the project team, thus increasing the project’s execution risk.

Recommendations

• When looking for service providers, ServiceNow’s public partner finder page on its website, a web search, and service provider adverts can all be useful sources of information. Certain basic partner statistics are there, including CSAT, e.g., customer satisfaction score. However, keep in mind that a strong CSAT score orientation exists in the service provider community. Hence, it is highly unlikely to come across service providers with bad CSAT scores. In fact, a minimum CSAT score of 8.5 out of 10 is required to even be listed on the official partner finder page. Thus, in reality, CSAT scores mostly indicate the service providers’ account management effectiveness rather than their actual service quality. Partner events such as Knowledge, NowForum, NowSummit, SNUGs and the like can also be useful to talk to the members of the community and find new service providers.
• In general, it is recommended to be open to new service providers and to work in a multi-provider setup. Moreover, a planned service provider screening approach makes it easier to find the right service providers for the projects and support services. As a result of continuous market consolidation and acquisitions, several experienced ServiceNow experts tend to leave larger service providers. Hence, there is a continuous supply of emerging service providers in the market, who can often do a better job than their larger competitors at more affordable prices.
• An efficient way to determine whether a service provider is the right one is to talk to the service provider’s non-sales-oriented staff members. Look at their experts’ profiles on LinkedIn; ask for a demo from them. Moreover, have your own experience with their consultants in the presales phase, and if possible, do the same in a smaller lower-risk project first. Exploring new service provider opportunities is usually worth the time investment.

9. Resource estimate challenges

Symptoms

• When the ServiceNow project’s resource estimate does not seem to be in line with the project’s scope, a breakdown of the estimate is missing, or the estimate was provided by someone who has less experience with ServiceNow.
• In these cases, a fixed-scope fixed-price project is requested, even if the project’s scope is not defined appropriately.

Recommendations

• A ServiceNow project’s resource plan is usually either based on a fixed scope and price or is determined on a time and material basis. Fixed-scope fixed-price projects are recommended only when the projects’ goals and scope are defined in detail. Otherwise, there will be a significant risk of budget overrun or poor service quality, accompanied with late delivery. For more details on this topic, e.g. trading between project constraints, it is recommended to look up the ‘project management triangle’.
• On the other hand, time and material projects are recommended only with proven service providers, because a less experienced service provider can use far too much resources and time in a time and material setup. Hence, the latter is considered to be a higher risk for the project’s successful execution.
• Resource estimates are key in ServiceNow projects, as huge differences can exist in the market. In my experience, larger service providers can easily be three times more expensive than their smaller competitors, and this is not only about the daily rates but also work estimates derived from resource-efficiency, risk-taking appetite, and a pressure for profitability. Larger service providers are often less efficient, less risk-taking, and have a higher pressure for profitability in comparison to their smaller competitors. In practice, this means that service providers’ daily rates themselves are significantly less important than they are thought to be. On the other hand, resource estimates are significantly more important to determine the real cost of a project and efficiently compare service providers’ quotes.

10. Project scheduling challenges

Symptoms

• These challenges arise when there are frequent deadline breaches or reschedules in a ServiceNow project. In such cases, even if deadline breaches seem to be the major symptom, in reality, based on our experience, reschedules are becoming far more common, without people realising the same. A reschedule is a kind of deadline breach wherein both the customer and service provider agree that they cannot deliver something on the originally planned time owing to various reasons, such as inefficient planning, unexpected technological challenges, lack of skilled resources, and so on. Thus, they postpone the target delivery date. However, even if they do so based on mutual consent, the reschedule is often a deadline breach, which is communicated carefully to avoid a negative impact on the project managers and sponsors’ reputation as much as possible. Hence, in many cases, it still indicates poor service quality.
• In such cases, stakeholders act in the project with a mostly reactive attitude due to the lack of priority, time, attention, and so on.
• There are project dependencies that become known only during the project, such as the cloning of ServiceNow sub-production instances for a higher priority project.
• In these challenges, project scheduling changes give rise to resourcing issues owing to the need to change previously planned and agreed resource allocation on the current and other projects.
• Stakeholders have to multitask a great deal between parallel projects, causing delays due to their inability to focus on several projects simultaneously.

Recommendations

• When planning a ServiceNow project’s schedule, be realistic about the tasks’ duration and effort required, with the help of a senior ServiceNow expert who can make accurate estimates. Look for project dependencies continuously, not only at the beginning of the project, and take in account people’s real availability, including holidays, and their expected level of utilisation.
• Take into account that project reschedules are likely to have an impact on resource allocation and cause availability as well as utilization conflicts. It is recommended to check such kind of conflicts before agreeing on reschedules. Further, if those conflicts are confirmed, take them into account and communicate them transparently.

11. Project budget and cost management challenges

Symptoms

• These challenges arise when there is a high pressure on the ServiceNow project budget and on those who are responsible for the budgeting.
• In such cases, project budget overspending occurs due to various factors, such as inaccurate work effort estimates, under-specified requirements, incomplete scope, high technology complexity, changing expectations regarding the project, among others.
• There is no allocated budget even for essential scope changes, if or when they become necessary.

Recommendations

• It is recommended to split ServiceNow projects into multiple project phases in order to manage the project budget efficiently. The advantage of an agile project management approach is that the requirements, e.g. user story backlog, can be split into multiple parts based on the project stakeholders’ priorities.
• Track earned value in the projects. There is no need for a sophisticated tool or a time-consuming calculation; just simply look at the resources used till a point of time, along with the project tasks completed or features delivered, and if there is a gap, it is time to make adjustments.
• Allocate a 10–30% contingency budget for potential scope changes, depending on the complexity of the projects. For instance, a more complex multi CI-class CMDB project with integrations is more likely to result in multiple scope changes, thus requiring a contingency budget, whereas a simple SLA project is less likely to require a contingency budget.

12. Solution design and development challenges

Symptoms

• In these challenges, specific ServiceNow project objectives are unclear, and business requirements are underspecified.
• When no ServiceNow solution architecture and design plans are in place, it is unclear what exactly will be implemented and how.
• When scrum stories are missing, they either have a very high level or are of poor quality. For example, they are not specific enough to deploy features based on them.
• When developer skills are insufficient to design and develop the required solutions, and the developers simply deliver too many defects and known errors before production deployment.
• In such cases, ServiceNow license financial aspects are not taken into account when designing a solution.

Recommendations

• The business requirements should be documented and communicated with all project stakeholders transparently. Moreover, the main objectives and list of deliverables are required, even if a project is executed in an agile manner. It is important that a solution architect reviews them. Otherwise, the technology risk can especially be high during the execution of the project. For instance, an integration was supposed to be direct, but instead a MID server is required between the endpoints.
• Have an efficient methodology for project management, such as an agile development framework. Agile is good when shooting for moving targets. The necessary tools exist in ServiceNow. Thus, there is an Agile Development application built into ServiceNow, which can be used to manage the project as well as the requirements, tasks, scope changes, and so on.
• Waterfall is out of fashion. However, in a fixed scope project wherein the requirements are well defined, it is still the most efficient way to execute the project, one step after another. Even though the requirements are called stories, the execution phases are called sprints, and the developer team is called a scrum team to make the terminology trendier.
• ServiceNow license financial aspects should be considered when designing a solution. For example, a custom ServiceNow application can easily cost much more owing to the user licensing policy than extending the functionality of an existing out-of-the-box ServiceNow application, in order to cover the required functionality.

13. Project integration and dependencies challenges

Symptoms

• A ServiceNow project can depend on other projects. For instance, placing some new ServiceNow application features on the Service Portal, before a new Service Portal version is released, usually means that the deployment of those new application features will have to wait until the new Service Portal version is deployed. Another typical dependency is when some kind of data transformation and data cleaning are required for the migration of the business data into ServiceNow.

Recommendations

• Identify project dependencies as early as possible, and take them into account when planning the project and when executing it. If the situation is uncertain regarding a dependency, include the dependencies in the project risk register, and review the said dependencies’ status regularly.

14. Project support tools and techniques challenges

Symptoms

• In such challenges, a ServiceNow project’s communication is dominantly email or voice based.
• There is extensive spreadsheet usage during the project.
• There is a lack of shared project requirement, solution design, scrum story, project task, and progress report repository.
• Moreover, multiple tools are used (for example, Slack, Teams, Yammer, SharePoint, ServiceNow Agile Development, Email, Google Sheets, and so on), and this is confusing for the project members.

Recommendations

• Although any kind of project management tool and methodology that make sense can be used, SIM (ServiceNow Implementation Methodology) and SAIF (ServiceNow Adaptive Implementation Framework), previously called StartNow, are very effective in this regard. These are proven methodologies with several templates that can be downloaded from the ServiceNow Partner Portal. Further, the ServiceNow Agile Development application can be activated as well. Hence, it is recommended to use these tools instead of reinventing the wheel or managing ServiceNow projects in an ad-hoc unorganised manner.

15. Resistance to change challenges

Symptoms

• Such challenges arise when there is significant resistance to change from stakeholders, which can be caused by favouring a legacy tool, legacy ways of working, or simply by the organisational culture of the company.
• When the ServiceNow project’s stakeholders are overutilised, they handle the ServiceNow project with lower priority, and it is inconvenient for them to invest their time on changing something that is within the range of their toleration capacity.
• When the analysis and communication of the project benefits are missing, the reasons for which they should execute the project is unclear to the stakeholders when they will receive no benefit from doing so; on the contrary, they are likely to experience an increased level of administrative workload.

Recommendations

• Management commitment and continuous management involvement are important to support change, and project stakeholders’ involvement is also key, just as the communication of project benefits with them. In addition, motivating project team members with the opportunity to acquire new and marketable skills in a ServiceNow implementation project can be helpful. Further, it is usually easy to convince stakeholders about this because ServiceNow was reported to be the most innovative company of 2018 by Forbes. Thus, it is fair to say that ServiceNow-related skills are competitive in the market.

16. Stakeholder identification and involvement challenges

Symptoms

• In these challenges, the identity of the users of the solution delivered by the ServiceNow project is not clear. Hence, their expectations and inputs are not taken into consideration.
• Some of the key stakeholders are not involved, who represent the areas that are supposed to use the delivered solution. Moreover, their approval for the requirements, solution design, sprint demos, or user acceptance testing is missing.
• The project is a low priority for the stakeholders in the planning phase, and no feedback is provided in this regard. However, later when they realise that soon they will have to start using the solution, they provide more feedback that changes the planned solution significantly.

Recommendations

• Conduct a detailed project stakeholder identification as early as possible, and manage all stakeholders actively, in accordance with their interest and role in the project. Remember that ServiceNow is a platform for numerous applications, and these applications are easy to integrate. However, the majority of the key applications have different owners. Thus, bridging the gaps between them is a critical success factor in ServiceNow projects wherein multiple applications are affected.

17. Project responsibility and team member skill challenges

Symptoms

• When it is unclear who is responsible for what in a ServiceNow project, the project team members can possibly work on any of the open tasks, ranging from planning to development and testing. In addition, it is unclear who is actually responsible for the deliverables that they are involved in. Thus, as soon as the task goes south, fingers are pointed at someone else.
• The project team members’ skill levels are unclear or extensive development is required in the project. However, only citizen developers (e.g., low skill developers who can usually perform ServiceNow configuration and only some limited scripting) are assigned to the job.

Recommendations

• The most common responsibilities that should be defined in ServiceNow projects include those of product owners, business analysts, solution architects, project or engagement managers, developers, testers, among others. Such responsibilities should be clearly defined, and the project team members should be assigned to these roles with their consent.
• Project stakeholders’ skill levels should be clear and should be taken into account when assigning project tasks. For instance, in a story backlog, during sprint planning, the story point estimation should take the assigned developers’ ServiceNow skill levels into account.
• The project team’s morale is as important as their skills. Hence, the team’s attitude and proactive behaviour are critical success factors, which means that maintaining the team morale at an optimal level is an important task for effective management.

18. User acceptance testing challenges

Symptoms

• In such challenges, there is insufficient user involvement in user acceptance testing during a ServiceNow project. Thus, either not enough users from the impacted usage areas are involved or their level of involvement remains on the surface level only.
• There is a lack of sufficient feedback from the testers included in the user acceptance test. For example, the number of responses is too low or the quality of the responses prevents developers from finding and correcting defects.

Recommendations

• Set an agreement in place at an early stage of the ServiceNow project with the managers of the impacted project areas to ensure that appropriate level of participation is achieved in user acceptance testing.
• Focus on the preparations of user acceptance testing, which includes planning with a defined set of test cases and defining a test execution plan with related test scenarios, especially when the project or user acceptance testing is executed in a virtual team setup.
• Communicate with testers the factors that should be tested and the way an issue report looks like. For instance, users should be expected to provide a description of their tests, most of the time, and attach screenshots.
• In addition, the Automated Testing Framework application in ServiceNow – which is a part of the core platform – can also be helpful when there is a need to test the same functionality repeatedly, for example, following ServiceNow platform upgrades.

19. Documentation and training challenges

Symptoms

• In such challenges, it is unclear what the original plans were and what the changes are in a ServiceNow project, due to frequent and un-communicated changes.
• The handover for support is chaotic, and there is no sufficient information to support the solution. Thus, the original developers need to be contacted frequently after production deployment.
• Users cannot use the solution efficiently after production deployment, despite the delivered functionality that meets expectations.
• New users who start using the delivered solution later have no learning materials. Hence, they cannot use the solution efficiently.

Recommendations

• Track the changes made in the plans and implemented solutions in order to document the solution at the end of the project, so that users can easily be trained and further changes are easier to make in the rolled out functionality.
• Document the solution to improve supportability and to properly hand it over for support. This should be done to also ensure that future modifications can be implemented efficiently without the need for reverse engineering the solution owing to the lack of documentation. It is useful to use the originally documented user stories, solution design plans, and user acceptance testing cases as a basis for a ServiceNow solution’s admin, user, and possibly end-user guides or other such training materials.
• Ensure that there is planned knowledge transfer between the delivery and support teams.
• Prepare training materials on the newly implemented solution to ensure that new users of the solution can use it efficiently.

20. Project communication challenges

Symptoms

• Such challenges arise when ServiceNow project stakeholders do not have clear information about what is happening with the project and what tasks they need to focus on.
• Stakeholder expectations and feedback are not collected during the project, with regard to the solution design, sprint results, testing results, to name a few.
• Project milestones and task deadlines are not clear to the stakeholders. They are only involved in a project that has no real project attributes such as a scope and schedule.
• There is no agreed meeting plan, which especially causes issues if the stakeholders are typically busy.
• Periodic communication concerning the project status is missing or not shared with all of the stakeholders whom it may concern.
• When a project manager is primarily engaged in forwarding emails or probably organising some meetings but provides very little other additional value to the project.

Recommendations

• A detailed project kick-off as well as frequent workstream discussions should be scheduled with all of the ServiceNow project stakeholders.
• Expectations regarding the project should be gathered from as many stakeholders as possible, because in addition to the officially agreed project goals, stakeholder opinion is a critical success factor. It is usually best to collect expectations as much as possible from the project’s preparation phase in order to avoid project scope changes and other such surprises.
• Communicate with stakeholders periodically with respect to the milestones, open tasks, and status reports. Hold regular scrum team stand-ups and schedule meetings in advance as much as possible, thinking about the next project phases as early as it can reasonably make sense. Using the ServiceNow Agile Development application can help significantly with transparency and with improving the communication between project stakeholders.

21. Project change management challenges

Symptoms

• In such challenges, a ServiceNow project’s preparation is inefficient. Hence, after the preparation or presales phase, the aspects specifically within and beyond the scope of the project are unclear.
• Project change requests that are either new, approved, rejected, still under work, cancelled, or closed are not logged and tracked.
• Stakeholders who are normally motivated to have a successful project get stuck in a scope creep, due to the project’s complexity and their lack of experience, which results in flooding of the service provider with new requests, as they expand their ServiceNow knowledge, often with unchanged budgets and delivery dates.
• The service provider can allocate only inexperienced consultants to the project, which leads to the development of an inefficient service design and missing key features from the solution.
• Developers work on change requests that they received from other stakeholders without having a prior solution architect’s review and/or project scope change approval.
• All scope change requests are approved without any control from the standpoint of the budget, solution architecture, projects goals, and so on.

Recommendations

• Prepare for project scope changes, e.g., embrace change, document, and share change requests, and track their statuses, assess change requests, and their impact. Discuss and decide on changes transparently; communicate these changes, and deliver the necessary ones.
• Hold back on the implementation of change requests until they are agreed between the customer and service provider to ensure that the changes fit the project’s scope, budget, schedule, and so on.
• Prioritise change requests, i.e., at least mark them as ‘must have’, ‘should have’, and ‘nice to have’.
• It is usually not recommended to push a ServiceNow service provider to accommodate too many scope changes, because it can have a negative impact on the project’s quality, schedule, and resource usage.

22. Project quality management challenges

Symptoms

• In such challenges, the designed ServiceNow solutions are overly complex. For example, there are several sophisticated integrations between ServiceNow and third-party applications, or the process workflow includes comprehensive exception handling branches.
• Service provider quotes are highly priced owing to the project’s expected complexity, resulting in a defensive, risk-avoiding, financial risk management approach adopted by the service provider.
• The developed solution is determined to be full of poor codes when the coding standards and practices are analysed with a code-checking tool or by a senior developer.
• The way in which ServiceNow update sets will be used is not agreed upon beforehand, in addition to their naming convention. For instance, some developers can create update sets per user story, while some can put all new features in one update set.

Recommendations

• A senior ServiceNow expert should be responsible for the preparation or at least the review of the solution design to ensure that the plans are realistic.
• Code reviews should be conducted by senior members, and less experienced developers should be coached actively during the project.
• It is recommended to perform comprehensive developer testing at the end of each development sprint, instead of handing over useless deliverables for user acceptance testing.
• There should be agreed upon coding and update sets’ usage standards. In case of a larger project with multiple sub-production instances, the usage of the ServiceNow Team Development application can also be helpful.

23. Project risk management challenges

Symptoms

• Such challenges arise when ServiceNow’s project management is reactive, which means that most issues occurring during the project come to the surface without a chance to avoid them. This typically indicates several solution redesign iterations, additional development sprints, and long user acceptance testing phases.
• There is a lack of an active risk register, and risks are not followed through their lifecycle, resulting in symptoms such as reschedules, scope changes, budget overrun, resource availability issues, among others.
• The impact of risks is unclear and the related necessary project scope changes are not handled. Hence, they are likely to cause issues at a later stage of the project, when it will be even more difficult, time consuming, and costly to manage them.

Recommendations

• Project risk management should be active during the entire ServiceNow project, to assess the project’s progress as well as changes and to look at the most critical aspects of the project, especially stakeholders, service providers, processes, and technologies used.
• There should be a project risk register, if possible, in the ServiceNow Agile Development application, which would be set up and kept up to date during the entire project.

24. Early life support challenges

Symptoms

• In such challenges, several issues are escalated during the early life support period of a ServiceNow project, usually as a result of inefficient solution design, poor coding, lack of involvement in testing, missing risk management, and so on.
• New requests are placed during the early life support period, which need to be implemented with priority. Further, these requests usually arise as a result of insufficient stakeholder involvement or issues related to the solution design.
• There is an emergency release soon after the production goes live.

Recommendations

• If new features are required, they should be planned and developed in an organised and prioritised manner. Hence, try to avoid reactive firefighting. On the contrary, schedule the release of new features as soon as it becomes clear that they will be needed.
• Make a difference between real defects and requests. Focus on remediating defects first; requests can usually wait for a longer time.
• Communicate defects and new requests proactively and transparently. Do not let the project’s results be spoiled by new requests assumed to be defects by users.

25. Transition to support challenges

Symptoms

• Such challenges arise when post go-live ServiceNow solution support responsibilities are unclear or there is no support agreement in place.
• In these cases, handover between the implementation service provider and support service provider is not agreed, or there is no communication between these two service providers or teams.
• The solution documentation is missing, so the implemented solution is overly challenging to support. Moreover, the original developer of the solution needs to be contacted frequently in order to understand and solve the issues.

Recommendations

• As early as possible, there should be an agreement for the support service provider in a ServiceNow project, to ensure that the handover happens smoothly after deploying a solution into production.
• Even if ServiceNow environments change almost continuously and most projects are delivered in an agile manner, an agile approach is not synonymous to an undocumented or unorganised way of working. Thus, a solution documentation should be available, which describes the solution elements for support and potential feature extensions in the future.

Conclusion

• The experience factor in ServiceNow projects is key, and nothing can substitute it. In practice, this means that unless senior ServiceNow experts are involved in a project, it is highly likely that the project will encounter several issues and could fail to deliver the expected outcomes, partly or completely.
• A positive and proactive attitude is the most important soft skill in projects. Thus, if projects members are motivated and perform in the project with a ‘can do’ approach, the project is significantly more likely to succeed.
• The best project management practice in ServiceNow projects, irrespective of the project methodology, is to identify project threats, e.g., findings that can have a negative impact on the project. Further, it is important to identify problems that have already had a negative impact on the project. Act on all such findings as soon as possible, by involving other project stakeholders and communicating with them transparently.

If you run into any other common challenges in your ServiceNow projects and would like to help others avoid them, please feel free to share your experience as well.