infotech
Before you begin
Three things to keep in view.
- Agree the business process and its owner before defining the application scope.
- Use realistic scenarios to review standard capabilities, migration and readiness.
- Make adoption and support part of the delivery plan from the beginning.
Start with the decision, then the system
Bring the business owners into the conversation early. Agree which operational problems the project should address and how you will recognize progress. A shared definition of success gives the implementation team something useful to work toward.
Make the starting point concrete. If the priority is a more reliable close, describe the current delays and the decisions that depend on the figures. If it is a better service experience, identify where customers repeat information or wait without an update. A specific problem helps the team distinguish essential work from attractive but unrelated features.
Put it into practice: Name the operational outcome and the person who will confirm it.
Name the processes in scope
Write down the complete journeys that matter: from an enquiry to a paid order, or from a service request to a resolved case. Identify where those processes cross departments. Microsoft’s Business Process Catalog provides a common starting point for this discussion.
A process map should include the handovers, not only the tasks within one department. Identify what triggers the work, which information moves and who accepts responsibility at each stage. Record the common exceptions as well. This makes scope easier to review and gives testing a useful structure later in the programme.
Put it into practice: Trace one complete transaction across every team it touches.
Understand the standard capabilities
Walk through the standard product with the people who do the work. Separate an essential business requirement from a habit inherited from the old system. Document any gap and the reason it matters before deciding how to address it.
Use a small set of representative examples during demonstrations. Include one straightforward transaction and one that exposes a real exception. When a gap appears, compare the options: configuration, a change in working practice, an extension or a different application boundary. Record the reason for the decision so it remains understandable after the workshop.
Put it into practice: Record the business reason for each departure from the standard approach.
Treat your data as part of the project
Identify which records need to move, who owns them and what needs to be cleaned up. Agree how migration will be validated. An application is only as useful as the information people can trust inside it.
Migration is also a business decision about what the new system needs on its first day. Separate active records, open transactions and required history. Define reconciliation criteria before the first trial, and have the owners of the information review the result. A completed transfer is not the same as business acceptance.
Put it into practice: Reconcile trial data using criteria agreed with its owners.
Prepare people for the change
Give process owners and users a role in testing. Plan training around real tasks, and make it clear where support will come from after launch. Adoption is something to prepare for throughout the project.
Give each role a practical way to learn the tasks it will perform. Include the unusual situations that require judgement and explain where help will come from. Before launch, confirm that business owners, support colleagues and delivery teams share the same understanding of readiness, outstanding issues and the first improvement priorities.
Put it into practice: Confirm the support handover before the implementation team steps back.
Explore Microsoft guidance
Make it specific to your business.
Bring a process, a priority or a decision you are working through. Our team can help you explore the Microsoft capabilities and implementation choices that fit.
Start a conversation