When implementing Dynamics 365, defining the project’s scope will be key to whether the implementation is considered a success or a failure. The scope is important as it defines what is to be accomplished and what is outside the parameters of the project.
The Project Management Institute defines the scope of a project as all the work performed to deliver a product with the specified features and functions.
While this is a straightforward definition, there are also other things to consider when you scope your Dynamics 365 project. This blog post will walk you through everything that should be considered when you’re defining the scope of your project.
Why is it important to define the scope?
- The project scope sets expectations with all the stakeholders about what the project is implementing.
- The project scope helps control the project’s cost and schedule by defining what will be implemented.
- The project scope helps define why you are implementing Dynamics 365 and the benefits of the implementation.
- The project scope helps define the process by which the team can change the scope of the project.
Factors that will help make a project scope Successful?
- Defining the scope is a collaborative effort and should not be left to a single individual to define. You should include future users, management, and IT staff in creating and reviewing the project scope. Creating the scope in isolation can result in costly reworks, change orders, and a Dynamics 365 system with unwanted features.
- Creating the project scope will be an iterative process. There should be drafts and versions until the required stakeholders have all signed off on the project scope.
- The project scope can change after everyone has signed off. However, changing the project scope impacts the timeline, budget, and project resources. Documenting how to change the project scope should be clear for all stakeholders.
- The type of Dynamics 365 project should be kept in mind when defining the scope. For example, implementing a brand-new Sales application when the sales team currently does not use any application will have different needs than migrating from Salesforce to Dynamics 365 Sales or migrating from Dynamics GP to Dynamics Financials.
- In every project, there are always a finite amount of resources available, and the result is not that everyone will have every feature implemented that they want. A great way to address this is to consider a phased approach for your implementation.
Step 1 – Define the Drivers Behind Implementing Dynamics 365
Project drivers answer the question about why you are implementing Dynamics 365. Defining why you are implementing Dynamics 365 provides a framework for the stakeholders when creating the rest of the project scope. Examples could be our current CRM system is outdated and no longer meets our needs, we don’t currently have a CRM system, or we need to reduce costs. At this point, you can also identify the project’s budget, who owns what, and who will be held accountable for the project.
Step 2 – Project Objectives and Success Factors
Project objectives and success factors will be the actual desired results you want to achieve after the project is completed. These factors should focus on outcomes. Examples of project objective and success factors are:
- After implementing Dynamics 365 the average handle time per call will be reduced by 20 seconds within 90 days.
- The percentage of leads that are converted to an Opportunity will increase by 5% within 6 months of implementing Dynamics 365.
- The sales executives will be able to track Contacts, Leads, and Opportunities when Dynamics 365 is implemented in April.
Each of these should be SMART (specific, measurable, aggressive or attainable, realistic, and time-sensitive) goals.
Step 3 – Identify Functional Areas and Project Stakeholders That Will Be Impacted
During this step, you should define which areas of the business will be impacted by the implementation.
For example, if you plan to implement Dynamics 365 Sales, you would include the sales team and then work to identify the key stakeholders from that team that will help with the implementation.
You will also want to identify functional areas that will be impacted, such as the training team if training is required, the IT department, or any other functional area that the Dynamics 365 implementation could have an effect on.
Step 4 – Identify and Prioritize Features and Functions
Work with stakeholders to identify, document, and prioritize features and functions they need from Dynamics 365. Hosting brainstorming sessions with stakeholders is a great way to gather these.
There are a couple of methods that you can use to do this with the stakeholders. One method is to have the stakeholders show you the current system they use. Users can tell you during the session what they like and do not like about it.
After the user has demonstrated the current system, you could then demonstrate similar functionality, if it exists, within Dynamics 365.
A couple of things to consider about these sessions:
- These sessions should be a safe place for stakeholders to express themselves on issues with the current system. If users hold back information, you may miss important functionality.
- Expectations need to be clearly conveyed to all stakeholders that the list of functions and features will be prioritized, but not everything will be implemented. This is where having a phased implementation can help keep stakeholders engaged as it provides a mechanism for future features and functions to be implemented.
- These sessions need to be collaborative, and every stakeholder that attends should be encouraged to actively participate.
- Discuss common functions and features within Dynamics 365 that are often customized—such as forms, views, reporting, security, and navigation.
You can use several different methods to document these features and functions for the team. For example, if your team follows Agile, you can use a product backlog and user stories.
The important thing is to make sure you have engaged all the stakeholders and functional areas impacted by the implementation, and there is agreement that when documenting the feature or function that it was documented correctly.
Also, while gathering these requirements, you will want to note how necessary a feature is and what impact it has. There are several ways to do this. One is to rank each feature on a scale of one to five with one as a “must have” feature and five as a “nice to have feature.” You can use the same scaling method to record the impact of the feature.
Documenting each feature and function this way will help provide an easy way to prioritize what will be implemented and provides a list of future features and functionality that can be implemented after the project is completed.
One final item to evaluate for each feature or function is how will they affect the desired objectives of implementing Dynamics 365. If a goal is to reduce a call center agent’s handle time, but a feature was requested that will cause this to be increased, then there is a chance the project will not be considered successful.
Identifying these issues early will help facilitate discussions with the stakeholders and may result in either the objectives being changed or the feature being re-prioritized.
Step 5 – Define what is Out of Scope
Defining what is out of scope is just as important as defining what features and functions are within it. While listed as step 5, defining what is out of scope occurs throughout the process of creating your Dynamics 365 scope. Examples of out of scope items could be:
- Dynamics 365 will be implemented for the finance team only. Future phases will look at implementing Dynamics 365 for the sales and operations teams.
- Case history from the current system will be archived and not migrated to Dynamics 365.
- The sales team uses a custom quoting system. Configuring the Quote entity is out of scope.
Defining what is out of scope will help prevent scope creep and set expectations with stakeholders about what is not going to be implemented.
Step 6 – Define Scope Change Management
What is the process by which you can change the scope of the project? Change is inevitable and being able to evaluate, document, and review the change will help make the project successful. The process for changing the scope could be as simple or as complex as required but it needs to be defined. This process should include the following:
- Who is responsible for determining the impact of the change on the project’s resources, schedule, and budget?
- What mechanics are used to document the change and the impacts of the change?
- Who is responsible for approving the change?
Step 7 – Scope Review and Approval
The last step is to have the scope reviewed and approved by the required stakeholders. The scope approval process can be in person, virtual, or electronically. Typically sharing the final draft with the required stakeholders and hosting a virtual or in-person meeting is effective at gaining approval.
Conclusion
Creating a project scope for your Dynamics 365 project is important to the success of the project. A collaborative process that encourages stakeholders to provide input and feedback about the project scope is extremely helpful in making sure you have defined everything within the project scope. Lastly, ensuring the project scope is reviewed, approved, and has a mechanism for change will have everyone on the same page and working towards a successful implementation.
