Case study in transitioning to support

This case study tells a story in two acts. It shows how IT project implementation methodologies have been changing to keep up with the cloud innovation of Dynamics 365 applications. It also shows how IT organizations within businesses have been evolving as the cloud changes their role and responsibilities.

The case study illustrates the dangers of assuming that an existing, well-functioning support model will work well in a different architecture and with changed business processes in new applications, without deliberate planning and action. This is especially true in a cloud world.

Act I: The journey of learning

This is a story of a medium-sized organization (fewer than 1,000 employees) with multiple offices across three European countries/regions and their corporate headquarters in the UK. Its core business includes professional services, field services, and bulk distribution from its own warehouses.

The organization was growing fast. To support and accelerate this growth, it decided to replace several local applications and multiple on-premises enterprise resource planning (ERP) and customer relationship management (CRM) systems with Dynamics 365 Finance, Supply Chain Management, and customer engagement apps across the enterprise. It planned to roll out the solution first to locations in two countries/regions that had significant interdependency (accounting for about 15 percent of its business) and then to the other businesses incrementally, as part of the next phases of the project. The next phases would also include more functionality related to Human Resources, Payroll, Customer Service Center, and contract management.

The existing support teams were fragmented across various systems and sometimes by business unit. These support teams were supposed to be organized under a single structure in IT before the transition to Dynamics 365. All support activities and teams were supposed to be managed by a director of support services who would report to the CIO.

The project was scheduled to go live about 10 months after it started. At the end of the Initiate phase, it had achieved the following:

• The end-to-end business process flow diagrams and description were adequate in most areas.

• The solution blueprint document was clear enough to confirm the scope of the overall design.

• Budgets and project resources were revised and approved based on the latest solution blueprint and project plan. The project scope and go-live date were reviewed and reconfirmed by the steering group.

• In theory, the support team was reorganized by main business areas: Finance, Sales and Marketing, Operations, Field Service, Warehouse and Shipping, IT business application, and IT servicing, rather than by legacy system. However, in reality, the teams continued to be tied to the legacy systems they had expertise in supporting.

There was an informal understanding that the support team would be trained during the project. However, during the Implement phase, the project team said that they were behind schedule and too busy with project delivery to help educate the support team. The backup plan was for the support team to be part of an extended, one-week training and hand-off period after UAT was complete.

As the implementation progressed, the support organization focused on the day-to-day needs of the current legacy systems. It was assumed that the risk was low because the support team was experienced and some of the project's SMEs would join the support team, bringing knowledge with them. It was also assumed that the support team would be able to pick up the new duties easily.

During the Prepare phase, when some members of the support team were asked to help with testing, they didn't feel ready to participate until they had been through training, which was scheduled after testing. The project SMEs didn't feel they could conduct internal training because they also had little hands-on experience with the working system.

When UAT was complete, the project team had other unplanned activities that were higher priority, and so the training and handover to the support team were reduced to two days.

The go-live went ahead on schedule, but the support team struggled to support the business. The initial assumptions that the support team would just pick up the new system support were wrong, because the underlying processes had also changed significantly. The support team wasn't informed about all the business process decisions and wasn't familiar with the new control and approval requirements that were configured in Dynamics 365. The shortened training and handover didn't provide enough context to support a production system.

The support operating model had changed, in theory, from a distributed, system-level team structure to a more business process and enterprise IT-based one, but it wasn't tested during the Implement or Prepare phase. The gaps and deficiencies were exposed only when the teams had to operate in production. The new operating model also didn't consider how the new business processes, architecture, and policies affected the support requirements.

In the previous support operating model, all queries and issues came directly—and informally—to an individual support team member, and they handled them with little external visibility. In the enterprise-level support, even with a limited rollout, the support team received many administrative queries that reduced their time to address more critical tickets.

The team also had to revise IT servicing procedures to reflect the new technology implications in a cloud-based SaaS model. They had to update policies related to data retention and backups because processes based on the legacy on-premises systems weren't reviewed and updated for the new cloud-based SaaS architecture.

The project team planned to start working full-time on the next phase of the project after only two weeks of hypercare. The budget hours for the implementation partner hypercare support were supposed to last four to six weeks, but ran out within two weeks because the support team needed more help from them. They missed a lot of SLAs in the early weeks. The company had to formally extend hypercare for both project teams and the implementation partner because getting their attention was hard when they had other priorities for the next phase.

After critical issues were resolved and new tickets were at a manageable level, the company did a post-go-live review and made the following recommendations:

• Define explicitly what activities, tasks, and actions the support team needs to do, in the context of the new system, processes, people, and architecture.

• Define the support operating model more clearly, with different levels of support and clearer expectations from partners. For example, use tools like Microsoft Teams channels where super users can help answer simple questions quickly. The super users would also help better formulate issues and questions that needed higher-level support.

• Allocate time for the support team to be involved in the project to ensure their learning is deep enough and relevant enough to the new process and architectural context to be useful in production. Don't rely on a last-minute, half-hearted handover.

• Plan the transition as part of the project plan with specific tasks, such as process design reviews and test case preparation, so that the team has multiple opportunities to use the developing system.

Act II: Fewer problems = shorter story

The company approved and enacted these recommendations over the next few months. The next rollout six months later had a much larger user base, but it went much smoother with a shorter hypercare period, higher user satisfaction, and lower cost than the first go-live.

The moral of the story? Poor service is always more expensive than good service.