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.