High-level tasks for a Dynamics CRM 4.0 project

In a previous post, I listed many of the technical skills that a Dynamics CRM 4.0 implementation team likely needs to possess in order to design, code, deploy, and support a truly useful and rock solid system. In this post, I'm going to share some thoughts on the roles and tasks that go into successfully launching a Dynamics CRM system.

On my CRM projects over the years, I've worn the hat of most of the project role members you'll see below - sometimes many of them at the same time. On a CRM deployment with only 10 users, I was the sole contributor - from business analyst to C# developer and everything in between. But most often I've worked on a 2-5 member team, with the largest deployment coming in at 500+ users.

Let's take a look at the hats that you might have to wear on your next project by stepping through the high-level tasks of a Dynamics CRM 4.0 project.

Needs Assessment

Goals and Tasks:

• Gain a thorough understanding of the needs of the stakeholders and their business and end-users.
• Identify and meet with key business stakeholders and domain experts. Ask lots of questions and write down every answer.
• Create and distribute documentation listing the project vision, scope, risks, and assumptions.
• Understand and communicate the project scope. What's in and what's out?

Team Members:

• Business Analyst
• Project Manager
• Senior Developer

Just a thought... Isn't it awesome at this stage of the project to know that, with Dynamics CRM 4.0, you can deliver an extremely robust CRM or line-of-business application for dozens or hundreds of users in less time than it takes an average IT shop to decide between .NET vs. Java or thick-client vs. browser-based? Think about it... you're out of the gate with a solid and proven enterprise software architectural design including role-based security, web services API, metadata-driven UI and business object engine, customization tools and much more without writing a single line of code. Now, designing business objects, writing plugins, creating SRS reports, and integrating the system with other systems takes time and skill, but the point is that you can focus much more on the needs of the business and less on how you're going to provide e-mail templates, workflow, or hundreds of other features -- because many of them are already ready to go! Anyway, just a thought...

Project Plans

Goals and Tasks:

• Define the work that will be done on the project and who will do it. This typically involves creating a statement of work (SOW), requirements specification, use cases, test and defect tracking plans, a list of resources and their availability, a work breakdown structure (tasks and time estimates), and a project schedule.
• Requirements Elicitation: Gather, understand, review, and articulate the needs of the system's stakeholders and users. Observe current business processes, interview users and stakeholders, and distribute summaries for verification.

Team Members:

• Project Manager
• Test Lead

Dynamics CRM 4.0 Implementation Plan

At this point, you should carefully read the Dynamics CRM 4.0 Implementation Guide to gain an understanding of Microsoft's recommended approach to planning, designing, configuring, customizing, and deploying a CRM 4.0 system. However, as lengthy and detailed as the Planning and Installation Guides are, they don't cover many of the real-world project topics such as setting up and using a defect tracking system, utilizing a source code repository, or conducting system testing. I'll cover these topics below.

Team Members:

• Project Manager
• Development Lead
• Test Lead

Project and File Management Tools

Below are some of the tools I put in place before starting in on a Dynamics CRM 4.0 deployment.

• Requirements Management: Ideally, system requirements should be maintained in a system that's accessible to all project team members and stakeholders. In the past, I've used the customer's Dynamics CRM system (in a stable environment) for this purpose. I created a custom "System Requirements" entity and added attributes such as requirement name, id, description, priority, time estimate, key stakeholder(s), questions/answers, requirement elicitation status, implementation status, etc. If it's not possible for you to utilize the CRM system for this purpose then Excel (maintained in SharePoint, of course) works well, too.
• Version Control: It's essential to set up a version control system (such as Microsoft Visual SourceSafe) to safely store and track documentation, source code, exported CRM XML-based customization files, and other system artifacts. Also, assign someone the task of making backups of the file repository and keeping a copy off-site (if allowed by the company).
• Defect Tracking: Given the ease of customization in Dynamics CRM 4.0, you could utilize the "test" system for tracking defects. However, if this is not practical or possible then you'll find several excellent choices for logging and tracking the status of system defects. Systems that I've used in the past (that I've liked) include FogBugz and Jira.
• Automated Builds: If your CRM 4.0 deployment includes plugins, custom ASP.NET applications, Windows services, or other compiled code, consider taking the extra time to automate the compilation and deployment of all software components. Tools such as MSBuild and NAnt help make full automation of builds and deployment a reality. The benefits of this type of automation are that you don't have to build and deploy manually hundreds of times (thus saving you lots of time in the long run) and you'll end-up with fast and consistent deployments.
• SQL Server Backups, scheduled at least daily. Backing up the CRM databases will not only preserve your hard work designing entities and attributes but will also store the hundreds of lines of JScript you've no doubt written for your project. Needless to say, this is a critical task that should be scheduled and verified at least once per day.

Team Members:

• Project Manager
• All Developers
• All Testers
• System Stakeholders

System Configuration and Customization

Note: This section is incomplete. I'll fill-in the details here soon.

• Entities and attributes
• Forms: layout, data validation, JScript code, dynamic picklists, tabs, views
• Navigation: SiteMap, isv.config
• Security Roles
• E-mail: inbound, outbound, tracking, templates
• Reports
• Workflow
• Plugins and workflow assemblies
• Custom applications: ASP.NET, IFRAME, ISV folder
• Systems Integration
• Outlook considerations: customizations, offline/online

Testing

Goals and Tasks:

• Make sure that the system does what the users and stakeholders want it to do and as agreed upon in the SOW and requirements documentation.
• Execute the test plan. Log all defects.

Many more project details coming soon... please check back for an update to this posting.