The Importance of Roadmapping
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!