Getting Feedback

Posted 13-Jan-2004 11:35 AM
From Richard Hoving [Posted by Teri Robinson]
I have been involved in the implementation of a CRM system for our office, which is a small subsidiary of our parent company. We have been using the system for half a year now and I would like to organize a formal evaluation of our current implementation under the employees that work with the system. The reason I want to do this is:

- to get a better understanding of what functionality the current system is missing. I would like to gather some requirements for a next phase

- To send some feedback to the parent company about the current state of the system. Problems the users encounter and the general level of hapiness with the system.

Because I would like to base my evaluation on good analysis I was wondering if there is any information available to assist in these kind of evaluations? Things like questionnaires, overviews of subjects you can ask about, methods to follow during the investigation.

My alternative at the moment would be to organize informal 1-on-1's with some of the key-users of the system and ask them about the things they like, dislike and miss in the current system.

I hope you can point me in the right direction.

best regards,

Richard Hoving

PS: As you must know evaluations like this might encounter some political resistance from key-people in the organization. I am trying to give a thorough eval that will help the company progress. The question is how to stay within those boundaries.

Teri Robinson
Managing Editor

[This message was edited by Bob Thompson on 14-Jan-2004 at 08:01 PM.]

Reply With QuoteEdit or Delete MessageReport This Post
Niko
Member

Posted 26-Jan-2004 12:55 AM
Dear Richard,

Before you get into the business of inteviewing and even questionaires, the first thing you may want to consider is an evaluation of the system and its success against original targets and plans as should have been specified during roll out, in effect measuring a local ROI.

That should give a local picture to H/Q of how they are doing in general with the product at local level in meeting original objectives, and whether ROI has been achieved, or if something needs to be done or adjusted to achieve it.

After this information is at hand, then you could and should go a level below, and identify the operational gripes with the system in terms of pure technical implementation (eg buttons in the wrong place, difficult to work with form layout etc). You should try to this as objectivelly as possible, which may mean part of the info is obtained qualitative through 1-1 interviews and observation, or quantitative through questionaires).

Regards,

Niko

gautam
Member
Picture of gautam

Posted 12-Apr-2004 01:43 AM
Hi Richard,

Your post seems to suggest that you are more inclined towards a software evaluation.

In that case, check out www.CRM4SME.com It has an excel download that will allow you and the core CRM & IT teams to do a soul search on your technical capability.

Of course, user feedback is important for buy-in (besides, we should practice what we preach.) However, the more senior users of the system are often more resistant about it.
It might be better to recruit younger / newer members of the sales, marketing or customer support depts. They are typically more open and also more enthusiastic about getting the "additional responsibility". Even though they tend to be lower in the hierarchy, they are the frontlines who need to use the system the most, and also can give insights into opinions and attitudes of their team-mates and seniors.

To get really meaningful user analysis, try this:

1. Recruit some of the younger, more enthusiastic people from key depts into a "crack team". If possible, get a senior executive to personally do the "recruiting"

2. Vest them with the responsibility of using the system and evaluating it for flaws and irritants; tell them take the system and "Rip it apart."

3. Have regular meetings with them. They could be weekly, fortnightly or monthly, whatever works best.

4. Most important, keep in informal; and keep it "between yourselves", rather than a very visible, public initiative. Else peer pressure might make people shy away from being part of the team.

While "recruiting" them, you can also run them through the system and ask for any immediate comments/feedback. This will give you something to report to your bosses.

But the real feedback will come over a couple of months. A one-off survey is rarely taken seriously; or its used as an opp to blow off some steam.

This setup will get you real insight from the user's perspective. In the long run, it would also help get buy-in from other segments.

I notice that my response comes a little late. I hope you can still use some of these ideas. I would love to know what methods you eventually used and how the operation worked out for you.

All conservatism is based upon the idea that if you leave things alone you leave them as they are. But you do not. If you leave a thing alone you leave it to a torrent of change.—G. K. Chesterton

Graham Hill
Guru
Member

Posted 13-Apr-2004 10:34 PM
Richard

Building upon what other respondents have written...

It might help you in your quest if you keep in the front of your mind the notion that the system is only there to enable a business process to be carried out and managed effectively.

If you don't have a clear view of what process the system is there to enable, then I suggest you quickly develop one using a robust approach such as SADT/IDEF. Without this unambiguous process view, reviewing the technical aspects of a system is somewhat irrelevant.

Assuming that you do have a clear process view, you can then carry out a step-by-step review of how the system's functionality supports individual business and management process.

By mapping systems functions against individual business processes (using something as simple as Excel within a technique such as Quality Function Deployment), you can not only review the business fit of the system, but also identify areas for improvement in the future, whether that be in core functionality, in user look & feel, or in any other area. This will form the foundation of the System Review and of the Requirements Catalogue that such a review would normally create too.

It's not that difficult if you remember that a system is there for one purpose only—to support how your business is carried out. It's not about ROI, its not about usability, its not even about systems. It's about business.

Graham Hill
Independent Management Consultant