Case study in process-focused solutions
A large, multinational organization that provides contract-based servicing with some manufacturing and distribution services wanted to replace parts of its 15-year-old tier-one enterprise resource planning (ERP), customer relationship management (CRM), and related legacy systems.
The wrong road
The company started the project with the traditional Waterfall method and a heavy documentation bias. It based its initial requirements on its old systems, collecting a long list with the help of an implementation partner. The requirements phase took longer than expected and needed multiple extensions.
The reviews of the requirements involved many parties who had to read, understand, and validate them. The business approvers were worried that they might miss something important or subtle. They requested multiple document-based reviews with formal comments. The project team responded to the comments, which generated more comments. This spiral of reviews finally ended, but business stakeholders weren't confident that they fully understood what they had approved. They hoped that the design phase would clarify things.
The design phase followed the same pattern of writing and reviewing complex design documents. It also ran behind schedule. The focus was on the "gaps" identified, but they were often out of context and hard to discuss with the business users. Uncertainty increased, and the stakeholders decided to review the project direction and the reasons for the delays and dissatisfaction.
The change of direction
As part of the review, which included third parties, they made several recommendations. The main recommendation was to adopt a more process-focused approach and use the processes as the framework for a more Agile way of working. The first step was to define the end-to-end process at the highest level to set the boundaries of the project scope in business process terms. The next steps then generated two more levels of detail for the business process streams. The project team worked as a combined business, project, and implementation partner workstream to do the process mapping at a fast pace.
The right road
After the team had a reasonable map of the processes, they mapped the requirements to the processes so that they could understand them in the context of a process. As a result, they restated many of the requirements and anchored them better in the context of a business transaction. This way, the requirements were clearer and more relevant.
They put the processes at level 2 into a storyboard. The partner solution architect and the customer's lead functional expert created the storyboard. The customer's lead functional expert used the process flows to create logical end-to-end process flows across workstreams to make the delivery of software meaningful. The partner solution architect provided the Dynamics 365 application view of the embedded standard processes, dependencies, and constraints. They made sure that the sequence of process delivery would be efficient within the Dynamics 365 applications. They used the storyboard to drive the sequence of work from delivering the foundational processes to the more peripheral ones. They also prioritized the level 2 end-to-end processes by considering the core, most frequent, and baseline path through the process as a higher priority. They delivered the core processes before the more specialized and less frequent variations.
They mapped this set of processes in the storyboard to an overall design within Dynamics 365 applications, creating a process-focused solution blueprint. They reviewed it against the existing technical, system, and data solution blueprint to create a rounded solution blueprint.
The team distributed the delivery of the processes into sprints of four weeks each. Each sprint delivered a meaningful part of the storyboard for each of the workstreams, with an emphasis on delivering end-to-end processes as quickly as possible. They made a high-level plan based on the sequence, dependencies, and estimated effort related to process delivery.
They planned the sprints based on the processes in scope for each sprint, defining more detailed process flows when needed. They kept the documentation to a minimum and designed the processes in the Dynamics 365 system in collaborative workshop environments. They performed all related activities, such as data migration, integrations, testing, training, and change management, based on the processes in scope. Each sprint ended with a conference room pilot, where the business subject matter experts presented the new logical business process and how the processes were designed and implemented in the system in a demo to an invited business audience.
At the end of each sprint, rather than reviewing and approving complex and technical design documents, the business attendees reviewed and approved the incrementally complete and functioning processes in Dynamics 365. The business engagement improved as the project spoke their language and they worked directly with the emerging Dynamics 365 system rather than with abstract design documents and lists of requirements.
The destination
The project continued to use the process-centric approach beyond design and build. The team used the processes to script and drive end-to-end testing, reporting status and progress as "ability to execute a process within the system." The senior business stakeholders on the steering group also connected better with the project because they could understand the project readiness and business operations implications.
The project successfully went live, and the company continued to use a process-centric view for the rest of its go-lives in other countries and regions. The implementation partner decided to use this process-centric approach as its new standard implementation approach for its other projects because it could see the benefits.