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 wee!s 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 sta!eholders and the users from the outset of the project it is also important to manage their e#pectations and ma!e sure that as a team $internal and e#ternal% we are all wor!ing 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. & 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' (. )hat are the objectives of the project from my perspective as someone who will be responsible for delivery* +. )hat are the objectives of the project from the perspective of the customer who will be responsible for using and funding the system* ,. )hat is the basis of the engagement and how we will we wor! together to achieve the above objectives* I always try to insist on agile projects my firm belief is that large big bang projects are e#tremely difficult to get right; I will cover agile delivery from the perspective of a CRM project in another post. -o 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. .he following is an e#ample of a project scoping document it"s not appropriate for all types of project but I hope you find it useful. )hen I was running projects I would often ta!e a blan! 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 ma!e sure you cover the most important points. &s 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. .he Project /coping document could have the following sections' (. Project 0ac!ground +. Project Commercials ,. Project Methodology 1 Control

2. Project .eam 1 Contacts 3. Project /cope 4. 5uture /cope 6. Out of /cope

Project ac!ground
Provide a description of the business the nature of the business organisation chart and who their customer are. 0riefly describe reasons for change and business benefits that are e#pected'

7#pected impact to the business 7#pected impact to the customer 7#pected return on investment

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

Assumptions
8escrive or provide a list of high level project or business level assumptions that have been made.

Project Commercials
.his should outline the commercial basis of the project. Is the project billable* If it is billable how with this be billed $fi#ed price time and materials capped etc%. )hat does the project include*

/oftware Installation* 9icences* .raining* Project Management* Configuration* 8evelopment* .esting* :ser &cceptance .esting* ;o 9ive Rollout*

;o 9ive /upport* Ongoing Maintenance*

7vent at the outset of a project I believe it is important to set some e#pectation of possible costs and time scales this helps the business prioritise what is important. 8epending on what is !nown and what the project ris!s 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 9evel of data migration re<uired 9evel of customi=ation re<uired 9evel of availability of client personnel 0usiness > user e#pectation

Project Methodology and Control

It is very important that a methodology for implementation and project control is agreed. )hether a project follows an agile or waterfall process you need to define this upfront describe e#actly what this means and what the level of ?project ceremony@ will be and what the e#pectation 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. &ddress the most challenging aspects of the project first prioritise features and items that are architecturally significant as well as those that meet business objectives. & good methodology with the appropriate project and control should'

&llow the project team to wor! at ma#imum efficiency with the business re<uirement top of mind &llow the business users full transparency into the project with the ability to influence the deliverable $under strict project guidance% 7nsure a consistent level of delivery wor! and service across the team Provide the ability to learn from previous projects implement best practice and build upon that learning 7nsure information is shared and that there are not unreasonable e#pectations placed on individuals

& good project also needs good tools $a topic for another post%. I would categorise these tools into the following'

Collaboration .ools .ime .rac!ing .ools

Project .rac!ing .ools'

o o o

5eature Re<uests Capture 0ugs and Incident Capture Ris!s 1 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. &dditionally I would advise a single point of contact that represents the business and a single point of contact that represents the delivery team. 0e careful do not mista!e the single point of contact as your only point of contact to the business. )e want to involve the wider project team with the wider business users and sta!eholders it is critical to remove the gap between technology and business. .he 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. /tatus reports and meeting should be agreed these can be'

8aily > wee!ly > monthly meeting or calls as appropriate /hared wor!space for project updates 8istribution list and email notification for wee!ly project updates

:nfortunately 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 #y=@. .ry to limit emails usage to confirm something you agreed or discussed. Aou have to find ways to get your message heard and that means multiple channels & typical wee!ly email update might be something li!e'

Project /ummary 1 Commentary since last update )or! done since last update period )or! to be done this period 0loc!ers > issues that needs addressing

Project "eam and Contacts

&gree who is a member of the team and try to set e#pectation of how much time might be needed from them or at least how long you e#pect <uestions should be answered in.

Project .eam 8elivery .eam

/upport .eam Infrastructure .eam 0usiness /ponsor Bey /ta!eholders

Project Scope
.ry to reach an agreement on broad project scope and success criteria as <uic!ly as possible. .ry to achieve a project scope that can be delivered as early as possible but ma!e sure that it still delivers value to the business or users. I learnt a lot in my time as a product manager about Minimal Ciable Product $MCP%. &s I said before maintain absolute focus on features that are easily perceived as useful and benefits that are highly visible# &s soon as a new project is underway meet with the !ey sta!eholders and identify the primary success criteria for the implementation and how this will be measured. :nderstand the reasons they are implementing a solution for e#ample are they replacing an incumbent system and if so why.

Project Re$uirements
%unctional Re$uirements
8ocument at a very high level some of the major functional re<uirements of the system. :se Case titles with perhaps a brief e#planation of the most important ones is enough at this stage. It is li!ely that changes will need to be made to the out of the bo# system therefore it is helpful during the early stages of the project to e#plain the differences between configuration customisation and development tas!s. I typically define configuration tas!s as'

Configuring system settings such as date formats currency etc /etting up rules for email trac!ing Creating business units and teams for permissions and security Installing clients and configuring clients settings as re<uired Creating personal and>or system views

I typically define customisations tas!s as'

Creation of new attributes Changing attributes labels and types Creation of new forms tabs views

Creation of dashboards Creation of business process rules $wor!flow%

I typically define development tas!s as'

Integration with e#ternal systems Creation of new functionality 7nhancements to e#isting functionality

.he early days of a project are a very e#citing 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 e#pectations.

Reporting Re$uirements
8escribe at a high level any reports or dashboards that need to be produced. .his often feeds bac! into the data that needs to be captured and therefore influences the data model. :nderstanding the reporting re<uirement 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. .ry to understand the reason behind the report and ascertain if in realty it gives any insight into the business.

Integration Re$uirements
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. .ry to !eep as much of the data outside of the CRM system as without true integration this vastly simplifies the project. )e 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 bac! office system. Consider <uestions such as

8oes the data need to be updated by the user* Is there data that would be useful in reports wor!flow dashboards devices* One way or two way integration* 0atch or realDtime integration* 5re<uency of integration* )hat will be the golden source* )hat happens if data or system is unavailable*

Data Migration
&ssign ownership of the data migration process. .his individual needs to understand the data have the power to ma!e decisions and have the capacity time wise to find answers to <uestions from the project team. .a!ing 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. 8escribe the data migration re<uired for the project and list the various data sources $if any%. 0e clear about the following'

-umber of data sources $specifically the number of different schemas% Comple#ity of the mapping and business logic to be applied Euality of the data 8ata cleansing re<uirements Colume of data to be migrated If the data will be imported manually using the 8ata Import )i=ard or though other data tools or the &PI Performance and speed of the source system $Microsoft CRM Online will <uite happily create 2FF records per second but if the source system is slow and the performance cannot be guaranteed you need to factor this in%. 8escribe your e#pectations of the environment and permissions $if any% that will be needed.

8ata Migration is probably the ris!iest part of any project and the most difficult to estimate. I would advise $for <uic! start projects or pilot projects% fi#ing the time of data migration and just attempting to do as much as possible. &n agile process is perfect for this. Iterate iterate iterate'

8efine Migration /pecification /print > Cycle One

o o

Cycle with basic data Review finding and plan ne#t migration

/print > Cycle .wo

o o

Cycle with additional data Review finding and plan ne#t migration

/print > Cycle .hree

o o

Cycle with additional data Review finding and plan ne#t migration

&nd so onG

&on %unctional Re$uirements

8etail any non functional re<uirements. .hese re<uirements can be anything from specific compliance constraints to disaster recovery and performance. Aou will need to carefully consider who to ascertain the re<uirements from as it is li!ely to be a mi# of business and I. sta!eholders. .ypical non functional re<uirements are'

0ac!up Re<uirements Performance Re<uirements and 7#pectations 8isaster Recovery 7#tensibility and Maintainability /ecurity

"raining
8escribe 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 :&. team have not been sufficient involved or trained. .rain early train often and engage the users from the outset with relevant sessions. &void long training sessions and try to split the training into role>goal based courses. I li!e to do a simple one hour introductory session followed by two or three follow up sessions a wee! or so later and then a refresher near ;o 9ive. 8escribe the re<uirements'

7nd user training .rain the trainer On site or remote training 5acilities re<uired $room projector screens etc% -umber and types of sessions 9evel of tailoring

'ser Acceptance "esting ('A")

:ser &cceptance .esting 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. 8eveloping the most difficult aspects first will give you more time to resolve or provide wor!arounds. Ma!e sure to involve the right business users in the :&. process. 8escribe the :&. process that will be carried out and what the tools that will be used are going to be. /et e#pectations of response time and manage it li!e an /9&. Beep on top of scope creepH 9i!e data migration this is often an area that can get out of control. /o li!e

data migration assign a single point of contact that has capacity and authority to ma!e tough and timely decisions.

*o +ive
.his is all about planning; if the business has been involved throughout then there should be no surprises. & ;o 9ive document should describe the team logistics and steps re<uired to put the project live'

/ign off commercials and agreement with all suppliers Installation of any applicable licences Installation and configuration of users 5inal data migration .raining of remaining user base ;o 9ive support ;o 9ive plan Rollbac! plan

,ut of scope
&s important as it is to !now what is in scope if you !now something cannot be done within the costs and timeframe then spea! nowH /imilarly 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. &s the project progresses many new re<uirements are going to be discovered. 8o not dismiss these because they are out of scope instead capture them evaluate them and ma!e sure that are considered for future releases. ;etting additional re<uirements is a good sign that the users are engaged ma!e them feel that their voice is heard show them that their re<uirement are being captured.

Conclusion
I 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 ne#t project. .his posting is provided ?&/ I/@ with no warranties and confers no rights.