large projects
#1: You took the buffalo for a walk
Monday, March 23rd, 2009 | EIM, SPM, Top 'n' Lists, Top 5 Mistakes Collecting SPM / EIM Project Requirements, large projects, requirements | 2 Comments
#1 of 5: Top 5 Mistakes Collecting SPM / EIM Project Requirements
You need to be in control and organized. And if you’ve ever tried to walk a buffalo, you can attest to the fact that you are not in control of that situation. In this metaphor, the buffalo is a requirements meeting without an agenda. They can definitely get away from you and cause a lot of damage along the way.
The Problem
Implementations have a natural order of events.
• Scoping/Budgeting
• Resource Selection/Planning
• Project Start
• Requirements
• Design
• Etc…
› Continue reading
Similar Posts:
- #2: You painted the wall from bottom to top - JasonKearns
- #3: You asked the tourist for directions - JasonKearns
What’s in a name?
Tuesday, February 17th, 2009 | EIM, Project Direction, SPM, humor, large projects | 1 Comment
As humans, and if you’re reading this you most certainly are a human, we have a biological need to name everything around us. Whether it’s insects, rocks, cloud formations or psychological disorders… it needs to have a name. In fact, upon encountering a new object such as a star, the first thing we humans do is name it.
Manmade creations such as software systems are not immune to this. When we burn long hours putting in a new HRMS, CRM or SPM system we need to put a moniker on it so that we can communicate. The interesting thing is all systems get a name whether we force them to or not; they take on a name in one of three ways:
1. We can’t think of anything.
Most times there isn’t much thought put into naming a system but it takes one anyway. In this case, probably due to the enormous amount of marketing done before and during the project, the overall system takes on the name of the major software vendor involved. We see many SPM clients refer to their system as the Callidus or the Oracle tool. The problem with this naming method is it is often the case that the calculation engine is but a small part of the overall system. Subsequently, the brand either suffers or benefits from elements it can’t control. Basically anytime anything goes haywire all you hear in the hallways is… “It’s Callidus again; that thing never works.” Who cares if the problem was due to bad data from SAP or a botched network upgrade rather than the vendor software product itself? The name gets the blame and the brand suffers. Many front line reps hate their SPM software vendor and have no idea why. This also hurts the IT department in the long run when they need to make decisions about upgrades and future applications. If you choose the same old vendor who everybody hates, you don’t look very smart.
2. We can’t think of anything but we know what NOT to call it.
I’ve been a part of some real initiatives with clients where they really and truly want to come up with the perfect system moniker… but couldn’t. Either they couldn’t agree or they just didn’t get any great ideas. All they know is they don’t want the words Callidus, Oracle or Varicent being spoken in the halls. This noble effort still produces a name, just not a very creative one. Constituents begin calling it what it is, the system that calculates their paycheck. Usually something like: The Commission System or the Bonus Calculator. In some cases the tool takes on the name of one of its creators. This is how you get enterprise level systems with names like: The Jared Tool or The Tom Report. I personally love it when reps refer to the entire SPM system as a “report”. Another de-facto name origin can be the database where your application’s data resides. That’s how you get names such as MRDB (Management Report Database) and ICDB (Incentive Compensation Database). Usually this kind of name would be relegated to the IT department. Then you might have the unfortunate multi-name situation where IT refers to the system as ICDB, the reps call it The Tom Report and HR calls it The Bonus Calculator.
On a side note, I once worked on a project where two months in we put together a nice big workflow diagram with 21 steps represented as boxes. The boxes were numbered 1 to 21. Two of those boxes ended up becoming user interfaces that were developed roughly 18 months later. What were the names of those new applications? The Number 7 Tool and The Number 13 Tool. We hadn’t bothered to come up with better names and by the time we decided to try it was too late. The original names stuck even though very few people on the team had any clue as to what those names originally meant. I bet there are plenty of similar stories out there.
3. Let’s name this thing properly.
Occasionally companies want to name the system and they do it successfully. The “perfect” name apparently is an acronym that cleverly describes the system and also serves to be a decent name for a compensation system. Here are some good ones.
These are the best I’ve seen.
COINS – Commission and Incentive System. I’ve seen this one at least three times.
CECS (pronounced checks) – Commission Earnings Calculation System
Here are a couple I’ve seen that are at least real acronyms.
CABS – Commission And Bonus System
SCARAB – Sales Commission And Reporting And Bonuses.
On the lighter side, here are some names that didn’t pass either because they’re border line vulgar or downright mean spirited.
CRABS – Commission, Reporting, And Bonus System
CRAPS – Commission, Reporting, And Payment System
MAGIC – Mostly Accurate General Incentive Comp
CLOSE – Commissions and Liabilities Operations System for Employees
ALMOST – Automated Liability Management Of Sales Transactions
ENOUGH – Employee Operational Unit Gage Heuristics
GUESS – Genuine Underwriting Employee System
SCARI – Sales Compensation And Reporting Infrastructure
ACE – Almost Calculates Exactly
CRASI – Commission, Reporting And Sales Incentives
OPTIC – Over Pays Their Incentive Compensation
UPTIC – Under Pays Their Incentive Compensation
No doubt there are many more out there and we’d love to hear them. We’re fascinated by the genealogy of system names.
Similar Posts:
There’s Value in the Journey
Tuesday, December 16th, 2008 | Compensation Plans, Project Direction, large projects, requirements | No Comments
We’ve all the heard of the Law of Unintended Consequences, that is that actions of people always have effects that are unanticipated or unintended. Although this term is typically used to describe government, I’m sure most of us have experienced it. Those of us in the realm of sales compensation know all about this Law. A move that seems beneficial one day can expose massive consequences the next. Conditions are always changing and you can debate decisions for weeks without truly understanding the impacts. But let’s not get too negative here. Why do all Unintended Consequences have to be “Consequences”? Many benefits can also come without warning. The world of R&D is teeming with examples of projects gone wrong leading to breakthroughs in unexpected areas. This kind of serendipity need not be reserved for those in white coats. We should all keep an eye out for the “good” in all this uncertainty. Most of us already agree that all decisions are temporary. That’s why a push to having more system flexibility is vital to having up to date and effective incentive plans.
The need for more flexibility usually leads to a new system altogether. This brings about the most critical decision of all… what do we build and how? So let’s do assessments, let’s do vendor selections, let’s diagram and hypothesize to our hearts content. ROI analysis needs to be done and the numbers have to work. Can we drop headcount? Can we reduce overpayment? What’s the value in turning around plan changes faster? How many hours per day will our sales force rededicate to selling when their reporting is better?
I love the early theorizing about a new system. There is always such optimism. Compensation Managers and Compensation Administrators are usually dying for some sort of relief from their current predicament. I love bringing that relief. I’ve been there and feel for them. That being said, it is rare that the final delivery of a system lives up to these initial dreams. No matter how “realistic” we try to be, the road to get a system up and running always takes a toll on scope and budget.
This is where I offer some encouragement. The Journey brings its own rewards. Often times, we focus so hard on the finish line and lose sight of what we’re learning every day. Take this list of tasks:
· Processes
o Document system workflow for compensation calculations.
o Document business operations workflow for compensation calculations.
o Define ideal skill sets and headcount for IT and business operations.
· Comp Plans
o Obtain catalog of current plan documentation.
o Devise method for managing plan change version control.
o Agree to SLA for turnaround on plan changes.
o Define all key data sources and data elements needed for current and future plan calculations.
· Reporting
o Discover true business critical end user reports and their requirements.
o Investigate need for ad-hoc analysis reporting.
o Define all key data sources and data elements needed for current and future compensation reporting.
· Testing
o Create test cases and methodically test calculation scenarios.
o Identify gaps in automated functionality and devise adjustment procedures that satisfy SOX.
All of these tasks are part of a typical systems implementation. Notice that none of them actually require the building of a new system. Yet, not many organizations can afford to spend time doing all of these tasks without the pretense of a large new system development. What is the value in doing all of these things? In many organizations these would be monumentally valuable especially if you start uncovering gross errors or if your lack of documentation is hurting your ability to handle turnover.
My point is to appreciate the Unintended Benefits of your project—not all unintended consequences need be negative. If you can find a way to predict these benefits, then an ROI case can be made; regardless, at the end of the day going through this process can improve your organization if you take proper advantage.
Similar Posts:
- #2: You painted the wall from bottom to top - JasonKearns
- EIM / SPM system upgrade: port or reengineer - MichaelStus
Beware of unneeded system flexibility
Sunday, October 26th, 2008 | Project Direction, large projects, requirements | No Comments
Software package implementation including EIM/SPM software can be a complex process and many projects are not successfully delivered or are done so over budget. One issue that often causes trouble on projects is the introduction of functional flexibility that is ultimately unneeded. Many times when a business owner is asked about a particular business function there is a tendency to overstate the need. For example plan sales compensation plan administrators often say they need the ability to change a particular commission rate or rule effective at any time, even multiple times within a pay period. In reality based on how the compensation plan is constructed, it may make no sense to do so and the practice may actually never be done this frequently.
Why should software systems implementers and the eventual owners worry about this unneeded flexibility? The simple answer is that if these requirements make it into the final feature set to be delivered, costs can increase dramatically. The direct relationship between feature addition and development and delivery costs is obvious. Additionally, in severe cases of unneeded feature bloat, the system may become undeliverable. Finally, unneeded flexibility may result in a system with increased complexity causing higher post implementation maintenance and operational expenses.
What drives the introduction of unneeded requirements for a software system? Several that I have experienced:
• Business owners do not want to restrict themselves – Business owners do not often find themselves being asked what they want in a new software system. Not wanting to blow this chance, they have a tendency to cloud attention to true practical business need with a kid in a candy store mentality. Additionally no business owner wants to be remembered as the one that gave in on a system requirement that down the road hinders business function. Erring on the side of caution for a business owner means always answering requirements inquiries with the most flexible feature rich driving answers regardless of true business need.
• Limited access to true statistics on business process – A well designed system should best satisfy the automation of business tasks that are most frequently performed and that are most critical to success of the enterprise. Often though, true data about the frequency at which certain business events or functions occur is not known; project timelines often discourage proper analysis which would provide data crucial to the best requirements set determination.
• Inexperience among requirements gatherers - Business analysts or others who have been assigned to gathering system requirements may lack the experience to ask the right questions of more seasoned business experts that will own the system being developed. Additionally, if these business analysts are not familiar with the workings of the proposed software, they miss opportunities to steer or corral functional requests into the most implementable options.
How can this issue be addressed? More education about system delivery process across all members of the project team can help. Business owners and business analysts can benefit from a better understanding of how the software works. Additionally these team members should not be isolated from the development and eventual operational costs associated with the decisions on requirements and feature set determination. Requiring business owners to justify requests with real statistics about the frequency of occurrence of scenarios driving their inclusion can help distinguish absolute from exaggerated need. Finally, understand going live with a system with the critical subset of all desired functions is an option; plan for additions but allow time for the evolution of business process that certainly take place with its introduction to dictate their priority. Encourage all parts of your delivery team to keep these ideas in mind; sacrificing some functional flexibility is well worth avoiding a poorly designed, difficult to operate, or undelivered system.
Similar Posts:
- EIM Solutions Resist Commoditization with Supplementary Features - MichaelStus
- There’s Value in the Journey - JasonKearns