Let’s talk about scope creep…

To some extent, it’s inevitable. After all, while identifying system requirements up front is standard practice, it is really tough for clients to foresee system nice to haves until they start seeing the system in action. The key to dealing with scope creep isn’t to just ignore it. No, it must be acknowledged and carefully managed. And today’s blogpost is all about managing that scope creep. Enjoy!

Once a client determines what they need their Microsoft Dynamics 365 build to include, they need help and guidance from experienced D365 consultants. Generally speaking, PowerObjects promotes using as much out-of-the-box configuration as possible. Sometimes this can be misleading. A strictly out-of-the-box configuration means custom development isn’t part of the solution. In other words, there is no custom code – whether it be JavaScript another programming language. Let’s compare it to building a house based on the model home – when it is built, the future homeowner has some options, of course – type of fixtures, cabinets, countertops, etc. But, if the homeowner wants to deviate from the basic model, the time and cost associated with the extra design and build become very real factors. Well, the same is true with a D365 deployment. We can do just about anything, of course, but from a time and cost perspective, we try to steer each client in the direction of using as much out-of-the-box functionality as possible.

Avoiding Initial Plan Scope Creep

PowerObjects has a proven process that includes a Plan for Success phase. This is where we spend time discovering the requirements for the project. We work side by side with the client team to ensure we capture all requirements based on what the business needs/wants. When we do this, we are careful to point out what can be done out-of-the-box and what will require custom coding.

After the client agrees that all requirements are captured, we create a Detailed Project Scope Document. This document helps to estimate the efforts and cost for the project. Of course, the more detailed we were in documenting the requirements, the better we can hold the project team accountable for staying within scope – thus avoiding scope creep. We also deliver a Functional Design Document – a more detailed explanation of these efforts. The Functional Design Document is updated throughout the project lifecycle and is an artifact of what was built.

Demo Scope Creep

Throughout the project, we often demo what is being built, which allows clients to have a preview of their new system. Depending on the project management methodology being used – Waterfall or Agile – feedback can take on different forms as a result of the demo. If new items that were not considered in the Plan for Success are requested after the demo, they should go into a backlog for a future phase. However, if they are determined to be critical success factors for the current phase, the project team needs to evaluate how adding it will affect the budget and timeline and then share this information with the client before a final decision is made.

Additional requirements that emerge in the build phase – aka scope creep – must be managed very carefully. As consultants, we obviously strive to do whatever we can to make our clients happy – hey, we love getting all 10s on our client satisfaction surveys! 🙂 But on a more serious note, if the project team doesn’t carefully manage scope creep, it can turn a project upside down financially and put the timeline at risk.

So, what is our best practice for carefully managing scope creep? For starters, when we get requests for additional functionality, we discuss them as a project team. We revisit the agreed-upon initial intention to use as much out-of-the-box functionality as possible. If the new requests are not critical to the success of this release – they are put in a backlog that will be used for the next release. Essentially, the mantra is “if we wait until a solution is absolutely perfect and has every single thing the client wants, it will never be released!” The project team estimates the effort for each item in the backlog and works with the client’s project team to prioritize. Sometimes, there is extra budget remaining and the timeline allows certain items to be part of the first release.

UAT Scope Creep

User Acceptance Testing (UAT) is a critical phase of every project. Successful UAT begins with identifying testers – a group of the client’s employees who will eventually be active users in the system. Prior to the system being released to the entire user base, this group goes through test cases/scenarios and test drives the system, logging all issues they encounter. It is not unusual for the testers to log “nice to haves” that were not part of the original project. In other words, scope creep.

Once again, these extra scope items must be carefully managed by both the client and the PowerObjects team. Did we mention earlier that as consultants, we always strive to meet each client’s needs and wants? But in this case, saying “no, we can’t add that nice-to-have item right now” should really be seen as looking out for their best interest. After all, it is our responsibility to focus on the items included in the original project scope and ensure each item is working as intended and without any issues. Once again, those nice-to-have items are not simply ignored – instead, they are added to the backlog and will be revisited down the road. The project team should review the findings with the UAT team to ensure the testers understand which items are considered out of scope. They need to understand the vision of the system the client had, and sometimes the budget and timeline need to be explained, as well, in order to reinforce why a nice-to-have can’t “just be added.” It is critical that the UAT team recognize their feedback is being heard and their input will be considered in a future phase – after all, if they don’t feel their input is valued, they may not be strong early adopters of the new D365 system. On the other hand, when they feel valued and understand the potential of next steps, they will often be the biggest adoption advocates, sharing their excitement with the rest of the company.

Summary

As D365 consultants, we help clients manage their D365 builds so they can get what they need for their business while also respecting budgets and timelines. After we release their build, we give them time to use it and gather more feedback from their users. Some items in the backlog are determined to be no longer needed, whereas other items are confirmed as requirements and will be reprioritized on the list. Getting a D365 system released for our clients empowers them to begin making decisions on what will make it even better – because as business needs evolve, so too can D365 environments. But not managing scope creep carefully means delaying the release, which in turn means depriving the client of the power to begin using it and identifying how to make it even better.

The lesson? Scope creep is inevitable – to deny that is being unreasonable. But if it’s managed carefully and consistently, it can lead to improved functionality in future releases.

For Dynamics 365 tips, subscribe to our blog!

Happy Dynamics 365’ing!