requirements
#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
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