Applications Server
 

Implementing with Microsoft Dynamics Sure Step 2010 : Waterfall-based implementation project types

11/22/2011 3:04:27 PM
To address the scale and complexity of the customer's implementation engagements, Sure Step offers the users the choice of three waterfall-based implementation project types and one waterfall-based upgrade project type. The focus of this section will be on the three waterfall-based implementation project types—Rapid, Standard, and Enterprise.

The Rapid project type

The Rapid project type represents the simplest delivery approach among the Sure Step waterfall-based project types. The Rapid project type is designed for out-of-the-box implementations of the Microsoft Dynamics solution, which essentially entail zero or minimal customizations of the standard solution.

The Rapid project type prescribes fourteen activities to solution "Go-Live", and as such, it is positioned in Sure Step as a lean or accelerated delivery approach. The relatively low number of activities, of course, doesn't directly translate to fewer implementation hours, but it does imply a minimalistic approach that requires extreme discipline and hard work from the customer and consulting teams. This is because such a lean approach does not factor in any time for missteps—it has no leeway in the budgeting and resourcing structure of the project.

The following is a screenshot of the Rapid Project Type, including the activities shown in the left navigation tree:

Before selecting the Rapid approach, it also very important that in the Diagnostic phase, the service provider and customer determine that the standard Microsoft Dynamics has a high degree of solution fit with the customer's requirements, and that no major customizations or add-on Independent Software Vendor (ISV) solutions are needed to complement the standard solution. If proper due diligence is carried out to determine that a high degree of fit exists, the Rapid project type can indeed live up to its name and provide a rapid delivery of the solution. It could be a recipe for disaster if one of the two parties—the consulting or customer teams—willfully chooses this project type even though they are aware of additional rigor being needed in developing the solution.

The following are the ideal conditions for the usage of the Rapid project type:

  • A very high degree of fit exists between the customer's requirements and the selected Microsoft Dynamics product's features. The general rule of thumb is to look for about 90% degree of fit or higher to justify the usage of a Rapid project type.

  • No customizations or minimal customizations will be needed to meet the customer's requirements, nor does the solution include any ISV solutions. It is important that if there requirements that are classified as "gaps" with the prescribed solution, they will require only simple custom code development efforts.

  • Business process analysis is not in the scope of the Rapid engagement. A "rapid" engagement necessitates that the customer undertakes this effort, and is not a requirement for the consulting team.

  • Integration or interfaces to third-party sources is outside the scope of the engagement. Developing code for integrating to outside sources can be fraught with factors outside the delivery team's control. For that reason, going with a minimalistic approach is not recommended if the solution requires integrations and interface development.

  • The migration of data from legacy or third-party systems to the envisioned solution is straightforward or outside the scope of the engagement. Just like integrations to third-party sources, extracting data from outside sources introduces factors beyond the control of the delivery team, and hence is not recommended.

From a general customer profile standpoint, the Rapid project type is typically used in small-to-medium sized businesses deploying Microsoft Dynamics solutions. The typical number of users for the solution in these companies is small—up to 25. The usage scenarios for the solution could include companies moving away from homegrown legacy systems or smaller systems that no longer support their growth. These customers must have gone through the selection process in the Diagnostic phase to determine a good fit with the Microsoft Dynamics solution, and would be looking for the solution to go into production with a limited amount of functionality in a relatively short timeframe so as to quickly realize value from the solution.

Also, the customers that fit the Rapid project type profile may have a relatively small number of users, both on the business and IT side, with prior experience in implementing or using ERP/CRM solutions or solutions that encompass a high swath of the organization. The relative inexperience in this area requires that the customers choose a good partner who understands their vision and can deliver the solution to meet it. For the customer, it is also judicious to lean towards a more out of the box solution deployment. Hence it is preferable to choose the Rapid project type, so that they can start with a more straightforward solution and gain the experience before jumping into complex solution scenarios.

While the typical usage of the Rapid project type is for smaller businesses, it is important to note that this project type should not be considered as limited to the size of the customer. When you look past organizational size and look at usage patterns and needs, you may find other use cases for this project type. For example, the Rapid project type could also be applicable in multisite deployments, where the solution has already been developed and delivered to the first site and a very similar solution is being delivered to additional sites.

The Standard project type

The Sure Step Standard project type is suitable for a majority of Microsoft Dynamics projects, and hence the most widely used. This project type includes activities in all nine cross phases, to support customizations, integrations, and interfaces, as well as business process analysis. As such, the Standard project type can be used on typical medium scale, single-site implementations.

The next screenshot is of the Standard Project Type in Sure Step. Included in the screenshot is a partial view of the activities shown in the left navigation tree, indicating additional severity in each of the cross phases.

The Standard project type is best suited for medium-to-large sized businesses that find a fairly high degree of fit of their solution requirements with the corresponding Microsoft Dynamics solution. The rule of thumb on the degree of fit is around 70-80%, but more importantly the required customizations should not be overly complex, in which case, the Enterprise project type may afford a more rigorous approach to managing the custom code development process.

The usage scenarios for the Standard project type include the following:

  • The customer's requirements can be met to a fairly high degree (about 70-80% fit) by the selected Microsoft Dynamics solution, which may or may not include an Independent Software Vendor (ISV) solution in addition to the core Microsoft Dynamics solution. The activities in the Standard project type provide more prescriptive guidance for the setup of the ISV solution in conjunction with the Microsoft Dynamics solution by service provider, and hence the Standard project type is more suitable than the Rapid project type.

  • Business process analysis activities are included. One of the most widely used features of Sure Step is the extensive business process maps included. These process maps afford customers and service providers an excellent starting point to map their future workflows from the standpoint of using the standard Microsoft Dynamics solution functionality. Not only do the process maps allow the customers' end users to understand in a graphical manner how the solution functionality is designed to operate, but they also allow them to visualize how their current processes could fit into the new system and if there are opportunities to make simple tweaks in their processes to alleviate the need for complex customizations. The importance of this cannot be minimized for the long-term outlook and Total Cost of Ownership (TCO) of the solution.

  • Organizational Change Management (OCM) is identified as a key discipline for the customer engagement, though the need is not as stringent as it would be for large-scale engagements.

  • Custom code development is needed for the requirements classified as "gaps", with the prescribed solution being simple to complex, but not overly complex, as stated earlier. For highly complex customizations, the additional rigor in the Enterprise project type may be better for the customer and service provider.

  • Custom code development may encompass integration or interfaces to third-party sources, as well as migration of data from legacy or third-party systems to the envisioned solution. Again, it is suggested not to make these coding efforts overly complex.

The Standard project type customer profile is the one with a fairly decent number of system users—typically up to 250. With a higher number of users from a cross-section of the organization, the solution not only needs to account for varied requirements in each of the business units, but it also needs to handle interdependencies across these units. As such, moderate-to-complex customizations can be expected to retrofit the standard solution to the customer's workflows. The solution will also likely need to interface to a few subsystems, both from a data integration standpoint and from a reporting and business intelligence system or data warehousing standpoint.

The customers in the medium-to-large segment also typically have a reasonable number of experienced business and IT users who have used and/or deployed other non-legacy business solutions. Averages in this segment may be up to twenty years of full-time experience on the business side, and ten years on the IT side, with ERP/CRM and general business solutions. For the customer, it is important that these users are an integral part of the team that is helping to fashion the overall solution requirements, in selecting the solution that best corresponds to their needs, and in delivering the solution, including configurations and all the way through to user acceptance testing. It is easy for these users to be wrapped in their day-to-day activities and not have time for the project, and as such it is the responsibility of the management of the customer organization to ensure that these users get some sort of a relief from their daily tasks to be able to participate and have meaningful contributions to the solution delivery engagement.

The usage of the Standard project type can also be extended beyond the medium-sized organizations to large enterprises. For example, a large multisite organization, looking for a common solution across its organization, may look to deliver a similar solution that has already been deployed in a pilot site. While the pilot site solution may have been developed using the more robust Enterprise project type, future rollouts of the solution to ensuing sites could use the Standard project type. Such usage scenarios of solution rollouts are described in a later section.

The Enterprise project type

The Enterprise project type is the most rigorous of all the Sure Step project types. Designed for large complex scenarios, the Enterprise project type is characterized by deep program management activities, requiring focus and discipline from the customer and service provider throughout the length of the engagement. Large-scale engagements are typified by complex requirements and solution scenarios that necessitate a thorough approach for governance and oversight in all disciplines, including project management, solution configuration and setup, custom code development, and testing. To cater to these types of usage scenarios, the Enterprise project type is provided.

The following is a screenshot of the Enterprise Project Type in Sure Step. Included in the left navigation tree view in the screenshot is a partial view of the activities in the Analysis phase, which highlights the depth and diligence that is prescribed for project governance alone.

The typical usage scenarios for the Enterprise project type include the following:

  • The requirements for the solution include complex customization and/or multiple ISV solutions in addition to the core Microsoft Dynamics solution. In large engagements, especially multisite projects, it is not atypical to see multiple development teams spread out in different continents, building on specific requirements for the same solution. It is critical that these teams are all "working with the same sheet of music" so to speak, meaning that they are all working towards the same goal. To ensure that there is tight coordination between the teams and each of the teams understands the interdependencies, the Enterprise project type is used.

  • The custom code development efforts may include complex integration or interfaces to third-party sources, as well as migration of data from legacy or third-party systems to the envisioned solution. Again, the diligence provided by the Enterprise project type is needed here to ensure that risks are identified up front, as well as that mitigation scenarios are also developed to alleviate the risks, if needed.

  • Due to the far reach of the solution, a concerted effort for Organizational Change Management (OCM) is needed for the customer. The Enterprise project type prescribes activities for OCM experts to plan up front, and develop strategies and techniques for managing the projected change across the organization.

  • In concert with the OCM activities are the deep Business Process Analysis activities that allow the service provider and customer organization to discuss and document the future or to-be workflows for the customer. The activities and templates provided in Sure Step facilitate this for enterprise-scale customers.

  • Large scale engagements also require the installation and management of multiple environments for developing the solution. This not only requires a bigger investment in the hardware for the project, but it also requires activities for planning, setting up, maintaining, and transitioning these environments, including clear documentation for the teams that will be supporting these environments after the handoff, as prescribed in the Enterprise project type.

  • Multisite engagements, especially ones where a common, consistent solution is desired across the organization, also need a rigorous set of solution configuration and development activities advocated by the Enterprise project type. The development of the solution for these organizations can get even more complicated when each location also has a set of unique needs that need to be considered over and above the common list of requirements across the organization. The unique needs may stem from local country laws, accounting and reporting regulations pertaining to the local country, or from specific requirements of the local marketplaces.

The profile of the organization requiring the usage of the Enterprise project type is one with a very high number of system users—250 users and above. Depending on the number of locations that the solution is to be deployed at, coordinating across all the users requires a well-planned and thought out approach that is provided by this project type. This includes activities for gathering the requirements across the locations, training the super-users and end users for each location, as well as a thorough user acceptance testing of the solution at each site prior to deployment.

The organizations in this segment are also characterized by a large number of experienced users in the business and IT groups. Due to the size and reach of the solution, the customer organizations typically appoint selected resources from this experienced group as dedicated resources for the length of the solution delivery engagement. In effect, these resources are extensions of the implementation team, and these power users typically become the lead internal "go-to" persons to support other users after the solution becomes operational.
 
Others
 
- Microsoft Dynamics AX 2009 : Design and Implementation Patterns (part 2) - Table-Level Patterns
- Microsoft Dynamics AX 2009 : Design and Implementation Patterns (part 1) - Class-Level Patterns
- BizTalk 2009 : Creating More Complex Pipeline Components (part 4) - Custom Disassemblers
- BizTalk 2009 : Creating More Complex Pipeline Components (part 3) - Validating and Storing Properties in the Designer
- BizTalk 2009 : Creating More Complex Pipeline Components (part 2) - Schema Selection in VS .NET Designer
- BizTalk 2009 : Creating More Complex Pipeline Components (part 1) - Dynamically Promoting Properties and Manipulating the Message Context
- Microsoft Dynamics GP 2010 : Tailoring SmartLists by adding Fields
- Microsoft Dynamics GP 2010 : Controlling data with SmartList Record Limits
- Upgrading and Configuring SharePoint 2010 : Configuring a content database
- Upgrading and Configuring SharePoint 2010 : Creating and associating content databases to a specific web application and site collection
- Administering Active Directory Domain Services : Working with Active Directory Snap-ins (part 2) - Saving and Distributing a Custom Console
- Administering Active Directory Domain Services : Working with Active Directory Snap-ins (part 1)
- Microsoft Dynamic CRM 2011 : Canceling and Reopening a Service Request Case
- Microsoft Dynamic CRM 2011 : Resolving a Service Request Case
- Systems Management Server 2003 : Server Modifications After Installation
- Systems Management Server 2003 : Modifying the Installation
- Creating a SharePoint Form with InfoPath Designer : Create a Form Library from InfoPath & Design a SharePoint Form Using the SharePoint Form Library Template
- Creating a SharePoint Form with InfoPath Designer : Publish Your Form & Use Your Form in SharePoint
- Microsoft Dynamics AX 2009 : Code Access Security
- Microsoft Dynamics AX 2009 : Classes and Interfaces
 
 
Most View
 
- Adobe Flash Professional CS5 : Manipulating Symbols in 3D Space (part 1) - Controlling the camera view: Perspective and vanishing point
- Adobe Flash Professional CS5 : Manipulating Symbols in 3D Space (part 2) - Transforming symbols with the 3D Rotation tool
- Mobile Web Apps : Loading Pages (part 3) - Going Backwards
- Microsoft Dynamics AX 2009 : Design and Implementation Patterns (part 1) - Class-Level Patterns
- Introducing the iPhone SDK (part 5) - Programming Paradigms
- Beginning Android 3 : Set Up the Emulator
- Microsoft Excel 2010 : Analyzing Worksheet Data - Adding Data Validation to a Worksheet
- Microsoft Dynamic CRM 2011 : Resolving a Service Request Case
- Accessing PowerPoint on the Web and Mobile Devices (part 1) - Setting Up SkyDrive
- Microsoft Excel 2010 : Using Print Preview