Comments for Alpha Comp http://www.canidiumblog.com EIM and SPM system and related commentary presented by Canidium Thu, 11 Mar 2010 02:45:13 +0000 http://wordpress.org/?v=2.6.1 Comment on Recession Coming to a Close by admin http://www.canidiumblog.com/2009/05/recession-coming-to-a-close/#comment-57 admin Mon, 08 Jun 2009 18:00:14 +0000 http://www.canidiumblog.com/?p=544#comment-57 Fed Chair Bernanke's comments last night on 60 Minutes seem to support this survey: http://cbs5.com/business/bernanke.recession.economy.2.960050.html Fed Chair Bernanke’s comments last night on 60 Minutes seem to support this survey:
http://cbs5.com/business/bernanke.recession.economy.2.960050.html

]]> Comment on #5: You put lipstick on a pig by JasonKearns http://www.canidiumblog.com/2009/04/top_5_spm_reqs_mistakes_number_5/#comment-49 JasonKearns Thu, 16 Apr 2009 16:18:49 +0000 http://www.canidiumblog.com/?p=492#comment-49 That's a great point. You definitely need to get a good understanding of how things work today before you can offer improvements. Out of that, there will certainly be elements of the old design that work very well and should be duplicated. That's a huge time saver and an easy win. There will also be elements that can be eliminated and/or ignored because they're not critical. That’s a great point. You definitely need to get a good understanding of how things work today before you can offer improvements. Out of that, there will certainly be elements of the old design that work very well and should be duplicated. That’s a huge time saver and an easy win. There will also be elements that can be eliminated and/or ignored because they’re not critical.

]]> Comment on #5: You put lipstick on a pig by MichaelStus http://www.canidiumblog.com/2009/04/top_5_spm_reqs_mistakes_number_5/#comment-48 MichaelStus Thu, 16 Apr 2009 04:20:11 +0000 http://www.canidiumblog.com/?p=492#comment-48 I'd like to suggest a corollary: if you can spend too little time reworking business processes, you can certainly spend too much time doing so as well. I've seen projects bog down because an attempt is made to address every last issue with the current process as part of the initial delivery. Do what you can, but be mindful of your budget and timeline. I’d like to suggest a corollary: if you can spend too little time reworking business processes, you can certainly spend too much time doing so as well. I’ve seen projects bog down because an attempt is made to address every last issue with the current process as part of the initial delivery. Do what you can, but be mindful of your budget and timeline.

]]> Comment on #1: You took the buffalo for a walk by JasonKearns http://www.canidiumblog.com/2009/03/top_5_spm_reqs_mistakes_number_1/#comment-28 JasonKearns Mon, 30 Mar 2009 14:13:42 +0000 http://www.canidiumblog.com/?p=382#comment-28 That's a good point David. One of our "top 5" mistakes is similar to that. In fact, we may borrow some of your thoughts for that posting. Its amazing how many "common" mistakes you can come up with when you really start thinking about it. That’s a good point David. One of our “top 5″ mistakes is similar to that. In fact, we may borrow some of your thoughts for that posting. Its amazing how many “common” mistakes you can come up with when you really start thinking about it.

]]> Comment on #1: You took the buffalo for a walk by david.carlson http://www.canidiumblog.com/2009/03/top_5_spm_reqs_mistakes_number_1/#comment-24 david.carlson Thu, 26 Mar 2009 01:53:54 +0000 http://www.canidiumblog.com/?p=382#comment-24 The most common mistake I see in requirements is letting the customer create a requirement that is really a design. Often, the only way customers can think of requirements is to describe them as the design of how the system works today. Rather than saying “we need to give credit to salespeople who worked on the deal”, they say “we require the system to have a code that equates to these 5 people that report to this manager so they can get credit”. The most common mistake I see in requirements is letting the customer create a requirement that is really a design. Often, the only way customers can think of requirements is to describe them as the design of how the system works today. Rather than saying “we need to give credit to salespeople who worked on the deal”, they say “we require the system to have a code that equates to these 5 people that report to this manager so they can get credit”.

]]> Comment on Compensating for the Recession by MichaelStus http://www.canidiumblog.com/2009/01/compensating-for-the-recession/#comment-17 MichaelStus Fri, 20 Feb 2009 18:10:24 +0000 http://www.canidiumblog.com/?p=259#comment-17 An article similar to ours is here: http://salesresourcegroup.ca/blog/?p=9 . An article similar to ours is here: http://salesresourcegroup.ca/blog/?p=9 .

]]> Comment on What’s in a name? by Julien http://www.canidiumblog.com/2009/02/whats-in-a-name/#comment-16 Julien Wed, 18 Feb 2009 19:29:58 +0000 http://www.canidiumblog.com/?p=271#comment-16 Hi Jason, I like the names you are proposing... It seems like many companies I work with have non-flattering ways of calling their comp system. But I can't agree with you that we should name the systems "properly". I think that the best way to call a system, is by the name of the vendor... Call it TrueComp, call it Callidus. That's what it is. Most companies have multiple comp/incentive systems and if you name it by a clever acronym, it leads to confusion. Sure, people might unfairly criticize the comp system when its not at fault... but who cares. If people blame the decision maker for choosing the same solution again when it needs to be replaced, the blame will happen whether the system was called Callidus or COINS. And if the system is implemented properly, there is a good chance that people - especially front line reps who only have exposure to dashboards and reports - will like the system. Julien Dionne http://leapcomp.com Hi Jason,

I like the names you are proposing… It seems like many companies I work with have non-flattering ways of calling their comp system.

But I can’t agree with you that we should name the systems “properly”. I think that the best way to call a system, is by the name of the vendor… Call it TrueComp, call it Callidus. That’s what it is. Most companies have multiple comp/incentive systems and if you name it by a clever acronym, it leads to confusion.

Sure, people might unfairly criticize the comp system when its not at fault… but who cares. If people blame the decision maker for choosing the same solution again when it needs to be replaced, the blame will happen whether the system was called Callidus or COINS. And if the system is implemented properly, there is a good chance that people - especially front line reps who only have exposure to dashboards and reports - will like the system.

Julien Dionne
http://leapcomp.com

]]> Comment on Reputation as an incentive by Julien http://www.canidiumblog.com/2009/01/reputation-as-an-incentive/#comment-13 Julien Wed, 21 Jan 2009 01:16:45 +0000 http://www.canidiumblog.com/?p=225#comment-13 As an additional point of interest for your readers, I wrote a related post on LeapComp about social versus monetary reward here: http://leapcomp.com/2008/05/for-love-or-money-social-vs-monetary-reward.html Julien dionne http://leapcomp.com As an additional point of interest for your readers, I wrote a related post on LeapComp about social versus monetary reward here:
http://leapcomp.com/2008/05/for-love-or-money-social-vs-monetary-reward.html

Julien dionne
http://leapcomp.com

]]> Comment on Reputation as an incentive by Julien http://www.canidiumblog.com/2009/01/reputation-as-an-incentive/#comment-12 Julien Wed, 21 Jan 2009 01:11:46 +0000 http://www.canidiumblog.com/?p=225#comment-12 Michael, Stackoverflow is a neat website, but I'm not a big fan of this kind of website in general. The main reason is that, there are so many ways to do something - especially in IT - that it's often better just to figure it out than try to interpret the answer of multiple different people, who may not have understood the question correctly in the first place. For example, I would have solved your challenge with a quick 3 line Perl script and a neat regular expression. But if you don't have Perl and don't know anything about regular expressions, there are dozens of other way to do it. The other reason is that if the question is very difficult or specific (like a Callidus question), it's probably easier/quicker to turn to your own network to get a prompt answer. But to your point, a reputation system is hardly a new concept, and it seems to work magic in most collaborative environments including discussion boards, Slashdot powered sites, wikis, etc. But then you always have those (like me) who don't care much about a "Reputation" on a new collaboration site. I have seen many companies trying to build a reputation system as part of their portals, content management systems, and even internal help desks... But in my opinion, they all failed. Many people participated... and many were spending much more time "building their reputation" than doing their actual work. Maybe the most important take-way from your post is that employees should be commended for doing a good job, and that recognition is a real motivator. Michael,

Stackoverflow is a neat website, but I’m not a big fan of this kind of website in general. The main reason is that, there are so many ways to do something - especially in IT - that it’s often better just to figure it out than try to interpret the answer of multiple different people, who may not have understood the question correctly in the first place. For example, I would have solved your challenge with a quick 3 line Perl script and a neat regular expression. But if you don’t have Perl and don’t know anything about regular expressions, there are dozens of other way to do it. The other reason is that if the question is very difficult or specific (like a Callidus question), it’s probably easier/quicker to turn to your own network to get a prompt answer.

But to your point, a reputation system is hardly a new concept, and it seems to work magic in most collaborative environments including discussion boards, Slashdot powered sites, wikis, etc. But then you always have those (like me) who don’t care much about a “Reputation” on a new collaboration site.

I have seen many companies trying to build a reputation system as part of their portals, content management systems, and even internal help desks… But in my opinion, they all failed. Many people participated… and many were spending much more time “building their reputation” than doing their actual work.

Maybe the most important take-way from your post is that employees should be commended for doing a good job, and that recognition is a real motivator.

]]>