Slow xRM: 2012

My main role at my company is to deliver subject-matter expertise on Dynamics CRM (which includes solution design for companies building products on top of CRM) and to manage the delivery of the resulting product by our development team in Kiev, Ukraine. I enjoy both of these roles, but the actual project management piece, which is a part of the “managing delivery” role, I could honestly do without.

So when I saw how our team worked as I started my employment here, I was concerned. As might be expected from an off-shored professional services organization, the approach to work was a bit scattered at first. Projects would come in, the least-busy people were assigned to those projects, we tried to maximize the time each person spent working on billable work, etc. This meant that the team never had time to gel (as there was no consistency in the makeup of the teams from project to project). It also meant that each person was typically working on several projects at once. Projects were difficult to close out, and I don’t think it was a great environment for developers who want a more planned approach to their careers, the competencies they build, and the type of work they do.

So I was really happy when we had 2 projects start that were both multi-month development projects. The larger one has been going for 8.5 months and has 6 developers/testers working on it. Most of that team has been very consistent throughout the project. So at the beginning, I decided that this would be the perfect opportunity to introduce agile to the team. I had several particular goals:

Avoid gantt charts [shudder]. I hate them. And to try to manage an 8-month project that started with a 230-page technical spec with waterfall and a gantt chart and a critical path … I’d die first. The technical spec was written by a 3rd-party architect, so this created a sticky business triangle, but outside of that, we tried to use this architect as our on-site customer.
Overcome the wall I felt between myself and the devs. It seemed like they were afraid to speak their minds to me, to contribute their ideas to our projects, to tell me when they had a better idea than I did … I assumed this was cultural. I know they didn’t agree with me all the time, because previously, from time to time, they had followed my way of doing things until they kind of exploded with frustration at doing it my way when they had a better idea. I wanted a more open dev environment where we could work together as equal contributors, even if I am technically above them in the chain of reporting.
Instill agile skills in the team. This was for their own benefit as much as it was for mine. I consider agile experience a plus for any developer’s resume. This is especially true if he has truly experienced agile (not just adopted a few mechanisms like sprints and scrums).

So … how did it go? The culture gradually changed. I was gratified to see the technical lead on our team start to take over my role as the person who led the planning meetings, started writing the stories, etc. His confidence in this role grew as the project went on. We faced some challenges, such as going way over budget, but as I investigated the causes (and asked the direct question multiple times about whether this was a result of using the unfamiliar agile approach), we honestly determined that the project had just been poorly estimated at the beginning. Estimated at the beginning, you might ask? Yes … we couldn’t do everything the right way according to agile. I’ll discuss this below.

What Went Well

We finally got the art of agile estimation down. We started by looking directly at the spec and trying to group the sections from there into our iterations. This worked marginally well until the sections got too big to do in one iteration. We started re-writing sections from the spec as user stories that the developers could understand more readily and give the gut-feeling estimates we needed to generate our story-points. As the weeks went on, the estimates began to coalesce. At the beginning, there would generally be one cluster of estimates with 2-4 days difference between the highest and the lowest, and then one outlier from the “pessimistic guy” that was usually 5 days higher than everyone else. We averaged the estimates together to get our story points. While we were fairly consistent in the number of story points we accomplished from iteration to iteration, it could have been better. At the end, the estimates were much closer together, usually all within 1 to 1.5 days of each other.
Planning improved. The major challenge with this project was the complexity of the technical spec. Did I say it was 230 pages long? And completely unreadable by normal humans. After starting with 2-week iterations and really struggling to consistently deliver the planned functionality due to problems that arose mid-iteration, we pared the iterations down to 1-week. We had our demo and planning every Tuesday, so the developers really had only 4 development days plus a few hours in an iteration. This dramatically improved our consistency. Keeping the planning cycles short left much less room for us to get bogged down in complexity we didn’t understand when we planned.
Code quality was great. We re-factored constantly, we tested the functionality for each iteration diligently so we could release it at the end of the iteration (even though the customer never took the product out of the demo into production). I honestly think the code quality in this project was the best I’ve seen from our team.
Cooperation was awesome. Since this project had most of our team working on it, I feel like it’s actually transformed our team. Our leader (who was appointed the technical development lead shortly after the project started) has been able to develop a great collaborative atmosphere with the other team members, and that’s not something that would have happened had they all just been working on 3 projects at once like they were before. They spoke to each other, walked to each-others workstations, and generally had a much higher level of interaction than on other projects.

What didn’t go well

There’s only so much you can do in your first attempt to implement agile. The core of agile is the cooperation between business people and developers, and this is where we fell short, unfortunately. So, while I’m hesitant to say we were fully practicing agile with these shortcomings, I think we made great strides, and we’ll learn from these things moving forward.

Collaborative workspace – while our developers have this among themselves, there was simply no way for us to put our “onsite customer” (the 3rd-party architect who wrote the spec) in the same room as the developers in Kiev for more than 3 days at the beginning of the project. At first, he was present via Skype at our daily standup meetings. Then, he was only present at our demos. He was always available for questions, and was very helpful, but it wasn’t the same as having him in the room. When could you ever have the customer in the room all the time for a professional services project, especially an off-shored one? I would say never. Unfortunately, this is a challenge that may not have a perfect solution. The best thing to do is to try to keep the customer as involved as possible, especially at the points where input is needed and decisions are made. Demand his availability, and, if possible, insist that he not require questions to be scheduled.
Full implementation of my favorite concepts- there were some XP concepts that I just couldn’t get the team to try – including test-driven development and pair programming. I’ve spoken to developers who have successfully used these practices and will attest to their effectiveness, but my developers in Kiev were not ready for them. Well, we change gradually, right? Maybe sometime in the near future. But it’s important to have the right financial configuration on a project to introduce radically different development practices, and this probably wasn’t it.
Welcoming change – this is another pillar of agile, and unfortunately, we fell short here. Why? We were working on a fixed-fee project. At first this was good for our adoption of agile, because instead of being accountable for every hour we spent, we could focus more on the result. However, as it became apparent the estimates we had used to price the project were way off, the financial burdens of the project required us (me, mostly) to start really challenging any input our onsite customer gave us that changed the scope of the project. Enter the business triangle I mentioned earlier. We had to document any changes as change requests to the paying customer, who then had to go back to the onsite customer (the third-party architect), who then came back to us, and the politics would commence.

The third item here is especially telling. One of the biggest challenges I see in a professional services team doing agile is the project’s financial arrangement. A fixed-fee project seemed like a good arrangement at first, and it probably would have been somewhat OK had we done a better job up front estimating. But the best arrangement would be for the customer to understand agile and the value it can create in his own go to market strategy. He should understand the advantage of not spending his full development budget before his product ever lands at an end-customer. There is a huge benefit financially and strategically in understanding the core functionality an end-customer needs in order to give your customer money (minimum releasable functionality). If your customer understands this principle, he can pay you to develop 10% of his product’s planned functionality and then have paying end-customers funding all or part of the other 90%. The alternative is paying for all 100% himself, and then realizing that 80% of it is irrelevant, and that he’s missing another 60% of things his end-customers want (I’m making all of these numbers up, but you get the point).

If everything were perfect, I would see a fixed-seat project, where the customer simply pays for x number of full-time developers and testers, and then commits the resources from his own company to work with that dev team daily. There’s no scope, no milestones, and no fixed fee. The customer knows what he’s going to pay for development each week or month, but he doesn’t know what the product is going to look like. Most people will be uncomfortable with this. However, if they’re smart, they’ll gladly accept that uncertainty for the increased agility that will allow them to get early feedback from customers and develop the solution that makes money the fastest.

lundi 15 octobre 2012

HOWTO: Sonoma Partners Universal Search

Sonoma Partners a récemment édité un add-on pour Microsoft Dynamics CRM 2011 permettant de chercher une chaîne de caractères dans les enregistrements de plusieurs entités simultanément.

1. Installer le moteur de recherche

1.1. Télécharger la solution.

Pour installer le moteur de recherche, il faut dans un premier temps télécharger la solution qui contient l’add-on.

Pour cela, aller sur le site de Sonoma Partners en cliquant sur le sur le lien suivant.

Cliquer sur « download and try Universal Search from our website ».

Remplir le formulaire et cliquer sur « Submit Request ».

Un Email avec un lien va être envoyé à l’adresse email indiquée.

Cliquer sur le lien pour télécharger la solution « Sonoma Partners.UniversalSearch-Managed » (fichier zip de 192 ko).

1.2. Importer la solution

Ensuite, il faut importer la solution téléchargée dans le CRM.

Aller dans Paramètres > Solutions et cliquer sur « Importer ».

Importer la solution téléchargée.

Une fois que l’importation a été faite, on peut utiliser le moteur de recherche en cliquant sur le bouton « Universal Search » dans le ruban du menu général.

Dans la colonne « record summary » se trouve l’ensemble des entités sur lesquelles la recherche peut porter. On peut choisir d’effectuer une recherche sur toutes les entités (All) ou sur certaines d’entre elles seulement, en les cochant.

Le moteur de recherche propose par défaut les entités suivantes : Comptes - Contacts - Incidents - Opportunités - Prospects.

Il est toutefois possible de définir les entités disponibles à la recherche en utilisant le configurateur.

2. Configurer le moteur de recherche

Pour configurer le moteur de recherche, aller dans Paramètres > Solutions.

Ouvrir la solution « UniversalSearch ».

Dans la colonne de gauche, intitulée « Available Entities », se trouve la liste des entités disponibles pour la recherche. Dans la colonne de droite se trouvent les entités sélectionnées.

Il est possible de supprimer et d’ajouter des entités pour la recherche à l’aide des deux boutons situés entre les colonnes.

Dans ce cas, je n’ai pas besoin des entités sélectionnées par défaut. Je les supprime donc toutes en faisant une multisélection et en cliquant sur le deuxième bouton.

Inversement, je sélectionne dans la colonne de gauche les entités qui m’intéressent et les rends disponibles à la recherche en cliquant sur le premier bouton.

Une fois que ma sélection est faite, je l’enregistre en cliquant sur « Save ». A tout moment, je pourrai restaurer les entités sélectionnées par défaut en cliquant sur « Restore Defaults ».

Je peux également modifier le nombre de colonnes apparaissant dans le résultat en modifiant la valeur dans le champ « Columns to display ». Par défaut, la valeur est 4, ce qui signifie que les quatre premières colonnes de la vue « Recherche » seront affichées dans le résultat.

Le champ suivant, « Max. records returned », sert à définir le nombre maximum de résultats à afficher par entité.

3. Lancer une recherche

Après avoir configuré le moteur de recherche, je l’ouvre à nouveau.

Les entités disponibles à la recherche sont bien celles que j’ai choisies.

Pour rechercher un enregistrement, je saisis une chaîne de caractères dans le champ de recherche.

Je vais, par exemple, effectuer une recherche sur tous les enregistrements contenant la chaîne « Kery James » en tapant « *kery james ».

Le moteur de recherche m’indique le nombre d’enregistrements trouvés par entités. Dans ce cas, j’obtiens un artiste, 6 disques et plus de 50 titres.

Je peux ouvrir l’enregistrement qui m’intéresse en cliquant sur le lien.

Remarque : les champs disponibles à la recherche sont les champs définis comme critères de recherche. Lorsqu’on modifie les critères de recherche d’une entité, il faut supprimer puis rajouter l’entité en question dans la solution « UniversalSearch » pour que le moteur de recherche prenne en compte cette modification.

It is now possible, in Microsoft Dynamics CRM 2011, to look for a character string in various entities simultaneously thanks to Sonoma Partner’s new add-on.

1. Installing the search engine

1.1. Downloading the solution

To install the search engine in the CRM, you should first download the solution which contains the add-on.

Go on Sonoma Partners’ website by clicking on the following link.

Click on « download and try Universal Search from our website ».

Fill in the form and click on « Submit Request ».

You will receive an Email with a link. Click on the link to download the « Sonoma Partners.UniversalSearch-Managed » solution (zip file, 192 ko).

1.2. Import the solution

Once you have downloaded the solution, you need to import it in the CRM.

Go to Settings > Solutions and click on « Import ».

Import the downloaded solution.

You can now use the search engine by clicking on the « Universal Search » button on the main menu’s ribbon.

In the « record summary » column, you can find the entities available for search. You can either search in all entities or only in the checked entities.

The following entities are available by default : Accounts - Contacts - Cases - Opportunities - Leads.

You can nevertheless choose which entities are available by configuring the search engine.

2. Configuring the search engine

Go to Settings > Solutions.

Open the « UniversalSearch » solution.

You can see two columns, one with the available entities, one with the selected entities.

You can add and withdraw selected entities with the two button between the columns.

Note: the search engine can only be configured in the CRM’s native language. This is why the entities appear in French on this example.

In this case, I don’t need the default entities. To withdraw these entities, I select them and click on the second button.

Then I choose the entities I need in the « Available Entities column » and add them by clicking on the first button.

Once I have chosen my entities, I can click on « Save ». I always have the possibility to restore the default entities by clicking on “Restore Defaults”.

I can also change the number of columns displayed in the result by modifying the value of the “Columns to display” field. The default value is 4, which means the first four columns of the “Research” view will be displayed.

In the same way, I can change the maximum number of records returned by entity in the following field “Max. records returned”.

3. Launching a search

After configurating the search engine, open it.

The available entities are the entities I chose while configuring the search engine.

To look for a record, I enter a character string in the search field.

For instance, I click “kery james” to look for all the records with the “Kery James” string.

The search engine tells me how many records were found in each entity. In this case, I found one artist, 6 discs and more than 50 tracks.

I can open the record I want by clicking on the link.

Note: the available fields for search in the search engine are the fields you made available for search in the CRM. Each time you change the available fields for search in an entity, you need to withdraw this entity and add it again in the “UniversalSearch” solution to make the fields available for search in the search engine.

jeudi 11 octobre 2012

13 CRM Best Practices for 2013

13 CRM Best Practices for 2013 by Paul Pitman at Collier Pickard (11/10/12)

With less than 12 weeks to Christmas, now might be a good time to start planning for 2013. Too early? With these 13 CRM best practices there is no time like the present. Whilst individually each of these will help get your CRM system ready for the New Year, the more you can do, the better the results.

The pundits are in agreement - 2013 will continue the austerity we have seen in 2012. Making sure that your CRM system is delivering in the essential tasks of Acquiring, Retaining and Developing customers need not cost the earth. With careful planning, getting the best out of your system is a team effort that will cement CRM as “the way we do things”.

1. Perfect data is a myth.

Or perfect data is an expensive illusion. Either way, focus on the 20% of your data that yields 80% of your revenue. Don’t ignore the rest – but don’t throw money at trying to achieve perfection in every piece of data.

2. If it is important enough to record, it’s important enough to back-up.

You probably haven’t thought about your back-ups for a while. Sure those nice people in IT are backing everything up – but how long would it take to restore? How up to date is the last backup? A quick email may just save you a time and money in the event of a server crash.

3. Don't assume that it's safe in the cloud.

Feeling smug because your data is in the cloud? So, there should be no problem with checking how easy it is to get a backup, just in case you need to move systems in 2013. Some of the leaders in cloud-based CRM are going to disappear in 2013 – you don’t want to be caught out.

4. Set your users free.

The CRM market has been screaming mobile for the last 5 years. 2013 is the year it becomes reality. Windows RT devices will be appearing near you soon. Does your current CRM platform deliver?

5. Manage your access points.

With more connected users comes the need to manage more access points. Bring your own device (BYOD) and home working necessitates a review of your security settings. How easy would it be for someone to steal your data?

6. Share the burden of data cleaning.

Not just internally by getting everyone to keep their slice of the data up to date. 2013 is the year that social and other data cleaning services will enter the mainstream. Often thought of as only relevant to larger organisations, plunging prices and easy availability will help to automate data cleaning for everyone.

7. Invite your customers in – and ask them to help with the clean-up.

Sounds bizarre? Customer portals are set to take off in 2013. Make sure that there is a compelling reason for your customers to come to your site and update their details and preferences. No compelling reason? What about linking access to content in LinkedIn, Facebook, or other social media? These are all great sources of extra data.

8. Review how you're using your CRM system.

Your relationships are multi-faceted – use the right part of your CRM system to reduce the effort in recording and storing data. Try implementing those bits of the software you never bothered with. No need for Customer Services? Try thinking of it as post-sale customer care. Don’t track opportunities? Think of it as a way of developing a playbook filled with tips that work!

9. Direct mail is making a comeback.

Perhaps in the recent past it was sufficient to just hold email and phone contact details – but as direct mail proves its value, get ready to hold postal address data. Now would be a great time to look at integrating access to the Post Office Address File (PAF).

10. Delete Data!

Yes, you read that right. In your CRM system there is data that needs to be deleted. The Data Protection Act (DPA) sets out guidelines on data retention. Use these to develop a data strategy and implement it. Do it quickly before your data embarrasses you.

11. Save money.

When was the last time you audited the usage of your system? If 20% of the users do 80% of the work, do you really need all of those licences? Do you really need people who can’t or don’t use CRM? If that sounds harsh, just think about the long term value of a customer you don’t know. Impossible to calculate.

12. Spend money.

The flip side to point 11 is to spend money. Invest now for the future in things that can deliver a return. Invest in people, education and tools to make CRM work for your business. Invest in expertise to accelerate those returns.

13. Back your instincts with solid proof.

As a Sales or Marketing professional, believe in superstition. Nothing about the number 13 – or the effect of black cats. If your gut instinct tells you something then go straight to your CRM system for the hard proof.

There they are - 13 things that you can do in 2013 to make your CRM system even better. Of course, you could always get ahead of the crowd and start now!

Did I miss anything? What are your plans for 2013?

lundi 17 septembre 2012

How to get users using CRM

How to get users using CRM by Chris Pennington at Professional Advantage

A customer relationship management is an invaluable tool for many businesses. Yet, licensing the software such as MS-Dynamics or SFDC is only half the issue. CRM systems are useful when they contain relevant data. Note the operative word “relevant”.

Here comes the tricky part. Ensuring relevant data is stored in the CRM system requires two essential ingredients; both of which rely upon the most variable component – the human element.

Whilst it may sound obvious the two essential ingredients are:

a. The end-users must use the system.

That means recording and putting data into CRM. How often do we hear of proposals stored on someone’s laptop; Email correspondence with clients left in someone’s inbox; Meetings and phone calls noted in someone’s diary but never recorded against a client in CRM.

b. End-users need to be consistent in their use of CRM.

This is a case of garbage-in-garbage-out. Different users will approach the system in different ways and hence record information differently and to varying degrees of granularity or quality.

It is often the “obvious” that thwarts us. It’s so obvious that we fail to address it. Yet, ignoring these obvious ingredients often happens, because the remedy is not easy to apply. It is easier to ignore it and put up with the consequences. Then we hear the lamented catch-cries, “Why can’t I get 100% adoption of my CRM”, “…I can’t rely on the information – so I won’t bother”, or “you’ll never get sales reps to use the CRM system, it’s not in their DNA”

Here are some ways to help overcome the barriers,

1. During implementation:

Remove superfluous fields on the screen

Make use of mandatory fields

Make field labels and data entry points intuitive

Think ahead about what information you need to keep that is relevant

2. Have visible and vocal executive sponsorship

A senior executive that continues to beat the drum about updating CRM will raise its importance in others

3. Training and re-training

Training existing staff on how you want them to use CRM (note this is different from training them on what CRM can do)

Re-training. Users will develop their own habits and will over time deviate from the procedures that company wants to enforce

New-staff training. In the first few days a new employee is often bombarded with information. If they are lucky enough to get any system training, the likelihood is they will forget it very quickly. On-boarding training needs to be planned and delivered properly

Keeping training to bite-sized sessions, it doesn’t need to be full-blown classroom training.

4. Setting time aside in the calendar (records won’t update themselves)

Allocate a specific time for end-users to update their records. If the company knows that between 4pm-5pm every Thursday the sales team will be unreachable because they are updating their records it will build a culture of meaningful information.

5. Exception reporting

Look for exceptions and anomalies and then bring them to the individual’s attention to remedy. (Note this rarely happens on a regular basis, since it is seen as nagging. Setting the scene in advance from the Executive Sponsor can help position why this is important).

mercredi 15 août 2012

Want to Future-Proof Your CRM? Get Flexible

Want to Future-Proof Your CRM? Get Flexible by Christopher J. Bucholtz (17/11/11)

When the so-called experts dispense advice about CRM implementations, whether they're first-timers or replacements of old systems, they always include a caveat about the future. You need to solve today's problems with the new system, but you also need a way to "future-proof" your investment so that the next set of problems to present themselves don't force you back into the CRM selection process.

The key, as I've heard it from one undoubtedly Canadian consultant, is to do as Wayne Gretzky suggested: Don't skate to the puck, skate to where the puck is going to be. OK, but how to I get to the metaphorical location of that metaphorical puck if I don't know where it's metaphorically going yet?

The secret goes beyond the CRM technology you may have on-hand. It applies to the technology too, but it's really an attribute that must be present across your entire customer-facing organization. That attribute is flexibility.

CRM's about people, processes and technology. All three must be flexible in order to keep your CRM efforts relevant and maximize your ROI.

Limber Up, People

Let's start with people. The people you hire and the people you promote need to be flexible in how they think and how the input they receive modifies their approach to customers. Rigidity is a concept that favors business-centric approaches; customers evolve, and so the flexibility to evolve the way you relate to them is in itself a customer-centric trait.

This ability to be creative in the context of the way one works is important in front-line workers, but it's even more important in managers. Front-line people see the evolving customer on a daily basis, but managers can be removed from this reality and thus need to work at being flexible in the way they manage to let front-line workers' insights guide strategy.

Changes to Process

Next comes process. Unbending, rigorously adhered-to processes were great when Henry Ford was rolling Model T's down the assembly line. But customer relationships can't be mass-produced -- they can be replicated to a degree, but each customer is slightly unique. To meet the needs of each of these relationships will require the ability to spot where your processes need to bend or even change to accommodate the needs and desires of customers.

Not changing a process that clearly fits with the new tendencies of the customer because it works best for the business is no longer an option. It's not about your business -- it's about the customers, and they know it.

Application and Vendor

Finally, there's the technology -- and when I say "technology," I really mean the application and the vendor. Both need that attribute of flexibility.

The CRM system ought to be configurable, customizable and personalize-able easily. If the user can't make changes, they should be easy for others with more technical acumen, and those changes should be inexpensive and quickly made thanks to the way the application is built. This is the key to taking the things your people discover about customers and converting them into new processes that introduce the right data into your CRM system.

Your application vendor should reflect this. If it insists that you make your processes conform to the way it works, you're dealing with a vendor that fails to understand the value of flexibility. And beware any vendor that wants to charge you a premium for providing flexibility; in this era, that's like a car dealer trying to charge you extra for wheels.

When selecting a CRM solution, you must look for solutions to today's problems, and you need to consider features that can address problems you anticipate -- but flexibility in all three key components of CRM is the only way you can prepare to handle the issues you don't anticipate.

samedi 14 juillet 2012

CRM Project Evaluation

CRM Project Evaluation by John Eccles from Magnestism (20/10/11)

After about 4 weeks of operation there should be a formal evaluation of the system to assess user-acceptance of the system and overall user-friendliness of the system. The evaluation will highlight any misalignments, software bugs, ideas/needs for software enhancements and any further training required. In addition, the overall project should be evaluated.

Why 4 weeks? Of course this is flexible. But time is needed for users to become familiar with the system and be in a position to comment constructively. And to long a delay may allow issues to “fester” and make it more difficult to recall details of the project.

How to conduct the Evaluation

At Magnetism, we send an evaluation to our Clients after 4 weeks via email. The first page of the evaluation explains the purpose and process:

Purpose:

To evaluate the system delivered in order to learn how to improve it.
To evaluate the service provided by the Supplier to provide constructive feedback.
To evaluate the change process in order to learn how future changes can be managed better.

Process:

We recommend that the process should be managed by either the Project Manager or the Project Sponsor.

1. The evaluation forms should be completed by all staff involved within 5 working days.
2. The completed forms should be collated by the designated manager and forwarded to the Magnetism Project Manager.
3. Magnetism will prepare a summary of the responses together with details/recommendations regarding the following:

a. Outstanding software bugs that will be addressed
b. Other outstanding issues
c. Further training
d. Software enhancements and extensions

What should be evaluated?

The users and their managers should evaluate the system and the training provided:

1. How well the system does what it does?

a. User-interface
b. Ease of use
c. Reliability
d. Ease of training new users
e. Usefulness of user-documentation
f. Pleasing aspects
g. Annoying aspects
h. Confusing aspects
i. Ideas for improvement

2. What else could/should the system do?

a. More reporting
b. Charts & dashboards
c. Automation – workflows
d. Reminders
e. Integration with other systems
f. Use in other parts of business

3. How helpful was the Training?

a. The course
b. The trainer

The Project Team should evaluate the Project and the Supplier:

4. Objectives

a. Re-state objectives
b. Were objectives met?
c. Are there new objectives for the system?

5. Deviations from plan and their impact

a. Re-state project plan
b. List deviations
c. Evaluate impact

6.Change Management

a. Preparation for change
b. Training of users & managers
c. User perception and acceptance
d. Resolution of issues

7. Supplier

a. Communications
b. Understanding of Client needs
c. Responsiveness
d. Professionalism
e. System deployment
f. Training (Also Users)
g. Post-go-live support

vendredi 15 juin 2012

CRM Analysis

CRM Analysis by Luneos (29/06/10)

If you want to invest a couple thousand dollars into a CRM solution, it really pays off to perform initial requirement analysis. This analysis provides help when you are selecting the right CRM vendor and later also during system deployment and testing. If the analysis is done carefully, it helps to distinguish between really important features and nice to have’s, as well as to decide, in which order should be these features implemented.

According to our experience, the best approach is at first to divide CRM analysis into several parts (e.g. contacts, calendar and tasks, document management,..), then assign a percentage weight to each part and begin to ask specific questions. Answers can be then rated on scale from one to ten and the system with the highest weighted total sum is then the best CRM for your company.

Before signing the contract, put together an implementation plan that includes both features specification (from analysis) and their deployment date. If it is possible, attach this document to the official contract, because such step can help you to avoid potential unpleasant discussions about implementation scope and time.

Licences or hosting?

There doesn’t exist any universal answer for the question if it is better to purchase licenses, or rather decide for a hosted SaaS solution. This decision always depends on company size, its attitude to IT, trained staff availability and other internal and external factors. The hosted solution with fixed monthly price has an advantage that your company doesn’t need any initial bigger investment to purchase licenses or hardware and this fact has a positive impact on your cashflow.

Tailor made industry solutions

We also recommend to make a brief survey among your competitors and business partners to find out which systems do they use and how are they satisfied with their performance. Performing such survey helps you to quickly eliminate inadequate solutions and focus only on those CRMs that can bring your company real benefits.

Before choosing CRM system and its supplier also try to find out if some vendor doesn’t already have experiences in your industry and if there isn’t any tailor made industry solution. The main advantage of these preset systems is not only faster deployment and configuration, but also better IT support for your processes.

lundi 11 juin 2012

Dynamics CRM 2011 - The Agile Approach

Dynamics CRM 2011 - The Agile Approach by Jaime Smith at Magnestism (10/06/12)

There is plenty of information all over the net about AGILE, its origins, methodology, tool etc, so as I have said previously I am looking at it from within CRM and SureStep practice. Within SureStep it is somewhat of a hybrid and definitely veers away from a strict Agile approach.

What it maintains from Agile

1. Solution Backlog

A list of the requirements that have been defined during the analysis phase. The compilation of this backlog signifies the end of the Agile Preparation Phase.

2. Sprint formation

Within the Agile Execution Phase, sprints will be defined with durations of between 5 days and 30 days. A sprint cycle should never longer than a month.

3. Sprint Backlog

This defines the development activities for each sprint cycle (pulled from the Solution Backlog) – these are reviewed on a daily basis (We hold SCRUM every morning) and tasks are shared out amongst the project team.

It is essential to note that included within each sprint and on the sprint backlog are all project tasks/phases including, analysis, planning, design, development and testing. This differs from the waterfall approaches where each phase is completed before the commencement of the next one.

After the sprint is finished there is collaboration between the customer and the supplier – the development is reviewed and anything that is rejected or requires additional work is added to the Solution Backlog to be scheduled as part of a later sprint.

Where it deviates from Agile

Agile SureStep approach adopts the two final phases from its waterfall siblings – Deployment and Operation. It is here that User Acceptance testing occurs.

Best fit for this project type

- Anyone who wants to use CRM as a platform and requires integration to other third party solutions

- If you are not entirely sure of your needs this provides greater flexibility throughout the project lifecycle. Warning: This approach can be more costly as it is hard to define at the outset what the project costs are going to be, however it can result in much greater accuracy within your end product.

- Requires relative fit to the OOTB CRM (50 %– 75%)

- Those who have data to migrate from existing systems

- Single site implementation

- Can incorporate organisation change management activities if required

This approach can be highly disciplined and assist in keeping your project within scope and creates a great sense of manageability but it does come with the recommendation that those in significant project roles have significant experience with IT implementations (both the customer and the supplier) and that super users form part of the project team.

Pages

lundi 5 novembre 2012

jeudi 25 octobre 2012

mardi 23 octobre 2012

jeudi 18 octobre 2012