Demystifying a taboo: The way to identify and overcome 25 common challenges in ServiceNow projects – Part 1 of 3

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 blog 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.

    First, 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?

    1. Only 2.5% of companies successfully complete 100% of their projects.
    2. 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.
    3. 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?

    1. 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 sceptical 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.
    2. 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


    • 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.


    • 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


    • 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.


    • 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


    • 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.


    • 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


    • 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.


    • 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


    • 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.


    • 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


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


    • 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


    • 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.


    • 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


    • 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.


    • 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.

    To be continued…

    About the author

    Zalan Heil is 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.