Implementation Guide

Success by Design
Microsoft Dynamics 365
Success by Design Implementation Guide

Published by Microsoft Corporation, 1 Microsoft Way, Redmond, Washington 98052.

Copyright © 2021 Microsoft Corporation.

All rights reserved. No part of this book may be reproduced or used in any manner
without permission of the copyright owner.

Azure Cosmos DB, Bing, BizTalk, Excel, GitHub, Hololens, LinkedIn, Microsoft 365,
Microsoft Access, Microsoft Azure, Microsoft Dynamics 365, Microsoft Exchange Server,
Microsoft Teams, Office 365, Outlook, Power Automate, Power BI, Power Platform,
PowerApps, SharePoint, SQL Server, Visio and Visual Studio are trademarks of Microsoft
Corporation and its affiliated companies. All other trademarks are property of their
respective owners.

The materials contained in this book are provided “as-is” and Microsoft disclaims all
liability arising from you or your organization’s use of the book.

Information contained in this book may be updated from time to time, and you should
refer to the latest version for the most accurate description of Microsoft’s FastTrack for
Dynamics 365 program.

Case studies used in this book are fictional and for illustrative purposes only.

First Edition

Printed in the United States of America

ii
This book is dedicated to Matthew Bogan, our colleague and friend. The way you think
and the way you approach everything you touch embodies a growth mindset—that
passion to learn and bring your best every day to make a bigger difference in the world.
Thank you for being a shining example.

iii
 What’s inside
Strategy................................................1
1 Introduction to Implementation Guide............................................. 2

2 Success by Design overview.................................................................12

3 Implement cloud solutions..................................................................27

4 Drive app value.........................................................................................60

5 Implementation strategy......................................................................85

Initiate............................................. 106
6 Solution architecture design pillars................................................. 107

7 Process-focused solution.................................................................... 122

8 Project governance................................................................................151

9 Environment strategy........................................................................... 188

Implement..................................... 224
10 Data management............................................................................... 225

11 Application lifecyle management................................................... 260

12 Security..................................................................................................... 283

13 Business intelligence, reporting, and analytics............................ 318

14 Testing strategy..................................................................................... 346

15 Extend your solution............................................................................ 380

16 Integrate with other solutions...........................................................413

17 A performing solution, beyond infrastructure........................... 462

Implementation Guide: Success by Design iv

 Prepare........................................... 500
18 Prepare for go live................................................................................. 501

19 Training strategy................................................................................... 539

Operate.......................................... 579
20 Service the solution.............................................................................. 580

21 Transition to support.............................................................................611

Conclusion............................................................................................................ 652

Acknowledgments............................................................................................. 655

Appendix................................................................................................................657

Implementation Guide: Success by Design v

Section
Strategy
1 Introduction to Implementation Guide
2 Success by Design overview
3 Implement cloud solutions
4 Drive app value
5 Implementation strategy

1
1 Guide
Introduction to
Implementation
Guide
Implementation Guide: Success by Design: Introduction to Implementation Guide 2
“Our success is dependent on our customers’
success, and we need to obsess about them—
listening and then innovating to meet their
unmet and unarticulated needs. No customer of
ours cares about our organizational boundaries,
and we need to operate as One Microsoft to
deliver the best solutions for them.”
– Satya Nadella, Chief Executive Officer of Microsoft

Overview
Microsoft believes that every business is in the
business of creating great customer experiences.

As a precursor to the Dynamics

To achieve that, business applications must do more than just run your
365 implementation resources in back office, marketing, supply chain, or even field operations as discrete
this book, this chapter will: entities. Organizations need to tap into data signals from across their
Explore the opportunities presented as business—and use them to drive ongoing improvements in the products,
organizations shift into the predictive era.
services, and experiences they intend to deliver to their customers.
Outline our vision for Dynamics 365.

Introduction
Help readers understand what an
investment in Dynamics 365 invites
in terms of enabling holistic, unified
digital transformation.

In this chapter, we explore how the shift from the reactive past to the
predictive era is currently affecting our industry—and will eventually
affect every industry. We also look at Microsoft’s vision for Dynamics
365 and how our apps allow holistic, unified digital transformation. In
our view, these topics are essential to anyone about to embark on an
implementation of Dynamics 365.

Implementation Guide: Success by Design: Introduction to Implementation Guide 3

 Armed with these perspectives, the rest of this book—which aims to
share the mindset and guidance needed to successfully implement
Dynamics 365—is sure to take a more meaningful shape for readers.
This chapter’s content is adapted
from the combined thinking of James For Microsoft, this is especially important, considering the investment
Phillips, President of Microsoft’s Digital
that you are making in us.
Transformation Platform Group; Rolf
Harms, Corporate Vice President of
Microsoft’s Cloud and AI Strategy; and

Every industry
Muhammad Alam, Microsoft’s Corporate
Vice President of Dynamics 365.

turned upside down

We find ourselves at a turning point: over the coming decades, the role
of technology will be turned upside down with profound implications
Fig. 1-1
for every aspect of business—from customer experiences to core
operational processes to the very nature of products and services.
Reactive past
Picture this: in the reactive past (Figure 1-1), a customer purchases a
Applications
car from a dealer. One day, while going down the road, the car stops
running. The customer calls the service center and reports a problem.
Application platform At this point, a service advisor opens an application, types a few notes
about the problem into a form, and then schedules a repair visit. It
may be the first time in years that any data related to the customer
or the vehicle has flowed—a few kilobytes trickling down, and only in
reaction to the car’s malfunction—into the dealer’s relational database.
Only now the dealer can provide service to the customer, but the car’s
Relational database manufacturer might never see a single byte of data from this event. As
this example illustrates, in the reactive past, data flows downward from
applications at only a drip.

Now consider what is possible today: the same customer purchases a

car from the dealer. With appropriate permissions granted by its new
owner, the car provides a continuous stream of data back to the dealer
and the manufacturer. It may be a self-driving car, with computer
vision models trained in the cloud via data captured by the entire
fleet’s cameras. Every operating parameter of the engine, every press
of the brake, every trip route—all are signals that provide a rich basis
for predictions to ensure a higher-value relationship between the
customer, the dealer, and the car’s manufacturer.

Implementation Guide: Success by Design: Introduction to Implementation Guide 4

 In Microsoft’s view, the possibility of a higher-value relationship is
present for every product, every service, and every business process.
In the predictive era (Figure 1-2), the paradigm is that everything is a
source of data and potential insights. As organizations embrace this
shift, they enable an upward data flow that originates from everywhere
and, at the same time, informs their products, services, and applications.

For companies that “grew up” in the predictive era, that paradigm is
second nature. But for mature enterprises, the path can be more diffi-
cult, as it requires transformation of existing capabilities and processes.

For Microsoft, this isn’t just theory or prediction. We have been pursuing
our own transformation and have faced many of these challenges
ourselves. At the heart of our transformation is the way we build products.
Instead of the multiyear product cycle of traditional, on-premises
products, Dynamics 365 is delivered as a service that’s continuously
refined and always up to date. It also allows us to capture rich telemetry
on bugs and usage to inform ongoing feature development.

Beyond its influence on the way we run our own business, this digital
transformation paradigm has affected how we think about success for
our customers. Microsoft’s vision has always been about democratizing
Fig. 1-2

Predictive era

Dynamics 365 apps

Power Platform

Azure
Data ingestion (Planet Scale
Foundation)

Implementation Guide: Success by Design: Introduction to Implementation Guide 5

 software and technology capabilities to empower everyone. Looking
forward, we have renewed our purpose in the context of the cloud in a
world where everything is a source of data and potential insights.

Microsoft’s mission is “to empower every person and every organization

on the planet to achieve more.” Harnessing data to help you predict
the future and intelligently guide actions represents a core capability
that invites organizations to achieve more by innovating everywhere
(Figure 1-3).

Microsoft’s data-first
cloud strategy
The opportunity contained in the shift from reactive to predictive—know-
ing that the car is on its way to failure before it fails—is hard to overstate.
For Microsoft and for our customers, every product, service, and business
process is ripe for reinvention. But the reinvention requires a wholesale
reimagination—a literal turning upside down—of the systems that power
the interconnected fabric of products, services, and applications.

To help companies reinvent their businesses and thrive in the predictive

era, Microsoft has invested in applications (such as Dynamics 365
Sales), an application platform (Microsoft Power Platform), and an
infrastructure platform (Microsoft Azure) spanning from enterprise and
Fig. 1-3
independent software vendor (ISV) developers to citizen developers.

Innovate everywhere

Suppliers Assets Operations Employees Products and Customers

Create a resilient, Get the most from Optimize your Empower your services Delight your
efficient supply your assets. operations. people and teams. Connect your customers from
chain. products and first touch to
services. delivery to success.

Implementation Guide: Success by Design: Introduction to Implementation Guide 6

 The entire Microsoft cloud (Figure 1-4) comes together as a unified
digital-transformation platform with consistent security, identity, and
compliance boundaries.

With everything as a source of data and potential insight, Microsoft’s

goal is simple: help customers take the right action at the right time
with the right message via the right channel to achieve the right busi-
ness outcome. (Throughout this book, you may find that we refer to
this concept as the digital feedback loop, as shown in Figure 1-5. It
Fig. 1-4 demonstrates how organizations tap into data sig-
Microsoft cloud nals from across their business, and use those signals
to drive ongoing improvements in the products, ser-
vices, and experiences delivered to their customers.
Microsoft 365 Microsoft Dynamics 365 The customers then respond to these improvements,
thus fueling a self-reinforcing cycle.)

Dynamics 365:
Power Apps Power Automate Power BI Power Virtual Agents

Microsoft Power Platform

Cloud-based
business apps
Microsoft Azure

for holistic,
Identity, security, management, and compliance

unified digital
transformation
Fig. 1-5

Engage Empower
customers people Keeping the opportunities of the predictive era top
Intel
l i ge nt of mind, we want to take a step back and focus on
what Microsoft got right with Dynamics 365, further
Data & AI
explain our data-first strategy in terms of Dynamics
365, and provide advice to customers embarking on
s
sy

te
ce

ms n
ie
s

per
and ex
an implementation of Dynamics 365.
Optimize Transform
operations products Looking back, it’s clear that Microsoft’s company-
wide push into the cloud set in motion the trajectory

Implementation Guide: Success by Design: Introduction to Implementation Guide 7

 of what we know today as Dynamics 365. But also notable was Microsoft’s
decision to embark on a business applications journey into the cloud
with its previously named Dynamics CRM and Dynamics AX products.

Although they were separate applications at the time, Microsoft’s deci-

sion to move forward with Dynamics CRM and AX foreshadowed the
importance we place on developing a cloud-based business application
solution that offers customers a holistic, unified digital-transformation
platform covering the front office, the back office, and beyond.

Fast forward to today, and few of Microsoft’s competitors can offer a

complete cloud business application with the breadth, depth, and level
of integration with existing Microsoft products that Dynamics 365 has.

Dynamics 365 is a portfolio of business applications that meets

organizations where they are—and invites them to digitally transform.
Each app is designed to remove the barriers and eliminate silos within
organizations by working together with existing systems—or the entire
portfolio of Dynamics 365 apps—for outcomes you simply can’t get
unless every part of the business is connected seamlessly.

Microsoft’s data-first Dynamics 365 strategy

If you’re reading this book, then your business likely has already invested
in Dynamics 365. However, understanding Microsoft’s future vision for
Dynamics 365 will help you take full advantage of your investment.

Building on Microsoft’s cloud strategy (which includes Dynamics 365),

several other factors contribute to Microsoft’s data-first strategy to put
Dynamics 365 into a category of one:

Dynamics 365 is a ▪ Dynamics 365 provides front-office and back-office cloud applica-
tions that are consumable in a composable manner, which means
portfolio of business that our customers can maximize their investment without having
applications that to do an extensive rip and replace of what were historically behe-
meets organizations moth customer relationship management (CRM) and enterprise
resource planning (ERP) processes.
where they are—
▪ Dynamics 365 is built upon the low-code Power Platform to
and invites them to enable pro and citizen developers to build solutions, automate
digitally transform. processes, and generate insights using Power Automate, robotic

8
 process automation (RPA), and Power BI—which no other vendor
can offer with its core platform.
▪ All of these are natively built on Azure, the cloud with an unmatched
level of security, trust, compliance, and global availability.
▪ Add to this the assets of Office 365 (such as Microsoft Teams,
LinkedIn, and Bing), which can be used to enrich the business
application experience.

With Dynamics 365, organizations have the only portfolio of intelligent

business applications that enables holistic, unified digital transformation
and empowers everyone to adapt and innovate—anywhere.

Advice to customers
embarking on an
implementation of
Dynamics 365
Microsoft’s ideas on what customers should keep doing—whether they
are embarking on an implementation of Dynamics 365 or any other busi-
ness application—are detailed later in this book, but they include many
of the traditional activities, such as business-process definition, quality-
requirements management, end-user readiness, and change management.

However, Microsoft recommends against project teams that structure

The ability to their engagements as massive 9-month to 18-month waterfall efforts.

start quickly in From a cloud services perspective, this old, on-premises implementation
style needs to be jettisoned in favor of agility.
the app allows
organizations to The ability to start quickly in the app allows organizations to bring value
bring value to to their business in an accelerated fashion. The focus of project teams

their business in should be on finding the function or area of the application that the
business can start using as quickly as possible, and then expand and
an accelerated enhance from there. The application and the business are going to change
fashion. anyway, so it is in the best interest of organizations to claim value early.

9
 More pointedly, Microsoft’s view is that being agile does not mean
engaging in sprint cycles that still require a 9-month to 18-month team
effort to deploy part of the application to end users.

Traditional business application models can no longer keep up. Long

setup times, expensive and complicated customizations, and slow
adoption curves make it nearly impossible to meet the needs of a
changing and demanding customer base.

Think beyond the implementation—

and beyond the technology
The key question as you embark on an implementation of Dynamics
365: why are you doing it? Is it just a rip-and-replace effort, or does the
implementation represent an opportunity for digital transformation,
advance your business model, allow you to leapfrog over the competi-
tion, or something else?

In making an investment in business applications, organizations are

called upon to clearly identify the value they intend to drive toward.
Will the technology get you there? Does the software or the imple-
mentation partner have the vision to get you there?

An investment in business applications requires a level of organizational

maturity to think about what you and your business are after. It also
requires you to think beyond just the implementation of technology.
Organizations that
understand the Organizations that understand the power of data—and want to
power of data—and harness it so that they can disrupt the market—are the business appli-

want to harness it cation projects that Microsoft wants to be a part of. This is where we
believe the world is going, and our products reflect that.
so that they can
disrupt the market—
are the business The journey forward
application projects
We understand that every organization comes with a unique set
that Microsoft wants of challenges, opportunities, and priorities. No matter where you
to be a part of. are in your digital transformation, Implementation Guide offers the

10
 guidance, perspective, questions, and resources to help you drive a
successful Dynamics 365 implementation, and harness data for insights
that lead to the right actions and the right business outcomes across
any business process.

The first section of Implementation Guide provides an overview of the

Success by Design framework, which Microsoft created to help our
customers and partners drive successful implementations of Dynamics
365. Additional chapters in the first section focus on the mindset and
thinking required to implement in the cloud.

Subsequent sections of Implementation Guide address the major topics

in the Dynamics 365 implementation lifecycle, including Microsoft’s
point of view on solution design, environment strategy, data, security,
business intelligence, integration, performance, user readiness, support,
and much more.

Whether you’re a first-time implementer or a been-there-done-that

Dynamics 365 architect, we hope you’ll bring us along on your journey.

Implementation Guide: Success by Design: Introduction to Implementation Guide 11

2 Guide
Success
by Design
overview
Implementation Guide: Success by Design: Success by Design overview 12
 Success by
Design overview
This chapter introduces Success by Design—a
framework and practice created by Microsoft to
help project teams implement Dynamics 365.

Based on thousands of real-world customer projects, Success by Design

is the sum of our Dynamics 365 implementation experience. It offers
topic-specific reviews and prescriptive guidance (approaches and rec-
ommended practices), which provide a reliable path to project success.
Success by Design is intended to be used by Dynamics 365 system inte-

One of the primary grators, independent software vendors (ISVs), and customers as a means
to better architect, build, test, and deploy Dynamics 365 solutions.
goals of this book is
to democratize the For our customers, Microsoft recognizes that Success by Design
practice of Success doesn’t guarantee implementation outcomes, but we’re confident that

by Design by making it will help you achieve your project’s goals while enabling the desired
digital transformation for your organization.
it available to the
entire community For our partners, Microsoft is confident that Success by Design, cou-
of Dynamics 365 pled with your implementation methodology and skilled resources, will
increase your team’s effectiveness in delivering successful Dynamics
implementers.
365 projects to your customers.

Implementation Guide: Success by Design: Success by Design overview 13

 Success by Design history
As demand for Dynamics 365 cloud services increased across the
enterprise, Microsoft identified the clear need to change the way we
thought about evolving our services and our responsibility to customers
and partners. We recognized that it wasn’t enough to design a platform
containing a set of features. We needed to also understand what it
takes to deliver a fully functioning, end-to-end solution that runs the
mission-critical processes of our customers’ businesses. From this need,
Success by Design was born.

Microsoft believes that customer success is the precursor to every

Dynamics 365 product development decision. Because of this, questions
fundamental to product development now challenge our engineers at
every step of the process:
▪ In what way must each product feature be delivered to ensure
customer success?
▪ How do we make Dynamics 365 apps valuable, durable, reliable,
and performant?
▪ What aspects of the product should be jettisoned because they
don’t meet fundamental customer success criteria?

For the first time in the product’s history, such questions have led to
the successful transition of 100 percent of Microsoft Dynamics 365
online customers to one version, to a dependable and safe deployment
process, to a steady and coherent feature release cadence (including
many overdue feature deprecations), and to a reliable and performant
platform that delivers customer value. But product is only one half of

Microsoft believes the customer success equation.

that customer Microsoft has put equal emphasis on the need to provide you the
success is the prescriptive guidance and recom­mended practices to ensure a smooth
precursor to every implementation project and a properly designed and built Dynamics 365
solution that successfully transforms business operations. This push has
Dynamics 365 also resulted in the transformation of Microsoft’s FastTrack for Dynamics
product development 365 service, which makes certain that our community of Dynamics 365
decision. implementers—customers and partners—has access to Success by Design.

14
 This chapter focuses on the fundamentals and practice of Success by
Design and its desired result: Dynamics 365 projects whose technical
and project risks are proac­tively addressed, solutions that are roadmap
aligned, and project teams that are successful in maximizing their
organization’s investment in Dynamics 365 cloud services.

Make Success by
Design your own
Enabling Dynamics 365 project teams to practice Success by Design
means an ongoing commitment by Microsoft to provide the commu-
nity of implementers—customers and partners—best-in-class business
applications, along with the latest in Success by Design project resources.

It also means project team willingness to incorporate the practice

of Success by Design into their overall project approach—regard-
FastTrack for Dynamics 365 is a
customer success program run by less of implementation methodology or the Dynamics 365 product
Microsoft’s Dynamics 365 product
being implemented. At its best, Success by Design fortifies a project
engineering team that helps
customers implement Dynamics 365 team’s chosen implementation methodology with a model for prod-
apps and realize business value faster.
The practice of Success by Design is
uct-aligned project governance.
fundamental to FastTrack’s approach,
but the Success by Design framework
is available for use on any Dynamics No matter where you find yourself in your Dynamics 365 implemen-
365 implementation project. tation, fundamental to Success by Design is the willingness of project
teams—despite the common pressures of time, budget, and resources—
to pause in order to understand and address technical and project risks
before it’s too late in the project lifecycle.

To this end, this chapter focuses on the what and the why of Success by
Design, as well as how project teams can use it to accelerate customer
success throughout the implementation of Dynamics 365.

Success by Design
objectives
Success by Design is prescriptive guidance (approaches and recom-
mended practices) for successfully architecting, building, testing, and

15
 deploying Dynamics 365 solutions. Success by Design is informed by
the experience of Microsoft’s FastTrack program, which has helped our
customers and partners deliver thousands of Microsoft’s most complex
In this book, we use the term “Finance
Dynamics 365 cloud deployments.
and Supply Chain Management” to refer
to the collective category of Dynamics
365 apps that includes Finance, Supply
Chain Management, Commerce, Human
Success by Design reviews are exercises in reflection, discovery (obser-
Resources, and, in some cases, Project vation), and alignment (matching to known patterns) that project teams
Operations.
can use to assess whether their implementation project is following
recommended patterns and practices. Reviews also allow project teams
to identify (and address) issues and risks that may derail the project.

Success by Design should be used as an adjunct to the project team’s

For interested customers, Microsoft chosen implementation methodology for the following benefits:
recommends that project leaders team
▪ Reduced risk due to early detection of problems
up with their implementation partner
to enable Success by Design within their ▪ Alignment to recommended practices
project. In addition to the Success by Design
resources available in this book, it’s highly
recommended that project teams ready The result is a roadmap-aligned solution architecture that is performant,
themselves by enrolling in the Success by
Design training on Microsoft Learn. scalable, and future-proof. ¹

Success by Design phases

Success by Design maps the Dynamic 365 implementation lifecycle
into four methodology-agnostic phases: Initiate, Implement, Prepare,
and Operate (Figure 2-1). In this section and the following sections, we
outline the Success by Design phases, their relationship to Success by
Design reviews, and the desired outputs and outcomes.
Fig. 2-1 In the Initiate phase, the project
team is in discovery mode—gath-
ering and validating business
requirements, finalizing the high-
level solution approach, making
inroads to define all in-scope
workstreams, and updating the
Initiate Implement Prepare Operate
project plan to reflect these up-
dates. When the project team has
¹ Acknowledging the possibility that feature produced the high-level solution
deprecations or other changes to product roadmap
in compliance with Microsoft policy may occur. design and the related project

Implementation Guide: Success by Design: Success by Design overview 16

workstreams are more or less defined, Success by Design begins with
the Solution Blueprint Review. (More on the Solution Blueprint Review
and other reviews later in this chapter.)

In the Implement phase, the project team is focused on building the

solution per the agreed-upon solution design and scope. Implementation
Reviews are introduced in this phase, having been informed by the
findings and recommendations of the Solution Blueprint Review. As we
learn later in this chapter, Implementation Reviews are used to more
deeply address questions related to the specific aspects of the solution
design (data model, security, integration) and implementation practices
(ALM, testing strategy). Implementation Reviews are meant to fully ad-
dress the risks identified during or after the Solution Blueprint Review
but before the solution build is too far along.

By the Prepare phase, the solution has been built and tested and the
project team is preparing for the final round of user acceptance testing
(UAT) and training. Additionally, all necessary customer approvals have
been granted, information security reviews completed, the cutover
plan defined (including go/no-go criteria), mock go-lives scheduled,
the support model ready, and the deployment runbook completed
with tasks, owners, durations, and dependencies defined. At this point,
the project team uses the Success by Design Go-live Readiness Review
to identify any remaining gaps or issues.

In the Operate phase, the customer solution is live. The goal of this
phase is stabilization and a shift in focus towards functionality and
enhancements that are earmarked for the next phase of the project.

Success by Design reviews

With a high-level understanding of Success by Design phases, we now
turn to Success by Design reviews.

Each review raises questions that serve as points of reflection that

project teams can use to generate important discussion, assess risk,
and confirm that best practices are being followed.

17
 The Solution Blueprint Review serves as the starting point of Success
by Design. We suggest that the Solution Blueprint Review be a man-
datory review for the project because findings that come from it lead
to Implementation Reviews, which offer project teams the opportunity
Later chapters of this book will cover each
Success by Design review in greater detail.
to drill down into topic-specific areas where deeper dives are deemed
For the most comprehensive coverage of necessary for further understanding project and solution risk. Finally,
Success by Design, refer to the Success by
Design training on Microsoft Learn. the Go-live Readiness Review, which we also suggest as a mandatory
review, is the last stop for assessing any remaining risks before go-live.

Figure 2-2 illustrates that Success by Design reviews are not to be

conducted as abstract exercises separated from the project. Rather, the
scheduling and implementation of each review relies on the availability
of key project artifacts and the readiness of the project team to discuss
them. (For a more in-depth look at Figure 2-2, visit the Appendix,
which provides Microsoft’s view of the typical deliverables, activities,
tasks, and stakeholders involved in each Success by Design phase.)

Success by Design outputs

With a basic understanding of Success by Design’s objectives, phases,
and review flow, it’s important to pause to understand the makeup of
Fig. 2-2 review outputs and their purpose—findings and recommendations.

Initiate Implement Prepare Operate

Get ready to start Design and build Deploy Live

Requirement analysis Code Testing and acceptance Solution health

Project governance Configure Go-live planning Usage

Fit gap analysis ... User readiness Maintenance

Customer kick-off Data modeling Cutover planning ...

... Solution performance ... Post Go-live Readiness Review

Solution Blueprint Review Integration Go-live Readiness Review

Success by Design
review and workshops
...

Implementation Guide: Success by Design: Success by Design overview 18

Fig. 2-3
As described in the previous
Matched to Lead to section, reviews are informed by
Findings known patterns recommendations project artifacts (project plans,
requirements, fit gap, solution
architecture, design documents,
and so on) produced by the project
team, and other information such
as formal or informal project
touchpoints. The availability of
such information points to the readiness of the team to schedule and
conduct Success by Design reviews. Additionally, project teams may rely
on Microsoft for telemetry and other tools to inform review discussions
and generate review outputs.

The primary review outputs fall into two related categories: findings
and recommendations.

Findings come in three types:

▪ Assertions  Findings that capture noteworthy aspects of the
solution or approach. Assertions highlight what the project team is
doing right, typically in line with best practices.
▪ Risks  Findings that could potentially impact the implementation
negatively if not mitigated.
▪ Issues  Findings that are currently impacting implementation
negatively or will do so if not resolved.

Findings should include as much detail as possible and be matched

to known patterns. Findings matched to known patterns often yield
insights that lead to recommendations or actions necessary to resolve
the issues identified (Figure 2-3).

To better illustrate this point, consider this customer example:

A global corporate travel company is implementing Dynamics 365

Customer Service to drive its call center transformation. As the project
team digs into the business’s requirements, they learn that the Dynamics
365 solution must account for integration with multiple legacy systems

19
 (many with high transaction volumes). Additionally, the requirements
point to a business-mandated customization that the project team
agreed could not be achieved using out-of-the-box functionality.

In preparation for the Solution Blueprint Review, the project team

parses these and other details, including confirming that solution
performance testing was purposely left out of the project scope on
the assumption that Microsoft’s Dynamics 365 cloud service should be
performant on its own. (Alt­hough it’s true that Microsoft is responsible
for delivering a reliable and performant cloud service to its customers,
our experience is that solution design and the resulting configurations,
customizations, and ISVs to achieve that design may play a role in
impacting overall Dynamics 365 solution performance.)

Considering that the Dynamics 365 solution in question is projected to

In Success by Design, findings link support 4,000 users at scale (including the multiple integrations and
observations to known patterns that invite
a key customization mandated by the business), the project team’s
actions necessary to address project risks
and issues. findings are clear: keeping solution performance testing out of scope
is a risk that negatively impacts the project. Among other findings
and recommendations not covered in this example, the project team’s
architect (who led the Solution Blueprint Review) recommends that
the project Steering Committee approve adding solution performance
testing into the test cycle.

The architect’s findings are summarized as follows:

▪ The solution requires custom development to meet its
business requirements.
▪ Performance testing is not included in the test cycle.
▪ Following best practices, solution performance testing should be
added to the test cycle (and if necessary, the solution performance
workshop should be scheduled to further explore the risk and report
any additional findings back to the project Steering Committee).

Track success measures

One more step remains in the Success by Design process: tracking success
measures. After completing Success by Design training, you may decide

Implementation Guide: Success by Design: Success by Design overview 20

 to create your own success measure tracking template. Otherwise, project
teams can use Success by Design tooling (as served by FastTrack or your
implementation partner) to track success measures. But what are success
measures, and why are they important?

What are success measures?

By its very nature, Success by Design is a project-specific endeavor. For
anyone practicing Success by Design across one or many Dynamics
365 projects, the question arose: How do we measure the health of just
one of those many projects? Success measures allow us to do just that.

Success by Design empowers project teams to track the health of

projects across seven categories and over 30 success measures. Figure
2-4 highlights some of these catego­ries and related success measures.

Tracking success measures is simple: After a Success by Design review

or other compelling project event, your FastTrack Solution Architect or
partner architect will access Microsoft’s Success by Design tooling and
update the relevant success measures for the project. Success measure
updates are either red, yellow, or green, and include project-related
details relevant to the success measure.

Fig. 2-4
Why are success
Review Findings Recommendations measures important?
Success measures are important
because they provide access to
micro and macro project health
trends. Tracking success mea-
sures for a single project allows
Success measures stakeholders to assess the overall
health of the project at a glance.
Similarly, the benefit of tracking
Risk Assertion Issue success measures over 10, 20, or
100 projects is that Microsoft, the
partner, or the customer project

Implementation Guide: Success by Design: Success by Design overview 21

 team can see patterns that may be impacting them. For example, mac-
ro-level tracking may yield an application lifecycle management (ALM)
problem. Access to this data allows Microsoft or the partner to under-
stand whether it’s a project or product problem, and gain insights on
how to fix it.

Conclusion
Success by Design equips project teams with a model for technical and
project governance that invites questions and reflection, which leads to
critical understanding of risks that might otherwise go unnoticed until
too late in the project.

Considering the pace of cloud solutions and the investment that organi-
zations make in Dynamics 365 software and implementation costs, even
the most experienced customers and partners with the best methodolo-
If you’re using Success by Design within gies will benefit by incorporating Success by Design into their projects.
your Dynamics 365 implementation
project, we want to hear from you! To
share your Success by Design feedback As covered in Chapter 1, Microsoft believes that every business is in
and experiences, reach out to us at
[email protected]. the business of creating great customer experiences. To achieve that,
business applications must do more than just separately run your back
office, marketing, supply chain, or even field operations. They must give
you the agility to remove every barrier in your way. When this happens,
business applications become more than just operational solutions.
They become resilient solutions that enable the digital feedback loop
and adapt to customer demands, delivering stronger, more engaging
experiences around the products you make and services you provide.

22
 Case study
An inside look at the
evolution of Success by Design
When our Solution Architects got their start with Dynamics 365, they
found themselves hooked on the challenge of effectively aligning an
organization’s business processes and requirements with the (software)
product in hopes of delivering solutions that resulted in actual value
for users.
The content of this case study is based on
interviews conducted with Dynamics 365
Because of this, FastTrack Solution Architects also know the challenge of
FastTrack Solution Architects. The goal is
to provide readers with an inside look at working with people, understanding the business, shaping software to
Success by Design. We hope you enjoy
this insider view.
meet the needs of the business, and delivering a solution that is accepted
by users. They know that projects don’t always go well and often fail.

It’s for exactly this reason that the FastTrack for Dynamics 365 team
and Success by Design were created.

A shift to Dynamics 365 in the cloud

Dynamics 365 isn’t software that is purchased and implemented as is.
As such, implementing Dynamics 365 products rely on qualified partners
to get the implementation right.

Complicating matters further, the promise of the cloud has been

that you can focus on the application and forget about everything

Implementation Guide: Success by Design: Success by Design overview 23

 underneath. But the reality is that cloud implementations require a
comprehensive understanding of how design and build decisions may
impact Dynamics 365 cloud performance, scalability, and more.

Accordingly, the shift to implementing Dynamics 365 in the cloud re-

mains challenged by on-premises implementation habits in which the
mindset is to overly customize—“because you can”—without impact.

The shift to implementing Dynamics 365 in the cloud requires not

just technical capability but also a definitive understanding of how to
design and build Dynamics 365 solutions within the constructs of the
online service.

The evolution of Success by Design

FastTrack for Dynamics 365 was formed to help customers maximize
their investment in Dynamics 365 by making sure that they (and
their partners) have access to the right information, recommended
practices, and a connection to the product group throughout the
implementation lifecycle.

When the FastTrack for Dynamics 365 team was formed, these goals
were initially achieved without the use of a framework. In other words,
FastTrack Solution Architects used their experience and connection to
the product team, but this approach contained too many variables to
be consistently reliable.

Over time, Microsoft’s experience revealed that Dynamics 365 customers

were running into very similar problems. For example, FastTrack would
identify that some aspect of the solution was designed and built in
a manner that wasn’t compliant with recommended Dynamics 365
implementation practices. And unfortunately, too often the Solution
Architects would catch the issue too late in the implementation lifecycle.

As a result, Microsoft began to ask itself: How can we change the

FastTrack approach so our Solution Architects can address problems
before they manifest themselves as problems? FastTrack also

Implementation Guide: Success by Design: Success by Design overview 24

 acknowledged that its approach couldn’t be “one Solution Architect
solving the problems of one customer project.” Our Solution Architects
needed to work in a way that would benefit all customers.

To identify and address problems early, our Solution Architects had

to engage with project teams on multiple levels. We needed to un-
derstand project plans, how project teams were thinking about doing
customization, data migration, and more. This need for early visibility
across all dimensions of the project meant aligning to an approach
that afforded our Solution Architects the opportunity to get involved
in these conversations from the start, to identify the problems and risks
early, and to give the right guidance to the project team before more
problems arise.

This required a period of FastTrack experimenting with the right approach.

We started a concept that we referred to as checkpoints, which involved
using surveys, but we found that this approach kept us in a reactive
mode. We kept revising our approach and eventually we got it right.

From this experimentation, Success by Design was born: a proactive

As stated earlier in this chapter, Microsoft practice that invites a purpose-built dialog that touches all levels and
recommends that project leaders team
dimensions of the project (technical and nontechnical) so problems are
up with their implementation partner
to enable Success by Design within their identified before they impact the project.
project. In addition to the Success by
Design resources available in this book,
it’s highly recommended that project Success by Design gets to the heart of how project teams are thinking
teams ready themselves by enrolling in
the Success by Design training on and what they’re doing so that any risks can be identified and mitigated.
Microsoft Learn.

With Success by Design, FastTrack joins the customer, our partners, and
the product team in a manner that ensures alignment between all three.

Success by Design for every

Dynamics 365 customer project
At some point during the evolution toward Success by Design,
Microsoft asked the question: How can we make sure every Dynamics
365 implementation is successful from the start? The key phrase is
“every Dynamics 365 implementation.”

Implementation Guide: Success by Design: Success by Design overview 25

 As this chapter highlights, the FastTrack for Dynamics 365 team doesn’t
have a special lease on the practice of Success by Design. This book’s
goal is to democratize Success by Design and make it available to the
entire community of Dynamics 365 implementers.

The more project teams invest in Success by Design, the more they will
get out of it.

Implementation Guide: Success by Design: Success by Design overview 26

3 Guide
Implement
cloud solutions
Implementation Guide: Success by Design: Implement cloud solutions 27
 Introduction
The cloud—the constellation of connected servers, data
warehouses, and associated software and services—is at
the core of a digital transformation strategy.
Organizations of all sizes recognize that the cloud is the fastest way
to modernize their operations to increase efficiency while better serv-
ing customers. For many organizations, the shift to the cloud simply
means running their applications in a public cloud infrastructure
instead of the traditional on-premises datacenter. For other organi-
zations, however, a software as a service (SaaS) model that uses cloud
applications as well as the underlying cloud platform is a quicker path
Adopt a cloud mindset to digital transformation.

Cloud implementation Whatever model an organization chooses, we find that the key to
success isn’t what implementation looks like, but rather how leaders,
Customize and extend
cloud applications architects, and entire companies approach the digital transformation
journey. Success in the cloud isn’t just about the technology or the fea-
Operate in the cloud tures available—it’s about the organizational mindset. For a successful
digital transformation, your organization must prepare for changes
Evergreen cloud
that span the entire enterprise to include organizational structure,

Upgrade from on-premises processes, people, culture, and leadership. It’s as much a leadership
to the cloud and social exercise as it is a technical exercise.

Implementation Guide: Success by Design: Implement cloud solutions 28

 In this chapter, we provide a perspective on what to expect when imple-
menting your cloud solution using Microsoft Dynamics 365. We introduce
principles relevant to any SaaS application. Concepts introduced here
Supporting research and studies
are elaborated on in subsequent chapters. We hope these principles help
McKinsey  The keys to a successful you set your course and guide you in your leap into the cloud.
digital transformation

Smarter with Gartner  Cloud Shift We start by addressing how to develop a cloud mindset in an organi-
Impacts All IT Markets
zation, which is foundational to your digital transformation. Then we
delve into factors to consider and understand before you shift to a
shared public cloud from an on-premises setup. These include how the
shift will impact controls you have in place and how to think differently
about scalability, performance, shared resources, and more. After
that, we discuss the principles around customization and extending
cloud apps. Finally, we explore the operating model, always up-to date
evergreen cloud models, and the options to migrate to the Dynamics
365 cloud from on-premises.

Adopt a cloud mindset

Adopt a cloud mindset
Cloud implementation Embracing change is a common theme, but infusing it throughout your
organization is vital to your digital transformation journey. Therefore,
Customize and extend
cloud applications we include it as a thread that runs throughout this chapter and book.
Adopting the cloud mindset is also an intentional way to help organiza-
Operate in the cloud tions break the mold and think differently about how applications are
designed, developed, secured, and managed in the cloud.
Evergreen cloud

Upgrade from on-premises

First, let’s understand the “why” behind the pervasive adoption of SaaS
to the cloud business applications by organizations across the globe. Traditional
approaches to business applications mostly involve the IT department
building a custom application or using an off-the-shelf product aug-
mented with customizations to meet the specific business requirements.
The typical approach includes phases to gather requirements, build,
go live, operate, and then follow the change management process to
request changes or add new features. The IT department has full control
of the application, change process, releases, updates, infrastructure, and
everything needed to keep the solution running for years.

On the surface, this sounds ideal. It has been the standard operating

Implementation Guide: Success by Design: Implement cloud solutions 29

 model for deploying and operating business applications. This way of
working, however, is losing relevance in today’s fast-paced world of
shifting supply chains and evolving customer needs and expectations.

Application development and deployment was disrupted not neces-

sarily because of the cloud or new technology—the undercurrent that
made the cloud pervasive was the changing landscape of business.
Unharnessed data from ubiquitous smart and IoT devices and other
sources fueled startups that disrupted whole industries seemingly
overnight. With that, the average lifespan of companies plummeted.
This inflection made the survival of a business dependent on delivering
the best product, the best customer experiences, and constant inno-
vation to meet ever-growing expectations. This new business arena
means businesses must change more often, evolve their processes
more quickly, and become more data driven to understand customer
needs, pain points, and preferences.

The changes we’re talking about aren’t triggered by the cloud or tech-
nology. These are thrust upon us by the changing business landscape.
Adopting a cloud mindset, then, is about transforming your processes,
people, culture, and leadership in such a way that your organization can
embrace change quickly and successfully. We believe the fundamental
organizational characteristics that will determine success in this environ-
ment come down to focusing on delivering business value through a
secure cloud technology platform. This includes the ability to harness the
data that is captured to generate insights and actions. This platform will
also rely on automation to quickly react to changing needs.

In this section, we explore these organizational characteristics that help

drive the cloud-first mindset to achieve digital transformation.

“Every company is a technology company, Focus on business value

no matter what product or service it
provides. Today, no company can make, Technology is a ubiquitous force that influences almost every business.
deliver, or market its product efficiently
without technology.”
Indeed, the IT department within a bank or a manufacturing com-
pany may be larger than entire tech companies. Understanding how
—Forbes, “Why Every Company is a
Technology Company” technology affects customers and business is important to help any
company survive and thrive. It’s also important to not let technology

30
 hinder growth or impede business. The role of technology is to deliver
business value by driving efficiency.

However, we often see enterprises whose technological landscape

has become so large and complex over the years that they fail to
deliver the agility demanded by the business. The IT departments are
consumed with dealing with the complexity of software compatibility,
update cycles, end of life deadlines, aging infrastructure, and antiquated
security policies with little time to focus on delivering business value.

An evergreen SaaS cloud approach to your business application,

however, takes away much of the infrastructure and operational IT
effort to keep the servers running, software patched, and other routine
tasks, and turns the focus of IT on the business. Operating in the cloud
doesn’t mean there are no operational responsibilities, environment
IT has a greater management, updates to SaaS services, feature deprecations, user
opportunity to communications, or coordinating change management for enhance-

focus on delivering ments and new capabilities, monitoring, and support. These functions
are all still required, but with a key difference: IT is now much closer to
positive business the business application layer and has a greater opportunity to focus
outcomes. their energy on delivering positive business outcomes.

Traditionally, business applications depict a set of key business processes

that allows the users to capture, track, and report on the process and
its progress. These business processes usually take the form of having a
user interface (UI) built on top of an underlying data store to capture or
display the information from the database. These “forms over data” soft-
ware applications can help organizations keep track of information and
make it easily available through reports. However, from an end user’s
perspective, they’re a data capture tool that doesn’t really help them
do their job any faster or better. This design of business applications
hasn’t changed in decades. It’s an outdated model that doesn’t bring
any additional value to the business or to the end user, and doesn’t
differentiate a business’s offerings and customer experience from their
competition, which is likely following a similar outdated approach.

Additionally, on an individual level, we want to automate routine,

boring tasks and focus on more creative, challenging work.

Implementation Guide: Success by Design: Implement cloud solutions 31

 For example, take a point-of-sale application that helps you address
your customer by first name and provides them personalized relevant
offers based on their loyalty, or recommends products based on their
purchase history and Artificial Intelligence (AI). This will be better
received by your employees and customers than an application that
can barely determine if a product is in stock or not. Simply offering the
best deal or best quality product isn’t enough in today’s hyper-com-
petitive environment. To win, you need to differentiate between your
customers, respond to their unique behaviors, and react to fluctuating
market demands.

Businesses likely already have the data to do this, but may lack the
technology to turn data into practical insight. For example, Dynamics
Automate the 365 Commerce taps your systems to gather customer intelligence from
routine tasks so a myriad of sources (such as social media activity, online browsing hab-

you can focus on its, and in-store purchases) and presents it so that you can shape your
service accordingly. You can then manage product recommendations,
creative, more unique promotions, and tailored communications, and distribute them
challenging work. across all channels via the platform.

Dynamics 365 applications are focused on delivering value to the busi-

ness and empowering end users, changing the business application
industry paradigm by forcing every business to innovate faster.

The “If it ain’t broke, don’t fix it” mentality common in large organiza-
tions, where business applications can remain unchanged for up to 10
years, puts the enterprise at risk. Unless your business is a monopoly
and can sustain without investing in technology, the hard reality is
most businesses today won’t survive without strategic plans for digital
transformation.

You need to ask yourself some questions:

▪ Has the rest of your industry not transformed and
embraced technology?
▪ Do your customers demand a better and faster process?
▪ Is your competition growing their market share by eating into yours?
▪ Does your competition have a better Net Promoter Score (NPS)?

Implementation Guide: Success by Design: Implement cloud solutions 32

 If you answered yes to most or if you don’t know the answers, your
business might be failing to adapt and react to changes in customer
behavior and expectations. Businesses that don’t invest in technology
will face challenging disruptive competitors, either global behemoths
or innovative startups. You need digital transformation technology
that gives you the command of three essentials: deep, cross-channel
customer insight; synchronized operations from front end to back end;
and scalability to drive rich experiences as needed.

Decision-making around such technology now carries existential

consequences. Lack of strategic visionary thinking, long-term planning,
and matching investments can prove to be catastrophic.

The critical point is your business application shouldn’t be designed

and deployed with an expectation that it will remain unchanged for
long periods of time. Instead, the core design principle for business ap-
Decision-making plications should be ease of change. You should take advantage of the
around digital wonders of automation to deliver changes as often as daily and weekly,

transformation now at the whim of business. This continuous development philosophy is

core to a Dynamics 365 SaaS application with weekly maintenance
carries existential updates and multiple waves of new features delivered every year.
consequences. Realizing the value of these cloud applications, therefore, is about
adopting the latest best-in-class capabilities, continuously delivered.
With this new mindset, SaaS services aren’t just used to meet business
requirements—they’re helping drive business value and adoption.

Increasingly, technology is becoming so powerful and democratized

that non-developers and people with no formal training in software
development are empowered to build applications, create workflows
that automate their work, and use machine learning with ready-made
AI models to analyze data. This concept of citizen application devel-
opment has drastically transformed businesses, where end users are
developing solutions to solve business problems and sharing these
applications with colleagues. This organic approach to app devel-
opment has short-circuited the application development lifecycle,
helping address the perennial issue of software adoption. IT depart-
ments are now responsible for the governance of these applications,
securing the access to data and environment, and focusing on building

Implementation Guide: Success by Design: Implement cloud solutions 33

 the underlying services and connector interfaces that the business can
consume in their applications.

These scenarios all help illustrate how a transition to the cloud can play
an instrumental role in refocusing technology to deliver business value.

Driven by data
This disruptive innovation we’re seeing across several industries is
fueled by data. Almost everything around us generates data: appli-
ances, machines in factories, cars, apps, websites, social media (Figure
3-1). What differentiates one company from another is the ability to
harness this data and successfully interpret the information to generate
meaningful signals that can be used to improve products, processes,
and customer experiences.

Organizations recognize data is an asset, and becoming data driven is

a key motivator for digital transformation. Still, the accounting rigor
that we see in finance is seldom observed when it comes to managing
organizational data. If data is the new currency, then we should
treat it like that. Get an understanding of your organizational data
Fig.
3-1 estate—the databases, data warehouses, and data lakes—that help
your company manage its cor-
porate data. Develop a holistic
Engage Empower view of customer data across
customers people departments, functions, and
applications, while acknowledg-
l i ge nt
Intel ing the regulatory boundaries
on data usage. These steps are
practically a prerequisite to
Data & AI digital transformation.
s
sy

te
ce

ms n
ie
s

an d ex per Depending on the volume of

data, its age, and organizational
Optimize Transform silos, the deduplication, correla-
operations products
tion, and conflation of data from
different systems could become
a complex project on its own.

Implementation Guide: Success by Design: Implement cloud solutions 34

 However, modern AI-powered customer data platform (CDP) technol-
ogies could come to the rescue. A CDP technology creates a persistent,
unified customer database that is accessible to other systems. Data is
pulled from multiple sources, cleaned, and combined to create a single
customer profile.

It’s also important to define your organizational data strategy for

business applications, develop guidelines on how new applications
store their data, what schema they use, and how other applications in
the organization can understand and use this data. You need to use the
most optimal datastore for your use case. For example, storing credit
card transactions in Dataverse (a repository to store and manage data
used by business applications) is suboptimal; a data lake might be a
better choice.

Being data driven is about better understanding your data’s quality

and relevance, and being able to generate valuable insights that are
actionable and can drive meaningful changes to your processes. Going
back to the point of embracing change, your data strategy should
reflect how you design your process, develop your applications, and
operate. If it takes several months to deploy a change request or years
to roll out an improved process, there is little point.

A data-driven business application cloud platform like Dynamics 365

enables you to:
▪ Create a data estate that is intelligent and AI-ready
▪ Connect and consume data from legacy on-premises systems,
other line of business applications, and third-party applications
▪ Have the necessary controls to secure and meet data compliance
requirements
▪ Build smart applications that are continuously improving
▪ Infuse data intelligence directly into the application, empowering
users to make effective and smart decisions
▪ Have agility so applications can quickly adapt to changes in
your process

Overall, the intelligence and insights you generate from your data
will be proportional to the quality and structure of your data. You

Implementation Guide: Success by Design: Implement cloud solutions 35

 can explore this topic more in Chapter 10, “Data management,” and
Chapter 13, “Business intelligence, reporting, and analytics.”

Think platform
An organization can take several approaches towards digital trans-
formation. In many cases, you start with a single application being
deployed to a SaaS cloud. A key responsibility of IT decision-makers

You’re investing and enterprise architects is to deliver a cloud platform for their or-
ganization’s digital transformation. Individual applications and their
in the platform, app feature sets are important, but you should also look at the larger
not just the picture of what the cloud platform offers and what its future roadmap
application. looks like. This will help you understand if the platform can meet the
short-term and long-term objectives of your digital transformation.

Thinking about the platform versus a single app offers clear benefits.
You avoid reinventing the wheel with each additional application,
and you instead deliver a foundation approved by governing bodies,
with clear patterns and practices. This approach limits risk and brings
a built-in structure that enables reuse. Platform thinking doesn’t nec-
essarily mean that other cloud platforms or legacy applications have
to be rebuilt and replaced. Instead, you can incorporate them as part
of an all-encompassing platform for your organization, with well-de-
fined patterns and swim lanes that enable integration and flow of data
between applications. Bringing this “systems thinking” to deliver a
platform for business applications can drastically reduce the amount
of time lost getting security and design approvals for individual apps,
thereby improving your agility and time to value.

Your business applications platform should already provide the following:

▪ Necessary security and design approvals for processing data in spe-
cific categories based on its sensitivity and regulatory requirements
▪ Clear guidelines on extending and customizing the platform to
ensure supportability and agility
▪ Established governance process to manage access and
service operation
▪ Approved integration patterns for communication with other
platforms and on-premises systems, with a clear process for
approving deviations

Implementation Guide: Success by Design: Implement cloud solutions 36

 ▪ Data storage guidelines for apps and patterns for sharing
▪ License entitlements that are available for individual apps
▪ Documented service protection limits and best practices that your
applications should comply with
▪ Resources for additional learning and guidance with access to experts

The due diligence and foundational work you do when choosing a

platform in coordination with IT and business decision-makers can save
weeks, if not months, of effort downstream when developing individual
apps. This thorough evaluation also helps drive predictable success.

Embrace DevOps and automation

Traditionally, the process to manually release a change to applications was
convoluted, involving several teams, change boards, manual regression
Due diligence tests, and approvals. It took weeks. This complexity makes teams averse to
change. Enhancements and updates are then consistently deferred, which
now helps drive affects the adaptability of your applications to shifting business and tech-
predictable success nology priorities. Automating builds and releases and building in testing
in the future. automation is crucial to allow for continuous software updates.

The biggest selling point of the cloud is to stay current and quickly deploy
software. You can’t rely on teams to manually test and deploy each and
every change to achieve that vision.

Traditionally, a time lag existed between code and test and deploy.
A bug in production meant repeating the lengthy cycle. The fear of
breaking code meant that teams tended to delay updates for as long
as possible. With automation, you deploy fast and potentially fail fast.
This is where the culture of fail fast comes in. Automated processes
help companies empower their teams to take risks. You fail but quickly
release a fix. Over time, failures decrease and success rates improve,
instilling confidence in teams to deploy and innovate, and delivering
value to the business faster. At the core of the cloud mindset is un-
derstanding and embracing DevOps. DevOps is the union of people,
process, and technology to continually provide value to customers.
DevOps is a cultural change in which we break down silos between
developers and administrators, and create shared responsibility for the

Implementation Guide: Success by Design: Implement cloud solutions 37

 quality of released software. The DevOps process automates software
delivery and speeds up the technology deployment lifecycle (Figure 3-2).

The idea is to enable development, IT, and quality and security teams
to collaborate to produce more reliable and quality products with the
ability to innovate and respond more quickly to the changing needs of
business. Implementing DevOps inherently depends on automation:
automating the build process to enable continuous deployment,
regression tests to improve speed and reliability, and administrative
actions like user and license management.

At this point, we should also explore continuous integration (CI) and

continuous delivery (CD) in the context of the cloud. The idea is each
code check-in from the developer should go into the main build and
get tested early. This takes CI to the next level by allowing for automat-
ed testing and continuous, automated code deployment.

If a change includes a bug, the build fails, and the cycle repeats. The
Fig. automation allows for changes to
3-2
happen quickly without unneces-
sary overhead—a team can focus
Plan on the business logic and not the
infrastructure. Therefore, with CD
Monitor Code we always have the most up-to-
date working software.

CI and CD bring agility to cloud

DevOps solutions by allowing for the latest
Operate Build
processes changes and bug fixes to move to
production code without delay.
This is a paradigm shift from the
world of on-premises software, in
which each change had to wait un-
Deploy Test
til all user stories were completed,
the full package was deployed, and
Release a testing team tested the change.
With automation, we’re reducing
time and improving quality.

Implementation Guide: Success by Design: Implement cloud solutions 38

 But this isn’t just a technological change. DevOps requires close collabo-
ration between development, testing, and deployment teams. This is a
cultural and mindset change in which the whole team trusts each other,
feels empowered, and is collectively responsible for product quality.
Dynamics 365 offers deep integration
with Azure DevOps with build tools to
Preparing your organization for the fast-paced world of the cloud
help automate your deployment pipeline means that automation isn’t optional anymore. Instead, investments
and effectively manage the application
lifecycle (Figure 3-3). in automation will deliver significant efficiencies and help improve the
overall reliability of your applications.

Cloud implementation
considerations
Implementing solutions from cloud SaaS products can reduce man-
agement overhead and allow you to deliver business value more
quickly by focusing on the application layer. Fundamental application
considerations, however, still apply to SaaS cloud applications. Security,
scalability, performance, data isolation, limits, and capacity are still
critical, but could have a different approach when compared to an
application deployed on-premises. This section focuses on some of
these considerations for SaaS cloud apps.
Fig.
3-3

ALM Powered by Azure DevOps

Initiate Build Release
Getting started, faster Build and walk away Automated, predictive, repeatable

Pack source Run

Provision Deploy Import Run solution Export Run solution Import as Increment Export
code from Run unit test Unpack repo Run unit test Pack solution integration
environment dependencies solution checker solution checker unmanaged version managed
repo test

Initial build pipeline instantiates pristine Building pipeline automates manual steps. No more Automated release pipeline removes manual steps. Weekly, daily, or hourly releases
development environment daily. need to upload to solution checker and manually become the new standard.
export solution, unpack, and push to repo.

Implementation Guide: Success by Design: Implement cloud solutions 39

 Adopt a cloud mindset Security readiness
The responsibility for security in SaaS cloud applications is shared by
Cloud implementation both the service provider and the customer. That means your existing
Customize and extend security policies might not be suitable to meet the security require-
cloud applications ment in the cloud. The SaaS service provider processes customer data
and is responsible for aspects such as securing the backend infrastruc-
Operate in the cloud
ture and data encryption in transit and at rest. As a data controller, the

Evergreen cloud customer is still responsible for securing access to environments and
application data.
Upgrade from on-premises
to the cloud
The IT information security team should clearly understand the
boundaries of these shared responsibilities to ensure the following:
▪ The SaaS service provider meets the organizational security,
privacy, and compliance requirements. This is usually done in the
beginning to approve the platform for use supported by a regular
review or audit process to ensure continued compliance.
▪ The security team is aware of the controls and configurations
required to govern access to data and fulfill the customer se-
curity responsibility. These could include defining the data loss
prevention policies, access control policies, and environment man-
agement policy. They usually have a default setup with a process
to manage deviations for specific apps.
▪ The governance process makes sure the application-level security
requirements are met. This is primarily managed by the appli-
cation teams and driven by business requirements for each app
deployment. You might have additional checks before deployment
to ensure compliance.

A good example of this is General Data Protection Regulation (GDPR)

in the EU, in which the SaaS service itself might be fully GDPR com-
pliant from a data processor standpoint but the customer is still
responsible for implementing data controller processes like a “forget
me” request or managing marketing consent for contacts.

Organizations need to review their information security policies and

ensure that they’re cloud ready. Doing this exercise earlier, before the
app deployment cycle, will help avoid delays. It’s important to closely
work with your cloud SaaS service provider to ensure all your security

Implementation Guide: Success by Design: Implement cloud solutions 40

 requirements are met. Microsoft publishes the details of how this
shared responsibility of securing data is fulfilled from a data processor
perspective on the Microsoft Trust Center, which provides detailed in-
formation on our security and privacy policies as well as the certificate
of compliance for various regulatory norms and internal standards.

Scalability
The scalability of the SaaS platform is a key consideration for business
applications. Being able to scale out and scale up to support seasonal
workloads or spikes in user activity will impact the overall user experi-
ence (both staff and customers) and effectiveness of business processes.

The cloud scalability parameters available in SaaS differ from a

traditional on-premises system. Instead of adding more servers or
increasing the power of machines, these parameters could be trans-
lated as available API capacity. You also shouldn’t assume that cloud
means infinite scale and computing power that can process everything
thrown at it. The good old coding and design best practices are still
relevant, but might need to be adapted. Although managing and
scaling cloud services is complex, increasing or decreasing your data
storage, processing power, and networking requirements can be done
seamlessly. In many cases, you can do so automatically or with simple
configuration changes. This microservices architecture, including
capacity-based routing to resources and storage management, is
transparent to Microsoft customers.

To summarize, the SaaS cloud offers the flexibility to scale horizontally

and vertically to support thousands of concurrent users. Embracing the
capacity-based model for resource consumption in the cloud helps not
only build optimized applications but also a better plan for operating
cost post deployment.

Latency and performance

Performance is a key consideration for business applications—it not only
impacts the end user experience and adoption, but can directly impact
business goals and key performance indicators (KPIs) of success.

Implementation Guide: Success by Design: Implement cloud solutions 41

In on-premises deployments, enterprises had complete ownership and
control of the infrastructure, and could guarantee and monitor appli-
cations’ latency and performance. In the cloud world, it’s not
as straightforward.

Research shows that a few milliseconds of latency lead to a big

percentage drop in page load times. For e-commerce companies,
this could mean a sizable drop in user attention and therefore sales
revenue. Low latency is not a good to have, but a critical deciding
factor in an enterprise’s brand and reputation. The same applies
to back office business applications operating in the cloud—user
experience and productivity can be significantly impacted in a
high-latency environment.

Several contributing factors can impact application performance,

including network latency, user device and browser, application de-
sign, and customizations. SaaS services are inherently scalable, have
vast compute power, and are available from multiple locations around
the world, but that doesn’t necessarily guarantee performance if the
solution is poorly designed, or if users are accessing the service from
environments with high network latency.

Your cloud applications are powered by hundreds of pieces of virtu-

alized hardware running on Azure datacenters sprinkled around the
world. A crucial decision you must make, then, is choosing the data-
center to deploy your application so that all users of the application
get an acceptable level of latency.

Performance also can suffer because of a poorly designed application. If

you’re changing standard code in SaaS or deploying custom applications
in platform as a service (PaaS) or infrastructure as a service (IaaS), your
team must design a high-performing application and carry out proper
performance tests, and only then do you deploy to production. Now, most
cloud providers work on a shared network infrastructure in which your
requests go through the internet and are used and shared by everyone.

Network latency is a crucial factor to consider alongside other architec-

tural and design decisions that impact performance.

42
 One option for businesses looking for more reliability and security is
to use a private connection. Cloud providers offer dedicated channels,
You can test latency using the Azure for example Azure ExpressRoute. These connections can offer more
Latency Test and Azure Speed Test 2.0 for reliability, consistent latencies, and higher security than typical connec-
each datacenter.
tions over the internet.

Isolation in the shared cloud

The cloud operates on a shared common infrastructure across differ-
ent businesses, which leads to economies of scale. But although the
infrastructure and processing may be shared in public clouds, you
have data isolation, which means one customer’s data isn’t shared
with others. Security and data use policies are taken very seriously by
Microsoft; it’s imperative that we maintain the highest data and secu-
Private connections rity standards. These standards and practices are audited and certified
on a regular basis by trusted third-party organizations. Security isn’t
offer reliability, an afterthought, but ingrained into how we develop applications, so
consistent latencies, that the computing infrastructure is shared and other security related
and higher security aspects are isolated.

The other aspect of sharing resources and infrastructure in the cloud is the
possibility of monopolizing resources or becoming a noisy neighbor. While
rare, these cases are more often caused by poorly developed runaway
code than a legitimate business use case. Automated monitoring and
protection throttles are built into the Dynamics 365 platform to prevent
such situations, so it’s important to understand and comply with these
service boundaries and throttles when designing for cloud platforms.

Service protection
and a capacity-based model
Service protection and limits are used in cloud services to ensure
consistent availability and performance for users. The thresholds don’t
impact the normal user operations; they’re designed to protect from
random and unexpected surges in request volumes that threaten the
end user experience, and the availability and performance characteris-
tics of the platform or solution. It’s crucial to understand the protection
limits and design for them with the appropriate patterns, especially
around high-volume workloads like integrations and batch processing.

Implementation Guide: Success by Design: Implement cloud solutions 43

 The cloud provides us the scalability to deal with large workloads, but
a shared public cloud doesn’t mean you have unlimited capacity or
computing power. In many cases, these capacity limits are enforced
Plan for the daily peak and the monthly
maximum order transaction
via licensing. You have to embrace this capacity-based model of cloud
volumes expected to ensure that the infrastructure and plan to operate within the entitlements, taking
service is licensed to satisfactorily
support the peak as well as the total into account usage profile, data volumes, and integration patterns.
maximum expected volumes. Also, plan Understanding these protections and service boundaries that apply
and prioritize for integrations and Open
Data Protocol (ODATA) requests based to a specific service helps bring clarity on available resources. It also
on the volumes, so they’re honored and
drives the right behavior when it comes to design and development so
not throttled due to request limits. These
checks and balances prevent overutilizing the solution is optimized to operate within the allocated capacity, or
resources, preserve the system’s respon-
siveness, and ensure consistent availability
additional capacity is procured to meet the requirements in advance.
and performance for environments
running Dynamics 365 apps.
Check out Chapter 20, “Service the solution,” for more information.

Integration with on-premises systems

The SaaS cloud might be the preferred approach for new applications,
but in most enterprise solutions, you could still have on-premises
elements. Therefore, it’s common to build integrations with these
on-premises systems. Establishing these integration patterns in
compliance with your internal security policies while allowing cloud
applications to authenticate and connect to on-premises services is
critical. This could involve allowlisting URLs and IP ranges on your
firewall, or using technologies like the Azure AD Application Proxy or
an on-premises gateway that allows such integrations without having
to open inbound connections into your customer’s corporate network.

Even from a design standpoint, patterns that worked on-premises

could be challenging in the cloud, due to latency and additional secu-
rity restrictions imposed. An example is the encryption of traffic leaving
a customer network or routing via a peering network.

Cloud and edge

The public cloud is the default and recommended choice of deployment
for the majority of Dynamics 365 customers, but you may want to extend
the cloud to unlock important capabilities for key scenarios where con-
nectivity is an issue. Your industry may need a solution on the ground,
such as brick and mortar commerce, field service, a manufacturing execu-
tion system (MES), warehouse operations, and project operations.

Implementation Guide: Success by Design: Implement cloud solutions 44

 These implementations are called cloud and edge, where cloud is the
system of intelligence and edge is the system of record.

For example, Dynamics 365 Commerce customers use the cloud and
edge model, in which the store operations run on-premises (edge)
and the main instance handles centralized back office functions like
finance, data management (such as products and customers), and
analytics (cloud).

Cloud and edge deployments provide business continuity for

mission-critical functions like point of sales, warehousing, and manufac-
turing. We want you to be able to continue running operations when
disconnected from the cloud. In case of a network outage, Dynamics 365
Point of Sales can sustain itself with basic operations and keep data gen-
Patterns that erated locally. When connectivity resumes, data is synchronized to the
worked on-premises cloud. Also, whenever throughput is high and more heavy processes are

could be challenging run in parallel, user productivity may be impacted. We want to enable
you to scale out and run manufacturing and warehouse processes in
in the cloud. isolation so high user productivity is always supported.

Another reason for choosing an on-premises deployment model is

that these businesses have made significant investments in local IT
infrastructure. We want to ensure you receive a meaningful return on
investment (ROI) before taking the full cloud route.

Another reason is internet connectivity. Regions with poor internet

connectivity see more occurrences of on-premises deployments.
Organizations operating in such regions go with an on-premises model
to mitigate the risk to their business from poor connectivity. They also
want to maintain a stable user experience for their staff.

Customize and extend

cloud applications
A SaaS application with rich features also provides powerful capa-
bilities to customize and extend the app to meet specific business

Implementation Guide: Success by Design: Implement cloud solutions 45

 Adopt a cloud mindset requirements. Customizations to the SaaS application can be at several
levels. Many involve little code (embracing the low-code/no-code
Cloud implementation philosophy) and offer the flexibility to tap into the underlying PaaS
layer. This allows you to take advantage of professional software devel-
Customize and extend
opment techniques that include custom code.
cloud applications
Operate in the cloud Chapter 15, “Extend your solution” covers the details of customization
and app extensions, considerations, and scenarios. In this chapter, we
Evergreen cloud focus on the principles to keep in mind when making decisions about
customizing the application or extending platform capabilities. While
Upgrade from on-premises
to the cloud these principles broadly apply, in some cases a tradeoff is necessary,
in which the approach depends on specific situations, in-house skills,
timelines, budget, user expectations, processes, and other factors.

Know the platform

When using a SaaS cloud platform like Dynamics 365, it’s important
to know that this isn’t a one-time software purchase. It’s an ongoing
partnership between the customer and service provider, with an
operating contract that governs the service-level agreement (SLA),
security, ongoing updates, and more. You need to understand how the
service runs and how updates and changes impact your solution (and
therefore business), and employ the supported way of extending and
customizing the application in harmony with the service contract. With
this knowledge and compliance, you can ensure continued support
and avoid unexpected issues.

Even when using supported extension techniques, you need to adhere

to best practices. A good example is that while the platform might
allow you to run synchronous code for up to two minutes when creat-
ing a record, running to the time limit would block a user’s UI thread
for two minutes when they save a record. Is that acceptable? Similarly,
you could use custom code to limit access to records and implement
a custom security requirement, but certain access mechanisms could
bypass your custom code, leading to exposure. The point is to carefully
design your customizations and assess their impact, particularly when
those customizations affect the end user’s experience or deviate from
the security control constructs provided by the platform.

Implementation Guide: Success by Design: Implement cloud solutions 46

 In general, the low-code/no-code techniques that rely on configu-
ration rather than custom code are optimized by the platform, and
should be a preferred approach. However, custom coding may be re-
quired in some use cases. We have a no-cliffs philosophy with limitless
possibilities to extend the application using the underlying platform.
The ability to address this by using the underlying PaaS is a superpower
in the world of SaaS applications.

Be aware that custom coding and PaaS extensions bring additional

maintenance responsibilities and are best left to professional devel-
opment. Even when using PaaS to extend your solution, serverless
technologies are usually better suited to this approach.

Other factors include solution capacity planning, which should con-

sider the impact of your customizations, and the implications of using
certain PaaS technologies that use a pay-as-you-go model. We recom-
mend your organization establish guidelines for customizations that
Using a SaaS cloud take into consideration the platform, user experience, security, and
platform is an approved patterns for integrations. In addition, enforce best practices
ongoing partnership with automated checks wherever possible in the build pipeline. Power
Platform includes an app checker and app monitor that can help
between customer identify unsupported techniques and anti-patterns that can lead to
and service provider. performance and scalability issues.

Don’t mimic your existing system

A common misstep is trying to mimic a legacy system or the features of a
different SaaS platform when implementing a solution. This mindset can
lead to excessive customization and prevent you from realizing the true
potential of the platform and all its strengths to build your solution. To focus
on business value, you should adopt a business process–oriented approach.
It’s important that business requirements aren’t muddled with implementa-
tion details or dictate a specific approach rather than a business outcome.
A simpler approach is to look at the business processes for transfor-
mation and implement those using the platform capabilities instead of
replicating the existing solution. It’s closer to business, future-proof, less
costly, and easier to maintain than simply lifting and shifting your existing
experiences to the cloud. You also avoid technical debt from excessive

Implementation Guide: Success by Design: Implement cloud solutions 47

 customizations. Aligning to the platform allows you to maximize its capa-
bilities so you get an evergreen, always up-to-date solution.

Future-proofing
One of the key principles we have established in this chapter and through-
out this book is getting comfortable with change. SaaS enables you to
adopt new features to maintain a competitive edge. These features and
capabilities are built on top of an existing baseline of features and tables.
Although repurposing or using a custom table may not be unsupported,
deviations can severely impact your ability to take advantage of future
capabilities or can affect the interoperability of your solution.

In addition to the business process–oriented approach to implemen-

tation, we also recommend that you review your existing business
processes and compare that with what the standard application has to
To focus on business offer. You can benefit from adopting standardized processes backed
value, adopt a by research and feedback from leading customers in their industries,

business process– because you benefit from all that expertise. Using standard processes
also makes your business less dependent on expensive and hard-to-
oriented approach. maintain customizations.

The Common Data Model (CDM) is an open standard schema for

business data created in collaboration with SAP and Adobe, and is
used across Dynamics 365 applications. Aligning to the CDM can help
future-proof your solution. It can also make sure you can take advan-
tage of enhancements as well as other business applications across the
industry that honor the schema and can easily interpret your data.

Another way to future-proof is to understand your roadmap, in-

vestment direction, and trends so you can better align to the future
direction of the platform. This helps reduce technical debt and rework.

Understand the tradeoff

Expect tradeoff decisions to be made when implementing your
solution, particularly when it comes to the user experience (UX). In
Dynamics 365, the platform provides several out-of-the-box controls

Implementation Guide: Success by Design: Implement cloud solutions 48

and UX patterns that can be reused in a model-driven paradigm to
quickly assemble applications. These address common usage patterns
and also meet accessibility standards. It’s common for a business to
make specific requests around application navigation, behavior of a
specific control, or even colors to highlight specific controls. From a
technical perspective, most of these UX needs can be met either by using
custom code to build custom controls or by using a different app para-
digm, in which you start with a blank canvas to develop a pixel-perfect
UI that you could use in combination with model-driven controls.

Several factors could guide these decisions, including user adoption,

but you should also assess the cost-benefit ratio of customization.
In some cases, building and maintaining custom controls can be
time-consuming and require specialized skills. If you can easily address
some scenarios with user training, you can save hundreds of hours of
development and test effort. In addition, specialized UX requests are
often subconsciously driven by the need to replicate an existing system
or just a familiar pattern, even though the requests defy modern UX
best practices and accessibility needs.

Independent software vendors

Independent software vendors (ISVs) are third-party organizations that
exclusively develop software or software solutions that are compatible
with the service to deliver additional capabilities.

An effective way to approach extending your solution is to use an ISV

solution from the app marketplace for your platform. This can save
time and effort in development and testing, and provide you with a
tried and tested solution used by peers in your industry.

Several industry-focused ISVs provide solutions to fill unique product

gaps and address specific business needs in industries such as fashion
and hospitality. Make sure to perform due diligence when looking for
an ISV. For example, an ISV needs to make sure their solution is avail-
able for the version you’re targeting for go live. Otherwise, deployment
timelines can be affected. It’s also important that you’re aware of the
support model for an ISV, their commitment to keep it up to date, and
the protection clause if the solution provider goes bankrupt or is sold.

49
 You will also want to know how the ISV handles deprecation notices for
phased out software and update cycles.

AppSource offers a variety of ISV solutions

to suit your needs.
Chapter 15, “Extend your solution,” provides a deeper dive into making
a solution work for you.

Adopt a cloud mindset

Operate in the cloud
Cloud implementation
Successfully operating in the cloud will drive business value for your orga-
Customize and extend nization. Having the right skills and the change management processes
cloud applications
aligned to your platform will ensure you are set up to operate smoothly
Operate in the cloud and derive continued value from service updates and enhancements.

Evergreen cloud Center of Excellence

You might have a partner and specialized development team assist
Upgrade from on-premises
with the initial deployment, but once in “business as usual” operations
to the cloud
mode, does your team have the skillset to manage the platform, main-
tain the custom components, and assess and implement appropriate
new features? Not having the correct level of expertise and guidance
onboard after you go live can inhibit solution advancements and
undermine your ability to take full advantage of the platform. Creating
a Center of Excellence (CoE) within the organization and investing in
developing the skills to operate on the platform is extremely valuable.
Organizations that embrace organic application development by end
users also need a well-established CoE. This center can administer,
nurture, govern, and guide users to adopt the citizen development
approach to business applications, empowering everyone to create
innovative apps with high standards by using a consistent application
lifecycle management (ALM) process.

Microsoft provides a CoE starter toolkit that includes prebuilt processes:

▪ Administer  Gain insights into your Power Platform adoption
▪ Govern  Establish audit, compliance, and archive processes
▪ Nurture  Accelerate your adoption with a thriving community
▪ Drive innovation  Pick the most impactful and valuable scenarios
for development
▪ Consistent ALM  Apply source control strategies using GitHub

Implementation Guide: Success by Design: Implement cloud solutions 50

 ▪ Standards and theming  Create, manage, and share enter-
prise-branded themes as well as maintain and follow organizational
best practices and standards
You can read more about CoE at
Establishing a Microsoft Power
Platform Center of Excellence. Usage and monitoring
Running your business on the cloud means you want the cloud to be
always available, responsive, and scalable. You also want to be alerted
to unexpected issues in the applications and infrastructure so you can
diagnose and fix them. Additionally, you want to comply with SLAs you
have in place from other businesses. Having a monitoring capability
can prepare your business to meet these objectives.

What to monitor?
Different personas in your company will want to monitor for different
aspects of the system. End users may be more concerned with respon-
siveness, admins may be looking at changes, and the business may be
looking at KPIs like the time taken to place an order.

When running a SaaS application, you want to focus on the business,

while a service vendor assumes the role of maintaining the solution.
As a customer, you still have a level of control over the solution. This is
especially important when you have customizations in place to fine-
tune the business processes for your organization. If you introduce a
new feature in production and it causes unexpected issues, you want to
detect it proactively and resolve it before it becomes a problem. Using
For example, you can configure
Dynamics 365 and Azure features and flags to control new features can serve you well in these
Application Insights to access
situations because you can quickly turn off a faulty feature.
telemetry and diagnostics data
and set up alerts and dashboards
to proactively monitor your
Dynamics 365 environments.
A proactive and reactive monitoring strategy that empowers your staff
to detect and resolve issues should be part of every customer’s arsenal.

Best practices for monitoring

Keep in mind the following best practices:
▪ Decide what exactly to monitor, especially the KPIs, and whether
the service is meeting them.
▪ Monitor your consumption, subscription, and services fees. The
more cloud services you use, the more they will cost.
▪ Use automation to automatically trigger actions and to alert

Implementation Guide: Success by Design: Implement cloud solutions 51

 people when thresholds are reached.
▪ Track user activities for accountability (including the applications, screens,
and features they use), the responsiveness, and the frequency of use.

Adopt and align to a product roadmap

Your cloud solution will continuously evolve and deliver on the prom-
ise of digital transformation by delivering new capabilities that help
you stay competitive in your industry. Cloud vendors do their own
research and listen to customer feedback to improve the product by
adding new features. Being actively engaged in this process by giving
feedback, staying abreast of the latest roadmap, and planning for
upcoming changes is an effective way to operate in cloud. Also, the
key stakeholders from the business need to remain engaged and stay
plugged in to new features development, investments, and product
direction. We recommend developing your own roadmap for business
applications and aligning this to the product direction to get the most
out of your investments.

Dynamics 365 has two release waves per year in which several in-
cremental enhancements and new capabilities are made available
to customers. Adopting these mandatory changes and new fea-
tures—many of which are included in existing license plans—are a
fundamental aspect of operating in cloud.

Stay engaged
Implementing the system is one thing, but getting continuous return
on investment (ROI) from your cloud solution requires engagement.
Companies who stay passionate and curious about the solution and
adopt the latest features are the ones who enjoy most success. We
urge all customers to maintain engagement through conferences and
events throughout the year, and stay connected by using community
You can choose from application-specific groups. Several official and unofficial communities have been formed
forums like the Microsoft Dynamics
Community Help Wiki, Yammer groups,
by customers, partners, and Microsoft engineering. Take every op-
blogs, events, and how-to videos where portunity to influence the product through active engagement with
you can discuss ideas, learn features, learn
roadmaps, and ask questions. product leaders, advisory boards, table talk with product managers,
preview programs, and collaborative development opportunities.

Implementation Guide: Success by Design: Implement cloud solutions 52

 Evergreen cloud
Adopt a cloud mindset

Cloud implementation
One of the benefits of a modern SaaS solution is that every custom-
Customize and extend
cloud applications
er runs on the latest version of the service. It’s the only model that
scales. With this approach, every security patch, bug fix, performance
Operate in the cloud enhancement, and functional improvement accrues to all implemen-
tations across the globe. Microsoft assumes responsibility for keeping
Evergreen cloud the platform current. This means that you no longer have to pull large
teams of people together every few years to perform a traditional
Upgrade from on-premises
to the cloud upgrade over many weeks or months with limited added value for the
business. The evergreen approach and the model of continuous up-
dates gives your business access to the latest capabilities to stay head
of the competition and meet changing customer expectations.

Dynamics 365 has embraced this approach of operating on one

version in a way that delivers benefits without disruption. The improve-
ments and enhancements embrace the CI/CD model, with service
updates delivered on a weekly basis, but these changes aren’t targeted
at the end user experience. You can take advantage of release waves to
preview upcoming changes and test and prepare your users before the
changes are deployed.

Achieving the right balance of delivering improvements and business

capabilities in a safe manner without disrupting the user experience is
paramount to our evergreen cloud approach.

Chapter 20, “Service the solution,” delves further into the updates
wave approach.

Upgrade from
on-premises to the cloud
Organizations over the years might have invested in on-premises
deployment of business applications. These applications could serve
the users and business well in their current state, but keeping them

Implementation Guide: Success by Design: Implement cloud solutions 53

 Adopt a cloud mindset on-premises over time could limit your opportunity for expansion. In
these cases, you should explore upgrading or migrating an existing
Cloud implementation on-premises business application to the cloud and bringing along exist-
ing business processes and data to speed up your digital transformation.
Customize and extend
cloud applications
Dynamics 365 provides the tooling and support to help on-premises
Operate in the cloud deployment upgrades or migrations to the cloud (subject to compat-
ibility and security checks). This option to upgrade to the cloud also
Evergreen cloud helps organizations take advantage of their existing investments in

Upgrade from implementation, as long as the supported implementation techniques

on-premises to are used and compatible with the cloud. Still, everything we discuss
the cloud in this chapter on the cloud mindset, considerations, extension, and
operations is fully applicable.

When upgrading or migrating to the cloud, consider the following:

▪ The most critical factor in deciding on the upgrade-to-cloud ap-
proach is to assess if the current application being upgraded meets
the requirement of the business and is well adopted by users.
▪ The data model, design, and data quality should ensure that the
application being upgraded becomes a stepping stone to acceler-
ate digital transformation. The upgraded application should serve
as a foundation for further growth and adoption of new capabili-
ties in the cloud. It shouldn’t stifle cloud adoption by carrying over
poor design and data.
▪ The cloud platform should be approved by security to store and
process data in accordance with the organization’s security policies
and regulations. The patterns used for authentication and integra-
tion also need to be revisited to make sure they’re cloud ready.
▪ Understanding the data category, flow, transformations, location,
and encryption during and post migration will help you navigate
The Dynamics 365 Migration Program organizational security policies and plan your cutover.
can help you take the first step toward
▪ The upgrade to the cloud can be a multi-staged process that involves
cloud success by migrating your on-prem-
ises solution with expert guidance from stringent compatibility and validation checks, so it’s critical to under-
Microsoft. For more information, refer to
the overview of our program or perform a
stand the process and review the prerequisites early in the process.
standard migration assessment. ▪ Some components in the on-premises application may need to
You can also move from Dynamics AX to be remediated or replaced to ensure cloud readiness. Examples
Dynamics 365 in the cloud.
to look at include deprecation, unsupported customizations, and
non–cloud ready patterns that pose a security or performance risk.

Implementation Guide: Success by Design: Implement cloud solutions 54

 ▪ Existing integration and peripheral applications will require
changes to ensure they work with the cloud applications.
▪ Any impact on process, performance, and usability due to latency,
service protection limits, or license capacity should be considered.

The ability to bring existing Dynamics 365 on-premises applications

into the cloud with proper due diligence can be a game-changer for
your digital transformation.

Conclusion
Embracing SaaS applications to run your business can significantly
accelerate your digital transformation, but it’s also important to rec-
ognize that organizational cloud maturity will play a significant role in
your strategy’s long-term success.

Organizations working on their first major implementation in the SaaS

cloud should expect some level of disruption to the existing ways of
deploying and managing applications. We hope this chapter serves as a
primer for Success by Design thinking by helping set the context for the
changes you can expect and driving you towards greater cloud maturity.

Implementation Guide: Success by Design: Implement cloud solutions 55

 Checklist

Adopt a cloud mindset Ensure that when upgrading existing on-premises solu-
tions to cloud, the data model, design, and data quality
Have a shared understanding at every level, from the make certain that the application becomes a stepping
executive sponsor to the developers, of the business stone and doesn’t stifle cloud adoption by carrying over
impact being delivered. poor design and data.

Ensure the organization has done its due diligence

organizing the data estate and understands the impact Customize and extend
of the new solution on the data estate.
Create guidelines for when to customize and extend
Gain approval for the cloud platform for use with the out-of-the-box apps and only adopt documented
appropriate application data category from information extension techniques.
security and compliance.
Avoid deviations and repurposing the out-of-the-box
Ensure the respective teams understand all administra- tables and data models (Common Data Model) because
tive, operational, support, and monitoring aspects of the this inhibits future adoption of new features and
platform, and the organization policies, processes, and capabilities.
patterns conform to the SaaS cloud.

Implement DevOps and CI/CD pipelines to support Operation

automation for build, testing, and deployment.
Ensure that the necessary expertise is available via the
Design the solution according to service boundaries and partner (system integrator) or internal teams post-de-
available licensing capacity, and ensure the controls to ployment to support and evolve the solution.
further expand and scale the solution are understood.
Engage with the community to keep up with the latest
Design the solution to meet the nonfunctional re- innovation and help influence the product direction
quirements, considering factors like network latency, using channels, events, blogs, and other mediums.
end-user environment, and devices.

Implementation Guide: Success by Design: Implement cloud solutions 56

 Case study
Rev up for speedier service
A family-owned business based in South Australia is one of the largest
retailers in the region, with ventures that span fuel, convenience, quick-
serve restaurants, and real estate.

One of its key businesses is a chain of retail stores that serves busy
guests across Australia.

Their focus on customer service has led the company to reimagine

the way its store systems are designed and connected. As their retail
chain has grown, they have faced common challenges: outdated
technologies, changes in customer behavior, and the pace of change
with existing suppliers. The company was ready for an overhaul and an
infrastructure solution that could serve its goals now and in the future.

Given the high volume of traffic that the retail chain processes and the
diversity of its retail store locations, the company was seeking a hybrid
solution with reliable, flexible connectivity.

Scalability and speed are critical for their retail business, and they
needed an infrastructure design that optimizes for both.

“We serve millions of guests each month,” says the company’s store
systems specialist. “To achieve speed of service, we know that we need
to have something on-premises to retain our workloads in the store.
And, at the same time, we need to have that cloud connectivity to the
back office.”

Implementation Guide: Success by Design: Implement cloud solutions 57

 A cloud engineer at the company adds, “We have stores in rural areas
where they don’t have high internet speed connections. We wanted
to have something that is both in-store and in the cloud that would
synchronize when it comes to failovers and redundancy, so that we can
have the best of both worlds.”

When it came to renewing store hardware and to keep up with the

pace of innovation, the company chose to go with a hybrid model that
integrates Azure, Azure Stack Edge, and Dynamics 365 Commerce.

The new design impacts the stores’ day-to-day connectivity. “What

we are planning to do is a direct connection to Dynamics 365, and the
failover needs to happen in Azure Stack Edge,” one engineer said. “We
expect to have a minimum of 99 percent of uptime.”

One of the team’s other top considerations was how easy the infra-
structure would be to manage, so they factored in what the company
was already using across its retail business.

“We have already heavily invested in Microsoft products. We use

Dynamics 365, Microsoft 365, Power BI, and multiple other products,”
explains one engineer. “We wanted to have a single pane of glass
where we could administer and monitor all of the systems.”

The hybrid deployment model using Azure Stack Edge and Dynamics
365 Modern Point of Sale provides store operations redundancy in case
of network outage.

The new infrastructure design provides the connectivity, consistency,

and efficiency that the company needs. Over time, the company ex-
pects that it will help them avoid store downtime, maintain real-time
stock levels, simplify its infrastructure management processes, and
reduce maintenance and compute costs.

The new infrastructure design will impact the customer experience at

the store level. “We offer a comprehensive omnichannel experience to
guests walking into our stores,” says the store systems specialist. “We
enable our guests to pay at the pump without having to come into the

Implementation Guide: Success by Design: Implement cloud solutions 58

 store by using the [retail chain] app. We also enable our guests to click
and collect their food, coffee, or supermarket needs. To enable that, we
need real-time connectivity to our head office systems—that is key for
us. With Azure Stack Edge and an in-store database, we are hoping to
get that real-time connectivity.”

This orchestration ensures connectivity and consistency, as a cloud

engineer explains. “We deployed three virtual machines. One is used
to monitor the in-store cameras, and the other is used to store a
Dynamics 365 database backup. If the store loses its internet connec-
tion to Dynamics 365, it would be able to operate normally while that
virtual machine continues with the operations. Then, once the connec-
tion is restored, it will be able to synchronize back to Dynamics 365.”

As the company continues to roll out its new infrastructure, it’s piloting
a solution to recognize vehicles’ number plates based on real-time
CCTV feeds. One benefit of this is loss prevention, in situations where a
number plate is tied to a known offender in a published database.

They also plan to use the in-store cameras to do machine learning and
AI on Azure Stack Edge virtual machines to predict stock levels and
alert the staff, all locally, without the cloud.

Implementation Guide: Success by Design: Implement cloud solutions 59

4 Guide
Drive app
value
Implementation Guide: Success by Design: Drive app value 60
 Introduction
In the constantly evolving world of Dynamics 365,
software as a service (SaaS) cloud applications, and
changing business needs, it’s important that your
business applications evolve and are consistently
delivering value.
This chapter outlines the approach to digital transformation and dis-
cusses strategies on how to shorten the time to value, cut through the
noise, and focus on business outcomes.

The digital transformation journey of an organization usually involves

various phases and levels of maturity. A green field implementation could
start with a pilot or even a minimum viable product (MVP) targeted
Key topics in this chapter: at a specific business process, then incrementally expand the solution
with more capabilities for the users and onboard new business pro-
Think like a startup: start lean, build a
successful MVP, evolve quickly cesses. Alternatively, replacing an existing system could mean that a
significant amount of functionality needs to be made available at the start
Phases and incremental strategy
in order to have parity. No matter where you start, realizing the long-term
Manage the change stream: business,
user, and product
goals of a SaaS-based digital transformation requires effective planning.

Achieve hyper-scale with expansion

approaches and enable organic growth In this chapter, we explore how to create a digital transformation road-
map for your organization that can help accelerate the time to value
Better together: satellite applications
and aggregations while maintaining relevance in a constantly changing technology and
business landscape. This guide can help you navigate the challenges

Implementation Guide: Success by Design: Drive app value 61

 of expanding your solution and drive continuous, long-term business
value through digital transformation.

Approach to digital
transformation
Throughout this book, we discuss several concepts related to Success
by Design, including how to initiate, implement, and deploy a project,
but the scope of Success by Design isn’t limited to a successful go live
or operational excellence. The long-term goal of Success by Design is to
create the right foundation for an organization to evolve their business
application landscape and expand their digital transformation footprint.

Success by Design Every implementation related to business applications doesn’t nec-

creates the essarily qualify as a digital transformation program aligned to the
foundation for business; several systems are migrated to the cloud in their current
form as a part of infrastructure modernization or to ensure sup-
an organization portability. In some cases, this is just the first step towards enabling
to evolve their digital transformation; opportunities could arise to take it further and
business application deliver transformational value to the business rather than looking at it

landscape. as just a tactical upgrade to projects run by IT with little involvement

from the business.

The discussion in this chapter targets business-focused digital trans-

formation programs and their expansion. Before we go into the details
of expanding a solution to further drive value, let’s discuss the funda-
mental approach to transformation: depicting your current business
model, the factors that affect your business model, how they can
trigger transformation, and defining your goals and scope of business
processes for a transformation roadmap.

Represent the business model

Before you define a digital transformation roadmap, a good strategic
exercise is to holistically develop an understanding of your business
model. You can do this at an organization, department, business unit,

Implementation Guide: Success by Design: Drive app value 62

 or team level to understand the value that you currently deliver, who
your customer is, and how to deliver that value and the key activities
and resources involved.

You could use several different techniques or frameworks to describe

an organization’s business model and how they create value. One
framework that we discuss in more detail is the Business Model Canvas,
developed by Alexander Osterwalder. It offers a simple, holistic, and
easy-to-understand representation of a business model. This model
isn’t officially endorsed by Microsoft or part of Success by Design, but
you can use the model to not only map your existing business model
but also highlight what aspects of your business model are changing—
which your digital transformation strategy will help you adapt to.

The business model represents the “why” and what it takes to deliver
the value to customer; how we go about doing it is the business
process definition.
Disruptions in the
business model
Triggers
create opportunities
Disruptions and inflections in the business model create big opportunities
for transformation. for transformation. In a world that’s changing at a pace greater than ever,
businesses have to reinvent themselves more often, improve customer
experiences, and attract and retain talent. The opportunities for impact
are plentiful (for a deeper discussion, see Chapter 1, “Introduction to
Implementation Guides”).

Let’s explore some examples of how changes in the business model,

disruption in an industry, new regulations, or even external factors like
global events can be a catalyst that triggers changes to business pro-
cesses and applications.
▪ Changes in customer segment  As businesses evolve their
products and expand their target customer base and demograph-
ics, they often see that their approach to nurturing their potential
customer base also needs to evolve. Targeted messaging that
resonates and is delivered through relevant channels becomes
extremely critical. Does your marketing automation and customer
data platform enable this?

Implementation Guide: Success by Design: Drive app value 63

 ▪ New channels  Customer channels that the business uses to
deliver their product and services are evolving. For example,
customers expect remote delivery of services via digital channels
instead of an in-person visit to a store, which is further necessi-
tated by evolving circumstances such as the COVID-19 pandemic.
What does this change in channels mean for your order manage-
ment systems or other related business processes?
▪ Changes in value proposition  Businesses might differentiate
themselves by coming up with unique customer value proposi-
tions in highly competitive sectors, such as offering a lucrative
subscription model, to drive recurring revenue and shareholder
value. For example, customers aged 25–40 are more open to
subscription-based purchases versus outright ownership. The
automobile industry now offers cars on a subscription basis and
charges based on miles driven, as opposed to customers paying
full purchase price. How are your processes and business applica-
tions affected by this change in business model?
▪ Changes in customer relationships  An organization’s ap-
proach to engaging with customers evolves with the business.
For example, an organization could change from an aggressive
customer acquisition phase to retaining and upselling within their
existing customer base after acquiring a fair market share. How is
your customer relationship management (CRM) strategy chang-
ing, what does this mean for your CRM system?
▪ Changes in revenue streams  As businesses evolve, they create
new revenue streams. For example, an energy provider in a highly
competitive market might provide home services to expand their
revenue stream, which triggers changes to customer processes
and related business applications. Do you know how your revenue
stream changes impact your business applications?.
▪ Resources and sustainability  More organizations are commit-
ting to environmental sustainability. How do your manufacturing
and operations track your carbon footprint, impact on emissions,
and procurement from sustainable sources?
▪ Custom manufacturing  With the advances in 3D printing tech-
nology, a manufacturing company can offer custom, made-to-order
options to their customers. How does this impact your operations
processes and enterprise resource planning (ERP) application?

Implementation Guide: Success by Design: Drive app value 64

 ▪ Partnerships and acquisitions  Inorganic, acquisition-based
growth is common in several industries, and so is the strategic
partnership between organizations to grow market share where
they have complementary services. How do these changes affect
process alignment and your supporting business applications?
▪ Cost and efficiency  New technologies offer efficiency advan-
tages that can reduce operational costs. For example, delivery
companies use electronic signatures instead of paper-based
solutions to get real-time notifications and provide new value
to customers. Are there opportunities to drive process efficiency
using the latest technology?
▪ External factors  Changes in the socioeconomic situation, po-
litical climate, and regulations can affect the way organizations
conduct business. For example, the EU’s decision to bring in the
General Data Protection Regulation (GDPR) affected every busi-
ness with employees and customers in EU, which required changes
to their business applications to ensure compliance. How are new
Changes to the and changing regulations impacting your business?
business model can
kickstart digital These triggers can all disrupt your existing business model. You can use
the Business Model Canvas to highlight what aspects of your business
transformation. model are changing and align your digital transformation strategy to
these changes, which will eventually help your business adapt and grow.

Digital transformation goals

Changes to the business model (caused by a variety of triggers) can
kickstart digital transformation. These transformation goals must be
defined in business terms, with measurable metrics that could poten-
tially involve several milestones. Let’s look at an example in which an
organization’s goal is to create a 360-degree view of their customer.
They want a holistic view of their customer, their activity history, prod-
uct purchases, subscriptions, and more. But this goal doesn’t relate to a
business outcome or a measurable key performance indicator (KPI). A
measurable goal for your digital transformation could be the business’s
ability to increase upsell to existing customers by X percent or reduce
the time to address customer queries by Y percent. This requires a
360-degree view of the customer.

Implementation Guide: Success by Design: Drive app value 65

 Although most programs begin with a set of business goals, it’s equally
important to communicate and reiterate these goals to the IT and
technical teams implementing solutions. In long-running transfor-
You can use objectives and key results
mation programs involving several technologies, teams and partners
(OKR) as a goal-setting framework for
digital transformation. might lose sight of the actual business goals by letting technology
become a distraction.

Business process
The next stage of the process is discovery, which involves key business
stakeholders. With a holistic view of the evolving business model and
transformation goals in place, you can identify the related business
processes and applications that need to change. The discovery exer-
cise should be focused on creating clarity around how the business
processes and applications identified need to evolve to meet the
corresponding transformation goals.

The scope of change could be automating a manual activity to

improve productivity, capture data accurately to improve the effec-
tiveness of strategy, and help your users do their job better and more
efficiently. This will enable the business to generate insights about your
customers by eliminating data siloes.

Prioritizing the changes to maximize and deliver measurable business

impacts continuously (without having to wait for a multi-year trans-
formation program to complete) keeps digital transformation in the
foreground, with engagement from the business, end users, and exec-
utive sponsors maintaining its relevance. Business agility should be the
key focus for long-running, comprehensive transformation, or you risk
missed business opportunities and loss of market share.

For more information, refer to Chapter 7, “Process-focused solution.”

Change streams
So far, this chapter has discussed the approach to digital transforma-
tion and how to develop a transformation plan for your application

Implementation Guide: Success by Design: Drive app value 66

 and the process involved. This has traditionally been a top-down
approach, starting at the business model and then narrowing down
to business processes and applications that deliver the most impact.
However, you should always keep in line with the broader theme of
constant change and embrace the mindset of getting comfortable with
frequent and inevitable change. In this section, we explore the change
streams that impact the roadmap and scope of planned activities.
Planning for how to deal with these changes throughout the program
is a key determiner of success.

Business
As we embark on the journey of transformation and start building the
business application based on the goals set by the business, it’s also
important to appreciate that during design and implementation, you
may need to accommodate for further adjustments and refinements.
Embrace the This support for agility and change needs to be fundamentally built

mindset of getting into the program. This is where some of the iterative methodologies
could be beneficial, enabling us to respond to the change without it
comfortable with turning into a disruption.
frequent and
inevitable change. Those leading or adopting transformational change often find that
it’s not well defined in the early period, so adopting changes quickly
and early is key—but so is flexibility as clarity reveals the resulting
business model. When transformation occurs in an industry, what the
industry will look like following the transformation is often not known.
Companies must be able to adapt quickly in the middle of the project
to incorporate these inevitable changes.

User
A key stakeholder in your transformation plan is the business user, who
interacts with the application daily. If the process being implemented
in the application doesn’t meet the needs of the user, or the applica-
tion doesn’t consider working patterns and end user usage, it could
lead to poor adoption and lack of engagement. Incorporating user
feedback continuously throughout the process using well-defined and
frequent touchpoints is key to achieving your transformation goals.

Implementation Guide: Success by Design: Drive app value 67

Your approach to designing and developing the application needs to
be user-centric; it must clearly articulate how the change being imple-
mented results in value for the user.

You should expect that user experience expectations constantly evolve

as users are exposed to a variety of software products both in the enter-
prise and consumer space. For example, the predictive text fill feature
popularized by web search engines is now the expected search expe-
rience in business applications. This makes it even more important to
adopt newer features and improvements delivered by SaaS applications,
which takes us to the next change stream: product and technology.

Product and technology

In the world of cloud-based SaaS applications, you can expect a con-
stant flow of new capabilities, improvements to existing features, and
transitions to the latest technology paradigms, which can impact your
current application. Traditionally, business applications were built by IT,
with features requested by the business and end users. With the SaaS
cloud, the service providers themselves are invested in understanding
the latest trends in business and delivering innovative capabilities to
help their customers stay ahead of the competition. For example, a
business trying to transform their sales application can assemble an
application using the best-in-class sales capabilities offered by the
SaaS provider instead of spending years in research, design, and de-
velopment to build from scratch, which would make the application
obsolete by the time it launches.

Continued investment in microservices by Dynamics 365, such as

planning as a service, can transform a core business model for companies
allowing them to run material requirements planning (MRP) as needed
to drive a significant and transformative way of managing demand and
the supply chain.

The enhancement delivered via continuous updates has a much

shorter adoption timeframe when compared to traditional major
version upgrades.

68
 SaaS application providers that are competing to build and deliver
business capabilities for customers are helping advance business appli-
cations in way that was unimaginable just a few years ago. Applications
that were just forms over data (mostly passive data capture systems used
to track, view, and report on known data) have evolved into applications
that can automatically capture data, learn from the data, deliver insights,
and guide users to the next best action. This makes it extremely import-
ant for business to watch for new capabilities being made available and
adopt them to accelerate their transformation to be a differentiator in
the industry. The key value proposition of SaaS is also the ability to tap
into the enhancements and features that are based on broad market
research. Activating these features can accelerate your transformation
with minimal effort and without any development cost.

Your SaaS application provider is no longer just a software vendor

providing an off-the-shelf product—they’re a strategic partner to your
business with significant impact on your ability to implement your
strategy. Developing a strong relationship with the SaaS providers
to not just learn about the roadmap but also influence the roadmap
through strategic feedback ensures that you’re getting the most value
out of the product.

External
External economic, social, and political drivers can disrupt your
transformation plan. The COVID-19 pandemic is an example of how
supporting remote work and creating online collaboration channels
became a top priority for most customers in 2020. This required co-
ordinated changes from infrastructure, to network, to the device and
application layer across the IT level of organizations. Although it’s dif-
ficult to foresee and plan for external events, the iterative approach to
delivering continuous value in smaller batches allows you to pause and
pivot as needed. For example, consider an organization on a long-term
transformation program that releases a major capability to users once
a year versus an organization that has adopted the DevOps culture
of delivering value with regular bi-monthly or monthly updates. The
latter company can realize value from investments and is better posi-
tioned to pivot when change demands it.

Implementation Guide: Success by Design: Drive app value 69

 Transformation map
So far, we have discussed a high-level approach to digital transforma-
tion and the various change streams that you need to consider. The
ever-growing product backlog of feature asks, change requests, and
product capabilities can overwhelm and potentially distract from the
drivers for transformation. To determine time to value, you need a shared
understanding between the business, IT, and users on how a product
feature or change aligns with the goals of transformation and impacts
the maturity of process implementation.

One way to visualize and communicate your digital transformation

goals is to plot the application’s capabilities in a transformation map
(Figure 4-1). You can adjust the definition of each quadrant to your
own goals and ambitions for the process, but you can easily get started
with the template we offer here. If all the feature asks, changes, and
SaaS product capabilities are plotted on this quadrant, you can deter-
mine the current state of your business process implementation and
agree on the future state aligned to your transformation goals.

For example, a sales system that only has the basic features of contact
Fig.
4-1 management and opportunity management may be considered
essential, whereas a system that can use AI-driven
insights with advanced forecasting might be a
Enhanced Differentiator

Predictive
differentiator that gives you competitive advantage
forecasting
Forecasting in your industry.
Sequences

Premium autocapture
Creating a dashboard for stakeholders that organiz-
Assistance
cards and studio
es the requirements and features in this fashion can
Essential Innovative bring great clarity—not just during initial implemen-
Contact
Conversion
intelligence tation, but for future increments. It’s also important
management
to prepare for time-based decay, in which a feature
Standard cards
Opportunity
that is considered a differentiator today might be
Advanced

pipeline
management
Quotes
Autocapture
considered essential in a few years. Similarly, some-
thing that is innovative or even considered ahead
Innovative of its time could become a differentiator in the near
future. You should plan to revisit and refresh this

Implementation Guide: Success by Design: Drive app value 70

 transformation map for each phase, product release, pivot, or strategic
inflection in your business.

Phases and increments

Planning and scoping distinct phases of your digital transformation pro-
gram directly impacts the time to value realization. What is delivered and
when it’s delivered also has an impact on the level of engagement from
the stakeholder and the end user’s adoption. These phases and increments
are based on the goals agreed upon with the business and allow you to
select the appropriate capabilities in the transformation map.

It seems reasonable to start with the essentials and basics in Phase 1 of

a solution and then deliver enhancements with most the innovative,
differentiating features in later phases of the program. But if the most
valuable parts of the transformation are planned for much later in the
lifecycle (Figure 4-2), you risk stakeholders losing interest, or user
perception changing (which is hard to correct). Additionally, the fea-
tures that were considered differentiators could now be essential due
to time decay. A transformation program that fails to deliver beyond
the essentials or the initial MVP drives little transformation.
Fig.
4-2

Without the core features, you can’t deliver en-

hanced capabilities. You should plan the phases so
Enhanced Differentiator

Predictive
you can pick up elements from various quadrants
Phase 2 Phase 4 forecasting
and deliver a holistic solution that has the key
Forecasting Sequences
process elements, integrations, and reporting that
Premium autocapture

Assistance cards delivers value (Figure 4-3). Look for quick wins: the
and studio
latest SaaS features that you can easily adopt with
Essential Innovative little effort to bring innovative and differentiator
Phase 1 Phase 3
Conversion
intelligence elements into the earlier phases.
Contact
management
Standard cards
Opportunity Digital transformation is as much about people
Advanced

pipeline
management
Quotes
Autocapture
as the process and technology. The phases and
incremental design should also help product own-
Innovative ers maintain the right level of engagement from
users and stakeholders. This drives excitement and

Implementation Guide: Success by Design: Drive app value 71

 curiosity, but most importantly feedback. You could draw an analogy
from a TV series that shows teasers at the end of each episode or the end
of each series to attract viewers back to the program. Do the same for
your digital transformation story by delivering value beyond the essen-
tials in each phase so customers come back for more after each sprint.

In the next section, we look at how the right approach to MVP strategy
when getting started with your digital transformation journey can help
get early feedback and drive value sooner rather than later.

Minimal viable
product strategy
The concept of MVP, which enables you to quickly build, measure,
learn from feedback, and pivot if necessary, has been well established
in the startup world.

Bringing the invaluable lean startup mindset to digital transformation

can help organizations deal with uncertainty from different change
streams and find the value that drives maximum business impact in
Fig. the least amount of time. Even in the context of digital transformation,
4-3
MVP is often used to test the value of a solution to a business and
gather feedback.
Enhanced Differentiator

Forecasting Phase 2 Phase 4

Predictive
forecasting When translating the lean startup methodology to a
Premium autocapture business application, MVP should not be a solution
Assistance cards
and studio with just the basic and essential features; you should

Phase 1
Sequences create a solution that will help transform your
process and deliver on the most important transfor-
Essential Innovative Phase 3

Conversion
mation goals with the least amount of effort. Most
intelligence
Contact importantly, an MVP is not the end state; programs
management
Standard cards
may be stuck in an MPV state for years.
Opportunity
Advanced

pipeline
management
Autocapture
Going back to the example of a sales application,
Quotes
let’s consider if users are currently using a home-
Innovative grown sales system with a form to enter and view
opportunity data. The system has a backend to

Implementation Guide: Success by Design: Drive app value 72

 store this information, which is also used for management reporting.
The business has invested in a Dynamics 365 SaaS-based sales ap-
plication after assessing its rich features, out-of-the-box AI insights,
and integration capabilities with Power BI for reporting and analytics,
“MVP is not the which allows them to improve their opportunity closure rate and get
smallest product accurate growth forecasts. A common approach is to first implement

imaginable, though the out-of-the-box opportunity management process and reports,

and plan future phases to implement AI-based insights with Power BI.
it is the fastest way Although you can easily follow this route, it doesn’t achieve the actual
to get through the goal of sales implementation. The system delivers an improved user
build measure learn experience but fundamentally does the same thing as the home-grown

feedback loop with sales system, with little direct value to the business. Alternatively, using
embedded intelligence with opportunity scoring and relationship
minimum amount health can help users target the right opportunities and improve their
of effort.” close rate, which directly impacts business.
– Eric Ries, author of The Lean Startup

A good MVP has the following characteristics (Figure 4-4):

▪ Delivers on the most important of the digital transformation goals.
▪ Is production-ready and uses supported customization techniques
(this is different from a proof of concept or prototype designed to
prove feasibility or get specific usability feedback).
▪ Goes beyond the essentials and delivers on top of the existing
capability of the incumbent system.
▪ Focuses effort on delivering maximum business value in the short-
Fig.
est amount of time, (you could compromise on some experiences
4-4
that aren’t directly aligned to business outcomes).

Delivers on Production ready with Beyond the essentials Maximum value to business
goals for supported customization and delivers on in shortest time, minimal
transformation techniques (not proof of existing system compromises
concept)

Characteristics of a good MVP

Creates the foundation, Test hypothesis Test, learn, Built to pivot and
supports building blocks and deliver on activate change after feedback
for success expectations

Implementation Guide: Success by Design: Drive app value 73

 ▪ Is built in a way that allows for quick changes based on feedback,
making it possible to pivot. This translates to a greater reliance on
low-code configuration versus highly customized, professionally
developed, code-heavy experiences.
▪ Allows you to test and learn on the latest SaaS product features
that could be activated (this requires some level of change man-
agement but almost no development effort).
▪ Allows you to test the hypothesis of a specific feature or solution
delivering the expected business outcome and adjust based on
what you learn.
Fig.
4-5
▪ Creates the foundation for long-term success—it should support a
building block mindset in which you keep adding without disrupt-
Build
ing previous steps. (For more information about the architectural
Code
skills to realize this approach, see Chapter 6, “Solution architecture
Ideas Emotional product
Reliable
design pillars.”)
Accessible

Functional
Although the MVP approach naturally works with new greenfield im-
Learn Measure
plementations, you may have existing apps that are being replaced or
Data migrated to another platform. Your scope should consider the existing
functionality to ensure parity, but shouldn’t try to mimic or replicate
the experiences of the outgoing application. Focus your MVP strategy
on delivering the most value to the business sooner without limiting
Fig.
the scope to essentials (Figure 4-5). An MVP with a very broad scope
4-6
that takes years to deliver may cease to be an MVP.

Users
Feature New
adoption workloads
Drive expansion
Incremental Satellite
changes applications All the approaches and techniques we have dis-
cussed so far in this chapter can help you create an
Expansion effective digital transformation roadmap for your
Application Integrations business application. They’re relevant to the Initiate
standardization
phase, but you can apply these methods iteratively
or revisit them for further expansion. This section fo-
Mobile Aggregation cuses on expanding the usage and scope of business
Pivot applications in different areas (Figure 4-6) to drive
even greater business impact, while considering
additional impact on the following:

Implementation Guide: Success by Design: Drive app value 74

 ▪ Security and compliance
▪ Application lifecycle management (ALM)
▪ Administration and governance
▪ User readiness and change management
▪ Environment strategy
▪ Limits and capacity
▪ Data and integrations

Users
The most common expansion scenario for a business solution is add-
ing more users. This could be the result of onboarding new regions
or countries onto the same application. User-only expansion sounds
straightforward, but you could have data migrations on a live system,
security and compliance challenges based on the region, or other
impacts (Figure 4-7).

Mobile
Ensuring support on multiple devices, at times with offline capabilities,
could be critical to adoption. In some cases, this needs to be a part

Fig.
4-7 Users

User readiness
Security and Admin and Environment Limits and Data and
ALM and change
compliance governance strategy capacity integrations
management

High Low Low Medium-high Low Low Medium

Potentially high If the solution Based on the Full-fledged Creation of a Although each Usually, data
impact based remains the environment user change new production user usually migration can
on regional same, impact on strategy and management environment comes with be complex on
regulations ALM is minimal the creation and readiness impacts the their own a live system
of additional effort is required environment capacity and in case
production strategy integration API, of additional
environments, capacity, and environments,
you could see storage could integrations
medium impact be impacted might have to be
replicated across
environments

Implementation Guide: Success by Design: Drive app value 75

 of the initial release (such as in warehousing systems in which goods
must be scanned when picked up), whereas in others it could be a
quick follow-up. Most out-of-the-box capabilities work as is on mobile
apps, with additional optimizations to support the move experience.
Our example sales mobile application offers the core sales application
features with additional targeted mobile experiences for field sellers
(Figure 4-8).

Incremental changes
Incremental changes are primarily driven through the feedback and
change requests from users and the business. These changes help ensure
that the application meets the expectation of ongoing enhancement
and continues to build on top of the initial MVP to maintain relevance.
It’s still important to look at these improvement requests through the
business value and transformation lens (Figure 4-9).

Feature adoption
As we have seen when discussing change streams, SaaS products make
significant investments in researching and implementing business
capabilities that their customers can easily enable. This is a key value
proposition of the SaaS cloud, and can play a key role in deriving value
from your investments. With continuous updates in Dynamics 365,
Fig.
4-8 Mobile

User readiness
Security and Admin and Environment Limits and Data and
ALM and change
compliance governance strategy capacity integrations
management

High Low Low Medium-high Low Low Medium

Potentially high If the solution Additional User readiness Should not have It should not Custom
impact based on remains the device policies effort is any significant have any embedded
the regulations same, impact on could have an required to impact significant integrations
and need for ALM is minimal impact ensure adoption impact on user might require
mobile device on mobile and capacity work to make
management or account for any them responsive
mobile applica- variations for mobile
tion manage- consumption
ment features

Implementation Guide: Success by Design: Drive app value 76

 new features are made available to customers. A business analysis of
the new features with technical impact analysis on the existing solution
and customizations (Figure 4-10) is a key business as usual (BAU)
activity that must be conducted in collaboration with key stakeholders.
Most of these feature improvements are made available to customers
with no additional cost and can help advance your application to the
innovative or differentiator quadrant.

Fig.
4-9 Incremental changes

User readiness
Security and Admin and Environment Limits and Data and
ALM and change
compliance governance strategy capacity integrations
management

Low Low Low Medium Low Low Low

Changes within No major No expected User readiness Usually remains Additional Assuming no
the approved impacts if the impact as long effort is unchanged integration and integration
SaaS service solution doesn’t as the data required app workloads changes, impact
boundaries have new PaaS boundaries could have is minimal
and data loss components don’t change some impact
prevention
policies should
have limited
security and
compliance
implications

Fig.
4-10 Feature adoption

User readiness
Security and Admin and Environment Limits and Data and
ALM and change
compliance governance strategy capacity integrations
management

High Low Low Medium Low Low Medium

Usually No major No expected User readiness No impact Usually no Features might

no impact impact expected impact as long effort is required impact, generate
except when as the data to use the new sometimes additional data
connecting to boundaries features features might but shouldn’t
external data don’t change require additional impact
sources storage and integrations
capacity

Implementation Guide: Success by Design: Drive app value 77

 New workloads
Dynamics 365 provides several business applications that are built
on the same scalable power platform. As end users adopt your ap-
plication, you will find additional opportunities to onboard related
workloads that could help eliminate data siloes by enabling stronger
collaboration and data sharing. For example, to achieve seamless
collaboration when you’re onboarding a marketing workload in addi-
tion to sales, the sales team can get visibility into the nurture programs
their customers are part of, extend invite to marketing events, and
so on. Similarly, the accounts payable team could expand and move
into a centralized accounts payable processing system. However, new
workloads can have significant impact (Figure 4-11).

Satellite applications
When deployed, your business application covers core use cases and
scenarios, some of which may only be relevant to a specific team, region,
or role. In such scenarios, you can deliver such targeted capabilities via a
satellite application. Satellite apps are a good opportunity for user-
developed apps and automations while using the data model of the core
application. You could also use these applications for incubation before
incorporating it in the core app. Regarding areas of impact (Figure 4-12),
it’s important to have strong governance around the data model and
creation of additional data stores, which can lead to data fragmentation.

Fig.
4-11 New workloads

User readiness
Security and Admin and Environment Limits and Data and
ALM and change
compliance governance strategy capacity integrations
management

Low-medium Low-medium Low-medium Medium-high Low-medium Low-medium Medium-high

This could be App- Some apps User readiness New apps Additional apps Data and
medium impact specific ALM could require effort is on existing can impact integration
based on the app; requirements additional required, but environments storage and needs for the
core Dynamics can impact your admin tasks existing users won’t have a tenant API new app can
365 apps might release and will benefit from major impact capacity have an impact
have been build pipelines a familiar UI
already approved

Implementation Guide: Success by Design: Drive app value 78

 Integrations
Integrations can play a key role in eliminating data duplication and im-
proving data quality. Most importantly, they reduce the need for users
to navigate multiple applications, which prevents context switching.
The core integrations should be part of the initial phases and not be
left to future expansion phases. Even the out-of-the-box integrations
with existing productivity applications like Microsoft 365 can positively
impact adoption and make the information seamlessly available across
apps while enabling stronger collaboration. However, an abundance of
caution is needed; integration can also lead to performance issues and
increase the overall complexity and cost of maintenance (Figure 4-13),
so using the right patterns and practices is critical.

Aggregation
Aggregation can help consolidate multiple business applications with
significant overlap of data and processes into a single application.
Aggregation is different from integration—it completely replaces the
application and brings the core feature set into an existing application
instead of exchanging or embedding information. For example, a
commercial banking sales system could become an aggregator for all
non-personal banking sales systems.
Fig.
4-12 Satellite applications

User readiness
Security and Admin and Environment Limits and Data and
ALM and change
compliance governance strategy capacity integrations
management

Low-medium Medium Medium-high Medium Medium-high Low-medium Medium

If the data flows Managing As the satellite User readiness Depending Potential impact You should
in accordance the lifecycle apps grow effort is low on the ALM to capacity; avoid
with data loss of satellite organically, the for citizen- and citizen you may also fragmenting
prevention apps requires appropriate developed development need licenses the data with
policies, impact changes to governance community strategy, the to support the additional apps
should be low existing ALM policies need to apps, but might environment makers and using their own
processes be in place to require readiness strategy is consumers if data stores,
manage them effort if they’re impacted they’re not but it may be
adopted more already covered required in
broadly by existing some cases
licenses

Implementation Guide: Success by Design: Drive app value 79

 The cutover approach for old applications is critical; make sure to avoid
parallel usage leading to fragmentation of data and other aftereffects
(Figure 4-14).

Application standardization
This model of growth is driven by creating a generic application that
isn’t targeted at a specific process but a host of similar processes. The
application could even provide a framework that enables the business
to onboard themselves. This can achieve hyper-scale, in which you can
broadly t-shirt size hundreds of processes or applications that serve
more than one business process.

Fig.
4-13 Integrations

User readiness
Security and Admin and Environment Limits and Data and
ALM and change
compliance governance strategy capacity integrations
management

Medium-high Medium-high Medium-high Low-medium Low-medium Medium-high High

Depending on ALM process Additional Depending You may need Potential Expect impact
the data flows, could be monitoring on frontend to have stubs impact to API on data
additional impacted and integration versus backend or downstream consumption movement and
security depending on telemetry integration, integration make efforts
approvals may complexity is needed the impact and environments to ensure
be needed for to support readiness effort integrations
integration reconciliation of could vary are built to
pattern failures standard

Fig.
4-14 Aggregation

User readiness
Security and Admin and Environment Limits and Data and
ALM and change
compliance governance strategy capacity integrations
management

Medium-high Medium-high Medium-high Medium-high Low Medium-high Medium-high

Level of impact Existing ALM Admin User readiness is This will have Additional users High impact
depends processes are processes are required impact on and increased with respect to
on data changed consolidated environment data volumes data alignment
classification strategy, impact capacity and integration
requiring a consolidation
potential merge

Implementation Guide: Success by Design: Drive app value 80

 A general-purpose application allows scale, but can require additional
training and user readiness, so it must be thoughtfully done to be successful.

For example, consider a generic case management system that can

accommodate hundreds of different case processes from different
internal business functions that broadly involve similar steps. The busi-
ness can create a team of resolvers, configure service-level agreements
(SLAs), provide email notification templates, and create Microsoft
Word or Excel templates to capture non-standard data, but they can
still use the generic application for core case management capabilities.
All these actions have important considerations (Figure 4-15).

Pivot
Pivots aren’t necessarily expansion, but can trigger major change to an
application, which could fundamentally change and further broaden
its scope (Figure 4-16). For example, a targeted Power App used by a
small team could go viral within an organization, and you must pivot
to make it an organization-wide application.

Conclusion
As we have seen throughout this chapter, achieving true digital trans-
formation is not a sprint, but a marathon—it’s a continuously evolving

Fig.
4-15 Application standardization

User readiness
Security and Admin and Environment Limits and Data and
ALM and change
compliance governance strategy capacity integrations
management

Medium-high Medium-high Medium-high Medium-high Low Medium-high Medium-high

Once approved Existing ALM There could be User readiness is Should have Additional users There could
for appropriate processes process specific required for each minimal impact and increased be an increase
data shouldn’t configurations new process data volumes in the data
classification, change for a required for impact capacity generated by
more processes specific template each new each process
shouldn’t have workload on the
an impact template

Implementation Guide: Success by Design: Drive app value 81

 Fig.
4-16 Pivot

User readiness
Security and Admin and Environment Limits and Data and
ALM and change
compliance governance strategy capacity integrations
management

Medium-high Medium-high Medium-high Medium-high Low Medium-high Medium-high

Application Existing ALM Admin and User readiness Potential Additional users Expect high
will need to processes will governance might be changes to and increased impact to data
undergo further potentially scope will required the overall data volumes and integration
scrutiny change need to be environment will impact based on the
reevaluated strategy capacity pivot

journey with iterations and changes that need to be effectively man-

aged. It starts with understanding the changes to your business model,
using triggers to accelerate transformation, and adopting the lean
startup mindset to build with an intention to test, learn, and change
while staying focused on driving maximum business value in the short-
est amount of time.

Going live with your MVP is the first step to driving value. You will iter-
atively refresh your transformation roadmap, revisit and refresh your
program goals, adopt new product capabilities, and drive meaningful
expansion while staying true to the core program value and transfor-
mation goals. Following this approach can establish your organization
as a leader in your industry.

The holistic value of SaaS is much broader; it goes beyond just the
technology and features of your application. You’re investing not only
in the technology but also in the research and innovation that drives
the product changes. Simplifying experiences and improving interop-
erability further reduces costs and drives business innovation.

As a final takeaway, we can’t emphasize enough the importance of

staying engaged and investing in learning. Stay on top of key product
announcements, industry trends, and research studies on technology
trends. Engage with product leaders via events, meetups, and advisory
boards. This will significantly boost your ability to achieve success.

Implementation Guide: Success by Design: Drive app value 82

 Checklist

Approach to digital Transformation roadmap

transformation Create an effective MVP scope that goes beyond the
bare minimum to accelerate value realization.
Have a clear understanding of the core business model
and how the application being developed impacts the Define your transformation roadmap and structure the
key elements of the business model. phases to maximize time to value and drive maximum
business impact.
Clearly articulate and communicate business transfor-
mation goals with specific measurable KPIs. Identify the expansion models and incorporate that into
your program phases.
Ensure the implementation team understands the
business processes in scope and the business teams are Adopt the latest capabilities to deliver continuous
closely engaged to optimize the process where needed. innovation to business.

Change stream
Account for the various change streams that will impact
the program and ensure budget and timelines are
adjusted to accommodate.

Implementation Guide: Success by Design: Drive app value 83

 Case study
Dynamics 365 helps
adapt business
processes to change
One of our clients, an accounting network, is facing unique and unex-
pected challenges. The COVID-19 pandemic has inhibited face-to-face
work, threatened global supply chains, and shifted regulatory and
political landscapes.

To maintain business continuity and stay connected with customers,

the company is adapting their digital selling techniques with the help
of Dynamics 365. With 360-degree views into each profile, sales staff
can work remotely without interrupting the customer experience.
The solution also works with the firm’s risk assessment tool to identify
vulnerable areas caused by the pandemic, allowing staff to create
proactive plans for their clients. The company is keeping their business
personal, up-to-date, and resilient by optimizing digital solutions in a
time of uncertainty.

This successful pivot clearly highlights the power of Dynamics 365 as

an adaptable SaaS cloud platform that can not only deliver strategic
solutions but also adapt to changing business needs quickly.

Implementation Guide: Success by Design: Drive app value 84

5 Guide
Implementation
strategy
Implementation Guide: Success by Design: Implementation strategy 85
 Introduction
Organizations embarking on a digital
transformation journey consider implementing
business applications as key critical milestones
for their business success.
The journey from a business vision to a successful implementation
of it requires the business and IT owners to define an overarching
strategy that acts as a framework to plan for predictable outcomes.
An implementation strategy defines these strategic choices and
decisions made in planning, implementing, and deploying Microsoft
Dynamics 365 applications.

Along with new technology comes substantial change to a company’s

business processes. It is critical to choose a process-focused, user-
Key concepts that will help in defining
a successful implementation strategy.
centric implementation strategy and methodology that not only
1 Key aspects supports digital transformation but also helps drives change manage-
2 Business drivers ment and user adoption. All of these factors are critical to making an
3 Success metrics implementation successful.
4 Methodology

5 Deployment
In this chapter, we explore common industry methodologies and look
6 Change management

7 Conclusion
at common deployment strategies and high-level views on change
management strategy.

Implementation Guide: Success by Design: Implementation strategy 86

Key aspects of
implementation strategy
The foundation of a successful implementation begins with planning
for key factors that define the overall implementation strategy. Let us
explore these key considerations.

Understand vision and business drivers

Project teams should be aware of the vision and strategic intent of the
customer stakeholders. Having a clear grasp of the key reasons behind
the implementation of a project and a collective understanding helps
the project team stay aligned with the project’s vision of addressing
significant business challenges.

It is important that senior management and project sponsors are clear

about the business requirements and help to establish the scope and
expected outcomes of the project. These goals help drive any decisions
that may be needed during the implementation cycle— for example,
prioritizing delivery of certain functional features over others.

This helps deliver a solution aligned with business needs and allows for
change management and a higher user adoption.

Identify key success metrics

After establishing a common understanding of the business challenges
and priorities, it is equally important to have an agreement on what the
key performance indicators (KPIs) that measure success look like. The
KPIs should be tangible metrics, for example opportunity conversion
rate, or average call handling time.

Understanding and identifying the KPIs is critical to ensuring the scope

being delivered is aligned with the expectations from the business
stakeholders and generates a tangible return on investment on the
Dynamics 365 investments.

87
 Some of the examples of success metrics/KPIs include:
▪ Improve the opportunity conversion rate from X % to Y % over
z period.
▪ Reduce sales cycle from x days to y days over z period.
▪ Increase net new customer adds from x to y over z period.
▪ Reduce average call handling time from x mins to y mins over
z period.
▪ Improve service request turnaround time from x days to y days
over z period.

The KPIs mentioned above are not exhaustive, customers have specific
KPIs that cater to their business scenarios. It is important to acknowl-
edge that each KPI the customer identifies and prioritizes has a direct
impact on the functionality that would be deployed on the Dynamics
365 Business Applications solution. Consequently, having a definitive
list of metrics to refer back to enables prioritization of the right use
cases and allows customer stakeholders to gauge the project success in
a tangible way.

Identify and allocate right resources

Setting up a productive team structure is critical to the success of the
project, which includes identifying the stakeholders, business process
owners, the team that delivers the projects, and the end-user representatives
who can be engaged from the beginning of the project lifecycle.

The key roles required for all projects can often be grouped into two
types of team structures.
▪ Steering committee  The group of senior stakeholders with the
authority to ensure that the project team stays in alignment with
KPIs. As they monitor the progress they can help make decisions
that have an impact on overall strategy, including budget, costs
and expected business functionality. Steering committees usually
consist of senior management members and group heads whose
business groups are part of the identified rollouts.
▪ Core implementation team  This is the team doing the actual
execution of the project. For any Dynamics 365 implementation
project, core implementation teams should include project

Implementation Guide: Success by Design: Implementation strategy 88

 manager(s), business subject matter experts, solution architects,
functional and technical consultants, developers, testers, change
management advisors, and user champions.

Process owners engagement is critical to ensure complete understanding

of business processes. Their understanding is required in case of any
process changes that may result from alignment with out of the box
features. User representation should also be planned properly to
adequately cover all the personas. Lack of availability of any of these
may result in delays and/or incomplete understanding of processes
and also impact user adoption. The involvement of process owners and
users can be staggered depending on the implementation phase. This
should be planned early on to allow business teams to make the required
changes to their schedules and be able to contribute efficiently during
the project lifecycle.

The project may require additional roles depending on the scope and
methodology. Some roles may need to join temporarily during the
project lifecycle to meet specific needs for that period.

For more details on team setup considerations, refer to Chapter 2,

“Success by Design overview,” and Chapter 8, “Project governance.”

Allocate budget and funds

Planning a budget for Dynamics 365 cloud applications typically
includes costs such as subscription, storage, implementation lifecycle
activities of designing, testing and deploying the solution, migration
from legacy applications, training, change management, and
continuous improvements.

Project lifecycles require constant assessments with careful considerations

and actions for the variance between budgets versus actual costs.

A common decision that most teams face is finding the right balance
between delivering a high value solution faster by using the off the
shelf capabilities versus extending the product capabilities to implement
the business requirements and needs. Extending the Dynamics

89
 365 applications not only requires initial development costs but also
maintainability and supportability costs in the long run. This is an area
Forrester’s Total Economic
Impact (TEI) of deploying various
where implementation teams should carefully revisit the cost impact.
Dynamics 365 apps is a good In the cloud world with rapid availability of new features and capabil-
recommendation to assess the
costs and benefits associated with ities, there is a need to rethink the investments required for extending
Dynamics 365 Implementation. the application. Refer to Chapter 15, “Extend your solution,” for more
Some of the exclusive TEI done by
details on assessing this impact.
Forrester are:

The Total Economic Impact of

Microsoft Dynamics 365 for Project management teams should give appropriate weight to areas that
Finance And Supply Chain
Management help them stay aligned with the overall project goals and objectives. It
has often been seen that as project scope and timelines change, the
The Total Economic Impact of
Microsoft Dynamics 365 Field activities that fall towards the end of the project lifecycle are usually
Service
descoped to meet budget constraints. These activities can include
The Total Economic Impact of performance testing, data validation testing, training, and change
Microsoft Dynamics 365
Customer Service management, which, when compromised, can significantly reduce the
quality and success of the implementation. It is important to revisit the
project goals and success factors that are defined during initial stages
to carefully revise the scope and timelines without compromising on
overall quality and user centric approach.

An overall approach is recommended since it helps define the total

impact by identifying the cost, benefit, flexibility, and risk factors that
affect the investment decision, helping organizations improve their
overall business goals of winning, serving, and retaining customers.

Choose a methodology
Before you discuss choosing a methodology for your Microsoft
Dynamics 365 project, we need to understand why a methodology is
important for Dynamics 365 projects.

Why methodology is important

A methodology is a prescriptive definition of activities to be undertaken
for a given project or engagement. It describes the use of a collection of
methods to achieve predictable outcomes.

Implementation Guide: Success by Design: Implementation strategy 90

 Methodology is the core of project execution that allows the team to
take the right path towards:
▪ Improved consistency and predictable outcomes.
▪ Setting clear definitions of project phases, milestones, deliverables,
and entry and exit criteria to each phase.
▪ Setting clear definitions of roles and responsibilities required for
the project.
▪ Reducing risks of missing critical activities required for a
successful outcome.

Following a methodology is akin to taking a planned journey; the

roadmap to success (as illustrated in Figure 5-1) involves the following:
▪ Plan ahead  Ensure you have clearly defined the destination
(project scope), and have all the right tools (resources, governance,
and methodology) and checklists (project monitoring) before
starting this journey.
▪ Know the road  Define the route (solution blueprint) to set clear
expectations on start and end dates at milestones so you can
meaningfully monitor progress and the team understands what is
expected from them.
▪ Avoid pitfalls  Utilize proven best practices, as advocated in the
methodology, that minimize risks, costs, and scope creep.
▪ Get there faster  Take advantage of strategies that help you save
Fig. 5-1

Plan ahead Know the road

Make sure you have all the right tools Set clear expectations around start and
and checklists for the trip. end dates and project milestones.

Start

Go live Go
live

Avoid pitfalls Get there faster No surprises

Minimize risks, costs, and scope creep Take advantage of strategies Delight executives and customers by
with proven best practices from that save time and money. delivering the right results on-time
thousands of employees. and on-budget.

Implementation Guide: Success by Design: Implementation strategy 91

 time and money. Plan, action, and regularly monitor and adjust to
ensure you are taking the most efficient route to your destination.
▪ No surprise  Delight users by delivering a user centric solution
and business stakeholders by delivering results on-time and
within budget.

Choose an implementation methodology

Let us take a look at the specific methodologies that can be used for a
Iteration and sprint is a timeframe successful Microsoft Dynamics 365 implementation.
in which teams deliver incremental
value in the form of working tested
software. Iterative approaches use We often see three types of models used to implement Dynamics 365
the term iterations while Scrum
Business Applications projects.
approaches use the term sprints.
▪ Waterfall model  A delivery execution model based on sequential,
steadily flowing, like a Waterfall, series of phases from conception,
initiation, analysis, design, development, testing, deployment,
operations, to maintenance.
▪ Agile model  Agile development is not a methodology in itself,
but an umbrella term that describes several Agile methodologies.
Some of the industry known methodologies are Scrum, XP, DSDM,
Sure Step for Agile (for Business Applications).
▫ Scrum methodology  A delivery execution methodology
based on Agile principles where requirements are in flux or
unknown prior to beginning a sprint. Sprints involve
requirements analysis, design, build, test, and user review.
Sprints are a fixed duration (usually 30 days), as illustrated
in Figure 5-2.
▪ Hybrid model  A delivery execution model based on Agile prin-
ciples where requirements within the context of business processes
are defined, analyzed, and prioritized and an overview design
solution blueprint is generated prior to beginning the sprints.
Sprints involve refining designs, build, test, and user reviews.
Sprints can be of varying durations.
Fig. 5-2

Product backlog Sprint backlog Sprint Working increment

of the software
24h
30 days

Implementation Guide: Success by Design: Implementation strategy 92

 Now let’s take a deeper look at each of these methodologies.

Agile
Success by Design Framework is
An Agile implementation is an iterative approach that uses a number
methodology agnostic and is aligned
to ensure proactive guidance and of iterations or sprints.
predictable outcomes irrespective
of chosen methodology. For more
information, refer to Chapter 2, In Microsoft Dynamics 365 Business Applications projects, the majority
“Success by Design overview.”
of requirements are delivered by the packaged software. There are
specific challenges and tasks that are out of the box and need to be
managed and mitigated as part of the project methodology with the
user stories contained in the form of a backlog. Using those stories, you
carve out plans and within them a number of iterations or sprints of
development and testing are executed. Within each sprint, you have a
number of user stories outlining the requirements.

Agile promotes a collaborative process between the resources that

own and specify the requirements for the solution and the resources
responsible for the development and rollout of the solution.

The idea is to release software faster, take early and regular feedback,
adapt, and release again. This cycle continues until all the requirements
are met or the backlog is cleared.

An example of Agile practices using the methodology prescribed by

“Sure Step for Agile” is shown in Figure 5-3.

Waterfall
The Waterfall approach to solution delivery is a sequential process
that depicts a linear flow of activities from one phase to another,
culminating with the solution being promoted to production and
then into operation.

This is a traditional methodology of implementing on premises business

applications. It is a linear, noniterative approach of implementing and
delivering projects.

Implementation Guide: Success by Design: Implementation strategy 93

 Fig. 5-3
1.1.1 4.1.1 5.1.1

management
Project management Project Project
Analysis

Program
management management
1.2.1 1.2.2
Conduct Gather user
solutions training
overview requirements
1.3.1 1.4.1 Design
Conduct detailed Gather
Agile preparation

4.2.2
business process business

Training
Conduct end
analysis requirements
user training
1.7.1
Set up DEV Development
and other
non-production 1.4.2
environments

process analysis
Conduct fit gap
analysis

Business
1.8.1
Establish Deployment
integration
strategy

1.9.1
1.4.3
Gather data
Define

Requirements and
migration Operation

configuration
solution backlog
requirements
5.4.2
4.4.2
Transition to
Go live
support

30-day sprint cycle

2.1.1
Define sprint

Custom
coding
backlog

2.1.4 2.1.2
Conduct sprint Conduct sprint
post mortem planning meeting

and testing
4.6.2

Quality
Daily sprint cycle Conduct UAT

3.1.1 3.1.2
Agile execution

Conduct daily Analysis and

sprint cycle design for
meeting sprint cycle

Infrastructure
3.1.3
3.1.6 4.7.1
Create scripts
Conduct Build production
for testing
sprint testing environment

3.1.4
3.1.5
Sprint
Generate
configuration
daily build
and development
and interfaces
Integration

2.1.3
Conduct sprint
technical preview

4.9.3
3.6.1 3.7.1
migration

Final data
Conduct Finalize
Data

migration to
solution production
production
testing specification

Implementation Guide: Success by Design: Implementation strategy 94

The phases, milestones, and deliverables are clearly defined, and you
only move to the next phase when a prior phase is completed.

In the modern cloud world, early stakeholder buy in is critical which

requires delivering quicker results, which makes waterfall technique
not so suitable.

An example of the Waterfall model as prescribed in Sure Step

Methodology is depicted in Figure 5-4.

Hybrid
In the current landscape of rapidly changing business needs and
changing technology trends, projects commonly adopt a hybrid
approach. This is a combination of Waterfall and Agile practices that
implementation teams use to meet their project needs. It allows teams
to tailor an approach that enables a successful implementation of
Dynamics 365 applications. It is also our recommended approach for
Dynamics 365 engagements.

Figure 5-5 shows an example of a hybrid approach, based on

Dynamics Sure Step 365.

With this approach, we can manage initial activities, like initiation and
solution modeling, and final activities like system integration testing,
user acceptance testing, and release to production, in a noniterative
way. Then the build activities, such as requirement detailing, design,
development, testing, are completed with an iterative approach.
This helps provide early visibility into the solution and allows the team
to take corrective actions early on in the overall cycle. This approach is
considered to use the best of both Waterfall and Agile approaches and
is a win-win for any size of implementation.

In the hybrid approach, the focus is on a regular cadence of iterative

and incremental releases of software features.

We stress for customer stakeholders to participate in the process, espe-

cially in the business validation reviews that happen after each sprint

95
 Fig.5-4

Analysis Design Develop Stabilization Deploy

Organization

Training plan

Deployment plan User training

Baseline
project plan

Functional design Go live

Process and
functional UAT scripts UAT
Solution

Transition to
requirements
Technical design support
Solution testing
Fit gap analysis
Solution design

Data migration
Technology

requirements
Integration and Production Production
interface design specifics environment
Environment
specification

Fig. 5-5

Noniterative Noniterative Iterative Noniterative Noniterative

Solution Solution Support

Mobilization Initiation Build Deployment Operation
modeling testing transition

Analysis Process
Design End-to-end
Development Performance
Iteration testing UAT

Once per
Once per project Once per release iteration Multiple cycles per release Once per release
in a release

Implementation Guide: Success by Design: Implementation strategy 96

 cycle. These reviews are placed at regular intervals during the project
schedule, and allow for faster valuation and better stakeholder buy in.

Through these reviews, customer stakeholders get an opportunity to

see working software, have discussions with the team, and provide
early feedback. The readiness of business processes is validated for
production use by an invited business audience by showing the
incrementally improving readiness across all the components in the
system as working software, like design, data configuration, data
migration etc.

The idea is to get early feedback and validation from the business team
on the business requirements scope and understanding. This approach
allows the project to showcase working solutions faster than other
methodologies and achieves a higher rate of implementation success.

Define deployment
strategy
A deployment and rollout strategy describes how the company is
going to deploy the application to their end users. The strategy chosen
is based on business objectives, risk propensity, budget, resources,
and time availability, and its complexity varies depending on each
implementation’s unique scenarios. There are several key factors to
consider prior to choosing any of the approaches detailed below.

▪ What is the MVP (minimum viable product) needed for faster val-
ue to customers and then later plan for continued enhancements?
Refer to Chapter 4, “Drive app value,” to define an MVP strategy.
▪ Is this a multi-country rollout or single-country rollout?
▪ Is there a need to consider pilot rollouts prior to wider
team rollouts?
▪ What are the localization requirements, especially in scenarios of
multi-org or multi-region rollouts?
▪ Do we need to phase out a legacy application by a certain key
timeline or can it be run in parallel?

Implementation Guide: Success by Design: Implementation strategy 97

 ▪ What is the extent of impact on end users’ day-to-day
productivity?
▪ What training needs do end users have?
▪ What is the complexity of integrations during the rollout?

Taking these factors into consideration, you should define a rollout

strategy that helps the organization deploy the application in the most
effective manner.

The following are some typical deployment strategy models.

Big-bang
In the big-bang approach, as the name suggests, the final finished
software solution is deployed to production and all users stop using
the old system and start using the new system on the go-live date.
The term “big-bang” generally describes the approach of taking a
large scope of work live for the entire user base of your
organization simultaneously.

The selling point of the big-bang approach is that it concentrates the

focus for a shorter rollout period compared to a phased rollout. You
trade the cost and disruption of staying in rollout mode for a longer
period of time for a longer wait to get value from the solution.

An example of big-bang rollout is when an organization that was using

a legacy business application for all of its corporate office finance team,
communicates to all end users to stop using the old system and start
using the new Dynamics 365 Finance on the go-live date.

The whole implementation can be very large and can encompass

multiple countries, departments, or business units. During transition,
the new solution is deployed through a number of activities while the
old system is turned off so the new system can go live.

The risks of this approach are that the entire project could be rushed,
minor but important details could be ignored, and business processes
transformed may not be in the wider interest of the organization. In

98
 an aggressive big-bang rollout, the risks are magnified due to the dual
combo of a large scope and shortened rollout period.

Change management can also suffer as people are less inclined to

use the system that may not be solving the business problems it was
meant to solve.

With such large changes happening, there is a potential for issues to

arise post go-live and falling back on the older system is very hard,
if even possible. It is critical to ensure proper contingency planning
for business continuity, and support mechanisms to deal with post
go-live issues.

Fig. 5-6
Large project scopes are at much greater risk by using the big-bang
approach since the delivery of
Pros Cons finished software to the produc-
▪ Shorter, condensed ▪ May not accommodate for rapidly
tion takes up a longer timeline,
deployment times, minimizing changing market scenarios and
there is more to organize during
organization disruption product capabilities, leaving a
lack of solution alignment at transition. If the final rollout runs
▪ Lower costs from a quick rollout
without loss of overall work, but deployment causing a negative into challenges, the wider user
with an added need to account impact for end users community is impacted due to
for resource costs to manage the ▪ Daily task delays from users the resulting delays. If Waterfall
complexity learning to adapt to the new methodology is used as the
application without any prior
▪ Same go-live date for all users implementation, then the end
experience
▪ Reduced investment in users don’t have a feel for the real
temporary interfaces ▪ Transitioning back to legacy
system when it is finally rolled out.
systems can be costly and
difficult, if even possible
However, if hybrid methodology
is used, it is possible to involve end
▪ Any failures during the rollout have
a high impact on maximum users users from the beginning, keeping

▪ Heightened probability of risks

them updated on what is land-
emerging from introducing large ing on go-live and keeping any
changes for large groups of users surprises in check.
▪ Heightened probability of issues
coming up in go-live For large and complex imple-
▪ No opportunity to learn from mentations, big-bang projects
early launches to change things can require many months or even
▪ Costs of ramping up a large rollout years to complete. Given the pace
team for a short period of time of change in most industries it may

Implementation Guide: Success by Design: Implementation strategy 99

 not be feasible to wait that long for implementation, especially since the
business that was analyzed for requirements could have different needs
and priorities a year later, as illustrated in Figure 5-6.

Phased rollout
In a phased rollout approach, we are releasing the software in a
number of phases or releases. The phases can be planned in several
ways and can be based on modules, business priority, business units,
or geographies. One approach for a phased rollout can be to release
an initial set of capabilities in the first phase and build on that by
releasing the rest of the requirements in subsequent phases. At the
release of the first phase for a business unit or module, it is expected
that the specific business unit’s end users stop using the legacy system
Fig. 5-7

Pros Cons
▪ Higher business value features can be prioritized. The ▪ Longer implementation and deployment timeline due
implementation team may also choose to prioritize lower to multiple go live events.
complexity features to adapt to the new functionality. ▪ Complexity of data migration from legacy application
▪ Unlike big-bang, phased rollout releases can bring to the target application increases as it needs to be
new use cases gradually, allowing for more buy in planned in a staggered approach.
from end users as they get used to the new system. ▪ Organization needs to plan for continuous disruption
▪ Project teams can optimize later phases by incorporating over longer periods of time, like parallel efforts of
the learnings from earlier ones. supporting deployments while working on future

▪ Risk of disrupting business is less as errors found in phase implementation.

the initial phase are limited to specific business areas ▪ Employee morale may suffer as they face change fatigue.
and users and rest of the business is not affected. Phased projects need lots of focus and coordination as

▪ When phases are based on functionality, rather than the team might start losing momentum after first few

module, geography, or business unit, it typically phases. These projects don’t have the benefit of focused

results in a faster time to value. intensity as the big-bang approach does. It is important
that the change management team keeps a tab on
▪ For large implementations, it reduces the level of
employee morale and plans initiatives to keep their
investments and resources needed for ramp up for
interest alive.
each deployment relative to a big-bang approach.
▪ Need to implement temporary scaffolding solutions to
manage integrations between new and legacy systems
until the new solution is fully rolled out.

▪ Scope creep can occur since project timelines are

drawn out. There can be a tendency to incorporate
changes and rework, which can affect the work for
subsequent phases and their timelines.

Implementation Guide: Success by Design: Implementation strategy 100

 and move to the new one. There could still be temporary scaffolding
integrations setup to integrate the new system with the legacy systems
until all phases are rolled out.

For example, a team can start the implementation with one business
unit. Once implementation is complete, they travel to the next business
unit. As the team gains experience and learns from past mistakes, the
subsequent rollouts become smoother. This leads to less risk and more
employee adoption, as illustrated in Figure 5-7.

Parallel rollout
In a variant of phased rollout approach, parallel rollout, the legacy
system is not discarded but kept alive along with the new system. More
than a rollout approach, it is a validation technique allowing users an
opportunity to learn, test, and get comfortable with the new system.
Typically, for few months both systems are actively used and users are
required to key in information in both systems.

▪ There is much more effort required from the users as they double
key information.
▪ This rollout may be preferred by projects where the business risk is
very high and cannot be easily mitigated by testing. At the same
time, we need to be mindful of making sure team is not cutting
corners on testing and training efforts.
▪ This rollout is less and less popular due to the extra efforts and
costs involved in keeping two systems.

Rollout strategy goes hand in hand with change management strategy

as several activities of change management play a key input to
successful rollout, as illustrated in Figure 5-8.

Fig. 5-8

Pros Cons
▪ Less risk ▪ High efforts and high costs

▪ Users take their gradually plan to migrate to the ▪ Needs for data duplication can get complicated. We
new system recommend having a clear exit plan that is time or
workload based, for example, all existing cases closed
in old system

▪ May mask poor training and testing efforts

Implementation Guide: Success by Design: Implementation strategy 101

 Define a change
management strategy
Adoption and change management planning is a critical aspect of
implementation strategy. Change is never easy for any organization and
requires thoughtful planning and a structured approach to achieve high
adoption and usage. A change management strategy with a clear action
plan ensures smooth rollouts and alignment with stakeholder and end
user expectations. In the absence of a planned change management
approach, many business applications tend to become purely a reporting
tool rather than a value driven user centric application.

Bridge the gap between business

requirements and results
All too often, projects meet requirements without a true focus on adoption
and business outcomes. The gap that exists between technology solutions
and business outcomes directly relates to the users who experience a
change in their day to day work. Change management focuses on bridging
this gap by effectively supporting and equipping the user community
to successfully adopt the transition. A change management mindset is
required across different functions, including the project development
teams, to keep the end user experience as a primary design consideration.

Increase likelihood of project success

PROSCI’s correlation data from over 2,000 data points and 10 years
shows that initiatives with planned change management are six times
more likely to meet objectives than those without a formal change
management strategy. The data is abundantly clear. The better we
apply change management, the more likely we are to deliver on
project objectives.

Take the change out of change

Change is difficult. To the degree that we can, we want to remove the
chance or variability associated with change. Project management has

Implementation Guide: Success by Design: Implementation strategy 102

Change is never accomplished this by providing direction on sequencing milestones,
deliverables, activities, and resources over the lifecycle of an effort.
easy for any Unless we proactively support and guide people through the changes
organization and our projects bring, we leave the likelihood of them embracing change
requires thoughtful to chance. Change management addresses this by providing

planning and a employees with the preparation, support, and skills they need to
succeed in change.
structured approach
to achieve high PROSCI’s framework that is followed at Microsoft describes the three
adoption and usage. sequential steps that are followed in change planning.

Preparing for change  The first phase in PROSCI’s methodology

helps change management and project teams prepare for designing
their change management plans. It answers these questions:
▪ How much change management does this project need?
▪ Who is impacted by this initiative and in what ways?
▪ Who are the sponsors we need to be involved to make this initia-
tive successful?

Managing change  The second phase focuses on creating plans that

integrates with the project plan. These change management plans
articulate the steps that you can take to support the users being
impacted by the project.

▪ Communication plan  Communications are a critical part of the

change process. This plan articulates key messages that need to go
to various impacted audience. It also accounts for who sends the
messages and when, ensuring employees are hearing messages
about the change from the people who have credibility with them
at the right time. Communication is an understated yet very signif-
icant aspect that keeps the various teams connected throughout
the entire journey. Some of the key communication aspects to
consider are:
▫ Providing a sneak peek into what is in it for end users
▫ Launch and availability communications
▫ Project sponsor vision and direction communication
▫ Communication frequency and approach
▫ End user feedback incorporation

103
 ▫ Status reporting, including steering committee reports
▪ Sponsor roadmap  The sponsor roadmap outlines the actions
needed from the project’s primary sponsor and the coalition of
sponsors across the business. In order to help executives be active
and visible sponsors of the change it identifies specific areas that
require active and visible engagement from the various leadership
teams, what communications they should send, and which peers
across the coalition they need to align with to support the change.
▪ Training plan  Training is a required part of most changes and is
critical to help people build the knowledge and ability they need
to work in a new way. The training plan identifies the scope, the
intended audience, and the timeframe for when training should
be planned for. It is important that the training plan be sequenced
in a way that allows for awareness and desire building before they
are sent to training. A common aspect that tends to be overlooked
is cloud focused training for IT administrators. As organizations
implement Dynamics 365 cloud applications, it also may mean a
significant change for IT teams, so it is important to plan training
that keeps their persona in perspective. They may require training
not only on Dynamics 365 administrative activities, but also for a
general understanding of cloud concepts.
▪ Coaching plan  The coaching plan outlines how you engage with
and equip managers and people leaders to lead the change with
their own teams. Managers can play a significant role in aiding
the change management efforts, but they need to be engaged as
employees themselves first and allowed to work through their own
change process. Once that’s done, you can give them the information
and tools to lead the same change process with their own teams.
▪ Resistance management plan  Resistance to change is expected,
so proactively defining the activities to mitigate the areas of concerns
should be initiated early on in the project lifecycle. Engaging user
champions from the end user community early on to build a user
centric solution contributes significantly towards addressing this risk.

Reinforcing change  Equally critical but often overlooked, this third

phase helps you create specific action plans for ensuring that the
change is sustained. In this phase, project and change management
teams develop measures and mechanisms to measure how well the

Implementation Guide: Success by Design: Implementation strategy 104

 change is taking hold, gauge user adoption, identify alignment with
KPIs, and correct gaps.

A successful change management strategy requires continuous

executive sponsorship, integration with the project management teams,
employee engagement, and frequent and open communication.

Conclusion
When a team defines an implementation strategy, they set clear
expectations and guidelines for the team and wider business on how
the project goals are going to be attained. This helps define a clear
translation of business goals into a structured implementation plan.

To summarize, a well-rounded implementation strategy takes the

following into consideration.
▪ Build a common understanding of vision.
▪ Identify the methodology based on the specific factors that are
driving the implementation.
▪ Follow the tried and tested approach that is defined by the meth-
odology—do not leave activities out just for convenience.
▪ Help to take feedback early in the implementation journey by
doing a show and tell after each sprint/phase depending on the
chosen methodology.
▪ Keep organizational culture under consideration while choosing a
methodology. Organizations that have followed a traditional ap-
proach such as Waterfall may need additional change management
planning to embark on a modern approach such as Agile or hybrid.
▪ Consider which industry practices may also have a bearing on
methodology. Some industries may have their own tailored ap-
proach and that needs to be kept into consideration.
▪ Formulate a focused approach towards user adoption by creating
a change management plan.
▪ Plan an approach of communicating to various stakeholders,
including leadership and end users.
▪ Continue to improve throughout the process—solicit end-user
sentiment and act!

Implementation Guide: Success by Design: Implementation strategy 105

Section
Initiate
6 Solution architecture design pillars
7 Process-focused solution
8 Project governance
9 Environment strategy

106
6 Guide
Solution
architecture
design pillars
You must be sure about the
solution before you start building,
because failure is not an option.

Introduction
You can’t have a solution without first having a vision.
When you know the answer you’re looking for, only
then you can find a solution to get you there.
But it’s not always easy to know and articulate what you want, let
alone identify the elements that are essential for creating a blueprint
of your solution.

This chapter outlines the pillars of a successful solution architecture

design that support your vision, and provides you with the building blocks
you can use to create a coherent and satisfying outcome. By utilizing
the Success by Design framework, we present a structured approach for
designing a solution that’s enabled by Dynamics 365 apps.

Solution architecture
design pillars
Most of us know what “architecture” means in the building industry—
it includes the job of the architect, the scope of the work, and what’s
ultimately delivered. The architect starts with the project requirements

Implementation Guide: Success by Design: Solution architecture design pillars 108

 and the budget, and then works on a blueprint of the design. Once the
physical labor begins, the foundation is laid, the house is built, and the
interior is completed. Many years of maintaining and improving the
building may follow. But why and when do you need an architect to
design a solution for your organization?

Let’s take the simple case of building a new house for a dog. In most
cases, this is a single-person job with a general vision of the final
product. Building a doghouse is cheap, and the risk of failure is low,
so a trial-and-error approach is one option.

But what if you were asked to build something as complex as the Sydney
Opera House in Australia? The approach would be completely different:
the job can’t be completed by a single person, the design needs to
be carefully planned, and architects, construction workers, plumbers,
electricians, and decorators have to coordinate their workflow. With so
many moving parts, there must be well-defined processes, an explicit
design, and powerful tools. When all the right pillars are in place, the
likelihood of failure is dramatically reduced.
Fig.
6-1

Solution architecture follows a systematic approach by identifying the

It all begins desired solution and the necessary building blocks, where each builds
with a vision. on the previous block and provides a foundation for the next block.
Solution architecture breaks up the work into logical sections, and
Processes
coordinates those sections, managing and mitigating the risks along
The vision leads to the
business strategy, where
the way.
the processes, people,
and data are joined.

People Data Building blocks of

The solution strategy solution architecture design
outlines how those
elements can be You start with a vision, which leads to a business strategy where the
addressed by using
processes, people, and data are joined (Figure 6-1). A solution strategy
the technology of
Dynamics 365 apps. outlines how those elements can be addressed by using the technology
of Dynamics 365 apps. Project and change methodologies, supported by
governance and control methods, define the workflows and the delivery.
The project and
change methodology
Solution architecture design incorporates the business vision and its
define the workflow
and delivery. implementation into a blueprint. The first version is created as part of

Implementation Guide: Success by Design: Solution architecture design pillars 109

 the pre-sales process and forms the initial high-level understanding of
what you plan to build.

Solution architecture enables implementation of a vision, and typically

begins after the business strategy has been crafted, but before the
solution is built and implemented (Figure 6-2). Architecture creates a
picture of the finished product and includes the specifications needed
to build it.

A solution architect provides the necessary quality control by ensuring

that key requirements are met, with all relevant interdependencies
considered and managed. A solution architect also serves as a translator
between the business and IT teams to articulate the impact of
technology on the business, and vice versa.

Vision
A vision is the desire to achieve something—to change the present and
improve the future.

When an organization decides to go through a transformation, it’s

usually because one or more people had the ability to predict what was
coming and expressed a desire for change, or a change was forced by
industry disruption or regulations. Such a change could be in the form
of a mission statement or a business case listing its objectives, which
Fig.
might include:
6-2

Implementation Guide: Success by Design: Solution architecture design pillars 110

 ▪ Finding unified and faster ways of working.
▪ Earning higher profits.
▪ Achieving better service or product quality.
▪ Improving the user experience.
▪ Empowering users to drive greater value by building apps.

As the vision comes together, the plan for achieving it can start
taking shape.

Business strategy
Every vision serves a purpose, as does every organization, and any
solution needs to be aligned with this purpose. A business strategy
supports your vision by answering fundamental questions, such as:
▪ Why are you making this change, and what are the anticipated
benefits? What is the business value sought by the solution? Where
do you imagine the organization will be in five, 10, or 20 years?
▪ What business capabilities can your organization offer with
the new solution? What business processes can you run? What
information and data would you like to record and report on, in
line with your organization’s services or products?
▪ Which clients, customers, or people inside the organization will be
served by the new solution, and who will be affected by it?
▪ Would you like to improve your current line of business or are you
open to a new industry?
▪ When do you plan to have the vision materialized? What is the
high-level timeline? And do you intend to deliver the solution at
once or grow in stages?
▪ Where are the regions—geographically and in terms of business
functions—to which the solution will apply? Will you apply it to
all or just some of them?
▪ Who is going to plan, design, and deliver the solution? Do you
have a preferred partner or do you need to select a vendor?
▪ How will you incorporate technology into your solution? (This
is the first step of solution design and the link to your solution
strategy, as well as the business case for IT transformation.)

Implementation Guide: Success by Design: Solution architecture design pillars 111

 Why should you
define your processes?
Processes
It creates consistency by Process architecture is a commonly understood, shared view of all
allowing for consolidation and business processes that an organization uses to deliver a product or
unification of processes across
service. It represents how an organization operates, in a structured
locations, teams, and systems.
order. Complete, accurate, and well-organized process architecture
It reduces complexity by is the first and most important pillar for a sound solution design. It
standardizing and rationalizing confirms end-to-end business understanding, provides a structure
previously complicated and
cumbersome procedures. for understanding the scope, and serves as the basis for testing
and training. It also forms a map for requirements gathering. The
It eliminates guesswork and processes are constructed at different levels to reflect specific areas,
potential ambiguity by
functions, locations, and teams. Process architecture is often referred
streamlining operations and
improving communications. to as a target operating model, a process library, or a catalog.

It promotes productivity by
Any transformation starts with defining your processes, which is also a
eliminating inefficiencies and
establishing one workflow for good time to revisit and improve them.
all users.

It guarantees quality by Dependent activities

maximizing attention to detail
and ensuring work is done in While we’re not going to take a deep dive into the business process
a pre-defined, optimized way management life cycle and capability maturity, following the Success
each time.
by Design framework can help you identify important elements of your
It boosts morale by helping solution design.
team members take pride in
mastering the process, refining
their skills, and avoiding mistakes Process architecture includes multiple dependent activities:
and missed deadlines. ▪ Scope management  Defining the scope of the solution is the first
step of the design. Ideally, you have a baseline process taxonomy with
It encourages continuous
improvement by giving team
at least three levels of the process architecture. Start by mapping
members who follow the requirements against it and marking which processes are in
processes a chance to give input scope. You can add to and take away processes from your initial
on how to improve them.
process library.
It increases user acceptance ▪ Business analysis  Initially, it’s likely that business users don’t
by providing a higher-quality know or understand the application, and the tech partner doesn’t
experience at each launch.
understand the business, so a business analysis helps to join them
together. A business analyst gathers requirements and links them
to processes; conversely, a good processes structure drives the
requirements gathering by asking all necessary questions.

Implementation Guide: Success by Design: Solution architecture design pillars 112

 Key deliverables related to processes
Process architecture map  Linear and cross-functional process flows
These show the input, output, and activities at process and
sub-process levels to help you figure out how a process must
change to meet requirements; you can also add details such as
assumptions, metrics, timelines, and costs.

Linear flow

This is a visual representation Product Product Product Product

of your business processes. ideation design development testing

Product
prototyping

Process catalog/ Product ideation phase

inventory and taxonomy Collect customer

suggestions

Test against
Conduct Put ideas into ideation Select ideas for
strategic
competitive analysis pipeline conceptual design
imperatives

Conduct ongoing
research

This is a sequenced list

of the processes, usually Process flows
Route Load Outbound
uploaded to Microsoft planning building logistics

Dynamics Lifecycle Services

(LCS) and synchronized with
Azure DevOps.

Inbound Wave
Receiving Put away Count Pick Pack
logistics processing

Planning

Implementation Guide: Success by Design: Solution architecture design pillars 113

 ▪ Requirements management  Every functional and nonfunctional
requirement needs to be linked to at least one process. If an
applicable process doesn’t exist, you must slot it into the relevant
section of the process architecture. DevOps is a good tool to use
for this success measure, as shown in Figure 6-3.
Fig.
6-3

Requirements
traceability matrix (RTM) Fit gap assessment

This links requirements throughout This is where you mark which

the validation process, and requirement and respective
is a key deliverable for process can be addressed by
requirements management. the system, and which ones
require customization.

Fig.
▪ Solution design  Once you have a better end-to-end business
6-4
understanding, it’s time to translate it into your system processes.
People With the Dynamics 365 solution design, a Microsoft partner works
with the process leads to develop the solution, and it can be helpful
Solution to create process flows that show how the processes can be run in
design the system.
s

ta ▫ As part of the process, data goes in as input exchanged

Da

se
es

oc
Pr between people and applications, and data goes out as output
in the form of documents, analysis, and reports (Figure 6-4).
▪ Test management  Once the solution is designed and developed,
the process architecture, along with the RTM, establishes a baseline
for testing. When you test every process, you ensure that every
requirement is addressed and the solution is appropriate. For more
information, refer to Chapter 14, “Testing strategy.”
▪ Training  Process architecture also defines and drives your
training content. You can use your process flows and guides as
a first draft for your training materials. Learn more in Chapter
7, “Process-focused solution,” and Chapter 2, “Success by
Design overview.”

Implementation Guide: Success by Design: Solution architecture design pillars 114

 Key deliverables
related to people People
Organizational structure
Even though not every process or activity is performed by a person,
Cross-functional there’s always a step or output that involves people, whether internal
process flows and maps
(employees and contractors) or external (customers and vendors). This
List of business users is the key reason why and how the solution design is influenced by the
or personas
people pillar. People shape the solution design in many ways, including:
Dynamics 365 ▪ Geographical location
security roles list ▪ Time zones
Mapping between personas ▪ Languages
and security roles ▪ Customs
▪ Internal and external hierarchies
▪ Organizational structure

This pillar of solution design is usually represented by the organizational

architecture, which visually intersects with process architecture in process
maps, and includes:
▪ Geographical structure
▪ Organizational groupings
▪ Line of business
▪ Reporting lines
▪ Segregation of duties

Data
The third pillar of solution design is data.

A system with inaccurate, misleading, or partial data will lead to a failed

implementation, so you must understand your data and how it fits into
the overall solution. With the right data, you can identify actionable and
analytical information that improves business intelligence. Think about:
▪ Master data  This is static information, such as details about
customers and products, that you use and exchange in your
Refer to Chapter 10, “Data management,”
to gain a broader understanding of the business activities.
various data functions you’ll need before
starting a project.
▪ Documents  This refers to documentation, such as sales orders and
customer invoices, that you create as part of your business process.

Implementation Guide: Success by Design: Solution architecture design pillars 115

 Key deliverables ▪ Reports  This is organized or filtered information, such as a trial
related to data balance or aged debt, serving as input or output for your business
activities.
Data governance strategy
▪ Transactions  This refers to recorded business information, such
Data architecture as customer payments and expense reports, that you create, store,
and report as part of your business process.
Data migration and
integration strategy
At a minimum, you must start with an understanding of how your data
Data quality strategy is currently utilized and how it supports your future vision. Planning
your data strategy upfront also allows for better scalability.

The world is evolving from silos of data to connected enterprise data

that enables the digital feedback loop. That is why a data strategy that
applies AI and analytics to make the data actionable is so critical to the
overall success of your design.

Solution strategy
Your solution strategy is a consolidated view and approach that defines
your overall solution. A solution blueprint is a living document with sev-
eral review points (Figure 6-5) during a project’s lifespan to help you
identify and take necessary actions, mitigate risks, and resolve issues as
they arise. In the Success by Design framework, the blueprint is consid-
ered essential for a project’s success, and provides a view of the overall
solution architecture and dependent technologies.
Fig.
6-5

Kickoff Go live
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52

Requirements

Design/build iteration

Stabilization

Go live prep

Solution SBR 2 SBR 3 SBR 4

Blueprint
Review ALM workshop Performance workshop Go live review
(SBR) 1 Environment workshop Test workshop Cutover plan workshop
Scheduling workshop Gap workshop
Customer kickoff BI workshop
Partner kickoff Integration workshop
Data migration workshop

Implementation Guide: Success by Design: Solution architecture design pillars 116

 The Solution Blueprint Review workshop is a mandatory part of the
solution design experience, and helps you keep track of your solution
design’s progress to ensure that your vision and objectives are still viable.
For more information and a list of activities
in each Success by Design phase, refer to It also allows solution architects and the implementation team to review
Chapter 2, “Success by Design overview.”
and gain an understanding of your:
▪ Program strategy
▪ Test strategy
▪ Business process strategy
▪ Application strategy
▪ Data strategy
▪ Integration strategy
▪ Intelligence strategy
▪ Security strategy
▪ Application lifecycle management (ALM) strategy
▪ Environment and capacity strategy

Capturing these details helps you understand the project, and validates
your solution design via the complete and well-organized processes, data,
and people enabled by Dynamics 365.

Technology
While technology does not drive all the processes, it provides the
backbone of products and services required to fulfill your businesses
strategy. Your processes dictate which technology to use and when, and
that technology will bring your digital transformation to life. For exam-
ple, the Dynamics 365 Sales app provides value-added details about
your organization’s lead-to-opportunity pipeline. Other examples of
technology that’s under the hood to support users include:
▪ Infrastructure as a service (IaaS)
▪ Software as a service (SaaS)
▪ Integration tools
▪ Business intelligence tools
▪ Azure AI
▪ Azure Machine Learning
▪ Data connectors
▪ Customer portals
▪ Mobility solutions

Implementation Guide: Success by Design: Solution architecture design pillars 117

 The technology and system selection are usually performed during the
sales process as part of the first high-level fit gap assessment.
For more on this topic, refer to Chapter 15,
“Extend your solution.”
Finding the right balance
For more information about the Success
by Design framework, refer to Chapter 2, It is easy to say that technology can be used to solve any business process
“Success by Design overview.” scenario, but technology is simply what turns the gears for your processes,
people, and data. It’s important to include all stakeholders in the design
decisions, because processes don’t always align with the technology. This
is what we call the “gap” in a requirement, and it’s where you might decide
to configure or customize an out-of-the-box solution to meet the needs of
the process. Think through the different options to find the right balance for
your solution, but be sure to challenge the business requirements before
customizing the system. You might be surprised to find out that what
seemed like a “must-have” customization is more of a “nice-to-have” feature.

Methodologies
A methodology is a collection of methods used to achieve predictable
outcomes. Good methodology also demonstrates why things need
to be done in a particular order and fashion. The Success by Design
framework is a higher-level abstraction through which a range of
concepts, models, techniques, and methodologies can be clarified.
It can bend around any methodology, including The Open Group
Architecture Framework (TOGAF), the Microsoft Solutions Framework
(MSF), and the Zachman Framework.

To achieve your solution, the workflows and delivery need to be

planned, organized, communicated by various methods, including:
▪ Project management
▪ Change management
▪ Governance and control

For more detailed information about Project management

project management approaches, review
Chapter 5, “Implementation strategy.” There are multiple project management methodologies and approaches,
and methodology for enterprise resource planning (ERP) is a topic that

Implementation Guide: Success by Design: Solution architecture design pillars 118

 can generate more heat than light. Partners often rely on their own
branded methodology to reassure customers about their governance.
Project management approaches can be grouped into three
core categories:
▪ Waterfall
▪ Agile
▪ Hybrid

As we move increasingly toward a low-code world, there are faster

deployments and fewer customizations, and your approach should
match the changing world and your customers’ expectations.

Change management
Project management (the “how”) and change management (the
“who”) are both tools that support your project’s benefits realization.
Without a change management plan in place, your organization’s
objectives are at risk. To drive adoption with your end users and
accelerate value realization, apply a vigorous change management
approach, which is most effective when launched at the beginning of
a project and integrated into your project activities.

The benefits of change management:

▪ It focuses on the people side of organizational change.
▪ It seeks individual and organizational perspectives.
▪ It requires action and involvement by leaders and managers
throughout the organization.

Governance and control

“When you have
The term “governance” often brings to mind just project management
bad governance, or possibly even stakeholder management, but such a limited view of
resources are governance may cause an organization to ignore core elements
destroyed.” required for success (Figure 6-6).

– Wangarĩ Muta Maathai, Every project component contains an element of uncertainty and
Nobel Peace Prize winner is based upon assumptions made before details are known or fully
understood. So, if we know this, why would we expect a project

119
 manager to be solely responsible for project governance? The
project manager is of course accountable for the project outcome,
Read more in Chapter 5, but 360-degree governance requires everyone—especially the
“Implementation strategy,” and
architects and leads—to play a role.
Chapter 8, “Project governance.”

A 360-degree governance method directly affects how well the

project team performs and the ultimate result, and is executed on
multiple levels:
▪ A governance board or steering committee has final
responsibility for meeting the project goals. It typically is
comprised of representatives or stakeholders from each of the
major participants.
▪ A project manager leads the team and administers project elements
that include alignment, risk identification and mitigation, escalation,
and cross-Microsoft collaboration.
▪ All project leaders, including the project manager, solution
architect, and technical architect, closely communicate and align
toward the common goal of solution deployment.

Fig.
6-6

Governance domains
Project Stakeholder Solution Risk and ​issues Organizational change
management engagement management management Change control and communication

▪ Weekly status ▪ Executive steering ▪ Oversight of ▪ Objective risk ▪ Identification and ▪ Intentional and
reports​ committee​ functional and assessment and prioritization of customized
nonfunctional mitigation planning​ requirements and communication to
▪ Project plan and ▪ Communication
attributes solution attributes​ stakeholders​
schedule​ and promotion​ ▪ Issue identification,
▪ Data, integration, ownership, and ▪ Tracking and ▪ Periodic
▪ Resource ▪ Escalation of
infrastructure, and resolution reporting via ADO effectiveness check​
management​ unresolved issues​
performance
▪ Prioritization and ▪ Organization and ▪ Solution adoption
▪ Financial ▪ Solution decision
▪ Customizations and severity assessment​ process changes​ and operational
management​ making and
process adaptation​ transformation
collaboration​ ▪ Risk response
▪ Risk management​ management​
▪ Security and management​
▪ Business alignment
▪ Change compliance​
and tradeoffs​
management

▪ Project status ▪ Project change ▪ Architecture board​ ▪ Project status ▪ Statement of work​ ▪ Communication plan​
meetings and reports​ management​ meetings and report​
▪ Governance ▪ Project artifacts​ ▪ Stakeholder
▪ ADO (project tools)​ ▪ Solution framework ▪ ADO (project tools) engagement​
▪ Project status report​
management​
▪ Governance ▪ Organizational
▪ Governance
framework ▪ Organizational change management
framework
change management

Implementation Guide: Success by Design: Solution architecture design pillars 120

 ▪ The technical architect leads and orchestrates the technical
architecture across all application components to ensure
optimal performance.
▪ The solution architect guides users toward the new vision
and transformation.
▪ The change manager ensures all internal and external
communications are in place.

Conclusion
As we’ve explained in this chapter, solution architecture follows a
systematic approach that identifies your desired solution and the
building blocks needed to construct it. Solution architecture design
takes your business vision and breaks it into logical sections that
become a blueprint for building your solution. Here is a list of the key
steps for solution architecture design:
▪ Define your vision.
▪ Create a business strategy.
▪ Outline your business processes.
▪ Determine how people are connected in and around
your organization.
▪ Know your data.
▪ Develop a solution strategy using technology and tools.
▪ Apply project management, change management, and
governance and control methodologies.

Implementation Guide: Success by Design: Solution architecture design pillars 121

7 Guide
Process-focused
solution
Implementation Guide: Success by Design: Process-focused solution 122
 Introduction
Fast changing technologies and markets demand a
rapid rhythm of delivering products and services.
Business applications improve inefficient processes by automating,
optimizing, and standardizing. The result: A more scalable
business solution.

An approach based on business process mapping and management in an

implementation project is fundamental if organizations are to achieve their
In this chapter we cover the goals. When implementations use this approach, there is more consistency
following topics related to a
in project phases, communication flows better, and processes run better.
process-focused solution:

Start your implementation project

with business processes This chapter introduces the importance of a process-focused approach
when implementing Microsoft Dynamics 365 Business Applications. The
Opportunity for optimization
goal is to emphasize the benefits of employing business processes as the
Defining the scope of
primary framework for a project implementation cycle.
the implementation

Defining your requirements

Fit to standard and

fit gap analysis Start with
Implementation lifecycle
connected to processes business processes
A solution that helps you to
operate your business
Business processes are the main drivers to start defining the solution
implemented in your project.

Implementation Guide: Success by Design: Process-focused solution 123

 The business language
Every organization has an internal language they use to describe daily
operations. This language is immersed in business processes and is
often largely based on terminology common to the industry. When
implementing business applications like Dynamics 365, this business
language is the best, most familiar way for the business to think about
their needs and the tools and technologies that they use for work. This
business language is not simply terminology. It includes the processes
used to conduct day-to-day transactions and activities. Curating and
utilizing these processes in the language of the business is important to
keep sight of the basic truths of business requirements. It also reduces
the risk of the implementation team getting lost in the jargon and
nomenclature of the technical tasks involved in the implementation.

When the project starts, putting the business process view of the
organization at the core pays dividends.

Start with a business process future vision

Creating a vision of how a business is transformed through technology
makes it is easier to focus on the activities needed to achieve that goal.
This vision needs to include the understanding of how the business
currently works and the state that it wants to reach after.

Successful implementations start with a clear understanding of an

organization’s business model. That includes understanding how the
organization creates value through its products and services, as well
When discussions about the project and as its relationships with customers and suppliers. There are multiple
business processes begin with third parties,
business processes strategically aligned to make that business model
it’s helpful for those who may not be
familiar with the organization’s business to work. Chapter 4, “Drive app value,” describes how to define a business
begin learning this language.
model and the importance of connecting the business model to business
processes, and the business processes provide the baseline to draw the
roadmap of your solution for the digital transformation.

The processes derived from the business model provide insight on

what it takes to reach the desired future. Business processes define the
functional scope of the solution being implemented as illustrated in

Implementation Guide: Success by Design: Process-focused solution 124

 Fig.
Figure 7-1. Any set of business processes being implemented needs
7-1
definitions before you can start working on requirements and other
Requirements
aspects of the solution.
Business
process
When defining your business model, assess the state of your processes.
Some organizations may want to use new technology to optimize existing
processes through automation. Others are moving to e-commerce or
outsourcing parts of the operation, which requires new business processes.
Solution
Still others might be moving to lean manufacturing.

Many organizations also seek to consolidate operations and introduce

standard processes across different parts of the business. Understanding
the state of the processes allows you to understand how to reach your
Business process model goals. The effort required to implement an existing process using new
technology is very different than what is required to define new processes
or gain consensus from stakeholders.

New business processes won’t always be the same across a business.

One division, for example, might decide to ship inventory directly to
customers rather than to a warehouse, while others continue to use a
warehouse. On the other hand, it may be that the model for employee
purchasing is the same, so a shared product catalog and ordering
Start your implementation process is implemented. In any case, business model analysis, process
project with business processes
reengineering, and standardization strategies should be considered
Opportunity for part of the project definition. That firmly anchors the processes to the
optimization business strategy and also helps generate process-based project goals.

Defining the
scope of the
implementation Opportunity for
Defining your
requirements
optimization
It is easier to find good opportunities to optimize your process using
Fit to standard and
fit gap analysis business process mapping.

Implementation
lifecycle connected
to processes Mapping processes
A solution that helps you to Processes are the heart of every business. They describe how the business
operate your business operates. The fact that your products or services reach your customer

Implementation Guide: Success by Design: Process-focused solution 125

safely and on time is due to a series of tasks executed by different roles
and different business units. Business mapping represents these steps.

Baseline business processes are called “as-is” processes. Depending on

the organization, these may be legacy processes or they may be new
processes engineered as part of a new solution or business model.

Regardless of where an as-is process set comes from, it is critical that

they are described at the appropriate level. As-is processes that con-
tain details about how current implementations are in legacy systems
introduce a risk of reimplementing the legacy system. Keeping as-is
processes at the more abstract level helps drive the scenarios in scope
and enables the team to focus on the desired business outcomes.

It’s worth reminding ourselves that the objective of as-is business

process mapping is not to define step-by-step how the solution is
designed in the new solution.

The goal of mapping the as-is business process is to:

▪ Provide structure/skeleton for the definition of the scope of
the project.
▪ Express the project aims in the natural business language of processes.
▪ Enable a natural way to define the main end-to-end business
scenarios (process variants).
▪ Provide the best language to identify and highlight areas for process
innovation and improvements, as well as risks and constraints.
▪ Become the basis for mapping to the equivalent process design
within the new system.
▪ Create a workable definition of the project that the business can
directly interact with without going to the level of individually
written requirements.

The value of having business processes mapped early is that it allows

everyone involved to understand how the processes operate by using
them as a common business language. This helps both third parties
and the organization agree on processes across multiple departments
and organization layers. It is common for senior managers to be
surprised by how processes actually work on the ground.

126
 It is essential that the right team is involved in mapping business
processes to the new technology. This team should be guided by the
business stakeholder who owns the process in the business opera-
tion. This individual is charged with making the right decisions about
structure and investment in the process to achieve their goals. The
stakeholder is supported by one or more subject matter experts who
are familiar with how the business process operates in the real world.
These experts can provide depth around the various scenarios under
which a process is executed. Their knowledge, coupled with a mindset
open to new ways of working, helps drive the right conversation on
process mapping.

Here’s an example. Let’s say a company is looking to move to a B2B

business model via e-commerce and seeks to deploy their telephone
salespeople strictly to consumers. There may not be existing patterns
within the business to replicate, so the new processes should be based
on expected outcomes rather copying legacy steps. This mindset
should be applied to all processes, as the key deliverables should be
the expected “business scenarios” and the desired business outcomes.

When reviewing new process diagrams, the team should consider

the following:
▪ Do the business SMEs recognize their business in the processes?
▪ Do they provide adequate coverage of the business activities in scope?
▪ Do they show the key interconnections between the processes?
▪ Do they show meaningful end-to-end business flows?
▪ Will they represent a good level at which the project team can
communicate with business stakeholders on risks, progress,
decisions, and actions?
▪ Do they illustrate processes sufficiently to identify opportunities
for improvement?
▪ Are they sufficiently well-defined to be able to be used in the next
stage where the processes can be applied to drive the design in the
Dynamics 365 system such that they can reflect the improvements
and the project goals and vision?

These process diagrams help define the baseline for the organization’s
current business and are a good place to start when plotting optimization

Implementation Guide: Success by Design: Process-focused solution 127

 objectives. They should help to identify the processes or parts of processes
that are not efficient or well understood.

The key to getting the processes mapped well and quickly is to ensure
the following.
▪ The right people are in the room to direct the mapping.
▪ Any mapping software or tools that help facilitate the rapid definition
of the process and do not slow things down.
▪ The level to which the process is described is directly proportional
to its importance to the business. For example, once the end-to-
end scope of a widely used and very standard finance process is
defined to a certain level it should not be further broken down to
step-by-step processes.
▪ The process mapping effort is interactive, not a series of documents
that go through long handoffs and approvals.
▪ The tools for the mapping can be anything from sticky notes, to
Microsoft Visio, to specialized process drawing software. The pro-
cess maps are visual and not hidden in wordy Microsoft Excel lists.

This is a vital step that needs to be executed early. Plan so that processes
are defined as fast as possible using the simplest tools in the workshop,
like sticky notes, pens, and whiteboards. The drawings and comments
can then be transferred offline to more sophisticated applications.

Remember that doing this mapping at the start of the project

implementation is important. It could become a fundamental part
of helping the analysis of the opportunities for process improvement
and creating the right baseline for the project.

Modeling your solution for the future

Digital Digital transformation is fast paced. Processes that work today may not
transformation is fast remain competitive tomorrow. Technologies like the cloud, artificial
paced. Processes that intelligence, machine learning, robotic process automation, virtual

work today may not reality, the Internet of Things, big data, virtual conference rooms, and
many others create possibilities that did not exist a few years ago.
remain competitive
tomorrow. When reviewing your business processes, it is important to keep in

Implementation Guide: Success by Design: Process-focused solution 128

 mind how innovative technologies can improve process outcomes and
collaboration. Similarly, there may be multiple areas in your processes
which would benefit from modern options now available. Technology is
For example, the Microsoft
HoloLens is being introduced to a key differentiator. Remember, chances are that your competitors may
some manufacturing processes with
well be considering these options and looking to incorporate them.
Dynamics 365 applications. Using the
HoloLens, the user can understand how
to operate a machine. Or if a machine
is broken, and support is on the other
side of the world, virtual reality enables
Standardize your features with a business
collaboration between the user and
support to repair the machine.
processes approach
Earlier, we discussed how a business model analysis can introduce
Or if you have a workflow with
approvals that require a signature, opportunities for process reengineering and standardization.
you could add eSignature software to
automate the process and reduce the
time for approvals. Assuming there is a good plan for process standardization grounded
in the business strategy, this standardization can be aided with a new
business application system.

Of course, standardization across business units assumes that the

business models are sufficiently similar and there are no local market
constraints or competitive reasons for there to be differences.

Various benefits can come from standardized processes assuming the

business models are sufficiently similar between the business units so
that the other barriers to standardization are low.
▪ Enables reduction in cost by reducing the variations of business
processes that need to be implemented, trained, and maintained.
▪ Facilitates comparative analysis across multiple groups of users
that are executing the same process.
▪ Facilitates mobility of resources within the organization through
standard processes to deal with changes in demand.
▪ Promotes the adoption of best practices across the organizations.
Optimization for anyone improves outcomes for everyone.

Standardization also helps with rolling out the implementation to

other business units as it reduces the time and effort compared
to building a process from scratch. After the first implementation,
there is a proven case of it working within the business. The next
business unit to be implemented can discuss the pros and cons of
the standard process with business peers.

Implementation Guide: Success by Design: Process-focused solution 129

 Similarly, it is important to confirm that the constraints and implications
are identified and well understood prior to starting design work.
▪ Standardization of a process can bring benefits at a group level,
but may be seen as additional work by a local business unit.
▪ Standardization can require significant change management.
▪ Is the standardization being defined at an industry level and then
implemented in the system? This can create a conflict if standard
processes are not a natural fit with Dynamics.
▪ Will the process be designed in Dynamics 365? And will these
processes become the new standard?
▪ Is the entire end-to-end process to be standardized or will there
be areas and functions for local variations? If so, does that align
with the standard capabilities in Dynamics, or could it need
customizations?
▪ Does the business case for standardization remain sufficiently
strong after all the constraints and implications are balanced
against the benefits?

In multiple, phased rollouts, process standardization often takes the

shape of a “core template” with the expectation of rolling out this
“template” to subsequent business units.

Creating process maps is essential to identifying the opportunities and

Start your implementation to realizing the potential benefits outlined previously. The use of the
project with business processes
common business language of processes is the vital mechanism that
Opportunity for optimization brings all of these aspects into focus.

Defining the
scope of the
implementation Defining the scope of the
Defining your
requirements implementation
Fit to standard and
fit gap analysis A business application implementation is essentially the delivery
of a new capability for end-to-end business transactions using the
Implementation
lifecycle connected application. Processes are the foundation for the definition of the
to processes solution scope. Processes embody many of the properties that make
A solution that helps you to for a good scope definition.
operate your business ▪ Business processes are well understood by the customer as they

Implementation Guide: Success by Design: Process-focused solution 130

 are expressed in the languages they know best.
▪ Processes are richer in context than a requirements list.
▪ Processes show the connections between different business units,
roles, functions, task-level steps, and systems.
▪ They are naturally hierarchical and can be expressed in different
levels of detail, depending on their intended purpose.
▪ Processes are the connectors that show the data and people
feedback loop.

Process mappings can be collected in a process catalog. This

catalog helps turn the visual process diagram into data. The business
processes in the catalog can then be numbered, labelled, and uniquely
referenced. Process hierarchy can be managed as part of the data
structures. Typically, these can then be managed in Azure DevOps
(or similar tools) where they can then be assigned to various tasks
such as configure, build, design, or test and to different project roles.

Business processes are usually interwoven with other business

processes. These interconnected processes can span systems, and
the connection can be a simple endpoint or an entire subprocess
performed in the external system. If the latter, it should be consid-
ered for your solution scope. Where the process is in the external
system is directly relevant to the end-to-end process, include the
full process in the process mapping. This not only helps in under-
standing the process, but also with making better decisions on
customizations and selecting ISVs, which are also stated in your
solution scope.

Using process mapping as part of the definition of the scope also

helps when working with implementation partners. The process flows
helps express the ultimate outcomes for the project and having them
reflected the statement of work can help with a more comprehensive
definition of the project that results in fewer change orders.

Keep in mind that business processes are always subject to change.

As you move forward you are enriching the business process flows,
and possibly adjusting the solution scope. That is exactly the flexibility
that a business process flowchart offers.

Implementation Guide: Success by Design: Process-focused solution 131

 Fit to standard and fit
Start your implementation
project with business processes

Opportunity for optimization

gap analysis
Defining the scope of the
In many projects, inertia drives the old ways of working. There are several
implementation
dangers in assuming that what works now also works just as well in a
Fit to standard and new Dynamics system. Recreating processes based on legacy systems
fit gap analysis (often very old systems) can lead to the following:
▪ Unnecessary and excessive customizations and costs related to
Defining your requirements
design, coding, testing, training, documentation, etc.
▪ Stagnation in the business as the natural opportunity for innovation
Implementation
lifecycle connected and improvements is lost
to processes ▪ Creating unique, siloed, inefficient processes when Dynamics 365
could provide more standard and recommended ways of working
A solution that helps you to
operate your business based on the learnings of thousands of customer organizations
▪ Damaging the natural usability engineered into Dynamics 365 by
forcing processes designed for legacy software into Dynamics
▪ Creating processes within Dynamics that were not designed to be
used in that way and therefore reducing the ability to use other
related functions because the processes are no longer a natural flow
or fit for the purpose
▪ Reducing the ability to immediately use the documentation, training,
sample code, and sample data available for the Dynamics system
▪ Reducing the ability to leverage market and industry knowledge,
insights, and experience in Dynamics 365 for the areas of interest for
the business
▪ Reducing the ability to directly apply tools and apps in
the marketplace
▪ Reduced capacity and resources available to apply customizations
that can provide significant business value as the available budget
and resources get used on customizations that do not add the
same value
▪ Creating barriers for end-user developers (citizen developers) to
create rapid, low-cost application using the Power Platform by
creating a more complex, customized data model/process model

When it comes to understanding exactly what is going to be implemented

in your future solution, it is necessary to perform a deep analysis about

Implementation Guide: Success by Design: Process-focused solution 132

 the current processes and what needs improvement. To determine what
functionalities of your business applications to keep, and what others
could be built or purchased from external vendors, we suggest under-
going the following analysis. We suggest this because it helps to have a
standard solution, with minimal customizations, which minimizes costs
and therefore maximizes value to the business.

Adapting to the standards of new system

It is recommended to start with a fit-to-standard approach for every
project. As part of the definition of the scope there should be a business
process catalog created in the early stages of the project. This can now
be used as the set of processes that can be configured and enacted in
Dynamics 365. Of course, initially, not all the configuration is completed
perfectly. However, starting with the core business processes and iterating
until there is a good, high-level understanding of how the processes could
be implemented within the system helps create the solution blueprint.
Putting the fit-to-standard approach at the front of the analysis helps
to set the right culture of “adopt wherever possible, adapt only
where justified.”

In most projects this analysis is not starting from a blank piece of paper;
the implementation partner has conducted some part of this analysis as
part of providing estimates on cost and time and a solution overview.
It is recommended that the customer project team get deeply involved
in this process to confirm that the key business processes were correctly
interpreted and to start gaining knowledge of the standard processes
embedded within Dynamics 365.

The continuation of the fit-to-standard leads to the definition of

requirements, fits, and gaps, but this is from the perspective of leveraging
the processes enabled within the system first rather than trying to recreate
the legacy system in Dynamics 365.
Processes are the
foundation for the The advantages of starting with this approach using the process catalog
are as follows.
definition of the ▪ It promotes the reduction of customizations by supporting the deliv-
solution scope. ery of the underlying business needs through configuration rather

133
 than going directly into fit gap analysis with detailed require-
ments that may be influenced by the existing or legacy system.
▪ It helps reduce the risk of missed requirements as the evaluation
of the fit with the new system is based on the richer and broader
context of business processes. As these business processes are the
natural language of business users, their evaluation is more com-
prehensive, meaningful, and effective compared to working with a
list of requirements.
▪ The process catalog can direct the fit-to-standard assessment
by working iteratively through the processes, starting with the
higher-level core processes, and then working with the more de-
tailed sub processes and variants. This also helps the business users
more clearly see how well their underlying business requirements
are being met within the system.
▪ The project is more likely to adopt modern recommended
standard processes embedded in the system.
▪ It creates higher-quality solutions as the processes are tested
by Microsoft and are more likely to be market-tested by others,
whereas custom developments and variants, especially complex
ones based on the legacy system, will need to be specifically
validated by the customer.
▪ The standard solution allows for more agility in adopting related
technologies and by keeping to standards where possible, make it
easier to add the real value-add custom extensions.
▪ It enables a faster delivery of the new solution; there is no need to
wait longer for a custom solution to be developed.
▪ Standard processes are more easily supported by internal and
external support teams, including Microsoft Dynamics Support.

The benefits of staying within the standard product wherever possible

are clear. The implementations following this approach, often called
vanilla implementations, adopt the Dynamics 365 system with its
standard configuration as shown in Figure 7-2.

Some businesses may have specialized business processes or an

innovative idea to improve their competitiveness in the market. In
such cases, a process-centric description of the system allows these
improvements to be adopted with more transparency.

Implementation Guide: Success by Design: Process-focused solution 134

 Fig.
7-2
Dynamics 365

Process Process Process Process

Start End
step 1 step 2 step 3 step 4

Gap analysis
As discussed in the previous section, adopting a process-centric
solution within Dynamics 365 has clear benefits. However, there may
be specialized functions that are not part of the standard solution as
shown in Figure 7-3. That is identified with the fit gap analysis. After
having the configurations set, you can look for gaps in the processes
and make a decision whether to customize.

Extending a solution can vary in terms of time, cost, and complexity.

There are many things to consider when extending. But it offers the
benefit of a solution tailored to business needs. See Chapter 15, “Extend
your solution,” for details on extending a solution. Here we look at the
implications of taking a process-centric approach.
▪ Some extensions can bring innovation into business processes. They
can add business value and provide good, long-term benefits.
▪ It is important to consider potential customizations in light of the
rapid pace of innovation in Dynamics 365 SaaS applications. New
features are released regularly and keeping an eye on the Dynamics
release plans avoids creating extensions that are quickly redundant.
▪ When evaluating a potential custom extension, using the process
maps can help determine the impact, not just on the process being
directly changed but also the impact on connected processes.
▪ When looking at potential solutions for requirements that cannot be
met directly in the standard system, consider the various different
Fig.
7-3
Dynamics 365 methods available:

Process
Process Process Process End
Start step 3 with
step 1 step 2 step 4
Extension

Implementation Guide: Success by Design: Process-focused solution 135

 ▫ For simpler designs, consider citizen developer-led applications
using the Power Platform, which can generate large value very
rapidly and at a low cost.
▫ For more complex or global solutions, some combination
of citizen and professional development through the Power
Platform or other technologies may be a more effective and
productive route. Using the process catalog can help provide
an excellent backdrop to communicate and collaborate
between the project team, the citizen developer, and the
professional developer.

Third-party solutions
An alternative to extending is to buy an existing solution from a
third-party vendor, also known as an independent software vendor
(ISV). This option is more common when there is a significant gap
and developing a functionality in-house can be complex and costly.
Sometimes you don’t have enough resources, budget, or expertise to
develop such a significant solution.

ISV solutions tend to focus on more specialized process areas,

normally covering some end-to-end industry-specific process. In
addition, ISVs provide specific functionality to cover gaps, as illustrated
in Figure 7-4. Successful ISVs have expertise and experience in the
vertical industry processes they cover and can therefore add value to
your business processes.

Dynamics 365 has been designed to meet standard business processes.

It enables projects to adopt the standard application more easily and
Fig.
7-4

Process 4 in
external app
or ISV
Dynamics 365

Process
Process Process Process End
Start step 3 with
step 1 step 2 step 5
Extension

Implementation Guide: Success by Design: Process-focused solution 136

 minimize the number of perceived gaps. It also has the flexibility to
customize and integrate external applications. Rather than choosing one
or the other, buying some third-party solution along with a standard
implementation can build an optimal solution.

Representing the fits and gaps in a business process map in terms of the
processes drives a better understanding within the implementation team
and the organization. This is also needed to enlist the requirements for
the design of the future solution.

Defining your
Start your implementation
project with business processes

Opportunity for optimization

requirements
Defining the scope of the
implementation Some projects start with lists of requirements derived as a set of
atomic functional requirements, but without reference to mapped
Fit to standard and
and documented business processes this can pose risks like the following:
fit gap analysis
▪ Late discovery of missing process steps
Defining your ▪ Misinterpretation of the requirement by parties not experts in the
requirements related process
▪ Lower business engagement in the project
Implementation
lifecycle connected ▪ Longer review cycles as the requirements and designs are less clear
to processes

A solution that helps you to Business process mapping helps draw the as-is processes to understand
operate your business how the business is running right now, and the to-be processes to show
how they work in the future. This also emphasizes the importance of
business process mapping early in the project.

After determining what you keep or build, create the list of requirements,
aligning them to the business processes for an accurate picture. You can
use tools equipped for the traceability of the requirements.

Typically, in a process-focused solution, once the processes have been

defined and agreed upon, the detailed requirements are derived and
relevant designs mapped. There are tools within Dynamics 365 to help
with managing the requirements. For example, Azure DevOps can
work to create and track requirements, and if you are implementing

Implementation Guide: Success by Design: Process-focused solution 137

 Dynamics 365 for Finance and Operations, you have the Business
Process Modeler (BPM) as part of your lifecycle services (LCS).

The list of requirements is easier to be crafted starting from the business

process mapping and it can be iteratively revised and refined.

Process-centric
Start your implementation
project with business processes

Opportunity for optimization

implementation lifecycle
Defining the
scope of the The value of taking a process-focused solution does not end with a
implementation better definition of requirements. Adapting all the activities in the
Defining your subsequent phases to be more process-based helps deliver better
requirements outcomes, regardless of underlying methodology.

Fit to standard and

fit gap analysis At go-live, a business application such as Dynamics 365 sees system
users performing tasks and activities as part of a business process.
Process-centric The users are not executing on gaps, fits, or isolated requirements.
implementation It is important to keep this in mind when thinking of the full project
lifecycle lifecycle. The ultimate test of the project success is when the system is
A solution that helps you to in operation and the design build testing actions are intermediate steps
operate your business towards that goal. It is recommended to drive these phases with the end-
to-end business process as the framework upon which all the related
activities are planned, performed, and measured.

See the prospect to cash with Dual-Write integration to high-level

end-to-end process map in Figure 7-5.

Design
When creating the solution blueprint, the vision of the overall solution
architecture gives solidity and certainty to the project scope. This is the
transition from scope as business processes to scope as designs within the
system. As it is expressed in business language, it helps to ensure that busi-
ness users can be usefully engaged in the review and approval of the scope
and proposed solution. There are, of course, other views of the solution
architecture in terms of data flow, systems landscape, and integrations.

Implementation Guide: Success by Design: Process-focused solution 138

 Fig.
7-5 Dynamics 365 Sales

Product and
Account Contact Quote Order Invoice
pricelist

Dual-write

Customer Contact person Product Quote Sales order Invoice

Finance and Operations

As part of the design phase in a Waterfall methodology, or during
design work in sprints in a more Agile methodology, breaking down the
end-to-end business processes into meaningful subprocesses provides
manageable, bite sized units of work. It also allows better communication
of the project tasks with business users.

The specific user stories, or configurations, and build work at a task

level can be related to the subprocesses so that they have the correct
business context. This makes it easier for business users to better
understand the design and the business reviews and approvals of
designs are meaningful.

If the business processes are collected in a structured and hierarchical

process catalog, this catalog can be used to do the following.
▪ Help more easily and logically determine the sequence of work
starting with the more foundational process designs before tackling
the lower-level designs.
▪ Help highlight the interrelationships and dependencies between
the different business value streams, departments, roles, and
functions—this helps with designing a more cohesive and
integrated overall solution.
▪ Help better manage the distribution of the actions and activities by
leveraging the sequence and interrelationship of the designs in scope.
▪ A process flow can directly be mapped to the system design from
configuration through data setup and functional run through.

Implementation Guide: Success by Design: Process-focused solution 139

 ▪ Help deliver working processes in Dynamics 365 software, by
implementing processes, including end-to-end process as early as
possible, and by taking a process-centric view.
▪ Help provide a better understanding of the solution by looking at
the current capability of the emerging system to execute end-to-
end processes.
▪ View the system in the context of a process, reducing unnecessary
customizations .Better engage the business subject matter experts
(SMEs) and business stakeholders by using the business language
of processes.
▪ More rapid delivery of working software that better reflects and
makes better use of the Dynamics 365 SaaS cloud world.

Deliver processes in Dynamics 365 as early as possible, taking a

process-centric view. The benefits are practical and real, and often the
only real barrier to taking a process-centric view of design tends to be
the legacy of previous, more technical, and custom development-centric
approaches, better suited to the pre-cloud and SaaS world.

Having the high-level process, you can start breaking down the end-
to-end business processes into meaningful subprocesses, as shown
in Figure 7-6.

Development and configuration

A process-centric view provides an excellent basis for converting de-
signs into software. It can help directly address the question of how to
execute the business process within Dynamics 365. The configuration
and development tasks have the background of the business process
context, and do not need to be treated as an isolated delivery of a task
from a long list of such tasks.

This isolation is still frequently seen in projects where the development

and configuration work becomes highly technical and is divorced
from the business process. This activity can become an end in itself,
which does not serve the project well. Instead, when a data- and
process-centric view is taken, the configuration and development
tasks can be planned and managed in service of delivering a process
embedded in Dynamics 365 software.

Implementation Guide: Success by Design: Process-focused solution 140

 Fig.
7-6

Dynamics 365 Sales

Product and
Account Contact Quote Order Invoice
pricelist

Dual-write

Customer Contact person Product Quote Sales order Invoice

Finance and Operations

Dynamics 365 Sales

Add products
Start Create order
to order
Price order

End Invoice order Pack order Pick order Confirm order

Finance and Operations

A process-first view allows the team to collaborate more productively. The

process designs, which now reflect the functions and configuration and
flow within the Dynamics system, help the various teams communicate
the context and better understand the delivery of any development.
Compared to working from a task in DevOps, or from a paper design,
the process background provides a better context and implications for
a build task. For example, taking a process-centric view can help with
the mapping of the access necessary for performing process tasks. That
helps build a picture of the related security roles.

A process-focused view of the emerging solution also helps avoid

the dangers of a primarily “fit gap” approach which can create point
solutions. Instead, with a process-first background, there is a high
probability that the tasks and activities crystalize into a coherent and
well-functioning solution.

Implementation Guide: Success by Design: Process-focused solution 141

 The project can also use the process-focused solution to conduct reviews
of the solution with the wider business to confirm that the project is
delivering on expectations. These reviews are much harder to do well
without the supporting process definition. That’s because without
the processes in focus, the project cannot speak the language of the
business. Many organizations are expecting some degree of business
process transformation as part of the implementation of Dynamics 365.
The reviews of the solution when the new processes are first explained
in business process terms helps ground the subsequent discussion of the
current state of the solution in clear, well understood business language.
This significantly improves the quality and usefulness of the business
review by minimizing the technical implementation jargon and instead
concentrating on the “business of business.”

Issues with resource constraints are well known. Showing incremental

progress of the build and development using business process language
improves the confidence of the wider business in the project. This can be
key for project success.

Testing
A project that has taken a process-centric view reaps the benefits during
testing. Other than the necessarily narrow focus of unit testing and some
non-functional tests, almost all other test types should be rooted in
some form of process definition. When there is an existing set of process
definitions and the associated designs, and a system with the designs
implemented, there are many advantages to the testing methods.
▪ It helps ensure full testing coverage and enables earlier detection
of any missing or inadequately defined functions or processes.
▪ The testing can more easily follow the process-focused path already
created earlier in the project.
▪ Testing has a natural focus on evaluating business process outcomes
which tends to be a closer match to the intention of the design and
eventual production use.
▪ It enables incremental testing of processes and subprocesses
which in turn helps engineer quality into the solution.
▪ Testing end-to-end processes, which is how the system is used in
production, is enabled.

Implementation Guide: Success by Design: Process-focused solution 142

Overall, testing in a business application like Dynamics 365 is a natural
match to a process-focused view of the solution. Having a process-
centric approach throughout the lifecycle allows testing to become the
natural and obvious progression of the project delivery.

See Chapter 14, “Testing strategy,” for more details on the overall
approach to testing.

Training
Training to use business systems like Dynamics 365 applications is
fundamentally learning how to conduct day-to-day business processes
using the system. Most of the functional roles in the system interact
with multiple functions and processes. Rarely do roles exist in a vacuum
of their own process, but instead interact with other processes. Having
business process flows defined and available in the process catalog,
including flows across the seams of system roles, helps both in the
collation of process-based training materials and to guide the training.

During the design process, if the roles are mapped against the processes
as part of security design, they can be directly used for testing and for
generating role-based training.

Even where some of the system roles may be very specifically restricted to
a specialized function in the system, there is often a need to understand
the upstream and downstream processes to perform a function well, and
to understand any implications of any delays or changes in the flow.

If whole project approach is process-focused, including the configure/

build activities, then the process of generating materials for training
(such as Training Guides for Finance and Operations and Guided Tasks for
Customer Engagement applications) goes smoothly, as there is a direct
correlation between the system processes and the training processes.

The process-based training not only helps prior to go-live—it also can
be used with new hires and when users change roles. It allows those
new to the business to absorb the business process simultaneously
while understanding how that process is performed within the system.

143
 Roles can be easily defined in a business process and use the correct
security roles for testing and training as shown in Figure 7-7.

Support
The process catalog created in the project provides more than the
framework for implementation. It can also help with supporting the
solution. Functional issues raised to support usually need to be repro-
duced by the support team to enable the team to investigate the root
causes. A robust process-based definition of the flow allows support
to recreate the steps defined by the agreed standard process flow. The
visual depiction and description of the process allows the support team
to speak a common language with the business user when discussing
the issues.

This ability to place yourself in the business process helps reduce the
number of back-and-forth cycles of communication and the overall
time taken to understand the issue in business terms. It increases the
confidence of the user that their reporting of the issue has been under-
stood. This reduces anxiety and improves user sentiment of the system.

A solution that helps you

to operate your business
To design and build a solution that has a great positive impact is not an
Fig. easy task. There are many aspects to consider, and everything is so
7-7

Create order - E2E process

Dynamic 365 sales Finance and Operation apps

Add products
Sales manager Start Create order
to order
Price order

Sales clerk Confirm order

WHS worker Pick order Pack order

AR clerk End Invoice order

Implementation Guide: Success by Design: Process-focused solution 144

 connected that even missing a little piece can significantly affect the whole
Start your implementation
project with business processes project. The business processes flows are the common playground where
we gather all the implementation artifacts together. They keep all the
Opportunity for optimization solution components and phases aligned. They are the line connecting
the dots and the main instrument for communication that helps to drive
Defining the
scope of the changes on how the business runs and helps to minimize missing those
implementation little pieces.

Defining your
requirements As you have read through the chapter, business processes are involved
during all the journey of the implementation and they also remain useful
Fit to standard and
fit gap analysis for future improvements. They have a perpetual impact in your business.

Process-centric The creation and documentation of business process flows is to prepare

implementation lifecycle
the fertile ground where the seed will be for all those implementation
A solution that helps activities that allow you to harvest optimized and efficient processes, risk
you to operate depletion, cost minimization, role compliance, integral solution, and, as
your business an ultimate goal, a successful implementation.

Implementation Guide: Success by Design: Process-focused solution 145

 Checklist

Business processes focus Ensure the business process definition is complete and
considers all activities and subprocesses.
Ensure the business process view of the organization is
Take advantage of the latest SaaS technology to drive
at the core of the definition of the project.
efficiency and effectiveness for the process optimization.
Clearly articulate the key business processes that are in
Ensure future readiness when mapping your business
scope and the respective personas so they are under-
process to the solution by incorporating configurability
stood by all involved parties in the implementation.
by design.
Ensure business model analysis, process engineering,
and standardization strategies are considered part of the
Fit gap analysis
project definition and deliver a strong process baseline
before implementation starts. Adopt a fit-to-standard approach and align to the
philosophy of adopting wherever possible and adapting
Collect the business processes in a structured and hierar-
only where justified.
chical process catalog during the requirements phase.

Process-centric solution
Use business processes for each phase of the project to
deliver better outcomes (all phase activities are better
planned, performed, and measured).

Opportunity for optimization

Explore opportunities to evolve, optimize, and consolidate
your processes as part of the implementation to meet
the digital transformation goals and drive user adoption.

Implementation Guide: Success by Design: Process-focused solution 146

 Case study
The journey to a
process-focused solution
A large, multinational organization that provides contract-based
servicing with some manufacturing and distribution services was
planning to replace parts of its 15-year-old tier-one ERP and CRM
systems and other related legacy systems.

The wrong road

The project started with the implementation process that they had
traditionally applied to other IT projects. The traditional approach was
strictly Waterfall with a heavy documentation bias. The initial phase of
requirements gathering was conducted by using the old systems as the
reference point. A very long list of requirements was gathered, with the
assistance of an implementation partner, across the various functions.
The requirements gathering phase was extended a few times as the
requirements review took significantly longer than expected.

The reviews needed multiple parties to read, understand, and validate the
requirements and there was a concern among the business approvers that
if they missed any requirement, or even a nuance, their system would not
function well.

So, there were multiple document-based reviews where comments

Implementation Guide: Success by Design: Process-focused solution 147

 from the approvers were formally submitted and the project team
wrote responses to them, which in turn generated even more
comments from the approvers. The spiral of these reviews finally
concluded, but the business was not entirely convinced that they fully
understood what they had approved and hoped that the design phase
would provide more clarity.

The design phase was similarly based on writing and reviewing complex
design documents and was running late. The focus tended to be on the
“gaps” identified, and as these were not always placed in context, the
discussion with business users was not always productive and was often at
cross purposes. As further delays accrued and the business users were
becoming even less confident about the proposed solution, the
stakeholders decided to review the project direction and the reasons
for the continuous delays and general dissatisfaction.

The change of direction

As part of the review, which included third parties, several
recommendations were made. The primary recommendation was to
adopt a more process-focused approach and apply the processes as the
framework for a more Agile way of working. The first step in the process was
to define the end-to-end process at the highest level in order to establish the
boundaries of the project scope in business process terms. The subsequent
steps then generated two further levels of visualization of the process detail
for the business process streams. The project took deliberate steps to try
to define the processes in terms of the business flow and desired business
outcomes, rather than replicating the existing systems. This process mapping
exercise was done at an accelerated pace, working as combined business,
project, and implementation partner workstreams.

The right road

Once there was a reasonable map of the processes, the requirements
were mapped to the processes so that they could be understood in the
context of a process. As a result, many of the requirements were restated
to be better anchored in the context of a business transaction and thus
less likely to be misinterpreted or removed for being redundant.

Implementation Guide: Success by Design: Process-focused solution 148

 The processes at level two were put into a storyboard by using the
expertise and leadership of the partner solution architect and the
customer’s lead functional expert. The customer’s lead functional
expert used the process flows to create logical end-to-end process
flows across workstreams so the delivery of software would be
meaningful. The partner solution architect provided the Dynamics
365 application view of the embedded standard processes,
dependencies, and constraints to ensure that the sequence of
process delivery would be efficient within the Dynamics 365
applications. This storyboard would drive the sequence of work
from realizing foundational processes to more peripheral ones.
Furthermore, the level two end-to-end processes (such as “Prospect
to Cash”) were prioritized by considering the core/most frequent/
baseline path through the process as a higher priority. The more
specialized and less frequent variations were sequenced to be
designed and delivered after the core processes.

This set of processes in the storyboard were then mapped to an overall

design within Dynamics 365 applications, generating a process-focused
solution blueprint. It was reviewed against the existing technical, system,
and data solution blueprint to create a rounded solution blueprint.

The delivery of the processes was distributed into sprints of four

weeks each, so each sprint delivered a meaningful part of the
storyboard for each of the workstreams, with an emphasis on
delivery of end-to-end processes as rapidly as possible. A high-level
plan was constructed based on the sequence, dependencies, and
estimated effort related to process delivery.

The sprint level planning was performed on the processes in scope

for that sprint, defining a more detailed process flow when required.
Documentation was kept to a minimum and the processes were designed
in the Dynamics 365 system in collaborative workshop environments. All
related activities such as data migration, integrations, testing, training,
change management, etc. were performed based on the processes in
scope. Each sprint culminated in a “conference room pilot” (sometimes
called “working demo” or “playback”), where the business SMEs
presented the new logical business process and how the processes

Implementation Guide: Success by Design: Process-focused solution 149

 were designed and implemented in the system via a demo to an
invited business audience.

At each sprint end, the business attendees reviewed and approved the
incrementally complete and functioning processes in the Dynamics
365 system instead of reviewing and approving complex and technical
design documents. Individual gap designs that had previously been
circulating on paper for weeks and months were getting translated
into end-to-end working software. Business engagement significantly
increased as the project was talking their language and they were
working directly with the emerging Dynamics 365 system rather than
with abstract design documents and lists of requirements.

Arriving at the destination

The project further reinforced the process-centric project approach,
beyond design and build, by using 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 with the project more meaningfully as
they were finally able to understand the project readiness and business
operations implications.

The project successfully went live, and the customer continued to adopt
a process-centric view throughout the remainder of their go-lives in
other countries. The implementation partner decided to adopt this
process-centric approach as their new standard implementation approach
for their other projects because they could clearly see the benefits.

Implementation Guide: Success by Design: Process-focused solution 150

 8
Implementation Guide: Success by Design: Project governance
Guide
Project
governance
151
 Introduction
As the footprint of cloud-based solutions increases,
we need to work with and address different business
and technology challenges.
For example, Dynamics 365 applications are increasingly able to use
low-code/no-code technology. Also, customers have higher expectations
on speed to value. The number of custom development-heavy, multi-year,
big-bang projects is diminishing; customers are looking for early and
incremental value, even on long-term, multi-country rollouts. Cloud-
For a successful project gov- based Dynamics 365 software as a service (SaaS) applications with regular,
ernance strategy, consider non-breaking system updates are changing the way we deliver business
these main areas: applications. Many of the limitations and sluggish project governance
Project goals processes of multi-year, on-premises implementations should not be
Project organization carried into the cloud.

Project approach
We need to ensure that we’re creating a project governance model
Classic structures
that is fit for the world today and tomorrow. This includes considering
Key project areas new governance disciplines and reviewing the classic governance
Project plan model for effectiveness. We also need to consider that many partners,
system integrators, independent software vendors (ISVs), and
We explore each of these areas in more
detail in this chapter. customers may have their own approach and governance standards
that they may have used previously.

Implementation Guide: Success by Design: Project governance 152

 Our objective in this chapter is to provide an overview of the importance
of good project governance. We discuss recommended practices on
how to define the different areas of project governance and analyze
and assess the effectiveness of your governance. We also describe in
more detail some of the key areas of project governance and the specific
considerations that can help stakeholders, project leaders, and
implementation teams increase their chances of success.

The project governance topics discussed in this chapter are relevant to any
implementation methodology; we focus on the underlying principles and
provide guidance in a way that allows customers, partners, and others to
evaluate their own approach and adjust as necessary.

Objectives of project governance

Project governance should be designed to provide the framework and
techniques to do the following (Figure 8-1):
▪ Map business goals into actions and measures that deliver the goals
▪ Structure, plan, and reliably, safely, and efficiently drive the project
▪ Anticipate and avoid common issues
▪ Detect emerging risks and divergence from the planned path and

Fig. 8-1
support corrective actions
▪ Provide the right amount
of flexibility and agility to
respond to unexpected events
and to adjust to the specific
constraints of the customer’s
business or project

When designing or reviewing

your project governance model,
you should examine how well it addresses each criterion. Furthermore,
it’s worth reexamining this in the specific context of the goals and
constraints of your current project.

In this chapter, we explore what project approaches, governance models,

disciplines, and techniques project teams should consider when preparing

Implementation Guide: Success by Design: Project governance 153

 for and implementing a Dynamics 365 project. Similarly, we use
Microsoft’s Success by Design framework to highlight critical questions
to consider throughout the project lifecycle to help drive success.

Why is project
governance important?
All system implementation projects, including Dynamics 365 applications,
need good project governance to succeed. However, business application
Fig.
8-2
projects have specific needs and challenges, and aren’t theeasiest of
projects to implement. Business applications directly impact and are
Typical directly impacted by the processes and the people in the business. For a
business application implementation to be successful, it’s not sufficient
governance to have good software and good technical skills; the project also needs to

issues have good governance processes that include the business.

Unclear or ever-changing A Dynamics 365 project needs to understand the business requirements
project scope deeply and at a domain and industry level. It also needs significant and
sustained participation from business users representing many different
Late discovery of roles, disciplines, and skills. Many, if not most business participants,
project slippage
may not have previous experience implementing business application
or business transformation projects, let alone Dynamics 365. This puts
Disputed areas of
accountability an additional burden on ensuring that the methodology, approach,
and governance models are sufficiently robust to support and drive the
Low or sporadic user and Dynamics 365 business application project. It also requires business users
business engagement
to gain sufficient knowledge of the standard capabilities of the Dynamics
365 application to better map their underlying business requirements to
Delays to go live at
a late stage the out-of-the-box solution.

Technical issues hiding It’s perhaps worth reminding ourselves of the most common problems
underlying governance issues
related to implementing business applications (Figure 8-2):
▪ Unclear or ever-changing project scope
Mismatched expectations
between customer and partner ▪ Late discovery of project slippage
▪ Disputed areas of accountability or project responsibility
Stakeholders blaming ▪ Low or sporadic user and business engagement
each other
▪ Delays to go live (often at a late stage)

Implementation Guide: Success by Design: Project governance 154

 ▪ Technical issues hiding underlying governance issues
▪ Mismatched expectations between customer and partner
▪ Stakeholders blaming each other

The list is long, and you may have seen other issues, but most of these
issues result in project delays. However, the root cause of the issues
tends to lie in gaps in the definition of the governance model, or in the
effectiveness of operating the project governance processes. Even after
the project goes live and meets most of the business requirements, if the
project delivery isn’t smooth, it can create stakeholder dissatisfaction
and a lack of confidence in the project.

In the context of the implementation lifecycle, you should define the

project governance model as early as possible, and certainly as part of
the Initiate phase of the project, because it directly influences the project
approach, oversight, resources, and project plan. During the Initiate
phase, if the customer or the partner has an underlying governance
model, you should review it and adapt it for this specific project, with
consideration for any specific business requirements and constraints.

Next, we explore the various areas that you should think about as part
of establishing your project governance model.

Project governance areas

Project Project governance is a wide topic and can encompass multiple different
governance practices and disciplines. Various methodologies exist in the market,
including those that are customized by partners and customers.
Project goals
Irrespective of the methodology, you should consider some fundamental
Project organization principles when designing your governance, or when reviewing and
revising it.
Project approach
The vast majority of projects have some form of governance; we’re
Classic structures
not describing setting up the common governance disciplines here.

Key project areas Instead, based on our experience across thousands of projects, we look
at the areas where we often see the need for reinforcement and expan-
Project plan sion to drive a more reliable and successful project delivery experience:

Implementation Guide: Success by Design: Project governance 155

 ▪ Project goals  We look at whether the goals deliver solid foundations
for the implementation, are well defined, and provide the necessary
direction to the project
▪ Project organization  We explore how the right project organization
and related roles and responsibilities help or hinder the efficiency of
the project
▪ Project approach  We examine the impact of the right methodology
and the wider approach on project success
▪ Classic structures  We review how we can examine the most
common governance processes to ensure they don’t hide the real
issues and provide false reassurance
▪ Key project areas  We look at how we can improve effectiveness in
areas of the project that get a lot of technical attention, but frequently
suffer from insufficient direction, planning, and oversight
▪ Project plan  We examine the critical importance of good project
planning and extract some of the planning-related lessons from
the previous sections

Project goals
Project goals Well-defined project goals are essential for steering a project and for
defining some of the key conditions of satisfaction for the stakeholders.
Project organization Often, the project goals are described in the project charter or as part
of the project kickoff. In any case, it’s worth shining a spotlight on them
Project approach
as part of the Initiate phase of the project and regularly throughout
Classic structures the project. We recommend taking deliberate actions to reexamine the
goals in the context of your latest understanding of the project.
Key project areas
When reviewing or crafting project goals, consider the following:
Project plan

Are the goals clear and realistic?

If your goals are overly ambitious or vague, the project may expend
unreasonable effort and time in the attempt to meet them, only to fall
short of the expectations set. Of course, no project intends to create
unclear or unrealistic project goals, yet there is a long history of such
examples, so we recommend conducting an honest review to confirm
these against the latest project scope.

Implementation Guide: Success by Design: Project governance 156

 Where possible, create objective goals, which are easier to measure, work
with, and track. Some qualitative goals such as “the new system should
work at least as well as the old system” are open to interpretation and can
drive the wrong project behavior. They can be misinterpreted and force
the team to design customizations in the new system to try and recreate
the old system. Instead, consider the goals in terms of the overall business
outcomes you desire; this framing allows the project to deliver them in a
way that is most efficient in the new system architecture.

Are the goals aligned with the business priorities?

If the goals aren’t well aligned with the priorities of the business stake-
holders and the business units in scope, the project won’t receive the
necessary business ownership, participation, or attention. Consider
whether the IT priorities and the business priorities expressed (or
implied) by the project goals are complementary. We also recommend
explicitly verifying that the priorities given by the organization are well
understood and aligned with those of the operating business units.
Sometimes group-led policies and requirements implied by the project
goals, which are expected to deliver additional controls and value at the
group level, may generate additional work at the operating unit level.

It’s essential to have all the stakeholders pull the project in the same
direction—conflicts at the level of misaligned goals are extremely
hard for the project team to solve. For example, if Finance leadership is
looking to improve compliance by adding more checks and approvals
in a purchase process, and Procurement leadership is looking for a
faster, less bureaucratic and more streamlined purchasing process,
It’s essential to have unless the goals are balanced, the project delivery will falter. The end
all the stakeholders result will probably disappoint both stakeholders. Another common

pull the project in example is when IT leadership has a goal of a single platform or
instance for multiple business units, but the business unit leadership
the same direction— has no goals to create common business processes. This mismatch
conflicts at the level can remain hidden and undermine the feasibility and efficiency of a
of misaligned goals single platform.

are extremely hard

Again, we recommend reviewing the goals with the stakeholders to
for the project team confirm that they will promote the right project delivery and business
to solve. outcomes. Successful projects have not only ownership of the project

157
 goals from the business, but also ownership of the successful delivery
of the project goals.

Are the project goals well understood by all the project members?
Some projects rely on a single kick-off meeting to communicate the
goals. However, many goals would benefit from more in-depth discussion
(especially with project members from outside the business) to better
explain the underlying business reasons. Consider how you can reinforce
this communication not just during the initial induction of a new project
member, but also throughout the project lifecycle.

Have the project goals been correctly translated into

project deliverables?
Once a project starts the Implementation phase, the necessary

Once a project starts attention needed for the day-to-day management and delivery can
sometimes overshadow the importance of the strategic project goals.
the Implementation This is one of the key findings from project post go-live reviews—the
phase, the necessary original aims of the project faded into the background as the project
attention needed battled with the day-to-day challenges.

for the day-to-

In many cases, projects are driven by the fit gap list, which takes a very
day management narrow view of the business expectations. Consider specifically reviewing
and delivery the initial scope of the project and initial solution blueprint (and project
can sometimes plan) with the business stakeholders to assess how well the goals are

overshadow the mapped to the project deliverables and take any corrective actions.

importance of the Is the governance process structured to formally monitor

strategic project goals. progress against the goals?
This is an often-neglected area; sometimes projects only seriously review
the goals or success criteria as part of the final go-live assessment, which
is too late. Try to avoid this by defining specific structured processes to
ensure the assessment is ongoing. For example, look at how the solution
design blueprint helps meet the business process objectives and how the
data migration and reporting strategy meets the information access ob-
jectives. Monitor to confirm that the project priorities are aligned with
the project goals and aren’t being diverted by other considerations or
day-to-day challenges.

Implementation Guide: Success by Design: Project governance 158

 Project organization
Projects implementing business applications tend to have common
Project goals
structures and roles (such as project manager, solution architect, subject
matter expert, functional consultant, and technical consultant) that are
Project organization recognizable across different projects. The difference in the effectiveness
Project approach of project teams comes from the way in which the project organization
functions in practice compared to the theoretical constructs (Figure 8-3).
Classic structures

When assessing your project organization, consider the following:

Key project areas

Project plan How well is the project team aligned to the business?
Teams that have good alignment between the business streams and
project functional workstreams tend to have more effective and high-
er-velocity projects. A common model is for each key business stream to
be matched with a corresponding project workstream. An experienced
leader from the business stream is usually seconded to the project and
takes on the role of the lead subject matter expert (SME). For larger
projects, multiple SMEs may be appointed for a single workstream.
Fig.
8-3

The direct involvement of a busi-

ness stream with the project is
usually the most successful model
because it engenders trust both
ways—from the business to the
project and vice versa. If you have
multiple organizational steps
between the business and the
project team SMEs, the level of
business ownership of the solution
design diminishes, as well as the
quality of the input from the SMEs.

Does the project organization

include active and appropriate
senior business stakeholders?
Projects are far more successful

Implementation Guide: Success by Design: Project governance 159

 when senior business stakeholders have clear roles and are active and
deeply engaged in driving the project. A good sign for the project is
when the senior stakeholders are keenly interested in the status of
critical processes and are making a direct impact on the prioritization of
tasks and making the corresponding resources available.

Projects in which the senior stakeholders are more passive and just
occasionally asking “How is it going?” or “Let me know if you need
something” tend to have poor outcomes.

Does the structure promote cross-team collaboration?

Examine if the project organization structure, reporting lines, team
leadership and composition, communication channels, team objectives,
and delivery approach naturally generate sufficient cross-team
collaboration, or if they naturally encourage silos.

Danger signs are project organization structures with the following:

▪ Team members performing the delivery work on the ground have
to navigate multiple layers of management to overcome issues
▪ Members of workstreams rarely work with other workstreams
▪ Responses to ad hoc questions on a team member’s task status
and issues are routed via the project manager—this also introduces
mistrust within the team
▪ Workstream communication channels are all hierarchical, with few
organic, cross-workstream objectives

A good way to determine the level of cross-stream collaboration

is, for example, to scrutinize how closely, and how often, the data
migration workstream works with the various functional and technical
workstreams’ design. How closely entwined are the ongoing delivery
objectives of the data migration team and those of the functional
team? Do they primarily communicate hierarchically or across to their
teammates in other areas?

Is accountability and authority well defined at the project

leadership level?
Projects where the wrong role is accountable for delivery or where
the accountability is diffuse tend to have low velocity, with project

Implementation Guide: Success by Design: Project governance 160

decisions stagnating. Projects where the accountability is given to
someone too junior in the organization to have the corresponding
authority may also languish without sufficient direction and resources.

How well are the team roles and responsibilities defined?

Every role on the project needs to be well defined, including roles that
may be part-time on the project. The critical role played by business
users that aren’t seconded to the project is often ill-defined. They
may typically be necessary for defining a detailed process or data
requirements, for approving business processes, or for preparing and
performing testing. These are critical activities, and the corresponding
roles should be well defined so the resources can be planned and their
tasks and status are visible to the project leadership.

How well are the team roles aligned to the solution complexity
and system design requirements?
You should conduct an honest analysis of the experience and ability
of the resources in key roles when compared to the complexity of the
design and its constraints. Be wary of job titles that don’t match the
experience and authority that normally accompany such titles.

This is particularly important for the key roles of lead solution architect,
lead technical architect, and project manager.

Are the levels of resources proportional to the level of

effort and complexity?
By the end of the Initiate phase of the project, you should have a reasonably
credible high-level solution blueprint, a reasonable estimate of the backlog
and effort, and a high-level project plan. This should provide a good
grounding for reviewing the level of resources planned for the key roles.

This honest review is especially recommended for the roles that are
likely to be the most constrained, so that mitigation plans can be
initiated in a timely manner.

During the implementation, you should regularly assess how the day-
to-day working of the control, communication, and feedback functions
are being helped or hindered by the project team organization

161
 (Figure 8-4). How well does the project organization structure facilitate
or constrict the undiluted and timely flow of direction, guidance, and
decisions from the business to the project workstreams? In the other
direction, does the structure enable or hinder the flow of accurate,
actionable, and timely feedback from the workstreams to the project
leadership and business stakeholders?

A typical setback on projects is the leadership team not receiving timely

and accurate feedback on project issues, therefore adding unnecessary
cost and delays. This is often due to structural issues created by a project
organization that doesn’t help the flow of meaningful information.
Projects with a lot of hierarchical communication and reporting-line
hoops to clear (especially on large projects) tend to have difficulties in
surfacing accurate data promptly. This can result in project challenges
stagnating for too long, which leads to delays and additional cost.

Many projects start with the ambition of some model of partnership

and shared leadership with the various parties involved. The projects
that better achieve this ambition are the ones that meaningfully
map the commercial and partnership arrangements (or expectations
if informally agreed) and their respective expertise to the project
organization. Projects tend to have better success when the custom-
er has a clear leadership (and ownership) role in the organization
Fig. structure driving the overall proj-
8-4
ect. Similarly, unless the customer
Accurate, honest, has experience and capability in
timely status: implementing business applica-
Progress, risks, tions, having the implementation
opportunities, blockers
partner in a leadership (and
accountability) role for provid-
Workstreams ing strategic guidance on the
implementation methodologies,
Project
system design, and technical
leadership
procedures allows for the best
Based on a close mapping of leadership roles to
understanding of
those with the best experience. Of
the project:
course, depending on the specific
Goals, direction,
decisions, resources expertise between the customer

Implementation Guide: Success by Design: Project governance 162

 and partners, the actual balance of responsibility lies somewhere in
the spectrum of these arrangements, and the organization structure
should be mapped to that agreement.

In business application projects, some critical project roles have a

disproportionate impact on the success of a business application
project. For most projects, the role of the solution architects and the
project manager is particularly critical to success. The project manager
and solution architect roles are important both from the implementa-
tion partner and from the customer; the customer solution architect
is usually described as the lead business SME or the business lead.
Depending on which areas of your project are particularly significant or
risky, you may want to add other roles to the list of the critical project
roles. You should then pay extra attention to ensure that the individ-
uals chosen for these critical roles have the right level of experience
and capability. For example, an ineffective solution architect may not
be able to direct the solution design blueprint such that the different
elements of the solution design come together into a coherent and
efficient solution that matches the business needs.

You should also confirm that the project organization allows all roles to
be successful by enabling them to properly assert their expertise and
strongly influence the design and implementation, thereby delivering
the full positive impact of their roles.

Project approach
Project goals When talking about project approach, one of the dangers is that it
can be assumed to be synonymous with the project implementation
Project organization methodology. This can then leave a vacuum in the processes that need
to be defined outside of the implementation methodology. This can
Project approach be especially true if the implementation partner is providing a limited,
technical implementation methodology. If you’re the customer, you
Classic structures
should consider the wider set of processes required to define your
Key project areas project scope, manage your resources, and manage the changes,
tasks, and processes. Prioritize areas that aren’t directly covered by the
Project plan partner but are necessary for every business to perform in support of

Implementation Guide: Success by Design: Project governance 163

 a business application implementation. You should explicitly identify
areas that would be the responsibility of the customer to manage.
Then confirm that you have adequate definition of the approach and
the right level of governance planned for each of these areas.

The areas excluded from the implementation partner’s responsibility

will vary, but the following areas are typically involved:
▪ Defining the scope of the project (the to-be business process and
system requirements)
▪ Managing internal project resources and liaising with wider
business teams
▪ Managing the process for the proper participation of all the
relevant business units and roles
▪ Managing the source data quality for data migration
▪ Training the internal project team and the end users
▪ Data, system, and process validation by the non-project business
users, such as user acceptance testing (UAT)
▪ Security and access definition and validation
▪ Implications on the wider IT enterprise architecture and wider
business processes
▪ Interpreting, applying, and validating the requirements related to
relevant regulatory bodies
▪ Cutover management
▪ Managing the non-Dynamics 365 systems involved in system
integrations
▪ Managing communication within the business and with customers
and suppliers
▪ Budget management
▪ Business and organizational change management
▪ Non-functional requirements such as performance management,
system security, and business continuity planning
▪ Transitioning and operating the support model and other post-
operational duties

This is not intended as an exhaustive list, more of an indicator that

the overall project approach needs to consider a much wider set of
functions than what may be covered by a typical implementation
methodology or a commercial contract. Some projects define the

Implementation Guide: Success by Design: Project governance 164

 overall approach in a project charter or similar document. You should
examine if the project approach adequately covers the missing areas
from the implementation methodology.

One of the discussions that regularly occurs about project approach is

the debate on waterfall versus agile. Methodologies based on either
of these principles have their advantages and disadvantages. For more
detailed discussion on implementation methodologies, refer to “Chapter
5, “Implementation strategy.” From a project approach perspective,
whichever methodology (or hybrid) is adopted, it’s important to identify
and record the specific risks that logically emerge from that methodolo-
gy and have a mitigation plan for each one.

For example, if your chosen methodology doesn’t include early anal-

ysis and defining a solution blueprint that reflects the whole design
scope, the project may stumble from designing specific solutions from
sprint to sprint. You may find that the designs in later sprints can’t be
built upon the previous sprints due to the constraints of not having
analyzed and considered the high-level design for the whole end-to-
end process. We often see this in pure agile projects.

Similarly, if the chosen methodology is strictly linear and mostly

document-based, you risk spending an enormous amount of time and
effort in analysis, design, and coding phases with little exposure to the
working solution and limited feedback on how the solution performs
in the system. This is a risk we see in many pure waterfall projects. You
need to identify such risks in your chosen methodology so you can
discuss, accept, understand, and specifically address them in the
project approach.

Sometimes when a methodology is being selected, there is an

assumption that a methodology that works well for a bespoke
software development project will apply with minimum changes
to a highly configurable Dynamics 365 cloud-based business ap-
plication implementation. Similarly, methodologies that suited the
old world of on-premises business application implementation
with long implementation durations aren’t best adapted to today’s
more rapidly evolving cloud world. Consider the very different

Implementation Guide: Success by Design: Project governance 165

circumstances of a modern, cloud-based Dynamics 365 business appli-
cation implementation:
▪ The implementation is for a cloud-based, packaged SaaS
software application
▪ A significant (if not a majority) of the activities aren’t coding, but
business process design, setup, configuration, data migration,
validation, and more
▪ Some critical activities for a Dynamics 365 application implementation
(such as extracting a fit gap report from a fit-to-standard analysis)
aren’t covered by more generic software development implemen-
tation methodologies
▪ There is ever-increasing functionality in the Dynamics 365 busi-
ness application of powerful configuration options or low-code/
no-code options and the ability to use the Dynamics 365 Power
Platform in citizen-developer and professional developer modes
▪ The methodology must address the fact that a very significant part
of the implementation process revolves around the understanding
and configuration of business processes and working closely with
business users throughout the project lifecycle
▪ Although Dynamics 365 applications provide a platform for custom
development, the chosen methodology must address the fact that
the development process is building on, or extending, the standard
business process flows designed in the system
▪ Dynamics 365 applications are a cloud-based, SaaS business appli-
cation with a regular update rhythm that needs to be recognized
as part of the new way of working

All of these factors (and more) mean that the implementation

methodology needs to be directly relevant to the nature and needs of
a Dynamics 365 business application project.

When looking to determine what the overall project approach should

address, consider the specifics of your whole project solution build life-
cycle and make any additions, adjustments, or highlights to the standard
methodology. Confirm that the key processes and controls you expect
are adequately addressed as part of the governance of the project:
▪ Does the methodology and approach enable a good definition of
the scope and a solution blueprint?

166
 ▪ Is the testing strategy fit for purpose?
▪ Do controls such as regular and appropriate reviews by the project
team and the business exist?
▪ Is a good process for project status analysis and reporting in place?

You may want to define a set of critical processes, deliverables, and

controls to ensure you have the right coverage from the project ap-
proach ( just as you would for functional and technical requirements).

Once you are in project implementation mode, and the focus is on

day-to-day tasks, it’s easy to lose sight of the ideals agreed in the gov-
ernance model at the start of the project. You should establish regular
checkpoints to go through the formal discipline of honestly comparing
the actual ways of working on the project with the governance model
and taking corrective actions as necessary.

For example, analyze a random sample of how a given feature, require-

ment, or user story is actually progressed through the lifecycle, or take
a scope change item and trace how it was handled to resolution. Did
they progress through their lifecycle as you expected, and did your
governance model help deliver a fast and quality result? Taking a (pref-
erably independent) regular pulse of the real, practical implementation
of the processes and controls helps keep the project approach relevant
and reduces risk.

Classic structures
Project goals Most, if not all, business application projects have the common, classic
governance structures in place. This section doesn’t give a general
Project organization overview of historically well-known disciplines around these common
governance areas; instead we look at how to assess the true effective-
Project approach
ness of these processes and controls in practice. The mere presence of
these classic governance structures such as steering groups, program
Classic structures
boards, or risk registers can sometimes lull projects into thinking that
Key project areas they have adequate active governance. Let’s dig deeper into these
areas to explore how we can get better insight into their function and
Project plan evaluate their effectiveness.

Implementation Guide: Success by Design: Project governance 167

 Steering groups
Most projects have some form of steering group in which the project
sponsor, senior business stakeholders, and project leaders meet regularly
to discuss and review the project. A lesson learned from participating
in multiple such steering groups across multiple projects is that the
effectiveness of these meetings varies hugely. Common factors that can
impact the effectiveness of a steering group are when the purpose of
steering group meetings is diluted or unclear, and when project status
reporting isn’t easily understood, accurate, or actionable (Figure 8-5).

Steering group meetings

Steering group meetings can negatively influence project success if the
project manager presents the status and the steering group is simply
checking in with very little understanding of the details of the project,
no direct engagement, and a lack of knowledge to challenge and ex-
plore issues more deeply. Projects that are considered able to manage
themselves despite some issues are often surprised by a sudden crisis,
resulting in delays and dissatisfaction.

An efficient and effective steering group has leadership team partici-

pants that understand and perform their primary function of steering
the project. This requires them to invest the time to understand the con-
Fig. tent of the project at a sufficient depth so that they can read between
8-5
the lines of the project status report, ask the right questions to
understand how and where they
can help, and proactively direct
the project.

Apply similar, regular assessments

of the effectiveness of other such
boards, like the change control
board or the design authority
board.

Project status reporting

Accurate, meaningful, and action-
able project status identification

Implementation Guide: Success by Design: Project governance 168

 and reporting is the lifeblood of a project. Business application imple-
mentations often involve complex, multiple strands of work, all of which
need to come together seamlessly and on time. Multiple parties are often
involved in the project delivery—business SMEs, business IT, business
project managers, and their equivalent roles from the implementation
partner, as well as other third parties. In addition to the main func-
tional and technical delivery, there are multiple other disciplines, like
data migration and security. All these roles have their own specialist tasks
to perform, and managing and monitoring all these different types of
tasks to provide a coherent project status isn’t easy.

Additionally, specialist teams may provide an overly technical view of

the status in terms that only that team understands. Often, project-lev-
el status reporting is driven by fit gap progress, which isn’t necessarily
the critical part of the project. Consider the following when looking for
effective project status reporting to the steering group:

Is the project status meaningful and actionable for

the intended audience?
For example, when presenting internally to your own specialist team, a
detailed and technical view is very appropriate; however, when presenting
the status to a steering group or to non-project team members, consider
how to express the status in terms that are understood and actionable.

Is there evidence to believe that the project status is accurate?

Consider how the project status data has been gathered, analyzed, sum-
marized, and presented. Understand the level of uncertainty associated
with the data. Is there a history of the project status data and related es-
timates versus actuals that can provide some idea of certainty? Steering
groups have to consider the degree of uncertainty associated with the
status when assessing risks and making critical decisions on moving or
adding resources, approving budgets, and setting timelines. This means
testing the accuracy of the status by looking at it from multiple angles to
ensure that it provides robust and actionable data.

Is there a comparison between the planned and actual status?

Project status reports only have meaning when they show an easily
understood comparison between the planned status and the actual
progress—the report must be able to answer questions like “Are we

Implementation Guide: Success by Design: Project governance 169

 on track?” “What is the size of the remaining work to completion?”
“What do we, as the steering group, need to do to get the project on
track and keep it on track?” The absence of comparing planned work
to actual and remaining work doesn’t allow the steering group to take
necessary actions to help recover.

Risk register
Most projects have some form of a risk register. When used well, this
register is a good way to communicate risks and help teams focus their
attention on removing barriers to success. The following are examples
of ineffective use of risk registers:
▪ Risks that are of little practical value to the project are being used
to shrug responsibility or provide cover against blame.
▪ Risks remain on the register for a long time with just new comments
and updates being added weekly at each risk review meeting, but
with no resolution. This implies that either the risk isn’t getting the
attention it deserves or it’s difficult to resolve and consuming more
and more resources without results. In any case, you should either
treat risks stuck in this loop urgently with focus or accept them with
a mitigation so they don’t drain the project over time.
▪ Risk priorities don’t reflect the project priority at that stage of
the project. You should take care to ensure that the risk register
doesn’t create a parallel project effort with its own priority and
path. Risks and issue resolution should be incorporated as part of
the main project delivery.
▪ The risk register has a very large number of risks, many of which
are stagnant. Consider how many risks the project can realistically
work on at any given time and trim the register according to real
project priority.

Stage gates
Stage gates or milestone-driven planning and reviews are a common
feature of the majority of business application projects, including more
agile projects. These milestones are regarded as important checkpoints
spread throughout the project timeline, which the project can only
pass through if they have met certain criteria. The reality of many

Implementation Guide: Success by Design: Project governance 170

 projects is that the checkpoints don’t always perform their intended
function. There may be several reasons for this, and projects should
examine if they are suffering from the following limitations:
▪ Criteria for the milestone are unclear  You should strive to
create very explicit criteria for entering and exiting a milestone. If
the criteria are difficult to measure, it’s difficult to take unequivocal
decisions based on data.
▪ Exit and entry criteria aren’t respected  Projects are typically
under great pressure to get past one milestone and move into the
next phase, either because of resource usability or commercial
payment triggers, or because the project optimistically believes
that it will somehow catch up with the stragglers that didn’t meet
the milestone criteria. Sometimes a project is also pressured to
move to the next phase because it implies progress. This self-de-
lusion can create additional risks in the project; uncontrolled
disturbances in project deliverables can delay the ultimate goal of
a successful go live. The debt incurred by skipping the criteria has
to be paid back at some point—the later it’s resolved, the higher
the cost. When considering allowing a milestone to pass when it
hasn’t met all its criteria, project leadership should strongly consid-
er the nature and size of the incomplete tasks, precisely how these
tasks will be addressed, what impact the lagging tasks will have on
A milestone dependent tasks. This allows for a managed transition between
should have the milestones with the risks fully understood and a clear and realistic

primary purpose action plan for the stragglers.

▪ Milestones don’t reflect true dependency  From a project
of confirming lifecycle perspective, a milestone should have the primary purpose
that the project of confirming that the project has satisfactorily completed the
has satisfactorily precursor tasks so that it’s safe, efficient, and meaningful to start

completed the the tasks of the next stage. There may be other perspectives, such
as commercial ones to trigger stage payments or just periodic
precursor tasks points for the project to review progress or cost burndown, but
so that it’s safe, we’re focusing on a project lifecycle point of view. Some common
efficient, and examples of stage gate criteria are as follows:
▪ To-be business processes defined  An approval step from the
meaningful to start business to confirm the business process scope helps ensure that
the tasks of the prior to spending a lot of effort on detailed requirements and de-
next stage. sign, the process scope has been well established and agreed upon.

171
 ▪ Solution blueprint defined  This helps ensure that the require-
ments have been analyzed and understood sufficiently well to be able
to define an overall, high-level design that is confirmed as feasible.
Additionally, the key design interrelationships and dependencies are
established before working on the individual detailed designs.
▪ Formal user acceptance testing start agreed  Starting formal
UAT with business users tends to be the final, full formal test phase
before go live, with the expectation that go live is imminent and achiev-
able. Prior to starting this phase, it makes sense to validate the readiness
of all the elements to ensure that this test phase can complete within
the allocated time period and meet the necessary quality bar.

Consider the various milestones that help with a true understanding of

readiness, especially those that help you better understand when to start
dependent tasks, such as feature complete, code complete, code frozen,
business data validated in Dynamics 365, or solution ready for user ac-
ceptance testing, and determine what entry and exit criteria would help.

Design and change boards

A project with multiple parties involved in the design and delivery tend
to have some form of design review board that ensures compliance
with the enterprise IT policies and standards. This board also ensures
that the proposed designs from the project (and especially design
changes) are fit for purpose.

Effective design review boards (also called architecture review

boards or design change boards) tend to have a good grasp of the
overall solution blueprint. In addition to reviewing any individual
design, they can ensure new designs and changes will operate
within the boundaries of the solution blueprint and won’t adversely
affect other designs.

The design review board should also have representatives, not just
from the project, but also from the wider business and IT, to help
ensure the business case for the design is sound and the impact on
related systems (integrations) and overall enterprise architecture are
considered. Another characteristic of a successful design review board

Implementation Guide: Success by Design: Project governance 172

 is that they have minimum bureaucracy and their focus is on helping
the project to move as securely and as fast as possible.

The process by which a design review board actually functions is as

important as its constituents and roles and responsibilities. Design
review boards should communicate the solution blueprint boundaries
and design standards expected so projects can proactively make sure
that they’re working within the expectations.

For the best project velocity, you should set an expectation that the
reviews will be interactive and expected to be resolved within a single
iteration. This requires the design review board to be pragmatic and well
prepared. It also requires the project to have the discipline to provide
sufficiently detailed proposed design information. This process needs to
be organized and communicated as part of the project governance in
the Initiate phase so you’re not trying to establish these practices during
the intensive pressures of a running project implementation.

Key project areas

Project governance is often thought to be confined to the classic areas
Project goals we discussed in the previous section, but in Dynamics 365 business
applications, we should consider the key activities that also need to
Project organization have governance processes embedded. We see many projects where the
strategies for the more specialist project delivery areas have their own
Project approach
processes and disciplines that don’t always work in concert with the
project approach or to the benefit of the overall project. These areas are
Classic structures
often managed and driven by specialists with specialist processes and
Key project areas internal goals.

Project plan It’s worth considering what governance is appropriate for these areas to
ensure the project (and hence the business) derives the best value. In this
section, we discuss the key areas of application lifecycle management
(ALM), test strategies, data migration, integration, cutover, and training
strategies (Figure 8-6).

Implementation Guide: Success by Design: Project governance 173

 Fig.
8-6 Application lifecycle
management
Does the defined application
lifecycle match the project
methodology? For example,
how will the configuration data
be analyzed, defined, approved,
secured, managed, and distribut-
ed to the different environments?
Is this process also governed by
the requirements of the project
approach, and will it be designed
to meet the expectations of the
project timetable? The risks here
are that ALM processes are some-
times considered as a technical
topic and not rolled into the
overall project governance, which creates mismatched delivery and
project planning.

The build process (configuration, data, code) in a business application

can be presented as a complex, technical, and jargon-filled process.
Business stakeholders may retreat and let specialists take complete
oversight. However, project leadership can get meaningful insight into
the (necessarily technical) build process by devising a layer of gover-
nance that provides the necessary understanding and helps keep the
project on track. For example, ask the following questions:
▪ Are the build requirements directly mapped onto the end-to-end
business processes, so that any discussions related to the require-
ment can be well understood in that context by non-technical
stakeholders?
▪ Are the right controls in place so that progress can be tracked and
reported in a way that is meaningful outside of the technical teams?
▪ Do controls exist to ensure the right quality, standards, and
compliance needs will be applied?
▪ Does the project have a practical and efficient method to raise

Implementation Guide: Success by Design: Project governance 174

 business process questions with the business area owners, and
a way for the business to understand the system delivery of a
business process?

A more in-depth exploration of the ALM and build process is available

in Chapter 11, “Application lifecycle management.”

Test strategy
A well-defined test strategy is a key enabler for project success. A high
level of governance is required to ensure that the right test strategy is
created and implemented, because multiple cross-workstream parties,
business departments, IT departments, and disciplines are involved.
When evaluating the suitability of the test strategy, in addition to the
technical angles, consider how well some governance areas are covered:
▪ Does the right level of governance exist to ensure that the testing
strategy is mapped to, and proportionate with, the project scope
and the business risks?
▪ Is the business sufficiently involved in the test coverage, test case
development, and approval of the testing outcomes?
▪ Is the project approach in line with the test strategy and test planning?
▪ Does the right governance exist to make sure the business pro-
cesses are tested end to end?
▪ Is the data to be used in the various testing phases and test types
sufficiently representative to fulfill the test objectives?
▪ Is the test coverage across the functional and non-functional areas
adequate to help assure the business of safe and efficient opera-
tion in production use?

More details on defining a successful test strategy are in Chapter 14,

“Testing strategy.”

Data migration
For data migration, examine the related governance coverage to
ensure that this process is well understood at a business level:
▪ Do you have the right level of business ownership and oversight
on the types and quality of data being selected for migration?

Implementation Guide: Success by Design: Project governance 175

 ▪ Is a data stewardship process in place to make sure that the
cleansed and migrated data is kept clean during the project and in
operational use?
▪ Will the data from the existing source systems be faithfully
transformed so that it’s still meaningful and fit for purpose in
Dynamics 365?

Review the data migration strategy from a governance view to ensure

the workstream is delivering to the needs of the project and the busi-
ness and isn’t becoming a silo with only technical oversight.

Integration
A common area missing governance is the management and own-
ership of non-Dynamics 365 systems involved in the integrations,
because they tend to be managed by those outside of the project.

The cutover from the Make sure that the business impact on either side of the integration is
understood and managed. Confirm that the data exchange contracts
previous system to are defined with the business needs in mind. Examine if the security
the new Dynamics and technology implications for the non-Dynamics 365 systems are
365 system is a time- properly accounted for.

critical and multi-

You also need project-level governance on the definition and manage-
faceted process. ment of non-functional requirements, such as expected volumes and
performance, and clear processes to resolve issues that may stem from
the other systems in the integration.

Cutover
The cutover from the previous system to the new Dynamics 365 system
is a time-critical and multi-faceted process. It requires coordination
from multiple teams for the related tasks to all come together for a go
live. You almost certainly need to include business teams that aren’t
directly part of the project. Therefore, cutover needs to be shepherd-
ed with a deep understanding of the impact on the wider business.
Preparation for the cutover needs to start early in the project, and the
governance layer ensures that the cutover is a business-driven process
and not a purely technical data migration process. For example, early

Implementation Guide: Success by Design: Project governance 176

definition and agreement on the related business calendar sets the
right milestones for the data migration to work with.

The legacy systems shutdown window for the final cutover is typically
short, perhaps over a weekend. For some cutover migrations, that window
may be too short to complete all the cutover activities, including data
migration. In such cases, the project team may perform the data migration
as a staggered, incremental migration, starting with slow-moving primary
data and frozen transactional data. This leaves a smaller, more man-
ageable remainder to address during the shutdown. This needs careful
governance, and the strategy needs to be decided early because the data
migration engine needs to be able to deliver incremental data loads. You
should also carefully consider what business activities you may need to
throttle or perform differently to reduce the number and complexity of
changes between the first migration and the final cutover. The changes
need to be meticulously recorded and registered (automatically or
manually) so that they can be reflected in the final cutover.

Training strategy
Most projects have plans to train at least the project team members
and business users. All too often though, training is seen as a lower pri-
ority. If any project delays put pressure on timelines or budget, training
can be one of the first areas to be compromised.

This trade-off between respecting the go live date and completing the
full training plan can be easier for the implementation team to rational-
ize because the team is aiming for a go live and the risk of poor training
can be seen (without sufficient evidence) as manageable. The worst
consequences of poor user training are felt in the operational phase.

You can mitigate this (mostly unintentionally) unbalanced trade-off

with the following actions:
▪ Clearly defining and communicating the implications on project
success in operational use of poor training delivery.
▪ Making the review and approval from the business reflect people readi-
ness. This check should be part of the entry criteria into user acceptance
testing and be a meaningful part of the go/no go for production use.

177
 The test for people readiness needs to be meaningful; it should be an
evaluation of the effectiveness of the training, and not just that it was
made available. The test should be equivalent to assessing whether
enough people in key roles can conduct their critical day-to-day busi-
ness process safely and efficiently using the Dynamics 365 application
and related systems.

More details on how to put together a good training strategy are in

Chapter 19, “Training strategy.”

Project plan
Project goals Project plan analysis is where the outcomes of a lot of governance top-
ics become visible. The effects of good governance are felt on a project
Project organization by noting that the project plan is resilient to the smaller changes and
unknowns that are a reality for all business application projects. Poor
Project approach
governance, on the other hand, manifests itself as continuously missed
targets, unreliable delivery, and repeated re-baselining (pushing back) of
Classic structures
the project plan milestones. The key is for the project planning process
Key project areas to have its own governance mechanisms to avoid poor practices, detect
them early, and provide the agility and insights to fix and adjust quickly.
Project plan
When determining how the project plan should be constructed, the
project plan should be able to demonstrate the following:

Is the project plan designed to cover all the critical areas?

Does the plan cover (at least at a milestone level) all the key areas of
activity? If not, key dependencies and effort will be missed.

Is the project plan actionable?

A project plan should be able to fulfil one if its primary purposes of di-
recting a project. If that isn’t the reality on the project, you should look
at how to restructure it so that it’s the main driver of project activity at
least at the milestone level.

If a plan is thousands of lines long, it’s unlikely to be directly actionable,

and will probably be in a state of continuous update and adjustment.

Implementation Guide: Success by Design: Project governance 178

 Similarly, if the project workstreams aren’t paying any attention to
the plan, it’s a clear sign that the project plan may not be actionable.
Actionable project plans help direct the project teams to deliver the
right activity at the right time and reduce uncontrolled activities.

Projects using agile practices may be using some form of prioritized

backlog management for much of the build and test activities, but there is
normally still a high-level milestone plan to allow for the communication
and management of related tasks that aren’t covered by the backlog.

Whatever methodology is in place, the plan should be regularly evalu-

ated to confirm that the teams are taking their direction from the plan.

Is the project plan up to date, accurate, and realistic?

Compared with the traditional on-premises business application
projects of a few years ago, today’s cloud-based Dynamics 365 imple-
mentations tend to move faster with shorter durations. A project plan
that isn’t up to date is ineffective.

Projects should institute thresholds for how out of date a project plan
is allowed to become. A project plan that is inaccurate in terms of the
estimated effort (and remaining effort), duration, and dependencies
will promote the wrong decisions and allow risks to remain hidden, and
ultimately give an inaccurate picture of the project status.

For a project plan to remain accurate, it needs a robust task estimation

process and a reliable and easy means of tracking tasks in progress. Con­
sider how to make this possible structurally and with efficient processes.

Does the project plan give a clear indication of what tasks

are critical?
Business application projects have many moving parts and many spe-
cialist areas. The project must be able to accurately derive the critical
path so that project leadership can focus their attention on those tasks.
For agile projects, agile crews prioritizing the backlog and managing
the critical path within short-duration sprints and iterations can pro-
vide the necessary insight.

Implementation Guide: Success by Design: Project governance 179

 Accountability for outcomes
Project planning should promote the clear identification of account-
ability for the outcomes (both at the workstream level and overall).
Often, projects create a RACI (responsible, accountable, consulted,
informed) matrix at the start of the project, but this may not provide
the right level of accountability for all areas. Additionally, this matrix
isn’t always referenced during the project implementation. Asking the
question via the project plan if the accountability for the outcome (not
responsibility) is clear helps keep the accountability fresh in everyone’s
mind. It keeps the project more agile with faster decision-making.

Status reporting
A well-constructed project plan facilitates accurate project status
reporting. However, it needs to be deliberately designed into the
project plan with the right dependencies, estimated effort, and mile-
stones so it can be easily extracted from the plan. This means that the
project should be deliberate in the detail to which tasks are scheduled
so dependencies and milestones are created with this in mind. Because
status reporting often has milestone-level status as a key indicator, the
meaning of a milestone’s completion must be explicitly defined so the
implications are clear to the intended audience.

Project plans also need a regular and easy-to-use process to keep

task progress updated with an accurate status. You should also define
a uniform and reliable method for units of progress so you get the
same quality of updates from all teams. For example, tasks defined as
80 percent complete often under-estimate the effort to complete the
remaining 20 percent; instead, consider reporting the remaining effort
in hours for a given task.

Some projects, especially ones using more agile practices, may use
alternative or additional analysis and presentation methods such as a
backlog burndown, remaining cost to complete, or earned value, but
these principles apply nevertheless and they all rely on having accurate
underlying data on actual versus expected progress to date and the
remaining effort expected.

Implementation Guide: Success by Design: Project governance 180

 A useful way to report the status
of a business application project
is to present a functional heatmap
view (Figure 8-7), which shows

Fig.
the readiness of the key processes
8-7
for the next major milestone (such
as sprint review, SIT, UAT, or go
Business process heat map example live). The functional heatmap is a
business process perspective of
Legend
Process not complete Process complete, the project plan status.
and not on track in repair, or testing

Status reports can also include

Process design blocked Process solution in Process complete and
or not started progress and on track ready for next test cycle status from other project controls
such as risks and issues, sentiment
Finance surveys, or resource availability in
prior months. These aren’t directly

HR derived from a project plan and

can provide a useful supplemen-
tary view. However, it’s important
Operations
to ensure that actionable con-
clusions are extracted from these
Logistics
alternative views; these conclu-
sions should generate tasks that
can be measured, planned, allocat-
ed, and subsequently reflected at
Legend
Process not complete Process complete, some level in the project plan.
and not on track in repair, or testing

Process design blocked

or not started
Process solution in
progress and on track
Process complete and
ready for next test cycle
Project
feedback loop
Finance Project status should provide a
feedback loop to the project stake-
HR holders, project management,
and the project team to adjust the

Operations project based on the findings. This

should be a defined process in
the overall project governance to
Logistics
create the discipline to regularly

Implementation Guide: Success by Design: Project governance 181

 review the status and generate explicit actions for the project that
directly address the status findings.

The project status should not be the only source for this feedback loop—
consider all the other controls and procedures in the project that can
generate actionable information, if only there were a systematic mech-
anism defined to diligently listen and extract the actions. For example,
updates from daily stand-ups, design reviews, sprint playbacks, or even
informal risk discussions can help provide useful feedback.

In summary, create a culture from your governance processes that ac-

tively recognizes the feedback loop and translates feedback into actions.

Conclusion
The primary intention at the start of this chapter was to provide an
overview of the importance of good project governance and provide
guidance on how to assess the effectiveness of your existing or pro-
posed governance model.

We then moved on to describe how many of the critical issues on a

Dynamics 365 project that initially may manifest themselves as tech-
nical issues actually have their roots in failures of project governance.
We also saw that the governance requirements for a Dynamics 365
business application needs to address the fact that the project is es-
sentially delivering the capability to perform business processes using
the application. So the governance model must include strategies and
techniques that can help realize the project goals through the right
engagement with business users and business processes.

We discussed how defining a project organization model that has an

engaged leadership and facilitates rapid and accurate communication is
more aware of the reality of the project. Similarly, project organizations
that enable the right accountability, naturally encourage cross-
collaboration, and reflect the complexity and effort of the project are
much more likely to have good velocity and be successful.

Implementation Guide: Success by Design: Project governance 182

We also discussed how the approach is much more than a technical
methodology, and that the approach must be practical and tailored to
the specific needs of a Dynamics 365 business application and to the
customer’s project and business needs and constraints.

We showed that the mere presence of the usual governance structures

doesn’t assure project success. We can evaluate the effectiveness of
the governance model in very practical ways and with a focus on the
specific needs of Dynamics 365 projects.

We also brought awareness to how a governance perspective on the

specific technical implementation strategies (such as test and build
strategies) can help a Dynamics 365 project achieve better, faster
results. We proposed that governance should be an organic part of
the strategy. These strategies shouldn’t be considered as being purely
subject to technical oversight and control.

Lastly, we discussed how a good project plan and planning process

will expose the outcomes of a lot of these governance topics. Project
planning shouldn’t just be an overall status reporting tool, but be
deliberately engineered to gain early and deep insights into the
effectiveness of the different elements of the project work and allow
rapid responses to the deficiencies.

You can use the key objectives of good project governance to judge
the overall suitability of a given governance model. Ideally, you should
test a proposed governance model against these objectives during the
Initiate phase of the project and throughout, but it’s never too late.

In summary, project governance for Dynamics 365 projects should be

a framework that permeates all aspects of our projects, not just the
typical areas that were historically or conventionally regarded as the
domain of governance. Good project governance isn’t a set of
generalized bureaucratic or administrative procedures to follow—it’s
about creating a Dynamics 365-specific governance culture of driving
the project to reliably and efficiently deliver the project goals.

183
 Checklist

Project goals Identify relevant project roles and areas of ownership and
assign them to team members with the right expertise
Ensure goals are clear, realistic, mapped to actions and and experience.
measures, correctly translated into project deliverables,
and regularly monitored throughout the project lifecycle.
Project approach
Align goals and ensure they are sponsored by relevant
Analyze, review, and confirm that your chosen imple-
stakeholders across the organization, and properly com-
mentation methodology works well with the business
municated and understood by the implementation team.
and project constraints and circumstances.

Project organization Classic governance

structure
Establish an effective steering group that understands
Align business streams with functional workstreams
enough of the project details to actively steer the project
for better efficiency and structure, and make sure the
based on meaningful, actionable, and evidence-based
business stream is directly involved in the project.
information.
Secure a strong executive sponsorship and active
Create a risk register with meaningful and actionable risks
engagement from senior business stakeholders within
that align with project priorities and are actively addressed.
each business stream.
Implement stage gate or milestone-driven planning and
Ensure cross-team collaboration in which members of
reviews as checkpoints to better track and communicate
each workstream are involved in other workstreams to
implications of the project status.
avoid working in silos.
Implement design review boards to ensure new designs
Plan and budget the project resources in proportion to
and changes operate within the boundaries of the
the effort and complexity of the project.
solution blueprint and don’t adversely affect
Define accountability and responsibility at the project other designs.
leadership level. Each stream identifies an owner with
autonomy who is empowered to make decisions.

Implementation Guide: Success by Design: Project governance 184

 Case study
Project governance as a
critical success factor
A large enterprise that was using legacy home-grown applications for
managing their sales and customer service business processes decided
to embark on a new cloud application, Dynamics 365. This was a mis-
sion-critical and complex implementation for this company; it would
affect their key business of providing customer service to their large
enterprise customers, and was the first cloud deployment within a
traditional IT managed landscape. The plan was to release a minimum
viable product (MVP) within a timeline of six months and follow a
phased approach for their users to adopt the new solution smoothly
and without too many challenges.

Although the implementation team ensured that the scope was

aligned with business priorities and clear project goals were agreed
upon, no clear processes were defined for the following key aspects of
the project:
▪ Realistic timelines for the activities planned within the engagement
▪ Understanding of technical and business complexity
▪ Well-defined project organization structure
▪ Assignment of adequate and qualified resources
▪ Effective project updates for the steering group
▪ Full understanding of the product’s out-of-the-box capabilities,
thereby avoiding unachievable product requirements

Implementation Guide: Success by Design: Project governance 185

 As the project began, complexities surfaced early in the cycle. However,
the team didn’t revisit and realign their activities. This resulted in the
following impacts:
▪ Poor quality of deliverables
▪ Mismatch in customer versus partner understanding of requirements
▪ High number of defects identified during initial testing cycles
▪ Incomplete implementation of requirements due to lack of skilled
resources on the project
▪ A continuously shifting end date for final go live, resulting in a
delay of 6–8 months
▪ A complete lack of trust between the customer and partner

After several discussions between customer and partner stakeholders

and a high impact on cost and morale, the team agreed to clearly de-
fine a project organization structure and an approach to continuously
monitor and manage the overall project. The following activities were
incorporated as project governance processes were defined:
▪ Considering the new technology, training needs for both the custom-
er’s business and IT teams were identified so they could understand
both the SaaS world and Dynamics 365 product capabilities.
▪ An architecture board was established that was responsible for
diligently reviewing architectural decisions coupled with the gap
analysis. For any gaps identified, this board provided input to
the change control board to ensure that a change management
approach was followed without any further impact on timelines.
▪ Both industry and product architects were assigned to the project
to avoid any further lack of domain understanding and perform a
clear fit gap analysis.
▪ The steering committee was empowered by the customer’s senior
management to take the relevant and necessary decisions through
the project.
▪ A key challenge that impacted the deliverable quality was that
several activities were planned almost parallel to each other and
were to be done by the same project team. As part of the project
reorganization, activities such as performance testing and vulner-
abilities testing were outsourced. This allowed the existing team to
stay focused on their core functional scope.

Implementation Guide: Success by Design: Project governance 186

 As the project team implemented these various controls and processes,
they were able to redefine their project timelines and have now gone
live within that timeline. This has led them to ensure that they can
apply and tailor these learnings to other projects to avoid similar high-
cost impacts.
As illustrated by this and other case
studies, project governance is the most In conclusion, project governance must not be thought of as an af-
critical factor that entails all the key
elements to make a project successful. terthought. It must be set up from the beginning to work as a flexible
backbone for the entire project.

Implementation Guide: Success by Design: Project governance 187

9 Guide
Environment
strategy
Implementation Guide: Success by Design: Environment strategy 188
It all starts with the foundation.

Introduction
Defining your environment strategy is one of the
most important steps in the implementation of your
business application.
Environment-related decisions affect every aspect of the application, from
application lifecycle management (ALM) to deployment and compliance.

At a fundamental level, a good environment strategy is about obtaining

the right balance with multiple layers of compliance and security,
productivity, collaboration, isolation, performance, and maintainability.
A strategy to manage environment provisioning and access—and
controlling resources within them—is key to:
▪ Securing data and resource access
▪ Organizing and structuring solution components
▪ Governing and managing capacity

In this chapter, we explore several deployment and transition scenarios.

By the end of this chapter, you should understand the factors to consider
when defining your environment strategy, and the available patterns
that will enable you to confidently deliver an environment plan for
your applications.

Implementation Guide: Success by Design: Environment strategy 189

 Environment strategy
Environments are containers that store, manage, and share your organiza-
tion’s data. They also store the data model, application metadata, process
definitions, and the security constructs to control access to data and apps.

A successful environment strategy defines the core principles and

policies for creating, granting access to, and decommissioning
environments of different types, along with the necessary governance
process. These policies should provide a consistent approach for
centrally deployed, IT-driven implementations and for citizen-
developed applications for individuals or small business teams.

A data strategy is likely to inform or impose constraints on an environ-

ment strategy. For example, an organization could build a unified data
platform that different apps and services consume, or there could be a
fragmented legacy data estate that must be accounted for in the cloud
environment strategy. Chapter 10, “Data management,” delves into the
patterns and scenarios that are relevant to environment planning.

It should be apparent from the sidebar questions that environment

To get started with creating strategy is not the responsibility of a single person or team. It can
an environment strategy,
involve IT admins, the architects responsible for the design and imple-
ask the following questions:
mentation of the solution, the information security and compliance
• Where are my users physically located?
teams, and the business stakeholders.
• What are my organization’s data com-
pliance and residency requirements?

• What types of environments are re- Environment-related decisions are hard and expensive to change. As
quired, and when?
we explain throughout this chapter, environment strategy can affect
• What are the different roles (such as
developers, testers, admins, business how solutions are implemented. This exercise needs to be done at the
analysts and trainers), and which envi-
ronments do they need access to?
start of the project—even before beginning implementation—and is
• What’s the access procedure for not something that should be left to the end as a part of a go-live plan.
an environment?

Tenant strategy
• Which apps will be installed in
the environment?

• Will the solution require more than one

production environment?

• Which services and third-party applica- Understanding tenants is fundamental to defining an environment
tions do I need to integrate with? strategy for your deployment. A tenant is a logical structure that rep-
resents your organization. Every cloud service to which an organization

Implementation Guide: Success by Design: Environment strategy 190

Fig. subscribes will be associated with the customer’s
9-1
tenant. A tenant is not dedicated to a specific ser-
Services vice; it has subscriptions for Microsoft services, such
Dynamics 365 as Exchange, Dynamics 365, Power BI, and Azure.
Every tenant is given a Microsoft domain—such as
Microsoft 365
Tenants yourorganization.onmicrosoft.com—but admins can
Azure microsoft.onmicrosoft.com
also associate their own custom domains with the
tenant. For example, as shown in Figure 9-1, contoso.
yourorganization.onmicrosoft.com onmicrosoft.com can be associated with contoso.
com and other domains owned by the organization.
contoso.onmicrosoft.com
You can also federate access to your tenant via your
organization’s on-premises Azure Active Directory (Azure AD) to enable
single sign-on (SSO) across on-premises and cloud services.

A tenant provides the highest level of isolation for a cloud service,

as it represents an organization and differentiates one customer
from another. Tenants never share resources or licenses because
they’re meant to represent an organization and not a department
or business unit. (In some cases, subsidiaries could share a tenant
with the parent organization, depending on the organization
structure, and the tenant model might mirror that structure.)

Isolation approaches also may differ between services. For example,

as shown in Figure 9-2, you could have different subscriptions in
Azure within the same tenant—and each subscription could host
different applications and have a different set of users—because
Dynamics 365 and the Microsoft Power Platform have environments
that isolate data and manage user access.
Fig.
9-2

Test
Operations
environment
Dynamics 365
and Power Platform
Production
Tenant Sales app
environment

[email protected]

SharePoint
Microsoft 365 SharePoint
site

Azure Subscription Web roles

191
 Your environment strategy should provide a balanced level of isolation
to meet the security and compliance needs of your organization. It also
should take into consideration the administration, ALM, and collabo-
ration needs of the project. To define the right tenant and environment
strategy for your organization, it’s necessary to understand the con-
trols that are available for each service to isolate code, configuration,
data, and users. It’s also important to note that the isolation provided
Fig. by services doesn’t necessarily reflect the underlying infrastructure or
9-3
design of a cloud service. A separate tenant doesn’t mean it’s a sepa-
Global single rate server farm—and having a separate environment doesn’t give you
a different front end.
tenant vs. global
multitenant setup Global single-tenant setup
Global single tenant Using a single Microsoft tenant to represent the organization in
the Microsoft cloud (Figure 9-3) is a common setup. It provides
unified administration for user access and licenses, enables seam-
Product
less integration between services, and lets the organization share
tenant resources.
Account Contact Addresses
All Dynamics 365 and Power Platform environments will be a part of
the same tenant. There could be different apps deployed in different
environments, or they could have different users for each app and
Global multitenant
environment, but all would belong to the same Azure AD that is
associated at the tenant level. Using the Multi-Geo setup, you could
Product #1
create environments in different countries or regions to meet your
compliance and application needs, but they would remain a part of the
Account Contact Addresses same organization-wide tenant. Sovereign cloud deployment requires
a separate Azure AD and might have additional regulatory restrictions
Product #2 that limit your ability to create environments in different countries
or regions.

Account Contact Addresses

Let’s examine some of the pros and cons for a global single-tenant setup.

Product #3 Pros of a global single-tenant setup:

▪ It aligns to the concept of tenant and the way cloud products
are licensed.
Account Contact Addresses
▪ It allows sharing of licenses and quotas across the tenant per
service. (Microsoft Dataverse storage is one such example.)

Implementation Guide: Success by Design: Environment strategy 192

 ▪ It provides a central place for IT admins to manage the services,
users, and licenses.
▪ It is easier to deploy organization-wide IT policies such as data loss
prevention (DLP) and conditional access.
▪ It is simpler to manage service account configurations and connections
when moving from one environment to another in the same tenant.
▪ It facilitates easier and safer integrations between tenant services,
without the need to elevate privileges to cross service boundaries.
(For example, Power Platform and Exchange Server-side sync is
only possible within the tenant.)

Cons of a global single-tenant setup:

▪ A tenant can only be associated to a single org Active Directory forest.
If there are independent subsidiaries using a separate Active Directory
forest, they can’t be added to tenant, but can use alternatives such as
Azure business-to-business (B2B) for guest-user access.
▪ In a single-tenant setup, you can create tenant-wide policies. All
environments, including the production environment, are governed
by the same policies. Creating exceptions for trying out new services
or testing might require the team to go through multiple information
security hoops. (For example, a proof of concept or pilot requiring a
different Active Directory conditional access policy will attract scrutiny
from security.)

Global multitenant setup

Usually, the tenant structure for the Microsoft cloud software as a
service (SaaS) mirrors the structure of the organization. But some
organizations operate as separate business entities in a country or
region—even though they might be part of a single umbrella brand. In
such cases, an organization might adopt a multitenant setup (Figure
9-3), as each business entity might have its own contractual needs,
regulatory constraints, and licensing agreements.

Alternatively, organizations can have separate tenants for development,

testing, and live systems. This primarily supports the information security
requirements to isolate data and keep users who aren’t involved in pro-
duction from accessing production systems. Still, using separate tenants
is generally not recommended because there could be data and access
isolation at the service level to meet information security requirements.

Implementation Guide: Success by Design: Environment strategy 193

(For example, you might use security groups on environments to
limit access.)

User accounts, identities, security groups, subscriptions, licenses, and

storage can’t be shared among different tenants. So, using separate
tenants might require replication of all other services or creation of
stubs for external systems—per tenant—for all the integrations. Also,
duplication of licenses and quotas across tenants may be needed
to support ALM and performance testing. Admins would have the
additional responsibility of ensuring that all the policies and settings
between tenants are in sync to avoid deployment failure between
tenants. Some organizations do go down this path because of their
historical setup or a lack of understanding of the controls available to
restrict access at the service level.

Let’s examine some of the pros and cons for a global multitenant setup.

Pros of a global multitenant setup:

▪ It works when different subsidiaries are fully independent, with
different systems to manage user identities in separate domains,
and have separate licensing needs.
▪ It provides the highest level of isolation that will simplify the
security approvals but is not generally required.
▪ It is easier to manage and monitor the cost per tenant without the need
for internal cross-charging and tracking usage of shared resources on a
single tenant. (For example, storage is shared on a single tenant.)

Cons of a global multitenant setup:

▪ Licenses can’t be shared across different tenants, which means
that storage, API add-ons, and other tenant-level quotas must be
purchased for each tenant, and you may have to purchase
separate licenses for the same user to access separate tenants.
▪ Overhead to maintain tenant-level Active Directory and DLP
policies consistently across tenants can lead to surprises during
production deployment.
▪ Service-level admin actions, such as ability to copy an environment,
may not be available across tenants, which can make testing or
troubleshooting difficult.
▪ The build automation and continuous integration and continuous

194
 delivery (CI/CD) pipelines that span multiple tenants can be more
complicated and might require manual intervention, especially
when managing connections to the service.
▪ You may have to purchase a significant number of licenses for con-
ducting testing. With load testing, for example, you can’t reliably
simulate a load from 1,000 users using five test-user accounts.
▪ If you’re using capacity add-ons, you will have to make duplicate
purchases for each tenant to develop and test your solutions.
▪ Integrations with other services, such as Exchange, can’t be done
across tenants, which means potentially purchasing licenses for
other Microsoft services for each tenant.

Overall, managing your ALM process across several tenants brings

unnecessary complexity to licensing and technology, and delivers little
value in terms of security, because you might already have the necessary
controls at the service level to limit access to business data.

Key factors affected by

an environment strategy
In this section, we explore the key factors directly affected by an
environment strategy, including security and compliance, ALM,
operations, and functional and nonfunctional aspects of the solution.
Considering these key factors will help you define an environment
strategy that meets the needs of your organization, and set the
direction for the future growth of these applications to meet evolving
business requirements.

Compliance
Security and compliance are critical considerations for an environment
strategy. Each organization needs to ensure that data is stored and pro-
cessed in accordance with local or regional laws, such as data-residency
requirements for a specific region. For example, the European Union (EU)
enforces the General Data Protection Regulation (GDPR) for EU residents,
as well as its citizens outside of the EU.

Implementation Guide: Success by Design: Environment strategy 195

At the onset of the project, your organization must determine your
environment’s compliance requirements. These can vary widely de-
pending on the industry, regulations, business type, and user base, and
will need to be approved by your internal security and compliance teams.

The most common elements affecting compliance are:

▪ The physical location of the environment(s), which usually
determines data residency
▪ The specific features and apps in the scope and their data-
processing requirements
▪ The encryption (at rest and in transit for confidential information)
▪ The disaster recovery procedures to restore the service and data
▪ The data-retention policies, and the ability to back up and restore data
▪ The personally identifiable information (PII) standards for data
protection, and ensuring the service is compliant with the regula-
tory requirements for the industry and region

Application design
The environment strategy can affect the application design. Conversely,
the needs of an application can drive the environment requirements,
and it’s not uncommon for IT systems within an organization to reflect
the actual structure of the organization. Depending on your organiza-
tion’s strategy for data isolation, collaboration, and security between
different departments, you could choose to have a single shared envi-
ronment or create isolated environments. For example, a bank might
allow data sharing and collaboration between commercial and business
banking divisions while isolating the personal banking division, which
reflects the bank’s application design and environment strategy.

Environment policies should not be created in isolation. Creating a generic

organization-wide policy, such as “Every application should use a separate
environment” or “All applications should share a single environment”—
without considering the business requirements or understanding the
underlying data and integration dependencies—could lead to unneces-
sary complexity and fragmentation.

The data store for an application and the supporting business process

196
 plays a key role in the environment decision. If multiple apps for different
departments can benefit from leveraging each other’s data, a single envi-
ronment with integrations can improve consistency and collaboration.
The user experience can be tailored via dedicated apps for different
personas and secure data access using the security model.

For sophisticated systems that need to use multiple environments and

potentially sync data between them, it could be technically possible,
but such patterns require careful consideration of performance and
API capacity—and are best avoided.

App integrations also play a key role, as multiplexing with different

environments may not work. For example, a user may not be able to
simultaneously sync emails to several environments.

Performance
Microsoft cloud services provide a high degree of scalability and
performance. Based on considerations such as network latency,
firewalls, network traffic monitoring, organizational proxies, and
routing by internet service provider (ISP), globally distributed users
can experience higher latencies when accessing the cloud. This is why
we recommend creating a latency analysis matrix (Figure 9-4) for
solutions that have a globally distributed user base.

This exercise gives a fair idea of how the network latency will
affect the user experience based on the location of your environment.
This information can be used to make a balanced choice so most
users have an acceptable level of latency, and application design can
be optimized for users in high-latency locations. For example, using
Fig.
9-4

Environment
User location Device Network Latency Bandwidth
location

North America Corporate

Canada Browser 80 ms 6.4 Mbps
(NAM) network

North America Corporate

Amsterdam Tablet 120 ms 8 Mbps
(NAM) Wi-Fi

Implementation Guide: Success by Design: Environment strategy 197

 lightweight forms or reducing the number of records shown on a page
can enable faster loads.

Also, environment types should be chosen carefully, based on the

workload and the capacity needed. Using trial environments, for exam-
ple, will not deliver the same level of performance as live production
environments, so it may not be suitable to develop or test the solution
on a trial.

Scalability
Scalability of the SaaS platform is a critical consideration for business
applications. Traditionally, scaling up in on-premises deployments was
about adding more servers or more CPU, memory, or storage capacity
to existing servers. In a cloud world with elastic scale and microservice
architecture, the server could be replaced by an environment and the
compute and data transfer units by the API capacity. (This is just used
as analogy—it’s not a one-to-one mapping where one environment
corresponds to a server in the SaaS infrastructure.)

The scalability parameters for a SaaS could be:

▪ How many parallel connections or concurrent users can you sup-
port with one application or in a single environment?
▪ How many API calls is a user entitled to make?
▪ What are the limits on workflow or code executions?

The following is a potential SaaS cloud interpretation of vertical and

horizontal scalability.

Vertical scalability
Organizations commonly operate single environments supporting
thousands of users, and each user has a defined API entitlement based
on the license type assigned. The environment’s storage grows as more
users and applications store their data. Dynamics 365 SaaS services
are built on a scalable cloud infrastructure that can store terabytes of
data to meet the requirements of large enterprises. When it comes
to workflows automation, each environment can have any number
of Microsoft Power Automate flows, each with thousands of steps

Implementation Guide: Success by Design: Environment strategy 198

 performed per day, which can be further scaled using appropriate
license types and add-ons. There are no hard limits on the number
of apps you can have per environment, but you can’t have multiple
first-party apps of the same type in the same environment.

Horizontal scalability
With horizontal scalability, organizations can have several separate en-
vironments, with any number of Power Automate flows on the tenant.
There are no native sync capabilities between environments, and you
still need to take license entitlements into consideration, especially
when it comes to tenant-wide storage and API entitlement.
The effort to
maintain the
Maintainability
solution is directly
Maintainability measures the ease and speed of maintaining a solution,
proportional to including service updates, bug fixes, and rolling out change requests
the number of and new functionality.
environments
involved. If you have several applications sharing common components in
the same environment, you should consider maintainability when
upgrading or deploying a new release. It’s also important to invest in
automation testing so you can run regression tests and quickly identify
any dependencies that could cause issues.

The effort to maintain the solution is directly proportional to the number

of environments involved. For example, testing a release wave or analyzing
the impact of deprecations is easier when there is just one production
environment with the Dynamics 365 Sales app and the Dynamics 365
Customer Service app, compared to a solution that uses different
production environments for the Sales and Customer Service apps.

ALM
ALM includes the tools and processes that manage the solution’s
lifecycle and can affect the long-term success of a solution. When
following the ALM of a solution, consider the entire lifespan of the
solution, along with maintainability and future-proofing. Changes to
your environment strategy will directly affect the ALM (and vice versa),

Implementation Guide: Success by Design: Environment strategy 199

 but it’s important to be clear that environments are not the repository
of your code and customizations.

Environments can be used to separate business functions or for different

purposes, such as development, testing, and production. Typically, at
least three environments are necessary to support a mature
release-management process.

Types of environments
Production environments are meant to support the business. By default,
production environments are more protected for operations that can
cause disruption, such as copy and restore operations. Sandbox
environments can be used to develop, test, and delete as required.

Purposes of environments
▪ Development  One or more development environments are
usually required, depending on the customization requirements and
time available. Development environments should be set up with
proper DevOps to allow for smooth CI/CD. This topic is covered in
more detail in Chapter 11, “Application lifecycle management.”
▪ Quality assurance (QA)  Allows for solution testing from both
a functionality and deployment perspective before the solutions
are given to the business teams in a user acceptance testing (UAT)
environment. Only managed solutions should be deployed here.
Depending on project requirements, there can be multiple testing
environments, including regression testing, performance testing,
and data-migration testing.
▪ UAT  Generally the first environment that business users will have
access to. It will allow them to perform UAT before deployment.
▪ Training  Utilized to deliver training. It allows business users to
practice in a simulated environment without the risk of interfering
with live data.
▪ Production  The live system for business users.

Citizen development
One of the key value propositions of the Power Platform—the underly-
ing no-code/low-code platform that powers Dynamics 365 Customer
Engagement apps—is that it enables people who aren’t professional
developers to build apps and create solutions to solve their own problems.

Implementation Guide: Success by Design: Environment strategy 200

 Central IT still has governance responsibility and creates guidelines
to secure data with DLP policies. But business users should be able to
build apps and automate their work while accessing data in a secure
way. This organic growth of applications by business users facilitates
digital transformation at a massive scale. Thousands of organizations
have adopted this “citizen developer” philosophy to quickly roll out
hundreds of apps across the organization, creating a community of
engaged employees who are helping realize the vision of an agile busi-
ness that can evolve to meet customer needs in days or weeks instead
of months or years.

The environment strategy that enables this kind of organic growth

will be different from a traditional IT-developed solution. It’s crucial
to deliver an agile and automated process where business users can
request environments to enable the maker experience and connect
When planning to data in a secure way while conforming to the standards for data
your environment modeling and application design set by the organization.

strategy, consider
any future phases Future-proofing
and rollouts of Future-proofing is the process of developing methods to minimize
any potential negative effects in the future. It can also be referred to as
the solution, as resilience of the solution to future events.
well as changing
requirements. Your environment strategy needs to take into consideration any future
phases and rollouts of the solution, and allow you to deal with changing
requirements and build a solution that will not limit the business or take
away necessary control. As an example, consider country-specific needs,
as well as variations to and deviations from the standard process.

Environment app
strategy
If you’re deploying multiple business apps on the Dynamics 365 platform,
you will need to decide on an environment app strategy. Should all apps
be deployed in the same environment? Or should each app have an
environment of its own?

Implementation Guide: Success by Design: Environment strategy 201

 There isn’t a standard answer or blanket approach that will work for all
apps within your organization. The best approach for you is the one that
facilitates collaboration and cross-pollination of information between
apps—while also reducing data silos and meeting your organization’s
security, compliance, and data protection requirements.

Multiple-app environment
In a multiple-app environment scenario (Figure 9-5), a single production
environment is used for multiple apps. For example, the production
environment might have the Dynamics 365 Marketing and Sales apps
to enable collaboration between the marketing and sales teams, and
facilitate a quick transfer of qualified leads to sales representatives.
Similarly, having the Sales and Customer Service apps in the same
environment gives the sales team insights into customer support
experiences, which could affect ongoing deals.

With multiple-app deployment, the app data, security models, and

data models are in a common repository, allowing the apps to reuse
any integrations. The security model design will be used to limit access
to data for each app, with the user experience defined by the individu-
al app. For example, the Sales and Marketing apps might use the same
lead table, but security roles and the app definition will control access
to records, fields, and processes.

Let’s examine some of the pros and cons for the multiple-app
Fig.
9-5 deployment model.
Pros of a multiple-app
Multiple-app environment deployment model:
▪ It enables stronger collabora-

Production environment tion between business teams

by decreasing data silos.
▪ It reduces the number of
Dynamics 365 apps
environments to manage, as
well as the amount of effort
needed for platform updates.
Sales Customer Marketing Field Project
▪ It allows reuse of integrations,
Service Service Operations
and its simpler design low-
ers API consumption while

Implementation Guide: Success by Design: Environment strategy 202

 avoiding the need for data sync across environments.
▪ It simplifies reporting and the business intelligence architecture.

Cons of a multiple-app deployment model:

▪ Its security model could become complex, depending on access
restrictions.
▪ Its ALM and release process needs to be coordinated for each
app and will require full regression testing when changing shared
components, making automation testing even more critical.
▪ Its capacity utilization for individual apps is more difficult to track.
▪ Its security, data models, or integrations, if poorly designed on one
app, can affect other apps.
▪ It might have limitations on deploying several apps of same type in
a single environment. (For example, you can’t have several Power
Apps portals with the same template in a single environment.)
▪ It can’t be used if you need to segregate the environments for a
globally distributed user base due to performance, compliance
regulations, or process differences.

Per-app environment
In a per-app deployment model (Figure 9-6), every application gets
its own production environment, with a separate set of environments
to support the underlying ALM and release process. There is complete
isolation of the data, schema, and security model. A per-app environ-

Fig.
ment might seem simpler from a deployment perspective, but it can
9-6
create data silos such that one business process cannot easily benefit
from sharing information with an-
Per-app environment other, leading to additional effort
in building complex integrations.
Production Production Production
environment environment environment Also, the security model is defined
per environment, so you can’t use
the platform security constructs
App App App
to define which data from one
environment will be accessible to
a user in a different environment.
Sales Customer Field
Service Service Consider an example where
the Sales and Customer Service

Implementation Guide: Success by Design: Environment strategy 203

 apps are deployed in separate environments, requiring core customer
records to be synchronized across the two. In this scenario, providing
sales representatives with visibility into support experiences will require
some level of integration, either by copying over the data periodically
or integrating the visual user interface (UI).

This approach might be more relevant for isolated functions within

an organization where there is little need for data sharing and col-
laboration. For example, an internal HR ticketing system for employees
has little to do with the sales process. Network latency, compliance,
and region-specific requirements could mandate the use of per-app
environments, but will introduce data-replication challenges, integra-
tion redundancy, and increased costs for storage, integration, and
maintainability.

Let’s examine some of the pros and cons for the per-app
deployment model.

If you’re deploying Pros of a per-app deployment model:

▪ Its security model is separately managed for each app, which
more than one app, simplifies configuration when there is no need for data sharing
you will need to between environments or development of custom
carefully consider security components.

these factors in ▪ Its ALM and release process for each app can be independent.
▪ Its capacity utilization for individual apps can be tracked easily for
coordination with cross-charging within the business.
the multiple- ▪ Its design issues in one app will not directly affect other apps.
app and per-app ▪ It is the preferred approach if there is a need to segregate the

environment environments for a globally distributed user base due to network

latency, compliance regulations, or process differences.
strategies covered in
Cons of a per-app deployment model:
the previous section.
▪ It can create data silos between business units and departments,
potentially reducing collaboration and value to the business.
▪ It means a linear increase in the number of environments to support
ALM for each app and the administration effort for platform updates.
▪ It largely prevents reuse of integrations and is a potentially complex
solution requiring data sync and complex custom security logic. In
some cases, integrations are not possible across several environments.

Implementation Guide: Success by Design: Environment strategy 204

 (For example, you can’t sync users’ Exchange mailboxes to several
environments at the same time.)
▪ It potentially brings higher API and storage costs due to data and
integration redundancy.
▪ Its reporting and intelligence architecture will be more complex and
require data unification in an external data store, such as a data lake.

Global deployment
scenarios
This section will focus on three common app-deployment models you
could use—along with the tradeoffs, pros, and cons when choosing
one approach over the other—to help you find the best option for
your deployment.

We’re discussing global deployment scenarios in the context of a

single-app deployment. If you’re deploying more than one app, you
will need to carefully consider these factors in coordination with the
multiple-app and per-app environment strategies covered in the
previous section.

Global single environment

A global single environment is just one environment deploying an
app that’s accessed by users across the globe. All the data, processes,
code, customizations reside in a single environment. Based on the
app’s security requirements and regional data-sharing policies, your
organization will have to manage access via security roles. This is the
most common approach, as it enables strong global collaboration and
a unified view of data and processes across different regions, business
units, and legal entities.

While a global single environment simplifies deployment and

maintenance of the solution, centralized process governance is needed
to ensure that different regions conform to a unified process, with
deviations kept to a minimum. If processes are not unified globally,

Implementation Guide: Success by Design: Environment strategy 205

 handling region-specific requirements will require a complex
solution—likely with poor performance—which ultimately will affect
usage and adoption.

Your organization Your organization might have to adjust the security model for each
region to meet local regulations and accommodate cultural differences
might have to around sharing and collaboration.
adjust the security
model for each Let’s examine some of the pros and cons of a global single environment.

region to meet Pros of a global single environment:

local regulations ▪ Data unification across regions and countries enables greater

and accommodate collaboration and helps standardize processes

▪ Settings, updates, configurations, and ALM are easier to manage
cultural differences ▪ Costs of storage and integrations are reduced by avoiding duplication
around sharing and ▪ Intelligence and reporting architecture, as well as master data
collaboration. management, are simplified

Cons of a global single environment:

▪ Change management and governance could be harder when trying to
make a process work for everyone while avoiding political challenges
▪ Poor adoption is possible in regions where users aren’t engaged or
if their requirements are deprioritized
▪ Security model configuration could become complex, as each
persona might have a different regional flavor
▪ Some regulatory and data-residency requirements would be hard
to meet in a global single environment, and could slow down
change and business agility if the effort isn’t well coordinated
▪ High network latency for users in different countries or regions can
affect performance and adoption
▪ Maintenance schedules and downtime are difficult to manage

Global multiple environment

Multiple-environment scenarios support different business units,
departments, teams, countries, or other structures inside an organization.

Each environment has its own database, and data isn’t shared across
environments. This builds a physical security aspect on top of logical,

Implementation Guide: Success by Design: Environment strategy 206

 out-of-the-box security based on security roles. In separating environ-
ments by region or country, solutions included in each environment can
support local business and compliance requirements.

If users are distributed over large distances, particularly for global

deployments, multiple environments may be more suitable because
of the implications (such as latency) associated with the connection
infrastructure, which can significantly affect the user experience.
Distributing environments to provide users with more local access can
reduce or overcome network-related issues, as the access occurs over
shorter network connections.

By creating
In terms of ALM, the solution-release process can be unique for each
multiple production environment, which will support specific business units, departments,
environments, and countries. However, it will increase the number of environments
it’s possible to needed to support development, testing, and training activities, as

easily implement each production environment needs its own environment to support
the solution-release process.
specific business
requirements and Because the data is not unified in a global multiple-environment setup,
have different