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
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 do 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
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 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
- 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
- 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.
9. Resource estimate challenges
- 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
- In these cases, a fixed-scope fixed-price project
is requested, even if the project’s scope is not defined appropriately.
- 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
- 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
- In such cases, stakeholders act in the project
with a mostly reactive attitude due to the lack of priority, time, attention, and
- 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
- 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 utilisation 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
- These challenges arise when there is a high
pressure on the ServiceNow project budget and on those who are responsible for
- In such cases, project budget overspending occurs
due to various factors, such as inaccurate work effort estimates,
underspecified 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.
- 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
- 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
- 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.
- 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
- 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.
- 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
- In such challenges, a ServiceNow project’s
communication is dominantly email or voice based.
- There is extensive spreadsheet usage during the
- 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.
- 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
- 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
- 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
- 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
- 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.
- 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
- 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
- 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.
- 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
- 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
- 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
- In such challenges, it is unclear what the
original plans were and what the changes are in a ServiceNow project, due to
frequent and uncommunicated 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
- New users who start using the delivered solution
later have no learning materials. Hence, they cannot use the solution
- 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
- 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
- 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.
- 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
- 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.
- 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
- 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.
- 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
- 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
- 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.
- 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
- 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
- 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
- Such challenges arise when post go-live ServiceNow
solution support responsibilities are unclear or there is no support agreement
- 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.
- 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.
- 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.
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.