At 10Pearls, A Project Called ‘Snowman’ Spawned A Powerful New Platform

The project’s code name was “Snowman.” 

With such a name, one would think the undertaking had been mere child’s play — but it was far from it. Technologists at 10Pearls took on the challenge of replacing a client’s legacy solution; a task that’s never simple yet necessary for organizations to keep up with the ever-evolving tech landscape. 

Director Eric Newman, who led the project, recalled how the old system was like a “black box” to the client. 

“They knew how it looked and the outcome but not how everything was configured behind the scenes,” he said. 

For Newman and his teammates, this obscurity warranted the need to collaborate closely with several teams across the client’s organization, culminating in the creation of an efficient, cost-effective solution that fully meets the clients’ needs. 

Newman believes the success of the company’s latest solution reflects 10Pearls’ unique approach to building and launching new products — defined by a focus on working with rather than for clients.

“Our team members understand that we are all one team working toward a common goal, and sometimes that means helping others or doing work outside of your original scope to benefit the team and project,” he said. 

Although Newman and his peers encountered various challenges throughout the product development process, they overcame them by relying on strong teamwork, sound practices and a bit of fun. For instance, in keeping with the project’s wintry theme, everyone involved was assigned a Frozen character to have as a Zoom background. 

Below, Newman shares more about the new platform’s creation, the teamwork and methodology involved and the ways in which team members were encouraged to grow and bond. 

Why did 10Pearls need to build this product, and how does it benefit the client?

Eric Newman

Director • 10Pearls

Our client contracted with us to modernize their legacy decision-support platform as they faced the rising cost of ownership. This legacy system also required significant lead time in making business rule changes, which were having a negative impact on their ability to address customer needs in a timely fashion. It required significant engagement from the operations team and involved manual resolution rates due to a lack of user self-service capabilities for configuration. 

Our solution brought the ownership and management of the platform in house, eliminating reliance on external teams and allowing the business to make and approve changes to business rules. The solution also resulted in significant operational cost savings by reducing input errors and eliminating unnecessary process steps while enhancing the user experience.

What role did you play in developing and launching the product, and what components comprise the new platform?

I was the director on the project, leading an agile team of more than 20 people. I worked closely with business, IT and senior leaders in defining requirements and designing the solution. Three applications were built to support the solution, all of which were developed utilizing Appian. 

The configuration tool is used by business subject matter experts and administrators to enhance the behavior of the system. These components include data parameterization, custom questionnaires, business rules and decision trees.

The clinical request tool is an external-facing application that the client’s partners use for entering specific case details to receive a decision. It leverages the information configured by the configuration tool to make recommendations, and it integrates with the client’s existing case-management and analytical tools.

Lastly, the lifecycle tool is a workflow application that manages the business process associated with the maintenance of the configuration components.
 

What obstacles did your team encounter — and overcome — along the way? 

We faced a few key obstacles along the way. We weren’t replacing an in-house solution where the client knows the ins and outs of how it works. We were replacing a legacy solution that was like a “black box” to our client. Using an agile methodology, we worked with the client to define the requirements, iterate on the solution and provide feedback quickly, all of which allowed us to pivot when needed.

Decision trees were needed as part of the decisioning algorithm, and there was uncertainty on whether Appian would be able to handle this. We built a proof-of-concept in Appian at the beginning of the project to demonstrate this functionality, eliminating the need to introduce additional technologies.

The third obstacle was a time constraint. Our client had to make a “go/no go decision” 12 months in advance, so we held a major demo of the product’s core pieces of functionality to give the business greater confidence about the delivery timeframe of the solution.

What teams did you collaborate with in order to get the product across the finish line, and what strategies did you employ to ensure it went smoothly?

We collaborated with several different teams across our client’s organization. We worked closely with the business department in gathering requirements and feedback on sprint demos. Our development team worked with IT team members on integration to different enterprise applications and deployment activities. 

Taking an agile approach to development helped ensure cross-functional collaboration, with daily standup meetings enabling team members to provide status updates regarding blockers. In addition, we held weekly requirement and refinement sessions to confirm that functionality is well-defined, sprint-planning sessions to validate priority of work and sprint demos to get approval on work completed. This approach provided constant communication across all teams involved in the development of the solution.

How did you help ensure team members came together to grow and have fun throughout the product’s development?

This project spanned more than two years, with the final solution completed in 18 months, followed by enhancements. When you have a team working together for that long, you need to find ways to keep them engaged and motivated. This is especially challenging when everyone is working remotely. 

“When you have a team working together for that long, you need to find ways to keep them engaged and motivated.”

Our goal was to build a cohesive team, and one of our norms is to have our cameras on during meetings. This makes a big difference when working with a client that you don’t get to see in person. We gave our project the code name “Snowman,” and everybody on the team was assigned a different Frozen character to be their Zoom background during meetings, making it colorful and fun. 

We encouraged team members to expand what they were working on, allowing them to switch roles often throughout the project to gain different experiences. Our project coordinator ended up leading business requirement sessions and managing our testing team. Developers would rotate who was presenting the sprint demos, and some developers became scrum masters. Besides that, we often did virtual happy hours, had “fun-shirt Fridays” and played icebreaker games, including “Would You Rather,” during meetings. I also sent the team quarterly gifts, such as Garrett’s Popcorn and Goldbelly gift cards.