The Importance of Roadmapping

DateAugust 28, 2018

Having heard from our migration team’s Taskmaster, Libby Holmes, about the importance of the Proven Process, it’s only fitting we dive deeper into PowerObjects’ experience with the Plan for Success phase.

What happens during this phase in a “normal” project?

By this point in an ordinary project, several things have already taken place during the earlier Evaluation phase. Most notable is that a preliminary statement of work (PSoW) document has been signed. From that point, the project is passed from Sales to our Delivery Team, who work to create a plan ensuring the needs of all stakeholders are addressed. This ensures the project is on track to be successfully completed. This phase focuses on project team training, identifying training and change management plans for the project, business process analysis, and really looking at everything to create a detailed project scope document (DPSD).

Another common deliverable from the Plan for Success phase is the project roadmap. Larger projects – especially those involving more connected systems, multiple org environments, and different business units – will often have a roadmap completed. While the roadmap plays an extremely useful role for the project team, not all projects require one to be successful, and the sales and pre-sales process is used to help identify this need.

What We Re-Learned

PowerObjects has teams of experts who spend all day every day working in Dynamics; we’ve literally had teammates plan their weddings using the software! That said, we also had an ambitious timeline, and as Justin O’Connor, the Workstream Wizard, pointed out: we try to move in sync with what our clients want. Therefore, we went to work on this ambitious timeline and project requirements, but we bypassed the roadmapping phase for our project. It’s important to point out that with our customers, we would have avoided this through our pre-sales process. As Libby pointed out in an earlier post, one of the biggest challenges in the early project stages is having to slow the customer down – which, in hindsight, we should have done with ourselves.

It’s not fun to be the one encouraging a project team to slow down to consider all the moving pieces, but it’s critical to the success of the project. There’s excitement in an upgrade, and those involved in the project planning from the client side are typically eager to get their hands on a brand-new system. Our project teams play a critical role in pressing the brakes, reminding the customer that it’s important to take lots of time upfront to plan. As it turns out, a company fully staffed with Dynamics experts who work in Dynamics all day everyday was particularly eager to hit the gas!

Knowing our team does this all day everyday gave us the impression we didn’t necessarily need a roadmap. We’re playing both partner and customer in this project, so our project team is also eager to get their hands on the new tool. We didn’t pump the brakes to roadmap, and in retrospect, it would have been helpful. As we’ve begun to move into the Design, Build, and Validate phase, Justin said he now wishes we had a roadmap. He believes there are some areas it would have helped clarify.

Despite this, Justin points out, that no harm came to the project or timeline by not having a roadmap in our case, but with so many parts of our business using our environment in such different ways, the roadmap would’ve helped with managing expectations and setting a goal for where we want to be with our system by a given date.
So what exactly did we learn? We thought by playing both customer and partner we could bypass the roadmapping process. In reality, it became that much more valuable because our team has been eager to make this move as soon as possible. As a result, we’ve reminded ourselves why we believe roadmapping belongs in many of our projects with customers. We want to instill confidence in the project, the project team, and the stakeholders who may not be directly involved but are impacted by the upgrade or implementation, and roadmapping is the perfect way to do that.

The Process Was Proven.

This site is meant to document the ups and downs in our move to the Cloud. Unfortunately, we didn’t create a roadmap, and we’ve now had the chance to see firsthand why it has long been built into our Proven Process for customer projects. Our Proven Process is the result of decades of work and on-the-job learning. As a company, we strive to drive success for our customers, and we’re thrilled to have had the opportunity to remind ourselves that when we stick to this process, it does just that. When you work with PowerObjects, you’ll be guided through our Proven Process because we have firsthand tested and proven it to work.

To see more of the Proven Process in action, check back often for more updates as we move to the Cloud!

Happy D’365’ing!

Q&A with the Taskmaster

Next Post

Taking out the Trash

Related

Evaluation Process

Q&A with the Taskmaster

Evaluation Process

The People Behind the Process

Evaluation Process

Off We Go!

About Our D365 Migration Story

At PowerObjects, one of our guiding principles is to Live the Technology. That ideal has helped us become a leading Global Systems Integrator for Microsoft Business applications through the lens of Microsoft Dynamics 365. This has kept us busy at work helping customers achieve their Cloud vision. So, what’s next for us? Well, we set our sights on the skies, sort of, as we make our own move to the Cloud.

PowerObjects is migrating our existing on-premises Dynamics platform to Dynamics 365 Online. We’ve always said that we are our BEST case study for Dynamics success, and by taking advantage of the robust online features, marketing automation capabilities, and reporting functionality (just to name a few), our goal is to prove even further how passionate we are about Dynamics 365 as a business application.

Follow us on our migration journey in this interactive microsite. We’ll be providing updates, behind the scenes peaks into the progress, and insight into both the highs and sometimes lows of an implementation. We hope you enjoy our story!