Creating a Strategic Plan

A few weeks ago my boss asked me to put together a twelve-month plan for the CRM team. He wanted me to identify things like:

• Areas where the CRM team are weak and strong
• Ways to align the CRM team to the values of the business
• Opportunities in the market to pursue

If you are given this task and never done a strategic plan before it can seem gargantuan but with a few tools, you can put together a plan like an MBA graduate without too much stress.

The Mantra of the Strategy Plan

Any kind of strategic roadmap-type plan seeks to address three questions:

• Where are we now?
• Where do we want to be?
• How do we get there?

I generally add these headings in the document and tackle them one at a time.

Where Are We Now?

I break this up into the external analysis (what is happening outside of the organisation) and the internal analysis (what is happening within the organisation). In the case of being a reseller, I also consider the external and internal analysis of the product i.e. for Dynamics CRM, what external factors are affecting the product and what factors within Microsoft are driving the product.

For the external analysis there is the very useful PESTEL analysis (or one of its variants). PESTEL stands for:

• Political: Government policy affecting operations/product
• Economic: Economic factors affecting operations/product
• Social: Cultural aspects affecting operations/product
• Technological: Technology changes affecting operations/product
• Environmental: Climate and weather factors affecting operations/product
• Legal: Laws affecting operations/product

I generally brainstorm anything that comes to mind that may have a bearing on business in the next five years. For example, whether businesses are moving to the cloud or not is a technological factor that could affect operations.

Once you have the PESTEL analysis laid out, you may also want to consider aspects such as the strengths and weaknesses of your competitors or, in the case of a product, the strengths and weaknesses of competitive products.

When all the external factors are documented, it is time to consider the internal factors which affect operations. For example, it may be the strengths and weaknesses of the CRM team or the values of the business which the CRM team are expected to follow. Perhaps it is the industries the CRM team have worked in and how a strong vertical presence may be an advantage in winning new work.

Where Do We Want To Be?

If your bosses are communicating a clear vision of where they expect the business to be and when, this is where this feeds in. If not, you can derive some potential directions using a SWOT analysis.

SWOT stands for:

• Strengths
• Weaknesses
• Opportunities
• Threats

Again, these are broadly considered internal (strengths and weaknesses) and external (opportunities and threats). We now feed the PESTEL factors into this and, to find a path for the future, we try to match up strengths and opportunities and weaknesses and threats. Directions will present themselves as ways to exploit opportunities using our strengths or mitigating threats by reducing weaknesses.

For example, let us say from our external analysis we know that none of our competitors have a Business Intelligence (BI) practice and from our internal analysis we know we do. Our strength in BI now presents a market opportunity if, for example, the market is interested in BI tools for their CRM system. We are uniquely positioned to serve this need.

For those factors which do not provide an insight into a potential direction, we can remove these from the document.

In my case I derived about half a dozen Strength-Opportunity pairs and half a dozen Weakness-Threat pairs. Using the direction provided by my boss I filtered these down to directions aligned to the larger goals of the business.

How Do We Get There?

The final step is putting together some meaningful actions to head in the right direction. I generally set for each ‘direction’ a 0-12 month action (broken into four quarters), a 1-5 year ‘action’ and a 5 year plus ‘action’. Obviously each action feeds into the action for the next timeframe. So, in the case of the BI opportunity, out first four quarters might be:

• Quarter 1: Liaise with the BI team to see if they are keen for a joint venture
• Quarter 2: Put together a cross-function team to develop a trial offering
• Quarter 3: Offer the trial to existing clients as a free product on condition of regular feedback and thoughts
• Quarter 4: Incorporate initial feedback into the offering and liaise with marketing to promote it

This then feeds into our 1-5 year action which might be “having a market-ready BI offering for Dynamics CRM”.

Our 5 year action may be “be the market leader in BI for CRM”.

Conclusions

Obviously not my usual blog topic but if you need to put something together to give you a bit of direction on where to head either at work or maybe even for yourself, this might give you a few ideas on how to approach it. My advice is start with the PESTEL and you will soon find the rest falls into place. Good luck.

A Couple of Form Security Tricks

Forms have come a long way in CRM 2011 and here are a couple of tricks I use a fair amount.

Hiding Locked Fields

Some forms have fields which simply cannot be taken off the form. A good example is the Account Name field on the Account entity.

While we can stop the field from being compulsory, by going to the field settings, we cannot remove the padlock indicating it is locked to the form (and any other forms we create from this one).

The solution is we hide the field in a hidden section. If we create a new section on the form, we can set its properties to be not Visible by default:

All we then do is drag our locked field to this hidden section and we no longer see it on the form.

Please note: If you put a compulsory field in a hidden section and try to save the record it will automatically expose the hidden section so you must make the field not compulsory for this to work (or autopopulate it via jscript OnSave). Also, as in my example, if you are hiding the default name attribute, populate it by using either a jscript or workflow because, otherwise, any child record will show a blank lookup reference, which can be confusing for users.

Dodging Compulsory Fields

Let us say you have a two-step process for handling cases. The call center team receive the emails, quickly reply to the simple queries and convert the trickier ones to Cases for the resolution team. The resolution team then get into the details of the Case and resolve it. It is conceivable that the call center team will not need to know as much detail as the resolution team and, being a team which is dealing with high volumes of queries, simply do not have the time to get bogged down into finding out the important information. It makes more sense for the resolution team to find this information out as part of their investigation.

In version 4, this meant we had a problem. If there are key fields on a Case form needed for things like business reporting, assuming they are compulsory, they must be filled out when the Case is created. Even today, many consultants will tell you to get around the problem we either relax the compulsory nature of the fields or write some tricky jscript to check the role of the user and tweak the fields dynamically.

With 2011 there is a little known alternative approach using forms. As you may know we can create multiple forms for a given entity and assign them to different security roles. We can even create roles with no actual security rights but use them as a way of giving forms to users.

In our case, let us create two forms: one for the call center users and one for the resolution team. We will take the detailed form with all our compulsory fields on it and ‘Save As’ to act as a template for our call center version. The problem comes when we try to remove the compulsory fields; the computer says ‘no’.

To get around this, we do a bit of a supported hack/workaround. We go to the field in question, make it non-compulsory, come back to the form, remove it and then make the field compulsory again (you will probably need to publish the changes between these steps as well).

The net result is we have a form with a bunch of compulsory fields missing from it. What is great is the form does not complain when the call center staff use it and hit the save button; it seems saving only checks the fields on the form in visible and hidden sections but not the fields off the form. This means the call center can create the seedling of a Case, assign it to the resolution team and, because the resolution team only have access to their detailed version of the form, they are forced to fill in the rest of the compulsory fields. No code needed and no compromise to what the business needs to capture.

Conclusions

If you are looking at form design and working with forms for entities like Cases or Products, you may have come across the kinds of problems mentioned above. With any luck these tips might save you some angst and code writing, enjoy

CRM: Culinary Recipe Management and Socialisation

In the spirit of my CRM Adventure Game and CRM Hangman I now present using CRM as a recipe database. This is a pre-cursor to my ultimate dream of creating a CRM cocktail database.

There is not much of a lesson here (although I do propose a very practical business use for this a little later on) other than it is something I wanted to do to show the flexibility of the platform (and because I am now doing the cooking in the house and wanted a way to ask “If I have ingredient ‘x’, what can I cook”). As usual, everything I have done here I have done without code and all up has only taken a few hours at the keyboard while watching TV.

The Structure

Pretty simple stuff, although I will likely extend it as time goes on.

Essentially, we have a recipe with ingredients. These ingredients are basically a food item with a measure e.g. 1 teaspoon of vanilla essence. A recipe also has equipment used to make it.

The Screens: Recipe

Not much to report here. I added the grids to the form to make data entry easier and at the bottom I added a multi-line text box to store the instructions.

The Screens: Ingredients

The complication here is I did not need the default text attribute. To get around this I added a new section, made it hidden by default, made the default field non-compulsory and set up a workflow to populate it when the record is created or when the Measure or Food Item fields change.

“To Serve” marks if the ingredient is a garnish or not a key component of the recipe.

The Screens: Food Items and Equipment

Again, simple stuff.

Reporting

One thing, which is always a hassle when putting together recipes is the shopping. Thanks to the Reporting Wizard, I can now select the recipes I am cooking for the week and generate a list of ingredients to check against the pantry and work out what I need.

I added in the Serves column because different recipes serve different numbers of people. I could have scaled the recipes to a common unit or split out the numerical component of the Measure field and done something clever by feeding it the number of people I am cooking for and scaling the values with code but this requires effort so I have left it as an exercise for the keen. For now, to use as a list to check what I need, it does the job.

Using Mobile Express, I can also access all of my recipes on my IFD-enabled or Online version of CRM anywhere. Very useful for clarifying whether a recipe needed dried or fresh herbs, for example.

Other Ideas

Other things I have thought of but not implemented are:

• Adding Calorie information to the Food Items (and then bringing this down to the Ingredients and rolling it up to the Recipe to get the total Calories in the meal)
• Linking Food Items to each other to record substitutes (or possibly using Connections)
• Adding matching wines to the recipes
• Incorporating Food Pairing to create completely new recipes

Using CRM For Socialisation

While this and the two games I previously put together are a bit of fun, there is a way you could use this for business in fostering a collaborative culture. The recipe configurations could easily be incorporated into a production CRM system. Why would you do this? To bring people together. A recipe database is something people can contribute to for the fun of it and give them an opportunity to discuss cooking tips in the office.

The rule could be all new starters must add a recipe to CRM. This gives them an opportunity to learn the system as well as letting others in the team know a little bit about them. Maybe it could form the basis of an office cook-off.

Alternatively, perhaps your team are keen gamers or movie buffs. If so, why not add a review section to the CRM system. Maybe you want to add a swap-meet section so people can sell old items through the corporate CRM system and deliver them through internal mail in the name of bringing people together.

Conclusions

The Dynamics CRM platform is very flexible and allows us to store organised information for practically any purpose with little, if any, coding. While a recipe database may not the obvious choice for an enterprise CRM system, it is easy to implement and provides a reason for people to come together through something other than the daily grind. However, if recipes are not your thing, try something else. The only limit is your imagination and the courage to do something different for the greater good.