Project Management CRM Best Practices - Project Work plan

This is the continuation of a series of posts regarding the Project Management CRM best practices.
Today I will talk about how to create a planning horizon without compromising the CRM solution in the
future and is performance.
After the project definition has been prepared (see my previous post about planning), the work plan can
be created. The work plan provides the step-by-step instructions for constructing project deliverables
and managing the project, please try not to do copy & paste of previous projects, we always need to
reflect what we going to deliver in each stage and the customer need to be aware of our task for that
week or month (last case scenario) this also depends if we have week deliverables or not.
Create a work plan as detailed as possible with resources assign, estimations and dependencies but
count always with some security pool as far out as your developers feel comfortable. This will be your
planning horizon but bear in mind certain details like creating 200 fields in just one entity, this will have
impact on performance later on with the extension of the product for other business areas, so this will
be a design issue, so for that reason is necessary to review the project design after each deliverable for
the next models/functionalities to be implemented. If that features are still not sign off from the
customer and we only have a draft of it.
After the planning horizon, we need to go to a higher level so we can decrease the level of uncertainty
by planning this our horizon we will move forward as he project progress, high-level activities that were
initially vague need to go down to the level of a feature, plugin, custom workflow activity or even
JavaScript, so the level of detail will get closer in terms of timeframe. On most of the projects and
depending the time we got for development, project management or business analysis, we should
always go for a level of feature, and on this feature we will include all the plugins, custom workflows and
JavaScript related to that feature, so this will help us on dividing the releases by solutions per feature (if
we are not merging solutions or package deplorer), Any way this solution creation is a matter of
architecture than project management.

Project Management CRM Best Practices Project

Management Procedures
This is the continuation of a series of posts regarding the Project Management CRM best practices.
Today I will write about how to define project management procedures. After the work plan definition
has been prepared (see my previous post about Work plan), the project management procedures can be
defined.
To define project management procedures up front we need to outline the resources that will be used
to manage the project. This will include sections on how the team will manage issues, scope change,
risk, quality, communication, and so on. It is important to be able to manage the project rigorously and
proactively and to ensure that the project team and all stakeholders have a common understanding of
how the project will be managed. If common procedures have already been established for your
organization, use them on your project. Once the project has been planned sufficiently we can manage

the work plan and monitor the schedule and budget, execution of the work can begin. But be careful
with things like "as soon the project is approved let go develop" this is completely wrong, we always
need to create a nice and good technical design by the Microsoft best practice, with mock-ups, what
bottoms should be shown, how the security model should be implement, etc. If you don't do this, what
is going to happen? You will finish telling the client how we feel how they should proceed and them?
You will redesign 10 times each process... so make yourself a favor and draw mock-ups to make the user
understand what is going to get, this is a really, really important.
In theory, since you already have agreement on your project definition and since your work plan and
project management procedures are in place, the only challenge is to execute your plans and processes
correctly but because there`s no project ever goes as it was estimated and planned, the challenge is
having the rigor and discipline needed to apply your project management skills correctly and
proactively, detailed as possible, describing what is need in every single workflows, business flow,
plugin, web service, etc. Review the work plan on a regular basis to determine how you are progressing
in terms of schedule and budget. If your project is small, this may need to be meet 2 times per week, 30
minutes is enough to keep the track on the project and for bigger projects 1 per week with 1 or more
hours. Identify all the tasks for the week after and chase the current week tasks and update the work
plan to show they are finished.
Determine whether there are any other activities that should be completed but have not been like a
new plugin that wasn`t in plan. After the work plan has been updated, determine whether the project
will be completed within the original effort, cost, and duration. If not, determine the critical paths and
look for ways to accelerate these tasks to get you back on track or same times certain changes or tasks
need to be pushed to other phase. Monitor the budget if we are working with fix price and in a case of
time materials make sure the client has budget to cover the excess of work. Be sure that the amount of
money your project has actually consumed and determine whether you`re actual spending is more than
originally estimated based on the work that has been completed. Be proactive talk with your developers
and predicted the amount of the remaining work and when will be completed to hit your original budget
or else raise the risk with the client so you can exceed the initial budget.
Being proactive you will need to look for signs like:
Variance in schedule and budget starts to get bigger, especially early in the project. There is a tendency
to think you can make it up, but this is a warning. If the tendencies are not corrected quickly.
You discover that activities you think have already been completed are still being worked on. For
example, users are still working in test scripts and is taking longer than actually it should.
You need to rely on overtime to hit the deadlines sprints especially in the begging on the project.
Team morale starts to decline. Deliverable quality stars to deteriorate. For instance, users complain on
workflows or plugins not working like calculations, emails, etc., java scripts giving errors on the load of
the page, be sure the developers do they on test before put the solution in UAT.
There`s rolls back need to be done.

Project Management CRM Best Practices - Planning

I will try to explain the best practices and the way to conduct a really successful project, so the first thing
we need to think before go to a client and ask what they want, we need to have in the back of our mind
all the features and gaps of the solution, this applies to any project when we are proposing a solution.
It`s imperative that our PM`s (if not us) need to have knowledge of the solution, in this case they at least
need some basic information unless all the interactions with the client we attend with an Architect CRM
solution or Senior CRM consultant/developer.
A PM for more projects his has implement they will never know or be updated of the gaps and features
of the solution and those could be important for the client and to the project.
But in any case we can never promise to the client to build the Taj Mahal in 3 months, because that will
never happen or will be highly cost for the client.
Therefore, when we thing in implementing a project we need to have in mind this amazing triangle and
usually we can only choose 2 options.
Along the years I have seen projects going wrong and projects going right sometimes caused by this
amazing triangle, but in all the cases we need to analyze and learn from them and to understand what
went wrong and what went well.
The right mix of planning, monitoring, and controlling can make the difference in completing a project
on time, on budget, and with high quality results. These guidelines will help you plan the work and work
the plan. Ok! But this is applied to all the projects what we have to do for CRM?
Well, given the high rate of project failures, you might think that companies would be happy to just have
their project finish with some degree of success. That's not the case. Despite the odds, organizations
expect projects to be completed faster, cheaper, and better. So make sure you divide the
implementation in small modules and deliveries, like sales, marketing, products or other xRM
development, dont try to do everything in just one shot, will not work and the client will only see
nothing for a long period of time and you not giving any value so build you project based on this
premises. The only way that these objectives can be met is through the use of effective project
management processes and techniques.
Plan the work and define the task very well for each resource in your team, bear in mind if you are
working with several resources in your team for CRM, you need to have concerns in terms on
deployment and how you going to deploy the several solutions or solution, and how you will integrate
this, so in this case plan some time for the guys to do this. Microsoft CRM has weak line integration
solution with no trace, so if you working with unmanaged solution or managed solution keep always a
backup of the project, so once more give time for the guys to do this.
Note: This is really high level plan example not for CRM*

Project Management CRM Best Practices - Managing Risk

This is the continuation and the last post regarding the phases of Project Management CRM best
practices.
Today I will write about managing the risk. After the managing scope definition has been set (see my
previous post about Managing Scope), we can start to managing the risk.
The biggest challenge in a project is to identify risks up front, because there are too many variables in a
project, starting with infrastructure, resources or solution, cause by the fact we are expecting some kind
of performance or feature and don't work and we need to redesign the all or part of the concept. This
happen to me in the last CRM 2013 project that i think the security model that i implement will work
fine applying security field but One of the big limitations of Field Security in previous versions of
Dynamics CRM was that it was only available on custom fields and not on out of the box fields. In
Dynamics CRM 2015 however Field Security can now be enabled on most out of the box fields, with only
certain system fields such as the primary key/primary field or status/status reason not having Field
Security as an option, and i have other issue cause by the fact the entity was created as organization
level and not user level not allowing me to implement an shared record security model. And the entire
security model had to be redesign.
When the planning work is occurring, the project team should identify all known risks. For each risk,
they should also determine the probability that the risk event will occur and the potential impact on the
project, one of the most common risk is the time spend on installation just because the service user
dont have access, even after we advise the client before the project start or scope creep, other
examples could be given. Those events identified as high-risk should have specific plans put into place to
mitigate them so they do not occur. Medium risks should be evaluated to see whether they need to be
proactively managed. For medium risk we may identify as assumptions like creating a mock-up that we
know for sure will be changed and we know that the form will have 30 fields instead of 150, this kind of
assumptions could help us to estimate and the outcome is much more probable. Continue to assess
potential risks throughout the project once the project begins and periodically perform an updated risk
assessment to determine whether other risks have surfaced that need to be managed. Bear in mind
always the features that the new CRM releases are coming if you are working online or offline, this is
really important an can give some implications or could solve halt of your issues, like for example the
new features available in CRM 2016 will help you on reporting or data analysis. Microsoft is now giving
us new features ever single year, and big jumps have being made, and sometimes this could cause some
impact on your project, especially if you are working online.
Issues are big problems, so try to resolve as quickly as possible. For instance, if you are migrating an
organization data from on-premises to online and on that organization you have Field One or AdxStudio
solutions and then you see that by importing data throw spreadsheets that will not work and you
basically, in my case I had to rewrite all the XrmToolKit so the import could be done.
So the project manager should manage this kind of open issues to ensure that they are being resolved. If
there is no urgency to resolve the issue or if the issue has been active for some time, it may not really be
an issue, because the user simply considers that is just nice to have and It may not be a potential
problem (risk), or it may be an action item that needs to be resolved at some later point. Real issues, by
their nature, must be resolved with a sense of urgency, but always prioritize them.

P Management CRM Best Practices - Managing Scope

This is the continuation of a series of posts regarding the Project Management CRM best practices.
Today I will write about how to manage scope. After the Procedures definition has been set (see my
previous post about Procedures), we can start to managing the scope.
On a perfect world we need to ensure that the sponsor approves scope-change requests, otherwise is
my opinion to set dates to automatically consider them as approved past a few days if we don't have
any answer from the customer side.
After the basics of managing the schedule, managing scope is the most important activity required to
control a project. Many project failures are not caused by problems with estimating or team skill sets
but by the project team working on major and minor deliverable because the team is working in parallel
projects for other clients and when they come back they don't know what to do, or just because is not
part of the original project definition or business requirements. Even if you have good scopemanagement procedures you need to avoid the Organization/Agency to hijack your resources for other
projects.

There are still two major areas of scope-change management to be successful, one is to understand
who the customer is and scope creep.
Most of the times the project sponsor is the person who is funding the project. In CRM case it could start
from Marketing, Sales, or even CFO, rally will start from CIO unless there's a huge infrastructure project
that need to be changed, too many databases, excels, or even integration with Microsoft Exchange etc,
Although there is usually just one sponsor, a big project can have many stakeholders, or people who are
impacted by the project, here is the hard part sometimes is not clear that in fact that stakeholders is the
one we should be talking too, because he thinks we his the stockholder but is not, in this case take care,
listen what he have to say and validate all the inputs with the sponsor, politics can be problematic and
has to be well managed. So all the requests for scope changes will most often come from stakeholders,
many of whom may be managers in their own right. One manager might want workflow that sends
emails automatically to his team because there`s new leads.
Another might want an exception to in certain leads will receive email. It doesn't matter how important
a change is to a stakeholder, they can't make scope-change decisions, and they can't give your team the
approval to make the change. So you need to define a common ground and sometimes the decision
"advise" need to come from you, in proper scope-change management, the sponsor (or a designate)
must give the approval, since they are the only ones who can add funding to cover the changes and
know if the project impact is acceptable.
There is no project that scope didnt creep, most of them cause by the time spend on the analysis, time
we had to do the scope, stakeholders changed their minds, etc. Most of the project managers know to
invoke scope-change management procedures if they are asked to add a major new function or a major
new deliverable, just because the we need to develop a new plugin because the business rule or one of
the roll-ups dint answer the need we had with calculations.

However, sometimes the project manager doesn't recognize the small scope changes that get added
over time. What we consider as a scope creep is the fact we have a series of small scope changes that
are made to the project without scope-change management procedures being used, just because we
consider its a small change and none of which appear to affect the project individually. But in matter of
fact this can grow and can accumulate a significant overall impact on the project. Many projects fail
because of scope creep, and the project manager needs to be diligent in guarding against it. The scope
creep, allows also the business to say that the deliverable is not done causing delays on the project, and
the adoption are not done by the business and at the end the project fails because no one is using it.

CRM Business Analysis - Best Practices

In most of the project I was in, usually the client doesnt have a clear view of the requirements, because
either we are implementing a system for the first time or they have some requirements from the old
system therefore we need to be cautious with the change management.
Many of the organizations do quality work around project management and practiced some SDLC, be it
Agile or Waterfall. However, the analytical expertise in the business analysis are the most important
factor that serves as a differentiator for achieving success in the project.
In terms of required requirements, we need to create prototypes (POC`s) in a storyboard fashion which
will allow the client to see himself what is being delivered in the solution. But my advice here is never
allow a POC to become a production solution, this will bring problems in the future. So the business
stakeholders need to see this business process reflected on the solution, but they must be prepared for
change.
What only matters are if the stakeholder is the owner of the process, otherwise we are spending our
time and the requirements will be changed after if his not the one how is going to decided, so we need
to meet with as many stakeholders as we can as many times as we need in order to gather our
requirements.
A requirement must have only ONE requirement and on it several tasks, make sure it can be testable
otherwise is consider invalid requirement. Bear in mind that we are talking about requirements and not
features, features is what we deliver when we build a solution in CRM case we deliver requirements
because we do services. Unless you are building vertical solution like Field One, Click Dimensions, Ad
studio or other type of vertical.
In many meetings I hear "system must be user-friendly?", this dont tell us nothing, the use of mock-ups
will help the user to understand how easy and user friendly is. Or we should use the same front end like
the old system, because people are used to it, dont try to invent the wheel, otherwise we are not given
any value to the customer in actual sense for longer-term, in this case the question should be why you
want to change?
Validating the requirements and getting the sign off is important, otherwise the customer will think we
are incompetent for going back to for more clarification, and in mean will they will change their mind,
this way you will avoid adding trash kind of components to your solution. For e.g. Fields or plugins which
will never be used again.

It is essential and the best-practice process says to create documentation, but sometimes this is basically
impossible when we are doing Agile approach so try to document the maximum at the beginning of the
project, otherwise you will spend lots of time updating the documentation, with all the workflows,
plugins, JavaScript`s, entities and relationships, use the tool on the XrmToolBox to help build generate
this documentation for you, dont think all will be done on the fly.
With each step forward you will improve your methodology and you will gain commensurate benefits in
the speed and accuracy.
In most of the process and workflows we should use BPMN because is VERY important to understand
how process will work and how we build it in CRM. For examples, lets consider server side components
in a typical CRM implementation. Since the creation of the record on entities until all the plugins and
workflows involved to build that process. Bear in mind all the integrations and web services should all
ways been mention on this flows and diagrams. This will help the developer and we can always have the
sign off of the process from the client.
There will be conflicts among people and how they see a requirement. Make sure you help facilitate
agreement, help then to be identified with that requirement and own it and as I said before, make sure
you are dealing with the owner of the process, and this will help you to mitigate failures and mistakes.
The time spent properly planning the project will result in reduced cost and duration and increased
quality over the life of the project and make sure you always have the sign off on every delivers you do
to the customer and relevant stakeholders.
Let me give you an e.g. of a 3th party solution migration to Microsoft CRM.
First The project overview you need to set the business drivers and benefits and when this integration
will take place, and if is really necessary, importing files or building a console application to do this
sometimes could take between 2 days or 2 weeks.
Second What are the objectives of this migration and what the client will gain with this? Are we just
importing contacts or is more than that? Like price list (need to be manually), products or other stuff
that the solution need to do some calculations? This type of migration could take you 2 weeks or more
depending the quantity of records, so do analyze that.
Third Is the scope of this migration just for one department, how many business units and organization
are we talking about, and in terms of security rules? Does the security model in CRM the same of this
3th party solution and how can we replicate that? How do we get the data and do we need to touch on
the 3th party solution? My advice is always don`t touch.
Fourth Sometimes we need to define the assumptions like relationship tables that are different from
the CRM and we need to put same days here to do this analysis and match tables and fields. Have
always in concern events like data need to be calculated or comes from a different source. Of course Im
not saying risk like do the client have the right hardware and infrastructure in place and the storage
capacity. Dont forget that when you are doing a migration you will need at least the double of the space
the solution use. This applies to any Microsoft CRM migration, like 2011 to 2013 and forward.
Fifth Do your approach will unfold and proceed normally usually only your own resources or do you
have dependencies on others, such as who will give the files?

Sixth Since we are talking of a migration we need to make sure we are talking to the sponsor and
stakeholder of this migration, and we need to define and assign on test phase people form the customer
side to test the data under supervision of the stakeholder

Seventh All the initial effort, cost and duration should be flexible enough to be revised, some
migration as I mention before can take 2 days or 2 weeks, depending on the complexity. As soon we got
the stakeholders approved and sign we can consider the work plan done.

CRM Business Analysis - Fit-Gap Analysis

This article is a continuation of something I have wrote before about the Business Analysis best
practices, so here follow some lights how to proceed for the Fit-Gap Analysis.
This will be a high level solution architecture, in terms of objectives engagement we need to validate
and understand the project scope. Validate and understand the degree of Fit of Microsoft Dynamics
CRM to the customer business and IT requirements. We should identify the major customization's that
will be required to address the customer requirements as well any ISV add-on solutions that may be
required. We should understand of how Microsoft Dynamics CRM will work in the customer business,
and all this as more detailed as possible.
Overview and Schedule is the process flow that we should use to do our analysis, which i separated by
phases for better understanding.
Fit/Gap Findings Degree of Fit
Based on workshops and interviews conducted the Fit-Gap Analysis we will determined a percentage
degree of fit for Microsoft Dynamics CRM to the customer business. Separating the effort estimates by
configuration, customization (plugins or integration) and workflows.
Fit-Gap Findings Major Customization Requirements
We should list the identified customization requires during the Fit-Gap analysis by Business requirement
and customization description, CRM design point (discuss how the customization will be handled in
Microsoft Dynamics CRM) and effort estimate in hours or days.
Fit-Gap Findings Requirements for ISV Add-On Solutions
In terms of ISV add-on solutions, we will use the same list as above plus the ISV-Add-On solution
requires (providing information on the ISV add-on solution that is required)
Fit-Gap Findings Requirements for Integration's
For the integration we will mention the business requirements and integration description, the CRM
design point where we will discuss how the customization will be handled in Microsoft Dynamics CRM
and the effort estimate in days or hours
Fit-Gap Findings Requirements for Data Migration

I those projects that we need to migrate data we need to include this requirements, therefore we need
to mention what data need to be migrated, number of rows (what volume of data needs to be
migrated), frequency (one shot or how oven will occur), will be a manual, semi auto, or automated
solution (manual, custom code like console application, BizTalk, user interface, etc.), and the effort
estimate in hours or days.
Fit-Gap & Solution Blueprint Deliverable`s
Our deliverable`s will be the fit-gap spreadsheet in which lists all the requirements, how they will be
addressed (out-of-the-box, configuration and customization) and the effort estimate associated with
each deliverable.
The solution blueprint is a Report (written in Microsoft Word) which covers our understanding of the
requirements, discusses Microsoft Dynamics CRM functional fit, reviews key design points, discusses
customization and integration requirements, reviews the proposed conceptual design and lists any
assumptions made.
Before moving on to the next steps it is important for us to validate this Fit-Gap & Solution Blueprint to
make sure we have a clear understanding of the customer requirements.
In all the fit-gaps findings the customer need to validate if these Business/IT requirements are truly
necessary or if the requirement can be dropped in order to reduce implementation costs.