Agile has been a big buzz word in the world of project delivery lately, but is it the right methodology for your CRM implementation? And if it is, how will you release it? There are several things you'll need to consider before making these decisions, and in today's blog, we will give you the information you need to decide whether Agile is right
for you!

So, what is Agile anyway? Whereas waterfall projects design and build everything up front for one release, Agile methodology advocates iterative releases continually building upon previous releases in a quick manner. Using short sprints to develop small, deliverable functionality, this approach allows for more immediate feedback and reduces rework. But how can you apply this to CRM implementations? And should you? Here are a few factors and approaches that will help guide your decision.

How do I know if Agile is the RIGHT approach for my CRM Implementation?

• Your organization has implemented Agile projects in the past and understands the process.
• You are comfortable making scope trade-offs and don't mind deploying a work-in-progress.
• You currently use multiple applications to accomplish different activities that will eventually be consolidated into Microsoft Dynamics CRM.

How do I know if Agile is the NOT the right approach for my CRM implementation?

• Your organization has never done Agile before.
• You want a big-bang approach so you can move onto other projects.
• You're looking to collect and leverage a lot of data right out of the gate.

With that information, do you think Agile might be the right approach for you? If so, here are some ideas to organize your Microsoft Dynamics CRM releases.

Approach # 1: System Area Releases

Microsoft Dynamics CRM has three main components: Sales, Marketing, and Services. Consider basing your releases around one component at a time. You might want to focus on Sales first, collecting prospect, lead, contact, and account data in CRM. Then you might branch out to Services components by creating ticket flows so your Service Desk can create tickets for accounts and contacts. Or your second release could focus on the Marketing component by segmenting customers and prospects into marketing lists and creating campaigns around them. The idea is to focus on the most important module in your organization and build releases that leverage the initial data you collected in the previous release.

Approach #2: Activity/End User-based Releases

Similar to the System Area Release approach, a different way to consider an Agile CRM implementation is to structure your releases around certain activities or end users. For example, you might focus your first release around account management activities (prospecting, surveys, reporting), then build out lead management functionality. Some examples of this may be activities around opportunities or lead management, an offline client, or mobile-device functionality. Take into account the audiences you might be training. Could segmented audiences help you determine and prioritize the functionality you need to get out the door first?

Additionally, you may want to consider this approach if you are currently using multiple tools to accomplish different areas of functionality, like if you want to sunset one application at a time for example. Structure your releases around bringing functionality into CRM as you sunset various systems.

Approach #3: Core Business Functions-based Release

Another way to determine releases is to look at your processes. If you can identify your core process (think of the essential skeleton steps needed to run your business) you can start by making your first release based around the bare minimum functionality needed. Something to consider is out-of-the-box functionality versus customizations or manual processes versus automated workflows. For instance, if you really need to get CRM released to end users, could you temporarily get by with searching for data manually and save report and dashboard creation for a later date? Think about what you really need right now and what would be nice to have later. Chances are, the bells and whistles you think you want in the beginning of the project will change once you've released core functionality.

Overall, implementing Microsoft Dynamics CRM using Agile strongly depends on the temperament of your project and your organization's culture. In the right scenario, Agile implementations can be far more successful than a waterfall implementation, but you should absolutely consider the factors above as you make your decision.

Check out our blog about Planning CRM Implementations for more thoughts on this topic. Which methodology have you used in Microsoft Dynamics CRM implementations? Would you do it differently next time? Why? Share with us your experience. We always love hearing from our readers!

Happy CRM'ing!