by Mark Martins
Working with budgets is something we all accept. Every research project has a budget, your client has one, you have one and your operations team or partner has one as well.
We all understand that there is a cost associated with labor and that people and businesses don’t work for free. Having said that, it is easy to forget that there is a finite amount of hours assigned to each project for programming and clients tend to be surprised when additional charges are incurred.
A number of factors can impact pricing for survey programming services, including:
- Beginning programming of the survey without a final survey questionnaire
- Receiving changes that fall outside the allowable number of hours included in the price
- Increase in survey complexity or length of the survey
- Heavy use of Rich Media Tools
- Large number of images
- Custom requests
In order to minimize scope creep/price increases, it is best to ensure that a final survey questionnaire is ready before programming begins.
The costs associated with survey programming should include a reasonable amount of hours for change management. You cannot track how much of your change management budget you’ve used unless you know how many hours you are allotted, so be sure you have this information. Changes beyond the limit usually result in added fees.
Nobody likes being surprised with additional charges, so here’s a few tips to help you save on survey programming:
Before programming begins
Tip 1: Ensure all relevant parties have provided their feedback on the questionnaire design and content before the survey is submitted to the programming team.
Spending a few more hours ensuring your questionnaire reflects your research needs minimizes changes and speeds up the programming process significantly (it may also save you money). Make sure all decision makers have had an opportunity to provide their feedback at the design phase, not the review phase.
After reviewing the test link
Tip 2: Always consider the cascading impact of your changes. Determine how your change will impact other questions that are asked in other sections downstream.
Tip 3: Never change question numbers after programming begins. Doing so will force the programming team to assign new ID’s to existing questions and re-program any logic that refers to those questions.
Tip 4: Never change code numbers for answer options (same reasons listed in Tip 3)
Tip 5: Always document all your changes by either highlighting the changes or by using the “track changes” function in MS word. If possible, provide a separate document listing all the changes. Poorly documented changes result in quality issues and/or delays during the programming phase.
Tip 6: Review the entire survey link and collect all feedback from your team before submitting it to programming. Although it may feel like you are speeding up the process by sending multiple changes, the time needed to review, clarify and implement each round of changes will be greater than working on one single list of changes.
Tip 7: Talk to the experts! If you’re unsure how to design or document complicated changes or logic, speak to your programming team. They can listen to your needs and suggest the best approach.
*This post originally appeared on LinkedIn.