80199 enus erp_04

Chapter 4: Project Execution and Monitoring During the Design, Development, and Deployment Phases

4-1

CHAPTER 4: PROJECT EXECUTION AND MONITORING DURING THE DESIGN, DEVELOPMENT, AND DEPLOYMENT PHASES Objectives

The objectives are:

• Examine how to plan early for the Deployment phase by creating a deployment plan.

• Learn how to use solution design documents. • Examine Performance Reporting • Examine Status Reporting • Plan and perform testing activities across different phases. • Conduct a Tollgate Review • Prepare and conduct the cutover from the non-production to the

production environment.

Introduction Project execution and monitoring covers all the activities a Project Manager must be concerned with during the execution phases of an implementation project for a Microsoft Dynamics™ ERP solution.

Each project requires the Project Manager, in collaboration with the project team, to determine what activities and processes are appropriate and to what extent each activity needs to be conducted.

The following list is an overview of project management activities from the different project management disciplines that are performed during the execution phases of a project, including Design, Development, and Deployment.

• Plan and perform quality assurance • Plan and perform quality control • Monitor and close purchase and acquisition • Ongoing risk management • Ongoing issue management • Manage project scope • Ongoing time and cost management • Project communication • Develop and manage a project team

Microsoft Official Training Materials for Microsoft Dynamics ® Your use of this content is subject to your current services agreement

Project Managing Microsoft Dynamics® AX, Microsoft Dynamics GP, and Microsoft Dynamics NAV Implementations with Microsoft Dynamics Sure Step 2010

4-2

Design Phase

The goal of the Design phase is to define how the customer's business requirements will be implemented. This phase includes configuration of the overall Microsoft Dynamics ERP solution, the design of specific customizations needed to satisfy business requirements, and the technical design identified during the Analysis phase.

FIGURE 4.1 DESIGN PHASE TIMELINE



4-3

Development Phase

The goal of the Development phase is to build and test the system components defined and approved in the design specifications, including developing the customizations, integrations and interfaces, and data migration processes.

FIGURE 4.2 DEVELOPMENT PHASE TIMELINE



4-4

Deployment Phase

The Deployment phase is where all the efforts of the project team are used for a successful transition to the new Microsoft Dynamics ERP solution. Key activities in this phase include End User Training, Performance Testing and User Acceptance Testing, and the actual cut-over to the new production environment.

FIGURE 4.3 DEPLOYMENT PHASE TIMELINE



4-5

Project Planning Project Planning is a recurring activity executed in all phases of the project. This means that the Design, Development, and Deployment phases will all include a planning activity.

The purpose of Project Planning in these phases is to monitor and track progress against the plan and to perform necessary adjustments to the plan based on changes to the scope, timeline, and resources.

Project planning involves updating the project plan to accurately reflect the timeline, resources, and milestones based on any changes that have occurred to the scope.

Project planning in the Design phase may also involve the creation of the Deployment Plan based on the project type and individual project requirements. The Deployment Plan involves the activities that need to occur to facilitate the rollout of the system to the end user base.

Project planning also involves updating the project financials on a weekly basis to manage the budget and accurately reflect the financial status of the project.

The Deployment Plan

The Deployment Plan outlines the activities that need to occur to perform a successful rollout of the application to the user base.

The Deployment Plan is created by the Project Manager and needs to outline the process and activities that will occur during the Deployment phase of the project.

The Deployment Plan is initiated during the Design phase to provide sufficient time for the project team to consider the deployment activities. It is a living document that needs to be constantly updated with feedback from the team.

The plan lists all the key tasks needed for a successful rollout of the application. These tasks include the following:

• Environment Setup • Data Migration • User Setup • End User Training



4-6

Lab 4.1 - Create the Deployment Plan The purpose of this lab is to emphasize the importance of considering the deployment activities early in the planning process. Microsoft Dynamics™ Sure Step advocates starting this process during the Design phase to allow enough time for all project team members to consider and respond regarding to the necessary aspects of the plan.

Scenario

The Analysis phase is complete and the start of the Design phase is being planned. The results are received from the in-depth analysis performed at Tailspin Toys, and there is an accurate view of Tailspin Toys' requirements for the Microsoft Dynamics ERP implementation. Based on this information you compiled a high-level project plan and received approval from Adam Carter to proceed with the project.

Since this is a fairly complex situation, Tailspin Toys is located in different geographical areas and the implementation involves nearly all their departments, it is time to create a more detailed plan for the Design, Development, and Deployment phases.

In the project lifecycle, it is now May 27, 2010 and the project is being planned. Use this lab to consider the deployment activities so they can be included in your project plan.

Goal Description

Envision the necessary activities for the Deployment phase and formalize this in the Deployment Plan.

Remember that the Deployment Plan is a living document and will be updated beginning with this lab.



4-7

Step by Step

Step 1 - List all deployment activities.

1. Which deployment activities are necessary? List them here.

Step 2 - Read the relevant information below.

The path toward Go-Live needs to be made as smooth as possible. The meetings at the end of the Analysis phase generated some general goals of Tailspin Toys regarding the further progress of the implementation.

Tailspin Toys is located in different countries, with their headquarters in Liverpool, where most of their activities are managed centrally. Only warehouse activities are diverted to Boston and Hong Kong. However, these separate locations are networked remotely onto the central server, which is located in Tailspin Toys' Liverpool headquarters.

As agreed upon, Tailspin Toys' internal IT Department will handle the infrastructure and there is no need for you or your team members to travel to Boston or Hong Kong.

Preparing the different non-production and the production environments will be Mike Nash's full responsibility. He will validate information, finalize the date/time schedule for the installation, review user and staff procedures, and notify the department of actual activity dates. However, during the installation and stabilization process assistance will be provided by preparing the software for installation, verifying that the solution works for the users, and monitoring defects on a regular basis.

Tailspin Toys decided that with the installation of the Microsoft Dynamics ERP solution, the legacy system will immediately be shut down so that the users will be forced to work with their new ERP application. This approach stresses the importance of thorough testing and training before going live. Throughout this process Trey Research will remain at Tailspin Toys' disposal through all the normal channels as stipulated in the beginning of the project in the Communications Plan.



4-8

Although the diversity in locations is not an issue, the size of the different departments poses a problem. The project team has been selected. However, there are not many resources at your disposal. Therefore, there is little room for parallel planning of activities, known as fast tracking. Since it might take too much time to wait until all requirements are translated into design specifications and for all custom code to be developed for all departments at once, Adam Carter agreed to handle the deployment per department or per business area.

This means each of Tailspin Toys' team members is responsible for follow-up, testing, acceptance, and sign-off from their department and their particular expertise. Before the actual Go-Live date, these same people must receive customized training on time concerning both the standard functionalities and the custom code. Further end-user training is not expected from Trey Research, since this will be organized by Tailspin Toys' team members after their Train the Trainer sessions.

Tailspin Toys team members

Responsible for Training required

Adam Carter General Overview

Mike Nash • Administration/Security • Integration and Interface • Data Migration • (Infrastructure; handled

internally)

• Introduction - 1 day

• Security - 1 day

Peter Houston • Finance, Bank/Cash Management

• Fixed Assets, AR/AP • Reporting


• Finance - 5 days

Russell King • Trade - Purchase • Inventory/Logistics • Quality Control • Reporting


• Trade - 5 days • Quality Control -

1 day

Shawn Richardson • Trade - Sales • Inventory/Logistics • Customer Service • Quality Control

Reporting


• Trade - 5 days • Quality Control -

1 day • Customer Service

- 1 day



4-9

Step 3 - Locate and open the Deployment Plan.

Review the content and layout of the Deployment Plan available in Microsoft Dynamics Sure Step.

HINT: You will find the Deployment Plan activity and template in the Design phase for Enterprise projects, under Project Planning.

Step 4 - Create the deployment plan for Tailspin Toys.

Try to formalize the information provided in Step 2 in the relevant sections of the Deployment Plan. Concentrate on the areas you feel are most critical to the plan.

2. What questions still need to be answered to complete the deployment plan?



4-10

Lab 4.2 - Update the Project Plan The purpose of this activity is to ensure that the project plan is kept updated with any changes to the timeline, resources, and milestones based on any changes that have occurred to the project.

Scenario

You are still in the same scenario as outlined in Lab 4.1.1.

It is May 27, 2010 and you are planning the project. This involves not only the creation of the deployment plan, but the updating of the project plan with all the information from the previous phase and specific planning for the current phase.

Goal Description

Any changes that have occurred to the project can have an impact on the project plan. As the Project Manager you need to identify these changes on a weekly basis and reflect the impact on the project plan.

Step by Step

Step 1 - Identify changes that have an impact on the Project Plan.

1. Were there any changes identified during the Analysis phase? If so, what impacts will these events or changes have on the project plan?



4-11

2. Examine the project plan for a standard project type. Which elements of the breakdown structure will need to be updated to achieve the planned change?

3. What other events can trigger a need for updating the project plan?

Step2 - Examine the Updated Project Plan.

During the project lifecycle (Design, Development, and Deployment phases) the Project Plan for Tailspin Toys is continuously updated. This updated Project Plan is available to you.

4. From the updated Project Plan identify the duration for the Design phase.



4-12

5. From the updated Project Plan identify the duration for the Development phase.

6. From the updated Project Plan identify the duration for the Deployment phase.

7. At the (planned) end of the Deployment phase, what is the duration from the start of the project?



4-13

8. Which phases and specific activities are related to the delivery of the Functional Design Documents (FDD)? On which dates are these activities planned?

9. Which activities involve Testing and when are these planned?

10. What tasks related to data migration are found in the different phases? When do they occur?



4-14

11. When is the Go-Live date for Tailspin Toys, and in which phase does it occur?



4-15

Solution Design The goal of the Design phase is to define how the business requirements will be implemented. The phase includes configuration of the overall Microsoft Dynamics solution and the design of specific customizations needed to satisfy business requirements identified during the Analysis phase.

Solution Design deliverables may include the following:

• Functional Design Documents (FDD) for Fits (Configurations) • Functional Design Documents (FDD) for Gaps (Customizations)

o FDDs for Requirements identified as Gaps in Standard Solution o FDDs for Integration and Interface Requirements o FDDs for Data Migration Requirements

• Technical Design Documents (TDD) • Solution Design Document (SDD)

The Project Manager decides which of these Solution Design deliverables to use in the project based on the project type and needs.

Functional Design Document

The Fit Gap Analysis activity results in the generation of the Fit Gap Spreadsheet. This is used to determine the business requirements fits that can be met by either the Microsoft Dynamics ERP solution or industry-specific solutions, or the gaps that can be met with custom code development.

Documenting fits in the Functional Design Document (FDD)During the Design phase the Application Consultant will work closely with the appropriate key user. Together they will document the configuration and parameter settings required for the standard functionality and ISV solution(s) to fully meet the business requirements. This is documented in the FDD.

The template is referred to as the Functional Design Document Configuration.

In this template, document the following information:

• Business Overview • Business Requirements • Solution Overview • Setup and configuration • Test plan



4-16

Documenting gaps in the Functional Design Document (FDD)The Application Consultant and appropriate key user will begin documenting business requirements which will be met with custom code development. These requirements are referred to as gaps. This is also documented in the FDD.

The template is referred to as the Functional Design Document Customization.

In this template, document the following:

• Purpose and background of the modification • Considerations and Justifications • Modifications to Forms • Modifications to Tables • Modifications to Processes • Other Modifications • Error handling • Test Scripts

Technical Design Document

The sections of the FDD containing the custom code development become the input to the creation of the Technical Design Document (TDD). In contrast to the FDD, the Development Consultant is responsible for the creation of the TDD which provides the detailed technical information to begin the development effort.

The goal of the Technical Design Document (TDD) is to define and document the technical details of each system modification or enhancement. The creation of comprehensive TDD documents is essential to the effective and efficient execution of subsequent development activities. These documents provide the roadmap for development and reflect the Functional Design that is approved by the customer for implementation.

Solution Design Document

The purpose of the Solution Design Document (SDD) is to allow the Business Decision Makers and other stakeholders to obtain a clear view of the proposed solution flow. As such, the SDD provides the overall solution description in business language, and includes the capabilities being enabled by the solution.



4-17

Information Flow from Functional Requirements to Design Documents

The following graphic illustrating the information flow from functional requirements to design documents is located in the Additional Resources node of Microsoft Dynamics Sure Step.

FIGURE 4.4 INFORMATION FLOW - FUNCTIONAL REQUIREMENTS TO DESIGN DOCUMENTS

As the Project Manager, decide which design documents to implement for your specific project. Microsoft Dynamics Sure Step will suggest the documents to be used based on the project type selection.

There are different options including the following:

• Implementing the complete set of all design documents. • Implementing specific documents only.



4-18

• Implementing FDDs and TDDs for each GAP and each FIT. • Implementing various combinations of these documents.



4-19

Lab 4.3 - Create a Fit Design in the Functional Design Document

During this lab you examine how to document the configuration and parameter settings required for the standard functionality and ISV solution(s) to fully meet the business requirements.

Scenario

The design of the Fits and the beginning of the standard system configuration starts on June 1, 2010. By now, the necessary non-production environments are setup. Brian Burke and Jim Wilson are part of the Trey Research team responsible for the solution design. They will work closely with the key users of Tailspin Toys.

It is decided that the team will document the Fit and Gap design in different functional design documents. Furthermore, each Fit and Gap will be documented in a separate Functional Design Document.

Goal Description

The goal for this lab is to examine the Functional Design Documents Configuration. In this template, the Fit design for Tailspin Toys is already configured.

Step by Step

Step 1 - Locate the Functional Design Document Configuration for Tailspin Toys and review the content.

1. How many requirements are handled in this FDD?



4-20

2. What is the requirement being addressed in this FDD?

3. Which solution is chosen for this specific requirement?



4-21

Lab 4.4 - Create a Gap Design in the Functional Design Document

Different Gaps are identified during the Diagnostic and Analysis phases. These are addressed by Brian Burke, Jim Wilson, and the key users of Tailspin Toys.

Scenario

It is now June 24, 2010 and as the Project Manager, you need to review the Functional Design Document Customization.

Goal Description

Brian and Jim documented their findings for the Gap design in the Functional Design Document Customization. Your goal is to review this design document and to learn about its content.

Step by Step

Step 1 - Locate the Functional Design Document Customization for Tailspin Toys and review the content.

1. Describe the content of this document. What does this document address?

2. Does the proposed design satisfy the functional requirements?



4-22

3. The document includes a presentation of the solution. Is this proposed presentation suitable for the customer? Why is this necessary?



4-23

Lab 4.5 - Create a Solution Design Document The Solution Design Document provides the overall solution description in business language, and includes the capabilities being enabled by the solution.

Scenario

On July 9, 2010 Brian Burke started with the creation of the Solution Design Document. The team worked on different design documents in the month of June. As a result multiple design documents are created.

To obtain a clear view of the proposed solution flow, it was recommended by the Project Manager that a Solution Design Document be created.

Goal Description

The goal for this lab is to explore the content of the Solution Design Document and to learn about its benefits.

Step by Step

Step 1 - Locate the Solution Design Document template in Microsoft Dynamics Sure Step and review the content.

1. Define why a Solution Design Document needs to be used in the project?



4-24

2. What content is expected in the SDD?

3. Examine the SDD template. List the content sections that are provided.

4. Section 4 (Strategy and Solution Concept) of the SDD document, contains a number of subsections. What type of information would belong in this section?



4-25

5. The Project Manager can decide which design documents to use and define what the expected content is. Explain the content in the Solution Architecture section of the SDD.

HINT: Review both the Solution Design Document Template and Solution Design Document Sample Document available in Microsoft Dynamics Sure Step to illustrate how the content of the SDD is determined by the project needs.

6. Prepare for the upcoming class discussion. Identify which of the design documents you feel are most critical and what types of projects would utilize them.



4-26

Lab 4.6 - Using Design Documents Having examined the different design documents, it is now time to discuss the findings in class.

Scenario

Topics for this discussion include the following:

• What are the benefits of using the design documents? What types of projects can benefit from these documents?

• Provide opinions about using separate design documents for each Gap and each Fit.

• Provide an opinion on the Solution Design Document. What does the SDD provide for the project team?

• How is the content of Tailspin Toys' SDD evaluated?



4-27

Project Performance and Status Reporting Project performance and status reporting are essential elements of project communication management. Communication Management is a critical success factor in projects. It is an ongoing activity during the project execution used to satisfy the stakeholders' needs. Based on the type of project as well as the individual project needs, different tasks may be completed within this discipline.

Project Performance Reporting

Performance Reporting collects and distributes performance information. This includes status reporting, progress measurement, and forecasting.

The performance reporting process involves the collection of all baseline data, and the distribution of performance information to stakeholders. Generally, this performance information includes how resources are being used to achieve project objectives. Performance reporting generally provides information on the project scope, schedule, cost, and quality. Many projects also require information on risk and procurement.

The benefits from proper Project Reporting include the following:

• An up-to-date accurate status of the project. • Solid input to proactively make corrections. • Allows managing project stakeholder expectations. • Historic reference for future estimates. • Minimize surprises to the customer. • More accurate representation of on-time completion.

Project Status Reporting

Project Status Reporting provides the customer with a weekly summary of the project consisting of the accomplishments, decisions, planned work, risks, and issues.

A status report is a document prepared by the Program Manager on a weekly basis using the information provided through the consultant status reports and the updated project plan.

The status report depicts the following information:

• Overall health status of the project • Tasks accomplished for this week • Decisions made • Tasks planned for next week • Issues and risks



4-28

• Vacation schedules • Forecast/actual hours by consultant

The status report is first reviewed with the project team through an internal weekly team status meeting and then presented to the customer based on the agreed upon timeline.



4-29

Lab 4.7 - Review the Consultant Status Report During this lab you examine a consultant status report. This report is created during the Development phase.

Scenario

The Development activity started on July 23, 2010 and is planned to finish on September 3, 2010. The workload includes the following:

• Custom Coding • Data Migration • Integration and interfacing

The planning can be examined in the provided timelines at the beginning of this chapter and the project plan. The estimates for development time are documented in the Microsoft® Office Excel® file Development Estimate.

Goal Description

The goal of this lab is to review a status report of the development consultant working on the custom code development for Tailspin Toys. Your challenge is to review this report.

Step by Step

Step 1 - Locate the Development Estimate for Tailspin Toys and review the content.

1. Which consultants are deployed during custom coding?



4-30

2. How many days are estimated to complete the trade functionality?

Step 2 - Locate the Consultant Status Report for Tailspin Toys and review the content.

3. Which consultant reported his or her individual status and what is the status period?

4. What did the consultant achieve in this period?



4-31

5. What accomplishments is Jim planning for in the next period?

6. What is your project management opinion of Jim's status report?



4-32

Lab 4.8 - Create the Project Status Report Project Status Reporting provides the customer with a weekly summary of the project accomplishments, decisions, planned work, risks, and issues. The purpose of this lab is to create a project status report.

Scenario

It is Friday, September 4, 2010. All consultant status reports are received for this week. Jim Wilson and Diane Prescott reported that they are still working on QC-2/5. They are behind schedule due to a delayed start with their requirements. They also experienced problems due to inaccurate requirements in the design documents. Having spoken with the key users, Jim and Diane concluded that the initial vision of the solution is not aligned with the current expectations of the key users.

As a result, the custom code development for Reporting and Finance is not yet started.

Josh Pollock reported that he completed the data migration development for the Fits, and he is now working on the data migration for the Gaps. However, to finish his work the functionality for QC-2/5 needs to be finished by Jim and Diane.

Heather Murchison reported on August 3, 2010r that she completed the Integration and Interface Development.

Goal Description

Create a Project Status Report for this period using the template provided in Microsoft Dynamics Sure Step.



4-33

Step by Step

Step 1 - Locate the Project Status Report in Microsoft Dynamics Sure Step.

Complete the report using the information provided in the scenario.

1. What are the key pieces of information you chose to convey in the project status report?



4-34

Testing Testing helps ensure that the project adheres to quality standards so that customer satisfaction goals are exceeded. The value of comprehensive, well-executed testing cannot be over emphasized. Even when there are minimal customizations, it is important for the customer to execute their typical business processes in the new environment to ensure that user workflow procedures and application configuration settings are appropriate for optimal productivity.

The types and extent of testing is dependent on the project type, and on the needs of the individual project.

Testing as a Cross Phase Process

Testing activities can be found in different phases of the project life cycle. Although activities for creating, updating, or executing test scripts are discussed in the Design, Development, and Deployment phases, it is important to consider testing activities during project scoping and planning in the Analysis phase. Test planning is conducted in the Analysis phase to establish the high level plan for testing and to establish the general standards and procedures to be followed when conducting software testing and validation. Also as the project work progresses, the project plan needs to be kept up to date regarding the activities related to testing.

During the Design and especially the Development and Deployment phases, configuration, customization, and data migration activities require the creation of a system change/release management process during the Analysis phase. This details what environments need to be maintained, the methods to be used to transport changes from a development and/or test environment to a production environment, and all the necessary testing and approvals throughout the process.

Quality and testing activities extend from the implementation and deployment of the Microsoft Dynamics solution through the Operation phase.

Part of the implementation's closing activities is the evaluation of the deliverables and acceptance criteria compared to the Statement of Work (SOW) and any change orders to ensure that all contractual obligations are met. All documentation needs to be updated, reviewed, finalized, and prepared for hand off to the customer.

Testing Activities during the Design Phase

The following testing activities may be performed during the Design phase:

• Conduct Feature Testing of Standard and ISV Solution(s), evaluate the results and make the required adjustments to the configuration.

• Create Unit and Function Test Scripts for Custom Code.



4-35

• Create Test Scripts for Integration Testing. • Create Test Scripts for Data Migration Testing. • Identify Process Testing Scenarios. • Create Data Subset for Testing.

Testing Activities during the Development Phase

The following testing activities may be performed during the Development phase:

• Conduct Sub-Process Testing - testing of related features that comprise a defined business process, performed during Configuration by the customer and the Application Consultants.

• Conduct Unit Testing - stand-alone testing of the system modification (custom code), performed during the Development phase by the Development Consultants.

• Conduct Function Testing - stand-alone testing of the system modification (custom code), performed during the Development phase by the customer and the consultants.

• Execute Process Testing - complete testing of related features and functions that comprise a defined business process, performed during the Development phase by the customer and the consultants.

• Execute Integration Testing - integrated testing of business processes performed by the key users prior to system sign-off. This focuses on end-to-end business processes including development, interfaces, reports, and integrations to external systems.

• Execute Data Acceptance Testing (DAT) - testing performed by data owners and key users in the Development phase prior to Integration Testing. During DAT, the customer not only verifies the data migrated but also validates that the data may be inquired upon, reported upon, and transacted upon.

• Develop Performance Test Scripts - testing of business processes and integration. This places a focus on high transaction volume that is anticipated during peak times so as to validate that the system performance meets the business requirements. This testing is performed by the Implementation Project team, typically using test automation software.

• Develop User Acceptance Test Scripts (UAT) - final testing performed by the key users prior to system sign-off. The end users selected to perform the UAT must have had appropriate training prior to the start of the UAT.



4-36

Testing Activities during the Deployment Phase

Testing during the Deployment phase involves validating that the configured system under load will meet the performance metrics, confirming that the overall setup and configuration of the system meets the customer's business requirements, and leads to User Acceptance sign-off.

• Performance Testing tests business processes and integration with a focus on high transaction volume that is anticipated during peak times so as to validate that the system performance meets the business requirements.

• User Acceptance Testing is the final testing performed by the key users prior to system sign-off. The end users selected to perform the UAT must have appropriate training prior to the start of the UAT.

Testing Environments

Designing, planning, and building non-production environments during the Design phase includes setting up testing environments for the execution of the following test scripts and scenarios:

• Unit and Function Testing • Process Testing • Integration Testing • Data Migration Testing • Performance Testing • User Acceptance Testing

These test scripts are executed during the Development and Deployment phases. Depending on the complexity of the engagement, separate environments might be necessary for Performance and User Acceptance Testing (UAT).



4-37

Lab 4.9 - Unit and Function Testing During this lab you follow up on all activities concerning the Custom Code Testing, otherwise referred to as Unit and Function Testing.

Scenario

Together with the creation of the Technical Design Document, the development consultants, Jim Wilson, Josh Pollock, and Diane Prescott created different test scripts according to the different custom code requirements during the period from June 29 through July 7, 2010.

During the Development phase, these tests were conducted by both the development consultants and Tailspin Toys' key users. The development and testing of custom code was performed from June 23 through September 3, 2010.

September 4, 2010 is the day to review the test results after following up on the consultant status reporting (refer to the previous lesson and labs).

Goal Description

As the Project Manager, follow up on the creation of the test scripts based on the results received from the test performance.

Step by Step

Step 1 - Review the Test Script Scenarios.

Locate the template Unit and Function Test Scenario worksheet for Tailspin Toys and review the created test scripts.

HINT: Although this lab uses the Unit Function Test Script Template for Microsoft Dynamics AX, it is recommended that you take a few moments to review the other templates available for this activity in Sure Step.

1. For which functional domains are there no test scripts created, and why?



4-38

2. For which functional domains are there test scripts created?

3. Are there sufficient test scripts created? Which document is used to check this?

Step 2 - Review the Test Results in the Updated Unit Function Test Scenario Worksheet.

Who is responsible for conducting the Unit and Function Tests?



4-39

4. In which document is the test results reviewed? Locate this document, and open it for review.

5. Are there any functional domains in which there are problems with the achieved results? If so, in which domains did the problems occur and what is their impact?

6. Examine the Unit/Function Test Script Details Document available in Microsoft Dynamics Sure Step. How does this differ from the Unit/Function Test Script worksheet you reviewed earlier? Would you always use both documents?



4-40

Lab 4.10 - User Acceptance Testing During this lab you monitor testing activities prior to complete customer system acceptance to prepare yourself and the project team for Go-Live activities.

Scenario

During the Development phase, from September 7 through September 25, 2010, different User Acceptance Test Scripts were compiled according to the agreed upon Conditions of the Satisfactions established during the Analysis phase.

The required User Acceptance Test data migrated into the staging environment on October 21, 2010 leaving the environment ready for the performance of the tests. Users performed the tests over a period of one week, from October 22 through October 28, 2010.

Goal Description

As the Project Manager, it is your responsibility to ensure that User Acceptance Tests are planned for and set up in time. During the performance of these User Acceptance Tests, monitor the results closely since they can have an impact on the overall project schedule.

Step by Step

Step 1 - Review the Test Script Scenarios and the Test Results.

Locate the Updated User Acceptance Test Scenario Worksheet template for Tailspin Toys and review the results.

1. According to which principle is the template divided?



4-41

2. Who is responsible for conducting the User Acceptance Tests?

3. In which environment is the User Acceptance Test preferably conducted? When was this environment set up?

4. Are there any functional domains in which there are problems with the achieved results? If so, in which domains and what is their impact?



4-42

Step 2 - Next Steps

Based on the test results, prepare yourself for the rest of the project lifecycle.

5. After conducting all tests, what are the logical next steps for the Tailspin Toys' project?

6. Based on the results from the User Acceptance Tests, is Tailspin Toys ready to sign-off on a complete system acceptance?

7. Even if all tests went well, do you believe this will automatically lead to the final stage of the project?



4-43

Tollgate Review The Tollgate Review may be conducted at the end of each phase in the project lifecycle. This review is a project quality element and represents a necessary quality stop at the end of each phase before the transition to the next phase. Not every project will utilize tollgate reviews. It is up to the project manager and the project team to set the standards for how to proceed from phase to phase.

The tendency to quickly slip into the next phase of a project as the desire to keep the team moving forward often compromises the original standards set for the completion of a particular phase. It is often believed that missed deliverables can be completed by running tasks in parallel, or asking for a few extra hours from the team. Eventually however, interdependencies between activities create a bottleneck, where so many activities rely on an incomplete task from a previous phase. This causes the entire project to become bogged down in repeated missed deliverables as delays exponentially multiply.

The Tollgate Review presentation is prepared by the Project Manager. It is presented to the customer at the end of the phase, with the core project team in attendance. The core project team includes the project leads, executive sponsor, and key users. The Tollgate Review highlights the current health of the project, key milestones achieved, key deliverables completed, project level issues and risks, and the conditions of satisfaction assessment.

The objective of this review is to ensure that the project team is aligned with the progress of the project and that the team establishes an action plan to address the issues and risks for the next phase.



4-44

Lab 4.11 - Prepare the Tollgate Review During this lab you create a Tollgate Review Report.

Scenario

The Tollgate Review will be conducted at Tailspin Toys on September 30, 2010. It is now September 29, 2010 and you need to prepare the Tollgate Review.

The project status reporting during the Development phase revealed that this project suffered a time and cost overrun. As a proactive Project Manager, you implemented corrective actions, which involved the deployment of an external development consultant. This allowed you to manage the time overrun, but you could not avoid the cost overrun.

On September 25, 2010 your team reported the following:

• All custom code development is completed. • All integration and interface development is completed. • Data migration development is completed. • The design documents are updated. • Integration testing is finished. • Data acceptance testing is completed. • Unit testing is conducted. • Function testing is conducted.

The Development Actuals spreadsheet contains the summary of the actuals for each deliverable in the Development phase.

Conversations with the members of the Development Team show that there is a mix of reasons for the overrun, including the following:

• Gray-zones in the design, caused by gray-zones in the analysis. • Key-users changing opinions about the expected solution. • Underestimation of the analytical reporting.

Also, it seems that during the Development phase the communication between both teams did not go as well as planned. Key users claimed they received no communication, while members of the Development Team suffered incomplete feedback from the Key User Team. However, you are convinced that the quality delivered for the custom code and configuration satisfies the expectations.



4-45

Goal Description

It is September 29, 2010 and it is now time to create the Tollgate Review Report to close the Development phase.

Step by Step

Step 1 - Locate the Tollgate Review Report template in Microsoft Dynamics Sure Step.

Concentrate on the key pieces of information to complete the Tollgate Review Report in preparation for the Tollgate Review. Be prepared to discuss your approach with the class.



4-46

Go-Live The Go-Live activity is completed at the end of the Deployment phase. The purpose is to initiate the successful processing of daily business transactions and activities in the new system.

The Live production environment is set up and configured. Functionality and performance is validated and signed-off on the completion of the Testing activities. The cutover plan is verified and tested to the fullest extent possible. The final data migration is completed and validated during previous activities. End-user training is performed and the users have demonstrated proficiency in performing their daily job activities in the new system.

The system is now ready to process necessary transactions and perform business processes as defined in the business requirements workshops. Following the cutover to the new system, the end users may require additional assistance and the Implementation Team needs to be prepared to continue providing guidance through the initial learning curve.

Go-Live Cutover Plan

The purpose of this activity is to ensure that a planned, documented, and tested cut-over process is in place. This reduces the risk of mistakes being made over the go live period which can have a significant impact on user acceptance and the solution as a whole.

In planning for the Go-Live cut-over consider the following key items:

• Plan: write a Go-Live cut-over plan that provides an overview of all those involved and key activities.

• Document: write a Go-Live cut-over process document that defines the details of the cut-over plan on a step-by-step basis. Include any key decision points and a step-by-step back out plan if things go wrong.

• Test: it is recommended that the full cut-over process is run as a preliminary run, against one of the other environments at least two weeks before the final cut-over is due. In complex projects several iterations of testing and enhancing can be required in the cut-over process.



4-47

Lab 4.12 - Create a Go-Live Cut-over Plan Examine what items need to be prepared and which tasks need to be completed before the Go-Live activity.

Scenario

The Go-Live date at Tailspin Toys is planned for November 9, 2010.

Go-Live will be performed on a per-department basis to provide each department the necessary attention. With the installation of the Microsoft Dynamics ERP solution, the legacy system will be immediately shut down, leaving the users with no alternative but to start working within their new ERP environment. Adam Carter still agrees that this is the best practice for his company.

However, before installing these live production environments, a lot of preparation and planning still needs to be performed. Most of these tasks lie in the hands of Tailspin Toys' IT Manager, Mike Nash, who is responsible for setting up the company's infrastructure. However, he will be assisted by Trey Research's Technology Consultant, Heather Murchison, as needed.

The tasks completed before the set up of the production environment include the following:

• Development of all custom code: 09/03/2010. • All development adjustments performed and signed off: 09/18/2010 • User Acceptance Testing is performed: 10/28/2010 • Infrastructure upgrades: 11/06/2010 • Training of key users and end users: 11/06/2010

The staging environment became polluted and corrupted during the performance testing. This resulted in having to build the live production environment from an earlier version of the database, and backing it up prior to testing. Heather Murchison will provide Mike Nash with such a version, since she is responsible for the backup of the database prior to every change. Also during the Go-Live activity Heather will back up the system on a regular basis. In the event of an emergency, she will be able to restore from the most recent backup. This process will be initiated by the Application Consultant, Brian Burke, who will notify all the necessary project members.

Different users will have to be set up for the production environment. Brian Burke will be responsible for this and for the migration of the necessary data from the legacy system to the production environment. This will initially occur a week before the actual Go-Live date.



4-48

Although key users and end users are fully trained before Go-Live, Adam Carter is concerned about his employees. He feels that they need someone to assist them if there are problems and to monitor them when necessary. Although it is not possible to have one of Trey Research's project members at Tailspin Toys' headquarters full-time, a compromise is reached, and a weekly check-up meeting is organized to report on the end-users progress. This meeting will be held between the two Project Managers, Adam Carter and you.

Goal Description

The goal for this lab is to prepare for the cut-over from the non-production to the production environment. As the Project Manager, you need to be well organized and ensure the Go-Live runs as smoothly as possible, since this is the final milestone before the Operation phase and the (successful) closing of your project.

Step by Step

Step 1 - Prepare for Go-Live Cut-over.

1. In your Project Plan review the activity planned for the Go-Live. How many days are planned for the Go-Live? Is it realistic, considering the Go-Live approach defined in the Go-Live Cut-over Plan? Why or why not?

2. What is the impact of your previous decision?



4-49

3. Are there any locations that require remote access to the Microsoft Dynamics ERP solution? If so, which departments require remote access and who is responsible for setting this up?

4. During which previous activities are the security roles defined? This is information that Brian Burke will need to create the different users in the production environment.

Step 2 - Create the Go-Live Cut-over Plan.

Based on the lab scenario and the questions from the previous step, complete the Go Live Cut-over Plan using the template provided in Microsoft Dynamics Sure Step for Microsoft Dynamics AX.

Focus on the areas you feel are critical to the success of the go live activity, and be prepared to discuss your selections in class.

For additional guidance, refer to the Go Live activity in Sure Step, and the associated Go Live Checklist.



4-50

Summary This chapter examines crucial project management activities during the Design, Development, and Deployment phases. Several activities are discussed in this chapter , including:

• Creating a go live cutover plan. • Working with the solution design documents. • Examining performance and status reporting.

This chapter also discusses envisioning, planning, and coordinating the testing activities and conducting a Tollgate Review.



4-51

Quick Interaction: Lessons Learned Take a moment and write down three key points you have learned from this chapter

1.

2.

3.



4-52

Solutions Lab 4.1 - Create the Deployment Plan

1. Which deployment activities are necessary? List them here.

MODEL ANSWER:

Use your implementation experience, as well as Tailspin's requirements, to formulate your answer. There are no incorrect answers.

2. What questions still need to be answered to complete the deployment plan?

MODEL ANSWER:

Use your implementation experience, as well as Tailspin Toys’ requirements, to formulate your answer. There are no incorrect answers.

Lab 4.2 - Update the Project Plan

1. Were there any changes identified during the Analysis phase? If so, what impacts will these events or changes have on the project plan?

MODEL ANSWER:

Yes, changes were identified during the Analysis phase. Only one of those changes is approved by the customer, the implementation of Microsoft Dynamics™ CRM to address customer service requirements regarding complaint tracking. As a result, the requirements regarding complaint registration are now out of scope for the Microsoft Dynamics ERP solution implementation. This affects the design and development phases with a decrease of five days.

2. Examine the project plan for a standard project type. Which elements of the breakdown structure will need to be updated to achieve the planned change?

MODEL ANSWER:

The approved change reduced the scope of the implementation by removing some functional gaps. This has an impact on time needed for designing and developing the custom code required for solving these gaps. This reduces the time needed for testing and training regarding these customizations. Concerning the project plan, this involves the following activities: 2.5.1, 2.6.2, 3.5.0, 3.6.1, and 4.2.1.



4-53

3. What other events can trigger a need for updating the project plan?

MODEL ANSWER:

The project plan may need to change due to various reasons. These include, but are not limited to, a change in the scope, quality issues, and a change to any design element.

4. From the updated Project Plan identify the duration for the Design phase.

MODEL ANSWER:

39 days, from 5/27/10 until 07/17/10

5. From the updated Project Plan identify the duration for the Development phase.

MODEL ANSWER:

53 days, from 07/20/10 until 09/30/10

6. From the updated Project Plan identify the duration for the Deployment phase.

MODEL ANSWER:

30 days, from 10/05/10 until 11/13/10

7. At the (planned) end of the Deployment phase, what is the duration from the start of the project?

MODEL ANSWER:

Analysis through Deployment: 158 days, from 03/30/10 until 11/13/10

8. Which phases and specific activities are related to the delivery of the Functional Design Documents (FDD)? On which dates are these activities planned?

MODEL ANSWER:

Design phase: activities 2.4.2 for fits on 6/4/10, and 2.5.1 for gaps from 6/8/10 to 7/7/10.

9. Which activities involve Testing and when are these planned?

MODEL ANSWER:

Design phase: activity 2.6 from 06/03/10 until 07/10/10, Development phase: activity 3.6 from 07/23/10 until 09/25/10, Deployment phase: activity 4.6 from 10/21/10 until 10/30/10.



4-54

10. What tasks related to data migration are found in the different phases? When do they occur?

MODEL ANSWER:

Analysis phase: 1.9.0 data migration (including gathering requirements) 4/20/10 to 5/8/10 Design phase: 2.9.0 data migration (including begin data migration) 6/17/10 to 6/25/10 Development phase: 3.9.0 data migration (including develop and freeze data migration scripts) 8/24/10 to 9/8/10 Deployment phase: 4.9.0 data migration (including final data migration to PROD) 10/21/10 to 11/3/10

5. When is the Go-Live date for Tailspin Toys, and in which phase does it occur?

MODEL ANSWER:

Deployment phase: activity 4.4.1: on 11/09/10.

Lab 4.3 - Create a Fit Design in the Functional Design Document

1. How many requirements are handled in this FDD?

MODEL ANSWER:

Only one requirement is addressed in this FDD.

2. What is the requirement being addressed in this FDD?

MODEL ANSWER:

FR-82, FI-6: need to be able to perform analytical accounting. They would like to analyze revenue and costs created by the different departments, cost centers, customers and customer groups, salespeople, and sales groups.

3. Which solution is chosen for this specific requirement?

MODEL ANSWER:

The requirement is implemented by configuring different financial dimensions.



4-55

Lab 4.4 - Create a Gap Design in the Functional Design Document

1. Describe the content of this document. What does this document address?

MODEL ANSWER:

This document describes the solution for the Gaps related to direct delivery. It describes how a custom code solution can be created and explains relevant considerations.

2. Does the proposed design satisfy the functional requirements?

MODEL ANSWER:

Discuss your answer with the class.

3. The document includes a presentation of the solution. Is this proposed presentation suitable for the customer? Why is this necessary?

MODEL ANSWER:

A suitable solution needs to be presented to the customer to be accepted and approved.

Lab 4.5 - Create a Solution Design Document

1. Define why a Solution Design Document needs to be used in the project?

MODEL ANSWER:

When the documentation of the solution, which involves different functional design documents with each containing details about specific requirements, is completed, it is recommended to have one overview document. This can be used to communicate with the executive stakeholders.

2. What content is expected in the SDD?

MODEL ANSWER:

This is a personal expectation. All answers are correct but can be open for discussion and peer learning.



4-56

3. Examine the SDD template. List the content sections that are provided.

MODEL ANSWER:

Executive Summary, Business Situation, Vision and Scope, Strategy and Solution Concept, and Solution Architecture

4. Section 4 (Strategy and Solution Concept) of the SDD document, contains a number of subsections. What type of information would belong in this section?

MODEL ANSWER:

This section should address how the Microsoft Dynamics solution will meet the priority business requirements for the customer.

5. The Project Manager can decide which design documents to use and define what the expected content is. Explain the content in the Solution Architecture section of the SDD.

HINT: Review both the Solution Design Document Template and Solution Design Document Sample Document available in Microsoft Dynamics Sure Step to illustrate how the content of the SDD is determined by the project needs.

MODEL ANSWER:

The solution architecture section of the SDD outlines the components of the solution and any planned integration points. This can include both standard components that need to be configured as well as customized components.

6. Prepare for the upcoming class discussion. Identify which of the design documents you feel are most critical and what types of projects would utilize them.

MODEL ANSWER:


Lab 4.7 - Review the Consultant Status Report

1. Which consultants are deployed during custom coding?

MODEL ANSWER:

Jim Wilson and Diane Prescott



4-57

2. How many days are estimated to complete the trade functionality?

MODEL ANSWER:

25 days

3. Which consultant reported his or her individual status and what is the status period?

MODEL ANSWER:

Jim Wilson reported his achievements for the status period of 07/20/2010 through 07/27/2010.

4. What did the consultant achieve in this period?

MODEL ANSWER:

Jim Wilson completed the requested functionality for TR-12. Jim estimates that he needs 15 more hours to complete TR-16 and 19, with an expected completion date of 08/04/10.

5. What accomplishments is Jim planning for in the next period?

MODEL ANSWER:

Complete direct delivery functionality TR-12/16/19. Unit testing for direct delivery TR-12/16/19 and start PO Approval functionality AS-7.

6. What is your project management opinion of Jim's status report?

MODEL ANSWER:

Jim's work is behind schedule and is suffering both a time and cost overrun. It is questionable whether he will be able to deliver his next set of planned deliverables. Jim's report is incomplete and he did not provide any reason as to why he is behind schedule. He did not report any issues, and did not begin testing. He reported to have finished one requirement, but without it being tested, rework can be expected.



4-58

Lab 4.8 - Create the Project Status Report

1. What are the key pieces of information you chose to convey in the project status report?

MODEL ANSWER:


Lab 4.9 - Unit and Function Testing

1. For which functional domains are there no test scripts created, and why?

MODEL ANSWER:

Test scripts are not created for the following functional domains: General Ledger, Accounts Receivable, Resources, Master Planning, Production, Shop Floor, Project, Human Resources, and Payroll. There are no customization requirements for these domains and so no custom code is developed or tested.

2. For which functional domains are there test scripts created?

MODEL ANSWER:

Test scripts are created for the following functional domains: Accounts Payable, Inventory, Purchasing, Sales, Warehouse Management, and Quality Control.

3. Are there sufficient test scripts created? Which document is used to check this?

MODEL ANSWER:

Yes, for every customization requirement there is at least one test script created. Compare this to the Detailed Fit Gap Spreadsheet, or the different Functional Design Documents, or the Technical Design Documents that are created for every gap/customization.

4. Who is responsible for conducting the Unit and Function Tests?

MODEL ANSWER:

For Trey Research: Development Consultants - Jim Wilson, Josh Pollock, and Diane Prescott – and the Application Consultant – Brian Burke. For Tailspin Toys: key users – Peter Houston, Russell King, Shawn Richardson, and Mike Nash



4-59

5. In which document is the test results reviewed? Locate this document, and open it for review.

MODEL ANSWER:

The Unit and Function Test Scenario Worksheet can be updated with test results. There are different columns to indicate a pass or fail, one for the consultants and one for the customers.

6. Are there any functional domains in which there are problems with the achieved results? If so, in which domains did the problems occur and what is their impact?

MODEL ANSWER:

For Quality Control there are no tests performed yet, because the custom coding is not complete (refer to Consultant Status Reporting). Another area identified with problems is Inventory and Warehouse Management. However, in both areas these problems did not result in a project stoppage. The problems will be fixed later and should not jeopardize the project.

7. Examine the Unit/Function Test Script Details Document available in Microsoft Dynamics Sure Step. How does this differ from the Unit/Function Test Script worksheet you reviewed earlier? Would you always use both documents?

MODEL ANSWER:

The Unit/Function Test Script Details Document can be used to record the details of an individual test script, as well as the results while the Unit/Function Test Script worksheet tracks the summary of results of all test scripts. You may or may not use both documents depending on the project type and needs. Be prepared to discuss your own perspectives regarding when each document might be necessary.

Lab 4.10 - User Acceptance Testing

1. According to which principle is the template divided?

MODEL ANSWER:

Each worksheet contains test scripts for a specific functional domain.

2. Who is responsible for conducting the User Acceptance Tests?

MODEL ANSWER:

Tailspin Toys’ key users – Peter Houston, Russell King, Shawn Richardson, and Mike Nash.



4-60

3. In which environment is the User Acceptance Test preferably conducted? When was this environment set up?

MODEL ANSWER:

It is set up in the Staging environment. This environment was set up during the Design phase and updated with the development of custom code.

4. Are there any functional domains in which there are problems with the achieved results? If so, in which domains and what is their impact?

MODEL ANSWER:

Initially, a small number of tests failed in the following functional domains: General Ledger, Accounts Receivable, Inventory, Purchasing and Master Planning. Some were solved by the time the second test person performed the tests. Other tests that failed due to small layout related problems will be fixed later and do not jeopardize the project.

5. After conducting all tests, what are the logical next steps for the Tailspin Toys' project?

MODEL ANSWER:

As the Project Manager, obtain complete customer acceptance to start the Go-Live activities and finally close the project. This helps prepare for the Operation phase, which is the last phase in the project.

6. Based on the results from the User Acceptance Tests, is Tailspin Toys ready to sign-off on a complete system acceptance?

MODEL ANSWER:

Since there are only a small number of failed tests and they did not have a serious impact, Tailspin Toys’ should be able to move forward in the project, with the correct guidance.

7. Even if all tests went well, do you believe this will automatically lead to the final stage of the project?

MODEL ANSWER:

Successful tests should allow a project to move into the final stages, although this is not guaranteed. Even at this point in time, some obstacles may present themselves and generate change requests or delays in a project for example.



4-61

Lab 4.12 - Create a Go-Live Cut-over Plan

1. In your Project Plan review the activity planned for the Go-Live. How many days are planned for the Go-Live? Is it realistic, considering the Go-Live approach defined in the Go-Live Cut-over Plan? Why or why not?

MODEL ANSWER:

The Go-Live is planned for November 9, 2010 for a period of one day. Since it is agreed upon that the Go-Live will be performed per department, this is not a very realistic plan.

2. What is the impact of your previous decision?

MODEL ANSWER:

The Go-Live will take longer than initially expected, therefore, the Project Plan will need to be adapted and the Operation phase and project closure will move further up in the year.

3. Are there any locations that require remote access to the Microsoft Dynamics ERP solution? If so, which departments require remote access and who is responsible for setting this up?

MODEL ANSWER:

The warehouses in Boston and Hong Kong.

4. During which previous activities are the security roles defined? This is information that Brian Burke will need to create the different users in the production environment.

MODEL ANSWER:

Development phase – 3.4.1 and 3.4.2



4-62
