32,99 €
Mehr erfahren.
- Herausgeber: John Wiley & Sons
- Kategorie: Fachliteratur
- Sprache: Englisch
Confidently shepherd your organization's implementation of Microsoft Dynamics 365 to a successful conclusion In Mastering Microsoft Dynamics 365 Implementations, accomplished executive, project manager, and author Eric Newell delivers a holistic, step-by-step reference to implementing Microsoft's cloud-based ERP and CRM business applications. You'll find the detailed and concrete instructions you need to take your implementation project all the way to the finish line, on-time, and on-budget. You'll learn: * The precise steps to take, in the correct order, to bring your Dynamics 365 implementation to life * What to do before you begin the project, including identifying stakeholders and building your business case * How to deal with a change management throughout the lifecycle of your project * How to manage conference room pilots (CRPs) and what to expect during the sessions Perfect for CIOs, technology VPs, CFOs, Operations leaders, application directors, business analysts, ERP/CRM specialists, and project managers, Mastering Microsoft Dynamics 365 Implementations is an indispensable and practical reference for guiding your real-world Dynamics 365 implementation from planning to completion.
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 817
Veröffentlichungsjahr: 2021
Ähnliche
Table of Contents
Cover
Title Page
Copyright
Dedication
Acknowledgments
About the Author
About the Technical Editor
Introduction
Chapter 1: Stages of an Implementation Overview
What Is Microsoft Dynamics?
The Client Journey
Implementation Methodologies
Triple Constraints
The Bottom Line
Chapter 2: What to Do Before You Begin a Project
Identify Your Project Team and Stakeholders
Identify Your Processes in Scope
Clean Up Your Data
Define Your Success Metrics
Possible Benefits
Building Your Business Case and Securing Funding
The Bottom Line
Chapter 3: Four Keys to Consider When Buying an ERP or CRM Solution
Selection Process
The Four Keys
Building Your Scorecard
The Bottom Line
Chapter 4: How to Evaluate and Buy Business Application Software
Buying Process Steps
The Bottom Line
Chapter 5: Organizing Your Team for Success and Project Governance
RACI
Your Partner's Implementation Team
Project Governance
The Bottom Line
Chapter 6: Sprints and Tools Needed to Run Your Project
Definition of a Sprint
Backlog
Sprint Meetings
Work Definitions
Azure DevOps
The Bottom Line
Chapter 7: Change Management Throughout Your Project
Success Criteria
Use of Satisfaction Surveys
Nine Steps to Change Management
The Bottom Line
Chapter 8: Organizing Your Business by Processes
Common Language Businesses Speak
Process Hierarchy
Discovering Your Processes
The Bottom Line
Chapter 9: Independent Software Vendors—Filling Gaps and Managing Partnerships
The Purpose of ISVs
Hosting Providers
Working with ISVs
Microsoft's AppSource Marketplace
The Bottom Line
Chapter 10: Factors for a Successful Project Kickoff
Pre-Kickoff Meeting Activities
Kickoff Meeting Content
Executive Message
Expectations for the Project Team
The Bottom Line
Chapter 11: Designing the Software Collaboratively
Joint Application Design Concept
Joint Process Design and Other Design-Related Definitions
Joint Process Design Iterations
SIPOC
The Bottom Line
Chapter 12: Requirements Gathering and Staying “In the Box”
Staying in the Box
Requirements
Writing Good Requirements
Fit/Gap Analysis
The Cost of Customizations
The Bottom Line
Chapter 13: Conference Room Pilots
The Purpose of a Conference Room Pilot
CRP Roles and Responsibilities
CRP Place in the Overall Schedule
CRP vs. UAT
What to Do Between CRP and the End of the Create Stage
CRP Goals
The Bottom Line
Chapter 14: Dealing with Challenges Mid-Project
Managing the Project Status
Risks and Issues
Common Project Challenges
The Bottom Line
Chapter 15: Customizations vs. Configurations and How You Manage Them
Customizations vs. Configurations
Tracking Configurations
Functional Design Documents
The Development Process
After Code Complete
The Lifecycle of a Customization
The Bottom Line
Chapter 16: Data Migration—Early and Often
Data Migration Plan
Extract
Transform
Load
Validating the Data
Technical Validation
Go-Live Iteration
The Bottom Line
Chapter 17: Environment Management and Deployments
Types of Environments
Environment Plan
Deploying Code
Security
The Bottom Line
Chapter 18: Testing
Definitions
Pre-Deploy Stage Activities
UAT Sessions
Post UAT Testing
The Bottom Line
Chapter 19: Training for All
Learning During Interactive Sessions
Learning Modalities
How to Manage and Distribute Your Content
Building Your End User Training Schedule
The Bottom Line
Chapter 20: Going Live
Go-Live Criteria
Mock Cutover and Final Week Activities
Go/No-Go Meetings
Live Cutover
The Bottom Line
Chapter 21: Hypercare
Go-Live Support
Role of HelpDesk
Post Go-Live Releases
Project Team Transition
The Bottom Line
Chapter 22: Support and Enhance Your Project
Support After Hypercare
After Action Review
Ongoing Releases
Future Enhancements
Calculating Return on Investment
The Bottom Line
Chapter 23: Bringing It All Together
Align Stage
Define Stage
Create Stage
Deploy Stage
Empower Stage
Additional Resources
The Bottom Line
Appendix: The Bottom Line
Chapter 1: Stages of an Implementation Overview
Chapter 2: What to Do Before You Begin a Project
Chapter 3: Four Keys to Consider When Buying an ERP or CRM Solution
Chapter 4: How to Evaluate and Buy Business Application Software
Chapter 5: Organizing Your Team for Success and Project Governance
Chapter 6: Sprints and Tools Needed to Run Your Project
Chapter 7: Change Management Throughout Your Project
Chapter 8: Organizing Your Business by Processes
Chapter 9: Independent Software Vendors—Filling Gaps and Managing Partnerships
Chapter 10: Factors for a Successful Project Kickoff
Chapter 11: Designing the Software Collaboratively
Chapter 12: Requirements Gathering and Staying “In the Box”
Chapter 13: Conference Room Pilots
Chapter 14: Dealing with Challenges Mid-Project
Chapter 15: Customizations vs. Configurations and How You Manage Them
Chapter 16: Data Migration—Early and Often
Chapter 17: Environment Management and Deployments
Chapter 18: Testing
Chapter 19: Training for All
Chapter 20: Going Live
Chapter 21: Hypercare
Chapter 22: Support and Enhance Your Project
Chapter 23: Bringing It All Together
Glossary
Index
End User License Agreement
List of Tables
Chapter 2
Table 2.1: Time Commitment by Role
Table 2.2: Capitalized Cost Items
Table 2.3: Non-Capitalized Cost Items
Chapter 3
Table 3.1: Performance at Scale Tiers
Table 3.2: Customer Readiness and Implementation Team Quality Levels
Chapter 5
Table 5.1: RACI
Table 5.2: Project Meeting Recommendations
Table 5.3: T-Shirt Sizing Scale
Chapter 6
Table 6.1: DevOps Core Fields
Chapter 11
Table 11.1: Iterative Sequence
Table 11.2: SIPOC Acronym
Chapter 12
Table 12.1: Example of a Fit/Gap Spreadsheet
Chapter 13
Table 13.1: Iterative Sequence
Table 13.2: Create Phase Schedule
Table 13.3: CRP vs. UAT
Chapter 14
Table 14.1: Mid-Project Challenges Mitigation Plans
Chapter 16
Table 16.1: Data Migration Classes
Table 16.2: Three Levels of Validation
Chapter 17
Table 17.1: Implementation Releases
Chapter 19
Table 19.1: Benefits of In-person vs. Online Synchronous Training
Table 19.2: Training Matrix
Chapter 20
Table 20.1: Go-Live Scorecard Example
Table 20.2: Go/No-Go Meeting Agenda
Chapter 21
Table 21.1: Implementation Releases
Table 21.2: Hotfix Releases Key Facts
List of Illustrations
Chapter 1
Figure 1.1 The Client Journey
Figure 1.2 The Align stage in the Client Journey
Figure 1.3 The Define stage in the Client Journey
Figure 1.4 The Create stage in the Client Journey
Figure 1.5 The Deploy stage in the Client Journey
Figure 1.6 The Empower stage in the Client Journey
Figure 1.7 Microsoft Dynamics Sure Step Methodology
Figure 1.8 Four parts of the Agile Manifesto
Figure 1.9 Triple constraints concept
Figure 1.10 Triple constraints with decreased cost
Figure 1.11 Triple constraints with increased scope
Chapter 2
Figure 2.1 Implementation core roles
Figure 2.2 Benefits of an ERP or CRM project
Figure 2.3 Capitalized and non-capitalized quick guide
Figure 2.4 Sample ROI calculation by Nucleus Research
Chapter 4
Figure 4.1 Key factors in rating your vendor
Chapter 5
Figure 5.1 Implementation core roles
Figure 5.2 Implementation team example
Figure 5.3 Microsoft SharePoint repository site example
Chapter 6
Figure 6.1 Hierarchy of work definitions
Figure 6.2 Kanban board functionality mock-up
Chapter 7
Figure 7.1 Project success definition
Figure 7.2 Three levels of organization affected
Chapter 8
Figure 8.1 Process classification framework
Figure 8.2 SIPOC diagram
Chapter 9
Figure 9.1 Microsoft AppSource Marketplace search functionality
Figure 9.2 Services listing example
Chapter 11
Figure 11.1 Joint Process Design
Figure 11.2 Quote to Cash process flow
Figure 11.3 SIPOC process flow
Chapter 12
Figure 12.1 Command prompt example
Chapter 14
Figure 14.1 The Project Enthusiasm Curve
Figure 14.2 Risk register
Figure 14.3 Mid-project challenges
Chapter 15
Figure 15.1 Developer activity
Figure 15.2 Lifecycle of customization
Figure 15.3 DevOps example
Chapter 16
Figure 16.1 Three steps to data migration
Figure 16.2 Data migration workstream activity
Figure 16.3 Data migration iterations
Chapter 17
Figure 17.1 Environments and necessary steps
Figure 17.2 Production environment joke
Figure 17.3 Environments and types of subscriptions
Figure 17.4 Environments in code packages
Figure 17.5 DevOps to environments
Chapter 18
Figure 18.1 Creating a test case
Chapter 19
Figure 19.1 Learning modalities
Figure 19.2 Microsoft Dynamics 365 Help documentation
Figure 19.3 Microsoft Learn learning platform
Figure 19.4 Microsoft Task Recorder
Figure 19.5 Learning validation options
Figure 19.6 Office hours outline
Chapter 20
Figure 20.1 Elements of the go-live criteria
Chapter 21
Figure 21.1 HelpDesk ticket progression
Chapter 22
Figure 22.1 HelpDesk ticket progression
Figure 22.2 Microsoft Subscription support plan
Figure 22.3 Microsoft Dynamics 365 Business Central main modules
Figure 22.4 Business Central Intelligent Cloud Insights capabilities
Figure 22.5 Forrester's Total Economic Impact study of Microsoft Dynamics 36...
Chapter 23
Figure 23.1 Align stage
Figure 23.2 Key activities during the Align stage
Figure 23.3 Define stage
Figure 23.4 Key activities during the Define stage
Figure 23.5 Key activities during the Create stage
Figure 23.6 Deploy stage
Figure 23.7 Key activities during the Deploy stage
Figure 23.8 Empower stage
Guide
Cover
Table of Contents
Begin Reading
Pages
iii
iv
v
vii
ix
x
xi
xxvii
xxviii
xxix
xxx
xxxi
xxxii
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
53
54
55
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
73
74
75
76
77
78
79
80
81
82
83
84
85
87
88
89
90
91
92
93
94
95
96
97
99
100
101
102
103
104
105
106
107
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
Mastering Microsoft Dynamics 365® Implementations
Eric Newell
Copyright © 2021 by John Wiley & Sons, Inc., Indianapolis, Indiana
Published simultaneously in Canada
ISBN: 978-1-119-78932-1
ISBN: 978-1-119-78934-5 (ebk)
ISBN: 978-1-119-78933-8 (ebk)
No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning or otherwise, except as permitted under Sections 107 or 108 of the 1976 United States Copyright Act, without either the prior written permission of the Publisher, or authorization through payment of the appropriate per-copy fee to the Copyright Clearance Center, 222 Rosewood Drive, Danvers, MA 01923, (978) 750-8400, fax (978) 646-8600. Requests to the Publisher for permission should be addressed to the Permissions Department, John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030, (201) 748-6011, fax (201) 748-6008, or online at www.wiley.com/go/permissions.
Limit of Liability/Disclaimer of Warranty: The publisher and the author make no representations or warranties with respect to the accuracy or completeness of the contents of this work and specifically disclaim all warranties, including without limitation warranties of fitness for a particular purpose. No warranty may be created or extended by sales or promotional materials. The advice and strategies contained herein may not be suitable for every situation. This work is sold with the understanding that the publisher is not engaged in rendering legal, accounting, or other professional services. If professional assistance is required, the services of a competent professional person should be sought. Neither the publisher nor the author shall be liable for damages arising herefrom. The fact that an organization or Web site is referred to in this work as a citation and/or a potential source of further information does not mean that the author or the publisher endorses the information the organization or Web site may provide or recommendations it may make. Further, readers should be aware that Internet Web sites listed in this work may have changed or disappeared between when this work was written and when it is read.
For general information on our other products and services or to obtain technical support, please contact our Customer Care Department within the U.S. at (877) 762-2974, outside the U.S. at (317) 572-3993 or fax (317) 572-4002.
Wiley publishes in a variety of print and electronic formats and by print-on-demand. Some material included with standard print versions of this book may not be included in e-books or in print-on-demand. If this book refers to media such as a CD or DVD that is not included in the version you purchased, you may download this material at booksupport.wiley.com. For more information about Wiley products, visit www.wiley.com.
Library of Congress Control Number: 2021930152
TRADEMARKS: Wiley, the Wiley logo, and the Sybex logo are trademarks or registered trademarks of John Wiley & Sons, Inc. and/or its affiliates, in the United States and other countries, and may not be used without written permission. Microsoft Dynamics 365 is a registered trademark of Microsoft Corporation. All other trademarks are the property of their respective owners. John Wiley & Sons, Inc. is not associated with any product or vendor mentioned in this book.
To my Stoneridge Software family
Acknowledgments
This really was a team effort—I get my name on the title page, but it all came together due to contributions across the Stoneridge Software team. My biggest thanks goes to Jessi Woinarowicz for managing the whole publishing process, reviewing all of the chapters, sending them off to be reviewed by the team, and working through all the back and forth. She's been my partner in this whole project, and I couldn't have done it without her. I also want to thank Paul Kjer for his willingness to serve as the technical editor of the book. Paul has a great perspective, and he is willing to challenge assumptions, which is so valuable on this project. I'd like to recognize Tory Bjorklund and Cody Marshall for their efforts in developing many of the concepts that the Stoneridge Software team has adopted over the years which are represented in this book.
I'd also like to thank a host of folks from Stoneridge Software for reviewing chapters and helping promote the book: Rich Studer, Jayson Read, Sara Jo Larsen, Anne Kaese, Dave Ruelle, Tim Everett, Dustin Pagano, Adele Graser, Heike Peters, Rob Wagner, Craig Conzemius, Mike McCardle, Tammy Plowman, Maggie Foster, Leah Baker, and Sabrina Zimara. I'd like to thank my excellent editing team of Gary Schwartz, Barath Kumar Rajasekaran, Christine O'Connor, and Kenyon Brown for giving me the opportunity to publish this book.
I want to extend a special thanks to my family, my wife Becky and my daughters, Katie and Amelia, for their encouragement and support throughout the entire process and for letting me disappear on weekends to write this book. Thank you.
—Eric Newell
About the Author
Eric Newell is the CEO and founder of Stoneridge Software, a Microsoft Gold partner specializing in implementation, consulting, and support for Microsoft Dynamics 365 business applications and technologies. In 2012, he co-founded the company with a passion for business excellence and a determination to better serve the market.
Driven by his vision to create an organization with exceptional team members and an outstanding work culture, Eric has led Stoneridge Software through rapid growth, acquisitions, several strategic initiatives, and the consistent successful delivery of ERP and CRM implementations. What started as a three-person organization in 2012 has now scaled to 200 people in the first eight years in business. In 2018, he also co-founded Levridge, a software company focused on delivering modern business applications for the Agriculture industry.
Prior to founding Stoneridge Software, Eric spent 13 years at Microsoft and Great Plains Software where he was instrumental in leading the Premier Field Engineering practice for Dynamics AX across North America to growth rates of 50 percent each year during his time in the role. Throughout his tenure at Microsoft, Eric led strong performing teams across Dynamics support, Global Support and Consulting Operations, and Premier Support.
Eric enjoys the challenge of taking complex business issues and using technology to figure out ways to streamline operations. The combination of solving challenges and assisting clients in tackling obstacles that affect their businesses are two of his biggest passions.
“My focus is to ensure our clients achieve their business goals with a straight-forward, yet strategic approach. I take pride in the work our team does every day, and it is a privilege for me to be able to lead that charge.”
—Eric Newell
In addition to helping clients achieve their goals, some of the recognition that Eric is most proud of are several “Best Place to Work” awards. Stoneridge Software has achieved a best-place-to-work status every year that it has been eligible, receiving recognition from organizations like Inc. Magazine, Minneapolis Star-Tribune, Prairie Business Magazine, and a Gold, top honors, in 2015 for medium-sized businesses from Minnesota Business Magazine. Stoneridge Software has also been named to the Inc. 5000 list of fastest-growing companies in 2020, 2019, 2018, and 2017, and the SPI Research “Best of the Best” Professional Services firms in 2016 and 2017. Eric Newell was also named Entrepreneur of the Year by the Fargo-Moorhead-West Fargo Chamber of Commerce in 2019 and included in Prairie Business Magazine's “40 Under 40” in 2017.
Eric's interest in business has also extended to the community, having served many years as chair of the Economic Development Authority. To help encourage businesses to consider moving to the area, Eric worked in partnership with the Economic Development Authority to spearhead a program called the “Barnesville Business Pitch,” which awarded cash prizes and a forgivable loan to entrepreneurs.
His community involvement also extends to serving a term on the school board, beginning a kindergarten through second grade basketball initiative for the community education program, coaching youth basketball, and, along with wife Becky, running the Whist tournament every year at the annual Potato Days Festival.
If he's not behind his laptop, you can find Eric attending his daughters' sporting events, visiting his two restaurants—The Purple Goose and The Pitchfork—and cheering on the Minnesota Twins. He is also the author of Minnesota Whist.
About the Technical Editor
Paul Kjer, PMP, has played many leadership roles in business software applications since his first ERP implementation in 1991. Paul is currently the Enterprise Practice Director for Stoneridge Software.
Introduction
I started my career in the world of ERP and CRM back in 1999 when I landed a job as a support engineer for Great Plains Software, supporting Great Plains eEnterprise version 5.5. I had a management and economics degree and a natural affinity for computers, but I certainly didn't know anything about an ERP product or SQL Server. I also hadn't observed project management before, and I didn't understand the impact of it.
My career path at Microsoft (which bought Great Plains Software in April 2001) took several turns as I pivoted to focus on internal applications on which the support team relied, and I became the Support Operations Manager. During that time, my job was to execute projects to make improvements to our incident tracking system, our knowledge base, and the business intelligence needs of our support leadership team. I needed to manage projects and interface with IT project managers. I had not read anything about project management, and I was learning on the fly.
At first, I thought project management was easy—you set up a meeting, invite the right people, take notes, and call it a day. At the time, there weren't good apps like Azure DevOps for tracking every task, and stand-up meetings weren't a thing. Project managers just hoped that team members would get their work done on time. They would ask them about it at the weekly meetings, and that was about it. Some project managers had a good game plan for the order of operation of the activity on the project, but many were just there to make sure that the meetings occurred.
I went through much of the middle of my Microsoft career without a high degree of respect for project managers. I didn't understand what true value they brought to a project. I also saw people who were trying to perform the dual roles of project management and business analyst or subject matter expert. This was my first introduction into how difficult it is to wear both of those hats at the same time.
I switched from an internally focused role back to a client-facing role in 2005, becoming a Technical Account Manager for Microsoft Dynamics GP and CRM. My work gravitated toward CRM, where I worked with some of Microsoft's largest clients. When working with one client, I started to see how valuable project management could be. This project manager ran meetings and took notes like other project managers, but he also knew what needed to be done and when, and he pushed the team to hit the timeline as well as follow up with resources outside of meetings to get their tasks completed. I started to see that a project manager could be a valuable addition to a team.
In my next role, I managed the Premier Field Engineering team focused on the Dynamics ERP products (Dynamics AX, Dynamics NAV, and Dynamics GP—we didn't have any Premier clients on Dynamics SL). In this role, my team performed two primary activities: performance and health check guidance for existing clients and a Dedicated Support Engineer who served as a Microsoft functional or technical resource for clients in all stages of the implementation. We had clients reach out asking if we could run their implementations or support them as they self-implemented. Microsoft's policy was that they should work with a partner; however, they could engage my team for assistance through the implementation. For the most part, my team was an accessory to the implementation, but we ended up getting more deeply involved in a few of them.
This is when my eyes were really opened to the importance of project management and how critical it is to have the right leadership to get you through a complex business application. Every single project suffered from a lack of strong project management, regardless of where it was provided—by the client or the implementation partner—and they were all running over time and over budget. I started talking to my friends on the Customer Relations team at Microsoft to understand the nature of the escalations (when the customer threatens to move off the product or sue the partner or Microsoft due to the lack of progress on the project) they worked on. The Customer Relations team was the first line of defense for any clients who were upset with the success of their implementation project. If someone sent a letter to Bill Gates saying that their implementation was failing, it would come to the Customer Relations team. That team had a lot of data on failing projects and the driving force of the problem. In some of the cases, it was a technical problem—a bug with Microsoft or a missing feature that someone promised them—but the vast majority were project management problems.
The combination of the project problems that my team saw with the problems from the Customer Relations team made me wonder: Does anyone really know how to run a business applications project successfully?
I'm the kind of person who loves to work on the hardest possible projects. I live for challenges. Seeing this huge challenge of how to run implementation projects, I dove in. I learned everything I could about implementation methodologies; I read every book about how to implement Dynamics at the time, and I volunteered to do two things: contribute to Microsoft's Sure Step methodology and teach a class for Microsoft to new consultants about how an implementation works.
Connecting with new consultants about how an implementation works made it abundantly clear that these students had a ton to learn about implementation. This fueled my passion to want to learn even more. This desire was a big reason why I decided to leave Microsoft and start Stoneridge Software. I wanted to put what I had learned into practice and to continue to learn more.
When we started Stoneridge Software, my first consulting job was to serve as a Project Manager for a Dynamics implementation that had been going on for over a year but was stuck. I was able to get it moving and implement quite a bit of it over the next year-and-a-half so the client could earn value out of their system. It wasn't easy, and it made me realize that I had to expand my knowledge every day in that role to keep up with all of the curveballs that I would get from my client.
Managing an implementation is never easy, regardless of how well you know the steps and the “science” behind running an implementation. There's an “art” to working with any different group of humans trying to put this into place. The goal of this book is to teach you the science and to give you some ideas on how to manage through the curveballs that come your way.
Who Should Read This Book
This book is for anyone who is involved in an ERP or CRM implementation or expects to be involved in one in the near future. The goal of the book is to appeal to all of the players who would be involved in the implementation so that they can learn more about what they should or shouldn't do when they play their part in the project.
The book speaks directly to a project manager on the client side of the implementation. It attempts to teach the project owner and manager each step of the process along the way to help the project be successful. I believe project owners, project managers, executives and executive sponsors, and IT leaders should read the book from start to finish. Subject matter experts or IT resources with a specific function should focus on the content specific to their role.
Some particular roles for whom the book is a fit: Company Leadership (CEO, President, CFO, COO), IT Leadership (CIO, IT Manager), IT roles (Business Analyst, Project Managers, Developers, Business Intelligence resources, IT Operations), and business leaders and members (VP of Manufacturing, VP of Operations, VP of Sales & Marketing, managers in each of these areas, and subject matter experts).
The book speaks more specifically to Microsoft Dynamics 365, but the same concepts can be used for other ERP and CRM systems. There are more specific examples related to Microsoft Dynamics 365, and I reference links to the most up-to-date information there.
What You'll Learn from This Book
This book will teach you all of the steps that you need to go through to begin and end an implementation of an ERP or CRM system. You will learn about the journey that starts with aligning with the right partner, then define what you want to implement, create the solution that works for you, deploy the solution, and enhance it. The book introduces the Client Journey, which takes you through those five stages, and the chapters are organized into those stages in the journey. The final chapter is focused on the timeline for each event during the project with references back to the detailed steps outlined in previous chapters.
How This Book Is Organized
This book is made up of 23 chapters. Each chapter walks you through a different key step in the implementation process. The chapters are largely in chronological order, but not the exact order, with several steps spanning different phases in the implementation process. Chapter 23 takes all of the activities and puts them in chronological order so that you can see each of the steps in order.
When I talk about steps, phases, and stages, I am referring to steps as necessary activities that you need to do to get through to completion. Phases are the larger, more chronologically based collections of steps. The way that I define phases in the book follows the typical waterfall approach. I'm using the term “stages” to refer to each of the five stages of the Client Journey, which we'll discuss next.
Let's jump into the steps. We are going to follow what we've determined at Stoneridge Software to be the Client Journey, and we've given it this name as a way of categorizing each of the stages that you need to go through during an implementation. We'll start by talking about the stages of the journey at a high level, and then we'll discuss what each session is associated with.
Chapter 1
: Stages of an Implementation Overview
This chapter offers a high-level overview and breakdown of the stages of an implementation.
Chapter 2
: What to Do Before You Begin a Project
This chapter covers all of the preparation one needs to complete before beginning a project, including identifying the project team and stakeholders, building your business case, securing funding, documenting processes, and cleaning up data.
Chapter 3
: Four Keys to Consider When Buying an ERP or CRM Solution
This chapter covers the four keys to consider when buying an ERP or CRM solution and how favoring one of the dimensions at the expense of the others can greatly reduce your chance of success. A successful selection of an ERP system will incorporate all four dimensions: Fit, Platform, Implementer, and Cost.
Chapter 4
: How to Evaluate and Buy Business Application Software
This chapter tells you how to go about actually buying the software and where to begin. It includes a breakdown of how to evaluate one's options and what to expect at the final stages of purchase.
Chapter 5
: Organizing Your Team for Success and Project Governance
This chapter covers the importance of identifying leadership roles, project team roles, and determining how tasks are divided between you and your implementation partner.
Chapter 6
: Sprints and Tools Needed to Run Your Project
This chapter tells you how to organize your project within a specific duration of time and how to keep you on track with goals and reviews.
Chapter 7
: Change Management Throughout Your Project
This chapter helps you define change management, its importance in the “people” aspect, and how it affects the pace and project success.
Chapter 8
: Organizing Your Business by Processes
This chapter outlines the 12 core process categories, including talking through business requirements and comparing “the old way” versus “the new way.”
Chapter 9
: Independent Software Vendors—Filling Gaps and Managing Partnerships
This chapter introduces you to Independent Software Vendors (ISVs) or add-on products and the role they play. Many successful projects include a third-party solution that specializes in a specific area and might fill a valuable niche.
Chapter 10
: Factors for a Successful Project Kickoff
This chapter uncovers the necessary components you need to have in place to set your project kickoff on the right foot.
Chapter 11
: Designing the Software Collaboratively
This chapter will demonstrate the powerful process of working collaboratively with your team and your implementing partner to configure the software with the best end results.
Chapter 12
: Requirements Gathering and Staying “In the Box”
This chapter outlines the important role of requirements gathering and how that plays into taking advantage of processes that come native within the solution you are adopting.
Chapter 13
: Conference Room Pilots
This chapter will explore conference room pilots for your team and the importance they play in the successful adoption of a new solution.
Chapter 14
: Dealing with Challenges Mid-Project
This chapter tells you how to explore the inevitable situation of dealing with challenges that occur mid-project. No matter how much planning and preparation goes into a project, there are always unexpected situations that you will need to address.
Chapter 15
: Customizations vs. Configurations and How You Manage Them
This chapter walks you through the difference between customizations and configurations, why there is a place for both, and how to choose which one is right for your business.
Chapter 16
: Data Migration—Early and Often
This chapter explains why migrating data early and often is critical to a successful implementation project. You'll learn the steps for data migration, how to clean data, when to start migrating, and working with data migration tools.
Chapter 17
: Environment Management and Deployments
This chapter covers why preparing the foundation your data and code will be moving to and planning the best way to get there is an integral component of a successful implementation.
Chapter 18
: Testing
This chapter covers what you need to know about software testing: what is it, how to do it, and why you need it for a successful implementation.
Chapter 19
: Training for All
This chapter outlines the training tips and guidance for everyone who will be using your system, focusing on the types of interactive sessions before training, the learning matrix, the different learning methods, and the importance of having a Learning Management System.
Chapter 20
: Going Live
This chapter tells you how to prepare for all of the potential pitfalls of going live with your software system and to put you in a good position for a successful implementation.
Chapter 21
: Hypercare
This chapter will cover what hypercare is, who the key players are for monitoring your system, and typical issues to look for.
Chapter 22
: Support and Enhance Your Project
This chapter covers what the transition to support looks like, why you need a plan for it, and what you should expect for system maintenance and enhancements.
Chapter 23
: Bringing It All Together
This chapter reviews, at a high level, all of the steps we've introduced to get your project live. You'll get an at-a-glance timeline, so you'll know when to do what during your implementation—that's often the hardest part of the overall project.
How to Use This Book
I suggest that each reader start by reviewing the section “How the Book Is Organized” to get an overview of what's covered in the book. Most readers can start at the beginning and go through each of the chapters to learn the content. If at any time there's a question of when something happens during the implementation, you can jump to Chapter 23, “Bringing It All Together,” in order to understand the chronological order of events. If you are a project owner, project manager, or executive, I suggest that you read the book from the beginning. Other roles can jump into the middle of book to find the chapter that best fits what they need to learn.
If you are in the middle of an implementation, you can certainly start the book on the chapter closest to where you are in your project. I suggest that you read backwards to see if there's anything that you should have done already. I also suggest that you read ahead from there to make sure that you stay ahead of the next steps on the implementation.
How to Contact Wiley or the Author
Sybex strives to keep you supplied with the latest tools and information you need for your work. If you believe you have found an error in this book, and it is not listed on the book's web page, you can report the issue to Wiley customer support team at wileysupport.com.
You can email the author with your comments or questions at [email protected]. You can also visit Eric's website at www.ericnewell.com.
Chapter 1Stages of an Implementation Overview
Welcome to the challenging world of implementing business application software. It's not for the faint of heart, and there aren't many guides that show you how to get there. That's the goal of this book—to provide an actionable guide to implement Microsoft's Dynamics systems successfully.
This book is designed for anyone involved in an Enterprise Resource Planning (ERP) or Customer Relationship Management (CRM) implementation. The content is focused on Microsoft Dynamics, as that is what I have spent my career working on. This book can and should be read by anyone in an executive-level leadership position—the chief executive officer (CEO), chief information officer (CIO), and chief financial officer (CFO)—if you are considering implementing a new business application. Implementing a new business application is something that you will only do a few times during your working career, and there simply is a lack of reputable guides to support you.
AFTER YOU COMPLETE THIS CHAPTER, YOU WILL BE ABLE TO DO THE FOLLOWING:
Define the Client Journey to complete a Microsoft Dynamics implementation
Differentiate between three common implementation methodologies
Recognize triple constraints and how they impact an implementation
What Is Microsoft Dynamics?
Microsoft Dynamics is a set of business application software built by Microsoft and focused on Enterprise Resource Planning (ERP) and Customer Relationship Management (CRM). Microsoft sells Dynamics in several different flavors that are ever-changing. The cloud-based solution is called Microsoft Dynamics 365, and it includes a very broad set of functionalities across Sales, Customer Service, Human Resources, Finance, Supply Chain, Commerce, Project Service, Marketing, and Customer Data Management. You can see additional information about the product on Microsoft's website at dynamics.microsoft.com.
The Client Journey
At Stoneridge Software, we developed what we call the Client Journey, which provides high-level stages to complete the implementation of Microsoft Dynamics. This takes you all the way from initial internal conversations, to meetings with potential vendors, to the enhancements you want to do after you've gone live on the software (see Figure 1.1).
FIGURE 1.1 The Client Journey
We'll break down the Client Journey in the chapters of this book. It all starts with gaining internal alignment and finding alignment with your chosen implementation partner. If you can do that, you're going to be ahead of most companies out there. The Align stage is focused on what you want to accomplish with the project.
Two chapters of the book are focused on the Align stage, starting with what to do before you begin a project and then a session on four keys to consider when buying an ERP or CRM solution. The goal of these two chapters is to get your team internally aligned and then provide you with an idea of what to be looking for in the best product for your company (see Figure 1.2).
FIGURE 1.2 The Align stage in the Client Journey
Once you have alignment internally and know the right type of implementation partner for you, you start on the Define stage. This is when you answer the (literally) million-dollar questions like what software are we going to buy? Who's going to be on the project? What does our budget look like? The Define stage takes you through the sales process and the pre-kickoff process of the implementation (see Figure 1.3).
FIGURE 1.3 The Define stage in the Client Journey
Seven chapters in the book focus on the Define stage, starting with the sales process, where we cover discovery, demos, and contract negotiations; then we move into the steps that you need to start the project out right. From there, we dive into the project preparations starting with how you organize your team, to moving to the cadence with which you run the project, and then to change management. We outline how to break down the work by process area, how to evaluate third-party solutions, and finish up with the kickoff meeting.
The Create stage is where most of the action happens (see Figure 1.4). This begins after the kickoff meeting, and it takes you through the point where code is complete and you're ready to test and get the software out the door.
FIGURE 1.4 The Create stage in the Client Journey
Seven chapters in the book focus on the Create stage. There is a lot to get done during this part of the implementation. I outline how to sort through the processes to generate requirements and how to make those changes to the software while driving toward a cut-off point that allows you to get ready to go live.
The Deploy stage is when you take the software and process from the project team and roll it out to everyone (see Figure 1.5). It takes you through the testing, training, and go-live phases. The chapters in the Deploy stage include testing, training, going live, and the post go-live activity we call “hypercare.”
FIGURE 1.5 The Deploy stage in the Client Journey
The Empower stage is where you find your rhythm for future advances to the solution and look for opportunities to continue receiving additional value from your solution. There is just one chapter in the book on this stage, and we discuss the various paths that companies pursue and the activities with which you want to be consistent after a successful go-live (see Figure 1.6).
FIGURE 1.6 The Empower stage in the Client Journey
Implementation Methodologies
Three common implementation methodologies are used across all different types of IT projects: Waterfall, Agile, and Scrum. Scrum is a variant of Agile, so we'll talk about those two collectively. The methodologies are discussed to provide general knowledge and background information, as they are commonly known in the IT world. What I recommend is a hybrid of these implementation methodologies, which we'll cover as we get further into the book.
Waterfall and Sure Step
Let's start with the oldest and most common methodology used in business application implementations—the Waterfall methodology. Born in the late 1950s, this was the first known implementation methodology and became more commonly known and implemented after 1985. The Waterfall methodology is a step-by-step methodology that tries to keep all of the activities in linear order from start to finish. You start with the Analysis phase, finish all of its elements, and then you move on to the Design phase. You then do all of the Design phase work and then move forward to the Development phase, and so on. In the Waterfall methodology, you are not supposed to work ahead and take on a future task outside of your current phase. The Waterfall methodology is a good fit for an ERP implementation because, in many ways, you do need to work through things in chronological order. You need to define your account structure, customer structure, your products, and other master data that you want to be able to set up early on in a project.
In the decade of the 2000s, Microsoft suggested that all Dynamics implementations follow its Sure Step Methodology, which was a Waterfall-based solution (see Figure 1.7).
As you can see, it starts with the Diagnostic phase and then moves to the Analysis phase, the Design phase, the Development phase, the Deployment phase, and finally the Operation phase.
In my days at Microsoft, I learned and used this methodology quite a bit, and it contributed to many of the documents in the Optimization section, as my team was focused on project governance, health checks, and workshops. Partners and Microsoft Consulting Services were directed (but not mandated) to use this methodology, so you saw a lot of adoption, especially in the 2007–2011 time frame.
During that time, a shift started to occur. It began with the Microsoft Consulting organization, as they realized that they needed an implementation that was more flexible than the rigid Waterfall approach. Microsoft started implementing some of the Agile concepts into the classic Waterfall approach, and that is when I realized that there was a better way. Microsoft stopped actively recommending Sure Step and stopped any further development on the methodology. The latest version dates back to 2010, so you can certainly review that information with the knowledge that the content is quite dated.
Customers and partners can find additional resources on Microsoft's CustomerSource site (mbs.microsoft.com/customersource/northamerica). Tons of document templates are available that can prove valuable on projects. You can certainly mine for treasure in the database without following it step-by-step.
FIGURE 1.7 Microsoft Dynamics Sure Step Methodology
Agile and Scrum
The Agile methodology was born from a meeting in 2001 between 17 IT professionals who felt that there was a better way than the stagnant Waterfall methodology. They wrote the Agile Manifesto, which includes 12 principles for developing software efficiently and effectively. The manifesto has four parts (see Figure 1.8):
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
FIGURE 1.8 Four parts of the Agile Manifesto
The Agile methodology is the opposite of the Waterfall methodology. It's designed to get software designed, developed, tested, and released quickly. This is great for web development or incremental development on top of a core platform, but it doesn't perfectly fit an ERP or CRM implementation because some components need to be done in a certain order.
The Scrum methodology takes the Agile Manifesto and puts it into action. Many great concepts are included in Scrum that help any type of implementation. We'll get into greater detail in Chapter 6, “Sprints and Tools Needed to Run Your Project,” but a sprint is a Scrum tenet that breaks activity into a two- or four-week cycle that you use to plan out your work. This allows you to manage a product backlog, which is everything you need to do on a project. From this product backlog, you assign activities to each sprint and that becomes your sprint backlog. The backlog provides a good idea of how much should be accomplished during a two-week period, and it creates urgency and accountability on a regular interval instead of everyone staying up all night for two weeks straight to get ready for a go-live.
I really like how sprint planning provides the ability to break the project into pieces that can be understood and managed. When you are estimating software development time, you never want someone to say 800 hours because this means that they have no idea how long it will take. If you say “there are several different components of the project, some I estimate at 8 hours, others I estimate at 40 hours, and collectively it comes to 800 hours,” I will believe you because you've taken the time to break it into great detail. In an ERP or CRM implementation that is going to take a year, you have to get a better breakdown of the work to know if your projected timeline is anywhere close to being accurate.
Triple Constraints
One final concept that I want to establish early is this idea of triple constraints. To understand this concept, you need to think about a triangle where the three sides are cost, scope, and time. Quality is in the middle, and it is impacted if you shortcut any of the other sides (see Figure 1.9).
FIGURE 1.9 Triple constraints concept
The way the triple constraints concept works is that you want to find an equal balance between scope, cost, and time. At that equilibrium point, the project quality will be good. If you decide to add to the scope of the project, you have to add cost and time to the project as well to maintain quality. If you decide to decrease time (you want the project done faster), then you have to decrease scope (and cost) to achieve your objective without compromising quality. If one side of the triangle expands, at least one of the other two sides must also expand, but not necessarily both. Another way to look at it is once two sides of the triangle are set, the other side is locked in. Once you have settled on scope and budget, your timeline is something that could be calculated as seen in Figure 1.10.
FIGURE 1.10 Triple constraints with decreased cost
Figure 1.10 shows how the triangle starts in equilibrium. You have a reasonable scope for budget (cost) and time to implement the project. Hopefully, all projects start that way. In Figure 1.10, you decrease cost, and, in that case, you have to decrease time (because consultants will continually bill during the time) and then you're going to sacrifice either scope or quality. If you decrease scope, you can preserve quality, but the amount of benefit you get from the project is less. If you maintain scope, you are basically saying that you're not going to test the solution thoroughly, or you're not going to train people and you're going to hope for the best once it goes live. You are increasing the odds that the project would result in a disaster.
Figure 1.11 shows a larger triangle. This is the scenario where you increase scope and therefore increase time and cost. Again, if you try to increase scope without increasing time and cost, you're diminishing training and testing and increasing the odds that the go-live could be a disaster.
FIGURE 1.11 Triple constraints with increased scope
The Bottom Line
Organizing your project in sprints
One of the key elements of the Agile and Scrum implementation methodologies is the concept of using a sprint to create interim deadlines within a project to make sure that you can deliver the full project on time.
Master It
What is the first thing you do during a new sprint?
Run a retrospective
Do a planning session
Do a review session
Outline the following sprints
Waterfall methodology
The Waterfall methodology is the classic way to execute on an ERP or CRM implementation, but I recommend that you use a hybrid of the Waterfall and Agile methodologies for your project.
Master It
What is a part of the Waterfall methodology?
The implementation is done in a step-by-step process
Sprints are used
New requirements are placed in the backlog
The Create phase
Sure Step
Microsoft put together a methodology in the early 2000s called “Sure Step,” which was widely adopted for Dynamics implementations during the 2000–2015 period.
Master It
Microsoft Sure Step follows which methodology?
Agile
Scrum
Client Journey
Waterfall
Challenging projects
ERP and CRM implementations are challenging projects that often go over time and over budget. The goal of this book is to prepare you better for a project so that you can complete it on time and within the budget.
Master It
What percentage of implementation projects go over budget?
100 percent
60 percent
40 percent
20 percent
Triple constraints
The triple constraints diagram is a triangle that represents a common concept in project management which shows how a change in one of the sides of the triangle affects the other two sides.
Master It
Which of the following is not part of the triple constraints of project management?
Cost
Scope
Sprint
Time
Chapter 2What to Do Before You Begin a Project
I could use lots of quotes before beginning a project: “Failing to plan means planning to fail” or “You'll never have to recover from a fast start” are two that come immediately to mind. You'll hear me repeat this over and over again throughout this book—the earlier you think about the steps of the project and prepare for them, the better off you will be. This starts way back at the beginning, even before you've committed to do an ERP or CRM implementation. If you can home in on what you want to do and who's going to do it, you can get work done before the project starts, and this can save you a considerable amount of money in the long-term.
This chapter is squarely in the Align stage, as you align your leadership and project team before you seek out an implementation partner. Smart companies take the time to get on the same page before the project begins. I have rarely seen a company execute a pre-implementation project that puts them in a better position to succeed with their implementation … but you can be the exception to the rule.
AFTER YOU COMPLETE THIS CHAPTER, YOU WILL BE ABLE TO DO THE FOLLOWING:
Identify your project team and stakeholders
Identify your processes in scope
Clean up your data
Define your success metrics
Build your business case and secure funding
Identify Your Project Team and Stakeholders
Let's start by figuring out who from the company is going to lead the project and who will be serving on the team. If you figure this out ahead of time, you can have this team play a big role in the selection of the business application platform. This makes for a more effective transition as you start working on the project. Several roles are outlined, as shown in Figure 2.1; however, not all implementations require each role. Let's discuss each role and figure out which ones fit for your size company and the complexity of your project.
FIGURE 2.1 Implementation core roles
Executive Sponsor
The executive sponsor is the person who takes overall accountability for the project. The executive sponsor reports on the progress of the project to the CEO. As it relates to the project, the executive sponsor spends their time managing project resources and communicating updates to leadership and the company as a whole. The project owner reports to the executive sponsor for the purposes of the project. (The owner doesn't have to report to the executive sponsor on the organization chart.) The executive sponsor doesn't work on the project 40 hours a week, or code anything. The executive sponsor's job is to put the right team in place, manage the executive relationship with the implementation partner, and remove blockers for the team.
In a small company, the executive sponsor should be the CEO. The CEO is the one ultimately responsible for the success of the project and needs to answer to the board on its progress. In a large company, the executive sponsor can be someone on the company's leadership team, oftentimes the CIO. My preference would be the Chief Operating Officer (COO) or the VP of sales and marketing—the actual business owner for where the digital transformation is going to take place. You can rely on the CIO to be a business partner on the project, but it's really the COO who is most affected by the process change that comes with the project, so they should be leading it.
Project Owner
The project owner is the most important role to fill on the project, and I find it fascinating that most projects don't have someone in this role. Many projects have a project manager, an executive sponsor, a core team, and IT resources, but they don't have anyone holding it all together and making decisions to keep the project moving. Having one central, authoritative resource running the project is the best way to be successful.
