In order to put the RAD Approach in the proper context, let’s first touch on the different project approaches as described by Sure Step; providing for two distinct project implementation approaches: Waterfall and Agile. Sure Step defines the two approaches this way:

Waterfall: this approachis a sequential process that depicts a linear flow of activities from one phase to another, culminating with the solution being promoted to production and then into operation.

Agile: this approachrepresents an iterative solution development method that promotes a collaborative process between the resources that own and specify the requirements for the solution and the resources responsible for the development and rollout of the solution.

There are three waterfall-based implementation project types: Rapid, Standard, and Enterprise, (each having an increasingly higher level of capability, complexity, and cost.)

The Rapid project type represents the simplest delivery approach and is designed for out-of-the-box implementations of the CRM solution, with little to no customization of the standard solution.

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

·        A high degree of fit between customer requirements and CRM solution product features.

·        Minimal customizations needed to meet customer requirements

·        No ISV solutions needed

·        If requirements are classified as "gaps" with the prescribed solution, they require only simple custom code development efforts.

·        Business process analysis is not in the scope of the Rapid engagement

·        No Integration or interfaces to third-party sources

·        Initial data migration from legacy or third-party systems is straightforward or not needed

The Rapid project type is typically used in small-to-medium sized businesses deploying CRM solutions. The typical number of users is low, usually under 25. Customers would like the CRM 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. Typically these customers have little prior experience in implementing or using CRM solutions successfully. 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. The idea is to start with a more straightforward CRM solution and let users gain experience in the basics of CRM before jumping into complex solution scenarios and a high degree of business process automation.

The Standard project type is suitable for a wide range of customers and usage scenarios and is the most widely used of the Sure Step project types for CRM implementations.  This project type includes activities in all of the project lifecycle phases and supports 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 Standard project type is best suited for medium-to-large sized businesses that find a fairly high degree of fit of their CRM solution requirements with the corresponding CRM product solution. More importantly the required customizations should not be overly complex, in which case, the Enterprise project type may be better for managing the required custom code development.

The Enterprise project type is the most rigorous; it is designed for large complex scenarios, andis 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.

And finally we’ll briefly describe the non-waterfall approach: Agile.

The Agile project type was introduced in the Sure Step 2010 release, primarily to facilitate the development and rollout of a customized solution to customers who want to use the base CRM product as a “platform” and customize the solution to their specific needs. These projects tend to evolve their requirements iteratively over the course of the project, as opposed to the linear waterfall approach. Agile requires a flexible and iterative approach to development.

While the Waterfall approaches have activities flowing across multiple project lifecycle phases, the Agile project type has something called “Sprint cycles” to encompass Analysis, Design, and Development phases. The Agile project type also supports two phases, Deployment and Operation, at the culmination of the Sprint cycles. So, in this context, the Agile project type deviates from a strict Agile approach, and is fashioned as a blended approach for CRM deployments.

Now let’s turn our attention to the RAD Approach.

A RAD approach is a hybrid between the Rapid project type of the Waterfall variety and the Agile project type. In many CRM implementations, a very important value-add, and ROI-builder is business process automation. Hence the need for a RAD approach because the Rapid project type, by definition, keeps business process automation outside the scope of the project. In my opinion, I believe it is kept out of the Rapid project type for two main reasons:

·        Customers typically do not have written process flows and have no experience in identifying their desires states for business processes in the new CRM system

·        The time and cost required for consulting, design and development of automated business processes and flows

A product such as Microsoft Dynamics CRM provides such a bounty of riches in the area of business process automation; it would be a shame not to take advantage of it in the first phase of the CRM project. However, we need to be careful not to overbuild as it could backfire. It takes a savvy consultant to find the correct balance, identifying those high-value processes to automate, while guiding an inexperienced customer team through the process of identifying desired future states for business processes; then building the CRM automation while not “blowing the budget”.

Here is where the RAD approach to CRM implementation is employed. I’ll walk you through a project scenario utilizing a RAD approach.

Presuming the ideal conditions of a Rapid project type are in place for the most part, in the first week or so of the project it should be very easy to make the main field, screen, and view changes to the data model of the core CRM business records (like Account, Contact, Lead, Opportunity, Case, etc). This set of system changes can then be presented to the core team in a User Training session. We can then begin RAD sessions designed to bring about value-added process automation in a highly interactive approach. Each of these RAD sessions may simulate a “sprint cycle” of the Agile approach.

We recommend that the project team select no more than 3 or 4 processes to automate within the first phase of the CRM project. Each RAD session is a facilitated consulting and system walk-through session, driven by the Lead CRM Consultant and is designed to draw out (via discussion and debate among the customer core team) the desired “future state” of the business process flow. This can be flowcharted on a whiteboard or in Visio displayed to the team by projector during the session. Or the consultant/team can take notes of the desired process automation, and then the flows can be done back at the office after the session is completed.  For example,

 

The development team can then quickly produce the desired automation components in the CRM dev/test system for the next RAD session for review, feedback, and “signoff”. 

Note, the primary value of the RAD session is the customer team interaction and debate that it produces. RAD sessions of this type are extremely valuable in producing a final product of high-quality and high-value; a system in which the customer has ownership and the expected user adoption is therefore much higher. 

There are many reasons why I believe a RAD Approach is great for many CRM projects for small-medium sized businesses (SMB) or divisions of larger businesses:

·        Faster “time to market” than traditional waterfall approaches

·        Lower project cost

·        Higher level of user ownership and adoption

·        Customers are more hands-on and will provide better feedback

·        Customer team more likely to develop better quality test plans for UAT

·        Less surprises at User Acceptance Testing time

·        Customer team more likely to assist in training material development and giving end user training

·        Customer team more likely to develop their own business process flow documentation and more likely to refine it on their own going forward

·        Delivered solution is in better alignment with customer’s goals

·        Knowledge transfer and expertise built more organically than in a waterfall approach

·        Customer team begins to build their own expertise in doing CRM Consulting as a result of RAD session involvement

·        More self-sufficiency in subsequent CRM phases

Although not specifically integral to the topic of this blog, some readers may want to know the difference between Agile and Scrum, as these terms are used interchangeably at times. “Agile” is a term that is generic to project management. The Agile approach is used in project management across all industries. “Scrum” is a term reserved for software development projects, and is a type of Agile project.

With the Agile methodology the course/direction of the final product can be altered throughout the development lifecycle. At the end of each sprint cycle, an increment of work is presented by the development team to the testing team for feedback. With Agile each sprint cycle builds on the previous, therefore incrementally the final product becomes better and more closely-aligned to the customer’s ultimate desires.

Scrum is a type of Agile approach that is used exclusively in software development. It is just a framework and not a methodology or a full process. Scrum does not provide detailed instructions to follow; rather it is dependent on the quality and ingenuity of the team developing the software. Scrum tends to require a higher degree of cross-functional and self-organizing teams, having no “team leader” per se. There is more team discussion and analysis that drives the software development effort.

Since Scrum is an Agile approach, software product features are developed incrementally in sprint cycles, and a demonstration is performed for the testing team; then feedback is provided for the next sprint cycle until all features have been developed according to customer requirements.