Licensing/Activation for 3rd Party LabVIEW Add-Ons and EXEs

In the next version of LabVIEW , we will introduce a new method for licensing/product activation of third-party products (for Windows platforms). You will be able to add a layer of licensing to your add-ons and EXEs to protect your products with a similar sort of mechanism that NI uses. The licensing feature employs a commercial-grade encryption scheme and automated activation system.

How it works

There are two types of licensing that this feature will enable: development licensing and deployment licensing.

1. Development licensing refers to protecting VIs in the LabVIEW environment. Add-on toolkit developers can use development licensing, so that licensed VIs break when a valid license doesn’t exist, thus preventing toolkit user from using an evaluation/expired version of a toolkit.
2. Deployment licensing refers to protecting an application at run-time. With deployment licensing, you can develop turn-key, commercial software application built with LabVIEW without the need to implement your own licensing/activation scheme. Deployment licensing will be made feasible through an API, so you check license states and activate licenses through your LabVIEW programs.

Want to learn more?

If you are interested in a webinar presentation to learn more, or to discuss specific software licensing/activation use-cases that your organization faces, please contact:

Jeff Meisel

Product Partner Program Manager / LabVIEW Product Manager

jeff.meisel@ni.com

(512) 683-8795

Reasons for Change Management

During an presentation about Project Management Practices that I recently gave at the UK Alliance Day, we were discussing the reasons for a good change management process. Some of these, I’ve mentioned in a previous post:

1. Accurate reflect that there has been a change to the contracturally agreed on specifications/requirements. I think this is the best ‘excuse’ to ‘enforce’ this process with the customer.
2. Recognition/approval to potential impact on timing and budget. Your developers should be made (painfully) aware that agreeing to changes, cost money. Regardless of whether they can be accomodated (in the timing allowed), you are adding value – and that should be captured and recognized.
3. Sets precedence for further changes – If you ‘blindly’ accept changes, then it is harder to get it stopped once it gets going. The customer is apt to say, ‘Well, you made these other changes (which may have been bigger). Why not this little one more?”

Notifications

I also advocate that Customer Change Notifications/Approvals. Even if you don’t intend to charge the customer, the change should be documented, the cost of that change estimated and included on that notification, as well as a separate spot to indicate charge to the customer (even if it is zero).

A couple other reasons

I got feedback from the audience that there are a couple other reasons to follow this process:

1. Change may just not be worth it – By formalizing the process, you give the customer (and/or your developer) to determine that it just isn’t worth the ‘hassle’ to make the change – including documenting it and getting the necessary approval. In that case, you’ve probably saved yourself some time and effort.
2. You might just get paid for it. Must admit that I’d probably hadn’t given this one enough consideration. So, you may just want to present Change Notification with the charge included and only zero it out if the customer pushes back. Even then, you established that you are providing extra value to the customer.

What say you?

Getting the feedback from my presentations, reminded me that I should do a better job in these blog posts to ask your thoughts and opinions. Do you have a formalized Change Management process? If so, what do your find effective (or not)?

Top Ways to Lose Money On Projects

After spending a couple weeks blogging about how to ensure project success, I was reminded about a presentation given by Dean Streck from V I Engineering back at NIWeek 2001. He gave a humorous presentation on the top ways to lose money on projects.

1. Don’t communicate … ever … with anyone (not your coustomer and not your vendors.)

2. Don’t train you sales team – on how to make contacts, assess customer needs, estimate projects, validate quotes, negotiate terms, close sales, ….

3. Verbals are as good as gold. Don’t worry about getting final specifications. Forget about kick-off meetings. Just take any version of the project proposal and dive right into building the system.

4. Don’tbother with project management. Just put junior engineers to the task. No need for a design review or leveraging existing technical assets. Encourage them to do it their way without constraints. 

5. Plan to use 100% of your budgeted time. And, if the customer asks for changes, just say yes. Memories are perfect, so don’t bother documenting anything especially changes. The only status updates occur at the beginning and end of the project. If your engineers do have extra time, have them spend it perfecting the system beyond required specifications.

6. When you think your done coding, try installing the system right away. The best place to find errors is at the customer site. Don’t bother the customer by calling in advance and scheduling time. Assume you will have clean power and noise free environment.

7. Support contracts are a waste of time, so forget about them. Just agree to fully support your system if the customer is ever dissatisfied or makes any changes.

I must admit I got some chuckles looking back through this presentation. Hopefully, you will too.

How To Ensure Project Success

Last week, I referenced this article, written by Vance VanDoren, of Control Engineering about how to avoid project failure. In addition to discussing the most common reasons for failure, he provided a list of ways to succeed:

1. Define project goals;
2. Develop project scope and schedule;
3. Establish multi-discipline project team;
4. Define the mechanical process;
5. Develop functional process controls descriptions;
6. Develop network configuration drawings; and
7. Develop equipment and programming specifications.

First Things First

I have to agree that lack of good/solid project requirements is probably the #1 challenge to project success. This can result from the customer not having a clear understanding of the project, the integrators failure to perform adequate requirements, or simply the sense of urgency to get the product started (without sufficient requirements.

Get the Customers to Help You Help Them

As I said last week, you may want to reference Vance’s article with your customers as a way to educate them about common project pitfalls. By better educating them, you can increase their understanding and desire to help you ensure the success of the project.

How to Avoid Project Failure

I found this article, written by Vance VanDoren, of Control Engineering. He discusses how system integration projects don’t always go smoothly. He lists the 10 signs of impending failure and 7 ways to stay on track. For instance:

Ten reasons for failure

1. Incomplete requirements;
2. Lack of client involvement;
3. Lack of resources;
4. Unrealistic expectations;
5. Lack of executive support;
6. Changing requirements and specifications;
7. Lack of planning;
8. Didn’t need it any longer;
9. Lack of management; and
10. Technology illiteracy.

Industrial automation projects may or may not fail as often as software development projects, but the reasons for failure are very similar, according to a less formal survey recently conducted by Control Engineering. All 1,800+ system integrators listed in the Automation Integrator Guide were asked to describe why an automation project might fail, what signs point to impending trouble, and how those problems can be avoided. Not surprisingly, several respondents agreed with the Chaos Report’s finding that “incomplete requirements” is the #1 problem.

Pass Along to Your Clients

While directed toward the end users, he offers some good tips that integrators should also be (painfully) aware of. Perhaps, the article is something that you can even point your customer to.

By the way, I’ve discussed many of these topics in more detail on this blog. Check out the Table of Contents as a convenient way to find them.

Project Close-Out – Part 2

Some companies make the mistake of only considering a project close-out from an engineering perspective.  Your project close-out procedures should also consider business aspects.

Commercial Pause

You should also stop and consider commercial aspects to your close-out process. From a financial perspective, there should be procedures to ensure that all billing has been completed, including change orders. In some cases, Alliance Partners require that all payments are received, even client authorization to close the project.

Marketing and Sales Opportunity

Finally, there are marketing and sales considerations during project close-out. Some Alliance Partners require that a customer story be written, even if it will only be kept internally. Ideally, it can be used in future marketing efforts. Satisfaction surveys are also a common practice – not just as a mandatory quality process, but as a chance of looking for the next opportunity. Some Alliance Partners ‘require’ the salesperson to meet with the client to complete the survey. If the feedback is good, then it is certainly a good time to ask about the next project or a customer reference. Even if it is not good, you can reinforce your professional approach and desire to do better the next time.

Project Close-Out – Part 1

With the system is successfully commissioned, it is time to close-out the project. Just as there should be a defined process to kick-off a project, there should be a define process to close a project. Consider developing a check list (just like project kick-off) that must be done.

The Obvious

 First and foremost, your project close-out should include adequate steps to make sure all project information and materials have been properly stored for future reference. This should include procedures to incorporate any field changes made during the commissioning, so that the final project information accurately reflects the final deployed solution.

Engineering perspective

 Alliance Partners will commonly require some sort of project review. At a minimum, it is a chance to review lessons learned and share them with the rest of the staff. More importantly, it is an opportunity to capture IP. What can be reused for future projects including software architecture, hardware designs, even methodologies and techniques? You should also have procedures to ensure that all project documentation is completed and properly stored.

Next week, we’ll cover the commercial aspects of project close-out.