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