A Sample CRM Project Scoping / Initiation Document

Over the years I have found that the biggest challenge in any CRM project is not the technology challenge but the people; the human component is the single most important aspect of a CRM project.

Project success is often based upon whether an implementation was delivered on time, a project should only been seen as a success if it meets the objectives of the business and the needs of the users. I promise you a project delivered a few weeks late that delights users will be a far greater success than a project delivered on time that isn’t used.

It is critical to involve the business stakeholders and the users from the outset of the project, it is also important to manage their expectations and make sure that as a team (internal and external) we are all working towards the same goal. Creating an understating between the project team (or implementation partner) and the business users will give you a far greater chance of delivering a successful project. One that is not only delivered on time but one and empowers the users and drives the business forward. A project scoping or project initiation document is one of my main tools for helping me to crystallise this understanding at the very outset of a project.

My primary aim when I do a project scoping document is to ascertain:

1. What are the objectives of the project from my perspective as someone who will be responsible for delivery?

2. What are the objectives of the project from the perspective of the customer who will be responsible for using and funding the system?

3. What is the basis of the engagement and how we will we work together to achieve the above objectives?

I always try to insist on agile projects, my firm belief is that large, big bang projects are extremely difficult to get right; I will cover agile delivery from the perspective of a CRM project in another post. No matter the methodology it is still important (in my opinion) to put together a project scoping document that forms the foundation of the understanding for the project.

The following is an example of a project scoping document, it’s not appropriate for all types of project but I hope you find it useful. When I was running projects I would often take a blank version of a document such as this with me whenever I met a client for the first time; it helps you focus the discussion and make sure you cover the most important points. As the early stages of the project progressed I would continue to add to the document with the objective of having it agreed with the client the earliest opportunity. It serves as our point of reference and the basis of an understanding between us.

The Project Scoping document could have the following sections:

1. Project Background2. Project Commercials

3. Project Methodology & Control

4. Project Team & Contacts

5. Project Scope

6. Future Scope

7. Out of Scope

Project BackgroundProvide a description of the business, the nature of the business, organisation chart and who their customer are. Briefly describe reasons for change and business benefits that are expected:

Expected impact to the business Expected impact to the customer

Expected return on investment

It is worth understanding previous projects and their reasons for success or failure.

Assumptions

Descrive or provide a list of high level project or business level assumptions that have been made.

Project CommercialsThis should outline the commercial basis of the project. Is the project billable? If it is billable, how with this be billed (fixed price, time and materials, capped etc).

What does the project include?

Software Installation? Licences?

Training?

Project Management?

Configuration?

Development?

Testing?

User Acceptance Testing?

Go Live Rollout?

Go Live Support?

Ongoing Maintenance?

Event at the outset of a project I believe it is important to set some expectation of possible costs and time scales, this helps the business prioritise what is important. Depending on what is known and what the project risks are, I try to give a range in terms of timescales as well as actual costs. It is very helpful if you can give the business some indicators as to what can influence the cost and timescales such as:

Is there a system being replaced Level of data migration required

Level of customization required

Level of availability of client personnel

Business / user expectation

Project Methodology and ControlIt is very important that a methodology for implementation and project control is agreed. Whether a project follows an agile or waterfall process you need to define this upfront, describe exactly what this means and what the level of “project ceremony” will be and what the expectation of the project and business uses team will be.

My advice for any project, particularly during early stages, is to maintain absolute focus on features that are easily perceived as useful and benefits that are highly visible. Address the most challenging aspects of the project first, prioritise features and items that are architecturally significant as well as those that meet business objectives.

A good methodology with the appropriate project and control should:

Allow the project team to work at maximum efficiency with the business requirement top of mind

Allow the business users full transparency into the project with the ability to influence the deliverable (under strict project guidance)

Ensure a consistent level of delivery, work and service across the team

Provide the ability to learn from previous projects, implement best practice and build upon that learning

Ensure information is shared and that there are not unreasonable expectations placed on individuals

A good project also needs good tools (a topic for another post). I would categorise these tools into the following:

Collaboration Tools Time Tracking Tools

Project Tracking Tools:

o Feature Requests Capture

o Bugs and Incident Capture

o Risks & Issues Capture

Project control meeting and updates

I would advise a single point of contact for all matters related to projects status and control; Project Manager or Product owner depending on your preferred terminology.

Additionally I would advise a single point of contact that represents the business and a single point of contact that represents the delivery team. Be careful, do not mistake the single point of contact as your only point of contact to the business. We want to involve the wider project team with the wider business users and stakeholders, it is critical to remove the gap between technology and business. The purpose of a single point of contact is a person who is responsible for day to day communication and ensuring that the right people are involved at appropriate times.

Status reports and meeting should be agreed, these can be:

Daily / weekly / monthly meeting or calls as appropriate Shared workspace for project updates

Distribution list and email notification for weekly project updates

Unfortunately emails seems to still be the preferred method of communication, but you really can’t rely on anyone reading them. It really isn’t good enough to say “well it was in an email I sent on xyz”. Try to limit emails usage to confirm something you agreed or discussed. You have to find ways to get your message heard and that means multiple channels

A typical weekly email update might be something like:

Project Summary & Commentary since last update Work done since last update period

Work to be done this period

Blockers / issues that needs addressing

Project Team and ContactsAgree who is a member of the team and try to set expectation of how much time might be needed from them or at least how long you expect questions should be answered in.

Project Team Delivery Team

Support Team

Infrastructure Team

Business Sponsor

Key Stakeholders

Project ScopeTry to reach an agreement on broad project scope and success criteria as quickly as possible. Try to achieve a project scope that can be delivered as early as possible but make sure that it still delivers value to the business or users. I learnt a lot in my time as a product manager about Minimal Viable Product (MVP). As I said before maintain absolute focus on features that are easily perceived as useful and benefits that are highly visible.

As soon as a new project is underway meet with the key stakeholders and identify the primary success criteria for the implementation and how this will be measured. Understand the reasons they are implementing a solution, for example are they replacing an incumbent system and if so why.

Project Requirements

Functional Requirements

Document at a very high level some of the major functional requirements of the system. Use Case titles with perhaps a brief explanation of the most important ones is enough at this stage.

It is likely that changes will need to be made to the out of the box system, therefore it is helpful during the early stages of the project to explain the differences between configuration, customisation and development tasks.

I typically define configuration tasks as:

Configuring system settings such as date formats, currency etc Setting up rules for email tracking

Creating business units and teams for permissions and security

Installing clients and configuring clients settings as required

Creating personal and/or system views

I typically define customisations tasks as:

Creation of new attributes Changing attributes labels and types

Creation of new forms, tabs, views

Creation of dashboards

Creation of business process rules (workflow)

I typically define development tasks as:

Integration with external systems Creation of new functionality

Enhancements to existing functionality

The early days of a project are a very exciting and creative time, even if all the suggested functionality cannot be delivered for day one, the ideas of the project team should be captured and can be phased in at a later date.

In line with the agile iterative process the aim is to deliver incremental functionality on regular basis. It is better to demonstrate functionality throughout the development process to ensure that the features are in line with business expectations.

Reporting Requirements

Describe at a high level any reports or dashboards that need to be produced. This often feeds back into the data that needs to be captured and therefore influences the data model. Understanding the reporting requirement will also help focus on capturing only the information that is absolutely necessary, we want to avoid turning our business users into data entry personnel. Try to understand the reason behind the report and ascertain if in realty it gives any insight into the business.

Integration Requirements

Identify what integrations are necessary and if these integrations are views onto other data (“iframes”) or if the data needs to reside in the CRM system. Try to keep as much of the data outside of the CRM system as without true integration this vastly simplifies the project. We want to avoid users having to open multiple systems (this can be done using iframes) but we also don’t want to turn the CRM system into a data warehouse or a duplicate of another back office system.

Consider questions such as

Does the data need to be updated by the user? Is there data that would be useful in reports, workflow, dashboards, devices?

One way or two way integration?

Batch or real-time integration?

Frequency of integration?

What will be the golden source?

What happens if data or system is unavailable?

Data Migration

Assign ownership of the data migration process. This individual needs to understand the data, have the power to make decisions and have the capacity time wise to find answers to questions from the project team. Taking a pragmatic approach to data migration and understanding the challenges (not trying to achieve absolute perfection on every element) will have a vast impact on the cost and the success of the project.

Describe the data migration required for the project and list the various data sources (if any). Be clear about the following:

Number of data sources (specifically the number of different schemas) Complexity of the mapping and business logic to be applied

Quality of the data

Data cleansing requirements

Volume of data to be migrated

If the data will be imported manually using the Data Import Wizard or though other data tools or the API

Performance and speed of the source system (Microsoft CRM Online will quite happily create 400 records per second, but if the source system is slow and the performance cannot be guaranteed you need to factor this in). Describe your expectations of the environment and permissions (if any) that will be needed.

Data Migration is probably the riskiest part of any project and the most difficult to estimate. I would advise (for quick start projects or pilot projects) fixing the time of data migration and just attempting to do as much as possible. An agile process is perfect for this. Iterate, iterate, iterate:

Define Migration Specification Sprint / Cycle One

o Cycle with basic data

o Review finding and plan next migration

Sprint / Cycle Two

o Cycle with additional data

o Review finding and plan next migration

Sprint / Cycle Three

o Cycle with additional data

o Review finding and plan next migration

And so on…

Non Functional Requirements

Detail any non functional requirements. These requirements can be anything from specific compliance constraints to disaster recovery and performance. You will need to carefully consider who to ascertain the requirements from as it is likely to be a mix of business and IT stakeholders. Typical non functional requirements are:

Backup Requirements Performance Requirements and Expectations

Disaster Recovery

Extensibility and Maintainability

Security

Training

Describe the training that will be provided. If the training will be to end users or will you use a train the trainer approach? Include training for the project team here not just the training prior to go live. Many projects are delayed because the UAT team have not been sufficient involved or trained. Train early, train often and engage the users from the outset with relevant sessions. Avoid long training sessions and try to split the training into role/goal based courses.

I like to do a simple one hour introductory session followed by two or three follow up sessions a week or so later and then a refresher near Go Live.

Describe the requirements:

End user training Train the trainer

On site or remote training

Facilities required (room, projector, screens etc)

Number and types of sessions

Level of tailoring

User Acceptance Testing (UAT)

User Acceptance Testing should be done throughout the implementation lifecycle and not just at the end. If you do it at the end you’ll discover problems to late. Developing the most difficult aspects first will give you more time to resolve or provide workarounds. Make sure to involve the right business users in the UAT process.

Describe the UAT process that will be carried out and what the tools that will be used are going to be. Set expectations of response time and manage it like an SLA. Keep on top of scope creep! Like data migration this is often an area that can get out of control. So like data migration assign a single point of contact that has capacity and authority to make tough and timely decisions.

Go Live

This is all about planning; if the business has been involved throughout then there should be no surprises. A Go Live document should describe the team, logistics and steps required to put the project live:

Sign off commercials and agreement with all suppliers Installation of any applicable licences

Installation and configuration of users

Final data migration

Training of remaining user base

Go Live support

Go Live plan

Rollback plan

Out of scopeAs important as it is to know what is in scope, if you know something cannot be done within the costs and timeframe then speak now! Similarly this is a chance for the business to provide further focus for the project by eliminating items that are lower priority and that should not be considered.

As the project progresses, many new requirements are going to be discovered. Do not dismiss these because they are out of scope, instead capture them, evaluate them and make sure that are considered for future releases. Getting additional requirements is a good sign that the users are engaged, make them feel that their voice is heard, show them that their requirement are being captured.

ConclusionI hope the above is useful, as I said in the introduction, this is not appropriate for all projects nor is it a comprehensive project initiation guide. I do hope however that I have been able to provide you with some help towards your next project.

This posting is provided “AS IS” with no warranties, and confers no rights.