Before we explore the business motivation and possible strategies for protecting your work, let’s recap all of the protection options we have in Excel:
Let’s explore different protection strategies from the business need point of view. Contrary to what you might expect, I’ll start off with the most demanding situation and work my way down the stream.
If you package a tight Excel product and sell it as a standard package to any paying customer, you would probably want to:
I presume you get the importance of protecting your IP intuitively. I do want to emphasize, though, the last point: protecting your product. It may seem to be an aesthetic, or convenience, or ease of use issue. It is much more than that. This is about your product robustness. This is about your reputation.
Typically, software products, especially built with Excel, are highly complex under the hood. You have dependencies between multiple players: VBA algorithms, range names, columns’ width, cells’ formatting, etc. Breaking your product’s integrity will leave the user with bad experience and your reputation will be stained. Yes, this will happen subconsciously, even if he knows it broke after he crossed the line. You want to keep the integrity of your product intact!
In order to cover the above interest, I’d recommend the following possible methods:
I do want to say that not all products deserve such a strict protection approach. My Excel Date Picker, for example, is not protected at all – it is delivered with the VBA code open for adaptation and learning.
The main difference between a product and a project, as far as our protection discussion is concerned, is that a product reaches many users you may not even know, while a project is delivered to a specific customer with which you have on-going relationships. (I elaborated on other differences between a project ad a product in my last week’s Blog post here).
Generally speaking, the protection bells are very moderate with a project. I rarely protect my VBA code, for example, even though it includes a library of hundreds of VBA functions I devised over the years that are a highly valuable IP of mine (by the way, I do offer a subset of this function library for free here).
If I do want to protect my VBA code, I clarify in the agreement that in the case that I cannot guarantee my support and maintenance services to the customer, I will release the code for him. This way I’m protected for as long as I care to maintain my business software career, and the customer get’s a fair degree of freedom and security.
On the other hand, I never compromise on user experience and solution integrity. In that regard, password-protection of the Workbook and all Worksheets are a must. The experience and integrity of the application are tightly controlled.
Needless to say, I do not log any activities on the application. The only standard HTTP communication to my external web-services and repositories outside of application-specific Internet communication needs, is the query to the customer name and product name to be displayed in the standard Splash screen, as in this example:
No data is sent outside of the customer environment to me.
Occasionally, I’m asked to design and develop a product for another entrepreneur. Such was the case with the Excel Rose Diagram. On one hand, it is a project for a specific customer. On the other hand, it will be a product that will reach many customers I have no control of.
The setting is even more challenging, as my customer requires access to my VBA code, not to be locked-in by me.
This situation is delicate and not guaranteed to always be resolved.
These days, I’m working on such a project for an Australian customer. The product is a pre-sales opportunity tracking workbench towards a streamlined closure by the end of the quarter.
In this case, the customer foresees the Excel solution as a first phase (sort of a prototype) before developing a cloud-based solution, therefore he was OK with me protecting the VBA code from view. Not always that’s the case, and I need to decide what am I willing to compromise, and what not.
In this situation, you may be working for a company (on a paid salary) and share Excel Workbooks with other colleagues. These Workbooks may sometimes contain sensitive data you don’t want others to see.
There are already good measures of protection, by the confidentiality agreement all employees are bound to. Still, it is usually corporate policy to have every employee be exposed to what he needs to see for his line of responsibility, and not more.
A fair measure here would be to Password-protect the Excel file for opening. Sometimes that will be just enough.
Join today to the Excel VBA Inner Circle with Mor Sagmon.Get a weekly lesson, weekly live Q&A, monthly deep-dive workshop, monthly challenge and other activities.