Methodologies
SimCrest Agile Project Delivery Framework
We have adopted the Scrum framework that allows us to delivery projects using agile principles. The framework has many benefits to our customers over more traditional waterfall frameworks that expects predictability of the future. Our framework allows us to respond better to change, deliver software early and often and collaborate better with our customer during the project execution. The result is working software that fulfills the requirements of our customer.
Delivery
Software is delivered early and often, allowing our customers to experience real value early in the project. We execute Sprints, where the most important requirements from the Product Backlog are developed into the software. Sprints are executed on an iterative basis and after each Sprint a partial delivery of the final product is typically released.
Changes
Change of scope is a natural part of a project execution. During a project our customer will experience the software and often make changes to the requirements. APDF embraces changes and allows us to quickly prioritize and place required changes into the Product Backlog.
Transparency
Our customer will be involved early and continuously throughout the project. It allows everyone to have full transparency into all aspects of the project.
Concept Phase
Here we will validate high level goals, objectives and business needs. The deliverables are the Project Charter and a Validation of the Business case. It states the overall scope, objectives and participants in the project. It provides a preliminary delineation of roles and responsibilities, outlines the project objectives, identifies the main stakeholders, and defines the authority of the project manager. It serves as a reference of authority for the future of the project.
Initiation and Planning Phase
The initiation phase (part of the Agile Project Delivery Framework) is used to define the vision, product backlog, business value and priorities of the Accelerated Business Case (ABC). The outputs of the ABC are:
Product Roadmap
Product Backlog (scope)
Target Architecture
Test Strategy
Team Capacity and Velocity Estimates
Release Plan
Risks, assumptions, issues and dependencies
The Planning phase that follows the Initiation phase is also called Iteration 0 Planning or Grooming session, where the product backlog is understood by the customer and the delivery team and prioritized by the Product Owner.
Execution Phase (Sprints)
The requirements, design, build and test are completed iteratively based on the highest business value. The most important User Stories from the Product Backlog is entered into the Sprint Backlog that subsequently is broken into tasks that are executed during the Sprint. Once the Sprint is finished the product increment is delivered to the customer if applicable/possible.
Training, product tests and implementation will also be delivered through some of the Sprints once the product reaches a maturity level that allows this to happen. This all happen according to the training, test and release plans defined in the initial planning phase and groomed in subsequent Sprints.
Sprints are iterative and repeats every 2 weeks (typically). After each Sprint and before the next Sprint, the Team reflects and improves upon each iteration.
Development
Development happens in the execution phases (Sprints) and involves a review of development requirements, final feature prioritization and resource assignment. Next, the development and test environments are set up and test plans started in the Initiation phase are finalized for each custom process.
Actual development activities can proceed concurrently, depending on the number of resources assigned. For example, feature customizations can be developed at the same time as integration and data migration processes. The development activity includes developer unit testing. It also includes Feature/Function testing performed by the consulting team. Ideally, this testing is done by someone other than the developer and follows the test plan that was previously defined.
Once the development cycle is complete for a specific customization, technical and End User documentation can be started, including any additional user training materials that will be needed. You will start Process testing using the test cases and test criteria that were defined in the Initiation phase. This testing validates feature customizations as well as integration and data migration processes.
The development and testing cycles continue until test results meet pre-defined test criteria and you are satisfied.
Deployment
Deployment happens in the execution phases (Sprints) where all the efforts of the project team come together for a successful transition to the new solution.
Activities prepare the infrastructure and application environments, as well as the End User, for the final cutover of the system. This includes the review of timelines, identification of primary roles, assignment of specific tasks, and the preparation of necessary tools and checklists. Activities in this phase will produce a Go-Live Plan with specific checklists as well as a formal Test Plan and End User Training Plan; will see the live and test environments set up and configured with some subset of the customer’s dataset loaded; fully test the system functionality and the infrastructure load capacity as well as training remaining End Users; and perform final system cutover, live data validation and transition to the next phase of the project.
During the Deployment Planning activities in this phase the implementation team reviews the Go Live activities, determines the resources needed and identifies the timeline. A Test Plan and End User Training Plan are also created at this time.
Setup and Configuration of the live environment as well as the test environment follows the Deployment Planning activities. System and User Acceptance Testing and Load Testing may produce results that require a return to activities in previous phases. Following the System Testing and Load Testing activities, a formal System Signoff will occur, acknowledging acceptance and approval to continue with the Go-Live activities.
The remaining End User training must take place as close to the final cutover date as possible so the information remains fresh in their minds.
Following the Final Data Migration, an acceptance walkthrough is done and data is validated against legacy system values. In order to launch the system, the consulting team will require approval. A meeting shall be arranged whereby the implementation team reviews the project deliverables and the critical acceptance criteria for the project are reviewed. As with all phases, documentation and approval of these steps may be required for regulatory compliance.
There will be times when systems will go live without having met all acceptance criteria. This may occur when there are external circumstances that affect the project. For example, the financial accounts may have to be run on the new system at the start of a calendar period. This means that the system must go live regardless of the acceptance criteria being met.
Closure
Once the project has been formally closed, the goal of the Operation phase is to transition the customer from the implementation project into on-going support following a successful go-live.
After the successful go-live cutover and sign-off in the Deployment phase, two concurrent activity tracks can start.
The first track includes various project closing activities related to final knowledge transfer from the project team to the customer resources. It is common to have various items still pending after go-live. It is important for you to review these pending items and agree on the final disposition. Project closing also includes delivery of final documentation, optional additional training for End Users, and final knowledge transfer related to on-going system maintenance the customer will take responsibility for.
The second track is the very important post-live support activity, which involves having consulting team members remain on the project for a period of time to make sure the new production environment is running smoothly and to ensure a smooth transition to on-going support. This is potentially a large activity that needs to be managed with a definite end date.
Optimization
The purpose of the Optimization phase is to review the existing implementation and make adjustments to increase the effectiveness of the solution.
Process
this review focuses on the work procedures that are in place for End Users and/or application and system administrators
Configuration
this review focuses on the configuration settings currently being used in the Microsoft Dynamics 365 solution
Performance
this review focuses on hardware, networking and infrastructure issues that may be impacting amount of time required to complete various work procedures or general system availability.
If the Optimization Analysis activities identify that the required modifications go beyond simple to moderate adjustments, it is recommended to define a complete implementation project starting with the Diagnostic phase. If the identified changes are more minor, the next step in the Optimization activity flow is to make a proposal to the customer for the changes that are being recommended.
The next set of activities relates to implementing the business process, configuration, or infrastructure changes that were proposed. These activities will be similar to other groups of activities throughout the rest of the methodology, depending on the actual circumstances.
After the changes are made and tested, and all outstanding issues have been resolved, the changes are moved into the live production environment in a go-live cutover procedure similar to the Deployment phase.
Upgrade
The upgrade phase allows you to improve your current Dynamics 365 Business Central solution by moving up to the new and improved version of the application. New features and functionalities will be introduced with the new version. Training will be provided to prepare the End Users on how to use the upgraded version of the solution.
The phase starts with analysis and planning activities that are designed to gather enough information to determine the size and scope of the upgrade effort.
If the Upgrade Analysis activities identify that the upgrade will include reassessment of business processes and/or the addition of new modules, it is recommended to define a complete implementation project starting with the Diagnostic phase. If it will be a basic upgrade of existing software applications, the next step is to make a proposal to the customer for the work required to perform the upgrade.
The next set of activities relates to performing the actual software upgrade, upgrading data, and training Key Users who will be involved with testing and possibly assisting with the training of other users. These activities will be similar to other groups of activities throughout the rest of the methodology, depending on the actual circumstances.
If system and user acceptance test results do not meet pre-defined criteria, it becomes necessary to review the cause of failure and make appropriate adjustments to either the software or the data that were upgraded. When all testing has been successfully completed, the next step is to conduct End User training, followed by the actual go-live cut-over, similar to the Deployment phase. The final step is customer acceptance and signoff on the upgraded system.
After successful go-live, the customer moves into operation mode with the upgraded environment, taking advantage of the new features and functionality that come with the upgraded version. At this point the customer signs off on the completion of the Upgrade phase.
Actual upgrade tasks to be performed in this phase may vary to some extent, depending on the needs to be upgraded. This may include specific tools that need to be run, the upgrade process and the preparation that needs to happen before the upgrade.