Today I am a compensation plan and direct selling expert. I help companies to launch and grow faster.
Prior to starting Sylvina Consulting in 1999, for 13 years I worked as a software developer, business analyst, and project leader for an MLM software company. I can tell you from firsthand experience, that it’s not easy to anticipate the needs of network marketing and party plan companies, many of whom intentionally try to run their businesses differently from their peers.
In my first life, as a Business Analyst for a software company, one of my assignments was to work on a project for a 40-year-old network marketing business. A man who held a high position in that company told me two years later, “We could have been a better client.” At the time, it wasn’t appropriate to agree with him, but he was speaking the truth. There were a lot of things he and his company could have done differently, which would have been good not only for the software company but also for their network marketing company.
I view the relationship with your software company or software developers as a marriage. For a good marriage, both parties need to be good communicators. More often than not, when software relationships suffer, it is because of a lack of good communication.
Being A Better Software Company Client
Did you know there are things you can do to be a better software client?
- When you verbally make a request to your software company or internal programmers, always follow up with that same request in writing. Ask for and receive a confirmation back.
- When you make a request, be clear in what you expect will be included and also list what you expect won’t be included. The better you define the scope of a project, the more likely the project will meet your expectations.
- Many software changes have ricochet effects. This means making a change in one area of your software may cause inconsistencies with software in other areas. Accept the responsibility to ferret out these “other” areas. Don’t assume your software developers will find them on their own.
- As soon as you think you need a software program created or changed, write up the requirement and give it to your software developers. The sooner you request a project, the higher the likelihood you will get it when you want it.
- Sometimes not all features in a project are needed at the same time. Prioritize the features so that if you need to wait longer for some of them, the right ones will be delivered first.
- Don’t assume your project will be delivered when you want it because you are the client. Ask for acceptance of your deadline. If you can’t get it, then adjust your deadline to one your software company or programmers can agree to. Remember to include sufficient time to test the program before you need it to go live.
- When a new software program or modification is delivered to you, assume it doesn’t work exactly right. Test it thoroughly. Prove to yourself it works 100% before assuming it does.
- If there is something wrong with a deliverable, finding the problem just before you need the program may be too late. The earlier you can test, the better.
- Saying thank you for a job well done helps motivate anyone to repeat the great performance next time. Isn’t that what you do with your representatives?
Compensation Plan Communication
Please, no one-pagers! Compensation plans cannot be communicated to software developers with merely a one-page chart of title requirements and compensation percentages.
The document you create to explain your compensation plan to your sales force is not detailed enough for your software providers or developers.
The best way to communicate the requirements of your compensation plan to software developers is to create for them a complete technical design document.
What is in a complete technical design document? I’m glad you asked, so I’ll tell you.
Placing your definitions on the front page of your technical design document is imperative. This way, they will be read first. When definitions are placed at the end, they are often not read by developers until later when a mistake is discovered.
In your definitions section, be sure to define all types of volume that you track. These could include Personal Sales Volume, Group Sales Volume, and Organization Sales Volume, for example. If a volume is calculated differently at times due to an exception, mention the exception in the definitions section.
Define exactly what it takes for a consultant to be classified as active, inactive, bonus qualified, etc. If there is more than one type of sponsor relationship (for example, enroller relationships and placement relationships), explain each of them clearly.
It is not a good idea to explain your compensation types only in a chart. Use as many words as you need to fully explain each of your compensation plan types.
Be sure that whatever terms you use to explain what is required for title promotion and title maintenance, these terms are first introduced and defined in the definition section at the beginning of your technical design document.
I learned a long time ago that it is not good enough to have a great set of definitions, an explanation of each compensation type, details on the title promotion and maintenance requirements for each title, and a summary chart. You also need to have in your technical design document some payout examples to illustrate your compression rules.
It is OK to have a summary chart in your technical design document. It is not OK to have a chart without the other sections just discussed.
The Blame Game
Whenever the software doesn’t work, we need to blame somebody. There are many possible points of failure.
Who can we blame? We can certainly blame the software tester for not catching the problem before the software went live. We can blame the programmer for not coding the requested functionality correctly. We can blame the analyst for not documenting the software requirements correctly. And we can blame the project’s stakeholders for not communicating what they wanted completely or clearly.
As you can see, there are many possible points of failure.
Taking Responsibility
The first step to fixing a quality problem is to measure where the quality problem started. In my 33 years of experience working with software developers, the most common factor to account for software problems is the lack of a business analyst.
A business analyst translates a stakeholder’s needs into written requirements. Not everyone can be a business analyst. If the requirements are incomplete or riddled with errors, there is a 100% certainty that the software will not function as desired. You can bank on it.
Quality Assurance is not the last step in the development process. Instead, QA is a commitment to quality in all steps.
The better job you do in communicating your requirements to your software providers or software developers, the better job they will do in meeting them.
Be A Better Client
Your software developers or software providers can only do so much. Garbage in, garbage out. Do your part to be a “better client.”
If you need some coaching or help to be a better client, call me. I can help you to design, improve, and/or document your compensation plan and other software requirements.
Jay Leisner
Sylvina Consulting
www.sylvina.com
503.244.8787
Jay Leisner, the President of Sylvina Consulting, is a top compensation plan and direct selling expert, a trusted adviser to new and established network marketing and party plan companies. For more than 30 years, Jay has enjoyed assessing and improving network marketing, party plan and referral marketing companies across the globe.
Leave a Reply