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.

Project Commissioning – Part 2

In the first part of Project commissioning, we talked about final testing and preparation of the project including the actual shipping of the system. This, week we talk about the on-site commissioning.

Delivery and Installation

Since we completed the FAT, system delivery and installation is always a breeze. Right?  Well, just in case, you should have defined practices for field changes. What is acceptable? Anything that makes the system work? Gets the customer off your back, so you can get out of there? I guess whatever you decide is acceptable, but there should be a method to document the field changes and make sure that all project information is updated accordingly.

SAT Down with Your Customer

After the installation is complete, you should again have a process to validate its operation against the specified requirements. This time for sure, you should have a document validating customer approval before you leave the premises.

License to Drive

You should also have a process by which you clearly transfer all software licenses to your customer. Note that is not sufficient has just taken possession of the system. You should inform them that you are transferring the licenses and some way for them to accept the terms and conditions of those licenses. For instance, they have to break the shrink-wrap, an envelope, or container that contains the associated licenses.

Project Commissioning – Part 1

OK, so you are getting close to the finish line – almost done with your project development. You may running on schedule or rushing to meet the deadline, but it is still no time to let lack of project management lead to unnecessary and costly mistakes.

FAT and Happy

Make sure that you perform a thorough Factory Acceptance Test (FAT) as defined by your V-diagram process to validate that your system meets all of the specified requirements. Involve the customer if possible. But, regardless, there should be a formal sign-off sheet with initials by each met specification. Some Alliance Partners even have a formal approval process before the system can be shipped.

In Ship Shape?

While being FAT is good, you still want to be in ship shape. So, take steps to avoid errors and delays. Have you checked to see if your labeling meets any requirements that your customer must have? Do you have a way to verify the complete shipment (e.g. pack slips)? Do you have insurance guidelines for shipments?

Project Development – Stay on Task

Now that you have an optimal design, the development work can proceed. Your development team should have defined processes and structured approaches to ensure that the work is as consistent and efficient – and conducted according to your project plan. Each development task (sometimes referred to as a work package) should have defined milestones, gates, and deliverables.

Use Standards and Assets

For most service-oriented business, design re-use is the only way to ‘get ahead of the game.’ Re-inventing the wheel – just won’t cut it. So, develop and use templates, coding practices, wiring standards, ….

Test Early and Often

Just like in the manufacturing lines where many NI-based solutions are deployed, it is good to test early and often to catch mistakes early and avoid lots of re-work. So, formalize your practices to test at the unit/module level as well as points of sub-unit integration. Verify that each task is correct and complete. As development progress, check to make sure that the system requirements are being met.

Managing Subcontractors

If you use subcontractors to assist your development efforts, implement processes to make sure that their quality meets your own. That starts with a formal evaluation and selection process, including contracts to avoid conflicts of interest, protects IP, and preserves T&Cs of your work. Once chosen, they should follow your procedures for communications, change orders/authorization, and work approval.